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

81–90 of 188 posts

Re: HTML 5.2 Recommendation

#81

Post by geofft »

ChrisSD wrote: post #52
geofft wrote: post #40

Earlier quoted context omitted.

You can ask someone to stop doing something legal. I'd hate to live in the sort of world where you can't. HN moderators would send the police after you to seize your laptop if you make bad comments. The only way to get your roommate to stop eating your plums would be to charge them with larceny. Every relationship would end with a restraining order, or it wouldn't be over. Failing to turn in a homework assignment on…

Sure but they are using the copyright to insist on attribution, which undermines the argument that they are simply against using the law. If they really didn't care they'd use CC0. And in the quoted statement they are not saying the W3C should improve their process for forking WHATWG's work. They are saying the W3C shouldn't fork their work at all. So despite their specifically chosen license (with easy to understand…

Yes, they do in fact want to use state violence to insist on attribution. They don't want to use state violence to insist on the W3C going away, but they still want the W3C to go away. That seems reasonable to me.

Re: HTML 5.2 Recommendation

#82

Post by jlebrech »

eberkund wrote: post #80
jlebrech wrote: post #37

nope, html needs to stop. it's a document markup language and shouldn't be used for apps.

What about XAML and all the other XML based UI markups? I find HTML refreshingly easy to use compared to the alternatives.

XUL seemed interesting, not being backwards compatible with html was one of it's strengths.

Re: HTML 5.2 Recommendation

#83

Post by colanderman »

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.

Right, hence my assertion that well-known names of feature sets are useful. "HTML 5.2" is useful in the same way that "C99" was, because eventually there is a day I can just assume everything in "HTML 5.2" is present in all my targets. If I don't have such a name, if I'm forever at "HTML 5", I'm forced into the "autoconf" scenario of using feature detection forever for everything not in the base specification.

(That the W3C is apparently incompetent at associating feature sets with names is a separate issue.)

Re: HTML 5.2 Recommendation

#85

Post by lewisflude »

jlebrech wrote: post #58
SimeVidas wrote: post #55

Earlier quoted context omitted.

What‘s the alternative (for web apps)?

don't make them

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.

Re: HTML 5.2 Recommendation

#86

Post by andrewmcwatters »

colanderman wrote: post #56
geofft wrote: post #43

Earlier quoted context omitted.

But that's the point - web authors are supposed to use feature detection instead of writing to a particular standard version. It turns out to be a better model for large interfaces. Yes, in theory, you can ask "Is this OS POSIX.1-2008-compliant or not." In practice, it takes a while to e fully POSIX.1-2008-compliant, and so you get autoconf, with its individual feature detections of specific function. Less clean, but…

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.

Re: HTML 5.2 Recommendation

#87

Post by andrewmcwatters »

colanderman wrote: post #83
tptacek wrote: post #78

Earlier quoted context omitted.

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.

Right, hence my assertion that well-known names of feature sets are useful. "HTML 5.2" is useful in the same way that "C99" was, because eventually there is a day I can just assume everything in "HTML 5.2" is present in all my targets. If I don't have such a name, if I'm forever at "HTML 5", I'm forced into the "autoconf" scenario of using feature detection forever for everything not in the base specification. (That…

Right on about the C99 analogy, thanks. That's my concern.

Re: HTML 5.2 Recommendation

#88

Post by jlebrech »

lewisflude wrote: post #85
jlebrech wrote: post #58

Earlier quoted context omitted.

don't make them

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.

Re: HTML 5.2 Recommendation

#89

Post by rlanday »

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.

Whether or not to remove a web platform feature from a browser basically comes down to how many people are using it vs. what is the maintenance cost. I suspect that browsers continue to support so they can continue to render all those great webpages from the late 1990s properly.

Re: HTML 5.2 Recommendation

#90

Post by collinmanderson »

stupidcar wrote: post #13
rwmj wrote: post #6

Earlier quoted context omitted.

For those who have not been paying attention for a decade, what's the relationship between this revision and WHATWG?

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.
Post reply on HN