- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 5 Aug 2008 12:06:42 +0000 (UTC)
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: 'HTML WG' <public-html@w3.org>
On Tue, 5 Aug 2008, Julian Reschke wrote: > > > > > > If you think it is so unlikely, why not make a statement that > > > something that parses as a URI must be a URI under the control of > > > the party minting the identifier? > > > > Would this resolve your use case? > > It would make it better, but I wouldn't still be happy with that > approach. Pity. > > > I'd prefer > > > > > > - the spec to give rules for the formats of these names, so clashes > > > are avoided (if you use a URI, use one you have authority over), and > > > > > > - a more compact syntax (be it QName, CURIE, whatever). > > > > > > - a mechanism that uses the same syntax as in other markup > > > languages, obviously (or is as close to them as possible). > > > > Are all three of these requirements absolute requirements, or would > > you be satisfied with, say, just the first? > > The first one IMHO is essential; the other "only" affect readability. Ok. > > Here are my requirements: > > > > - that the extension mechanism have a fallback mechanism for > > accessibility, e.g. so that you can give a "nearest equivalent HTML > > element" for each extension. > > Sounds like a good thing to have; not sure whether it's always required. I think accessibility is rather important. I wouldn't want to sacrifice what little accessibility we are potentially afforded here. Indeed, this might be, IMHO, the most important requirement. > > - that the extension mechanism be easy to use, e.g. not use any kind > > of indirection, not split the names up to distant parts of the > > document > > "easy to use" is subjective. For instance, with XML namespaces you can > still have the names on the same element; you don't *need* to split them > into distant parts. "easy to use" is subjective, but it is demonstrably true that XML namespaces are not easy to use. I'm willing to be quite flexible on this requirement, but my flexibility ends quite a long way short of a full-on XML-namespaces-like syntax. > > - that the mechanism work or fallback gracefully in legacy user > > agents > > I think it would be sufficient if it works in HTML5 UAs. HTML5 is written with graceful degradation as a fundamental requirement. In fact, it was the lack of backwards compatibility in XHTML2, more than almost anything else, that led to the formation of the WHATWG. So this requirement is so important that browser vendors have proved willing to fork core W3C languages straight out of the W3C to achieve it. > > - that the mechanism allow authors to use whatever naming scheme is > > most convenient for them > > ...as long as there's a *reliable* way to mint identifiers, I don't mind > when people choose not to use that mechanism. As long as they can't > create collisions with the aforementioned ones. Fair enough. I can address your first requirement and all of mine by saying that class names that contain colons must be absolute IRIs. Unfortunately, as you said above, that wouldn't make you happy. (It could be argued that this would also address your third requirment, since it would match HTML4...) If you're willing to sacrifice some uniqueness and some brevity, we could hit all of my requirements and most of yours by using class names of the form "tld.domain.keyword", like Java, and saying that class names with two or more dots and no colons or slashes must use this form. I don't think we can hit all seven requirements fully. If you have any proposals, I'm certainly eager to hear them. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 5 August 2008 12:07:19 UTC