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.
The web needs a good layout engine (Score:2, Interesting)
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 l
Re:The web needs a good layout engine (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
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 struc
Re: (Score:3)
css regions aren't build to auto scale based on the device size. You'll have to manage that manually with javascript :(
Re:The web needs a good layout engine (Score:5, Insightful)
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.
Re: (Score:2)
The issue is that you can have layout-level control, or you can have device independence.
Or, to a workable approximation, you can have both. There are lots of different devices, but ultimately there are only a manageable number of general types among them: smartphone-ish, tablet-ish, laptop-ish, large laptop/desktop-ish, and maybe a few speciality things. If you have a web site aimed at the general public that provides for 2-3 variations in layout that will fit comfortably on the small/medium/large size screens and you allow for both keyboard/mouse and touch interactions, you can easily retain
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Except your nice little theory is not going to work.
Plenty of very popular, very professionally designed and maintained sites use these kinds of techniques already. See all the discussion in recent years about responsive design [alistapart.com] for numerous examples of one way you can do it. There are others, too.
Just because it isn't cost-effective for some sites, or some web developers don't know how to achieve these results, that doesn't mean the principle is broken. It just means some developers are better than others, and isn't that the case in any technical field?
Re: (Score:2)
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.
One of the main goals of HTML is to be that semantic format you wish for. It has taken years (far too many) for it to get to that point, but in general, it works. You mark up your content semantically with HTML and then leave all presentation to be taken care of with CSS. At least, that's what web developers should be doing nowadays. I'm not saying HTML is perfect, far from it in fact, but in conjunction with CSS it does already provide a means to separate content from presentation.
Re: (Score:3)
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.
And how does that model apply to amazon.com? Or mac.com? Or wikis? Or google?
Re: (Score:2)
Re: (Score:2)
Mangling HTML to make it like .pdf instead is the worst possibility. Yet historically that is what they keep doing.
Eventually HTML will become like Postscript, but in an ad-hoc and messy way, instead of a consistent architectural design that guarantees cleanness (which would have been done if they'd just used postscript in the first place).
Re: (Score:2)
Re: (Score:2)
It seems to me that a pragmatic willingness to force HTML to do what it's not particularly good at has been the key to its long term success -- not architectural purity.
I can see how regions doesn't fit in with the overarching theme of content/formatting separation of CSS3, but while it's unquestionably ugly philosophically, it's unclear to me how much of a *practical* problem that actually is. If you don't need CSS regions, then you can simply not use it and be every bit as pure as if the feature never ex
Re: (Score:2)
Using that argument, you could rip out CSS support altogether and save even more kLoCs. Every feature presents a practical problem to the maintainer; the question is the effect a feature has on the users.
Like I said, if practically nobody needs the feature, that's a strong argument for the old heave-ho. But the beef with regions seems to be that the feature is ugly and awkward, which it undoubtedly is.
Re:The web needs a good layout engine (Score:5, Insightful)
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.
Re: (Score:2)
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, ...
Yeah, that's part of the nature of a physical medium. This has nothing to do with that - hyperlinks, and an infinite amount of scrollable space means the only point in doing that sort of thing is for milking ad impressions, which has nothing to do with graphic design.
As screens get wider, the ability to automatically flow text across multiple containers (e.g. columns) becomes more important. Scanning a line across one of those huge 27" apple monster screens will be unpleasant. Allowing one block of content
Re: (Score:2)
I agree that the rush for width in browser windows drives me nuts, especially when the web designer forces it on you.
But I'm not sure understand why this requires Regions? Multi-column has been done for quite a while.
Mozilla has some examples here: https://developer.mozilla.org/... [mozilla.org]
and CSS3 have examples here http://www.w3schools.com/css/c... [w3schools.com]
Are these the same thing as regions? Or are they using other concepts all together?
Re: (Score:2)
I believe Regions offers a superset of the functionality CSS columns does, but that wasn't really my point. The GP was saying "the web doesn't need magazine-like layouts". I was saying, yes, it does. The precise mechanism we use to get them (regions, fragments, columns, whatever) can be debated, but the need for those sort of layouts is pretty well established.
Re: (Score:2)
Whoops, sorry, didn't realise GP was you. Should checked usernames once in a while.
Re:The web needs a good layout engine (Score:5, Insightful)
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?
Re:The web needs a good layout engine (Score:5, Funny)
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.
Re: (Score:2)
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.
Like /.? :p
Re: (Score:2)
This troll is genius.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yeah, totally! Presentation and artistic design can never be content in themselves! Da Vinci should have just painted The Last Supper attendees in alphabetical order and left it to the viewer to do the rest.
Re: (Score:2)
Why does it have to be a "technical article"?
Technical articles are for journals. Glossy magazines with artistic layout are a completely different animal - their *point* is style as much as substance, for whatever that is worth.
And while I agree it's possible (and relatively common) to hurt usability with too much "fancy layout", it't still just plain incorrect to categorically state that "layout is not content, period." Period.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re:The web needs a good layout engine (Score:5, Interesting)
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.
Re: (Score:2)
Alas very few of the people who host websites have any.
The problem with a decade ago was tag soup and very questionable semantic integrity.
Now the problem is CSS selector soup instead and html that contains nothing but <div class="whatever"> which contains even less semantic worth than what it replaced.
My mantra is:
If your webpage looks shit in lynx, links, and w3m, then you've got a shit webpage.
Disclaimer: I've got a shit webpage that looks shit in every browser, but that's because I don't giv
Re: (Score:2)
Is that display: inline-block ? (Score:2)
That sounds a bit like inline-block.
Re:The web needs a good layout engine (Score:4)
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.
Re: (Score:2)
Re: (Score:3)
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.
That's what XSL-FO [wikipedia.org] was created for. Browser vendors should just add rendering support for that rather than tack some poorly thought out hack onto the CSS/HTML stack.
Re: (Score:2)
Why? If I want magazine style layout, I'll open a fucking magazine. When I go to a website, I want to see text and as few images as possbile, period.
And when I want to watch a movie, I'll go to the theater! If I'm viewing it on my tablet I'd prefer it delivered as a screenplay and unmixed mp3s for the soundtrack.
Re: (Score:2)
They don't want you to look at their website with your fonts/layout, since you suck at design.
Yes, unlike the 'designer' who 'designed' a web page that assumes you're on a desktop PC with Flash, not a 7" tablet without.
But I guess it guarantees a job for life as you have to keep producing yet more different versions of the same page for every new device.
Ugh (Score:5, Informative)
Re:Ugh (Score:5, Funny)
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!'.
Re:Ugh (Score:5, Insightful)
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.
Re: (Score:2)
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.
Hint: CSS arrived in the graphic designer era, and is precisely the problem.
Instead of the browser determining how to display the content, you are telling the browser how to display it, and if you don't happen to have produced a .css file which works on a WhizzPhone 2000, it looks like crap.
Re: (Score:3)
And you're suggesting the browser could do the job better without having any indication at all of how things should be presented?
Most browsers still feature the ability to turn off CSS (though it may be tucked away somewhere). Feel free to do so. As someone who has in the past participated in CSS Naked Day, I can attest to the fact that most sites are simply not navigable or easily readable when CSS is disabled and the browser is left to its own devices. I went to great lengths to ensure that mine were, as
Re: (Score:3)
I already addressed that. My general sentiment is, "yes, and?"
You seem to be advocating for developers to do a better job of designing for when CSS is disabled, and that's something I can get behind as well, since I do agree that many rely on it as a crutch. But you're talking about bad developers being bad developers. Even if we lived in a world where CSS had been permanently disabled on all machines, they'd still be making crappy sites that are hard to navigate. Maybe a bit better than they are now, but b
Re: (Score:2)
Re: (Score:2)
Indeed, the reason Adobe wants it is so that HTML/CSS can be used in its DTP software for print media. It would allow designers to use the same software for print and web, and as you point out demand precise rendering from the browser without having to resort to large images or PDF.
Re: (Score:3, Interesting)
Any designer who tried to argue with me that their page *needed* to be 1920 pixels wide would get a long-winded diatribe about mobile devices and responsive design. It's fine if your page stops growing at 1920 pixels, but you can't expect a tablet or mobile user to fit in 1920 pixels. If your solution is "let them pinch and zoom" then you're going to lose mobile users who are a fast growing segment. Instead, your site should use CSS Media Queries to reconfigure the page depending on the size of the use
Re: (Score:3)
It's because of graphic design that people use the web.
The layout is half the content.
That'll be why most web pages I visit are unusable on my 7" tablet unless I zoom in on the specific part I need to read or interact with.
Re: (Score:2)
Re: (Score:3)
Did you pour the bong water over your cereal this morning?
Or did you really intend to imply that sites with layout never scroll that and no-one's ever had to deal with scrolling before?
Re: (Score:2)
Re: (Score:2)
Re:Ugh (Score:5, Informative)
No graphic designer, EVER has said they wanted to use Comic Sans.
I can think of one.
http://en.wikipedia.org/wiki/V... [wikipedia.org]
Adobe's Red Hand (Score:4, Informative)
What a surprise two of the three editors of this standard are Adobe employees.
Re: (Score:2)
PDF's already embed images, text, layout, colors... you name it.
I don't think that's a reason to publish a pdf over expressing that content in html. Violation of convention or purpose or standards... any of those are good arguments, just not throwing in a reason of X already supports this, so use X.
Re: (Score:2)
They're making HTML a polyglot.
http://en.wikipedia.org/wiki/Polyglot_%28computing%29
It's something which appears to have some kind of structure one way (so that search engines can scan it), yet it also has a different structure for parsing a different way (for your browser to render it).
Worst of all, it's almost a 3-language polyglot, as the version visible to the browser then
Re: (Score:2)
Any pretence of any kind of portability in the modern web should be ditched. We really have done nothing but go backwards. In several different incompatible ways...
Re: (Score:2)
Well it's designed by Adobe? Then, if you say it's bloated I take your word for it.
But what if this is only a precedent?
"First they came for CSS Regions, and I didn't speak up because they were a mess..."
Edge Cases (Score:5, Informative)
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.
Re: (Score:2)
I'd say it is something they are dropping because most people HATE it rather than a question of need.
The only reason to use column layout that would need regions is when the media is too wide to flow between lines. That width is roughly a letter/a4 sheet in landscape. It completely breaks usability on the web.
Re: (Score:2)
Well isn't it theirs to do with as they please?
Of course it is, and I did not state otherwise.
My point is that Google is actively pursuing a core user strategy, and there are clear winners and clear losers as a result. I have my own personal biases on this topic, and I'll argue that leaving edge cases behind in an effort to solidify the core is not the best path to take.
My being critical of their decision, however, does not indicate that I think they shouldn't be allowed to make it.
Re: (Score:2)
Sure it is, but that doesn't mean we shouldn't tell people who might choose whether to use Chrome or an alternative browser about Google's actions, so their potential users can make informed decisions about whether they want to be actual users or not.
Problem is Content+Presentation model (Score:2)
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 th
Re: (Score:2, Insightful)
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 w
Re:Problem is Content+Presentation model (Score:4, Insightful)
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.
Re: (Score:2)
Simple markup with limited layout control is the design intent of HTML.
That might have been true 20 years ago. The world has moved on, and I suspect the kind of generic, lightly-styled content you're advocating is not what most of the browsing public want today.
Unfortunately we're still trying to shoe-horn modern sites that do suit the majority of the browsing public into old technologies that weren't designed to handle them. The irony is that there are only a few organisations with enough influence to change that situation today, but despite being one of them, Google appears
Re: (Score:2)
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.
And if different web browsers do layout in different ways, how would you deal with that? Also, the browsers should follow the standards, rather than the other way around, but good luck with that.
The other folly of modern HTML+CSS+JS (Score:4, Insightful)
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.
Re: (Score:3)
For instance when MS tried to destroy the web so it could position MS Windows as the only OS that would run on the web it attacked one particular venerability. That there was no gaurantee layout in a particular browser. Of course that is the way the web works by design. HTML was and is a markup language that identifies bits of tex
Re: (Score:2)
Is Google, like MS, willing to break the Web to do this? Evidently so. Is this a big deal. Maybe not right now, but recall MS started small, the integrated the entire COM architecture into IE.
That's a stretch. Google is doing the opposite of MS - they are leaving functionality out of the browser, they are not adding proprietary functionality. Firefox and Opera are leaving out the same functions too.
Re: (Score:2)
To that end, supporting esoteric features that aren't in use in any Google pages is basically a money sink. It requires time to develop and maintain, and makes changes harder, so it's obvious
One step forward, two steps back... (Score:2)
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
Re: (Score:2)
Of course implementing anything complex - like regions - takes a lot of code. Google's "efficiency" argument looks like a strawman. I mean, come on - if cutting lines of code is a goal unto itself, why not just remove CSS support entirely?
If removing lines of code is the ultimate goal, Google should just grab the lynx source code, rename it Chrome Ultra or something, and declare it as their web browser.
"Google and Opera" (Score:2)
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'
Re: (Score:2)
Ok, just saw the mention of Mozilla in the last paragraph. Still interesting that Opera got mentioned at all and Mozilla isn't mentioned until the very end.
Re:"Google and Opera" (Score:5, Insightful)
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.
Re: (Score:3)
Editorial bias... (Score:5, Insightful)
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'.
Re: (Score:2, Insightful)
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-is
Re: (Score:3)
Instead of the write-up, I would suggest reading the actual thread [google.com] on the mailing list.
The big story here isn't that Google wants to drop CSS Regions support here. It's the wholesale removal of code that reduces standards compliance in several areas (including CSS Multicolumn), and affecting features such as printing, which Google does not consider important because, I quote, "we're building an application platform, not a document viewer", and also because "we're choosing to improve mobile performance inste
Re: (Score:3)
I find this write up both encouraging and sad. Encouraging because at least one major vendor out there recognises that the current platform, standards and proposals just aren't fit for long term evolution of web applications and so something drastic needs doing. Sad because Google are going down this route, possibly because they feel they have to as each time they try and do something completely new (i.e. Dart) they get shot down by the opposition who refuse to support something produced by Google even if i
Fork Chromium (Score:2)
. 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?
Re: (Score:2)
Misread (Score:3)
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.
Things haven't changed (Score:3, Insightful)
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.
The Web isn't a magazine (Score:3)
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.
Presentation is tied to content, (Score:5, Insightful)
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.
Re: (Score:2)
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.
The sad thing is, if they'd given us the ability to define constants, separating content from presentation would have been easy, and simple. But because some people are worried that the ability to define constants (or macros) would be abused, we have CSS+HTML instead. Which is never abused.
Growing specs (Score:2)
If only CSS was Turing complete, we wouldn't need these hairy specifications. CSS is slowly becoming a behemoth.
Good! (Score:2)
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.
10k? (Score:2)
I'm just amazed that it takes 10k lines of code to support this feature.
Not a standard. (Score:5, Informative)
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.
Re: (Score:2)
Incredible stupidity from Google (Score:2)
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 easil
CSS Regions Considered Harmful (Score:2)
According to HÃ¥kon Wium Lie, and having read his rational I can't say I disagree. [alistapart.com]
Re: (Score:2)