I feel you're approaching the problem in the wrong mindset. You're imagining that you have one module and that's all you ever have. Instead, think of a the CSS module (your .testimonial module) as an interface - a blueprint to implement different types of .testimonial module variations.

The BEM architecture calls these "Modifiers" (http://csswizardry.com/2013/01/mindbemding-getting-your-head...).

When I look at your example, I don't think of a .testimonial object in two different contexts (one vertical in the sidebar of the signup page while one horizontal on the pricing page). Instead, I think of two different variations of the .testimonial object. So while your .testimonial class may define certain global styles, you change what you need by variations like .testimonial.vertical or .testimonial.horizontal (though I wouldn't actually use those names, but you get the idea).

This requires making a decision on when to apply what classes, but that's okay. You shouldn't be trying to abstract away actual UI decision-making to an automated tool or process. You seem to think that settings rules and logic to be executed based on those rules (when x, execute y; when y, execute z; etc.) will mean you always end up with a usable interface. However, this is not the case.

Ultimately, UI is not "write-once, use anywhere", and that's okay.

I've been thinking about adding a mobile version to Scribophile lately but reading about the craziness of media queries and browser support is kind of scaring me away.

I think the core of the problem is that CSS was designed to style documents (because the web long ago was more or less a collection of text documents), but as the web evolved, it became necessary to use CSS for styling UIs--an entirely different beast from documents.

This twisting has led to the state we're in now, where CSS creates the problem it tried to solve: updating a style on a medium-complexity web site requires digging through a minefield of complex and interconnected CSS. Yes things like SASS or LESS can help but they're not an ultimate solution, nor are they a web standard, so tying your horse to one of those carts can limit you in the future.

Maybe in CSS5 they can add proper object-oriented syntax and element queries to help increase modularity and reuse and decrease cascading and media query complexity.

Open question - who is really involved in developing the CSS specs and specific implementations for specific browser? Is it people who would also end up being end users, or people with a more theoretical/academic background?

I ask not to be snarky, but ... I've never really been satisfied with CSS. CSS proponents have shouted me down (figuratively) for being a 'tables' holdout, but it felt to me like we traded super-nested tables with ALIGN and CELLPADDING attributes for box-model hacks and numerous interpretations of the word "may" and "should" from years-old spec docs; it didn't feel like that much of an improvement in many cases.

Do browser makers consult 'regular' web developers before coding in new browser-specific CSS extensions?

It seems like this would be a great thing to implement "shim-first". Create a solid spec that defines the way it should behave, then write a JS library that makes the spec work in current browsers. Then you have a set up where browsers can implement it natively and only improve performance without changing behavior.

What I think we're starting to need is a separation between CSS for visual styling (font-size, border-radius, background-color, etc.) and CSS for layout (float, margin-left, etc.).

The first can only be done by CSS in the browser. But the second can be accomplished via CSS, or by JavaScript.

As the web evolves, CSS for layout is increasingly not keeping pace. But it's not unreasonable to think that we could do away with it altogether.

Is there anything preventing someone from creating totally new layout models, based on new formats, that are parsed in JavaScript, and essentially turn everything into div's with position:absolute? And get recalculated upon window resize etc.?

This would completely free us from existing layout limitations of CSS, to do the exact kind of things like element queries, or whatever else we might think of.

I'm just not really sure what the performance implications would be like.

Wow. In retrospect, when we needed general conditionals in CSS, we got just one, very specialized one, and the rest was swept under the rug.

How did I miss that until now?

So, until we have a full blown prolog interpreter for CSS layout calculation, someone will always complain CSS is not sufficient. What a surprise...

Maybe we should update CSS to include object oriented features too. Then we can have abstract factory methods for our reusable components. Throw in an optional type checker for good measure while we are at it.

Please people, CSS and HTML only ever have had a single layout algorithm. Maybe it is not terribly flexible but it is good for limited width and unlimited unknown height presentation of a single stream of content. If your content genuinely calls for a different layout, please consider using something else other than CSS and HTML.

While I appreciate the endless efforts to workaround and improve the layout capabilities of CSS, may I suggest embracing the limited nature of this stack and design accordingly?

Maybe, if we admit the "content" arrive, is rendered and consumed sequentially, we would relieve ourselves the burden of beating CSS into submission whenever we want to diverge; with the added benefit of making life easier for those who can't see.

You wouldn't shy away from a little bit of challenge of learning something more suitable for you purposes, right?

TFAA apparently decided on an eye-grabbing headline rather than one which matched his article. It probably works, but it's sad: his actual thesis is that media queries are insufficient or the wrong tool.

As acabal notes, the core issue is that CSS was originally for styling documents, and media-queries work in that framework: they're about laying out or formatting a document, not a component within the document.

Which is of course the wrong approach if you're creating distributable/reusable components and blocks. Media queries are not a hack and are probably necessary: the final author will use them to lay out his site/page responsively.

But they're not sufficient, because the inner layout of a sub-element is impacted more by the element's size than the viewport's (the sub-element's positioning and size on the other hand are affected by the viewport).

All in all, the article is a good note of a real problem. But its headline stinks for the usual reasons.

Your not using media queries correctly if your having these issues. If you want widgets to be responsive to a parent element then make them fluid. The fluid technique has been around since the beginning and doesn't require media queries. I keep seeing people talking about crazy new units and grid systems, etc, etc. Just learn how to use media queries correctly... Sounds like you are using too many breakpoints. General breakpoints with percentage widths can do anything.

