Live data from Hacker News

Tags to make HTML work like you expect

blog.jim-nielsen.com

171–180 of 248 posts

Re: Tags to make HTML work like you expect

#171
post #23

Earlier quoted context omitted.

Implicit elements and end tags have been a part of HTML since the very beginning. They introduce zero ambiguity to the language, they’re very widely used, and any parser incapable of handling them violates the spec and would be incapable of handling piles of real‐world strict, standards‐compliant HTML. > I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient.…

I didn't have a problem with XHTML back in the day; it tool a while to unlearn it; I would instinctively close those tags: , etc. It actually the XHTML 2.0 specification [1] that discarded backwards compatibility with HTML 4 was the straw that broke the camel's back. No more forms as we knew them, for example; we were supposed to use XFORMS. That's when WHATWG was formed and broke with the W3C and created HTML5. Than…

XHTML 2.0 had a bunch of good ideas and a lot of them got "backported" into HTML 5 over the years.

XHTML 2.0 didn't even really discard backwards-compatibility that much: it had its compatibility story baked in with XML Namespaces. You could embed XHTML 1.0 in an XHTML 2.0 document just as you can still embed SVG or MathML in HTML 5. XForms was expected to take a few more years and people were expecting to still embed XHTML 1.0 forms for a while into XHTML 2.0's life.

At least from my outside observer perspective, the formation of WHATWG was more a proxy war between the view of the web as a document platform versus the view of the web as an app platform. XHTML 2.0 wanted a stronger document-oriented web.

(Also, XForms had some good ideas, too. Some of what people want in "forms helpers" when they are asking for something like HTMX to standardized in browsers were a part of XForms such as JS-less fetch/XHR with in-place refresh for form submits. Some of what HTML 5 slowly added in terms of INPUT tag validation are also sort of "backports" from XForms, albeit with no dependency on XSD.)

Re: Tags to make HTML work like you expect

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

Which is also largely what happened: HTML 5 is in some ways that "best-effort" mode, standardized by a different standards body to route around XHTML's philosophies.

Re: Tags to make HTML work like you expect

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

[deleted]

Re: Tags to make HTML work like you expect

#174
post #153

Earlier quoted context omitted.

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.

Language detection (where “language”== one of the 200 languages that are actually used), IS trivial, given a paragraph of text.

And the fact is that the author of the web page doesn’t know the language of the content, if there’s anything user contributed. Should you have to label every comment on HN as “English”? That’s a huge burden on literally every internet user. Other written language has never specified its language. Imposing data-entry requirements on humans to satisfy a computer is never the ideal solution.

Re: Tags to make HTML work like you expect

#175

I'm not a web developer, so if someone can please enlighten me: Why does this site, and so many "modern" sites like it have it so that the actual content of the site takes up only 20% of my screen? My browser window is 2560x1487. 80% of the screen is blank. I have to zoom in 170% to read the content. With older blogs, I don't have this issue, it just works. Is it on purpose or it is it bad css? Given the title of the…

This site was designed many moons ago, for another age. That's both a blessing and a curse, but much more of a blessing. As you've found, you can fix the zoom.

It's rare to see a site as popular as HN which has made almost zero changes to the UI over its entire history.

Re: Tags to make HTML work like you expect

#176

I'm not a web developer, so if someone can please enlighten me: Why does this site, and so many "modern" sites like it have it so that the actual content of the site takes up only 20% of my screen? My browser window is 2560x1487. 80% of the screen is blank. I have to zoom in 170% to read the content. With older blogs, I don't have this issue, it just works. Is it on purpose or it is it bad css? Given the title of the…

Your pixels are too small. Enable system scaling for high dpi screens.

Re: Tags to make HTML work like you expect

#177

> ` ` 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 keyboar…

Isn't that what "en" on its own should be, though?

Re: Tags to make HTML work like you expect

#178

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)

> Note that and auto-close and don't need to be terminated.

You monster.

Re: Tags to make HTML work like you expect

#179

Earlier quoted context omitted.

You'll notice newspapers use columns and do not extend the text all the way left to right either. It's a typographical consideration, for both function and style. From a functional standpoint: Having to scan your eyes left to right a far distance to read makes it more uncomfortable. Of course, you could debate this and I'm sure there are user preferences, but this is the idea behind limiting the content width. From a…

Newspapers have less than 5% margin for whitespace. they're smart enough to have multiple columns. It's also a side-effect of how every line costs money and they need to cramp as much content as possible in one page. I get not having read all the way to the end and back, I even get having margins, but it should be relative to the screen size. Fixed width is the issue I think. To avoid paragraphs looking too thin, may…

You're not wrong. Increasing font size is one method.

Another method I like to use is to adjust the amount of words per paragraph depending on the medium. I will literally write more or less just to attain my personal favorite of 3-6 visual lines per paragraph.

Or sometimes I will more readily join paragraphs or split them more often in a text just to achieve my target.

Decreasing width is actually just really easy and also works really well when the type of content can vary.

All of this seems like some serious overkill attention to detail I know, but I guess it's a big deal for some people. For example, most people don't really care about dressing nice regularly anymore when they get older and marry because it frankly doesn't matter anymore (and they're totally right), but people who like fashion still care up until the end.

Re: Tags to make HTML work like you expect

#180
post #26

width=device-width is actually redundant and cargo culting. All you need is initial-scale. I explain in a bit more detail here: https://news.ycombinator.com/item?id=36112889

I've read your post. I'm going to test this on some crappy devices this week to confirm and then update my boilerplate.
Post reply on HN