- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 3 Aug 2008 22:09:50 +0000 (UTC)
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: 'HTML WG' <public-html@w3.org>
On Sun, 3 Aug 2008, Julian Reschke wrote: > > > > Education is expensive. Why not just make it unnecessary? > > If you can make it unnecessary without suffering from other drawbacks, > like chattiness, unreliable disambiguation and unnecessary mapping > problems to other specs, fine. Using a domain name followed by a hyphen followd by a word seems to solve all of these simply. > > > > One finds people confused about many things, but honestly I have > > > > rarely found any concept that causes non-geeks more confusion than > > > > the concept of indirection. Namespace prefixes are nothing more > > > > than indirection, that's their entire reason for being. > > > Class names use indirection as well. > > > > How so? > > It's first level indirection in that you specify a class name, instead > of adding the style information in place. In addition, it uses > inheritance with exceptions, plus cascading, and - in HTML5 - scoping. > > I'm mystified how a web developer can get *that*, and fail to understand > prefixes. Sorry. Oh for styling. Authors have had huge problems with that. It's actually quite humbling to try to teach CSS to someone who hasn't ever learnt the way of the Web, because they never ask "How do I make headings red?" they ask "How do I make this piece of text red?". The indirection of class names in CSS is a huge problem too. > > Why? Are you concerned that people using different dismabiguation > > schemes would somehow come up with clashing names? How would that > > happen? Could you give an example? > > Of course that could happen. For instance, when using domain names, is > the TDL right (URI) or left (Java packages). And so on. Could you actually give an example where this could happen? I haven't been able to find a case where an actual clash could happen. Consider that even without any sort of disambiguation mechanic other than just picking unusual names, Microformats has had no serious problems with clashes. If you add domain names to the same thing, the problem really becomes moot. It's like saying that you can't use checksums for disambiguating things because you might have a clash. > What if you don't have a domain name, and prefer a UUID. Or a URN? Or a > date-stamped URI (tag: URI scheme)? URIs give you the choice. class="C4E15D82-61A2-11DD-977B-B4AD55D89593" class="isbn:0674003810" class="ian@hixie.ch,2008-08-03,category" None of these are ambiguous. They don't even have to use the same scheme -- since they're all completely opaque, so long as you generate something that is unambiguous, you will know that it can never clash with someone else's. No need for URIs. But _you_ can use URIs if you want to. > > > Again: who is "we" in this case? Certainly not the HTML WG. > > > > So you're in favour of the behaviour seen in the browser wars where > > people just made up their own tags all the time? > > > > I am not. > > I am in favor of being able to use new vocabularies without getting the > WHATWG's or the W3C's approval first. The price for that is that I have > to put them into a separate namespace, and that is totally fine. It > works everywhere else. If the price for that is that you have to use a syntax intended for this use, which is in a different _syntactic_ space than the language's main vocabulary, is _that_ an acceptable price? > > If you are using the scheme="" attribute for Dublin Core metadata, > > could you point me to the part of the spec that defines what the > > semantics of scheme="" values is? How would an independent Dublin Core > > processor know how to interpret the scheme="" values? > > I can't answer that, and that is a problem of that standard. Ok, well, until someone can tell me what the attribute actually does, and show that's there's a real, widespread need for it, let's not add it. > That still don't gives us the mandate to simply drop the attribute. Actually, we have the mandate to drop anything we like in the whole language. Or add anything. > Also, HTML4 says the interpretation depends on the profile attribute, so > again, pages can opt into a specific behaviour if they choose to do so. Since we've also not included the profile="" attribute... We have other mechanisms now that are much more flexible for including private metadata of all kinds, e.g. data-*. > [GRDDL] The GRDDL maintainers should make the following changes to GRDDL: 1. Don't require profile="http://www.w3.org/2003/g/data-view" to support link rel=transformation. 2. Don't require transformations to look for profiles before applying their transformations. Having done this, you now no longer need profiles to be declared, without losing any functionality. We're not keeping profile="", evidence is overwhelming that authors rarely use it and, if they try, use it incorrectly. We're not including things that are much more widely used (e.g. <font>). The bar for adding a feature to HTML5 is high. profile="" doesn't even come close to qualifying. It's not even actually solving a problem that needs solving, it's just a way to declare something that you can just assume anyway. Indeed, it's similar to a DOCTYPE declaration. > If you insist on removing it, then please: > > - get WG consensus to do so, http://lists.w3.org/Archives/Public/public-html/2008Jul/0354.html > - explain to HTML4 users the replacement strategy, Do exactly what you did before, just without the profile="" attribute. This is what most authors are doing anyway. > - work with the other standards groups (in this case GRDDL) to get the > spec updated to use the other format. http://lists.w3.org/Archives/Public/public-grddl-comments/2008JulSep/0003.html -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 3 August 2008 22:10:30 UTC