12 ms·

I'm not quite sure how to interpret your last comment. You prefer the IE box model? Or you're saying they did it right from the get go? Because quirks mode was

I'm not quite sure how to interpret your last comment. You prefer the IE box model? Or you're saying they did it right from the get go? Because quirks mode was abandoned and everyone uses the Moz/W3C model now. A better example would be file line endings, where Microsoft did get it right (\r\n) and all the other OS's screwed up using just \r or \n.

niftich 9y ago
The W3C box model became standard and IE was criticized for its quirky noncompliant behavior [1], but then many years later 'box-sizing: border-box' was introduced and widely praised and adopted by frameworks [2][3]; it's funny how things change. [1] https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bu... [2] https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing [3] https://css-tricks.com/international-box-sizing-awareness-day/ https://css-tricks.com/international-box-sizing-awareness-da...
- gsnedders 9y ago
  > then many years later 'box-sizing: border-box' was introduced and widely praised and adopted by frameworks Well, IE implemented their version of the box model in '97 (coincidently, NN4 did the same); the box-sizing property was first proposed in 1999[1], and first appeared in a draft in 1999[2], and implemented in Gecko in 1999[3] and in IE5/Mac in 2000[4]. That's two years from IE/NN shipping the non-standard box model (the standard one was defined before IE4 and NN4 shipped) to having a property to toggle between them. To me, that isn't "many years". Really what makes it seem like many years is the fact that IE didn't implement box-sizing until IE8 which shipped in 2009. [1]: https://lists.w3.org/Archives/Member/w3c-css-wg/1999JanMar/0201.html https://lists.w3.org/Archives/Member/w3c-css-wg/1999JanMar/0... (sorry, W3C MO space, but I think at this point nobody cares if I mention that publicly) [2]: https://www.w3.org/TR/1999/WD-css3-userint-19990916#box-sizing https://www.w3.org/TR/1999/WD-css3-userint-19990916#box-sizi... [3]: https://github.com/mozilla/gecko/commit/3ee32d59158a036bd6673c72ed29b137f1fa78bb https://github.com/mozilla/gecko/commit/3ee32d59158a036bd667... [4]: http://tantek.com/notes/csssupport.html http://tantek.com/notes/csssupport.html
- dtech 9y ago
  IE's box model always felt much more natural. The problem was that the exact same CSS would result in widely different layouts in most browsers. IE was stupid to not implement the spec, the spec was stupid for not doing it the way IE did.
aktau 9y ago
Now I'm curious. How is \r\n more right than \n or \r? In which situations? Advantages? Disadvantages?
- ptaipale 9y ago
  If you send it in raw format to a Teletype, it'll print correctly... Other than that, I don't see it being any more right. But it is a convention that is far older than Windows or MS-DOS. I saw it myself first on CP/M but it was there on VAX/VMS and I expect the Teletypes had it from 1960's.
  - JdeBP 9y ago
    It's not that simple. In the 1960s operating systems such as Multics existed, which even then had the idea of device independence. So the end of line sequence as far as Multics applications were concerned was a single LF, whatever the terminal type. The operating system was in charge of converting that to whatever the terminal actually needed. Multics was following the standards of the time, moreover. As the ASCII standard of the time explicitly allowed an LF could denote both a Line Feed and a Carriage Return (and indeed any padding delay characters too) in a single character if the system decided to employ single character encodings. * H. McGregor Ross (1964-01-01). "The I.S.O. character code". DOI 10.1093/comjnl/7.3.197. The Computer Journal. Volume 7, Issue 3. pp. 197–202. * Jerome H. Saltzer and J. F. Ossanna (1970). "Remote terminal character stream processing in Multics." DOI 10.1145/1476936.1477030. Proceedings of the AFIPS Conference 36. pp. 621-627. * https://unix.stackexchange.com/questions/411811/ https://unix.stackexchange.com/questions/411811/
    - ptaipale 9y ago
      I tried to say that it was not so simple. Yes, obviously Multics had the LF line end convention. Some systems saved files internally in a record format so the line end was whatever what the software decided to print out there. But mostly I was just reacting to the silly idea that CRLF would be right and lone LF not: Microsoft didn't come up with that idea. It was there already in 1960's and perhaps useful when you didn't want to do any line drivers for converting strings at output. But that's not really any more "right" than other conventions.
