Live data from Hacker News

Tags to make HTML work like you expect

blog.jim-nielsen.com

141–150 of 248 posts

Re: Tags to make HTML work like you expect

#141

I know this was a joke: but I feel there is a last tag missing: ... that will ensure screenreaders skip all your page "chrome" and make life much easier for a lot of folks. As a bonus mark any navigation elements inside main using (or role="navigation").

>I know this was a joke I'm…missing the joke – could someone explain, please? Thank you.

Not a front end engineer but I imagine this boilerplate allows the JavaScript display engine of choice to be loaded and then rendered into that DIV rather than having any content on the page itself.

Re: Tags to make HTML work like you expect

#142
post #59

Earlier quoted context omitted.

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

No kidding. I've set the zoom level so long ago that I never noticed, but if I reset it on HN the text letters use about 2mm of width in my standard HD, 21" display.

> but if I reset it on HN the text letters use about 2mm of width in my standard HD, 21" display.

1920x1080 24" screen here, .274mm pitch which is just about 100dpi. Standard text size in HN is also about 2mm across, measured by the simple method of holding a ruler up to the screen and guessing.

If you can't read this, you maybe need to get your eyes checked. It's likely you need reading glasses. The need for reading glasses kind of crept up on me because I either work on kind of Landrover-engine-scale components, or grain-of-sugar-scale components, the latter viewed down a binocular microscope on my SMD rework bench and the former big enough to see quite easily ;-)

Re: Tags to make HTML work like you expect

#143

Earlier quoted context omitted.

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

Are you misunderstanding on purpose? I am aware they are optional. I am arguing that there is no reason to omit them from your HTML. Whitespace is (mostly) optional in C, does that mean it's a good idea to omit it from your programs? Of course a br tag needs no closing tag because there is no content inside it. How exactly is that an argument for omitting the closing p tag? The XML standard has no relevance to the current discussion because I'm not arguing for "starting to treat it like XML".

Re: Tags to make HTML work like you expect

#144
post #59

Earlier quoted context omitted.

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

Please don’t. HN has just the right information density with its small default font size. In most browsers it is adjustable. And you can pinch-zoom if you’re having trouble hitting the right link. None of the ”content needs white space and large fonts to breathe“ stuff or having to click to see a reply like on other sites. That just complicates interactions. And I am posting this on an iPhone SE while my sight has st…

Content does need white space.

HN has a good amount of white space. Much more would be too much, much less would be not enough.

Re: Tags to make HTML work like you expect

#145
post #137

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?

Because there are multiple doctypes you can use. The same reason "varx" is not valid and must be written "var x".

Re: Tags to make HTML work like you expect

#147
post #96

Earlier quoted context omitted.

Please don’t. HN has just the right information density with its small default font size. In most browsers it is adjustable. And you can pinch-zoom if you’re having trouble hitting the right link. None of the ”content needs white space and large fonts to breathe“ stuff or having to click to see a reply like on other sites. That just complicates interactions. And I am posting this on an iPhone SE while my sight has st…

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…

You're obviously being sarcastic, but I don't think that it's a given that "those are old font-size defaults" means "those are bad font-size defaults." I like the default HN size. There's no reason that my preference should override yours, but neither is there any reason that yours should override mine, and I think "that's how the other sites are" intentionally doesn't describe the HN culture, so it need not describe the HN HTML.

Re: Tags to make HTML work like you expect

#148

I know this was a joke: but I feel there is a last tag missing: ... that will ensure screenreaders skip all your page "chrome" and make life much easier for a lot of folks. As a bonus mark any navigation elements inside main using (or role="navigation").

>I know this was a joke I'm…missing the joke – could someone explain, please? Thank you.

It's because "modern" web developers are not writing web pages in standard html, css or js. Instead, they use javascript to render the entire thing inside a root element.

This is now "standard" but breaks any browser that doesn't (or can't) support javascript. It's also a nightmare for SEO, accessibility and many other things (like your memory, cpu and battery usage).

But hey, it's "modern"!

Re: Tags to make HTML work like you expect

#149

Earlier quoted context omitted.

This kind of thing will always just feel shoddy to me. It is not much work to properly close a tag. The number of bytes saved is negligible, compared to basically any other aspect of a website. Avoiding not needed div spam already would save more. Or for example making sure CSS is not bloated. And of course avoiding downloading 3MB of JS. What this achieves is making the syntax more irregular and harder to parse. I w…

> I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. Who would want to use a browser which would prevent many currently valid pages from being shown?

I mean, I am obviously talking about a fictive scenario, a somewhat better timeline/universe. In such a scenario, the shoddy practices of not properly closing tags and leaning on leniency in browser parsing and sophisticated fallbacks and all that would not have become a practice and those many currently valid websites would mostly not have been created, because as someone tried to create them, the browsers would have told them no. Then those people would revise their code, and end up with clean, easier to parse code/documents, and we wouldn't have all these edge and special cases in our standards.

Also obviously that's unfortunately not the case today in our real world. Doesn't mean I cannot wish things were different.

Re: Tags to make HTML work like you expect

#150
post #59

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

Setting aside the relative merits of 12pt vs 16pt font, websites ought to respect the user's browser settings by using "rem", but HN (mostly[1]) ignores this.

To test, try setting your browser's font size larger or smaller and note which websites update and which do not. And besides helping to support different user preferences, it's very useful for accessibility.

[1] After testing, it looks like the "Reply" and "Help" links respect large browser font sizes.

Post reply on HN