> I’ve found a pretty simple starting point for testing the bones of a website by using the following single line of CSS
Or just use Firefox. The built in CSS-designer/debugger has a button to do just this on demand.
Browser-suggestions aside, I really agree with the sentiment of this article. That’s how I like to build sites and solutions when not forced to use some other framework or approach.
And for anyone who isn't familiar with (what I would consider) the most important difference in this use-case: borders affect the positioning of other elements, whereas outlines do not. You don't want to be using a temporary border, since it can significantly affect the layout of your site when you remove it.
Borders still affect the positioning of things even with box-sizing set to border-box. For example, here "Block 1" is still two pixels taller than "Block 2":
Does that really matter though? A difference of 2px for something temporary doesn't seem like much concern. While I understand the implication is that these can accumulate and cause larger layout issues, the purpose of this practice is to highlight those areas to remove that accumulation anyway
When I'm coding DIV layouts by hand, I temporarily assign each DIV with a random background-color. Once I have the layout and responsiveness required, I strip the background-color setting on each DIV as I fill them up with content. Works for me.
I feel like there's strong friction between HTML trying to semantically describe the structure of a page page and JS frameworks where you try to build custom reusable components which might not fall into the rigid structure defined by classic HTML.
The spec authors would have done better to make the semantic stuff attributes. It's difficult to tell what CSS rules you're going to have to apply to any given semantic tag, which makes people instinctively reach for <div>s and <span>s. React native gets this right, with <Text> and <View> and just a handful of others, with attributes like testID and accessibilityLabel driving automated software that needs to read the screen.
My God that page is beautiful. Over half the vertical space is content without me touching anything. No banner bar asking me to install some bullshit mobile app. No 800-pixel panel at the bottom telling me what a cookie is. No incredibly obnoxious warning that I only have one more free article before the wisdom of the ages is lost to me so I'd better cough up five bucks.
It is not bad, but on a regular monitor (1080p) the white space is about 60%. We don't need wide monitors just to use the center 40% of it, we cannot go Notepad style and use 100% width, I would prefer to use about 60%. That makes also the page shorter and requires less vertical scrolling.
But this is picking on the page layout, not on the merits of the points in the article, that I mostly agree.
Depends on your setup. On my phone it was perfect. On my desktop the text column is about the size of a sheet of paper, which is again perfect for me. Widescreen monitors are great for filling in your peripheral vision when gaming but it's easier on the eyes to move your fovea 35 degrees of arc for every line instead of 75.
Looks great on my 900x1600 monitor... portrait just like the content I read. Using a tall not wide monitor makes reading more fun than watching movies! Mom would be proud.
The idea isn't to pretend it's 1999 and only use stuff that works in netscape4/IE5, but to build pages in the same way as then. <nav> adds something useful - it helps screen readers out, but costs nothing.
I still use tables. Always when I need to position things relative to each other and have them squish properly. I tried really hard to use/like divs but they are not helping me most of the time.
What I'll call 'table layout' can be done via CSS on any tags, you don't need to use `<table>` elements to make use of the 'table layout' you like. Lately CSS has added two new 'layout' modes you might like even better: Flexbox, and CSS Grids. Both of these take the ideas from table auto-layout, using constraints and content to help size things.
Separately from how you want things to look (CSS), you shouldn't be putting content into `<table>` elements that aren't the sort of thing you'd put into a spreadsheet. That's not using HTML well. Keep in mind you can still use the table layout with other tags via CSS. Always wrap your content in the most-fitting tag HTML has, then worry about the layout after :D
It is embarrassing, but I only know how to write HTML like it’s 1999. The last new thing I learned was an iframe, the kids tell me CSS something I should learn...
Keeping up is an endless treadmill. If your primary work is in some other domain, say backend infra or some non-coding profession that writes a line every blue moon, the investment may not pay off.
If you are a front-end dev it's of course a no-brainer to keep up.
Limitations imposed upon embedded scripts from foreign domains by technologies like CORS and the like, combined with modern styling abilities.
You can place another service's elements on a page that look like they're actually part of the page layout while the JS running them can freely communicate with the service's backend without having to bother with cross domain problems.
Think of all the support/chat widgets you see on modern-day pages, they're all iframes.
I've never understood the purpose of "semantic" html. It seems to be bandied about as some sort of unquestioned good, but why? If the code is easy to understand who cares that the "correct" tags have been used?
Obviously there are some benefits for screen readers and search engines, but these uses should be explicitly checked for as part of a QA process instead of relying on some vague standard of semanticness.
When done properly, it increases the separation between the actual content, and the styling on top of it. Any time you get closer to that ideal separation, accessibility is enhanced (and it’s also forward-thinking towards yet-unknown methods of accessibility assistance).
IMO this is an example of extreme overengineering and premature optimization. Unstyled html is so ugly and inconsistent across browsers that it’s just not a realistic scenario that it would be consumed without the css and js that make up the rest of the code.
When an alternate display method comes out and wants my semantic html, I will add it to my QA workflow and make sure that it looks good instead of relying on some vague standard of semanticness from one of many bloggers.
For a web application, unstyled HTML is almost certainly a mess even if it's perfectly semantic, but for a web page you absolutely don't need any CSS at all for it to be at the bare minimum readable on almost any device.
Sure it's mostly black text on white backgrounds with only minor typesetting differences between elements but as a means to present information it has worked since the mid 1400s...
This comment made me realize how relative everything is. It seems it was yesterday, when you would open Mosaic and slowly discover completely different worlds, one after another, and you'd never think of complaining HTML was aesthetically unpleasant...
Not sure why you'd think semantic HTML is for people reading the code?
It's for software reading the page and making use of the extra information, e.g. a screen reader being able to tell a user that there's a navigation element on the site and being able to jump there. Reader modes knowing what the main article on the page is. ...
(EDIT: I see you edited that point in, so yes, that's the main one, and IMHO a good enough one)
If you do semantic html vaguely right (using <button> for buttons, <table> for table, <input> for input fields) you have something you know will work decently on screen readers, plugin and other assistive technology (which includes password managers in the case of login forms, etc).
If you don't follow semantic html at all I don't see how QA can safe you, except for QA telling you to fix that <div> by replacing it with a <button> (or <div role="button">, or <a> or whatever you prefer).
Honestly, there isn't, except for a small subset related to screen readers.
At one point there was a kind of hope that semantic tags would make web content easily machine-parseable, unlocking a bunch of meaningful content reuse somehow that better semantics would make possible. (Big data, ML and all that.)
The two canonical examples being that lists were important so software could extract meaning from list items, and not using tables for layout so software could trust tables actually had meaningfully tabular data.
But... that never really happened, it's not clear it ever will, and it doesn't benefit the content author directly anyways, so... yeah.
(Like you say, screen readers are the main thing, so use the tags and attributes that are important to screen readers, like buttons and alt text... but that's a very specific subset. A screen reader certainly doesn't care if you use a <div> or an <li> or a <td>.)
Edit: I stand corrected on my example, for <td> specifically I forgot <table> lets screen readers navigate vertically and also read column/row labels.
You deserve downvotes. Semantic HTML is a key part of making your website accessible for people with disabilities. Ignore it, and you shouldn't be making things for the web.
> A screen reader certainly doesn't care if you use a <div> or an <li> or a <td>.)
It absolutely does. Try firing up a screen reader before you make such comments spreading misinformation.
For example, it's maddening to see people now making tables out of flexbox grids and such. In a screen reader you can navigate a <table> in two dimensions (rows and columns). The flexbox variety completely breaks navigating up/down columns.
As with most things like this in tech (and every other economic sector that has ever existed) it's largely a guild protection and enforcement matter. When economic guilds use an unnecessarily strict 'only proper way of doing a thing,' it is for insulation against outsiders and to enforce their control over the domain they have a personal stake in. To the extent that it's truly petty, that is the extent to which the person shouting about it has very little protection from eg an endless flood of low priced competition (Web developers have historically been very exposed); or otherwise it's just pedantry run wild and a personal issue.
You see this in all professions and without exception, from the exercise industry, to trades like plumbing, to healthcare and everything inbetween. Most of it is bullshit, process-based job security theater. Most major guilds just end up developing higher level cartel-like certification protections to keep them economically secured from competition.
What a terrible attitude towards accessibility. Try surfing the web with your eyes closed and only a screen reader to guide you. I guarantee you'll cheat and open your eyes, maybe then you'll understand.
I look at 'div soup' HTML and shudder. The authors of it have not got a clue. They also make it hard for people who do write proper HTML with the correct tags, styling the elements and keeping the separation of concerns to do anything with it.
It is about organising your content, if everything is in div tags you might as well just upload JPGs of your web pages, with different ones for desktop and mobile.
Another game changer is CSS grid. You no longer need wrapper divs to do very basic tasks such as centering content. In fact content with horrible divs everywhere is a nightmare to style up with CSS grid.
An example of this is a basic form. With just the form elements and labels you can get it looking sweet in next to no time with CSS grid.
However, if some zombie has put lots of spans and divs around the form elements and done the labels wrong then you have to choose either to rebuild the backend thing that churns out the form or just style it up lame block layout style.
Pseudo selectors are also cool, there is no need to have silly 'i' elements and spans to put that asterisk after 'required'.
Some people like to keep it simple, doing HTML properly, others want to pootle along with their divs and class attributes. I know what will look good in ten years time and what will look outdated.
HTML5 introduced many features but the main course was the semantic elements. You can and you should write web pages with these elements and also be thinking in terms of them.
You may scorn the accessibility aspect but accessibility is easy if you use the right elements. Why would you not want to have it? There is also the mindset that goes with it - the web is for everyone, not just rich, white, English speaking males with perfect eyesight.
The article is spot on and extremely well said. Styling elements rather than make believe classes is particularly well said.
I would say that people who create div soup HTML should be banned from the internets, the work practices of overly complicating everything has been going on for too long.
I don't even regard div soup web pages as proper web pages, it is like comparing beige deep-fried processed food with freshly prepared from ingredients food.
> you might as well just upload JPGs of your web pages
That was not so uncommon in 1999 :-(
Seriously, it's 2019 and some developers still don't get the value of semantic markup while this has been beaten to death for at least 20 years. this profession is cluttered with too many tourists. I even talk with devs bragging about the lack of care for markup.
I wonder how well it would work to do that with JSON-LD micro-format markup.
Google don't care about HTML as they are way too clever for that. If I had more time I would like to see how they would rank two identical pages, one done properly and one that was a JPG image with a dangleberry of JSON-LD tacked on. I bet they latter would fare better!
Screen readers, distilled/simplified views, other automated parsing.
Things like marking up addresses, phone numbers - as examples - means that a search engine can log a website as associated with a particular address, a browser can link to enable a number displayed to be called direct.
If for example there was a microformat (or other semantic markup) for opening times then SE/social sites could read and display (and update) that info without owners having to go on 20 sites if they change opening times.
Of course it can also help infer which parts of a page are advertising, or impressum, and not render that.
A plugin could offer to work on tables, or import them to a spreadsheet.
Because the idea that one can separate content from presentation appears as an elegant Platonic ideal to a lot of folks. The trouble seems to be that content and presentation are not actually disjoint sets. And (a perhaps different) set of folks want a slice of the juicy middle.
Don't get me wrong, I used to write as semantic HTML as I could; nav for navigations, table for table's, aside for well asides, etc as the author suggests, but ultimately it just really doesn't matter. nav and div render exactly the same. In fact, I find zero value in using ul/li's for lists that aren't bulleted. I know it's an unordered list of items, but really, what _is_ the value in writing semantic HTML if the devs/browser/users don't care or know the difference? Especially if you're changing the "semantic" element's default behavior in order to get a look and feel or behavior that is far from the original "semantic" intent.
Ever tried to use your pages with a screen reader? It's quite an interesting (and potentially maddening - screen readers are power-user tools, and quite difficult to get into if that's not how you normally operate) exercise.
I tried doing this once, and I wasn't even able to install the damned thing. If you've got any advice or instructions on how to get started with a screen reader for testing purposes, I'd be really interested.
On Windows I tried NVDA and the demo version of JAWS. Installation worked without issues for me, and I looked for tutorials on how to use them/put up the keyboard shortcut overview. Sorry I can't point you to anything more specific right now.
I thought this as well until a recent project needed to meet WCAG or whatever the requirements are called for accessibility... in those cases using the "standard" tags can save a lot of headaches in trying to make sure a screen reader knows what's going on with the page...
Accessibility is one reason. A web page may Visually look the same regardless of which elements you use, but it may be treated very differently to screen readers used by visually impaired people.
Using semantic HTML also helps search engine crawlers and other automated software understand the structure of your pages.
If you use semantic HTML you get a lot of accessibility for free, since screen readers etc. all speak semantic HTML.
That doesn't mean you can't write accessible web applications without semantic HTML, but it does mean you have to spend time adding the accessibility after the fact.
I mean you can, off course, write accessible HTML without semantic HTML. Just remember to:
* Set the correct aria attributes and roles for assistive technologies.
* Make the correct elements focusable, and order the focus correctly between elements, and add a specific style when then element is in focus.
* Capture the focus when appropriate but still allow focus to the URL bar.
* Set the correct key event handlers for keyboard navigation, submit events and triggers, validation events, etc. for assistive technologies, etc.
* Be prepared to warn users that your site will not work without javascript or in reader modes or in text based browsers, as well as make your site somewhat inaccessible for bots and crawlers.
And I’m sure I’m forgetting something. Point is, it is possible, but really hard.
This comment amazes me, I understand that I'm fairly old but I thought that around 2008 we got people away from using nested tables for layout to using semantic HTML + CSS because of accessibility (for humans accessing with different devices but even machines). I guess like the article says:
> Don’t forget that there is always someone new into the world of design and development. Hopefully this post steers others towards keeping HTML code semantic and clean.
Perhaps it's time to start linking to old A List Apart articles?
> ultimately it just really doesn't matter. nav and div render exactly the same.
More precisely, they render the same in common visual user agents.
It turns out the semantics can be distinct for other kinds of user agents. Accessibility is one context that matters. Intermediate UAs like search engines are another. Maybe voice browsing is going to take off with virtual assistants.
I think quite an important bit missing in sibling comments is web browsers and setups (in addition to screenreaders) other than the most popular ones. If an HTML document is composed as a document (i.e., using semantic markup, instead of focusing on exact visual representation), it has a decent chance to be usable in textual and lightweight browsers, and to look decently in mainstream browsers in a few years as well.
To get an illustration, one could browse WWW in such a browser (w3m, links, lynx, netsurf, etc), or even in FF with customizations, and/or browse web.archive.org (particularly websites from a decade or two ago) using a mainstream browser: basic HTML pages tend to be nice and accessible, while the ones using graphics, CSS (possibly optimized for 1024x768 or a similar resolution), and Flash/Java/JS/etc are usually a pain to get information from. I think most of the contemporary websites would produce a similar impression in another decade.
Another example where semantic markup matters is conversion into other formats.
This is all well and good but front end devs often don’t code semantically because frequently the designs we are asked to build aren’t idiomatic to the web. It’s less about wanting to use a div and more about not being able to style a frigging select box easily in a cross browser way (or add more advanced things like multi select and what have you...
In other words, our first concern is making things easy to change. The semantic web (at least some of it) just isn’t there yet.
I’ll finish by saying, that there are certain semantic elements that are safe to use. In that case, by all means.
I’ve found a pretty simple starting point for
testing the bones of a website by using the
following single line of CSS:
* {
border: 2px dotted black;
}
Another nice way to find obsolete elements is to simply type this in the console:
$$('*:only-child')
Elements with only one child usually can be optimized away. For example here on HN, it shows that every <code> element is wrapped in a <pre> element. I would think the same could be achieved by just setting the right styles on the <code> element.
That wouldn't necessarily be correct. <pre> is for preformatted. <code> is for code. The first tells the browser it's preformatted (which, to your point, is style related); the second tells you and the browser why that is -- it's code.
A poem might be a good example of something else you'd want to preformat.
Also, <pre> is a block element, while <code> is not.
The real issue is that there's something to be said about suggesting to write <pre class="code"> and <pre class="poem"> etc., or for that matter <pre type="whatever"> or simply <div class="whatever">. The real wtf here is that <code> has a special status in html while <poem> and other things that might want to be preformatted don't have their own tag. And that <pre> merely is a special type of <div> with some styling (which suits code just fine, but not poems) attached to it.
The author is arguing for semantic markup, but prior to HTML5 the concept barely existed. Everything was kludged together. Site layouts were tables. Later divs/spans ruled. Eventually sanity reigned and semantic elements were introduced.
So while I don't disagree with what they're saying, the title is a bit of a misnomer.
>[Don't] create tables built out of custom div elements
Tables aren't responsive. Those fancy div tables are used because they work better on mobile. With a splash of JS (or overly-clever CSS) you can also introduce interactivity, tabbed layouts, etc.
Unless dealing with a very small amount of tabular data, it's really hard to recommend tables anymore.
Otherwise, yeah, fair advice. Nothing really too controversial in there.
Semantic HTML was already fashionable in late 2004, when I was a graphic designer arguing against table tags. But my own exposure is a bad measure, just as is anyone else's. One of the most famous groups pushing for well-written HTML was WaSP, and it turns out that it was founded in 1998, https://en.wikipedia.org/wiki/Web_Standards_Project
HTML5 was honestly the opposite. XHTML and XHTML2 were born of a desire to have stricter, more semantic markup. But we live in the shitty timeline where XHTML2 died and we got HTML5 instead.
It would be more convincing if you had provided examples, why bad HTML practices are bad.
For using nav element good example is screen reader use, which will read all items if not using nav.
Custom form controls usually make developer life harder as they need to re-implement all functionality, that browser already provides with standard form elements. There was a good article about custom button implementation a while ago.
Building tables from divs and using "display: table" probably has been done to solve some complicated responsive layouts. I have no examples here.
Deep nesting usually makes debugging harder and sometimes leads to unclosed tags.
Javascript injection is usually a bad thing and you should prevent it with CSP.
Was I the only one who clicked this expecting React components for modern CSS layouts using markup like <img src="spacer.gif" width="390"> and <font color="red" face="Helvetica,Verdana" size="7"><b>Last Updated: June 1999</b></font> Otherwise you’re not writing HTML like it’s 1999, you’re writing HTML like it’s the web standards movement of the early 2000s before AJAX and Web 2.0 started trending.
If you really want to write HTML like it’s from 1999, read this blast from the past: https://www.w3.org/TR/2018/SPSD-html32-20180315/ Remember image maps? That’s real <nav> (which is HTML5 a decade later, iirc)
But to address the point of the article, you can use JS or backend code to enhance accessibility, such as by disabling focus on parts of a page when it should be disabled, or setting h1-h6 tag levels dynamically based on nested heading tags. If your aim is accessibility, this list may be useful: https://developers.google.com/web/fundamentals/accessibility...
While the spacer.gif made me really nostalgic, this is one of the things I don't miss.
However, layoutwise HTML is at the moment much like it had been in 1999: The basic structure with banner, nav, main, footer is much like the standard frameset, if there had only been role/landmark-markup for frames, and CSS-grid in its basic form is much like table-layout (less those Daliesque "poles" for positioning). Where there had been those fancy CMS templates with modular components, there are now frameworks… (However, JS is "a bit" more powerful and has grown out of `document.write()`.)
That said,landmarks and aria-markup are really a great deal when it comes to accessibility and are probably the most underrated additions to HTML.
InnerHTML arrived as a proprietary IE 4 feature and IE 4 launched in 1997, so yes. In Googling to double-check, I came across this little incompatibility: https://gist.github.com/jakearchibald/4489851
On the Netscape side of things innerHTML didn't arrive until NS Navigator 6.0. For Netscape's dynamic HTML model with NS 4.x, it was still a matter of opening a document stream and writing to it (`document.open()` … `document.write()` … `document.close()`), in this case the document of a layer or ilayer element (`document.layers[<layerName>].document`).
There was an interesting bug with `document.write()` in early versions of Netscape Navigator: If you wrote to table cell (td) or row (tr) code containing any embedding elements (like images or form elements) and there was adjacent whitespace around the script tags, the embedding elements (images) would show up twice. This was one of the more obscure bugs in the browser, which likely prohibited a broader use of `document.write()` with dynamic layouts etc at the time.
However, if you knew the quirks, you could load data objects in an invisible frame and render/update regions (frames or later layers) much like today.
What was initially setable: Beginning with NS 2.0 (JavaScript1.0) the state of form elements and window locations. Later (NS 3.0, 1996) also href and src attributes of images and anchors (links), the document title, and you could navigate the history, or call print() and find(), as well as manipulate a few other things, like keyboard focus. Of course there were event handlers, but they were quite specific for a few elements. (E.g., onclick or onmouseover were available for links and images only.) More complex interaction (including playing sound!) was possible via a proprietary Netscape Java/JS-bridge, called "LiveConnect".
Also: It's not just for blind people using screen readers; but also to improve end-to-end testing.
Yes, nowadays we hook into React components themselves, or even if not we can use those frameworks to strongly simplify writing selectors, because testing libraries have some magic built into them to use the component hierarchy directly...
... but depending on the amount of legacy and old in the app (and there will be legacy, and old stuff), and how strongly E2E you want to go (like "survive adding stuff from our team in that other city"), a "nav ul li[id='something']" will work ok for the developer maintaining the code, even if it is not the shortest possible selector; whereas a "div[...] div[...] div div + div" will catch up with you, even if you think you abstracted it away.
I didn’t find this particularly insightful, and disagree with many of the points made.
First of all the post is arguing for more semantic HTML and says nothing about using semantic HTML5 tags over <div>? AFAIK semantic tags didn’t even exist before HTML5 which is definitely not the 90s.
I also find using the <table> element generally be bad practice. There are much better/easier ways to build responsive tables using grid or flexbox than dealing with <tr>/<thead>/<td> everywhere.
> I also find using the <table> element generally be bad practice. There are much better/easier ways to build responsive tables using grid or flexbox than dealing with <tr>/<thead>/<td> everywhere.
Try using that monstrosity in a screen reader. You completely break vertical/column navigation. Hardly better.
Since the page is built on Jekyll, I'm guessing the article's HTML has been generated, thus explaining why paragraph tags are used.
Otherwise, one must explicitly use HTML to specify lists which is more laboriousa nd not as neat because of mixed content. In the end it works either way ¯\_(ツ)_/¯.
I think I get what you’re saying, but let me repeat it to make sure I understand: Jekyll, and of course Markdown, sites can use unordered lists, but you would need to specify explicit HTML for custom bullet points because there’s no obvious way to generate list elements with a specific class in Markdown.
That makes sense. I initially was confused because unordered lists themselves are very easy in Markdown, and indeed will generate <ol>s.
Really almost all of this comes down to, "don't use JavaScript to replace HTML". Everything else on this post derives from that one guideline. For example, "Implementing custom div layouts for forms while removing items like select or radio" is only possible if you're replacing native functionality with JavaScript.
Which is perfectly fine advice if you aren't doing anything really novel. You probably don't need a custom library for dropdowns or forms or whatever else and would gain performance, accessibility, and stability by hooking into the native versions instead.
The one part I disagree with is necessarily using <table> in place of divs with CSS Grid. The latter is native and is a perfectly legitimate replacement, with some added benefits like responsiveness.
Also the title is a bit of a misnomer, because lots of the HTML features that allow you to forego JavaScript are pretty recent:
> Content being heavily reliant on JavaScript “injection”
Salient point right here. Being served a blank white page (when JS is disabled) can deter a person from ever visiting a site again. Some peope out there want to vet a site before allowing it to run arbitrary code on their machine.
That's a bit of an exaggeration. JavaScript is strongly sandboxed and has a pretty good permissions system. The only malicious things it can really do are 1) based on cookies or 2) crypto mining.
Personally I think it's unreasonable to expect today's sites to work without JavaScript completely. The real benefits of using it sparingly are:
- Pages load faster
- Pages are more responsive
- Applications are less stateful and call out to systems that have a larger number of eyes on them, making them less fragile and lowering maintenance complexity
The microarchitectural side-channel attacks that have received a lot of attention lately really challenge the idea of a "sandbox".
Also the poster said that webpages shouldn't be blank without having, not that they should be fully functional. I think it's reasonable to expect some function without javascript.
3) Fingerprinting and tracking in general are heavily javascript-focused. Less common in practice (I assume), but still possible, are 4) Rowhammer or Spectre/Meltdown style attacks that break out of the permission system. Finally, there's general trickery, manipulation, and malware, like trying to embed a frame from Facebook and steal user credentials or so on (I'm fuzzy on these sorts of attacks, not an expert).
3) Right - and I guess "fingerprinting" goes slightly beyond cookies - but when people say "execute arbitrary code" they typically imply something has free-reign, which JavaScript generally doesn't.
4) True, although it's my understanding that the exploits are hard to implement, doubly-so from an abstracted layer like JavaScript.
> trickery, manipulation...like trying to embed a frame from Facebook and steal user credentials or so on
This falls under "cookies-based", and I'm pretty sure no JavaScript is necessary for these kinds of attacks.
I am split: web pages can be enhanced with JS, but webpage mostly shouldn't need them (exception: some data visualization does benefit from being able to dynamically change values).
Web apps on the other hand, probably do need them. I use newsblur and definitely enjoy the shortcuts.
Could've been different if web devs listened when they got told "your ads get overbearing, no one can even try to concentrate on the content anymore" - but they were greedy and ad blocking came about as self defense.
> The one part I disagree with is necessarily using <table> in place of divs with CSS Grid.
I suppose the soundness depends on how you read the word "table". For actual tabular data, <table> is probably the right choice for accessibility reasons. It's also why it's usually a bad idea to abuse tables for grid layouts in other cases.
If you want to write HTML like it's 1999 then you should use http://www.ihtml.com/ on the server side. I did. Somehow this didn't scare me away for life from web development. Somehow.
My biggest gripe with how modern html is written is not using <a> tags for link-like things. I often center click to open links in new tabs (Chrome and Firefox support this), but the way links have changed to <spans> with a listener attached that navigates to a new page--sometimes in a new window--really annoys me.
That's one of the underlying messages of this article. We're replacing elements with semantic meaning, such as <table>, with poorly implemented alternatives. Discarding <a> is part of that.
Some web designers just really want full control, even if that makes for a shoddy user experience.
So many people seemed to have forgotten what HTML in 1999 looked like. Layouts done with <table>s. Extreme <table> nesting to get layout just right. 1px spacer gifs everywhere. <font> tags. Very little CSS. Despair in the messiness of HTML and hope XHTML or whatever XML-based alternative was going to eat your lunch.
Semantic HTML only came back in the 2000s. Remember CSS Zen garden? Write HTML once and style it differently to achieve completely different looks. Even then, you had huge amount of CSS bugs. Like the voice-family hack or the
* > html
selector. Reading up on standards mode and quirks mode.
While I agree that semantic HTML is a nice thing, I am also confused because the HTML I saw in 1999 didn't look like what the author suggests. If I am not completely mistaken, nav is an HTML5 element that didn't even exist back then.
Instead, we used tables inside tables insides tables inside iframes to structure our navigations. CSS was still some mystic magic that only a few wizards knew how to use effectively. And in many cases, the result was actually less semantic than what we see nowadays.
So the arguments seem a bit odd, although I support the spirit of the message.
I guess there's some logic to that. If you want the ability to navigate within a website without restarting the music all the time, you need to implement some kind of hack. Back then, it was frames. Nowadays, it's SPAs.
I think clearly author was using "like it's 1999" as a metaphor, not literally.
It's a fairly common phrase (originating from a Prince song I think) that you can take to mean "like a throwback to a more authentic and possibly prior era." In this case the era is prior the explosion of frameworks and div soup.
Which strangely in this case is not necessarily prior but in parallel, as you said. This is English, it doesn't have to be precise like programming. You can use it for effect.
190 comments
[ 3.0 ms ] story [ 244 ms ] threadOr just use Firefox. The built in CSS-designer/debugger has a button to do just this on demand.
Browser-suggestions aside, I really agree with the sentiment of this article. That’s how I like to build sites and solutions when not forced to use some other framework or approach.
Good advice. Definitely sounds like captain obvious but it’s also something I think needs to be said.
I have never wanted anything other than this behaviour, so I pretty much always include it when starting on a fresh project.
<div style="padding: 8px; border: 1px solid black"> Block 1 </div>
<div style="padding: 8px;"> Block 2 </div>
https://jsfiddle.net/t4rkvfzx/
Anyway, agree with what’s being said here. K.I.S.S.
I think he’s advocating for semantic HTML, not 90s HTML
The idea isn't to pretend it's 1999 and only use stuff that works in netscape4/IE5, but to build pages in the same way as then. <nav> adds something useful - it helps screen readers out, but costs nothing.
Separately from how you want things to look (CSS), you shouldn't be putting content into `<table>` elements that aren't the sort of thing you'd put into a spreadsheet. That's not using HTML well. Keep in mind you can still use the table layout with other tags via CSS. Always wrap your content in the most-fitting tag HTML has, then worry about the layout after :D
If you are a front-end dev it's of course a no-brainer to keep up.
God I'm old.
1999 - Cool and Clever
2005 - Horrible
2010 - Horrible but sometimes necessary
2015 - Awesome
Huh, what happened?
You can place another service's elements on a page that look like they're actually part of the page layout while the JS running them can freely communicate with the service's backend without having to bother with cross domain problems.
Think of all the support/chat widgets you see on modern-day pages, they're all iframes.
And obviously: tracking all the things!
Obviously there are some benefits for screen readers and search engines, but these uses should be explicitly checked for as part of a QA process instead of relying on some vague standard of semanticness.
When an alternate display method comes out and wants my semantic html, I will add it to my QA workflow and make sure that it looks good instead of relying on some vague standard of semanticness from one of many bloggers.
Sure it's mostly black text on white backgrounds with only minor typesetting differences between elements but as a means to present information it has worked since the mid 1400s...
The more page authors use html 'properly', the more incentive there will be to improve systems like reader view.
This comment made me realize how relative everything is. It seems it was yesterday, when you would open Mosaic and slowly discover completely different worlds, one after another, and you'd never think of complaining HTML was aesthetically unpleasant...
It's for software reading the page and making use of the extra information, e.g. a screen reader being able to tell a user that there's a navigation element on the site and being able to jump there. Reader modes knowing what the main article on the page is. ...
(EDIT: I see you edited that point in, so yes, that's the main one, and IMHO a good enough one)
If you don't follow semantic html at all I don't see how QA can safe you, except for QA telling you to fix that <div> by replacing it with a <button> (or <div role="button">, or <a> or whatever you prefer).
At one point there was a kind of hope that semantic tags would make web content easily machine-parseable, unlocking a bunch of meaningful content reuse somehow that better semantics would make possible. (Big data, ML and all that.)
The two canonical examples being that lists were important so software could extract meaning from list items, and not using tables for layout so software could trust tables actually had meaningfully tabular data.
But... that never really happened, it's not clear it ever will, and it doesn't benefit the content author directly anyways, so... yeah.
(Like you say, screen readers are the main thing, so use the tags and attributes that are important to screen readers, like buttons and alt text... but that's a very specific subset. A screen reader certainly doesn't care if you use a <div> or an <li> or a <td>.)
Edit: I stand corrected on my example, for <td> specifically I forgot <table> lets screen readers navigate vertically and also read column/row labels.
In which current screen readers is that statement true? (I'm fairly sure the answer is "none", but ...)
It absolutely does. Try firing up a screen reader before you make such comments spreading misinformation.
For example, it's maddening to see people now making tables out of flexbox grids and such. In a screen reader you can navigate a <table> in two dimensions (rows and columns). The flexbox variety completely breaks navigating up/down columns.
You see this in all professions and without exception, from the exercise industry, to trades like plumbing, to healthcare and everything inbetween. Most of it is bullshit, process-based job security theater. Most major guilds just end up developing higher level cartel-like certification protections to keep them economically secured from competition.
I look at 'div soup' HTML and shudder. The authors of it have not got a clue. They also make it hard for people who do write proper HTML with the correct tags, styling the elements and keeping the separation of concerns to do anything with it.
It is about organising your content, if everything is in div tags you might as well just upload JPGs of your web pages, with different ones for desktop and mobile.
Another game changer is CSS grid. You no longer need wrapper divs to do very basic tasks such as centering content. In fact content with horrible divs everywhere is a nightmare to style up with CSS grid.
An example of this is a basic form. With just the form elements and labels you can get it looking sweet in next to no time with CSS grid.
However, if some zombie has put lots of spans and divs around the form elements and done the labels wrong then you have to choose either to rebuild the backend thing that churns out the form or just style it up lame block layout style.
Pseudo selectors are also cool, there is no need to have silly 'i' elements and spans to put that asterisk after 'required'.
Some people like to keep it simple, doing HTML properly, others want to pootle along with their divs and class attributes. I know what will look good in ten years time and what will look outdated.
HTML5 introduced many features but the main course was the semantic elements. You can and you should write web pages with these elements and also be thinking in terms of them.
You may scorn the accessibility aspect but accessibility is easy if you use the right elements. Why would you not want to have it? There is also the mindset that goes with it - the web is for everyone, not just rich, white, English speaking males with perfect eyesight.
The article is spot on and extremely well said. Styling elements rather than make believe classes is particularly well said.
I would say that people who create div soup HTML should be banned from the internets, the work practices of overly complicating everything has been going on for too long.
I don't even regard div soup web pages as proper web pages, it is like comparing beige deep-fried processed food with freshly prepared from ingredients food.
That was not so uncommon in 1999 :-(
Seriously, it's 2019 and some developers still don't get the value of semantic markup while this has been beaten to death for at least 20 years. this profession is cluttered with too many tourists. I even talk with devs bragging about the lack of care for markup.
Google don't care about HTML as they are way too clever for that. If I had more time I would like to see how they would rank two identical pages, one done properly and one that was a JPG image with a dangleberry of JSON-LD tacked on. I bet they latter would fare better!
After you've written the application? That makes absolutely no sense, unless you enjoy renaming lots of elements.
> instead of relying on some vague standard of semanticness
It's not vague, there is an actual international standard... WCAG!
Things like marking up addresses, phone numbers - as examples - means that a search engine can log a website as associated with a particular address, a browser can link to enable a number displayed to be called direct.
If for example there was a microformat (or other semantic markup) for opening times then SE/social sites could read and display (and update) that info without owners having to go on 20 sites if they change opening times.
Of course it can also help infer which parts of a page are advertising, or impressum, and not render that.
A plugin could offer to work on tables, or import them to a spreadsheet.
Lots of scope for advanced automations.
Using semantic HTML also helps search engine crawlers and other automated software understand the structure of your pages.
Browsers don't care. You may not care either. But people with disabilities attempting to make sense of your website do, very much so.
There's absolutely no reason __not__ to use semantic HTML, and many reasons to do so.
That doesn't mean you can't write accessible web applications without semantic HTML, but it does mean you have to spend time adding the accessibility after the fact.
* Set the correct aria attributes and roles for assistive technologies.
* Make the correct elements focusable, and order the focus correctly between elements, and add a specific style when then element is in focus.
* Capture the focus when appropriate but still allow focus to the URL bar.
* Set the correct key event handlers for keyboard navigation, submit events and triggers, validation events, etc. for assistive technologies, etc.
* Be prepared to warn users that your site will not work without javascript or in reader modes or in text based browsers, as well as make your site somewhat inaccessible for bots and crawlers.
And I’m sure I’m forgetting something. Point is, it is possible, but really hard.
> Don’t forget that there is always someone new into the world of design and development. Hopefully this post steers others towards keeping HTML code semantic and clean.
Perhaps it's time to start linking to old A List Apart articles?
- Sensible Forms: A Form Usability Checklist https://alistapart.com/article/sensibleforms/
- High Accessibility Is Effective Search Engine Optimization https://alistapart.com/article/accessibilityseo/
- A Brief History of Markup https://alistapart.com/article/a-brief-history-of-markup/
But even from this year:
- Conversations with Robots: Voice, Smart Agents & the Case for Structured Content https://alistapart.com/article/conversations-with-robots/
More precisely, they render the same in common visual user agents.
It turns out the semantics can be distinct for other kinds of user agents. Accessibility is one context that matters. Intermediate UAs like search engines are another. Maybe voice browsing is going to take off with virtual assistants.
To get an illustration, one could browse WWW in such a browser (w3m, links, lynx, netsurf, etc), or even in FF with customizations, and/or browse web.archive.org (particularly websites from a decade or two ago) using a mainstream browser: basic HTML pages tend to be nice and accessible, while the ones using graphics, CSS (possibly optimized for 1024x768 or a similar resolution), and Flash/Java/JS/etc are usually a pain to get information from. I think most of the contemporary websites would produce a similar impression in another decade.
Another example where semantic markup matters is conversion into other formats.
In other words, our first concern is making things easy to change. The semantic web (at least some of it) just isn’t there yet.
I’ll finish by saying, that there are certain semantic elements that are safe to use. In that case, by all means.
A poem might be a good example of something else you'd want to preformat.
Also, <pre> is a block element, while <code> is not.
The real issue is that there's something to be said about suggesting to write <pre class="code"> and <pre class="poem"> etc., or for that matter <pre type="whatever"> or simply <div class="whatever">. The real wtf here is that <code> has a special status in html while <poem> and other things that might want to be preformatted don't have their own tag. And that <pre> merely is a special type of <div> with some styling (which suits code just fine, but not poems) attached to it.
So while I don't disagree with what they're saying, the title is a bit of a misnomer.
>[Don't] create tables built out of custom div elements
Tables aren't responsive. Those fancy div tables are used because they work better on mobile. With a splash of JS (or overly-clever CSS) you can also introduce interactivity, tabbed layouts, etc.
Unless dealing with a very small amount of tabular data, it's really hard to recommend tables anymore.
Otherwise, yeah, fair advice. Nothing really too controversial in there.
Not really. The concept existed and was well known in many developer circles (e.g. List Apart Issue 268 from 2008 http://alistapart.com/issue/268/).
This article is from 2008, but I think it would be quite challenging to find something similar from 1999.
Oh yeah? Then what does Bootsttrap's table-responsive class do? The <table> tag can collapse just like any grid/flexbox mess.
From a cursory glance, it slaps a horizontal scrollbar on them.
If you really want to write HTML like it’s from 1999, read this blast from the past: https://www.w3.org/TR/2018/SPSD-html32-20180315/ Remember image maps? That’s real <nav> (which is HTML5 a decade later, iirc)
But to address the point of the article, you can use JS or backend code to enhance accessibility, such as by disabling focus on parts of a page when it should be disabled, or setting h1-h6 tag levels dynamically based on nested heading tags. If your aim is accessibility, this list may be useful: https://developers.google.com/web/fundamentals/accessibility...
However, layoutwise HTML is at the moment much like it had been in 1999: The basic structure with banner, nav, main, footer is much like the standard frameset, if there had only been role/landmark-markup for frames, and CSS-grid in its basic form is much like table-layout (less those Daliesque "poles" for positioning). Where there had been those fancy CMS templates with modular components, there are now frameworks… (However, JS is "a bit" more powerful and has grown out of `document.write()`.)
That said,landmarks and aria-markup are really a great deal when it comes to accessibility and are probably the most underrated additions to HTML.
Wasn't innerHTML still settable back then?
There was an interesting bug with `document.write()` in early versions of Netscape Navigator: If you wrote to table cell (td) or row (tr) code containing any embedding elements (like images or form elements) and there was adjacent whitespace around the script tags, the embedding elements (images) would show up twice. This was one of the more obscure bugs in the browser, which likely prohibited a broader use of `document.write()` with dynamic layouts etc at the time. However, if you knew the quirks, you could load data objects in an invisible frame and render/update regions (frames or later layers) much like today.
What was initially setable: Beginning with NS 2.0 (JavaScript1.0) the state of form elements and window locations. Later (NS 3.0, 1996) also href and src attributes of images and anchors (links), the document title, and you could navigate the history, or call print() and find(), as well as manipulate a few other things, like keyboard focus. Of course there were event handlers, but they were quite specific for a few elements. (E.g., onclick or onmouseover were available for links and images only.) More complex interaction (including playing sound!) was possible via a proprietary Netscape Java/JS-bridge, called "LiveConnect".
Yes, nowadays we hook into React components themselves, or even if not we can use those frameworks to strongly simplify writing selectors, because testing libraries have some magic built into them to use the component hierarchy directly...
... but depending on the amount of legacy and old in the app (and there will be legacy, and old stuff), and how strongly E2E you want to go (like "survive adding stuff from our team in that other city"), a "nav ul li[id='something']" will work ok for the developer maintaining the code, even if it is not the shortest possible selector; whereas a "div[...] div[...] div div + div" will catch up with you, even if you think you abstracted it away.
First of all the post is arguing for more semantic HTML and says nothing about using semantic HTML5 tags over <div>? AFAIK semantic tags didn’t even exist before HTML5 which is definitely not the 90s.
I also find using the <table> element generally be bad practice. There are much better/easier ways to build responsive tables using grid or flexbox than dealing with <tr>/<thead>/<td> everywhere.
Try using that monstrosity in a screen reader. You completely break vertical/column navigation. Hardly better.
Otherwise, one must explicitly use HTML to specify lists which is more laboriousa nd not as neat because of mixed content. In the end it works either way ¯\_(ツ)_/¯.
That makes sense. I initially was confused because unordered lists themselves are very easy in Markdown, and indeed will generate <ol>s.
Funny enough, only changing the body's background color to "lightgrey" and the font face to "serif" makes it look exactly like that.
Which is perfectly fine advice if you aren't doing anything really novel. You probably don't need a custom library for dropdowns or forms or whatever else and would gain performance, accessibility, and stability by hooking into the native versions instead.
The one part I disagree with is necessarily using <table> in place of divs with CSS Grid. The latter is native and is a perfectly legitimate replacement, with some added benefits like responsiveness.
Also the title is a bit of a misnomer, because lots of the HTML features that allow you to forego JavaScript are pretty recent:
https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Fo...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/In...
Salient point right here. Being served a blank white page (when JS is disabled) can deter a person from ever visiting a site again. Some peope out there want to vet a site before allowing it to run arbitrary code on their machine.
That's a bit of an exaggeration. JavaScript is strongly sandboxed and has a pretty good permissions system. The only malicious things it can really do are 1) based on cookies or 2) crypto mining.
Personally I think it's unreasonable to expect today's sites to work without JavaScript completely. The real benefits of using it sparingly are:
- Pages load faster
- Pages are more responsive
- Applications are less stateful and call out to systems that have a larger number of eyes on them, making them less fragile and lowering maintenance complexity
Minimalism is a virtue in any programming context
Also the poster said that webpages shouldn't be blank without having, not that they should be fully functional. I think it's reasonable to expect some function without javascript.
4) True, although it's my understanding that the exploits are hard to implement, doubly-so from an abstracted layer like JavaScript.
> trickery, manipulation...like trying to embed a frame from Facebook and steal user credentials or so on
This falls under "cookies-based", and I'm pretty sure no JavaScript is necessary for these kinds of attacks.
And a crappy end user experience. Why do I need to execute code just to read a static, read-only text article?
We now live in a post-Spectre world. I don't think a sandbox means all it meant in 2017.
Web apps on the other hand, probably do need them. I use newsblur and definitely enjoy the shortcuts.
I suppose the soundness depends on how you read the word "table". For actual tabular data, <table> is probably the right choice for accessibility reasons. It's also why it's usually a bad idea to abuse tables for grid layouts in other cases.
> It's also why it's usually a bad idea to abuse tables for grid layouts in other cases.
This isn't so much about semantics, it's about the way it kills responsiveness
Some web designers just really want full control, even if that makes for a shoddy user experience.
Semantic HTML only came back in the 2000s. Remember CSS Zen garden? Write HTML once and style it differently to achieve completely different looks. Even then, you had huge amount of CSS bugs. Like the voice-family hack or the
selector. Reading up on standards mode and quirks mode.Instead, we used tables inside tables insides tables inside iframes to structure our navigations. CSS was still some mystic magic that only a few wizards knew how to use effectively. And in many cases, the result was actually less semantic than what we see nowadays.
So the arguments seem a bit odd, although I support the spirit of the message.
FTFY
It's a fairly common phrase (originating from a Prince song I think) that you can take to mean "like a throwback to a more authentic and possibly prior era." In this case the era is prior the explosion of frameworks and div soup.
Which strangely in this case is not necessarily prior but in parallel, as you said. This is English, it doesn't have to be precise like programming. You can use it for effect.