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.
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 agree with this. Media queries are a tool that eliminates the need to maintain separate HTML templates for mobile- or tablet-specific versions of a website. They work well at this task.
Element queries as described by the author address an entirely different set of concerns, which is that modular components of HTML might be re-used in varying situations, and depending on the implementation you might want to style them differently. Media queries are the wrong tool to solve this problem.
The problem is that when we want to use this:
.testimonial (max-width:27em) {font-size: 0.8em;}
We have to use a context-specific style definition instead:
You might still have to revisit each of these styles in a media query to apply changes depending on the global presentation. So while the proposed element query might eliminate the need to chain selectors, I do not believe that it simplifies media queries in any meaningful way.
By including those classes in the actual markup you're hard-coding semantics about the presentation of those two elements that may cease to be relevant when the screen changes width. What if when the screen gets sufficiently narrow you want the horizontal layout to actually change to vertical? The breakpoint at which that happens is more closely linked to the size of the element than the global size of the whole screen (which media queries relate to).
So the point is that with element queries you're defining modular breakpoints that directly relate to your CSS modules, not the global size of the screen, and you're not polluting/complicating markup with CSS class names that could become non-semantic in drastically differing viewport dimensions.
I think there must be some schism here between people with a design background and people with a programming background, or something. As someone who is more of a programmer, if I can think of a way to specify what I want unambiguously, and my language doesn't let me use that method to actually specify the computer's behavior, then the language is broken.
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.
A "document" is one of the many possible "ui"s for the underlying model of information that gets displayed. I must be missing some nuance in the distinction you're trying to draw between a "document" vs a "ui." Are you talking about static vs. dynamic content?
CSS was made to style and place text on a page, not position buttons or define interactions or transitions or platform delineation or any of the other crazy things a view controller does in a compiled language.
Its an add-on to a markup language also built mostly only to display text.
A more constructive angle to this debate would be to compare HTML/CSS to other declarative UI frameworks such as those in QT and iOS and discuss what features need to be added or removed to make HTML/CSS more maintainable and less painful.
We all know the history of HTML and we're aware of the path it's evolution has taken.
Are you arguing that it's inherently unfixable and needs to be scrapped? I think you'd have a tough time arguing that point so why not move the debate forward instead of playing the curmudgeon?
Even then, if you plan things correctly and involve javascript for changes on the fly, it works quite well at positioning elements on the page, show results of interaction, performing transitions, and many of the other crazy things a view controller does.
It largely refers to the complexity of the layout. HTML and CSS were made for styling pages of text with headings, images, perhaps a table here or there. But now people want to make application UIs with fluid layouts with them.
Also, transclusion never really took off, so traditional web pages are different to an app's page state, which might be initialized from computation by composed modules on the backend and a series of asynchronous updates in frontend.
CSS has the cascade and @import and background-image links for example, but historically the document was typically one text file and some pictures; an app's UI is combined from many source files and subordinate resources. CSS works pretty well for declaratively styling a monolithic document, but it is not entirely satisfactory for styling the UI of complex app such as Facebook.
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.
Currently, we generally use preprocessors such as LESS or Sass to compile from some more improved syntax into usable CSS2/CSS3 before serving (a la CoffeScript->JavaScript). A shim is generally meant to be there just in case some feature (present in some modern browsers) isn't available in the current browser; For this use case, that would be ALL browsers, and you'd just be adding page load time across the board (and further delaying when the page gets styled during rendering).
>Currently, we generally use preprocessors such as LESS or Sass to compile from some more improved syntax into usable CSS2/CSS3 before serving (a la CoffeScript->JavaScript).
Unfortunately, even for static CSS, that's not going to be practical for element queries. You could do it in theory, but in practice, you'd end up generating tons and tons of CSS for even very simple sites.
>A shim is generally meant to be there just in case some feature (present in some modern browsers) isn't available in the current browser;
In this case, showing testimonials isn't core to most pages anyway, so no big deal if they fade in a second late. Heck, the animation might bring more attention to them. It's kind of bizarre reading hundreds of words from this author about this problem when he could have solved it 3 lines of JavaScript, checking the width of the element and swapping a class value.
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.
I agree with you 100% about the need to separate styling from layout. CSS for layout just plain sucks. Layouts that should be simple turn out to require hack upon hack to achieve.
In regard to your layout in JS question. There is an excellent port of the Cassowary constraint solver in JS [1]. It allows you to specify complex relationships between containers along with weights, which allow you to specify layouts in a sane manner. Performance is very good, especially since it takes advantage of web workers where available.
What I hate most about layout in CSS is that it takes something that should be brain-dead simple and turns it into something that requires memorization of edge cases and browser hacks with some added voodoo magic. It's such a waste of brain cycles.
To top it all off constraint based solvers have been around for over 20 years... and yet in 2013 we're still dealing with this mess.
Very cool repo and articles that he links to. Lots of the layout constraints (not type-size, colors, etc.) should be solved when Flexbox support lands in the other major browsers. For example a 20% wide container, that gets no wider than 800px and no skinnier than 200px can be solved with Flexbox pretty easily.
Not having adequate Flexbox support after it being discussed for soooo long is my other big problem with CSS.
flexbox is great, but it only solves a narrow set of layout issues. There's so much more that a constraint based system brings to the table. A layout system should make it extremely simple to anchor edges between arbitrary containers regardless of their position in the DOM.
While we're at it lets scrap the DOM too. It's really painful to see how much it is being contorted to suit the application paradigm.
If you use javascript for layout, you're gonna have a bad time. But you're totally right about separating layout from structure.
GridSet (http://gridsetapp.com) does some pretty amazing things. While it doesn't require you use a CSS preprocessor, you should check out the .scss it generates for a look into how they use preprocessor functions in a way that's much more similar to programming than CSS property-value lists.
> If you use javascript for layout, you're gonna have a bad time.
I don't think this is necessarily true across the board. If you're creating just another brochure site then CSS does a good job of document layout and it's true that usign JS for layout is unnecessary and counter productive.
If, on the other hand, you're creating complex layouts that mimic desktop applications (complex components, nested panels etc), then JS for layout is the only sane option.
This is difficult to discuss in abstracts. "Javascript for layout" is much too vague, because of course everything is using a mishmash of javascript states, CSS media queries, and JSON content.
I think what you're referring to is using javascript to build flexible layouts that afford a significant matrix of collisions between elements (w/ variable dimensions) by programmatically evaluating, resizing, moving, etc. For example, desktop Chrome's tabs: shrinking them as they increase in number, adjusting their position to keep the close button under the mouse, etc.
But I'm having a hard time thinking of such beasts on the web, where such complications can't (or shouldn't) be limited by design. Share some examples?
These layouts all use a combination of CSS for layout (floats, margin, padding etc) as well as absolutely positioned elements that are controlled using some variety of layout manager. Where this becomes especially useful is for collapsible, resizable, movable panels and windows.
A testament to the way in which CSS is lacking is evidenced through the hundreds of multi-thousand word blog posts that were devoted over the years to discussing how to achieve multi-column equal height flexible layouts [1]. This is something that should be trivial, instead hundreds of man years have been wasted trying to get boxes to line up nicely.
CSS3 flexbox solves some of these issues, however there is still no way in which to arbitrarily constrain or anchor any container to any other container which ultimately limits its usefulness.
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.
You can't hide an inner element, or completely change the way it acts just by making something "fluid". Making things fluid and using that to make bulletproof modules is a good first step, but it doesn't do everything we need it to do.
You can with LESS. I use LESS on all responsive projects and have done this many times. Obviously it is not vanilla CSS you write in but it is compiled into standard CSS. I really recommend trying it out before you reinvent the wheel.
you still have to base it off either the parent (.signup-page .testimonial) or a conditional that's only used on a particular page (.testimonial.compact). The media queries are sub-optimal but it's contained within .testimonial. Here's how it can look:
.testimonial {
media screen and (max-width: 900px) {
font-size: 0.8em;
}
&.compact {
media screen and (max-width: 1200px) {
font-size: 0.8em;
}
}
}
What if this thing shows up in 18 places, some of those change sizes on mobile, some of them in turn being reused in several places and then somebody changes something that affects the size (and therefore desired styles) of some but not other of those contexts, and adds 6 more contexts in which the size matters?
I want to say "When displaying a user profile, If there's more than X units of horizontal space, use the large profile image. If there's more than Y units of vertical space show their bio, trimmed to length but avoiding widow sentences and followed by ellipsis. If there's very little room at all, just show their user name."
I know what I want and I can describe it simply and in a way that a machine could implement, but using today's tools it will take significant developer (human) effort (which typically isn't within my client's priorities and ultimately gets neglected).
By all means, I would love to have element queries. They would definitely help in many cases. You would have to limit their use to just those areas of markup where container widths are explicit.
If it shows up in 18 places I bet you there will be two different contexts with the same container size, but different looks, and element queries won't help you at this point. You'll still need to tailor your CSS classes for different contexts.
Obviously if I want styles to vary by context of their container, I'll need to create those rules. The desire for and utility of being able to do that is not at all in question. I don't see how having such rules is in any way mutually exclusive with element queries.
lol, I'm losing all my valuable karma points!! I'm melting. No, really; I am sorry for being rude. I was being short sighted. I understand the issues encountered in responsive layout are new and evolving. I am sure you will create a great tool that fits your vision. I happen to think that LESS combined with media queries can accomplish any responsive layout I have yet to fathom. I hope that I can post more meaningful comments in the future.
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 didn't see it that way. Media queries do what their intended quite well, for the most part. What is described in the article should not be addressed by media queries at all. That's why I thought the idea was being described as element queries, which makes more sense in that context then calling them media queries.
Don't think of it as an improvement or replacement, but as an addition.
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).
Of course you could, but in addition to mobile devices, the point of media queries is to handle anything that might make a standard HTTP request. This includes televisions, older phones, gaming consoles, you name it. Javascript is relatively unreliable on many of those devices; what's worse, you don't want to force a jquery call just to do something that's actively supported by CSS3.
All good points. But I did think if them before posting.
"Javascript is relatively unreliable on many of those devices"
AFAIK it's reasonable to argue that just as Javscript can be unreliable, even non-existent, on many devices, so can CSS media queries. I think it's fair to say that media queries are still a "modern" browser feature. http://caniuse.com/css-mediaqueries
"what's worse, you don't want to force a jquery call just to do..."
Agreed - jquery is too large just for this. That's why I said "javascript/jquery". The jquery like syntax used was for simplicity. But in truth any simple selector engine would do the job. Sizzle for example, or even a home-grown one.
"...something that's actively supported by CSS3"
But that's the point OP was making isn't it? AFAIK, CSS3 @media queries do not support element level querying.
Plus if the desired result is supported in CSS3 then you can use javascript to just trigger the change via CSS instead of performing the task through the script.
An obvious example of this is transitions. If you have CSS3 transitions you can trigger them with a class name change instead of using jquery's animation code. When you can do that you don't need jquery or other library at all. Unless you have simply awful HTML that requires an advanced selector engine, such as Sizzle as you state.
But as you point out, if the devices listed have unreliable support of javascript then chances are it has unreliable support of CSS3.
I don't understand the argument against building a shim as a proof of concept though. What's wrong with building the example to see if it becomes popular in traditional uses of CSS before pushing it as a standard? Don't bother since it might not work on TVs because of lack of proper javascript support?
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?
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.
I only ever want a full site when the mobile layout is lacking something I know should be there. Which is then a fault of the mobile layout, not the method it's delivered.
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
The problem is that you're triggering the media query off the window's width still, and not the parent element's width. So it runs into the same problem mentioned in the article.
Right, but the width of the parent element in general depends on the width of your component, and then things are just bad.
The thing about the viewport width is that it's actually fixed no matter what things inside the viewport are doing, which means you _can_ base the behavior of things inside it on the width of the viewport.
The only real alternative is to have invariants where your component's width/height is determined and it's somehow enforced that no matter how you lay out stuff inside it won't affect those numbers. Basically think the entirety of your component inside an iframe, but without the separate script global and baggage.
Sorry, I actually meant just "element's width" not "parent". But you're right it definitely gets complicated, and you know way better than I do about which pieces are impossible and which aren't :)
The viewport query is a lot easier from an implementors point of view for sure, but it's also a lot less useful from a developer's point of view.
Would it be possible to have a way of only basing the element-specific query off of the state of the element before element-query-level styles had been applied?
For example, take an element that who's height is less than 100px. And say it has a query for `height > 80px` that hid a child element, which then kicked the element's height down to 75px. Technically the query would be undone, but maybe since it is a query-specific change, it doesn't factor in.
And it gets even more complicated when considering well what about a child's or parent's queries on top of that I'm sure.
All I know is while I'm writing these styles, I have very defined things that I want to do, that can be expressed in words perfectly clearly, and if I were able to express them in code it would completely solve tons of headaches I have with managing CSS. Ideally we could figure out a syntax and implementation that can translate those kinds of thoughts into code that works.
Ian, the problem is that CSS is a constraint description language, not an imperative language. So there is no "before" or "after"; there's just a state...
On the one hand this means that as things change it updates dynamically and all.
On the other it means that you can't just base queries on some "before" state. :(
I think we all agree that there are use cases that need solving here, for sure. We just need to figure out how to do it... Ideally while not precluding parallelized evaluation of CSS selector matching, style computation, and layout, which doesn't make things any easier.
In your example you're referring to the max-width of the viewport. In Ian's example, he's referring to the max-width of the `.testimonial` element itself.
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.
GWT is definitely not going to help the problem the author is talking about. GWT's "packaged" components still end up as the same markup and CSS. In most backend frameworks I'm talking about the Helpers, in GWT this would be some "View", or whatever isn't the presenter.
You would still need to use different CSS in the two cases mentioned, so it would be two different packaged components in GWT, two different Views. Maybe interiting from one another, but certainly far FAR more lines of code than a conditional / "modifier" CSS class. .testimonial.compact vs just a normal .testimonial, for instance.
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.
There's no direct SEO benefit per se, just the mitigation of duplicate content that can be introduced when an m.dot sub-domain (for the same content) is incorrectly implemented (i.e. not using rel=canonical/rel=alternate and other indexation directives). There's also the 'crawl once, show everywhere' benefit if you have a single front-end representation of the code. Introducing an m.dot version of your site requires Google et.al. to consider whether to use their separate mobile crawlers to crawl the content that has been created for the mobile experience.
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.