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

Tags to make HTML work like you expect

blog.jim-nielsen.com

Post reply on HN
Print view View original

131–140 of 248 posts

Re: Tags to make HTML work like you expect

#131

Post by tannhaeuser »

Aransentin wrote: post #4

Note that and auto-close and don't need to be terminated. Also, wrapping the tags in an actual is optional. You also don't need the quotes as long the attribute doesn't have spaces or the like; is OK. (kind of pointless as the average website fetches a bazillion bytes of javascript for every page load nowadays, but sometimes slimming things down as much as possible can be fun and satisfying)

Not only do html and body auto-close, their tags including start-element tags can be omitted alltogether:

    Shortest valid doc
    
Body text following here
(cf explainer slides at [1] for the exact tag inferences SGML/HTML does to arrive at the fully tagged doc)

[1]: https://sgmljs.sgml.net/docs/html5-dtd-slides-wrapper.html (linked from https://sgmljs.sgml.net/blog/blog1701.html)

Re: Tags to make HTML work like you expect

#132

Post by ryeights »

Izkata wrote: post #113
rob wrote: post #96

Earlier quoted context omitted.

Yeah, I'm really asking for tons of whitespace and everything to breathe sooooo much by asking for the default font size to be a browser default (16px) and updated to match most modern display resolutions in 2025, not 2006 when it was created. HN is the only site I have to increase the zoom level, and others below are doing the same thing as me. But it must be us with the issues. Obviously PG knew best in 2006 for de…

On the flipside, HN is the only site I don't have to zoom out of to keep it comfortable. Most sit at 90% with a rare few at 80%. 16px is just massive.

Sounds like your display scaling is a little out of whack?

Re: Tags to make HTML work like you expect

#133

Post by recursive »

haskellshill wrote: post #127
recursive wrote: post #123

Earlier quoted context omitted.

It sounds like you're headed towards XHTML. The rise and fall of XHTML is well documented and you can binge the whole thing if you're so inclined. But my summarization is that the reason it doesn't work is that strict document specs are too strict for humans. And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner.

The merits and drawbacks of XHTML has already been discussed elsewhere in the thread and I am well aware of it. > And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner. Yes, my point is that there is no reason to still write "invalid" code just because it's supported for backwards compatibility reasons. It sounds like you ignored 90% of…

I'm a stickling pedant for HTML validity, but close tags on

and are optional by spec. Close tags for
, , and are prohibited. XML-like self-closing trailing slashes explicitly have no meaning in XML.

Close tags for are required. But if people start treating it like XML, they write . But that fails, because the script element requires closure, and that slash has no meaning in XML.

I think validity matters, but you have to measure validity according to the actual spec, not what you wish it was, or should have been. There's no substitute for actually knowing the real rules.

Re: Tags to make HTML work like you expect

#134

Post by janwillemb »

troupo wrote: post #13
hlava wrote: post #7

It's 2025, the end of it. Is this really necessary to share?

Every day you can expect 10000 people learning a thing you thought everyone knew: https://xkcd.com/1053/ To quote the alt text: "Saying 'what kind of an idiot doesn't know about the Yellowstone supervolcano' is so much more boring than telling someone about the Yellowstone supervolcano for the first time."

Thanks! I didn't know that one.

I had a teacher who became angry when a question was asked about a subject he felt students should already be knowledgeable about. "YOU ARE IN xTH GRADE AND STILL DON'T KNOW THIS?!" (intentional shouting uppercase). The fact that you learned it yesterday doesn't mean all humans in the world also learned it yesterday. Ask questions, always. Explain, always.

Re: Tags to make HTML work like you expect

#135

Post by wpollock »

I appreciate this post! I was hoping you would add an inline CSS style sheet to take care of the broken defaults. I only remember one off the top of my head, the rule for monospace font size. You need something like:

   code, pre, tt, kbd, samp {
     font-family: monospace, monospace;
   }
But I vaguely remember there are other broken CSS defaults for links, img tags, and other stuff. An HTML 5 boilerplate guide should include that too, but I don't know of any that do.

Re: Tags to make HTML work like you expect

#136

Post by flymasterv »

janwillemb wrote: post #125
flymasterv wrote: post #104

I still don’t understand what people think they’re accomplishing with the lang attribute. It’s trivial to determine the language, and in the cases where it isn’t, it’s not trivial for the reader, either.

Doesn't it state this in the article? > Browsers, search engines, assistive technologies, etc. can leverage it to: > - Get pronunciation and voice right for screen readers > - Improve indexing and translation accuracy > - Apply locale-specific tools (e.g. spell-checking)

