- From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
- Date: Wed, 03 Dec 2014 15:30:00 +0100
- To: Julian Reschke <julian.reschke@gmx.de>, "Jukka K. Korpela" <jkorpela@cs.tut.fi>, whatwg@lists.whatwg.org
Julian Reschke <julian.reschke@gmx.de> writes: > On 2014-12-03 15:02, Jukka K. Korpela wrote: >> 2014-12-03, 15:49, Julian Reschke wrote: >> >>> I have a use case where a certain location in a document can have two >>> anchors (or even more). For instance, in a spec, the author may have >>> specified an anchor, but a section-number based anchor is required as >>> well. >> >> Can you elaborate on that? Why cannot you use the same id attribute >> value in all references to an element? > > 1.) An author-supplied anchor may change, but you want to preserve > existing "deep" links from other documents. The solution seems simple to me: Do not change the anchor id, ever. Alternatively, wrap the element in a div with a new id. > 2.) You may want to support anchors based on section numbers which will > allow other parties to link to a specific section of the document while > only knowing the section number and a template (think references to > sections numbers in RFCs over on tools.ietf.org). I suspect that “section number” and “id” refer to different concepts. >>> How about a new attribute "alt-ids" which would take a space-separated >>> list of additional anchors? >> >> What would be the use of such additional identifiers? > > See above. Essentially aliases for anchors. > >> The only thing I can imagine right now is a situation where you have an >> existing id attribute and references to it all around but now need to >> refer from a context that imposes its own restrictions on the syntax. >> Say, you have id="παράδειγμα" and you need to refer to the element using >> a URL like http://example.com/foo.html#παράδειγμ" but cannot because >> the URL needs to be used in an environment where Greek letters cannot be >> used. But this sounds like a rather rare occasion. > > It's yet another use case that could be addressed that way. I think this use case could be solved by either URL encoding or transliterating to ASCII. -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Received on Wednesday, 3 December 2014 14:30:40 UTC