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

41–50 of 188 posts

Re: HTML 5.2 Recommendation

#41

Post by andrewmcwatters »

wolfgke wrote: post #34
dmitriid wrote: post #11

Earlier quoted context omitted.

Full story here: https://www.reddit.com/r/javascript/comments/5swe9b/what_is_... tl;dr: Ignore w3c's HTML "standards" as they are (often poor) copies of WHATWG's standards.

> WHATWG's standards I my opinion one cannot call something a "standard" that changes every few days. EDIT: In this sense W3C's HTML 5.x can be considered a rather badly authored (cf. other comments here) standard, while what the WHATWG releases is not something that even measures up to a standard, but it is the daily version of how HTML is supposed to be today.

Exactly. How the hell is someone supposed to built against their work? You can't, it would just be piecemealed.

Re: HTML 5.2 Recommendation

#42

Post by igravious »

vog wrote: post #33
igravious wrote: post #23

Earlier quoted context omitted.

Their TOC needs to be collapsible and selectively expandable. UX fail imho.

> Their TOC needs to be collapsible Not sure what you mean. In the lower left there is a working collapse button.

No, not the entire sidebar, the individual branch elements of the tree I mean. Like this: http://jsfiddle.net/tygrj1us/

Re: HTML 5.2 Recommendation

#43

Post by geofft »

andrewmcwatters wrote: post #39

I wish WHATWG would properly version their work. I don't like the idea of a "living standard" because it leads to checking for individual functionality and feature detection, rather than being able to say, "This is fully HTML 5.x.x compliant." Regardless of the state of W3C, if I built an embedded renderer based on their specs, I could at least say, "this renderer is based on and link to the recommended spec version.…

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 way more practical.

