Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML 5.2 Recommendation

w3.org

Post reply on HN
Print view View original

181–188 of 188 posts

Re: HTML 5.2 Recommendation

#181

Post by jraut »

masswerk wrote: post #180
talmand wrote: post #98

Earlier quoted context omitted.

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?

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.

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.

Re: HTML 5.2 Recommendation

#182

Post by masswerk »

austincheney wrote: post #120
masswerk wrote: post #60

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…

> 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 (appropri…

"never intended to be archival" – HTML originated as an easy to handle stand-alone documentation standard (as a cut-down version of SGMLguid + links/anchors). The entire point of a documentation standard is backwards compatibility. Especially the just-ignore-what-is-not-implemented policy made this very promising regarding future usage, as long as major structural elements were to be honored. (Compare the drop of framesets, menus and manueitems as primary elements to represent structure and hierarchy, or the drop of major phrase elements conveying meaning and emphasis. Also, referring to the recommendation for substitutes, HTML is now not a stand-alone language anymore, but requires additional CSS.)

Opposed to this, HTML was not intended as presentation layer for fancy web-apps. (There had been better around for this in the Hypertext-world, even then.)

Re: HTML 5.2 Recommendation

#183

Post by ksec »

CaptSpify wrote: post #116
lewisflude wrote: post #85

Earlier quoted context omitted.

Where would you draw the line between a "website" and a "web app", would you like to see JS die entirely? Would you like the web to be non-interactive. Genuinely interested.

Not OP, but I would like to see JS on the web die entirely. Executing code without review just by clicking on a link? no thanks.

I really wish there are ways to do most common JS code, Ajax and Pjax alike entirely without JS. Even Advertising and Tracking that is without JS.

Re: HTML 5.2 Recommendation

#184

Post by austincheney »

om2 wrote: post #175
austincheney wrote: post #160

Earlier quoted context omitted.

I am having trouble finding the background information on this. Basically, the WHATWG took the W3C DOM and wildly changed some foundational concepts without a thorough understanding of what those decisions mean. Here is a very simplified description of this problem years after the fact: https://github.com/whatwg/dom/issues/102 It is important to understand the DOM wasn't created for HTML. The DOM, starting with DOM l…

This specific decision turned out to be mistaken, but W3C makes this type of mistake way more often and doesn't even always fix them. You can see in the record of this issue that the problem was eventually resolved. WHATWG Working Mode has also been updated since this change and would not allow this type of change to be made today without implementor support. Regardless of issues like this, browsers track WHATWG DOM…

A big difference is that it took somebody new to the WHATWG (many years later) to admit failure and correct the problem very directly. In the past the WHATWG had a severe case of not invented here syndrome and would troll people to death who disagreed with them.

I know from my own conversations with the WHATWG this wasn't something that long time WHATWG members would admit to (or even understand). It was the childishness, perhaps more than anything else, that nobody took them seriously.

> Regardless of issues like this, browsers track WHATWG DOM near exclusively.

I am going to disagree with you there. Perhaps they do now, extremely recently, but historically this is absolutely false.

> You can see devs from all of the major browser engines commenting in the issue you linked.

Yes, everybody participates in the WHATWG. This isn't new. Participation is different than adopting those recommendations back into your software.

Here is what browsers actually implement: https://www.w3.org/DOM/DOMTR and https://www.w3.org/TR/dom41/

It is important to keep in mind that the WHATWG doesn't do a lot of XML work, but the DOM is markup language agnostic. The DOM isn't something created or maintained in an HTML rich vacuum.

Re: HTML 5.2 Recommendation

#185

Post by austincheney »

nothrabannosir wrote: post #163
austincheney wrote: post #120

Earlier quoted context omitted.

> 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 (appropri…

> HTML was never intended to be archival This is about the exact opposite of archival: backwards compatibility. We don’t want to split the web into old web and new web. Having to switch browsers for decade old pages as we encounter them, raising the barrier to entry for that lore of old, effectively sepulchring it from the public. 99% of the web’s users are not going to understand when to switch browsers, how, nor wh…

> This is about the exact opposite of archival: backwards compatibility. We don’t want to split the web into old web and new web.

It happens anyways regardless of what people want. The 90s era web doesn't work properly in modern browsers and 90s era browsers don't work with the modern web.

> 99% of the web’s users are not going to understand when to switch browsers, how, nor why.

This also happens naturally. Chrome is the most popular browser and it doesn't come with most operating systems. That is something users must switch to.

Re: HTML 5.2 Recommendation

#186

Post by om2 »

austincheney wrote: post #184
om2 wrote: post #175

Earlier quoted context omitted.

This specific decision turned out to be mistaken, but W3C makes this type of mistake way more often and doesn't even always fix them. You can see in the record of this issue that the problem was eventually resolved. WHATWG Working Mode has also been updated since this change and would not allow this type of change to be made today without implementor support. Regardless of issues like this, browsers track WHATWG DOM…

A big difference is that it took somebody new to the WHATWG (many years later) to admit failure and correct the problem very directly. In the past the WHATWG had a severe case of not invented here syndrome and would troll people to death who disagreed with them. I know from my own conversations with the WHATWG this wasn't something that long time WHATWG members would admit to (or even understand). It was the childish…

Do you work on a browser engine? I do (WebKit). Your claim that browsers actually implement W3C DOM 4.1 is just totally wrong. We don't even read it.

The person who ultimately fixed this problem in the DOM Living Standard is Anne Van Kesteren, who was not even remotely new to WHATWG at the time. The person who filed this issue (Philip) is also a WHATWG old timer.

Re: HTML 5.2 Recommendation

#187

Post by masswerk »

jraut wrote: post #181
masswerk wrote: post #180

Earlier quoted context omitted.

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.

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 i…

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

Re: HTML 5.2 Recommendation

#188

Post by jraut »

masswerk wrote: post #187
jraut wrote: post #181

Earlier quoted context omitted.

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 i…

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 work…

This discussion involves details about content referenced from another domain (or source which is not trusted). The implementation seems to be an issue which has finally been solved with a standard. The new implementations are being worked on. It is called CORS and the problems are still hard to solve in practice.

I am super glad for all the hard work put into all this.

Post reply on HN