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

151–160 of 188 posts

Re: HTML 5.2 Recommendation

#151

Post by foolip »

ficklepickle wrote: post #148
domenicd wrote: post #118

Earlier quoted context omitted.

This change to requiring attribution is actually fairly recent, and was made with some reluctance on the part of us editors, despite eventually agreeing it was the best path forward. See https://blog.whatwg.org/copyright-license-change

Thanks for the link! It's great to be able to read the reasoning behind decisions. There is a typo in the third paragraph, first sentence, FYI. "Are not" is repeated. For example, there are derivative specifications ("forks") that are not are not prominently identified as copies of WHATWG standards

Typo fixed, thanks!

Re: HTML 5.2 Recommendation

#152

Post by dannyobrien »

austincheney wrote: post #137
mastax wrote: post #135

Earlier quoted context omitted.

This is not (uncontroversially) true. See the long discussion below or on any other W3C post on HN.

I don't need to see a comment thread here to understand the process. I have been following this for 20 years, long before there was a WHATWG. Additionally, WHATWG lost some credibility when they attempted to redefine the DOM and arbitrarily delete some node types. Granted, most of those types are legacy types not in use by anybody in long time, except for the attribute node type. Browser vendors simply ignored this f…

I wouldn't mind some extra information you have on this. When I've spoken to folks at the browser vendors one-on-one, they've talked about following WHATWG, rather than the W3C standard, but usually that was in conversations that were critical of the W3C, so it was hard to tell how ubiquitous that position was.

Re: HTML 5.2 Recommendation

#153

Post by foolip »

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

I know it's not quite what you're asking for, but each commit gets its own URL that you can use if you want to refer to a bit of text and know the link won't break: https://html.spec.whatwg.org/commit-snapshots/0184feb8b468f2...

Re: HTML 5.2 Recommendation

#154

Post by xg15 »

domenicd wrote: post #131
xg15 wrote: post #124

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) It's absolutely a fiction, but at the same time, this at least attempts to be a standard. The WHATWG version seems more like a reflection of "oh by the way that's the rules our browsers are following this month. Your's truly, the browser vendors."

> 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 around - there is just a constant stream of changes. (Which is kind of the point of the living standard concept after all)

Re: HTML 5.2 Recommendation

#155

Post by philipwhiuk »

_nalply wrote: post #103

This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references. Ah, hyperbole. I didn't know that humor could be specified.

No post body was provided.

Re: HTML 5.2 Recommendation

#156

Post by sjwright »

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…

Presumably new web browsers will only drop support for styling these elements in standards compliance mode?

Re: HTML 5.2 Recommendation

#157

Post by domenicd »

wolfgke wrote: post #147
Touche wrote: post #139

Earlier quoted context omitted.

Sorry, but you can't print that page and use that forever. I understand that you wish that you could, but you can't. I live in the real world, so rather than reading a snapshot and hoping it stays that way forever, I just read the up-to-date version since that's what is implemented by browsers, not the PDF I saved 3 months ago.

It is a strong liability in a project contract if the standard with respect to which you implement the code changes under your feet.

Given that the browsers with respect to which you implement the code change under your feet every 6 weeks, I think it's better the standard keeps pace with them than having it give a misleading impression of what you're developing against.

Re: HTML 5.2 Recommendation

#158

Post by chrismorgan »

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?

The tag is still necessary because of HTML for emails and Microsoft’s disappointing decision back in 2007 to regress Outlook to using the MSO renderer/editor, which is worse than IE 5.0.

Re: HTML 5.2 Recommendation

#159

Post by ocdtrekkie »

maemilius wrote: post #150
ocdtrekkie wrote: post #145

Earlier quoted context omitted.

Note that your CSS example is longer and requires combining two different syntaxes. And for one change, the difference in length and complexity is much more apparent. > Blah vs. > Blah Which is easier to remember? Which is more obvious at a glance?

The former. The problem is just that you've learned what the latter means better than the former. I'm the opposite. Plus, the former is an absolute value where the latter is not, as far as I've been able to tell. I know that first span will always be 10pt font. I have no idea what "2" even means in this context.

Another commenter did you a favor and explained why using 10pt is worse than using 2: https://news.ycombinator.com/item?id=15927837

Re: HTML 5.2 Recommendation

#160

Post by austincheney »

dannyobrien wrote: post #152
austincheney wrote: post #137

Earlier quoted context omitted.

I don't need to see a comment thread here to understand the process. I have been following this for 20 years, long before there was a WHATWG. Additionally, WHATWG lost some credibility when they attempted to redefine the DOM and arbitrarily delete some node types. Granted, most of those types are legacy types not in use by anybody in long time, except for the attribute node type. Browser vendors simply ignored this f…

I wouldn't mind some extra information you have on this. When I've spoken to folks at the browser vendors one-on-one, they've talked about following WHATWG, rather than the W3C standard, but usually that was in conversations that were critical of the W3C, so it was hard to tell how ubiquitous that position was.

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 level 2, was created in parallel with XML Schema. This is evident when reading some of the W3C mailing lists and comparing release dates of W3C publications.

Attribute nodes can be independently walked when walking the DOM. By removing attributes as a node type you break this functionality. You can use this little utility I wrote as a proof: https://github.com/prettydiff/getNodesByType/blob/master/get...

Browser vendors are extremely shy about adopting new technology that makes for breaking changes. They will do so, but you need to have an incredibly strong argument. WHATWG's changes to the DOM had no beneficial argument, except perhaps developer convenience for those developers who cannot figure out DOM walking.

The DOM is a pretty solid technology with regard to extensibility, predictability, and sturdiness. If you maintain a large major browser and somebody came to you with breaking changes and a bunch of weak bullshit for justifications what would you do? Also, imagine if you will, that if you ever challenge the people bringing you this pile of shit they will troll the hell out of you in a very visible and immature way.

The response from the browser vendors was to simply say nothing and ignore them like they were never there. I got into an argument about this with the WHATWG on a github issue once, and wish I hadn't. Ignorance is like a black hole that sucks everything in and it never stops to allow rational signals to escape undamaged.

Post reply on HN