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 d…
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 tow…
Write HTML Like It's 1999
61–70 of 191 posts
Re: Write HTML Like It's 1999
#62I'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.
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 p…
Re: Write HTML Like It's 1999
#63So 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.
Re: Write HTML Like It's 1999
#64Re: Write HTML Like It's 1999
#65Earlier quoted context omitted.
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.
I understand writing semantic HTML helps with accessibility, but it is by no means a silver bullet.
Re: Write HTML Like It's 1999
#66I’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 element is wrapped in a element. I would think the same could b…
is for preformatted. 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,
is a block element, while is not.The real issue is that there's something to be said about suggesting to write and etc., or for that matter or simply . The real wtf here is that has a special status in html while and other things that might want to be preformatted don't have their own tag. And that merely is a special type of with some styling (which suits code just fine, but not poems) attached to it.
Re: Write HTML Like It's 1999
#67Don'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 d…
> I find zero value in using ul/li's for lists that aren't bulleted 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.
Re: Write HTML Like It's 1999
#68If 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 (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...
Re: Write HTML Like It's 1999
#69My 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.
Agree. Is it a Jekyll theme or some totally customized template?
Re: Write HTML Like It's 1999
#70Yes, 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.