Follow Slashdot stories on Twitter


Forgot your password?

Google Planning To Remove CSS Regions From Blink 249

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.
This discussion has been archived. No new comments can be posted.

Google Planning To Remove CSS Regions From Blink

Comments Filter:
  • by Arker ( 91948 ) on Wednesday January 29, 2014 @04:36PM (#46103403) Homepage

    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.

  • by icebike ( 68054 ) on Wednesday January 29, 2014 @04:42PM (#46103481)

    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.

  • by msobkow ( 48369 ) on Wednesday January 29, 2014 @04:46PM (#46103523) Homepage Journal


    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?

  • Re:Ugh (Score:5, Insightful)

    by Anubis IV ( 1279820 ) on Wednesday January 29, 2014 @04:51PM (#46103563)

    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.

  • 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.

  • by ledow ( 319597 ) on Wednesday January 29, 2014 @05:07PM (#46103693) Homepage

    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.

  • by Anonymous Coward on Wednesday January 29, 2014 @05:12PM (#46103739)

    The problem with CSS is that it's an ungodly mess, and the promise of separating content from presentation was never there to begin with. div style="clear:both", anyone? Or just you try to make 3 columns of the same height using pure css-ness instead of an evil table. Fact is content is as presentation specific as it ever was. But hey, look CSS dropdown menus!

    What was needed was a language to transform content-html into presentation-html, but the guys who were _supposed_ to do that got all worked up about writing a generic tree transformation language, Turing complete! functional! in XML!, that they completely forgot what it was actually supposed to be used _for_. With the result that it's not actually used for anything. :(

  • Editorial bias... (Score:5, Insightful)

    by Junta ( 36770 ) on Wednesday January 29, 2014 @05:13PM (#46103759)

    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'.

  • by the eric conspiracy ( 20178 ) on Wednesday January 29, 2014 @05:16PM (#46103813)

    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.


  • by Bacon Bits ( 926911 ) on Wednesday January 29, 2014 @05:23PM (#46103905)

    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.

  • by Above ( 100351 ) on Wednesday January 29, 2014 @05:25PM (#46103927)

    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.

  • by Arker ( 91948 ) on Wednesday January 29, 2014 @05:36PM (#46104065) Homepage

    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.

  • by Anonymous Coward on Wednesday January 29, 2014 @05:55PM (#46104261)

    Not many people can use?

    Everybody using the current versions of Chrome and Opera, any WebKit based browser (virtually every handheld device), and IE have a browser that supports regions. Even older versions of Opera supports regions. Depending on who you get your statistics from, between 70-80% of all current web browsers support regions.

    That leaves Firefox, and a few niche browsers that don't support regions; currently less than 30% of the total market.

    So Google dropping regions represents a shift of 40-ish percent shift of the market. That's huge.

A committee is a group that keeps the minutes and loses hours. -- Milton Berle