- From: ppj <ppj@concept67.net>
- Date: Wed, 22 Jul 2009 11:36:02 +0000
On Wed, Jul 22, 2009 at 12:19:04PM +0200, Julian Reschke wrote: > Nils Dagsson Moskopp wrote: >> Am Mittwoch, den 22.07.2009, 10:38 +0000 schrieb ppj: >>> The Goal: Links w/o anchors. >>> The Strategy: Two >>> stage process. 1) get an extra 'search' attribute on to the <a> tag >>> in HTML so that we >>> have: e.g. >>> <a href='...' search='...'>link text</a> >>> 2) If there's take-up, then later on push for adding a date-time of >>> creation attribute to <a>. This will add link history to >>> the internet. >>> The way (1) works is someone sticks >>> the basic href to a page in the href >>> attribute, and then sticks the text they want to link to in the search >>> attr. The browser fetches the page, and as a secondary action (at user >>> option) searches for the text. The simple option is that it just >>> searches for the plain string, >>> maybe later it can do all the fancy approximate match stuff that I put >>> in the XPunt prototype in '06/07. >>> Since we know those search strings don't have to be very long to find >>> the unique location, it shouldn't burden the document text very much. >>> >>> >> >> An additional element seems very hackish; this likely is something >> better brought up in the context of an URI working group. I would also >> recommend talking to implementors directly. > > Fragment identifiers depend on the MIME type, thus it's in scope for the > HTML WG (which is in charge of text/html and application/xhtml+xml). > > ...but do consider existing work in this area, such as XPointer... > > BR, Julian Does XPointer trigger a behaviour in the browser as a basic behaviour? Seems as though few users on the web are using XPointer to create links, and even if they do, the browsers don't support this behaviour. Why would ordinary people, who create the majority of links, find XPointer useful to use? Kind Regards, Peter
Received on Wednesday, 22 July 2009 04:36:02 UTC