I also looked it up in Chicago Manual of Style, and one thing I remember is, you want to get your hands on an earlier edition (for geek fun) because they have much more detail about typesetting than they do in later editions. (I don't know what the edition sweetspot is but I found a 1930's copy and I liked it)

>mostly amused that Guido van Rossum...wanted web browsers to collapse multiple spaces to a single space...Python...treats whitespace as significant.

this is actually pretty funny, thank you

Anyway, I never used double spaces after periods. My typing teacher would always give me grief for it, but for whatever reason, I just never did it. As you can see, I still don't.

I don't think we can. Or can we?

    <span class="commtext c00">The period at the end of this sentence is followed by six spaces.      I bet we won't be able to see them.</span>

Interesting, given that I specifically sought out typing class in high school in the late '70s because I was confident that there was going to be a lot of keyboard usage in my future, might as well learn to use it.

And I don't want to hear whinging about subtle mechanical keyboard differences. When you learn at an under-funded rural school with manual typewriters, you also learn to appreciate anything that isn't making your fingers do mechanical printing. :-)

Those would be trailing spaces, not the whitespace Python considers significant (indentation).

http://1997.webhistory.org/www.lists/www-talk.1993q2/index.h...

> I would like to specify that multiple spaces be interpreted as such

The response is only

> Isn't it a violation of the SGML philosophy

This seems more relevant:

> spaces and tabs at the starts of lines are ignored, and extra space after punctuation is handled separately

http://1997.webhistory.org/www.lists/www-talk.1993q2/0470.ht...

No. It works the way I described.

>No. It works the way I described.

what you described made reference to white-space: normal which is a CSS property that I don't believe is available as part of the HTML standard itself (although I don't really keep up anymore so I could be wrong) but certainly wasn't part of older versions of the spec.

Copy and paste my comment somewhere, delete the parenthetical, and then read the result to yourself.

"HTML [...] treats all whitespace as insignificant" is simply inaccurate, no matter how you want to constrain it (e.g. "in older versions" or not). Whitespace is not insignificant.

1. <https://pchiusano.github.io/2014-10-11/defensive-writing.htm...>

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.

> HTML specifies to ignore any extraneous whitespace and simply collapse it into a single space[...] Outside of that and a few special cases, the default behavior is to ignore whitespace

No it doesn't, and it's not. What you're describing is how the browser displays the content. (And a few other things—like interactions when you select text to drag and drop or copy it to the clipboard.)

> building a website in PHP[...] 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

You keep saying "HTML" when you mean something else. In almost every instance if you just said "the browser" (broadly) instead, then you'd be good, but you keep saying "HTML".

There are absolutely parts of the browser that don't care whether they're seeing one space or a thousand varied whitespace characters (tabs, carriage returns, linefeeds, etc), because based on what style properties are in effect at that place the browser will be presenting that content to the user as if there's one space character when laying it out and putting it on screen. But the only whitespace that gets ignored in HTML, really, is the whitespace inside angle brackets around attributes and element names.

Your string metaphor is a good one. Content marked up with HTML is like one big string, and as you say, no one would expect whitespace in a string to be insignificant. It's not insignificant in HTML, either; it does, by default, get painted as if sequences of multiple whitespace characters were a single space, in most contexts. But again, that's a separate thing entirely.

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.

  $ dump ./scratch/p.html
  3c 70 3e 20 20 0a 20 20 49 27 6d 20 61 20 74 65
   <  p  >        .        I  '  m     a     t  e
  78 74 20 6e 6f 64 65 20 5b 20 20 20 20 5d 20 20
   x  t     n  o  d  e     [              ]      
  20 20 3c 2f 70 3e 0a
         <  /  p  >  .

The text node's value is exactly the sequence of characters between the closing angle bracket in `<p>` and the opening angle bracket in `</p>`:

  "  \n  I'm a text node [    ]    "

You're right about the second half, but you're wrong in thinking that it says extra whitespace should be ignored. It doesn't. The bigger problem, though, is in the first half.

I think you have an oversimplified understanding of what's going on in a browser and of the relationship that HTML has to what you see when the browser paints the content on the screen and lets you interact with it; a fundamental misunderstanding seems to exist on your part regarding the pipeline that you do or don't think of as existing between the markup and what you actually get when you open the page in a browser—there's a lot more to it than the browser being "merely the interpreter" for HTML.

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

Offhand, and after a few glasses of wine, there are a couple points where the whitespace collapse will occur:

- at the display level—when it's time for the browser to actually put the thing on the screen—for CSS contexts where the white-space property is "normal" or something similar, at least, or

- at the interaction level, when something like text selection happens, and the browser computes essentially the equivalent of node.innerText (versus node.textContent; alternatively: node.nodeValue, in cases where the node in question is a text node)