If you're writing an embedded renderer, you can always say "This is compliant with the standard as of 14 December 2017." If you're writing an embedded renderer that is being applied to the live web and not just to a fixed set of pages that are also embedded (e.g., you're shipping HTML documentation and a viewer, or a kiosk, or something), you will in fact be out-of-date when the living standard changes. There's no point in saying "I'm compatible with HTML 5.2.0" because the live web isn't targeting 5.2 any more. So you can either acknowledge that, or figure out how to get software updates.

Re: HTML 5.2 Recommendation

#44

Post by geofft »

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.

got removed from browsers, which I personally find kind of sad because that's what I learned in 1995 and I've written a web page that uses it. But it's weird and does nothing that a normal form couldn't do, so the browsers seem to want to deprecate it.

Re: HTML 5.2 Recommendation

#45

Post by Touche »

andrewmcwatters wrote: post #41
wolfgke wrote: post #34

Earlier quoted context omitted.

> WHATWG's standards I my opinion one cannot call something a "standard" that changes every few days. EDIT: In this sense W3C's HTML 5.x can be considered a rather badly authored (cf. other comments here) standard, while what the WHATWG releases is not something that even measures up to a standard, but it is the daily version of how HTML is supposed to be today.

Exactly. How the hell is someone supposed to built against their work? You can't, it would just be piecemealed.

Just because something changes often doesn't mean it is unstable. Do you ever shop at amazon.com? I do, and I find it pretty stable.

Just because it changes often doesn't mean things are sloppily accepted, or that experimental ideas are added and later removed.

Indeed, if you want to build something for the web, reading an outdated document that contains bugs browsers have already fixed is not a good idea.

Re: HTML 5.2 Recommendation

#46

Post by exikyut »

gsnedders wrote: post #30
vog wrote: post #26

Earlier quoted context omitted.

Thanks for the update! But is that actually an improvement over the previous situation? (Serious question.)

> 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 beside that.

So, you'd think the actual grassroots on-the-ground parts of a project that is ostensibly defined to be open and free, would actually be made of extremely smart people with straightforward management and as little bureaucracy as possible. Because, you know, the part where everything hits the ground needs to be well-oiled, have no chinks in the armor, and provide a secure foundation of independence.

And yet we have... chaos, infighting, politics and wars over (literally) nothing. And while all that's happening, corporations are progressively nibbling away at the capabilities we have today (to set up websites, to communicate freely) that we take for granted. One day we'll wake up checkmated by some incredibly well-engineered chess move...

Sighs

If the net neutrality thing is repealed, I will be exactly 0% surprised. It'll just be another EME, really.

Re: HTML 5.2 Recommendation

#47

Post by kenbellows »

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, should be considered possibly harmful if it:

- presents possible security problems; for examples, consider some of the points listed here: https://html5sec.org/

- promotes poor usability or accessibility; e.g. interactive tooltips with links or controls in them, for example, are quite difficult to make accessible, and I wouldn't want an HTML tag without a lot of discussion about accessibility

- promotes anti-patterns; e.g., at this point I think -style scrolling informational text is an anti-pattern in a web context, since it can the text much harder to read, especially on small screens

Of course, none of these concerns should lead to immediate removal of a thing as soon as they're pointed out, but they should be discussed and considered. It's a cost-benefit analysis: what does this feature actually buy us that isn't easily achievable with other features, what problems is it causing and how severe are they, and are the benefits worth the problems?

As for , my guess, though I haven't been able to find the actual discussion, is that it was removed because its semantics are somewhat in conflict with , and probably its most common use was custom context (aka "right-click") menus, which bring a lot of accessibility problems with them. I don't know that I agree with the decision to remove it altogether, since I think its use to semantically identify and group web application controls is very valuable and not covered by any other tags (though I'd love to be corrected), but I do think that context menus, which to me seems like the most common use for the tag, are a very problematic design element. Again, it's a balance; is it worth the problems it causes? I guess the authors decided it wasn't.

(Just to reiterate, I don't know why was removed, I'm just guessing. If anyone can find any of the discussions about and the problems with it, I'd love to read more.)

Re: HTML 5.2 Recommendation

#49

Post by wolfgke »

Touche wrote: post #45
andrewmcwatters wrote: post #41

Earlier quoted context omitted.

Exactly. How the hell is someone supposed to built against their work? You can't, it would just be piecemealed.

Just because something changes often doesn't mean it is unstable. Do you ever shop at amazon.com? I do, and I find it pretty stable. Just because it changes often doesn't mean things are sloppily accepted, or that experimental ideas are added and later removed. Indeed, if you want to build something for the web, reading an outdated document that contains bugs browsers have already fixed is not a good idea.

> Just because something changes often doesn't mean it is unstable.

When you do a project contract, you surely want to define the exact standard with respect to which the application is to be developed against, so that one can decide whether the reason for something looking wrong is a browser bug (I can work around it - but it will cost extra money) or indeed a bug in my code that the customer found (i.e. I have to work extra hours for no money because I did bad work).

To be able to decide such questions is a central purpose of existence for standards.

Re: HTML 5.2 Recommendation

#50

Post by andrewmcwatters »

Touche wrote: post #45
andrewmcwatters wrote: post #41

Earlier quoted context omitted.

Exactly. How the hell is someone supposed to built against their work? You can't, it would just be piecemealed.

Just because something changes often doesn't mean it is unstable. Do you ever shop at amazon.com? I do, and I find it pretty stable. Just because it changes often doesn't mean things are sloppily accepted, or that experimental ideas are added and later removed. Indeed, if you want to build something for the web, reading an outdated document that contains bugs browsers have already fixed is not a good idea.

This just speaks from lack of experience: that's exactly what it means in the world of software. Do you not understand what specification means? "Specific" is even in the word.

You can't compare it to browsing on Amazon, because functionality doesn't just go missing and literally break buying things; functionality doesn't just suddenly get added and people rely on the exact font size and copy of a particular header in the men's clothing department to be precisely 2em and "Men’s Clothing," and now that it's changed to 1.5em and "Men's Winter Fashion" a third-party app can't render the header in an appropriate width size nor find the clothes to begin with.

Post reply on HN