CSS Grid changes everything [video]
youtube.com
youtube.com
Not that I think this detracts from the talk at all. Fewer, cleaner tags is good, regardless of how they're spelled.
That said there are a lot of similar examples of magical beliefs that are unfounded. Extra <div> tags rarely matter and "semantic" CSS values don't do anything.
Your own book uses <asides> very heavily[0]. They are not just literally aside the regular flow of the document (actually, about that, see the next paragraph), the type of content in them is different - it is reserved for tangential stuff like jokes or deeper information that would interrupt the pacing of the main narrative.
Aside about asides in your book: I bought the epub version when it came out, and although it was a symbolic purchase (I had read the whole thing already as you wrote it), I somewhat regret the format choice due to the sorry state of epub readers. Not all of them even support the aside tag. The one that does (the Firefox Epubreader extension) does not keep a margin for the aside but inlines them. This really disrupts the flow of the text. In traditional book layouts that use the full margin for the text, these asides would be printed as a smaller footnote at the bottom of the page. Surely with the right bit of code one could generate such a layout, based on the semantic meaning of <aside>. But like I said: epub readers are in a pretty sorry state. Should have gotten the pdf instead[1].
That's a fair point. Since, historically, the convention has already been established that the stuff we put at the bottom of the page in a footer tends to be stuff about "X", we can now say with some confidence that "footer" has the semantic "about X".
> They are not just literally aside the regular flow of the document (actually, about that, see the next paragraph), the type of content in them is different - it is reserved for tangential stuff like jokes or deeper information that would interrupt the pacing of the main narrative.
Right, they are both. They are physically off to the side because they are unnecessary for the main line of the narrative. The form and the function are in harmony (as they should be!).
"Aside" is another funny word because it's also a spatial word. I'm not sure how it entered use for print. I could see it being simply because the text is to the side.
But "aside" also means an "an utterance not meant to be heard by someone; especially : an actor's speech heard by the audience but supposedly not by other characters". That conjures up a delightful image for me of an actor literally stepping to the side, leaning towards the audience and muttering a joke to them. That's the picture I always have in mind with the asides in my book.
I could see it entering print from that etymology too.
> I bought the epub version when it came out, and although it was a symbolic purchase (I had read the whole thing already as you wrote it), I somewhat regret the format choice due to the sorry state of epub readers.
I really appreciate you buying a copy! I agree, ePUB is about the worst format. But it works on eReaders, which is nice. If you aren't limited to one of those devices, the PDF or web version is probably better. If you'd like me to send you the PDF version, email me and I'd be happy to hook you up.
WAI-ARIA defines the mechanisms to make existing webpages accessible, and they do not require using tags for their semantic meaning - quite the opposite. You use role attributes for this.
For example:
<div role="button">Click me.</div>
WAI-ARIA complements semantic tags. It doesn't contain replacement for all semantic tags. It doesn't stop at the table tags. How would you represent <main>, <aside>, <header>, <footer> using WAI-ARIA such that the screen reader picks up the intent? Also imagine trying to replace the <input> or <textarea> elements with <div> tags. You would have to use _contenteditable_ and then implement all the semantic features yourself. It's just not worth the effort and the end result will be buggy.
Doesn't that give them semantic meaning? When I see a "header" tag, that tells me something about its intended use. When I see a "div" tag ... I start reading ids and class names and hope for the best.
Well, honestly, using HTML for around 90% of what it's used for these days is the roundest peg in the squarest hole to begin with.
Do they care more about its structural position? Then name it by structural position. Do your teammates care more about a component's logical relation? Then name it by its logical relation. Do they care more about the actual content? Then name it the EULA component.
But one way or another, based on the modern way of web dev where an interface is divided into components, any team inheriting a project will need to understand Y components explaining X pages no matter what. Naming is helpful, but the distance from good naming to great naming won't be a big force multiplier.
Unfortunately this is my life right now. When Chrome and Firefox dropped support for NPAPI a lot of enterprise customers intentionally moved their users back to IE 11. The loss of NPAPI has ironically increased IE 11's market-share, talk about unintended consequences...
I understand why they didn't but part of me wishes Microsoft had enabled NPAPI in Edge just so we'd at least get modern web standards even if NPAPI is bad and insecure. Instead IE 11's life is now another five years at minimal or until the last Java Applet, ActiveX control, or Flash page disappears.
But it most definitely works.
Which means, if you need to support IE10, you need a whole parallel set of styles. There's no graceful degradation when it comes to overall site layout, unless you're willing to serve the single-column mobile version to older browsers.
Who in the world has that as a significant user base?
This is the hipster frontend engineer attitude. Not to be mistakened for real frontend engineers who create robust sites for paying customers. Enjoy your world and ill enjoy the enterprise dollars. I like coding. I dont complain about the challenge.
For all you know, they build websites or applications that don't have any need to run on older browsers, or at the very least, there are diminishing returns.
There's always an opportunity cost. While you're building support for older browsers, they could be adding valuable functionality to their software.
Which is more valuable depends on the situation.
Customers with old browsers? Eww! You keep them; I'm better off without customers. :-)
update: solved it
CSS Grid is so intuitive you forget how difficult this problem has been in the history of UI engineering
I've worked with Flexbox for the last few years and still regularly have to look up the Flexbox reference pages. Perhaps it's just me, but I have found the whole Flexbox naming scheme anything but intuitive.
For the first year or so, I often had to look at this cheat sheet: (https://css-tricks.com/snippets/css/a-guide-to-flexbox/, but now it all feels very intuitive.
The one exception is `align-items: stretch` never works how I expect it to, and I usually end up with a combination of `flex-basis 100%` or `max-width: some px value` with `width: 100%;`
edit: Fixed spelling of "Touring"
There is a long-standing trend of adding scripting into declarative environments to allow greater capability. More often than not this becomes yet another avenue for exploitation by bad actors. As an industry we should learn from our mistakes and resist the use of executable code into static documents.
When I see devs saying "Just do it all in Javascript" I have to assume they aren't actually that familiar with CSS. First off Javascript simply manipulates CSS properties anyway when it comes to styling, and writing a system that completely ignores CSS and renders its own way is far more complex without any clear benefit.
There’s a reason all the “powerful CSS layouts” are all poor re-iterations of printed pages. Once you want actual layout, you end up carefully positioning everything with Javascript.
And by actual layout I mean things like Sencha (easily half of which still cannot be implemented in CSS without)
And when you take a closer look to the numbers you can see that in another 6 to 12 month the technology should be practically out there in every browser, as the few who will still not have it, will be some mobile browsers which will use the mobile first baseline variant anyway, if you follow the recommendations from the video.
Pretty cool stuff.
Now if it was a full constraint system, that would be more impressive.
Specify that two lines must be parallel, or perpendicular, or the same length, and those become constraints. Specify a dimension between two lines or points, and they stay that distance apart. A dimension can have an expression based on other dimensions, so if you need something to be twice the distance of something else, you can do that.
This goes beyond straight lines. You can have a circle or arc constrained to touch a line or another circle or arc. A curve can be constrained to be tangent to something else, for a smooth transition. Designers would love that.
The GUI won't let you add a constraint that conflicts with another constraints. There's no "constraint priority". All constraints are equal.
The GUI has a counter which shows how many degrees of freedom still need to be constrained. Little red arrows show you what can still move. When everything is constrained and nothing can move, the counter changes to "fully constrained", and the sketch is now rigid. But you don't have to go all the way to fully constrained if you don't want to. The system will do something reasonable if you don't.
Some sketch dimensions may be driven from another sketch. In the web world, this would correspond to adjusting to window size.
The CAD people deal with hard geometry problems, much harder than the ones web layouts face, and they have much better technology for doing it. It's even user-friendly.
for sure a GUI editor would be a beautiful thing to behold though!
Or ... when that's happening, much more exciting things are going on.
I'm wondering just how complicated text really needs to be, and what the benefits of walking well outside gridded layout is.
A text is essentially a linear strand, wrapped. Some of those strands may present as sub-texts (tables, lists, call-outs, etc.), but you still have the concept of "how do I present a sequence of letters, arranged by words, sentences, paragraphs, etc., into some folded space?"
We've gone from tablets, rock walls, scrolls, etc., to generally codices (printed) or ... well, sort of a scroll-page hybrid for Web.
That said, interesting points, and I plan on digging into this a bit further.
Tables overload what should be a data-definition element with layout semantics. And, yes, there's an argument that might be made, I suppose, that Grid (which I'm only just learning of from this video) might recreate some of the sins of table-based layouts. Especially of "pixel-perfect" layouts.
And, yes, I can see clients or frameworks which, say, assign a grid to Every. Damned. Paragraph. In. A. Page.
You cannot out-wit stupid, it's far too smart for that.
But the positive here is that you're getting the gridding of tables with the flexibility of semantic positioning. And that could be useful.
And unless you're dealing with a truly supergenius-level idiot, you might be able to deal with broken Grid layout by just dropping the Grid-based CSS entirely. Tools such as Reader Mode or Pocket (or similar) should have an easier time parsing this sort of thing.
Though really, if you want to fix HTML truly, insisting on standards-compliant formatting and imposing a penalty (Web search still seems to be the gatekeeper role here) on Really Bad Design might address some of that.
Though there's a horribly large amount of Very Bad Structural Page Design. Including much of it from, oh, just to select a publisher at random: Google.
Example: https://css-tricks.com/things-ive-learned-css-grid-layout/#a...
Also kudos to the speaker, Morten Rand-Hendriksen, that was a very enjoyable presentation!
yes grid is awesome but how to deal with polyfill is the question
I will be taking the approach of creating a "good enough" layout for older browsers and a superior layout to modern browsers using "@supports" feature query.