Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

w3.org

Post reply on HN
Print view View original

271–280 of 287 posts

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#271

Post by rangerpolitic »

dmitriid wrote: post #140
rangerpolitic wrote: post #95

Earlier quoted context omitted.

> Did you miss the 5-10 years during which every CSS designer tortured themselves replicating tables with floats? I never really understood why people had such difficulty with this. I was able to execute table-less layouts while still supporting IE5 on Mac. > To this day, changing a site's entire design without touching its markup is a mirage. That's only because HTML authoring is dead. No one writes HTML well these…

> Write well-structured, semantic HTML being mindful of a separation of concerns I keep hearing about this mythical beast, and yet I have never seen one beyond the simplest of text-only blogs.

You don't see it because either (a) people don't do it or (b) people are using HTML as a markup language for apps rather than documents.

HTML was created to be used for documents. It was coopted to be used for apps. They really should have come up with a different language for apps.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#272

Post by rangerpolitic »

jandrese wrote: post #220
rangerpolitic wrote: post #95

Earlier quoted context omitted.

> Did you miss the 5-10 years during which every CSS designer tortured themselves replicating tables with floats? I never really understood why people had such difficulty with this. I was able to execute table-less layouts while still supporting IE5 on Mac. > To this day, changing a site's entire design without touching its markup is a mirage. That's only because HTML authoring is dead. No one writes HTML well these…

Can you give us a link to your elegant table-less IE5 supporting website? I would like to see how you achieved it. I lost a lot of hair trying to make a simple 3 column layout where the middle column would scale to the width of the window and could consist of multiple DIVs in a vertical row, all of the same width. AKA "baby's first blog" layout. Something that should have been one of the design cases for CSS.

> Can you give us a link to your elegant table-less IE5 supporting website?

I cannot. They no longer exist. This was 14 years ago. I left web development shortly afterwards.

For your example, horizontal alignment was easy. One container div with a width of 99.9% and a left/right margin of auto. Inside you place three divs (columns) with a width of 33.3% and float left. Add another div at the end to clear the float.

Vertical alignment required a "hack."

http://www.greywyvern.com/code/min-height-hack

And to be clear, I never called it "elegant." I simply suggested it was possible.

Should CSS have been better? Sure. But, by that measure, it still sucks today.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#273

Post by tannhaeuser »

om2 wrote: post #268
tannhaeuser wrote: post #263

Earlier quoted context omitted.

