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

161–170 of 188 posts

Re: HTML 5.2 Recommendation

#161

Post by domenicd »

xg15 wrote: post #154
domenicd wrote: post #131

Earlier quoted context omitted.

> And yet, we don't get things like that changes page from the WHATWG version. (Unless you want to dig through the whole commit history) So far we've done our best to keep a really readable, tidy Git commit log, which should help with understanding changes: https://github.com/whatwg/html/commits/master If you omit the "Editorial:" or "Meta:" commits, I think it's actually at a similar level of detail as the W3C fork'…

But this is kind of my point: As of now, this doesn't exist. I don't think the commit history works. It doesn't give you any indication about which changes are relevant or irrelevant and it doesn't tell anything about the larger efforts taking place. Actually, I don't think it would even make sense to create an equivalent of the W3C diff, because there are no versions or other structures to organize the changes aroun…

The W3C fork's versions are arbitrary too though (yearly). You could organize a yearly update on what's new in the HTML Standard if you thought that would be valuable to people. It wouldn't change the fact that browsers release new features based on the ever-changing standard every six weeks. But it sounds like at least some people would find it useful.

Personally I'd tend toward weekly or monthly, although I admit that yearly is more likely to generate HackerNews posts ;)

Re: HTML 5.2 Recommendation

#162

Post by wahern »

tptacek wrote: post #78
colanderman wrote: post #75

Earlier quoted context omitted.

Unless "conditional includes" are some new feature of HTML5 that my Google-fu isn't turning up, that kind of negates the whole "static HTML" thing. Bootstrapping a web page through JavaScript polyfills is like autoconf all over again.

The problem with autoconf is that it detects every conceivable Unix featuring going all the way back to the 1980s, not that feature detection is itself that problematic.

autoconf doesn't detect much of anything by default. A few commonly used, boilerplate macros do a series of test (e.g. AC_PROG_CC, AC_USE_SYSTEM_EXTENSIONS, AC_SYS_LARGEFILE), but for the most part each and every feature test autoconf does was explicitly and individually requested by the author.

The real issue is that people copy+paste autoconf tests from other projects without thinking about whether they're necessary, or even confirming whether they work for their use case. And because people just copy+paste autoconf tests instead of keeping a browser tab open with the (free) POSIX spec when writing their code, most tests people add are for stuff that no longer needs to be tested for (i.e. all the major Unix platforms support most standard POSIX features by default), and lack the tests for non-standard interfaces they actually use.

But there's no easy way to fix such poor development practices. A good start would be if people just stopped using autoconf, as well as libtool, cmake, maven, etc, unless and until it really became necessary. Follow the KISS principle. Keep your build as simple as possible and regularly test your code on at least one platform other than Linux/glibc, such as FreeBSD or OpenBSD, rather than misplacing your faith in overly wrought tooling.

It works the same way on the web. Don't use the latest + greatest feature if you don't need to. Like with performance optimizations, don't add the burden until there's relevant, empirical evidence that it's worth your while in the particular case. Nobody ever magically achieved high performance or strong portability by adopting over wrought tooling before the problems ever presented themselves. Doing so often ends up with the opposite result.

Re: HTML 5.2 Recommendation

#163

Post by nothrabannosir »

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…

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

Re: HTML 5.2 Recommendation

#164

Post by sureaboutthis »

reificator wrote: post #91
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?

has never been in any HTML specification since time began.

Re: HTML 5.2 Recommendation

#165

Post by sureaboutthis »

taco_emoji wrote: post #126
ocdtrekkie wrote: post #110

Earlier quoted context omitted.

I unapologetically still use the font tag, because most of the time I have no desire to bother with CSS.

Even inline? Blah vs. Blah

pt is for print and does not translate to the web. There are articles about this, specifically from the W3C https://www.w3.org/Style/Examples/007/units.en.html

Re: HTML 5.2 Recommendation

#166

Post by reificator »

sureaboutthis wrote: post #164
reificator wrote: post #91

Earlier quoted context omitted.

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?

has never been in any HTML specification since time began.

And yet it can be supported just fine.

Re: HTML 5.2 Recommendation

#167

Post by liveoneggs »

kuschku wrote: post #132
domenicd wrote: post #130

Earlier quoted context omitted.

I work for Chrome, as an editor of the HTML Standard. So let me give you my perspective on this. In Chrome we ensure that all features we ship to the web go through a public standards process. This allows them to be developed by a collaborative community, including other browser vendors and web developers who would use them. It ensures that if we happen to ship a feature sooner than other vendors, there's a specifica…

> In Chrome we ensure that all features we ship to the web go through a public standards process. Ehm, basically every major feature Chrome has shipped has been shipped before the standard was even discussed. SPDY shipped long before HTTP/2 was even finalized, and QUIC is doing the same. NaCl shipped in the same way, without any standardization, and to this date, earth.google.com depends on it. In general, your probl…

https://github.com/whatwg/url/issues/118 is the curl issue, I believe. As I love curl more than any browser I personally side with it. It has support for ldap urls; curl wins. :)

Re: HTML 5.2 Recommendation

#168

Post by krapp »

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.

"Interactivity" can mean anything including hypertext itself.

And what sort of interactivity? Does backend logic count, or only logic in the browser? If only the latter - why does that matter, but not the former? Does any site that uses javascript qualify, regardless of how little?

Hacker News uses javascript, so is it a "web app" and not a "web site?" Would it suddenly become a webapp if the mods hit their heads and decided in a fever delirium to turn the whole thing into a SPA, despite it having the exact same functionality?

In this model, would YC have to publish the static pages of HN on the "static" web but the forum on the "dynamic" web? But what if they cache the threads? Now they're static as well. And having every web developer divide their attention and work between two platforms based on which part of it is "static" and which part is "dynamic" seems needlessly complex and confusing.

I sympathize with the idea - HTML and javascript are terrible for building applications, but if you want the web to only be static HTML files then your "new" platform is going to contain almost every website in existence, including most of the brochure sites, articles and "legacy stuff." Most web apps are also documents, few are strictly one or the other.

It would make more sense to bifurcate the web along WASM, because that will lead to the distinction between HTML and compiled binaries (which, I know, we've already been there with Flash and Java) both in the browser. But even then, WASM is intended to work within the context of javascript and HTML, not necessarily to stand alone.

Re: HTML 5.2 Recommendation

#169

Post by sureaboutthis »

vorpalhex wrote: post #69
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…

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

Mode tag? Compatibility mode?

Re: HTML 5.2 Recommendation

#170

Post by reificator »

orph4nus wrote: post #140
reificator wrote: post #91

Earlier quoted context omitted.

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?

I think you're missing the OP's point though. It's true that you can just use some CSS to make up for the lost HTML feature, but than again you could also rewrite the HTML part. Forgive me if I'm wrong, but I'm fairly sure that what the OP is trying to say, is that there are plenty of great websites out there, which were developed a long time ago, and for which there is no maintainer to do any work on it. Thus having…

I may not have expressed myself clearly, but I understood what OP was saying. Never overnight and post, kids.

I was thinking about something like Stylish or the user stylesheet I've been hearing about in Firefox (for their UI IIRC, but still). Inject some global css on older/missing doctypes, and it's probably less than 200 total declarations to handle every older tag. I'd imagine to be the hardest and/or longest, followed by and .

Would be a small extension.

My other point I think I expressed clearly enough, that the loss of presentational markup is not a loss of content in most cases. If the title is in Times New Roman instead of Arial, most of the time it'll just look worse. Unless the content is meta, the presentation is to make things more pleasant to read.

Post reply on HN