9 ms·

Hm – I'm not too happy to see most of the original HTML-elements marked "not conforming" and "must not be used", thus preparing for browsers to eventually drop

Hm – I'm not too happy to see most of the original HTML-elements marked "not conforming" and "must not be used", thus preparing for browsers to eventually drop the support. There are still lots of web-sites and valuable information stored and archived in this format. Back in the day, it was thought that basic HTML was a format to last. Who is going to update these documents in order to make them conforming to future browsers? Or are we just dropping a decade of documentation? Is it worth it? (Consider: Apparently, MS-Word docs or PDF prove longer lived than basic HTML documents! Who would have thought of this?)

jraut 9y ago
Dropping the support does not make the elements non-functional. Instead, they are presented differently. Formats and notations do undergo changes. The comment mentions long-lived MS-Word doc. Which version of those, specifically, has been around the longest so far?
- masswerk 9y ago
  I'm really afraid that this is preparing the final drop of browser support. (We've seen similar in http, where many of the http/1.1 (1997) features, like multipart-http, for-headers, etc. aren't supported by any client for years by now.) As for MS-Word and HTML: When I finished my thesis in the mid-1990s, I saved it both in the MS-Word version, I used to write it (MS Word 5 for Mac), and HTML (expecting future compatibility). I can still open the Word version, but I may be soon unable to conjure a formatted display of the HTML-version. And I can still display a PDF 1.x...
  - talmand 9y ago
    What do you mean by "browser support"? What functionality do you expect to go away that would prevent you from viewing an old HTML file in a modern browser?
    - masswerk 9y ago
      E.g., drop of framesets. Many old documentations use them, as do most websites from the second half of the 1990s (so-called 2nd gen. websites). Without frames, the content can't displayed in context anymore and consistency of presentation is lost entirely.
      - jraut 9y ago
        Oh gosh, that is absolutely true. A major change in presentation when the support is dropped to be sure. On the other hand, what was the level of standardization then? Were there not massive inconsistencies across browsers when you got into fine details of implementation doing frames? Especially parent-child -relations among elements/sets/contexts which is an integral concept in definitive DOM - a grand achievement in standardized HTML format.
        masswerk 9y ago
        In framesets, parent-child relations were absolutely defined and stable, as were the paths between individual frames. (Current frame is "self" or "window", parent frame or frameset is "parent", and the top most entry point into the hierarchy "top". Moreover, "self", transcending the window context, is also the only reliable reference to the global object, thus also providing a valid reference to the context of a worker. Specifically, it was for framesets that the notion of hierarchy was introduced, which eventually resulted in the concept of the DOM. Some inconsistencies to this concept of strict parent-child relations were actually introduced by early implementations of the iframe-element, which is, BTW, still a valid HTML element.) That said, there was a small inconsistency with an early subversion of Netscape 3, regarding, whether the frame source would be relative to any current location of the frame or rather relative to the frameset. (But this was an issue for a rather short period of time, two months or so.) A major difference in styling was the implementation of frame borders, if they would be entirely invisible by just specifying `border="0"` (Netscape and others) or, if they required the two attributes `frameborder="0"` and `framespacing="0"` (MS IE). In practice, next to all sites specified both schemes. And jet another, but minor implementation specific detail was the sizing of framesets: While Netscape Navigator supported, like all other browsers, a size specified in pixels, this was internally translated to percents of the total width. Therefor, depending on rounding to integers, the presentation in the Netscape browser could be off by a pixel or two. (The latter was, in deed, not unusual behavior at the time, just like MS Word and RTF used to translate any measurements internally to "tips" or twentieths of a point.)
- richev 9y ago
  Personal MS Word anecdote: Word 2016 can successfully open and render my final year University project report, compiled in 1996 using Word 6.0. It contains a bunch of embedded images, tables and moderately complex diagrams drawn using Visio 2.0. The report is saved across six .doc files, due to the size limitation of the 3.5" floppy disks we were using back then.
vorpalhex 9y ago
The HTML mode tag should put the browser into compatibility mode. This content should not be lost.
- sureaboutthis 9y ago
  Mode tag? Compatibility mode?
  - jraut 9y ago
    This covers the situation. Quirks mode is a legacy-compatible mode for old pages. https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
