- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 7 May 2008 00:35:50 +0000 (UTC)
Summary: profile="" doesn't work in practice so we have dropped it. We haven't replaced it with anything since there isn't really a problem to solve -- conflicts don't occur in practice, as Microformat names are picked to be rather unique and recognisable. The market takes care of problems like this without the need for namespace syntax. On Mon, 18 Apr 2005, James Graham wrote: > > Indeed. But, unless I'm missing something, the current spec totally > fails to address the use-case of multiple profiles per document in any > sort of useful way whatsoever. It seems entirely reasonable that people > will want to include multiple profiles (since e.g. licensing and XFN > type metadata is entirely orthogonal) so simply stating "authors are > encouraged to avoid using multiple profiles" is, IMHO, a real problem. This is resolved these days by the simple solution of not picking conflicting names. It seems to work pretty well in practice. [snip various proposals to reinvent xmlns="" but for profiles] On Mon, 13 Jun 2005, Hallvord R M Steen wrote: > > Regarding the following point from the "wishlist" of the specification: > > > Better defined user authentication state handling. (Being able to "log > > out" of sites reliably, for instance, or being able to integrate the > > HTTP authentication model into the Web page.) > > It would be nice if the UA could have a unified "logged in" interface > for both HTTP authentication and form login. > > I suggest a new LINK rel definition: > > <LINK rel="logout" href="/logout.cgi" /> > > The presence of this tag indicates to the UA that the server considers > the page a part of an authenticated session. This tag can be used by the > UA for having a "logged in" indication and a "log out" feature in its > UI. It might also be used by the UA to (optionally) automatically log > out when the user closes the window or the application. > > Perhaps we want to add rel="login" too? I don't really understand how this would work with HTTP authentication. Can you elaborate? On Tue, 12 Dec 2006, Mike Schinkel wrote: > Ian Hickson wrote: > > You *are* aware of vCard, you can design your metadata structure with > > it in mind. If you are worried about clashes, then stick a prefix on > > your class names. > > Less optimally than if I can do it in my own "context/namespace." > > > I honestly don't expect people to use both vCard and your format. > > *I* want to use vcard AND my format (for my website.) So I've just > turned your expectation false. Sure, but you know about both, and have control over your format. > > They'll use whichever one does what they need it to do (typically the > > most popular one), and ignore the others. > > That indicates to me you are not operating in the real world where > formats are often dicated by external business factors. If two companies > each say "markup using *our* preferred format" and those markups > conflict, one has to choose. Yup. > > In the market place, out in the "real world", conflicts will be > > resolved by either the languages changing to adapt to each other, or > > by some of them being made obsolete and irrelevant by other more > > successful ones. > > That is an idealistic view which is plain false because you can get two > entities that are each large and powerful each specifying a conflicting > microformat yet there are not in the same industry so they don't see the > conflict. However, the few small companies that work with both companies > don't have enough influence with either company to get them to change, > so they get screwed (all because Ian' thinks this isn't a real world > problem.) Well, in the 4 years we've been doing this HTML5 thing, this hasn't happened. I don't see why it would happen. > Maybe the problem is you work for Google, who can dictate, and not for > small companies that get dictated too, so you don't see the problem. I've worked for small companies too. In fact, when this part of the spec was last edited, I worked for Opera. On Tue, 12 Dec 2006, Martin Atkins wrote: > > I'm not sure if you are actually proposing what I'm proposing or if > you're just mentioning this in passing, but it seems to me a reasonable > compromise to create a registry of *container* classes which can contain > microformats or other extension stuff. Since these things only have to > be used once, they can be a little bit obtuse to avoid conflicts with > author-invented classnames. > > You just need to mention in some spec (which, in theory, doesn't even > have to be the HTML5 spec, since "class" is just an list of opaque > strings as far as HTML is concerned) that there will be a registry of > container classes which will all have some common prefix and that within > that container anything goes. > > Some arbitrary new microformat "foo" could then be assigned (for > example) the prefix "x-foo", into which it can plonk whatever it likes: > > <div class="x-foo"> > <div class="cheese">Cheddar</div> > </div> > > [...] > > If any of the inner classnames conflict between schemas, they can be > disambiguated in CSS and elsewhere using contextual selectors. As far as I can tell, you just basically described how Microformat specs work. On Tue, 12 Dec 2006, Robert Sayre wrote: > > I've gone back and forth on this one. The idea that one can take short > names and "ground them in URI space" by doing profile= or xmlns= or > whatever is a siren song. It does seem to solve squatting and naming > clashes... but those pesky authors tend to ruin it. It's almost like > they have better things to do that worry about rigorous markup > generation systems. > > Perhaps it's cheaper to make up your own root element and MIME type. I > can't think of many complaints concerning clashes of <title> elements in > documents with no namespaces. > > Claiming that HTML5 must qualify class names with the profile attribute > makes it seem like we're at an impasse. We're not. I don't see any > evidence that the profile attribute is more necessary in HTML5 than it > is in HTML4 or HTML6. Besides, it's so dependent on the idea of a single > source document that it will never survive tranlation to fragments in > syndication feeds, livejournals, and myspace pages. Indeed. On Tue, 12 Dec 2006, Michel Fortin wrote: > > The only reason this is supported in my proposal is for when people want > to define their own extension without having to register it with anyone. > If someone wish to have a short name, it has to be registered. > Obviously, hCard will have a short name, so there is little reason to > use the long form. If someone wants to have a widely used standard, it has to be registered in the public consciousness somehow, yes. > I'm not arguing that everyone would need to change hCard on their > website once HTML5 becomes a recommendation. hCard is already deployed > as it is and tools still need to support that syntax. But for the > future, using a profile attribute instead would ensure that existing > documents do not become non-conformant the day a new extension is added. HTML4 required profile="" for this kind of thing, as did Microformats, and few people bothered. I don't see why we would continue down this obviously failed path. > I'd like to add that the same problem can exists in reverse too: there > is always the possibility that someone influent, through the deployment > of software or by other means, carelessly popularize a class also in use > by a microformat. This would make the microformat unusable on the web. > The more microformats there are, the bigger are the risks that this > happen. If it happens, one or the other is adapted, and things can go merrilly on their way. No need for anything complicated like profile="". [snip other arguments along the same lines as the above] -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 6 May 2008 17:35:50 UTC