I usually add:
Tags to make HTML work like you expect
201–210 of 248 posts
Re: Tags to make HTML work like you expect
#202Fun 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...
The font size is perfect for me, and I hope it doesn’t get a “usability update”.
Re: Tags to make HTML work like you expect
#203Fun 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...
Text size is easily fixed in your browser with the zoom setting. Chrome will remember the level you use on a per site basis if you let it.
Re: Tags to make HTML work like you expect
#204Earlier quoted context omitted.
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.
Well, just because something is allowed by the syntax does not mean it's a good idea, that's why pretty much every language has linters. And I do think there's an evenly applied rule, namely: always explicitly close all non-void elements. There are only 14 void elements anyway, so it's not too much to expect readers to know them. In your own words "there's no substitute for actually knowing the real rules". I mean, y…
I don't believe there are any contexts where is valid that would also be valid.
I'm not opposed to closing tags as a general a general practice. But I don't think it provides as much benefit as you're implying. Valid HTML has a number of special rules like this. Like different content parsing rules for and . Like "foreign content".
If you try to write lint-passing HTML in the hopes that you could change to easily, you still have to contend with the fact that such a change cannot be valid, except possibly as a direct descendant of .
Re: Tags to make HTML work like you expect
#205Earlier 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…
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.…
XHTML in practice was too strict and tended to break a few other things (by design) for better or worse, so nobody used it...
That said, actually writing HTML that can be parsed via an XML parser is generally a good, neighborly thing to do, as it allows for easier scraping and parsing through browsers and non-browser applications alike. For that matter, I will also add additional data-* attributes to elements just to make testing (and scraping) easier.
Re: Tags to make HTML work like you expect
#206Re: Tags to make HTML work like you expect
#207Earlier 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...
The font size is perfect for me, and I hope it doesn’t get a “usability update”.
“I don’t see any reason to accommodate the needs of others because I’m just fine”
Re: Tags to make HTML work like you expect
#208I usually add: which gives you a nice automatic dark theme "for free"
Ah this is a good one! I should maybe start considering this as a default...
Re: Tags to make HTML work like you expect
#209Anyone else prefer to use web components without bundling? I probably should not admit this, but I have been using Lit Elements with raw JavaScript code. Because I stopped using autocomplete awhile ago. I guess not using TypeScript at this point is basically the equivalent for many people these days of saying that I use punch cards.
Stopped using autocomplete ? I want to hear more about this.
I could never.
Re: Tags to make HTML work like you expect
#210TFA 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…
For anyone else furiously going back and forth between TFA and this comment: they mean the actual website of TFA has these errors, not the content of TFA.