Slashdot Mirror
Google Planning To Remove CSS Regions From Blink
mikejuk writes "Google and Opera split from WebKit to create Blink, their own HTML rendering engine, and everyone was worried about the effect on standards. Now we have the first big example of a split in the form of CSS Regions support. Essentially Regions are used to provide the web equivalent of text flow, a concept very familiar to anyone who has used a desktop publishing program. The basic idea is that you define containers for a text stream which is then flowed from one container to another to provide a complex multicolumn layout. The W3C standard for Regions has mostly been created by Adobe — a long time DTP company. Now the Blink team has proposed removing Regions support to save 10,000 lines of code in 350,000 in the name of efficiency. If Google does remove the Regions code, which looks highly likely, this would leave Safari and IE 10/11 as the only two major browsers to support Regions. Both Apple and Microsoft have an interest in ensuring that their hardware can be used to create high quality magazine style layouts — Google and Opera aren't so concerned. I thought standards were there to implement not argue with."
Although mikejuk thinks this is a bad thing, a lot of people think CSS Regions are awful. Mozilla has never intended to implement them, instead offering the CSS Fragmentation proposal as an alternative. One major flaw of CSS Regions is its reliance upon markup that is used solely for layout, violating the separation of content and style that CSS is intended to enforce.
Regions are a horrible, messy, awkward layout model that fundamentally contradicts many of the benefits of HTML layout - particularly for different devices and screen sizes.
Yes, we'd all be much better off if the web server just provided content and the browser figured out how to display it, but, sadly, hat boat sailed twenty years ago, when graphic designers jumped on the web bandwagon. 'But my page must be precisely 1920 pixels wide with the text in 36-point Comic Sans, or I'll just die!'.
Wrong.
My browser is supposed to control the layout, not the web site.
Do you have any idea how many websites render like absolute shit because I use a custom display font instead of letting them use tiny unreadable headache-inducing fonts?
I do not fail; I succeed at finding out what does not work.
I'm not a web designer, but I don't see what the problem is in the situation you've posed. HTML is supposed to deliver the semantic content to the browser, while CSS is supposed to deliver the display instructions to the browser, exactly in accordance with what you said. Why should it matter if it's a designer making the CSS or if they do have exacting standards for how it should look? They should be able to do so!
The issue here is that regions required mixing some of the display instructions into the semantic markup. I'm all for supporting something that accomplishes what regions were trying to do, but mixing semantics and appearance is a big no-no. Display stuff stays with display stuff, and content stays with content. If you're a designer wanting to work around that limitation, there are Javascript libraries out there that will do stuff like this for you already. No need to screw up a language just to do it.
Incorrect.
The art director controls your viewing experience, not you.
That is because you do not know what you like, and the art director knows more about you than you do. They are professionals at knowing what you like.
Really, it goes back to the old saying by Henry Ford "If I had asked people what they wanted, they would have said faster horses."
My recommendation to you is to stop going to websites without a professional art director. You are hurting your eyes if you do that, and any site that doesn't treat art direction seriously doesn't have useful content anyways, since layout itself is content.
Again, you do not know yourself more than what a professional would know about you. This is something that can't be stated clearly enough.