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. If you think you need them, just make a PDF already - Adobe already has you covered.
It's called postscript.
If that's what you want to do just do it. Throw up a .pdf instead of a webpage.
Mangling HTML to make it like .pdf instead is the worst possibility. Yet historically that is what they keep doing. I wont hold my breath waiting for that to change. So expect to see 'regions' garbage stay.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Google is aiming more and more for the core, at the edge's expense.
They provide middling accessibility support, because it isn't something most people need. They dropped MathML support, because it isn't something that most people need. Now, they're dropping CSS Regions, because it isn't something that most people need.
It increasingly appears that you can have your Google product in any color, so long as it's red, green, blue, and yellow. One size fits most, and tough for you if it doesn't.
Obliteracy: Words with explosions
need for a proper layout engine that's flexible and can achieve exactly what graphic designers want. ...
the closest thing the web had to offer magazine-quality layout
Magazine quality layout is exactly why I haven't subscribed to any magazine in years, and prefer to read it on the web, instead of turning to page 96, then page 102, ...
Graphic designers my ass! Clutter-Mongers is a better term.
Sig Battery depleted. Reverting to safe mode.
Postscript is for fixed devices.
The issue that programmatic auto-flow systems like CSS regions try to solve is that the layout/text-flow changes with viewport dimension changes.
Honestly at this point, HTML should be obsoleted and everyone use an XML standard like RSS, or something semantic, and lay that out directly with CSS, since the entire web is converging on an blog-post/article-like data model.
Wordpress itself should be the equivalent data-model standard. Most CMSs revolve around that core data structure anyways. No need to build HTML from Wordpress, then lay that out with CSS. Might as well lay out the Wordpress-like data structure directly, without an intermediate HTML step.
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.
What a surprise two of the three editors of this standard are Adobe employees.
Trying to cover all cases with one universal standard is rarely the best solution. Covering the core with a small number of good standards, and having a few others that work differently to handle the rest is often the best way. This is simply because the 'solution space' covered by a single universal standard has many more regions of possibility that will never be touched than a few more focussed standards. Whilst it's massively oversimplifying, imagine the problem of covering a bounded region of a plane, that has an interesting shape, with squares. Hardcore minimalists will point out that one big square will do. That is what the universal standard approach tries to do. The trouble is that a few interesting cases can push the required size of the square to large proportions. If one wants to optimise for area, many small squares are better, but at the expense of having to manage many squares. A balance between these two, with a very small number of large squares and a slightly larger number of smaller squares, tends to be the best solution. Things work similarly with languages, both human and computer ones.
John_Chalisque
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.
That's because Opera isn't Opera any more.
As the article hints at, they threw away their Presto rendering engine and lumped in with a Chrome-a-like base.
In doing so, they basically started the browser from scratch and in many of the versions released for it (including desktop versions) something like 75% of the features I use Opera for simply aren't there. They haven't got around to recreating them, or have publicly stated they have no intention of ever doing so. They have been several "stable" releases since then, and still no sign of a lot of basic functionality.
Ever since then, it's Chrome-with-knobs-on as far as I'm concerned. Unfortunately, the knobs are the developers, not the features.
Stick with 12.14 until it no longer renders your sites of choice, if you're an Opera fan at all.
The writeup was intended to disparage Google's decision as going off the rails and abandoning an otherwise widely supported standard feature. That image would have been significantly impaired if it made clear that firefox never supported it in the first place, meaning only Apple and Microsoft really bothered. That fact changes things from 'Google is breaking the web by ignoring widely adopted standards' to 'Google abandons obscure function that not many people can use already'.
XML is like violence. If it doesn't solve the problem, use more.
I hate to say it, but it's not a bug. It's a feature.
Simple markup with limited layout control is the design intent of HTML. It was expressly designed to present documents whose look and layout were to be determined by the reader, not the author. That CSS provides a mechanism to do layout is beside the point because HTML still demands that the browser, not the server determines what a page looks like. This is all by design, because the author can't know what the reader is using to read the document. HTML+CSS is not intended to replace desktop publishing any more than MS Word is. If you want results akin to desktop publishing, you need to use desktop publishing software.
If you want to make a TeX-based browsing engine, please, go right ahead. I'd love to see a TeX engine in browsers just for all the pedantic web designers out there. Trying to make HTML+CSS behave like desktop publishing software is a fool's errand.
The road to tyranny has always been paved with claims of necessity.
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.
I love the idea that content is marked up based on it's intrinsic content (this is a heading, this is a paragraph, this is a footer) and that is independent from the styling (make this text blue and center it). However if anyone thinks HTML+CSS is a good example of how to do this, they are delusional. View source on any web site and you'll find tens to hundreds of "divs", that is markup, used solely for layout purposes. Even worse, what should be pure markup is often abused for presentational purposes. h1/h2/h3/h4/h5/h6 are rarely used in "outline" form as they are intended, but rather h1's are styled one way, and h2's are styled another, and any particular section of content may start with one or the other based on visual style.
Regions are clearly no worse, or better, in this respect.
I do think "the web" needs something like Regions to go along with load-on-demand content baked into the service. Many web sites simulate that today with Javascript. Given that device sizes are actually getting more spread out, from watches to 80" TV displays, the layouts will have to be different. Being able to design a small/medium/large layout, including some flow of where the content should go, and then providing a list of content (here's 20 articles, load however many fit on the screen) would be awesome. Phones could load one at a time. A 30" monitor user would have all 20. It would all flow, without excessive markup.
In short, I see a lot of the pot calling the kettle black here, and people arguing rather than innovating.
The issue is that you can have layout-level control, or you can have device independence.
PDF gives you one, HTML used properly gives the second, choose one.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
The W3C standard for Regions has mostly been created by Adobe ... I thought standards were there to implement not argue with.
CSS Regions is not a W3C standard. It is a Working Draft. The entire point of publishing a working draft is to solicit feedback from the community. There have been several working drafts that were never promoted to final recommendations, because there was no community consensus that they were a good idea. What Google and Mozilla are doing is a perfectly constructive part of the standardization process.
This gets into the sticky conflict of art versus utility. Most geeks consider the utility standpoint first: we want to absorb info as quickly as possible. However to some designers and/or readers, a web page is as much art as utility: the designer is trying to inject a feeling using look, style, and feel.
Are you going to tell an oil painter to "increase the contrast" so you can see his/her painting better? "Hey Monet, your dither size is too large, I can't make out the detail!"
I'm not condoning any one viewpoint, only pointing out there may be conflicting goals and expectations involved here.
Table-ized A.I.
The problem is, a flexible layout engine is really a declarative programming language and most graphic designers are horrible at programming, thus the layouts they design are extremely buggy. Yet we can't just let programmers design layouts because they tend to be horrible at graphic design. What's needed is a high-level layout language that can be given a template, produces a consistent look and feel on all devices yet optimizes the details for them, and most importantly any bugs (such as elements overlaying each other) will manifest themselves right there on the designer's display.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.