Secondary use cases

[Wilto]

So, the primary use case—which may be the only use case, really—is pretty easy to explain in broad terms. I’d love to see some community-contributed specific use cases, though: links to things you’ve worked on that would’ve been much less painful given an “element query” solution, uses that aren’t covered by the stuff we’re illustrating so far, and so on. No formalities needed—if you have a link to a live example or a Codepen/jsbin/jsfiddle, a write-up, a blog post you’ve read on the subject, whatever: fire away in the comments.

[anselmh]

Using responsive images, responsive videos (means media queries) in components on a web page. Serving the proper size is nearly impossible because RWD should react to element queries but can only react to media queries. I may write this down separately in detail with a demo.

Generally spoken, EQs would be a massive improvement for component based web applications where each component is independent and should work in different surroundings.

[derekjohnson]

If you have a wide main column and narrow sidebar layout in wider viewports, a component that consists of an image, heading and paragraph will probably need to be displayed differently depending on which column it's contained in.

One might want it to look like a classic media object in the main column, but display each element vertically at 100% width when in the sidebar.

AFAIK all we can do now is add a modifier class to the component, duplicate the components classes in child selectors of the sidebar, or throw JavaScript at it. We also have to tie the CSS solutions to the viewport width which further reduces their independence.

Basically what @anselmh said, just an example I've had to deal with on a few occasions.

[niksy]

Recently I’ve worked on project which needed to have responsive ad serving solution. One ad type that has shown the need for element queries are wallpaper ads.

Let’s say you have resolution of 1680px and main container with 1280px width. Left and right side should both have two ad placeholders with 300px width. Simple math says that you’re left with 400px for both sides, while both ad placeholders require 600px.

So what we did is placed class on parent element which signaled browser to apply different styling on current breakpoint if ad server is serving wallpaper banners—specifically, 1024px breakpoint styling on 1280px breakpoint. For that, we used scoped media queries which duplicated styling from 1024px breakpoint inside 1280px. This increased CSS size somewhat significantly, but we were able to keep it contained using provided mixin. This certainly wouldn’t be easy in terms of maintenance without using preprocessor.

[acolangelo]

A current project (launching Monday, will update with links) has a template that is using a masonry-type layout. The articles within this interface need different layouts based on how the columns resize (sometimes not uniformly). Since the content is always changing, the points at which these articles need different layouts are not predictable.

[rupl]

I have been experimenting with EQ-based responsive images using https://github.com/Snugug/eq.js

The easiest way to accomplish this is omitting src then using the callback available in the JS lib to populate the images based on the "state" of their parent component. Although this particular library achieves decent performance by forcing you to declare the element's possible breakpoints beforehand (and the only query you can specify is min-width), I like how each one gets a label. It's a nice bonus:

<!-- eq.js creates data-eq-state attribute from data-eq-pts -->
<div class="my-component" data-eq-pts="small: 400, medium: 600, large: 900">
  <h1>Hello World</h1>
  <img alt="my responsive image"
    data-src-small="path/to/small.jpg"
    data-src-medium="path/to/medium.jpg"
    data-src-large="path/to/large.jpg">
</div>

// Layout for .my-component
.my-component {
  &[data-eq-state="small"] img {
    width: 100%;
  }
  &[data-eq-state="medium"] img {
    width: 50%;
    float: left;
  }
}

// Create callback for eq.js (example assumes jQuery is around)
function eqImages() {
  $('[data-eq-state="small"] img[data-src-small]').each(function () {
    var $this = $(this);
    $this.attr('src', $this.data('src-small'));
  });
  // repeat for other two values in data-eq-pts...
}

// Register callback and send nodeList to library. A full example would also
// include a window.resize listener so that they update on orientation change;
// the code in the handler would be identical to this line.
eqjs.query(document.querySelectorAll('[data-eq-pts]'), eqImages);

[davidjgoss]

"List" components in particular spring to mind. For a real word example, look at .productlist here at different viewport sizes: <http://www.thackerays.co.uk/designer-womenswear/brands/ted-baker

It starts out with the image left-aligned, then shows two items per row when the viewport gets a bit wider, then switches to images on top with center-aligned text when the viewport gets wider still.

I'd like to reuse this component for a "Similar items" section in the last part of this template after the "Shop for more" section...: http://www.thackerays.co.uk/designer-womenswear/items/ted-baker-leyah-pink-black-shopper-58881

...but if I do that, when the viewport is wide it will be in a narrow column, but because the viewport is wide it will clumsily display in the larger format instead of the left-aligned format I'd want it to.

The other thing I thought of was forms; you might want to switch from top-aligned labels to left-aligned labels depending on the width of the container, and a form such as a newsletter signup could appear in many different contexts and therefore different sized containers.

Happy to start writing up either/both of these with images for the doc if it would help?

By the way, I'm beginning to form some thoughts on an element/container query syntax, is there a discussion happening somewhere about that?

[csuwildcat]

I believe @rupl is on the right track, place name-id'd query definitions in an attribute, and style against active query name-ids. That's the same conclusion I reached when coding this element query implementation/post: http://www.backalleycoder.com/2014/04/18/element-queries-from-the-feet-up/

[kylegach]

We (http://civicplus.com) build a CMS for local governments that allows the editor of a page to drop Widgets (e.g. A small calendar with a list of events, related FAQ questions, etc...) into Containers on that page, which can be of varying, flexible widths (and can also be split into columns, but the example stands if simplified to not include that feature). Similar to the example in the current Use Case & Requirements doc, these Widgets sometimes need different layouts depending on the width of the Container they occupy. At the moment, that is only feasible using JS to fake element queries (we used https://github.com/jonathantneal/MediaClass) as we cannot reasonably write Widget styles that are 1) specific to an individual site (our CMS powers 1600+ sites) and 2) cover all possible scenarios for those Widgets.

You can see this system in place here: http://snohomishcountywa.gov/, though that site was specifically-designed to not require the use of this feature any more than we had to.

TL;DR - The example in the docs is compounded when it is a user/editor (as opposed to a developer, i.e. us) that controls the placement of the elements needing queried.

[peterwilsoncc]

Perhaps subtly different to the existing sidebar use case, is an example in which a sidebar can be toggled by the user.

The class - or other DOM changes - used to open/close the sidebar could be outside the tree containing the elements with the EQs.

[PaulSpr]

A secondary use-case could be better responsive backgrounds. We can now change backgrounds based on window dimensions, but it would probably be much more efficient (bandwidth wise) to do this based on element dimensions. The element is usually smaller than the window which means that a small background is enough. Or even better have a small, square and wide background and load the appropriate background based on aspect ration of the element.

[Wilto]

Nice. Great stuff, guys—thanks.

[jonathanKingston]

The main use case for me as I said in #9 is:

Having element queries for a web components allows components to be self contained. I think that with this separation template authors could concentrate on laying out these reusable blocks with far less care of the contents of the components.

To the extreme I feel this means a content author can write html in a lego style fashion with a reduced need for littering css with endless single use scenarios as we see currently leading to lots of fragmented hard to maintain styles.