reificator 9y ago
<blink> is no longer supported by browsers, but with a few css declarations it works just fine. Removing support for presentational markup does not mean a loss of information. Browsers will still render tags they don't recognize, and re-applying the styling of those tags is often trivial. (I mention <blink> because it's one of the more difficult, but not terribly so) As the web evolved, our needs changed. Do we still need the tag?
- ocdtrekkie 9y ago
 I unapologetically still use the font tag, because most of the time I have no desire to bother with CSS.
 - taco_emoji 9y ago
 Even inline? Blah vs. Blah
 - bzbarsky 9y ago
 Just as a nit, "font-size:10pt" is a lot worse than from an accessibility perspective. is "one notch below the user's default size". If the user sets a 20pt font, it's going to be larger than 10pt. You could use "font-size: small" to get the size="2" behavior. (Also, "font-family: Whatever", not "font-face: Whatever".)
 - ocdtrekkie 9y ago
 Note that your CSS example is longer and requires combining two different syntaxes. And for one change, the difference in length and complexity is much more apparent. > Blah vs. > Blah Which is easier to remember? Which is more obvious at a glance?
 - maemilius 9y ago
Bahamut 9y ago
Doesn't this have negative ramifications for email too?
- duskwuff 9y ago
  Not really. HTML rendering by email clients has never been especially standards-conformant; the publication of a new HTML standard (especially by W3C, as mentioned elsewhere) isn't likely to affect that.
domenicd 9y ago
I don't really know what process the W3C fork of our work uses for removal, if any, but you can learn more about how features get removed in the (WHATWG) HTML Standard per our working mode: - https://whatwg.org/working-mode#removals https://whatwg.org/working-mode#removals - https://whatwg.org/faq#removing-bad-ideas https://whatwg.org/faq#removing-bad-ideas In short, I think it's important to distinguish between conformance and removal from browsers. Removal from browsers is a big deal and, as per those links, is only done when it's not going to break the web, or when the benefits are very high (e.g. security issues). Removal from being conformant just reflects the evolution of best practices. See also https://github.com/whatwg/html/blob/master/FAQ.md#how-are-developers-to-determine-when-certain-parts-of-their-pages-will-become-invalid https://github.com/whatwg/html/blob/master/FAQ.md#how-are-de...
frik 9y ago
What's wrong with W3C again? Are we on the same train we were with the ill-fated XHTML 1 strict and XHTML 2. Anyway what's going on anyway with Google+Microsoft+Apple+W3C, why is there such a big push to HTTPS and HTTP/2, and declaring old HTTP/0.9 and HTTP/1 and HTTPS/1 and HTML5.0 as legacy!? And why is Mail still sent in plain text completely insecure, and no adoption hype to support SMIME/etc? It is beyond fishy. Or is it just pure greed, no one cares about non-walled-garden-open-web (aka everything has to live in LinkedIn/FB/AppStore/PWA) and there is no money in mail?
- duskwuff 9y ago
  This W3C recommendation is essentially meaningless. The W3C's "HTML 5.x" specifications have never been considered normative by browsers. The actual HTML specification which browsers follow is maintained by WHATWG at: https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/
  - deleted 9y ago
    [deleted]
  - kuschku 9y ago
    > The actual HTML specification which browsers follow ...is found here: https://chromium.googlesource.com/ https://chromium.googlesource.com/ The reality is that the WHATWG (a) only writes descriptive standards, describing what already exists, usually with pseudocode and prosa instead of ABNF or EBNF (see the URL standard replacement), and (b) only describes something once it’s actually been implemented on larger scale. On the topic of what standards are supposed to do – prescriptively shape and replace what exists – the WHATWG isn’t useful. WHATWG "standards" are the equivalent of Microsoft Office Open XML, a standards body just taking an existing implementation, defining whatever it does as standard, and doing it so incomplete that the result is useless. Yes, WHATWG and W3C are doing the best they can do in the current climate (where Google can roll out QUIC and SPDY before even any standard is defined across websites accounting for 6% of global traffic, 65%+ of web browsers, and 85%+ of mobile phones), but this is just misleading. It helps no one to pretend to do standardization work when you don’t actually have any power to decide anything – neither WHATWG nor W3C can actually force, or even ask, Google to change SPDY or QUIC. They’re papertigers.
austincheney 9y ago
> Back in the day, it was thought that basic HTML was a format to last. HTML was never intended to be archival. Archival assumes a long term relationship between format and user-agent, but those two things evolve independently. > Who is going to update these documents in order to make them conforming to future browsers? You don't update legacy documents stored in an archive. You find a conforming user-agent (appropriately old browser version) to consume them in their intended state. > Is it worth it? Yes, HTML is a versioned format. Improvements to the format are welcomed and necessary.
- xg15 9y ago
  Except, as described later in this thread, WHATWG HTML, the spec that is actually implemented is decidedly not versioned and changes from day to day. It's likewise discouraged from keeping old user-agents. (See e.g. chrome's and firefox' aggressive update and support policies.) From what I understand, the WHATWG's policy regarding archival is "well yes the format is constantly changing but we'll try REALLY hard to not make too many breaking changes."
  - austincheney 9y ago
    To my knowledge the WHATWG specs are the backbone of the W3C specs, but nobody follows the WHATWG specs. Browser vendors prefer to follow the W3C specs precisely because they are versioned and perform against a slower and extremely thorough review process.
    - om2 9y ago
      That’s not right. Browser implement the WHATWG specs. That said, validity changes don’t matter to the browser’s ability to render old pages. Changes to remove support for an element entirely are very rare.
    - mastax 9y ago
      This is not (uncontroversially) true. See the long discussion below or on any other W3C post on HN.

