Re: Custom Elements: 'data-' attributes
On Wed, May 14, 2014 at 1:18 PM, Soledad Penadés 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 Wed, May 14, 2014 at 7:18 AM, Soledad Penadés wrote: [snip] > 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. > > I'm not sure what this means by UA handling, can you explain? Let me give you a concrete example and you can tell me what happens. I work in higher education, and we have custom elements for things like student's schedules - showing them, making them, etc. And we have lists of courses, etc. Lots and lots of stuff that has to do with classes (the kind that are taught) and these classes have unique ids and titles too. So what happens when I do: or or These are important things to our component, so, probably I would register them - but both class and offering mean something as global attributes, and these are plugged into all sorts of things - CSS, qsa, etc... When you say "then don't let the UA handle it as it would do if unregistered" - what does that mean in this case? anything? Would that all still continue to work? I'm just trying to understand what you are suggesting there... > > -- > // > // http://soledadpenades.com // @supersole // > // GIF HACKTIVIST // Mozilla Apps Engineering // > // > > > > -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Custom Elements: 'data-' attributes
On Tue, May 13, 2014 at 5:44 PM, Boris Zbarsky 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 13/05/2014 10:37, Anne van Kesteren 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. Thank you for adding this idea to the list, Anne! Now that you've involved me I have to emerge from the Lurkers in the Shadow tree and add in the rest of my comments: As a developer which likes the idea of web components because they will allow me to write "semantic code" I am concerned about prefixing the attributes of *my* components with data-. It not only is unneeded noise but it also clashes with the understanding I had of how web components should work. If they are custom, they *are* custom--I should have total ownership over them. Hypothetical comparison: where I can grab a reference and access this in JS with synth.osc1 = ... synth.frequency = ... vs data-frequency="320"> synth.dataset['osc1'] = ... synth.dataset['frequency'] = ... Plus this second method looks like it wouldn't allow me to use custom setters/getters. Specially setters! When you're building components you want to do fancy things when you modify attributes, for example update the position of a knob with a smooth transition, and not just update the attribute value. I'm grateful to James Graham and Anne V.K. for explaining me the reasoning behind this prefixing idea: so that both current and FUTURE global attributes do not clash with the attributes I choose to use in my component. 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. Hope that makes sense! :-) sole -- // // http://soledadpenades.com // @supersole // // GIF HACKTIVIST // Mozilla Apps Engineering // //
Re: Custom Elements: 'data-' attributes
> On May 13, 2014, at 2:37 AM, Anne van Kesteren wrote: > >> On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa 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 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 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 Tue, May 13, 2014 at 2:37 AM, Anne van Kesteren 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 Thu, 08 May 2014 19:42:04 +0200, Ian Hickson wrote: On Thu, 8 May 2014, Bruce Lawson wrote: On 7 May 2014 20:03, Ian Hickson 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. ...etc. But the attributes are _already_ scoped, since they're on the element. ...vs 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 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 Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa 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 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 May 12, 2014, at 2:00 AM, Anne van Kesteren wrote: > On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa 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 Mon, May 12, 2014 at 11:24 AM, Simon Pieters 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 Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren wrote: On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa 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: made us have to rename to (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 Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa 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 May 9, 2014, at 3:22 AM, Anne van Kesteren wrote: > >> On Thu, May 8, 2014 at 6:49 PM, Brian Kardell wrote: >> 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? > > _test="" or -test="" works fine. However, if we advice developers to > mint attributes like that and APIs like ele._test() I'd imagine they'd > laugh at us. Not exactly a great improvement over the status quo. I don't think we can equate name collision in attribute names with that of method names. The reason name collisions in attributes is bad is because attributes define directives for UAs to follow. This doesn't apply to element methods which define the API surface for authors. Suppose we didn't have "contenteditable" today and someone had defined a custom element that used this attribute name for some other semantics C. If we then introduced this attribute for what it stands today, semantics P, we'll be in a trouble because UAs would start treating custom elements' contests as if they were editable. 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. - R. Niwa
Re: Custom Elements: 'data-' attributes
On Thu, May 8, 2014 at 6:49 PM, Brian Kardell wrote: > 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? _test="" or -test="" works fine. However, if we advice developers to mint attributes like that and APIs like ele._test() I'd imagine they'd laugh at us. Not exactly a great improvement over the status quo. -- http://annevankesteren.nl/
Re: Custom Elements: 'data-' attributes
On Thu, May 8, 2014 at 5:37 AM, Anne van Kesteren wrote: > On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa 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. > > > > reads a lot better than > > > > 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
Re: Custom Elements: 'data-' attributes
On Thu, 8 May 2014, Bruce Lawson wrote: > On 7 May 2014 20:03, Ian Hickson 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. ...etc. But the attributes are _already_ scoped, since they're on the element. ...vs 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 12:53 AM, Ryosuke Niwa 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. reads a lot better than 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 7 May 2014 20:03, Ian Hickson 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 May 7, 2014, at 4:30 PM, Glenn Maynard wrote: > On Wed, May 7, 2014 at 5:07 PM, Ryosuke Niwa 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
Re: Custom Elements: 'data-' attributes
On Wed, May 7, 2014 at 5:07 PM, Ryosuke Niwa 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
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 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, 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
Le 07/05/2014 21:36, Ryosuke Niwa a écrit : On May 7, 2014, at 12:03 PM, Ian Hickson wrote: On Wed, 7 May 2014, Anne van Kesteren wrote: On Tue, May 6, 2014 at 7:19 PM, Wilson Page 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 May 7, 2014, at 12:03 PM, Ian Hickson wrote: > On Wed, 7 May 2014, Anne van Kesteren wrote: >> On Tue, May 6, 2014 at 7:19 PM, Wilson Page 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
On Wed, 7 May 2014, Anne van Kesteren wrote: > On Tue, May 6, 2014 at 7:19 PM, Wilson Page 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 Tue, May 6, 2014 at 7:19 PM, Wilson Page 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/
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?
