Supporting standards is pretty unimportant when you have an interface to ruin, ads to sneak in, an unasked os to support, etc... /s
To be on topic, there isn't much activity in the bug topic: https://bugzilla.mozilla.org/show_bug.cgi?id=616605. Two blockers landed in Fx30, but that is well within the statistical margins of randomness.
Wow, just scanned your comment history. You really have boner about slagging on Firefox. What is your story? Every browser has good points and bad points, but for some reason you myopically focus on the shortcomings, real or perceived, of firefox.
I understand fanboy mentality of being invested in something and over promoting it, but I don't understand where you are coming from. Care to elaborate?
Even if my comments (those few I posted already, what shouldn't be enough of a basis for such conclusions) seem to indicate that I dislike Firefox, that is not the case. I have little against Firefox itself, so much I use it as my main browser, and the Beta as secondary. Though, I have to admit I went over with the above comment, as more than half was off-topic (and most likely the source of down voting).
What I do not like is some of the decisions Mozilla leaders made lately. For example, I am clearly against the Directory Tiles or Australis in it's current form, but I support the rapid release cycle, as it clearly threw back Fx into the race and is now one of the top two browsers.
what was also hasty without the 'addons are compatible by default' and Mozilla Maintenance Service
Bloomberg has been funding Igalia to land CSS Grid implementation work in both WebKit and Blink. Igalia wrote a recent blog post about the latest work:
I always liked the flexibility of using that layout manager (although I always managed it via visual editors) so if this does reach mainstream compatibility it could be good!
As comments on the article point out, it seems to overlap with FlexBox quite a bit though.
I think it's actually based on the grids in WPF ( http://en.wikipedia.org/wiki/Windows_Presentation_Foundation ). This is no bad thing; those grids are superb for UI layout. Look at the editors list; this comes out of MS. Again, it's good that they feed this out into web standards.
Very much reminded me of WPF, where grids are awesome. This being CSS, the syntax is a bit wonky, but it is certainly very good news for a world stuck in "pick any one of three sizes" bootstrap grids.
It may seem like that, but the major difference is the layout is left to the CSS. When combined with css media queries, the grid can provide a complete restructuring of the layout completely independent of the markup which would not would have been possible with tables.
Grids are also significantly more flexible and more responsive than tables. You finally get reliable vertical centering of elements as a side-benefit.
Tables got a very bad name because they were abused back when they were the only thing available for layout: "if the only tool you have is a hammer..." Yes, but sometimes data is actually tabular.
Grids are good for UI layout. The web was just for documents, but not any more. So now we need good ways to lay out UIs.
A comment on the original link stated that 'flexbox is slow', someone responded with a question; 'is the spec inherently slow or just current implementations?' but no-one elaborated.
>Tables got a very bad name because they were abused back when they were the only thing available for layout: "if the only tool you have is a hammer..." Yes, but sometimes data is actually tabular.
Not only that: layouts are actually tabular (grid based) themselves. That's why tables were, even if not created for layout, an untuitive fit for doing layout work.
We shouldn't have left tables in the first place. Design (including flexible responsive design) is ALL about grids.
Since they didn't have them in the early days, the used HTML tables, which weren't designed for that, but have lots of the needed behavior built-in.
Then came the idea to use floats, which was a horrible idea. Floats weren't designed for layout either (they were designed to, well, float simple elements, e.g let text flow around an image and such).
So designers, instead of abusing tables (which weren't meant for layout, but at least had what was needed), they started abusing floats (which weren't meant for layout AND didn't have what was needed, without ugly hacks and workarounds).
Flexbox and the Grid Layout are actual layout systems, designed for that very purpose. Finally.
At 1:35 he says "you can do all sorts of things you can't do with tables". I think I'll continue learning jQuery Mobile and run on a wide variety of devices and PC's.
Great, but I feel horrible at the same time because browser just slowly reinvents everything, and is still limited to a single specific implementation. How about just make Javascript frigging fast so everyone can code their own layout system? How about standard NaCl interface for layouting? Browser needs to be an open platform, not a framework.
> How about just make Javascript frigging fast so everyone can code their own layout system? How about standard NaCl interface for layouting?
If layout were in JS (or PNaCl), we wouldn't be able to run it off the main thread, or parallelize it in Servo, or experiment with running it on the GPU. We would also lose the ability to do text reformatting on mobile, accessibility would be harder, etc.
To elaborate in regards to running CSS off the main thread: We got very lucky that IE's extensions to allow JavaScript in the middle of CSS evaluation (and also possibly XBL) never caught on, and so CSS can be done more or less entirely independent of the main JS event loop (unless the styling is performed in response to a direct JS query, e.g. getComputedStyle). If layout were performed by JS, there would be no hope: layout could perform arbitrary JS manipulations and we would be no choice other than to stall the main event loop while styling is happening (as current browsers do). But because CSS is largely separated from JS, we can just run it off the main thread and allow JavaScript to run uninterrupted by layout.
> How about just make Javascript frigging fast so everyone can code their own layout system?
Because separating content (HTML) from layout (CSS) from behavior (JS) is a good thing, and because, particularly, being able to have content work without layout or behavior (for situations where you just need the content), and to have content and layout work without behavior (for situations where you just need static presentation) are important.
I'm curious: how do you feel about css transitions? I'm being totally non-snarky here, and I fully agree in the ideals of separating the three concerns, but I sometimes wonder if the existing lines aren't drawn in slightly the wrong place.
Conceptually, I think what they cover fits more into presentation than behavior, because its how the transition from one state to another is shown. So I don't see CSS transitions as an example of the line being drawn in the wrong place.
I'm not saying that its always clear cut or that reasonable people can't disagree on where to draw the line.
Is there any non-video documentation? I find videos painfully slow compared to scrolling through some quick actual code examples side-by-side with results.
Chrome appears to have some of it experimentally. For example, the old 'grid-definition-columns' which was removed from the spec is supported, but the newer (?) 'grid-template-columns' isn't. Alignment doesn't seem to work, at least as I understand it should (e.g. 'align-self: center' should vertically align a grid item).
For 95% of what people want this for, CSS tables would probably work just as well ("display: table" ). The main advantage of this seems to be the "minmax" ability, and some rethinking of the api, since CSS tables are semantically based on HTML tables.
"CSS Grid Layout is coming to Firefox in 2012": http://www.2ality.com/2012/03/css-grid-layout-firefox.html
So where is Firefox support for this? Was there a good reason to delay, or was it just other priorities? Did flexbox take much longer than expected?