Re: Custom Elements: 'data-' attributes
On Tue, May 13, 2014 at 5:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: I slightly worry about the performance implications of this and the number of changes to UAs this will require: any place inside a UA that examines attribute values (only for global attributes?) would need to consult this reservation information, right? Yes. Though maybe not for styling? I suspect if we're going to allow genuine subclassing of existing elements, you would want to potentially override attributes there too. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
On Wed, May 14, 2014 at 1:18 PM, Soledad Penadés s...@mozilla.com wrote: And that's where I suggested leaving attribute handling to the component. If it self-registers as handling a certain attribute, then don't let the UA handle it as it would do if unregistered. Very much like the idea. A potential issue is if the element is used before the element definition is registered. Then it would first be parsed as the global attribute, but what happens when it has been registered? Changing the semantics of the attribute mid-way is a bit weird. -- David Håsäther
Re: Custom Elements: 'data-' attributes
On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa rn...@apple.com wrote: But expandos are usually added to HTMLElement and other builtin elements, right? Depends, might be on instances too. What we're talking about here is adding properties and methods on a custom element, which is a subclass of HTMLElement so I don't think it'll cause the same issue. If a site has if (ele.prop) you'd have that issue since that suddenly starts returning true for e.g. the body element or some such. Similar reason is why getElementById() is not available an elements. Sole had the idea of providing hooks for attributes so a component can say it handles them rather than the user agent. That makes a lot of sense to me. That way you can grab any name, even existing ones. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
On Thu, 08 May 2014 19:42:04 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 8 May 2014, Bruce Lawson wrote: On 7 May 2014 20:03, Ian Hickson i...@hixie.ch wrote: Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. I think the ship HMS Ugly has already sailed, given a dash is compulsory for the names of custom elements. Also, requiring a dash in the names of custom attributes would establish an easily-memorable convention for authors, and safeguard new global attributes. I disagree. I think the HMS ugly really has been launched - and successfully sailed for years. I agree with Bruce that dashes in attributes are easy for everyone to remember. The question is really how important that is. With element names, you really should be putting a uniquish prefix on your element names to avoid clashes with other custom vocabs. So the dash is just the way we encourage that. Right. google-button yahoo-button ...etc. But the attributes are _already_ scoped, since they're on the element. android-patterngrid width=3 height=3 ...vs android-patterngrid data-width=3 data-height=3 The data- bits don't add anything useful. if they were andr- they might remind authors that this is a width specifically scoped to the element (and measured in unicorns, or somehow different from the normal width). For more obviously custom attributes like translation-tracker tt-src=http://example.org/yvfol; I suspect this is actually helpful for authors in getting it right. But if we simply require everything to be data-* I agree that we're not likely to help anyone much. So if we are going to do something, IMHO it should look more like your attributes must have a dash in their name… Anne's point about the DOM interface also being an issue is very important also. Yes. Unless we're also going to be forcing everyone to prefix their APIs, which would also be really ugly, the namespace wouldn't be protected anyway. True… This a price of ditching XML and namespaces (which was done because there were benefits too). Those things are seperable, and there is no law that we can never re-invent namespaces for an HTML world if it turns out that the functionality really was needed. Hence my initial question - can we get a really important benefit for some (more) ugliness in the Web platform, do we need to find another solution, or is the problem so small we don't need to worry? I'm dubious about the last suggestion, but whether one or the other of the first two is more likely to be correct isn't immediately apparent to me. cheers chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Custom Elements: 'data-' attributes
On Tue, May 13, 2014 at 2:37 AM, Anne van Kesteren ann...@annevk.nl wrote: Sole had the idea of providing hooks for attributes so a component can say it handles them rather than the user agent. That makes a lot of sense to me. That way you can grab any name, even existing ones. 3 this idea, would love to hear more. It's like dinner reservations for attributes! :DG
Re: Custom Elements: 'data-' attributes
On 5/13/14, 7:31 AM, Dimitri Glazkov wrote: Sole had the idea of providing hooks for attributes so a component can say it handles them rather than the user agent. That makes a lot of sense to me. That way you can grab any name, even existing ones. 3 this idea, would love to hear more. It's like dinner reservations for attributes! I slightly worry about the performance implications of this and the number of changes to UAs this will require: any place inside a UA that examines attribute values (only for global attributes?) would need to consult this reservation information, right? -Boris
Re: Custom Elements: 'data-' attributes
On May 13, 2014, at 2:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa rn...@apple.com wrote: But expandos are usually added to HTMLElement and other builtin elements, right? Depends, might be on instances too. Sure, authors can do anything they please to do but a typical workflow is to define a property on element's prototype. What we're talking about here is adding properties and methods on a custom element, which is a subclass of HTMLElement so I don't think it'll cause the same issue. If a site has if (ele.prop) you'd have that issue since that suddenly starts returning true for e.g. the body element or some such. Similar reason is why getElementById() is not available on elements. Right. I think we need to discourage authors from using such an idiom on inprefixed author defined properties. If authors are writing terrible code, there is so much we can do to mitigate that. Sole had the idea of providing hooks for attributes so a component can say it handles them rather than the user agent. That makes a lot of sense to me. That way you can grab any name, even existing ones. Sounds like a sensible idea. - R. Niwa
Re: Custom Elements: 'data-' attributes
On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com wrote: On the other hand, if the same element had exposed contentEditable property, then UA's native contentEditable property would simply be overridden since it would appear higher up in the prototype chain. It's true that this custom element's contentEditable would have completely different semantics from that on other elements but that wouldn't break websites that use this custom element as long as authors are only accessing contentEditable property on instances of the custom element for semantics C. I forgot the exact details, but we had some amount of trouble when we introduced min and max attributes due to sites using expandos with the same names. I think we need something better than encouraging certain conventions if we want this to work. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com wrote: On the other hand, if the same element had exposed contentEditable property, then UA's native contentEditable property would simply be overridden since it would appear higher up in the prototype chain. It's true that this custom element's contentEditable would have completely different semantics from that on other elements but that wouldn't break websites that use this custom element as long as authors are only accessing contentEditable property on instances of the custom element for semantics C. I forgot the exact details, but we had some amount of trouble when we introduced min and max attributes due to sites using expandos with the same names. I think we need something better than encouraging certain conventions if we want this to work. Bare names in event handler content attributes are troublesome. For instance, sites doing: button onclick=action() made us have to rename button action to button formaction (the new .action reflecting action= was closer in the scope chain than the intended function). Global attributes have the same issue. So when we research if it's safe to add a new global attribute, it's not enough to measure how often such an attribute is used in the wild. We need to research bare names in event handlers also. -- Simon Pieters Opera Software
Re: Custom Elements: 'data-' attributes
On Mon, May 12, 2014 at 11:24 AM, Simon Pieters sim...@opera.com wrote: So when we research if it's safe to add a new global attribute, it's not enough to measure how often such an attribute is used in the wild. We need to research bare names in event handlers also. This we can thankfully mitigate in the future due to @@unscopables. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
On May 12, 2014, at 2:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com wrote: On the other hand, if the same element had exposed contentEditable property, then UA's native contentEditable property would simply be overridden since it would appear higher up in the prototype chain. It's true that this custom element's contentEditable would have completely different semantics from that on other elements but that wouldn't break websites that use this custom element as long as authors are only accessing contentEditable property on instances of the custom element for semantics C. I forgot the exact details, but we had some amount of trouble when we introduced min and max attributes due to sites using expandos with the same names. But expandos are usually added to HTMLElement and other builtin elements, right? What we're talking about here is adding properties and methods on a custom element, which is a subclass of HTMLElement so I don't think it'll cause the same issue. - R. Niwa
Re: Custom Elements: 'data-' attributes
On 7 May 2014 20:03, Ian Hickson i...@hixie.ch wrote: Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. I think the ship HMS Ugly has already sailed, given a dash is compulsory for the names of custom elements. Also, requiring a dash in the names of custom attributes would establish an easily-memorable convention for authors, and safeguard new global attributes. Bruce
Re: Custom Elements: 'data-' attributes
On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa rn...@apple.com wrote: The answer to that question, IMO, is no. It's not safe to use custom attributes without 'data-' if one wanted to write a forward compatible HTML document. Note that the question is scoped to custom elements, not elements in general. It seems kind of sucky that if you have already minted a custom element name, you still need to prefix all your attributes too. j-details open= reads a lot better than j-details data-open= The clashes are also likely to happen on the API side. E.g. if I mint a custom element and support a property named selectable. If that gets traction that might prevent us from introducing selectable as a global attribute going forward. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
On Thu, 8 May 2014, Bruce Lawson wrote: On 7 May 2014 20:03, Ian Hickson i...@hixie.ch wrote: Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. I think the ship HMS Ugly has already sailed, given a dash is compulsory for the names of custom elements. Also, requiring a dash in the names of custom attributes would establish an easily-memorable convention for authors, and safeguard new global attributes. I disagree. With element names, you really should be putting a uniquish prefix on your element names to avoid clashes with other custom vocabs. So the dash is just the way we encourage that. google-button yahoo-button ...etc. But the attributes are _already_ scoped, since they're on the element. android-patterngrid width=3 height=3 ...vs android-patterngrid data-width=3 data-height=3 The data- bits don't add anything useful. Anne's point about the DOM interface also being an issue is very important also. Unless we're also going to be forcing everyone to prefix their APIs, which would also be really ugly, the namespace wouldn't be protected anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Elements: 'data-' attributes
On Thu, May 8, 2014 at 5:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa rn...@apple.com wrote: The answer to that question, IMO, is no. It's not safe to use custom attributes without 'data-' if one wanted to write a forward compatible HTML document. Note that the question is scoped to custom elements, not elements in general. It seems kind of sucky that if you have already minted a custom element name, you still need to prefix all your attributes too. j-details open= reads a lot better than j-details data-open= The clashes are also likely to happen on the API side. E.g. if I mint a custom element and support a property named selectable. If that gets traction that might prevent us from introducing selectable as a global attribute going forward. -- http://annevankesteren.nl/ What do the parsing rules say about what an attr may begin with? Is it plausible to just leading underscore or leading dash them as in CSS so that all that's really necessary is for HTML to avoid using those natively (not hard, cause, why would you) and then you provide an easy hatch for good authors and get decent protection without getting too crazy? -- Brian Kardell :: @briankardell :: hitchjs.com
Custom Elements: 'data-' attributes
I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes?
Re: Custom Elements: 'data-' attributes
On Tue, May 6, 2014 at 7:19 PM, Wilson Page wilsonp...@me.com wrote: I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes? Yeah, we should figure something out here. From one perspective you've already namespaced your element by using a dash. However, given the existence of an ever growing set of global attributes you probably do not want to clash with those. Maybe we should allow any attribute as long as it contains a dash (and does not match a set of existing names)? Still seems somewhat suboptimal. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
On Wed, 7 May 2014, Anne van Kesteren wrote: On Tue, May 6, 2014 at 7:19 PM, Wilson Page wilsonp...@me.com wrote: I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes? Yeah, we should figure something out here. From one perspective you've already namespaced your element by using a dash. However, given the existence of an ever growing set of global attributes you probably do not want to clash with those. Maybe we should allow any attribute as long as it contains a dash (and does not match a set of existing names)? Still seems somewhat suboptimal. Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. We only introduce them at the rate of ~one per year if you treat namespaced groups of attributes like event handlers, microdata, or ARIA as single units (which they more or less are, for this problem, I think). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Elements: 'data-' attributes
On May 7, 2014, at 12:03 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 7 May 2014, Anne van Kesteren wrote: On Tue, May 6, 2014 at 7:19 PM, Wilson Page wilsonp...@me.com wrote: I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes? Yeah, we should figure something out here. From one perspective you've already namespaced your element by using a dash. However, given the existence of an ever growing set of global attributes you probably do not want to clash with those. Maybe we should allow any attribute as long as it contains a dash (and does not match a set of existing names)? Still seems somewhat suboptimal. Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. I don't think being careful is a sound strategy. How are you going to quantify the risk of adding a new global attribute in the future? I don't want us to depend on some random search engines to make a guess as to which names are safe to use. - R. Niwa
Re: Custom Elements: 'data-' attributes
Le 07/05/2014 21:36, Ryosuke Niwa a écrit : On May 7, 2014, at 12:03 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 7 May 2014, Anne van Kesteren wrote: On Tue, May 6, 2014 at 7:19 PM, Wilson Page wilsonp...@me.com wrote: I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes? Yeah, we should figure something out here. From one perspective you've already namespaced your element by using a dash. However, given the existence of an ever growing set of global attributes you probably do not want to clash with those. Maybe we should allow any attribute as long as it contains a dash (and does not match a set of existing names)? Still seems somewhat suboptimal. Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. I don't think being careful is a sound strategy. How are you going to quantify the risk of adding a new global attribute in the future? I don't want us to depend on some random search engines to make a guess as to which names are safe to use. I want to agree with you, but it's impossible to prevent authors from using any sort of attributes in their content (willing to bet hard money web browers won't stop page rendering because some custom element attribute doesn't contain a dash; looking at the XHTML precedent if nothing else). Such search will have to happen anyway. It'd be nice if the tooling to make such search was available to inspection, though. David
Re: Custom Elements: 'data-' attributes
On Wed, 7 May 2014, Ryosuke Niwa wrote: How are you going to quantify the risk of adding a new global attribute in the future? Same we we do today. Look to see how many pages use the attribute, find a name that's not used much, and then try to deploy it and see what breaks. I don't want us to depend on some random search engines to make a guess as to which names are safe to use. That's basically how we've been doing it so far. I mean, it's not like disallowing people from making up attributes has stopped everyone from making up attributes. This is already a problem. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Elements: 'data-' attributes
There is a difference in people not caring about forward compatibility and polluting the global namespace, and not providing a mechanism to do it right in the first place. If we're encouraging authors to define their own attributes, then we should provide a mechanism or a guideline to do so in a forward compatible manner. - R. Niwa On May 7, 2014, at 1:23 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 7 May 2014, Ryosuke Niwa wrote: How are you going to quantify the risk of adding a new global attribute in the future? Same we we do today. Look to see how many pages use the attribute, find a name that's not used much, and then try to deploy it and see what breaks. I don't want us to depend on some random search engines to make a guess as to which names are safe to use. That's basically how we've been doing it so far. I mean, it's not like disallowing people from making up attributes has stopped everyone from making up attributes. This is already a problem. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Elements: 'data-' attributes
On Wed, May 7, 2014 at 5:07 PM, Ryosuke Niwa rn...@apple.com wrote: There is a difference in people not caring about forward compatibility and polluting the global namespace, and not providing a mechanism to do it right in the first place. You'll always need to be able to declare attributes that the browser doesn't know about, for polyfills. If we're encouraging authors to define their own attributes, then we should provide a mechanism or a guideline to do so in a forward compatible manner. Allowing isn't necessarily encouraging, and we do have a guideline: use data-*. Be careful of falling into the trap of adding complexity to fix something that isn't actually a serious problem... -- Glenn Maynard
Re: Custom Elements: 'data-' attributes
On May 7, 2014, at 4:30 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, May 7, 2014 at 5:07 PM, Ryosuke Niwa rn...@apple.com wrote: There is a difference in people not caring about forward compatibility and polluting the global namespace, and not providing a mechanism to do it right in the first place. You'll always need to be able to declare attributes that the browser doesn't know about, for polyfills. Sorry, I don't follow how that is relevant to this discussion. Could you clarify what you mean? If we're encouraging authors to define their own attributes, then we should provide a mechanism or a guideline to do so in a forward compatible manner. Allowing isn't necessarily encouraging, and we do have a guideline: use data-*. Be careful of falling into the trap of adding complexity to fix something that isn't actually a serious problem... I mean... we can't disallow anyone from using arbitrary attribute name just the same way we can't disallow people to use arbitrary element name. However, we specifically say authors shouldn't do that and use data-* instead now. If you're proposing that we don't change that and we should continue to encourage authors to always use data-* attributes, then I'm fine with that. However, I don't think that's being discussed here. I think what's being discussed here is whether or not it is safe to use custom attributes without the 'data-'. The answer to that question, IMO, is no. It's not safe to use custom attributes without 'data-' if one wanted to write a forward compatible HTML document. - R. Niwa
