- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 22 Jul 2009 09:50:19 -0500
On Wed, Jul 22, 2009 at 7:02 AM, ppj<ppj at concept67.net> wrote: > On Wed, Jul 22, 2009 at 06:50:33AM -0400, Darxus at ChaosReigns.com wrote: >> On 07/22, ppj wrote: >> > e.g. <a href='...' search='...'>link text</a> >> >> I've wished for this a number of times, but I think I would be more >> interested in the spec saying that a document should include id tags at >> every point someone might want to link to which the author of the document >> is willing to provide. >> >> It seems odd to me that the definition of the id attribute doesn't mention >> its use as a fragment identifier. >> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-id-attribute >> >> -- > > Hi, > We played with filling documents with ids a lot. This is not a bad idea, but > the users (imho) want to link to text first and foremost. So I'm > suggesting we could let them. > > Folks have suggested XPointer vs. attribute hack on the <a> element. But I would > prefer the element to have something superficial ordinary people can > understand, even if behind the scenes the browser turns that into XPointer. > What's the present rate of user uptake of XPointer? It would be relatively simple to expose a UI that allows one to point at some text and automatically generate an XPointer to the element containing that text. Assuming that you could then generate a url with that information (which would take browser cooperation), you'd be golden. I am generally against anything that would change the target of a link, but isn't representable in the actual url. Anything I can click, I should be able to copypaste into my browser's location bar and get identical results. ~TJ
Received on Wednesday, 22 July 2009 07:50:19 UTC