HN user

slowwriter

287 karma
Posts7
Comments70
View on HN
TruffleRuby 4 months ago

Someone replied to his final tweets and ended with “#ChatGPT response”. It seems like the most sad and dystopian thing to me.

I got 19/20. Turned off True Tone and cranked the screen brightness. Half the time I didn’t know if it was just my eyes playing tricks on me, but it was interesting to notice how the colors seemed completely indiscernible for a few seconds and then suddenly one stood out.

I see. Don’t know if you’re still checking for replies on this thread. Livin’ up to my name. Thanks for taking the time to explain, though.

I’m going to have to look further into this to get a better understanding, but I suppose the rules for collapsing whitespace in a text node exist somewhere in the HTML specification, but not at the “interpretation” stage as I assumed.

To be clear what I imagined was that at the interpretation stage a text node would be marked to begin at the first non-whitespace character and end at the last non-whitespace character. And then within the text node there might be additional whitespace that would need to be collapsed into a single space.

Since the first type is not rendered at all and the second type is collapsed to a single space I assumed the rules could exist at two different points in the process/pipeline.

So what I gather here is that both types exist at a later stage than “interpretation” (basically what you see when you open Developer Tools and inspect individual nodes).

But I guess the subtlety here is that at whichever stage the whitespace collapsing/removal happens, the rules for it would still have to be defined by the HTML specification somehow.

And another subtlety to counteract that is that HTML is a markup language and not a programming language. One is executed, one is rendered. So any comparison between say Python and HTML needs to take that into account.

So even though there is some whitespace ignoring going on at some point from:

<p>[whitespace]This textnode has extraneous whitespace[whitespace]</p>

To the point where [whitespace] is not rendered in the viewport, the fact that the ignoring does not happen at the “interpretation” stage is important because that’s as far as the comparison between say Python and HTML can go before the two veer off in different directions.

I’m mainly typing this out for my own understanding, but again, will have to look into it myself to validate or correct my current framework of thinking about this. Thanks for an interesting discussion

I don’t understand your distinction between “the browser” and “HTML” in this context. The browser is merely the interpreter of the language, but the HTML specification lays out how the language should be interpreted.

Also, this is an example of whitespace that is ignored:

<p>[whitespace here]I’m a text node[more whitespace here]</p>

I don’t believe that is what you referred to when you said “inside angle brackets around attributes and element names”.

Here the whitespace or sequence of spacelike characters is not collapsed into a single space. It is simply ignored, and the text node (string) begins at the first non-whitespace character.

That is actually what I referred to when I said that you end up adding a lot of extra whitespace when building a website in, say, PHP. Because that is where it typically ends up in the generated output.

Let me be clear about what I meant by whitespace insignificance.

When you put plain text into an element, that is equivalent to a string in typical programming terms. No, whitespace is not entirely insignificant within a text node. But almost. If we leave out <pre> and other special cases here, HTML specifies to ignore any extraneous whitespace and simply collapse it into a single space. So it is “extraneous whitespace insignificant” in a sense. It doesn’t ignore whitespace interely, but no one would expect that in the contex of a string in any language, even a whitespace insignificant one.

In a text node HTML goes out of it’s way to minimize the meaning of whitespace, but it does do the minimum of respecting that words have spaces between them. You can put spaces some places and have it break or change stuff, like in the middle of an attribute name or value, in the middle of an element name, etc. But you would expect that to happen in any whitespace insignificant language. Outside of that and a few special cases, the default behavior is to ignore whitespace (for example whitespace between the beginning or ending tag of an element and the text node it contains), and as such HTML is very much whitespace insignificant in my opinion.

The reason why I commented that this design was absolutely the right call is basically cases like building a website in PHP, where you mix the two languages together. Here you end up adding a lot of whitespace from indenting your code, etc., and it would be a nightmare if HTML didn’t treat whitespace as it does.

I entirely agree that the explanation in the article is somewhat confusing, because we're selecting 3 items starting from #3 in a list, counting both from the top and the bottom. So which of those three options does the 3 stand for?

The very first demo in the MDN doc for :nth-last-child helped me understand: https://developer.mozilla.org/en-US/docs/Web/CSS/:nth-last-c... – just change the "-n + 3" to "n + 3" to match the example in the article.

In that case the selector starts at the third element from the bottom and ends at the top element, matching a total of 6 elements.

In situations where someasks "so you're saying that..." followed by something they didn't say it might very well be on purpose, but in other cases being explicit about how you understood someone can allow them to elaborate and correct your understanding.

It's much better than just continuing the conversation under a false assumption.