jraut 9y ago

Dropping the support does not make the elements non-functional. Instead, they are presented differently. Formats and notations do undergo changes. The comment mentions long-lived MS-Word doc. Which version of those, specifically, has been around the longest so far?

masswerk 9y ago
I'm really afraid that this is preparing the final drop of browser support. (We've seen similar in http, where many of the http/1.1 (1997) features, like multipart-http, for-headers, etc. aren't supported by any client for years by now.) As for MS-Word and HTML: When I finished my thesis in the mid-1990s, I saved it both in the MS-Word version, I used to write it (MS Word 5 for Mac), and HTML (expecting future compatibility). I can still open the Word version, but I may be soon unable to conjure a formatted display of the HTML-version. And I can still display a PDF 1.x...
- talmand 9y ago
  What do you mean by "browser support"? What functionality do you expect to go away that would prevent you from viewing an old HTML file in a modern browser?
  - masswerk 9y ago
    E.g., drop of framesets. Many old documentations use them, as do most websites from the second half of the 1990s (so-called 2nd gen. websites). Without frames, the content can't displayed in context anymore and consistency of presentation is lost entirely.
    - jraut 9y ago
      Oh gosh, that is absolutely true. A major change in presentation when the support is dropped to be sure. On the other hand, what was the level of standardization then? Were there not massive inconsistencies across browsers when you got into fine details of implementation doing frames? Especially parent-child -relations among elements/sets/contexts which is an integral concept in definitive DOM - a grand achievement in standardized HTML format.
      - masswerk 9y ago
        In framesets, parent-child relations were absolutely defined and stable, as were the paths between individual frames. (Current frame is "self" or "window", parent frame or frameset is "parent", and the top most entry point into the hierarchy "top". Moreover, "self", transcending the window context, is also the only reliable reference to the global object, thus also providing a valid reference to the context of a worker. Specifically, it was for framesets that the notion of hierarchy was introduced, which eventually resulted in the concept of the DOM. Some inconsistencies to this concept of strict parent-child relations were actually introduced by early implementations of the iframe-element, which is, BTW, still a valid HTML element.) That said, there was a small inconsistency with an early subversion of Netscape 3, regarding, whether the frame source would be relative to any current location of the frame or rather relative to the frameset. (But this was an issue for a rather short period of time, two months or so.) A major difference in styling was the implementation of frame borders, if they would be entirely invisible by just specifying `border="0"` (Netscape and others) or, if they required the two attributes `frameborder="0"` and `framespacing="0"` (MS IE). In practice, next to all sites specified both schemes. And jet another, but minor implementation specific detail was the sizing of framesets: While Netscape Navigator supported, like all other browsers, a size specified in pixels, this was internally translated to percents of the total width. Therefor, depending on rounding to integers, the presentation in the Netscape browser could be off by a pixel or two. (The latter was, in deed, not unusual behavior at the time, just like MS Word and RTF used to translate any measurements internally to "tips" or twentieths of a point.)
richev 9y ago
Personal MS Word anecdote: Word 2016 can successfully open and render my final year University project report, compiled in 1996 using Word 6.0. It contains a bunch of embedded images, tables and moderately complex diagrams drawn using Visio 2.0. The report is saved across six .doc files, due to the size limitation of the 3.5" floppy disks we were using back then.

vorpalhex 9y ago

The HTML mode tag should put the browser into compatibility mode. This content should not be lost.

sureaboutthis 9y ago
Mode tag? Compatibility mode?
- jraut 9y ago
  This covers the situation. Quirks mode is a legacy-compatible mode for old pages. https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...

reificator 9y ago

<blink> is no longer supported by browsers, but with a few css declarations it works just fine. Removing support for presentational markup does not mean a loss of information. Browsers will still render tags they don't recognize, and re-applying the styling of those tags is often trivial. (I mention <blink> because it's one of the more difficult, but not terribly so) As the web evolved, our needs changed. Do we still need the tag?

ocdtrekkie 9y ago
I unapologetically still use the font tag, because most of the time I have no desire to bother with CSS.
- taco_emoji 9y ago
 Even inline? Blah vs. Blah
 - bzbarsky 9y ago
 Just as a nit, "font-size:10pt" is a lot worse than from an accessibility perspective. is "one notch below the user's default size". If the user sets a 20pt font, it's going to be larger than 10pt. You could use "font-size: small" to get the size="2" behavior. (Also, "font-family: Whatever", not "font-face: Whatever".)
 - ocdtrekkie 9y ago
 Note that your CSS example is longer and requires combining two different syntaxes. And for one change, the difference in length and complexity is much more apparent. > Blah vs. > Blah Which is easier to remember? Which is more obvious at a glance?
 - maemilius 9y ago