This is such an excellent point. Media Queries have been bugging the hell out of me lately for a reason I couldn't put my finger on, and I think you just nailed it

I've encountered one scenario where element queries would be incredibly useful: web app designs that include sidebar navigation that toggles open and collapses. This design pattern makes responsive design a little bit more difficult. The main challenge is that the width of the main content pane changes depending on the state of the sidebar. Your media query to scale down an element or rearrange a layout, often has to default to happening at a greater window width than otherwise necessary (if the sidebar is collapsed), because of the potential for the sidebar being open. There are some gross ways to work around this with JS, but I don't think it's worth it. An element query would make it easy to watch the width of the main content pane, independent of the sidebar pane's state.

If you create an account at Stipple.com and log in, you'll see an example of what I'm talking about (disclosure: I'm an engineer at Stipple).

I wonder if a javascript/jquery helper could be used as a fill for now?

You could set up size points for an Element like this (mobile first approach) :

$(".testimonials").when-min-width(400px, "medium").when-min-width(800px, "large");

Then you're CSS could look like this :

.testimonials{ // do basic stuff, and small display stuff }

.testimonials.medium{ // do medium display stuff }

.testimonials.large{ // do large display stuff }

Hmm. Maybe I'll build it.

Media queries are still necessary to lay out the page you've described. The primary containers of your pages all need to move around based on the size of the top-level container.

If you could only rely on your parent, that would also be problematic - the size of a component would be dependent on its chain of parents. If you were reusing the same component within further containers, say 3 different pages, you might want two to look the same despite a size difference, and element queries don't help you anymore. You just need a .testimonial.compact class, have slitghtly different media targeting, and now you have two types of testimonials that you can use on further pages.

Element queries could also easily create strange loops that cause the threshold to be crossed recursively, if the parent bases its width on the child. This is the case with inline-block elements and the property-which-must-not-be-named.

This all makes more sense in the context of TJ Holowaychuck's new Component package management tool (first link in the article). Component gives a sane structure to building small, modular js+css+html+assets components. https://github.com/component/component

IE used to have dynamic CSS properties [0], which were most often used in the wild to achieve max-width in IE [1] (at huge cost — in the linked article the author warns against using the very performance-expensive technique).

But the way that technique is implemented is actually very similar to what you're describing: the CSS causes the selected element to examine some of its DOM properties and conditionally apply styles on a per-property basis.

Maybe this is another great old IE quirk that needs some W3 loving?

[0] http://msdn.microsoft.com/en-us/library/ms537634(v=vs.85).as... [1] http://www.svendtofte.com/stylesheets/reflections-on-max-wid...

While we're complaining about the faults of media queries, allow me to add my largest perturbation with them: As a user, I sometimes want the "full" site when I'm on my phone/tablet.

With media queries, it's essentially impossible to let users choose their format experience.

We has a similar issue to solve. One part of our app is comparable to the inbox of an email client (list of messages). We launched a new dashboard view, where people could add all sorts of charts and also lists of messages. We used the same code / css for that, but here as well we wanted to hide / unhide certain things in the message depending on the width of the widget. We finally added some very simple (and highly restrictive) js code to make it happen in some way. Check this gist to see what we did: https://gist.github.com/folke/5314876

undefined

From what I've read the way to approach media queries is to shrink your page width to a point where the page breaks and then add in some code to fix it.

Element queries would be nice, but aren't we essentially doing that if we take the idea of the previous approach and apply to more high level elements?

If we create media queries on a per element basis we are essentially achieving the same thing. In that sense media queries are a superset of your proposed solution. It would make for a nice short hand though.

I had that same idea more than once, to propose a local per-element media query.

In fact the concept itself of querying the whole window to understand the dimension a portion of it will occupy... well it's strange.

At the same time, have you considered the implications of such a structure? A local media query could change the queried properties. Dangerously recursive.

In fact you COULD reach what you want using seamless iframes. I tinkered my head with such an option sometimes.

Exactly! This is part of a more fundamental problem with the whole concept of responsive web design... It can't be just about media queries. I blogged about this some time ago, and plan to amend with links to this article. Well done. Here's my post -- http://barkgolgafrincham.wordpress.com/2012/10/04/responsive...

The ability to compile Java to Javascript is only one of GWT's benefits ... the ability to package the associated HTML and CSS into "modules" and later import the modules you need makes web pages the collection of components the author desires.

I can create similar self contained components in JSF and several other languages (frameworks), so I'm wondering if the problem is the author's development technique.

There are some good points made in the article. The responsive or one-for-all approach is still in its infancy. There will be issues, but I see an evolution in this that will ultimately lead to very succinct reusable widgets as described by the OP.

This is definitely one to grow on.

The web should take a cue from QML when it comes to creating self-contained and reusable components: http://qt-project.org/doc/qt-5.0/qtqml/qtqml-documents-defin...

Is there any SEO benefit of using media queries over pointing to a subdomain with a separate stylesheet. I.E. m.domain.com ?

Personally, for reviewing Google Analytics I just prefer making my web apps & sites responsive. Though responsive can take quite of bit of time.

Something i've been working on. It's pretty basic yet >.< https://github.com/gabriel-felipe/MagicHTML

I think this is currently the main issue still holding RWD back right now.

I blogged about the same issue not long ago: http://pxlz.me/44

https://github.com/wemakeweb/element-queries

Shadow DOM and web components probably give you the document root context you need for that example to work.