Live data from Hacker News

Write HTML Like It's 1999

bradleytaunt.com

61–70 of 191 posts

Re: Write HTML Like It's 1999

#61
post #52

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…

It's always a good time to link to "A List Apart".

Re: Write HTML Like It's 1999

#62
post #18

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.

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…

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.

Re: Write HTML Like It's 1999

#63
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.

Re: Write HTML Like It's 1999

#64
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.

Re: Write HTML Like It's 1999

#65
post #34

Earlier 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.

It gets you 90% of the way there.

Re: Write HTML Like It's 1999

#66

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 element is wrapped in a element. I would think the same could b…

That wouldn't necessarily be correct.
 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

#67
post #39

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…

> 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.

Maybe I don't care about people with disabilities in the same way that I don't care about people using IE6.

Re: Write HTML Like It's 1999

#68
Was I the only one who clicked this expecting React components for modern CSS layouts using markup like and Last Updated: June 1999 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 (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

#69

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.

Agree. Is it a Jekyll theme or some totally customized template?

Might be backed by this: https://github.com/bradleytaunt/accssible?

Re: Write HTML Like It's 1999

#70
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.

Post reply on HN