Bahamut 9y ago

Doesn't this have negative ramifications for email too?

duskwuff 9y ago
Not really. HTML rendering by email clients has never been especially standards-conformant; the publication of a new HTML standard (especially by W3C, as mentioned elsewhere) isn't likely to affect that.

domenicd 9y ago

I don't really know what process the W3C fork of our work uses for removal, if any, but you can learn more about how features get removed in the (WHATWG) HTML Standard per our working mode: - https://whatwg.org/working-mode#removals https://whatwg.org/working-mode#removals - https://whatwg.org/faq#removing-bad-ideas https://whatwg.org/faq#removing-bad-ideas In short, I think it's important to distinguish between conformance and removal from browsers. Removal from browsers is a big deal and, as per those links, is only done when it's not going to break the web, or when the benefits are very high (e.g. security issues). Removal from being conformant just reflects the evolution of best practices. See also https://github.com/whatwg/html/blob/master/FAQ.md#how-are-developers-to-determine-when-certain-parts-of-their-pages-will-become-invalid https://github.com/whatwg/html/blob/master/FAQ.md#how-are-de...

frik 9y ago

What's wrong with W3C again? Are we on the same train we were with the ill-fated XHTML 1 strict and XHTML 2. Anyway what's going on anyway with Google+Microsoft+Apple+W3C, why is there such a big push to HTTPS and HTTP/2, and declaring old HTTP/0.9 and HTTP/1 and HTTPS/1 and HTML5.0 as legacy!? And why is Mail still sent in plain text completely insecure, and no adoption hype to support SMIME/etc? It is beyond fishy. Or is it just pure greed, no one cares about non-walled-garden-open-web (aka everything has to live in LinkedIn/FB/AppStore/PWA) and there is no money in mail?

duskwuff 9y ago
This W3C recommendation is essentially meaningless. The W3C's "HTML 5.x" specifications have never been considered normative by browsers. The actual HTML specification which browsers follow is maintained by WHATWG at: https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/
- deleted 9y ago
  [deleted]
- kuschku 9y ago
  > The actual HTML specification which browsers follow ...is found here: https://chromium.googlesource.com/ https://chromium.googlesource.com/ The reality is that the WHATWG (a) only writes descriptive standards, describing what already exists, usually with pseudocode and prosa instead of ABNF or EBNF (see the URL standard replacement), and (b) only describes something once it’s actually been implemented on larger scale. On the topic of what standards are supposed to do – prescriptively shape and replace what exists – the WHATWG isn’t useful. WHATWG "standards" are the equivalent of Microsoft Office Open XML, a standards body just taking an existing implementation, defining whatever it does as standard, and doing it so incomplete that the result is useless. Yes, WHATWG and W3C are doing the best they can do in the current climate (where Google can roll out QUIC and SPDY before even any standard is defined across websites accounting for 6% of global traffic, 65%+ of web browsers, and 85%+ of mobile phones), but this is just misleading. It helps no one to pretend to do standardization work when you don’t actually have any power to decide anything – neither WHATWG nor W3C can actually force, or even ask, Google to change SPDY or QUIC. They’re papertigers.

austincheney 9y ago

> Back in the day, it was thought that basic HTML was a format to last. HTML was never intended to be archival. Archival assumes a long term relationship between format and user-agent, but those two things evolve independently. > Who is going to update these documents in order to make them conforming to future browsers? You don't update legacy documents stored in an archive. You find a conforming user-agent (appropriately old browser version) to consume them in their intended state. > Is it worth it? Yes, HTML is a versioned format. Improvements to the format are welcomed and necessary.

xg15 9y ago
Except, as described later in this thread, WHATWG HTML, the spec that is actually implemented is decidedly not versioned and changes from day to day. It's likewise discouraged from keeping old user-agents. (See e.g. chrome's and firefox' aggressive update and support policies.) From what I understand, the WHATWG's policy regarding archival is "well yes the format is constantly changing but we'll try REALLY hard to not make too many breaking changes."
- austincheney 9y ago
  To my knowledge the WHATWG specs are the backbone of the W3C specs, but nobody follows the WHATWG specs. Browser vendors prefer to follow the W3C specs precisely because they are versioned and perform against a slower and extremely thorough review process.
  - om2 9y ago
    That’s not right. Browser implement the WHATWG specs. That said, validity changes don’t matter to the browser’s ability to render old pages. Changes to remove support for an element entirely are very rare.
  - mastax 9y ago
    This is not (uncontroversially) true. See the long discussion below or on any other W3C post on HN.