I giggle a little bit inside when web designers say "We shouldn't use meaningless tags that exist only for layout. We should use semantic ones, like <header> and <footer>!". Except that, uh, "header" and "footer" themselves are layout terms. They're just a metaphor for a document as a body ("<body>") with the head at the top and the feet at the bottom. It's not like the contents of a <footer> tag have anything to do with feet. We call it "semantic" simply because the metaphor is old enough that we've internalized it and no longer see it.
Not that I think this detracts from the talk at all. Fewer, cleaner tags is good, regardless of how they're spelled.
I do not see how the etymology of these words being a layout-metaphor argues against them having more semantic value now? The way you describe a footer makes it sound like the last block of text of any article (being at the bottom) is by definition the footer. Which is of course not the case: it is used for certain types of content.
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].
We call them semantic because they have extra technical meaning in HTML (built in WAI-ARIA roles for example). For example, browsers expose them as landmarks for screen readers.
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.
> Except that, uh, "header" and "footer" themselves are layout terms.
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.
Semantic tags are required from an accessibility point of view. If not, there wouldn't even be a need for a <table> tag. Might as well just use <div> with display:table. Actually you could just about use <div> for everything! But by doing so, you are alienating those who use screen readers to browse your site.
I really don't see why we should have semantic tags to begin with, since semantics isn't obviously the psychological API by which future colleagues are going to operate on your code. Think about the interface by which colleagues wish to edit your code.
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.
If you need to support IE 10, 11, or Edge then Grid is broken. Microsoft's browsers follow an older spec than Chrome/Safari/Firefox. Microsoft are going to fix Grid in Edge 17, but no release date yet.
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.
I've used grid with IE11. You need to add some extra prefixing noise to your css. The way you identify grid elements is different and it sucks to duplicate the layout information.
How do you feel about his advice to people in your position? He suggested that you start with a design for mobile that works on a wider screen. Then use grid to achieve responsive designs. He also suggests that responsive design comprehends browser and browser version (ie don’t always look the same across all browsers). Interested I your thoughts.
In addition to these, the article "A Complete Guide to Grid" on CSS-Tricks [1] is an excellent reference to use after you've become familiar with the concepts.
I worked with CSS Grids back in 2010 when I was working on a Windows 8 app. Since then I hated any other constraint resolver including Box Model, iOS Auto Layout and Flexbox model.
CSS Grid is so intuitive you forget how difficult this problem has been in the history of UI engineering
The intuitiveness of CSS Grid is the major appeal for me.
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.
I wonder if I'm alone in the opinion that whatever method is used to create a complex layout, the method needs to be Turing Complete. I can understand the appeal of being able to create some tags and not having to worry about what happens after that, but you really only end up with a good design if you're just trying to do something simple. We often see people so devoted to the idea of CSS they end up with something incredibly complicated that could have been done in just a handful of lines of code.
I disagree. It is possible to generate a wide variety of layouts using this and other purely declarative approaches. If producing a layout requires the use of "Turing-complete" semantics, then JavaScript is available for the purpose. I would argue if your layout becomes that complex you might consider simplifying.
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.
As someone who recently converted to using CSS grid for my company, I can't imagine going back. It really reduces the mental overhead when building complex layouts and has made my code shorter and easier to understand.
Who is the target audience of your company? The reason I ask is that I highly doubt I could use CSS grid at my company(news outlet) without breaking the site for many of the users.
It's funny, as six month ago I wasn't very fond of the whole "Grid is ready today" talk with ~65% of browsers supporting it. But actually I am glad that within 6 month that percentage seems to have risen by another 10% so that we have ~75% today: https://caniuse.com/#feat=css-grid
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.
Wrong. Tables impart meaning to user agents (browsers, screen readers, google bots, etc) and as a side effect they have a default visual style that is useful for some layouts in some limited situations (but without any kind of fine-grained detail that most modern designs call for -- ESPECIALLY when making responsive designs that work across different screen widths).
CSS Grid, on the other hand, is a tool specifically for complex visual layouts which imparts no semantics on the content (so it is proper to use for non-tabular content).
Disclaimers: I'm not principally a UI/UX designer, though I (re)write a hell of a lot of CSS because so much of it completely sucks.
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.
I believe it's so that you can use -1 to refer to the last gridline. If it was 0-indexed there would be no way to target that final gridline, or there would be a one-off error when using negative numbers.
[+] [-] munificent|8 years ago|reply
Not that I think this detracts from the talk at all. Fewer, cleaner tags is good, regardless of how they're spelled.
[+] [-] vanderZwan|8 years ago|reply
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].
[0] http://gameprogrammingpatterns.com/introduction.html
[1] http://gameprogrammingpatterns.com/sample.pdf
[+] [-] flooq|8 years ago|reply
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.
[+] [-] awj|8 years ago|reply
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.
[+] [-] shripadk|8 years ago|reply
[+] [-] ams6110|8 years ago|reply
[+] [-] threatofrain|8 years ago|reply
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.
[+] [-] commandlinefan|8 years ago|reply
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.
[+] [-] ben174|8 years ago|reply
[+] [-] Someone1234|8 years ago|reply
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.
https://caniuse.com/#feat=css-grid
[+] [-] daotoad|8 years ago|reply
But it most definitely works.
[+] [-] ko27|8 years ago|reply
[+] [-] ryangallen|8 years ago|reply
[+] [-] Bromskloss|8 years ago|reply
[+] [-] Jordanpomeroy|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] Dangeranger|8 years ago|reply
- http://labs.jensimmons.com/
- https://gridbyexample.com/
[+] [-] yawgmoth|8 years ago|reply
[+] [-] mhink|8 years ago|reply
1: https://css-tricks.com/snippets/css/complete-guide-grid/
[+] [-] callahad|8 years ago|reply
[+] [-] msoad|8 years ago|reply
CSS Grid is so intuitive you forget how difficult this problem has been in the history of UI engineering
[+] [-] blueside|8 years ago|reply
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.
[+] [-] ruairidhwm|8 years ago|reply
[+] [-] joshfarrant|8 years ago|reply
[+] [-] gmiller123456|8 years ago|reply
edit: Fixed spelling of "Touring"
[+] [-] eyesee|8 years ago|reply
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.
[+] [-] tmalsburg2|8 years ago|reply
https://en.wikipedia.org/wiki/Alan_Turing
[+] [-] pg_bot|8 years ago|reply
[+] [-] ravenstine|8 years ago|reply
[+] [-] JepZ|8 years ago|reply
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.
[+] [-] Animats|8 years ago|reply
[+] [-] jordanlev|8 years ago|reply
[+] [-] dredmorbius|8 years ago|reply
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.
[+] [-] wes-k|8 years ago|reply
[+] [-] bajsejohannes|8 years ago|reply
[+] [-] kybradeck|8 years ago|reply
Example: https://css-tricks.com/things-ive-learned-css-grid-layout/#a...
[+] [-] gilrain|8 years ago|reply
[+] [-] cryptos|8 years ago|reply
[+] [-] wes-k|8 years ago|reply
Also kudos to the speaker, Morten Rand-Hendriksen, that was a very enjoyable presentation!
[+] [-] TACIXAT|8 years ago|reply
[+] [-] ronnier|8 years ago|reply
[+] [-] gkilmain|8 years ago|reply
[+] [-] esfandia|8 years ago|reply
[+] [-] pvg|8 years ago|reply