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

151–160 of 248 posts

Re: Tags to make HTML work like you expect

#151

Post by torstenvl »

rob wrote: post #96
ano-ther wrote: post #88

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…

Don't do this.

Re: Tags to make HTML work like you expect

#152

Post by super256 »

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

Really? I find the font very nice on my Pixel XL. It doesn't take too much space unlike all other modern websites.

Re: Tags to make HTML work like you expect

#153

Post by bilkow »

flymasterv wrote: post #136
janwillemb wrote: post #125

Earlier quoted context omitted.

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…

Your whole comment assumes language identification is both trivial and fail-safe. It is neither and it can get worse if you consider e.g. cases where the page has different elements in different languages, different languages that are similar.

Even if language identification was very simple, you're still putting the burden on the user's tools to identify something the writer already knew.

Re: Tags to make HTML work like you expect

#154

Post by ifwinterco »

recursive wrote: post #128
imiric wrote: post #60

Earlier quoted context omitted.

I'll copy what I wrote a few days ago: The fact XHTML didn't gain traction is a mistake we've been paying off for decades. Browser engines could've been simpler; web development tools could've been more robust and powerful much earlier; we would be able to rely on XSLT and invent other ways of processing and consuming web content; we would have proper XHTML modules, instead of the half-baked Web Components we have to…

There's no way it could have gained traction. Consider two browsers. One follows the spec explicitly, and one goes into "best-effort" mode on encountering invalid markup. End users aren't going to care about the philosophical reasoning for why Browser A doesn't show them their school dance recital schedule. Consider JSON and CSV. Both have formal specs. But in the wild, most parsers are more lenient than the spec.

Yeah this is it. We can debate what would be nicer theoretically until the cows come home but there's a kind of real world game theory that leads to browsers doing their best to parse all kinds of slop as well as they can, and then subsequently removing the incentive for developers and tooling to produce byte perfect output

Re: Tags to make HTML work like you expect

#155

Post by layer8 »

shiomiru wrote: post #72
layer8 wrote: post #52

Earlier quoted context omitted.

While true, they also require user agents to support other encodings specified that way: https://html.spec.whatwg.org/multipage/parsing.html#characte... Another funny thing here is that they say “but not limited to” (the listed encodings), but then say “must not support other encodings” (than the listed ones).

It says > the encodings defined in Encoding, including, but not limited to where "Encoding" refers to https://encoding.spec.whatwg.org (probably that should be a link.) So it just means "the other spec defines at least these, but maybe others too." (e.g. EUC-JP is included in Encoding but not listed in HTML.)

Ah, I understood it to refer to encoding from the preceding section.

Re: Tags to make HTML work like you expect

#156

Post by somat »

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…

On that subject I would be fine if the browser always rendered in standard mode. or offered a user configuration option to do so.

No need to have the default be compatible with a dead browser.

further thoughts: I just read the mdn quirks page and perhaps I will start shipping Content-Type: application/xhtml+xml as I don't really like putting the doctype in. It is the one screwball tag and requires special casing in my otherwise elegant html output engine.

Re: Tags to make HTML work like you expect

#157

Post by rob »

torstenvl wrote: post #151
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…

Don't do this.

I agree, don't set the default font size to ~12px equiv in 2025.

Re: Tags to make HTML work like you expect

#158

Post by embedding-shape »

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

> At quick glance, it looks like they're still using the same CSS that was made public ~13 years ago:

It has been changed since then for sure though. A couple of years ago the mobile experience was way worse than what it is today, so something has clearly changed. I think also some infamous "non-wrapping inline code" bug in the CSS was fixed, but can't remember if that was months, years or decades ago.

On another note, they're very receptive to emails, and if you have specific things you want fixed, and maybe even ideas on how to do in a good and proper way, you can email them (hn@ycombinator.com) and they'll respond relatively fast, either with a "thanks, good idea" or "probably not, here's why". That has been my experience at least.

Re: Tags to make HTML work like you expect

#159

Post by childintime »

brianzelip wrote: post #73

> ` ` The author might consider instead: ` `

It's time for an "en-INTL" (or similar) for international english, that is mostly "en-US", but implies a US-International keyboard and removes americanisms, like Logical Punctuation in quotes [1]. Then AI can start writing for a wider and much larger public (and can also default to regular ISO units instead of imperial baby food).

Additionally, it's kind of crazy we are not able to write any language with any keyboard, as nowadays we just don't know the idiom the person who sits behind the keyboard needs.

[1] https://slate.com/human-interest/2011/05/logical-punctuation...

Re: Tags to make HTML work like you expect

#160

Post by recursive »

haskellshill wrote: post #143
recursive wrote: post #133

Earlier quoted context omitted.

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

I'm beginning to think I'm misunderstanding, but it's not on purpose.

Including closing tags as a general rule might make readers think that they can rely on their presence. Also, in some cases they are prohibited. So you can't achieve a simple evenly applied rule anyway.

Post reply on HN