The narrative that "HTML5 looked at what browsers do, rather than following ivory tower SGML" is simply a myth and not backed up by facts. Ian Hickson introduced sectioning elements, the whole flawed outlining algorithm idea, and the aside element (presumably to make it easier to tell ads from content for Google's crawler), with lots of controversities at the time. The HTML spec is also chock full of inconsistencies…

The HTML parsing algorithm looked at what browsers do. WHATWG HTML also included other innovations, some of which didn’t entirely work out. Nowadays, new additions are not added so loosely and there is a better defined working mode and governance policy.

"Government policy" yeah right. Chrome implements stuff, and Moz has to follow suit; then it gets prescribed in WHATWG's spec. OTOH, stuff introduced by Moz that Chrome doesn't implement gets removed from the spec. Such as much needed new elements for basic declarative UIs (menu, menuitem) to fight over-reliance on JavaScript and CSS hacks, introduced by FF but boycotted by Chrome. As was part of the WHATWG snapshot on which W3C HTML 5.1 was based, and removed in W3C HTML 5.2. There's no evidence Hixie analyzed "what browsers were doing". There is, however, evidence that Hixie just made up new elements as he saw fit [1].

[1]: https://www.webdesignerdepot.com/2013/the-harsh-truth-about-...

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#274

Post by lucideer »

lstamour wrote: post #209
lucideer wrote: post #208

Earlier quoted context omitted.

I really really don't mean to be dismissive here, but... you know the WHATWG largely emerged as an backlash against the W3C's efforts to create an extensible standard for allowing authors to create custom elements (what's more, they would be namespaced with actual schema, a la react prop-types, or—later—Typescript interfaces), with extensible forms (xforms). This is a process started in the late 90s! Two decades late…

It's important to note, nobody's being forced to use custom components or new syntax by specification, though as deprecations occur it's possible based on usage statistics that services like Google or new browser security or performance improvements could affect your site. And speaking to XML for a sec, while XHTML's backwards compatibility problems could have been avoided by specifying some kind of graceful fallback…

Tiny off-topic side-not on E4X: it was extremely popular in it's time... for extension author, GM scripters, XULers, anyone who had the freedom to use it without the concern of cross-browser compat. I think its failure was either one of standardisation bureaucracy, or of odd cross-client resistance to implementation, rather than it not being tech people wanted.

> I would say it's remarkable how many standards on the web apparently don't have anything to do with HTML.

I took the thrust of the original comment I responded to above to be giving WHATWG and general living/rolling-spec. process credit for increasing the pace of useful/practical/needed web innovations. I was pointing out that many of the cited examples of useful innovations were created either before WHATWG existed, or at least outside of WHATWG process, and that the majority (admittedly not all) of what the WHATWG has actually contributed has been superfluous cruft. That's the intent of my separating "this is part of HTML5, this isn't". Obviously many things are/can be subsumed into HTML5 as that's where they belong taxonomically, but I'm focusing on inception and what benefit living-standard process brings.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#275

Post by CM30 »

clairity wrote: post #245
CM30 wrote: post #242

Earlier quoted context omitted.

This times a million. And for anyone who needs some bona fide examples of new standards and updates that are useful from the WHATWG specifications, well how about: New semantic elements like header, footer, section, article, nav, aside, main, etc. These are far better for making logically structured pages than a ton of divs with class names would be. The various new input types and attributes. Now you can have input…

if only all of those things were fully flushed out in the various browsers... for instance, it disheartening to realize that it's been 15 years already and useful form elements like date(-time), phone, and email still don't have reliable and complete cross-browser behaviors, validation (i know it's hard, but still), and styling/event hooks.

True, support still isn't perfect. The calendar/date picker stuff is especially annoying here, since it really should be easier to customise and more similar cross browser than it currently is.

But most of the things mentioned do work in more browsers than not, and you can use them without worrying the site will break in almost all cases. The new semantic elements will never have issues (unless you're trying to target IE8 or below), the validation works fine in pretty much all modern browsers (as do simple styles for it) and support for the picture element and srcset are pretty good too.

The likelihood of anyone using the Blackberry browser or IE mobile is small enough to ignore.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#277

Post by dmitriid »

rangerpolitic wrote: post #271
dmitriid wrote: post #140

Earlier quoted context omitted.

> Write well-structured, semantic HTML being mindful of a separation of concerns I keep hearing about this mythical beast, and yet I have never seen one beyond the simplest of text-only blogs.

You don't see it because either (a) people don't do it or (b) people are using HTML as a markup language for apps rather than documents. HTML was created to be used for documents. It was coopted to be used for apps. They really should have come up with a different language for apps.

Why people don’t use it in a) would be an interesting discussion. And I fully agree on b): HTML (+ CSS) is wholly inadequate for app development.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#278

Post by spiralx »

lilyball wrote: post #230
boomlinde wrote: post #105

Earlier quoted context omitted.

> You keep repeating "semantically sound" but I can't fathom what that means in your context. Documents built on the principle that their structure should relate to the meaning of their content rather than its presentation are what I consider "semantically sound". By negative example, an HTML document filled with div pyramids just to apply layout information, and obtuse class and id names are not what I consider sema…

One of the interesting things you could do with XHTML was ditch the HTML entirely and write an XML document expressing the semantic content, and then couple that with an XSLT stylesheet to convert it into XHTML for display. This way the exact same resource could be read by machines to get the semantic content, and then read by browsers and transformed into the display content. I'm not sure if anyone ever actually use…

I wrote an XSLT stylesheet that could turn an XHTML document into a display of its own source, complete with indenting, code folding and syntax highlighting. I was quite pleased with that :)

When I worked at the BMJ all of our content was stored as XML and rendered to the browser using XSLT, although this was done on the back-end and the resulting XHTML embedded in our various Spring applications. This sort of thing is probably the most common use of XHTML today...

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#279

Post by spiralx »

amyjess wrote: post #122
boomlinde wrote: post #48

Earlier quoted context omitted.

> These are the same people who created XHTML, an ivory tower idea nobody was waiting for... who didn't support the most popular layout method at the time, tables, in their new styling language CSS. You certainly could lay out pages using tables in XHTML, but the point of the standard in the first place was to enable semantically sound documents for the sake of interoperability and to facilitate separation of concern…

I honestly don't think either was the purpose. XHTML existed to make parsing easier. The only things you couldn't do in XHTML 1.1 Transitional that you could do in HTML were having unclosed tags and using uppercase in tag names. That's it. Now yeah, the strict version tried to force you into semantically sound documents... but that was completely orthogonal to XHTML vs. HTML. Both XHTML and HTML were available in bot…

Could you have unquoted attributes in transitional?

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#280

Post by bzbarsky »

tannhaeuser wrote: post #263
bzbarsky wrote: post #203

Earlier quoted context omitted.

> WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance I don't think that's a fair characterization at all. Ian Hickson was pretty intimately familiar with the SGML formulation of HTML. What led to that being dropped was that no browsers implemented it in practice and that trying to implement it as written in the HTML 4 standard actively broke web pages (which had been written aga…

The narrative that "HTML5 looked at what browsers do, rather than following ivory tower SGML" is simply a myth and not backed up by facts. Ian Hickson introduced sectioning elements, the whole flawed outlining algorithm idea, and the aside element (presumably to make it easier to tell ads from content for Google's crawler), with lots of controversities at the time. The HTML spec is also chock full of inconsistencies…

I'm not saying HTML5 didn't have its share of architecture astronauting, attempts to add features that didn't pan out, etc. Trust me, I know it did.

I'm not saying it didn't spec various things that didn't match browsers (some just because, some because it tried to reverse-engineer browsers and failed). Well do I know it did; we're still sorting some of those things out. The only defense there is that unlike previous web specs it actually tried to specify this stuff (like navigation!) instead of just saying "yeah, do whatever".

The element name thing was actually needed for compat with how browsers parsed HTML in practice. The ID thing largely affects well-formedness, but was also informed by common practices, and the mismatch with CSS in large part was probably somewhat unavoidable due to differences in reserved chars. For example, there's really no reason, within the context of HTML, to not allow "foo.bar" as an ID, and people were definitely using IDs of this form all over, whereas in CSS you'd need to jump through the "#foo\.bar" hoop to use it in a selector.

SGML comments were definitely _a_ big problem (I'm not sure why you decided to describe them as "the" problem). This sort of markup:

  
    This is still comment, because the '>' is inside the comment the third double-dashes started, yes?
was fairly common: people like to use "--" as a replacement for em-dash and it often ends up in the middle of comments. Browsers that attempted to implement SGML comment parsing would end up with the "This is still comment text commented out; other browsers did not.

> presumably to make JavaScript commenting uniform with HTML syntax

No, that was there to enable hiding of tag contents from browsers that didn't know about at all. So you would write:
and in a non-script-aware browser you wouldn't have a blob of script text showing up... It's actually a pretty sane approach for the problem of initially introducing the element in a world where it didn't use to exist.

> In any case, WHATWG has driven almost all web browsers out of existence already

I'm not sure the problem here is "WHATWG" per se. I'm pretty sure that if WHATWG had never existed the results would have been pretty similar...

Post reply on HN