It states the cargo culted reasons, but not the actual truth.

1) Pronounciation is either solved by a) automatic language detection, or b) doesn't matter. If I am reading a book, and I see text in a language I recognize, I will pronounce it correctly, just like the screen reader will. If I see text in a language I don't recognize, I won't pronounce it correctly, and neither will the screen reader. There's no benefit to my screen reader pronouncing Hungarian correctly to me, a person who doesn't speak Hungarian. On the off chance that the screen reader gets it wrong, even though I do speak Hungarian, I can certainly tell that I'm hearing english-pronounced hungarian. But there's no reason that the screen reader will get it wrong, because "Mit csináljunk, hogy boldogok legyünk?" isn't ambiguous. It's just simply Hungarian, and if I have a Hungarian screen reader installed, it's trivial to figure that out.

2) Again, if you can translate it, you already know what language it is in. If you don't know what language it is in, then you can't read it from a book, either.

3) See above. Locale is mildly useful, but the example linked in the article was strictly language, and spell checking will either a) fail, in the case of en-US/en-UK, or b) be obvious, in the case of 1) above.

The lang attribute adds nothing to the process.

Re: Tags to make HTML work like you expect

#137

Post by 9029 »

dinkelberg wrote: post #102

TFA itself has an incorrect DOCTYPE. It’s missing the whitespace between "DOCTYPE" and "html". Also, all spaces between HTML attributes where removed, although the HTML spec says: "If an attribute using the double-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two." ( https://html.spec.whatwg.org/multipage/syntax.html#attribute... ) I guess the brows…

Maybe a dumb question but I have always wondered, why does the (authoring?) spec not consider e.g. "doctypehtml" as valid HTML if compliant parsers have to support it anyway? Why allow this situation where non-compliant HTML is guaranteed to work anyway on a compliant parser?

Re: Tags to make HTML work like you expect

#138

Post by nikeee »

jraph wrote: post #32

> is what you want for consistent rendering. Or if you prefer writing markup like it’s 1998. Or even if you eschew all societal norms. It’s case-insensitive so they’ll all work. And if you want polyglot (X)HTML.

I tend to lower-case all my HTML because it has less entropy and therefore can be compressed more effectively.

But in case of modern compression algorithms, some of them come with a pre-defined dictionary for websites. These usually contain the common stuff like in its most used form. So doing it like everybody else might even make the compression even more effective.

Re: Tags to make HTML work like you expect

#139

Post by [deleted] »

rob wrote: post #59
aragonite wrote: post #29

Fun fact: both HN and (no doubt not coincidentally) paulgraham.com ship no DOCTYPE and are rendered in Quirks Mode. You can see this in devtools by evaluating `document.compatMode`. I ran into this because I have a little userscript I inject everywhere that helps me copy text in hovered elements (not just links). It does: [...document.querySelectorAll(":hover")].at(-1) to grab the innermost hovered element. It works…

I wish `dang` would take some time to go through the website and make some usability updates. HN still uses a font-size value that usually renders to 12px by default as well, making it look insanely small on most modern devices, etc. At quick glance, it looks like they're still using the same CSS that was made public ~13 years ago: https://github.com/wting/hackernews/blob/5a3296417d23d1ecc90...

[deleted]

Re: Tags to make HTML work like you expect

#140

Post by zamadatix »

rob wrote: post #59
aragonite wrote: post #29

Fun fact: both HN and (no doubt not coincidentally) paulgraham.com ship no DOCTYPE and are rendered in Quirks Mode. You can see this in devtools by evaluating `document.compatMode`. I ran into this because I have a little userscript I inject everywhere that helps me copy text in hovered elements (not just links). It does: [...document.querySelectorAll(":hover")].at(-1) to grab the innermost hovered element. It works…

I wish `dang` would take some time to go through the website and make some usability updates. HN still uses a font-size value that usually renders to 12px by default as well, making it look insanely small on most modern devices, etc. At quick glance, it looks like they're still using the same CSS that was made public ~13 years ago: https://github.com/wting/hackernews/blob/5a3296417d23d1ecc90...

12 px (13.333 px when in the adapted layout) is a little small - and that's a perfectly valid argument without trying to argue we should abandon absolute sized fonts in favor of feels.

There is no such thing as a reasonable default size if we stop calibrating to physical dimensions. If you choose to use your phone at a scaling where what is supposed to be 1" is 0.75" then that's on you, not on the website to up the font size for everyone.

Post reply on HN