Benjamin SmedbergThe discussions about HTML and RDF have drifted from practical interoperability into theoretical “validity”, purity, and architectural grandiosity. Let’s get back to the specific technical question that needs to be answered: if you embed RDFa in HTML5, does it parse into a usable DOM? If not, are there specific changes to the parsing specification that will allow it to parse to a usable DOM?
Paraphrasing Mark Pilgrim, you are missing the point. The HTML5 specification is political manifesto, cleverly disguised as a specification. Other examples:
alt attributes. We spent 1/3 of today’s HTML working group call (literally: 20minutes out of a nominal 60 minute meeting) talking about the wisdom of requiring an alt attribute.
In none of those twenty minutes did we talk about any specific change to any specification.
Any specification for something that underpins so much of human endeavour is bound to appear manifesto-like. It’s like saying that acts of parliament are political statements cleverly disguised as laws. They’re not disguised as anything. They’re one and the same. It’s unavoidable.
Having said that, if there are use cases for which we need a technology like RDFa, then we should make sure it does work. Finding the former is proving harder than I expected, so maybe there actually aren’t that many use cases, and we can address them with more targeted solutions; but if we do decide that we’re going to support RDFa, then the questions you quote Benjamin as asking would be important.
I actually read those transcripts, and everything else. And the specifications. It hurts. A lot. You guys have more guts and determination and grit than I do. I may not agree with you on all the decisions that get made, but more power to ya. Good luck. I’ll stick in the private sector where I can just bully people at will.
I guess I’m not sure I understand why it’s important to find a use case for RDFa within HTML. I’m sure I’m missing something here, but it seems to me that the goal ought to be to enable other people to embed stuff that the original spec writers never would have imagined. Shouldn’t the language simply be something along the lines of, “You can embed stuff willy-nilly, but a) don’t expect the browser to know what you’re talking about and b) if you’re a browser, ignore anything you don’t understand, and all of its child elements and attributes.” And then make sure there’s a functional mechanism for letting browsers gracefully handle whatever it was you embedded but that they didn’t support.
Anyhow, clearly, I don’t pay anywhere near enough attention to HTML5.
I’ve heard it said that things that are impossible just take longer. And there certainly is a point after which the adjective benevolent no longer applies.
The relationship section I cited is entirely avoidable.
The selection of a pejorative DOCTYPE is entirely avoidable. This item alone certainly seems like it qualifies as a exemplar of Sayre’s Law.
The HTML5 specification could simply state that the alt attribute is optional, leaving to others the layering on of additional constraints.
Henri’s validator may or may not enforce those additional constraints. It may or may not accept RDFa. In either case, if it is important enough to enough people, I’m sure that somebody will fill that gap.
Bob Aman has it on the nose. The big problem with shunning an extensible mark-up language as the basis for HTML is that you then have to figure out how to deal with a plethora of specific extensibility cases (or decide not to, leaving the whole thing up in the air), manage to do it in a consistent way and a manner which is consistent with the XML-based serialisation yet different enough to the latter to justify it not being XML in the first place.
The whole thing’s insane. Most professional web developers I know care about only one aspect of HTML5: the part which attaches an attainment label to all of the stuff the “good” browsers have supported for ages, because “HTML5-compatible” is a hell of a lot less wordy than saying “the standards-compliant browsers”, but unfortunately no less ambiguous. The new stuff? Nobody cares. The extensibility stuff? That’s what XML was invented for, and why HTML has an XML serialisation. At this rate, we’ll have all retired before anything really is HTML5 compatible.
How about imposing a procedural rule like “if you can find two major browser vendors willing to implement your pet proposal for an extension to HTML, we will consider it, otherwise keep it for HTML6”. I’m pretty sure semantic nonsense like RDF* will fall to the wayside, while genuinely useful stuff like the Canvas widget stays.
Sam: We have ample evidence showing that people copy DOCTYPEs around on the basis of nothing more than which one looks most formal. Thus if we want to encourage people to use the shorter DOCTYPE, it makes sense to make the longer one (which is only longer to enable certain legacy uses) be something that doesn’t look formal. I don’t really see why this is a problem or controversial.
Regarding the alt="" attribute: we don’t want to say that alt="" should be optional, because that would be an accessibility nightmare. It isn’t optional, it shouldn’t be optional.
I don’t think it makes sense to have the HTML5 spec only define an incomplete language. What else should we leave out? The title="" attribute? How about how to construct a table from <table> elements? No, the spec should be a complete spec for the language it defines.
Regarding the extensibility mechanisms — HTML5 already has literally over half a dozen extensibility mechanisms: [link]
The problem with RDFa isn’t that it can’t already be done using the existing extensibility mechanisms (I haven’t checked if it can); the problem is that if there are use cases so important that there is an entire W3C community built around it, then maybe we should support them natively in the language. The discussion right now is just a matter of finding out whether or not these use cases are important enough, which is a judgement call based on problem descriptions.
Fazal: HTML5 already has that procedural rule: [link]
Fazal: the answer to Benjamin’s original question may very well be that there is zero that browser vendors need to implement in order to allow RDFa to be conformant.
First I’ll note that you entirely skipped over the proprietary languages issue. As Maciej indicatesI think that sort of thing could go without saying in an open standards specification. Which brings us back to the question: is this meant to be a standard or a manifesto?
I don’t really see why this is a problem or controversial.
The HTML5 specification could simply state that the alt attribute is optional, leaving to others the layering on of additional constraints.
Or, you know, leave @alt mandatory, since none of the “others” asked HTML5 to take this up in the first place.
I don’t like taking up my time arguing over this, either. You’re right, HTML5 is a political manifesto. If it weren’t, this change would never have happened in the first place. There’s no pressing need to deviate from the status quo.
Quotable Quote The HTML5 specification is political manifesto, cleverly disguised as a specification source: Sam Ruby Googles boy Hixie’s HTML5 editorship helps Google to keep raking in the bucks at the cost of the web Again, the issues here are...
For the record, I think that making Sam Ruby a chair of the HTML5 working group is a good sign, in a dismal process. Credit Sam with pointing out bits that are just wrong. The DOCTYPE section is a good/bad example. A DOCTYPE is a mostly useless, but...
The HTML5 specification is political manifesto, cleverly disguised as a specification. Cleverly ? De l’intelligence qui fait inventer l’eau chaude alors....