Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write HTML Like It's 1999

bradleytaunt.com

Post reply on HN
Print view View original

51–60 of 191 posts

Re: Write HTML Like It's 1999

#51

Post by kungtotte »

woah wrote: post #29
LocalH wrote: post #22

Earlier quoted context omitted.

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 so…

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

Re: Write HTML Like It's 1999

#52

Post by jeena »

burgerzzz wrote: post #25

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

Re: Write HTML Like It's 1999

#53

Post by tomhoad »

woah wrote: 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.

> explicitly checked for as part of a QA process

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!

Re: Write HTML Like It's 1999

#54

Post by pbhjpbhj »

woah wrote: 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.

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.

Lots of scope for advanced automations.

Re: Write HTML Like It's 1999

#55

Post by walshemj »

vikingcaffiene wrote: post #41

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

id settle for front end devs not abusing flipping h tags

Re: Write HTML Like It's 1999

#56

Post by mjw1007 »

woah wrote: post #29
LocalH wrote: post #22

Earlier quoted context omitted.

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 so…

Firefox's reader view is a realistic system that lets us consume html pages without their original CSS.

The more page authors use html 'properly', the more incentive there will be to improve systems like reader view.

Re: Write HTML Like It's 1999

#57

Post by mdtusz »

trnglina wrote: post #12
whalesalad wrote: post #3

Instead of a border I tend to have a debug helper that adds a 1px outline of cyan or pink. To get the “bones” of a component or page. Good advice. Definitely sounds like captain obvious but it’s also something I think needs to be said.

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.

* { box-sizing: border-box; }

I have never wanted anything other than this behaviour, so I pretty much always include it when starting on a fresh project.

Re: Write HTML Like It's 1999

#58

Post by no_gravity » 

    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 be achieved by just setting the right styles on the  element.

Re: Write HTML Like It's 1999

#59

Post by wwweston »

burgerzzz wrote: post #25

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…

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

Re: Write HTML Like It's 1999

#60

Post by defanor »

burgerzzz wrote: post #25

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

Post reply on HN