Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You don't get HTML. Neither do I. A couple years back there was a well-received "semantic HTML" submission here. I was in the small minority wondering how come `<div class="button">` is better semantics than `<button>`.


This page is a pretty convincing argument for why <button> is the right element: https://www.buttoncheatsheet.com/


It's not quite right though. You need

    <button type=button
if you don't want it to have submit semantics (including submitting the containing form if you happen to have it in one).


And this thread right here is why we can't have truly semantic HTML, and why the thing most people tout as "semantic HTML" today... isn't.


I've come to think the error in semantic HTML is that humans think there's a difference between "button" and "ceqnej"... but there isn't. Something has to actually define the difference. Computers don't care.

Where can I get this definition and apply it to my program?

There isn't one.

The browser knows what a <button> is, but it knows a lot of other things. <button> isn't particularly special.

I still have to explain it to any program I may write, and it's no skin off my nose to explain it what a "button" is, or a <div class="button">, or a <div class="ceqnej">. If I don't speak English that's what button looks like anyhow.

What I can get for my program is a specification of HTML and a compliant parser. But that provides extremely weak "semantics".

"Semantic HTML" is a cognitive illusion brought about by looking at 62 75 74 74 6F 6E and conflating your human read of those bytes with real meaning.

(There is value to using nice-looking HTML... but the value is for humans, and has more to do with principles of software engineering and data organization and virtually nothing to do with "semantics".)


XML would be truly semantic




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: