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

231–240 of 248 posts

Re: Tags to make HTML work like you expect

#231

Post by janwillemb »

spc476 wrote: post #187
janwillemb wrote: post #134

Earlier quoted context omitted.

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.

Such questions can be jarring though. I remember my "Unix Systems Programming" class in college. It's a third year course. The instructor was describing the layout of a process in memory, "here's the text segment, the data segment, etc." when a student asked, "Where do the comments go?"

:) true. I'm a teacher myself. I never dismiss questions, but I do get discouraged sometimes.

Re: Tags to make HTML work like you expect

#232

Post by reactordev »

5- wrote: post #196
reactordev wrote: post #106

Earlier quoted context omitted.

Overall I would agree but I also agree with the above commenter. It’s ok for mobile but on a desktop view it’s very small when viewed at anything larger than 1080p. Zoom works but doesn’t stick. A simple change to the font size in css will make it legible for mobile, desktop, terminal, or space… font-size:2vw or something that scales.

> Zoom works but doesn’t stick. perhaps try using a user agent that remembers your settings? e.g. firefox

Perhaps not recommend workarounds to lack of utilizing standards.

Re: Tags to make HTML work like you expect

#233

Post by haskellshill »

recursive wrote: post #204
haskellshill wrote: post #185

Earlier quoted context omitted.

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, yo…

Again, you're focusing on a pointless detail. Sure, I made a mistake in offhandedly using li as an example. Why do you choose to ignore the actually valid p example though? Seems like you're more interested in demonstrating your knowledge of HTML parsing (great job, proud of ya) than anything else. Either way, you've given zero examples of benefits of not doing things the sensible way that most people would expect.

Re: Tags to make HTML work like you expect

#234

Post by wonger_ »

notepad0x90 wrote: post #167
harrall wrote: post #161

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…

For font size that increases with screen size, you can use some clamp() math, like:

  --step-0: clamp(1.125rem, 1.0739rem + 0.2273vw, 1.25rem);
Taken from https://utopia.fyi/type/calculator?c=360,18,1.2,1240,20,1.25...

Re: Tags to make HTML work like you expect

#235

Post by sgarland »

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

I hesitate to want any changes, but I could maybe get behind dynamic font sizing. Maybe.

On mobile it’s fine, on Mac with a Retina display it’s fine; the only one where it isn’t is a 4K display rendering at native resolution - for that, I have my browser set to 110% zoom, which is perfect for me.

So I have a workaround that’s trivial, but I can see the benefit of not needing to do that.

Re: Tags to make HTML work like you expect

#236

Post by sgarland »

recursive wrote: post #133
haskellshill wrote: post #127

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…

IMO, all of those make logical sense. If you’re inserting a line break or literal line, it can be thought of as a 1-dimensional object, which cannot enclose anything. If you want another one, insert another one.

In contrast, paragraphs and lists do enclose content, so IMO they should have clear delineations - if nothing else, to make visually understanding the code more clear.

I’m also sure that someone will now reference another HTML attribute I didn’t think about that breaks my analogy.

Re: Tags to make HTML work like you expect

#237

Post by chrismorgan »

zelphirkalt wrote: post #14
xg15 wrote: post #5

Earlier quoted context omitted.

There is some irony in then-Facebook's proprietary metadata lines being in there (the "og:..." lines). Now with their name being "Meta", it looks even more proprietary than before. Maybe the name was never about the Metaverse at all...

Are they proprietary? How? Isn't open graph a standard and widely implemented by many parties, including many open source softwares?

The Open Graph Protocol was thrown over the wall by Facebook and promptly abandoned. It’s an atrocious spec, a good chunk of what it did (and most of what people actually wanted from it) was already unnecessary (og:description, for example, is stupid), its data model makes several woefully bad choices, it’s firmly based around Facebook’s interests (especially pictures!), it’s built on standards that were already looking like they were failing and are definitely long abandoned now, and I don’t think I’ve seen a single page implementing OGP tags correctly in the last five years and I’m not confident that a strictly correct reader implementation even exists (the specific matter I have in mind pertains to the prefix attribute). Also a bunch of key URLs have been 404ing for many years now.

Re: Tags to make HTML work like you expect

#238

Post by mb2100 »

bitbasher wrote: post #148
petecooper wrote: post #130

Earlier quoted context omitted.

>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"!

This. But hey, let's work on swinging the pendulum of technology back while keeping the DX. I'm doing that with https://mastrojs.github.io/

Re: Tags to make HTML work like you expect

#239

Post by recursive »

haskellshill wrote: post #233
recursive wrote: post #204

Earlier quoted context omitted.

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, yo…

Again, you're focusing on a pointless detail. Sure, I made a mistake in offhandedly using li as an example. Why do you choose to ignore the actually valid p example though? Seems like you're more interested in demonstrating your knowledge of HTML parsing (great job, proud of ya) than anything else. Either way, you've given zero examples of benefits of not doing things the sensible way that most people would expect.

To (hopefully) be clear, I don't think there are many benefits either way.

Re: Tags to make HTML work like you expect

#240

Post by janwillemb »

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…

This comment contains a few logical fallacies.

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

This dismisses existing explanations without engaging with the mentioned reasons. The following text then doesn't provide any arguments for this.

> Pronunciation is either solved by a) automatic language detection, or b) doesn't matter.

There are more possibilities than a and b. For example, it may matter for other things than pronunciation only. Also it may improve automatic detection or make automatic detection superfluous.

> If I am reading a book [...] 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.

A generalization of your own experience to all users and systems. Screen readers aim to convey information accessibly, not mirror human ignorance.

> There's no reason that the screen reader will get it wrong, because isn't ambiguous

This is circular reasoning. The statement is based on the assumption that automatic detection is always accurate - which is precisely what is under debate.

> If you can translate it, you already know what language it is in.

This a non sequitur. Even if someone can translate text, that doesn't mean software or search engines can automatically identify that language.

> The lang attribute adds nothing to the proces.

This absolute claim adds nothing to the logic.

Post reply on HN