johnchristopher 9y ago
> I'm not quite sure how to interpret your last comment. You prefer the IE box model? Or you're saying they did it right from the get go? Because quirks mode was abandoned and everyone uses the Moz/W3C model now. It's worse than that. His position was: MS's understanding and implementation of the box model is the correct interpretation of the W3C specs (yeah, I know).
Stratoscope 9y ago
Interesting that you find \r\n to be "right" and the others "screwed up". I'm curious about the reasons for that. The biggest problem is that each OS went its own way (Mac started with \r but of course uses \n now). If they all had the same line ending all along, whatever it was, no one would think much about it. \r\n has the obvious disadvantage of being twice the size, along with making it possible to land in the middle of a line ending instead of before or after one. Of course one advantage would be if you're controlling physical equipment where carriage return and line feed are independent of each other. I learned to program in 1968 on a Teletype ASR33 where CR and LF were literal commands to return the carriage to column 1 and advance the paper. You had to use both because they did two different things. Or on occasion you might use CR by itself to overprint a line. LF by itself was pretty rare, but would do what you expect if you used it: advance the paper without moving the print carriage. CR LF was fine if you were typing interactively - in fact you just had to hit the CR key and the remote system would provide the LF. But usually we would punch our programs on paper tape, dial in, run the tape through and get the printout, and hang up right away. At $30/hour in 1968 dollars, this saved a lot of money. And of course you would run your tape through locally to print out and proofread your program before testing it online. To be able to print a tape locally, you needed both CR and LF, but even that wasn't quite adequate. You really wanted to allow a little extra time for the machinery to settle, so the standard line ending we punched on a tape was CR LF RUBOUT. RUBOUT was a character that punched out all the holes in a row of the paper tape. It was ignored by convention, so you could erase a typing error when punching a tape by pushing the backspace button on the tape punch and hitting the RUBOUT key. Because it was ignored, RUBOUT was also useful as a "delay" character in the newline sequence. So I guess I'll never get over the feeling that the One True Line Ending is: \r\n\x7F (Nah, I'm happy with \n, but it makes a good story.)
- walshemj 9y ago
  Could have been something that came from DEC as the original NT was influenced by VAX systems (which often had LA120's as consoles) I seem to recall.
  - diffuse_l 9y ago
pedasmith 9y ago
In the old days, we knew to either open a file in text mode (where whatever the OS had would be converted to a single \n) or in binary mode (where it wouldn't, and you had to deal with the conversion yourself). IMHO, what SHOULD happen is that if you have a device that has special timing requirements (like the old fashioned printers with no memory), then the driver is responsible for the handling the timing. Adding in weird bits to everyone's files is a bad idea. And yes, I know the difference between carriage-return and new-line. And I know that in the old C specs, "\n" didn't have a guaranteed mapping to either.

niftich 9y ago

The W3C box model became standard and IE was criticized for its quirky noncompliant behavior [1], but then many years later 'box-sizing: border-box' was introduced and widely praised and adopted by frameworks [2][3]; it's funny how things change. [1] https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bu... [2] https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing [3] https://css-tricks.com/international-box-sizing-awareness-day/ https://css-tricks.com/international-box-sizing-awareness-da...

gsnedders 9y ago
> then many years later 'box-sizing: border-box' was introduced and widely praised and adopted by frameworks Well, IE implemented their version of the box model in '97 (coincidently, NN4 did the same); the box-sizing property was first proposed in 1999[1], and first appeared in a draft in 1999[2], and implemented in Gecko in 1999[3] and in IE5/Mac in 2000[4]. That's two years from IE/NN shipping the non-standard box model (the standard one was defined before IE4 and NN4 shipped) to having a property to toggle between them. To me, that isn't "many years". Really what makes it seem like many years is the fact that IE didn't implement box-sizing until IE8 which shipped in 2009. [1]: https://lists.w3.org/Archives/Member/w3c-css-wg/1999JanMar/0201.html https://lists.w3.org/Archives/Member/w3c-css-wg/1999JanMar/0... (sorry, W3C MO space, but I think at this point nobody cares if I mention that publicly) [2]: https://www.w3.org/TR/1999/WD-css3-userint-19990916#box-sizing https://www.w3.org/TR/1999/WD-css3-userint-19990916#box-sizi... [3]: https://github.com/mozilla/gecko/commit/3ee32d59158a036bd6673c72ed29b137f1fa78bb https://github.com/mozilla/gecko/commit/3ee32d59158a036bd667... [4]: http://tantek.com/notes/csssupport.html http://tantek.com/notes/csssupport.html
dtech 9y ago
IE's box model always felt much more natural. The problem was that the exact same CSS would result in widely different layouts in most browsers. IE was stupid to not implement the spec, the spec was stupid for not doing it the way IE did.

aktau 9y ago

Now I'm curious. How is \r\n more right than \n or \r? In which situations? Advantages? Disadvantages?

ptaipale 9y ago
If you send it in raw format to a Teletype, it'll print correctly... Other than that, I don't see it being any more right. But it is a convention that is far older than Windows or MS-DOS. I saw it myself first on CP/M but it was there on VAX/VMS and I expect the Teletypes had it from 1960's.
- JdeBP 9y ago
  It's not that simple. In the 1960s operating systems such as Multics existed, which even then had the idea of device independence. So the end of line sequence as far as Multics applications were concerned was a single LF, whatever the terminal type. The operating system was in charge of converting that to whatever the terminal actually needed. Multics was following the standards of the time, moreover. As the ASCII standard of the time explicitly allowed an LF could denote both a Line Feed and a Carriage Return (and indeed any padding delay characters too) in a single character if the system decided to employ single character encodings. * H. McGregor Ross (1964-01-01). "The I.S.O. character code". DOI 10.1093/comjnl/7.3.197. The Computer Journal. Volume 7, Issue 3. pp. 197–202. * Jerome H. Saltzer and J. F. Ossanna (1970). "Remote terminal character stream processing in Multics." DOI 10.1145/1476936.1477030. Proceedings of the AFIPS Conference 36. pp. 621-627. * https://unix.stackexchange.com/questions/411811/ https://unix.stackexchange.com/questions/411811/
  - ptaipale 9y ago
    I tried to say that it was not so simple. Yes, obviously Multics had the LF line end convention. Some systems saved files internally in a record format so the line end was whatever what the software decided to print out there. But mostly I was just reacting to the silly idea that CRLF would be right and lone LF not: Microsoft didn't come up with that idea. It was there already in 1960's and perhaps useful when you didn't want to do any line drivers for converting strings at output. But that's not really any more "right" than other conventions.

johnchristopher 9y ago

> I'm not quite sure how to interpret your last comment. You prefer the IE box model? Or you're saying they did it right from the get go? Because quirks mode was abandoned and everyone uses the Moz/W3C model now. It's worse than that. His position was: MS's understanding and implementation of the box model is the correct interpretation of the W3C specs (yeah, I know).

Stratoscope 9y ago

Interesting that you find \r\n to be "right" and the others "screwed up". I'm curious about the reasons for that. The biggest problem is that each OS went its own way (Mac started with \r but of course uses \n now). If they all had the same line ending all along, whatever it was, no one would think much about it. \r\n has the obvious disadvantage of being twice the size, along with making it possible to land in the middle of a line ending instead of before or after one. Of course one advantage would be if you're controlling physical equipment where carriage return and line feed are independent of each other. I learned to program in 1968 on a Teletype ASR33 where CR and LF were literal commands to return the carriage to column 1 and advance the paper. You had to use both because they did two different things. Or on occasion you might use CR by itself to overprint a line. LF by itself was pretty rare, but would do what you expect if you used it: advance the paper without moving the print carriage. CR LF was fine if you were typing interactively - in fact you just had to hit the CR key and the remote system would provide the LF. But usually we would punch our programs on paper tape, dial in, run the tape through and get the printout, and hang up right away. At $30/hour in 1968 dollars, this saved a lot of money. And of course you would run your tape through locally to print out and proofread your program before testing it online. To be able to print a tape locally, you needed both CR and LF, but even that wasn't quite adequate. You really wanted to allow a little extra time for the machinery to settle, so the standard line ending we punched on a tape was CR LF RUBOUT. RUBOUT was a character that punched out all the holes in a row of the paper tape. It was ignored by convention, so you could erase a typing error when punching a tape by pushing the backspace button on the tape punch and hitting the RUBOUT key. Because it was ignored, RUBOUT was also useful as a "delay" character in the newline sequence. So I guess I'll never get over the feeling that the One True Line Ending is: \r\n\x7F (Nah, I'm happy with \n, but it makes a good story.)

walshemj 9y ago
Could have been something that came from DEC as the original NT was influenced by VAX systems (which often had LA120's as consoles) I seem to recall.
- diffuse_l 9y ago

pedasmith 9y ago

In the old days, we knew to either open a file in text mode (where whatever the OS had would be converted to a single \n) or in binary mode (where it wouldn't, and you had to deal with the conversion yourself). IMHO, what SHOULD happen is that if you have a device that has special timing requirements (like the old fashioned printers with no memory), then the driver is responsible for the handling the timing. Adding in weird bits to everyone's files is a bad idea. And yes, I know the difference between carriage-return and new-line. And I know that in the old C specs, "\n" didn't have a guaranteed mapping to either.