[whatwg] alternate ids for elements
Hi there, 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. Right now I can address this by inserting an additional div element, but this is kind of ugly, and doesn't scale well. How about a new attribute alt-ids which would take a space-separated list of additional anchors? Best regards, Julian
Re: [whatwg] alternate ids for elements
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? 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? 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. Yucca
Re: [whatwg] alternate ids for elements
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. 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). 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. Best regards, Julian
Re: [whatwg] alternate ids for elements
Julian Reschke julian.resc...@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
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
On Tue, Dec 2, 2014 at 6:04 PM, Boris Zbarsky bzbar...@mit.edu wrote: Actually, sandboxing iframes of your own site is one of the main sandbox use cases: it allows limited user upload of content without creating security holes, in theory. No it is not, only if you use it in combination with srcdoc you are safe. Otherwise an attacker could trick the user to navigate directly to the file and steal cookies or origin-bound data. (The solution here is to finally fix the clipboard stuff. I believe both Gecko and Chrome have similar plans to address this case judging from their mailing lists. It would be good if those discussions moved into a spec space.) -- https://annevankesteren.nl/
Re: [whatwg] alternate ids for elements
I too have run into this (specifically wanting to preserve old deep-links) and think it would be reasonable, in theory. However, in practice I see no reason for browsers to expend valuable engineering resources on this when an empty `div` (or, more traditionally, an empty `a id=/a`) suffices to give the same functionality.
Re: [whatwg] alternate ids for elements
Domenic Denicola d...@domenic.me writes: I too have run into this (specifically wanting to preserve old deep-links) and think it would be reasonable, in theory. May I ask why you changed the element ids at all? However, in practice I see no reason for browsers to expend valuable engineering resources on this when an empty `div` (or, more traditionally, an empty `a id=/a`) suffices to give the same functionality. I believe this to be wrong – an empty element does not give the same functionality; a wrapping a or div element, however, does that. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] alternate ids for elements
On 3 December 2014 at 14:15, Julian Reschke julian.resc...@gmx.de wrote: 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). another way to do this is let people link to parts of a document based on CSS selectors rather than author-defined IDs. One such proposal is http://simonstl.com/articles/cssFragID.html, whereby you could link to -say- the fifth h2 using http://example.com/lorem.html#css(h2:nth-of-tyupe(5)), whether or not the author had put an ID on the h2. bruce
Re: [whatwg] PSA: Chrome ignoring autocomplete=off for Autofill data
Just to follow up on this for archival purposes... In Chrome M40 (possible even sooner) the proper input and change events are triggered for both form and password autofill. Good job guys! Safari 7 and 8 are still broken. In FF 34 the form autofill works well but password autofill doesn't fire any events. Things are still pretty broken for many end users but we've already made major progress. Yay! \i On Fri Nov 14 2014 at 8:12:33 AM Igor Minar imi...@google.com wrote: I believe so, but I'll double check and will email you off this thread. \i On Thu Nov 13 2014 at 11:06:37 PM Evan Stade est...@chromium.org wrote: That sounds like crbug.com/354257 which was fixed in March. Are you sure this is still a problem on newer versions of Chrome? On Thu, Nov 13, 2014 at 8:22 PM, Igor Minar imi...@google.com wrote: Are you going to properly fire changeinput events when autofill happens? The current autofill behavior is causing major headaches for application and framework developers and by ignoring autocomplete attribute you disable the only way developers can work around this bug. On angular we had to developer a special hack in an attempt to fix it, but it's far from ideal: https://github.com/angular/angular.js/issues/ 1460#issuecomment-33837127 The browser should let DOM know when autofill happens, so apps can treat user input and autofill as the same. Right now this is not the case and it sounds like you are going to make it only worse. \i On Thu Nov 13 2014 at 11:20:28 AM Evan Stade est...@chromium.org wrote: Hi, Chrome already ignores the prevalent autocomplete=off for password fields. We plan to ignore this tag for Autofill (addresses, credit cards) fields as well. autocomplete=off will still be respected for autocomplete data (e.g. past searches on crbug.com). We think this will break a very small number of sites that use autocomplete=off for legitimate reasons, e.g. they use the Google Maps Places Autocomplete API, and don't want Chrome trying to autofill in addition. But it will improve behavior for a much larger set of sites which use autocomplete=off for confused reasons as a part of, e.g., their checkout flow. We have found the prevalence of autocomplete=off in top sites' checkout forms to be quite high. Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete=off. I am curious what other browsers do around autocomplete=off, and if they respect it for address/user profile/credit card type data. Since there's no way to feature detect the browser's behavior, it would be convenient if all browsers agreed on the meaning/value of the attribute. -- Evan Stade
Re: [whatwg] alternate ids for elements
Nils Dagsson Moskopp writes: Julian Reschke julian.resc...@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 ... 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. But what if the original ID used had a typo in it? Or a product name has to change for legal reasons? It's entirely reasonable for anchors to be ‘meaningful-to-human’ IDs that are indicative of the section they are labelling, and for section names to change over time. For instance, Wikipedia pages have an ID for each section which is based on the section name. Every time somebody edits a section title, the anchor changes ... and any external links specifically to that section break. There are far too many broken links on the web of this form, where the link goes to the correct page but includes a non-existent anchor. Quite often the intended section is still on the page, just with a new anchor. Letting sites keep old anchors working would be a benefit for users following external links to them. Alternatively, wrap the element in a div with a new id. Or have some JavaScript which checks for known alternative anchors and replaces them with their canonical spelling. Smylers -- http://twitter.com/Smylers2
Re: [whatwg] alternate ids for elements
2014-12-03, 19:41, Smylers wrote: The solution seems simple to me: Do not change the anchor id, ever. But what if the original ID used had a typo in it? Id attribute values are strings used for identification. Any “typo” in them is just part of the string. Or a product name has to change for legal reasons? That’s irrelevant. Id attribute values are not product names, or names at all. And I don’t think you are referring to any real case here. It's entirely reasonable for anchors to be ‘meaningful-to-human’ IDs that are indicative of the section they are labelling, and for section names to change over time. Id attribute values are not meant to be understandable to humans. If you write them expecting them to be, you need to deal with the consequences. It is true that id attribute values may appear as part of URLs, but so do e.g. form field names and values, yet we are not worrying about setting aliases for them. For instance, Wikipedia pages have an ID for each section which is based on the section name. Every time somebody edits a section title, the anchor changes ... and any external links specifically to that section break. If that is so, it is poor design and should be fixed at that level. The alternate id proposal would not help at all unless Wikipedia was changed to keep old id attribute values as alternate values. If you can persuade them to do that, try making them fix the original problem instead. It should be much simpler to make an id attribute value, once created, permanent than to introduce a new mechanism. There are far too many broken links on the web of this form, where the link goes to the correct page but includes a non-existent anchor. The proposal would not help with that. Those links would remain broken. For any new content, which one is easier, to keep id attributes as they have once been assigned or to change them but turn old values to something to be appended to a list of alternate ids? Besides, all existing browsers would completely ignore the alternate id list, so it would take several years before they could be relied on. Yucca
Re: [whatwg] alternate ids for elements
Am .12.2014, 15:30 Uhr, schrieb Nils Dagsson Moskopp n...@dieweltistgarnichtso.net: Julian Reschke julian.resc...@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. It might be useful to add a note to https://html.spec.whatwg.org/multipage/dom.html#the-id-attribute advising not to change ids, at least not when they are used for the purpose of linking to certain parts of the document. Rfc4287 uses the term “permanent” for atom:ids. That’s a nice word. Martin
Re: [whatwg] PSA: Chrome ignoring autocomplete=off for Autofill data
On Wed, Dec 3, 2014 at 12:26 PM, Igor Minar imi...@google.com wrote: In FF 34 the form autofill works well but password autofill doesn't fire any events. Do you have a testcase demonstrating this problem? Based on my knowledge of Firefox code, I am surprised that there would be a difference between password and form autofill. (Feel free to follow up directly rather than on the list.) Gavin
