Not that I think this detracts from the talk at all. Fewer, cleaner tags is good, regardless of how they're spelled.
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.
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.
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.
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>
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.
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.
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.
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.
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.
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.
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!