It does so by collapsing any amount of space into single INDENT and DEDENT tokens, so I'm not sure what the irony is supposed to be. If the last line started with 8 spaces, Python will not distinguish between the next line starting with 10 spaces and the next line starting with 50.

For example, here is some Python code typed correctly in the comment box but rendered without the code formatting support (using a | at beginning of line to prevent the code formatting to kick in):

|def foo(flag):

| if flag:

| print("this is indented")

| print("is this?")

If you check the HTML, it looks like this:

  <p>|def foo(flag):</p>
  <p>|    if flag:</p>
  <p>|       print("this is indented")</p>
  <p>|    print("is this?")</p>

It is not hard. Just use the right tag. You want the <pre> tag here. Here, fixed it for you:

  def foo(flag):
      if flag:
         print("this is indented")
      print("is this?")

Perhaps I misunderstood your comment, but this is quite wrong. If I have a block that's indented at 8 spaces, and the next line is 10 spaces, but should be in the same block, it will definitely throw an IndentationError.

In the same scenario, Python does not distinguish between (the next line starting with 10 spaces), which produces an INDENT token, and (the next line starting with 50 spaces), which produces the same INDENT token. The amount of whitespace isn't relevant. All that matters is the comparison between one line and the previous line.

> I think it's mostly propaganda by Knuth and Kernighan (TeX and troff) that makes people want this.

> Let's keep HTML simple!

was unexpected. Knuth as propaganda!

The discussion noted some O’Reilly books sentence-spaced, and layout software had different levels of support with TeX notably supporting it. And that’s the key: it’s a typographical layout choice. For document input, for writers, it’s a matter of markup for the output typographical layout not double-spacing per se. It’s an aesthetic choice only, similar to the spacing we add between letters, around punctuation etc.

So the question is not, should we support double spacing, but: should we support this sentence spacing typographical technique?

Because double spaces are an hack used to achieve layout they should not be necessary, but word processors not supporting it leads to people implementing it themselves. (If you’re a product manager, this is the sort of thing you spot to indicate a missing feature.)

It gets worse on the web: because most white space is collapsed together the double-space trick doesn’t work, and it’s _very_ hard to do in CSS.

Marc Andreessen’s 1993 comment ‘how is a text widget supposed to know where a sentence ends and where it doesn't? That sort of syntactic analysis we can't do...’: yes, it’s hard. English parsing is hard. Other languages are hard. I don’t believe that’s a reason not to do it any more.

My website has sentence spacing [1] in CSS as a purely aesthetic choice based on a technique by Tom Fine [2, 3]. And it’s automated: I run the site text, single-spaced, through a Python script that understands sentences and marks up sentence spacing.

[1] https://daveon.design/about-dave-on-design.html#typography-&...

[2] https://hea-www.harvard.edu/~fine/Tech/html-sentences.html

[3] http://widespacer.blogspot.com/

The bold and italics look like they’re being applied in browser though, rather than specific faces.

And it’s calling out for some small caps for acronyms like ‘HTML’.

Nice to see sites with this style, it’s very rare nowadays!

Yes, both bold and italic are being applied by the browser, and I do need to fix that. Italic is a temporary choice because I don't like the look of EB Garamond (the current text font) in its italic face, and need to find an alternative. Bold, though, is not intentional. I've noticed the macOS and iOS stacks mimic bold differently, which is an interesting thing to have found.

Excellent point re allcaps for acronyms. Should be pretty easy to add to the site generator. Thanks for the suggestion :)

That HTML collapses multiple spaces is a feature, not a bug. It means you can, if you want, double-space sentences while authoring/editing your source files and the result will still come out “correct” (according to settled practice).

With respect, that's an incorrect assertion. I have books on my shelf published up through the eighties with wider spacing between sentences. A more accurate comment might be that in the modern design era, and I'd guess this is approximately post-WW2 onwards, sentence spacing shrank and it is now common not to. That clarification is true.

How do I know? I like wider sentence spacing (see my comment above on this thread) and have kept an eye out for it in books when I buy them.

I suspect it was computers that killed wide sentence spacing: the web, as seen in the linked discussion thread, combined with word processors that weren't as capable as TeX and didn't support it. Here we are thirty years later and it's become the absolute norm, so much we can barely imagine an alternative. But I regret that technical decisions and limitations have left us in this position.

If it helps I do think the eighties one, and I wish I could remember what it was, was indeed an outlier. I’d actually love to track down the O’Reilly’s books mentioned in the linked thread.

The fact that the exchange is recorded is magnificent to me. We don't have a written dialogue of the guys who decided to start putting spaces in English words in the first place...

https://en.wikipedia.org/wiki/Scriptio_continua