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].
> 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.
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.
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.
That's not true, though. Semantic tags may make it easier to be accessible, but they are absolutely _not_ required.
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>
is perfectly accessible, and will be interpreted as a button, though semantically it's a div.
WAI-ARIA has its limitations. When it comes to tables (which is the example I provided) there are no roles for demarcating headers (<thead>), body (<tbody>) and footers (<tfoot>). Instead there is a generic "rowgroup" role which doesn't indicate to the person using a screen reader if the row belongs to a header or body or footer. Also, without a header demarcation, it becomes the responsibility of the disabled user to keep a count of the table cells to be able to associate content with headers (which the blind user will have to assume is the first rowgroup). Complex tables (which have multiple header rows with some cells merged) are simply inaccessible to the user.
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.
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.
It doesn't with IE10 though. And there's no way to fall back to flex or another column system.
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.
One scenario I can think of is a non-IE user telling an IE user to go to a particular website and click the button that's at the top of the right sidebar. For the IE user, it might be a stacked layout where the sidebar actually appears under the main content. I would call this a nuisance more so than a major issue, but nevertheless it is something to consider.
I think the average computer user knows that websites often look different on computers vs. phones, so they might be confused when a website looks different than normal on a computer. Like I said, I would only call this a nuisance. Certainly not a big deal.
I think it depends of if you need trafic from those browser or not.
Because if you do, you'll have to maintain several version, or increase your time on working on it to do gracefull degradation (which is of course a good way to do, but more expensive)
So you like being lazy ... a technical challenge comes your way and you hope others fix it for you.
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.
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 haven't built a site in the last 5 years without flexbox and not a single time was I able to interact with it without referring to docs, then still randomly iterating through property values in the inspector until it looked right. That's basically my official process. Luckily the problem space is simple enough for that to be efficient, and only a couple of properties are needed 90% of the time.
I've had the opposite experience. I haven't floated anything in years, and I'm constantly running into problems that I can quickly solve using simple combinations of flexbox, margin, and padding.
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%;`
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.
I'd agree with you if web pages were "static documents", but they aren't and never were. They've always had to adjust to different screen sizes, and quickly became interactive applications, and now have to adjust to radically different pixel densities.
And all of that works just fine with CSS. CSS has problems, but more to do with scoping or lack of a grid-based layout system (until now).
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.
I think you misunderstood my response, in what you were replying to I was just pointing out web pages are not static documents. I in no way intend to suggest that JavaScript can solve all of the problems with CSS, and also don't agree that the grid system will help much. IMHO the biggest thing missing from the CSS/HTML/JavaScript system is the ability to determine how much space is required to display certain text or elements, vs how much space is available to display them, and the ability to make decisions based on that (recursively) on how other elements are displayed.
Yeah. And then you actually want to create a layout that can display images properly, and you’re screwed.
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)
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.
Medical practice management software. (we run the medical practices as well) If we made software that was accessible to the general public I would hesitate to only use CSS grid.
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).
It's worth trying Inventor (or Autodesk Fusion 360, which is basically a cloud-based Inventor with a free demo) to see a constraint system with a good GUI. Draw lines and make boxes, and if you end a line at an edge, the line endpoint is constrained to that edge. End a line at the endpoint of another line, and those points are constrained to be at the same place. If a line is drawn vertically or horizontally, it's constrained to stay vertically or horizontal. Drag a point or line, and everything else is adjusted, but as little as possible, to maintain the constraints.
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.
It was very hard for the CAD and animation industries to figure out a good UI for editing geometry. It took about two decades. But it's now a solved problem. The web layout industry should look at that technology, which comes from an industry that has to deal with hard geometry problems.
One of the advantages of architectural design is that few building footprints vary greatly from instance to instance, or for the same instance, particularly over the course of a fraction of a second or so.
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.
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.
Yes, but that would mean the first gridline == 0 and the last gridline == -1, instead of the way the spec is written today, where the first gridline == 1 and the last gridline == -1. For me, consistency wins here.
I think it means make your containers 100% width blocks and stack them on top of each other vertically.
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.
Not that I think this detracts from the talk at all. Fewer, cleaner tags is good, regardless of how they're spelled.