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

91–100 of 188 posts

Re: HTML 5.2 Recommendation

#91

Post by reificator »

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…

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 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?

Re: HTML 5.2 Recommendation

#92

Post by reificator »

andrewmcwatters wrote: post #86
colanderman wrote: post #56

Earlier quoted context omitted.

How does one perform feature detection in a static HTML page? As far as I can tell the only way to author a compatible web page these days is by checking every damn feature of HTML you use against some humongous table like Can I Use? before assuming your audiences' browsers support it. Compare to versioned specs, where I need simply determine the minimum spec version supported by my target audience (and any exception…

This is the annoying part. It's a joke that a site like Can I Use needs to exist, and that browser vendors don't really have apt versions of their own compatibility tables. Going to a third-party website to check to see if something is supported is disgusting.

I'm quite happy with the various vendor pages, including internet explorer/edge.

But since I'm not developing for a single browser (outside of my day job that is) I'm going to use the aggregate site that shows all of them at once.

Re: HTML 5.2 Recommendation

#93

Post by reificator »

jlebrech wrote: post #88
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.

interactivity should move to a newer platform and the web should just be for brochure sites, articles and legacy stuff. there should be a new platform that uses a new engine that's isn't backwards compatible. It might be possible to do this soon with wasm+canvas, but then you have unused rendering engines (html/css) and it's recreated from the ground up.

Is that a practical "should" or an ideological "should"?

Re: HTML 5.2 Recommendation

#94

Post by exabrial »

I really wish we'd "simplify" the HTML spec. The "pave the cow paths" approach to allow non-closed tags and mix of various syntaxes has lead to an explosion of complexity. That has regressed into terrible performance and memory hungry parsers.

Re: HTML 5.2 Recommendation

#95

Post by rhencke »

exabrial wrote: post #94

I really wish we'd "simplify" the HTML spec. The "pave the cow paths" approach to allow non-closed tags and mix of various syntaxes has lead to an explosion of complexity. That has regressed into terrible performance and memory hungry parsers.

This was done once - it was called XHTML. It was, effectively, just HTML in XML form. Tags had a single syntax (no implicitly self-closing tags). Documents were required to be well-formed, syntactically, or they would not display.

It did not win.

Re: HTML 5.2 Recommendation

#96

Post by collinmanderson »

exikyut wrote: post #46
gsnedders wrote: post #30

Earlier quoted context omitted.

> But is that actually an improvement over the previous situation? (Serious question.) No, it means we have two increasingly different documents purportedly defining the same things, and when they do copy patches over they've failed to also copy over other dependent patches too on a number of occasions leaving their spec as defined unimplementable.

I know the current manglement isn't explicitly malicious, but this is an atrocious state of affairs. Practically speaking, the Web is a consortium of corporate foghorns that also happen to collectively be the majority ad-hoc directors of new media (translation: agendas with finance). Cable and daytime TV was the old media, which of course still exists, and social media has become a juggernaut majority of its own besi…

At this point both W3C and WHATWG are not where innovation on the web is (or should be) happening. It's up to the individual browser makers to innovate. W3C and WHATWG's job should be to document any consensus among browser makers.

It shouldn't be their job to decide how browsers should work, that's the browser makers' decision. (Which happens to be large corporations, for the most part.)

Re: HTML 5.2 Recommendation

#97

Post by Bahamut »

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…

Doesn't this have negative ramifications for email too?

Re: HTML 5.2 Recommendation

#98

Post by talmand »

masswerk wrote: post #79
jraut wrote: post #66

Earlier quoted context omitted.

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?

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

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?

Re: HTML 5.2 Recommendation

#99

Post by [deleted] »

collinmanderson wrote: post #90
stupidcar wrote: post #13

Earlier quoted context omitted.

The W3C version is a sporadically updated, bad-faith fork of the WHATWG version, created to maintain the fiction that it "owns" HTML, which it deems necessary to maintain the organisation's standing (and funding) in the eyes of other organisations and governments.

I think of it like WHATWG is the git master branch of the "html" standard, and W3C regularly packages a modified (changing things they disagree with) version of it and "release" it with a version number (HTML 5.x), going through alpha, beta, etc. By the time it's finalized, it's out of date.

[deleted]

Re: HTML 5.2 Recommendation

#100

Post by domenicd »

kenbellows wrote: post #47
magnat wrote: post #14

What's the point of removing features such as "menu" from HTML standard? If there are browsers supporting it and webpages using it, would Mozilla (or Google or Microsoft) actually remove those features just because newest standard said so? I mean: marquee was deprecated long ago, yet browsers still render it correctly.

I can't speak for the spec authors, but IMHO, tags should be deprecated and eventually removed when they are deemed to be useless, especially when their functions and/or semantics are covered by another tag, and especially when their use is harmful (or rather, more harmful than beneficial). In my (very personal) opinion, an HTML tag or attribute, and more generally a feature of any design/development framework, shoul…

I haven't looked at the W3C fork of our work, but in the actual HTML Standard (maintained at the WHATWG), menu was not completely removed---just the mostly-unimplemented context menu feature. We left menu as a semantic alternative to ol/ul for menu-like lists.

See more at https://github.com/whatwg/html/pull/2742

---

For more on removals within the WHATWG process, see:

- https://whatwg.org/faq#removing-bad-ideas

- https://whatwg.org/working-mode#removals

There's also the case of things like marquee, which are not removed, but just marked as obsolete and something that web developers must not use. (Which in practice means that conformance checkers like https://checker.html5.org/ are required to complain about them; it doens't mean there's some godlike web-developer-enforcement committee going around preventing you from writing code that uses marquee.) Their implementation requirements are still in the spec; see e.g. https://html.spec.whatwg.org/multipage/obsolete.html#the-mar... and https://html.spec.whatwg.org/multipage/rendering.html#the-ma.... (Same for frame/frameset, by the way.)

Post reply on HN