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.
With the web finally hitting magazine-quality typography, there's definitely a need for a proper layout engine that's flexible and can achieve exactly what graphic designers want.
CSS regions might not be it (or it might), but Google needs to offer something to replace it, because that's the closest thing the web had to offer magazine-quality layout. The web needs the equivalent to inDesign.
If they do not, everyone will just layout for iPad (Safari), and that will be considered standard, while other other layout engines like Chrome remain unsupported.
Apple is very good at pushing typography, and had Google offered something that can replace CSS Regions, Apple would have considered it.
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.
He who thinks "I thought standards were there to implement not argue with" obviously hasn't been around for very long...
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
What a surprise two of the three editors of this standard are Adobe employees.
But I can easily imagine that regions are crap. Why don't they implement a purely functional and modern layout&typesetting language instead?
HTML+CSS attempts to have a content-with-markup source file, and a standard format non-programming language for styling, with no control over how things are layed out. This is great for simpler styling duties, but eventually becomes unwieldy. What is needed is to analyse and factorise how a web browser today actually does layout internally, and create a programming language that can access that directly, drawing on specifications in a CSS-like stylesheet for its source information. That would result in the CSS not, by itself, determining the style, but being subject to the whims of the engine that maps CSS-styles to actual screen representations. But hey, isn't that what we've already got with multiple browsers each implementing their own layout, and the programmable mapping layers hard-coded into the browsers (especially with IE and standards vs. quirks mode)?
I would like to see the Cairo model of drawing standardised, and the layout facilities of an HTML browser and other things added at an API level with the actual browser implemented as a light wrapper on top of that. That would also allow broswer-like apps with different document structures to be developed much more easily. I can dream, I guess.
John_Chalisque
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
Seems HTML and CSS is creaking from the load. I always though the whole point of CSS what to influence how HTML (and/or XML) content was be presented.
Seems like proper text flowing would be a big boon to that. Not that CSS Regions is the best solution, but that why you have a process to discuss and work towards a workable standard. It's clear that Google is more interested in web applications than layout, and removing this code goes along with that.
I don't subscribe to this point of view. I see HTML/CSS as a poor foundation for UI applications. I'd much rather see a new model for application markup and have HTML and CSS focus on static content layout that can be embedded in the application or standalone as a plain web page. But the HTML5/Web2.0 train just keeps rolling along.
I can't remember the last time an article mentioned four of the five major browsers while including Opera and not Firefox. Times, they are a-changin'
. 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.
Why not fork Chromium then?
If Pandora's box is destined to be opened, *I* want to be the one to open it.
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 first misread this as "Google plans to remove Blink from CSS."
I thought, "Isn't that a good thing? Wait, is blink even still around? Wait a minute..."
Then I had to reread the headline and TFS and my fun was over.
15 years ago my biggest problem when dealing with HTML was when the clients were print designers.
I guess it hasn't changed. We aren't going to have display postscript on the small mobile devices that are so prevalent now.
Sorry, the web and print are two different media. It isn't going to look the same.
If you need really fine control use PDF.
Stop trying to cram a month's work of clothing into an overnight bag.
&tc.
My first thought is that Adobe wants CSS Regions to be able to do print-media-style page layout, missing the point that the Web isn't a printed magazine. You don't know how big your target display window is, you don't even know whether it's landscape or portrait. You don't know if the viewer can even see images at all, nor if they can see colors correctly (look up the percentages of the population with various types of color-blindness). So why are you trying to be so precise about layout with so many unknowns in the mix?
I truly hate Web sites that force a 3-column layout with narrow columns that don't flow to the width of my window, or that flow the advertising material and leave the content narrow and on a dozen different pages so I'm forever clicking "Next" to keep reading. I have a large monitor and a wide window for a reason. My browser has a scroll-bar for a reason. Constraining me to a magazine's column widths and pagination is completely missing the point. I'm there for the content, and when layout becomes so complex and cumbersome that it's interfering with the content you're Doing It Wrong.
Who knew?!
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.
If only CSS was Turing complete, we wouldn't need these hairy specifications. CSS is slowly becoming a behemoth.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
I'm not a web designer, so I can't speak to the technical pros and cons of CSS regions -- but if this results in fewer web sites flowing an articles text over multiple columns magazine/newspaper-style, then I'm all for it. I hate it when websites do that.
This is a motherfucking website.
And it's fucking perfect.
I'm just amazed that it takes 10k lines of code to support this feature.
Before making ANY changes, we need to stabilize and make even the most basic features consistent.
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.
That sounds a bit like inline-block.
I believe the original poster is incorrect
"proposed removing Regions support to save 10,000 lines of code in 350,000 in the name of efficiency."
Eric wrote "I was very surprised to find that patch was over 10,000 lines!" If I am not mistake 10,000 is referring to the patch he wrote to remove most of Region code and not the full region code If the patch is 10,000, can you imagine the full scope of Region?
Mozilla goes for CSS Fragmentation. *snort* Sorry.
It was a mistake the created tables for the specific purpose of tabular data. They should have called them something more generic like: tiles or grids. And saved us a lot of grief with CSS.
This whole CSS/JavaScript/HTML is a complete Ivory Tower fiasco.
Its like the Top Gear guys trying to build a space shuttle.
And the mess only gets worse with each revision.
I believe in supporting standards and not rejecting them for political or ideological reasons, so i am in favor of CSS Regions being included. The fact is i dont see how the proposal seriously jeopardize semantics/presentation seperation. How the region chain is established is usually done entirely at the CSS level. it could it appears be altered by CSS code. Most pages nowadays use DIV with attached CSS for presentation these days, anyway. This actually does provide for a seperation of sorts, one can easily access the properties of DIV tags in the page from other code. its true, that p tags are not being used much. The fact is this: the web for 99% of users and developers is used for WYSIWG formatting where the user sees what the developer defines. If Web standards do not provide this, i GAURANTEE you that HTML will end up being used for about 1% of internet web content.
I have a strong dislike of PDF and ending up with a web filled with PDF and Flash would lead to a far more opaque environment in being able to look at the code and externally access page elements.
The people who oppose CSS Regions have a mindset that would turn HTML into a fringe standard that few use and would lead to a web that is almost entirely implemented with Flash. Um, I think I would much rather have a relatively open and accessible HTML environment being used for content, even if it is not being used exactly how the purists think it should be, than flash.
According to HÃ¥kon Wium Lie, and having read his rational I can't say I disagree.
This sentiment is very wrong. It's easy to generate a standard that is no good, and the W3C is often not good at keeping out bogus standards. If we followed this sentiment browsers would burn resources implementing all kinds of useless things like XHTML2, XSL-FO, etc etc etc. "Browsers implement it" is an important and completely reasonable test of validity for any spec, alongside "Web developers use it".
Actually, the blink tag is dying, you're right. However, it's possible with CSS keyframes animations to do a lot more (including 3D pulsing, and spinning if you really want), which is far more annoying than blink ever was.
In some ways, I'm kind of sad that flash is also going out - as it used to be so easy to block everything annoying on sites by disabling the blink tags, and having click-to-load plugins.
Now, with everything being all JS/CSS based, and half the freaking internet break when you turn off JS (seriously? why do blogs need to load in the main textual content dynamically?!?!?) it's very hard to get a minimal experience that doesn't suck.
I see a lot of comments about the merits or drawbacks of CSS regions. But in the end, isn't the real issue to be discussed here is the fork of Blink from Webkit ? With the CSS regions and MathML examples, we can see the clear benefit of using a common, open source layout engine. Even if Google was not interested in these features (or rather did not want to commit the resources needed to maintain them), they would have got them "for free" through the work of other contributors to Webkit. I wonder if the gains Google got from forking Blink are really worth these kinds of losses.
you would think that vector graphics would have seemed like an obvious standard to implement in any first iteration of "the web"... ahead of bitmap images for sure... you would think that computer science type people would be able to think enough ahead to see where a tag was a bad dumb idea, versus a general media inclusion tag. you would think that some means of controlling the layout and flow of the text should be implemented straight away in the first version of any web standards. you would think that the same markup describing the content could have such a system.
but then you would be wrong, because the entire web is just a crappy hack, feeding countless zillions of jobbed workers because "sadly, you need to include jquery and 10 other javascripts, use some mangle-mathed grid layout css, plus all the 10 million other css files you had to include to stylize your social media icons, and then you need to make 10 version of your site and have more javascript for checking which device and browser they are on..
what a load of crap.
the saddest thing i can think of is the countless human-hours invested into developing software that goes around bad standards made by short-sighted people. what a waste of life force. one is better off simply programming an arduino and getting on with it...
Interesting: in French, his name sounds like "asshole" (connard)
Just saying that it isn't as 'take your ball and go home' as the writeup sounded.
Of course, just because something is 'standard' doesn't mean it's useful. MS historically was subject to ridicule for discarding a standard and then going on their own and implementing the same functionality in an incompatible way. Here, Google's saying that they don't want to implement any alternative scheme to the same end, just not implement the capability at all. The open source world rarely fully implements any standard (for good reason, many parts of standards are impractical, unused, or in some cases some loophole demanded by a proprietary vendor to be able to declare support for the 'standard' without having to make a lot of effort on their part.
XML is like violence. If it doesn't solve the problem, use more.
Yes, bellyaching about CSS region support was the wrong track. This certainly points to a larger problem. Building an 'application platform' is not what I wanted in a browser.
XML is like violence. If it doesn't solve the problem, use more.