New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make custom attribute rules consistent with custom element name rules #2271

Open
LeaVerou opened this Issue Jan 17, 2017 · 71 comments

Comments

@LeaVerou

LeaVerou commented Jan 17, 2017

Related WICG discussion: https://discourse.wicg.io/t/relaxing-restrictions-on-custom-attribute-names/1444

Currently, custom attributes need to start with data-. For frameworks with a lot of attributes (Angular, Vue etc), this introduces a serious problem: Either they prefix all attributes with data- and become prone to collisions with other libraries (I've even had two of my own libraries collide!), or they make them extremely verbose (data-ng-*), or they make them non-standard (ng-*, v-*), which is their chosen solution. I'm about to release a library with a lot of attributes and I went for the latter as well. The former two pose serious practical problems, the latter is just conformance.

However, it doesn't have to be this way. Custom elements allow any element name with a hyphen in it, we could do the same for attributes. The cowpaths have been paved: Several very popular libraries follow this practice already. This is not true for proposals like #2250, which introduce a completely new naming scheme.

The main issue with this is all the existing attributes in SVG that come from CSS properties which use hyphens. However, there are several solutions to deal with this:

  • Exclude these prefixes, or just these names. The SVG working group is dying and these attributes must be manually added to the spec, there's no clause that says all CSS props must automatically be available as attributes.
  • Only allow prefixes of 1 or 2 letters. This gives us 26*26 + 25 = 701 more prefixes already, and does not clash with any CSS property that is available as an SVG attribute (z-index is the only CSS property that matches this, and it's not an SVG attribute). It also legalizes Angular & Vue's practices.

The more commonplace invalid HTML becomes, the less authors care about authoring valid HTML. Validation becomes pointless in their eyes if they see tons of perfectly good use cases being invalid. Also, if both attributes with and without hyphens are equally invalid, nothing forces developers to stick to any naming scheme. So, I think it would be great if we found a solution for this. And it's a proposal that requires zero effort from implementers, since these attributes already work just fine!

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jan 17, 2017

I’d be fine with this as long as the pre-hyphen part could be empty, so attributes could have names like -foo, -bar, etc.

Otherwise this does not add much over the existing data- prefix (e. g. da- instead of data-) and is probably too problematic compared with the absolutely issue-free and future-proof underscore/hyphen-prefixed custom attributes.

To be fair, better than nothing anyway though.

Marat-Tanalin commented Jan 17, 2017

I’d be fine with this as long as the pre-hyphen part could be empty, so attributes could have names like -foo, -bar, etc.

Otherwise this does not add much over the existing data- prefix (e. g. da- instead of data-) and is probably too problematic compared with the absolutely issue-free and future-proof underscore/hyphen-prefixed custom attributes.

To be fair, better than nothing anyway though.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 18, 2017

Member

I'm supportive of this, but only if we also add an API equivalent to what we added for custom elements. It should be possible for folks to easily observe when such attributes are added, removed, and change in value.

Member

annevk commented Jan 18, 2017

I'm supportive of this, but only if we also add an API equivalent to what we added for custom elements. It should be possible for folks to easily observe when such attributes are added, removed, and change in value.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Jan 18, 2017

Member

I’d be fine with this as long as the pre-hyphen part could be empty, so attributes could have names like -foo, -bar, etc.

Starting with a dash is not XML-compatible. Currently the spec requires data-* attribute names to be XML-compatible, and custom element names as well.

Member

zcorpan commented Jan 18, 2017

I’d be fine with this as long as the pre-hyphen part could be empty, so attributes could have names like -foo, -bar, etc.

Starting with a dash is not XML-compatible. Currently the spec requires data-* attribute names to be XML-compatible, and custom element names as well.

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jan 18, 2017

Otherwise this does not add much over the existing data- prefix (e. g. da- instead of data-) and is probably too problematic compared with the absolutely issue-free and future-proof underscore/hyphen-prefixed custom attributes.

Clearly, you have not considered collisions between libraries and think everything can have the same prefix and the only problem is how to make the prefix less verbose. I don't blame you, I thought they were an edge case in the past as well, but they absolutely are not. With your proposal, libraries would end up doing things like _ng-*, or (most likely) simply not care and continue using ng-* like they've done for years.

LeaVerou commented Jan 18, 2017

Otherwise this does not add much over the existing data- prefix (e. g. da- instead of data-) and is probably too problematic compared with the absolutely issue-free and future-proof underscore/hyphen-prefixed custom attributes.

Clearly, you have not considered collisions between libraries and think everything can have the same prefix and the only problem is how to make the prefix less verbose. I don't blame you, I thought they were an edge case in the past as well, but they absolutely are not. With your proposal, libraries would end up doing things like _ng-*, or (most likely) simply not care and continue using ng-* like they've done for years.

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jan 18, 2017

I'm supportive of this, but only if we also add an API equivalent to what we added for custom elements. It should be possible for folks to easily observe when such attributes are added, removed, and change in value.

That would be awesome. So basically, syntactic sugar for MutationObserver?

LeaVerou commented Jan 18, 2017

I'm supportive of this, but only if we also add an API equivalent to what we added for custom elements. It should be possible for folks to easily observe when such attributes are added, removed, and change in value.

That would be awesome. So basically, syntactic sugar for MutationObserver?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 18, 2017

Member

The problem with MutationObserver for this use case is that you don't know where the attribute is going to be added. So if you want a global custom attribute, you'd have to observe the entire tree and even then you'd miss certain things, such as shadow trees.

Member

annevk commented Jan 18, 2017

The problem with MutationObserver for this use case is that you don't know where the attribute is going to be added. So if you want a global custom attribute, you'd have to observe the entire tree and even then you'd miss certain things, such as shadow trees.

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jan 18, 2017

@LeaVerou

With your proposal, libraries would end up doing things like _ng-*, or (most likely) simply not care and continue using ng-* like they've done for years.

_ was invalid at the moment of making decisions as for design of those libraries, that’s most likely why libraries’ authors have decided just to drop the (only valid at that moment) data- prefix and not to use a generic prefix that would be formally invalid anyway.

As a side note, it’d probably be wrong to assume that the fact that it’s hard for someone who is already a smoker (existing libraries in terms of custom attributes) to leave off smoking is a reason not to try to prevent others (new products and libraries) from starting smoking (provide a valid short unobtrusive generic prefix).

Marat-Tanalin commented Jan 18, 2017

@LeaVerou

With your proposal, libraries would end up doing things like _ng-*, or (most likely) simply not care and continue using ng-* like they've done for years.

_ was invalid at the moment of making decisions as for design of those libraries, that’s most likely why libraries’ authors have decided just to drop the (only valid at that moment) data- prefix and not to use a generic prefix that would be formally invalid anyway.

As a side note, it’d probably be wrong to assume that the fact that it’s hard for someone who is already a smoker (existing libraries in terms of custom attributes) to leave off smoking is a reason not to try to prevent others (new products and libraries) from starting smoking (provide a valid short unobtrusive generic prefix).

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jan 18, 2017

The problem with MutationObserver for this use case is that you don't know where the attribute is going to be added. So if you want a global custom attribute, you'd have to observe the entire tree and even then you'd miss certain things, such as shadow trees.

True, and what you're proposing would solve a HUGE problem and I would cry tears of joy once it gets implemented! I'm just a bit concerned that it requires considerably more implementor effort, so adding it could stall. Whereas just permitting such attribute names at first would let us use them and it's a super easy addition to the spec since it requires no implementation effort.

LeaVerou commented Jan 18, 2017

The problem with MutationObserver for this use case is that you don't know where the attribute is going to be added. So if you want a global custom attribute, you'd have to observe the entire tree and even then you'd miss certain things, such as shadow trees.

True, and what you're proposing would solve a HUGE problem and I would cry tears of joy once it gets implemented! I'm just a bit concerned that it requires considerably more implementor effort, so adding it could stall. Whereas just permitting such attribute names at first would let us use them and it's a super easy addition to the spec since it requires no implementation effort.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 19, 2017

Member

Fair, I think there is interest to go in this direction once custom elements has shipped. This idea was briefly discussed at the last W3C TPAC. I think the main thing we lack is someone freeing up the time to write the standard. @domenic thoughts?

Member

annevk commented Jan 19, 2017

Fair, I think there is interest to go in this direction once custom elements has shipped. This idea was briefly discussed at the last W3C TPAC. I think the main thing we lack is someone freeing up the time to write the standard. @domenic thoughts?

@rniwa

This comment has been minimized.

Show comment
Hide comment
@rniwa

rniwa Jan 19, 2017

Collaborator

I think the fact custom elements kind of encourage people to add a random attribute is a serious issue already so coming up with a some convention for author-defined attribute is a win even if we couldn't add an API for custom attributes yet.

Having said that, we think custom attribute is a much better alternative to is attribute.

Collaborator

rniwa commented Jan 19, 2017

I think the fact custom elements kind of encourage people to add a random attribute is a serious issue already so coming up with a some convention for author-defined attribute is a win even if we couldn't add an API for custom attributes yet.

Having said that, we think custom attribute is a much better alternative to is attribute.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Jan 19, 2017

Member

Pages in httparchive with attributes that start with _ or non-standard attributes containing -:

SELECT * FROM (
SELECT page, url, REGEXP_EXTRACT(LOWER(body), r'(<[a-z][a-z0-9-]*\s+(?:(?:data-|aria-|http-|accept-)?[a-z]+(?:\s*=\s*(?:"[^"]*"|\'[^\']*\'|[^>\s/"\']+\s+)|\s+))*(?:_[a-z]|(?:[b-ce-gj-z]|d[b-z0-9]|a[a-bd-qs-z0-9]|h[a-su-z0-9]|da[a-su-z0-9]|ar[a-hj-z0-9]|ac[a-bd-z0-9]|ht[a-su-z0-9])[a-z0-9]*-)[^>\s]*\s*=[^>]*>)') AS match
FROM [httparchive:har.2017_01_01_chrome_requests_bodies]
)
WHERE page = url
AND match != "null"
AND NOT REGEXP_MATCH(match, r'["\']\s*\+') # exclude JS string concats
AND NOT REGEXP_MATCH(match, r'<(altglyph|animate|circle|clippath|color-profile|cursor|defs|desc|ellipse|feblend|fecolor|fediffuse|fedisplacement|fedistant|feflood|fefunc|fegauss|feimage|femerge|femorph|feoffset|fepoint|fespec|fespot|fetile|feturb|filter|font|foreign|g\s|glyph|hkern|image|line|marker|mask|metadata|missing|mpath|path|pattern|polygon|polyline|radial|rect|set\s|stop|svg|switch|symbol|text\s|textpath|tref|tspan|use\s|view\s|vkern)') # exclude SVG elements

4068 results: https://gist.github.com/zcorpan/b54592e415a2f79f2ef7f79c0c37b2ed

Of those:

  • 26 have _moz_*
  • 531 have an attribute starting with _ (excluding moz prefix).
  • 22 have x-webkit-* or x-ms-* (the HTML spec for a while recommended vendor extensions to be prefixed with x-vendor-).
  • 57 start with x- (excluding webkit/ms prefixes).
  • 2015 have a prefix of 1 or 2 letters and a dash (excluding x-).
  • 1418 have 3+ letters before the dash.

Other things to note:

  • SVG font-face had x-height and v-alphabetic (etc) attributes. But this element is dead.
  • The HTML attributes with dash are aria-*, data-*, accept-charset, http-equiv.
  • I found an instance of typo of aria -- it would be good if conformance checkers could continue to catch this mistake:
    <button area-invalid="true" aria-required="true" aria-controls="checkincontainer" aria-label="checkin" id="checkinbutton" class="checkinbutton">
    
Member

zcorpan commented Jan 19, 2017

Pages in httparchive with attributes that start with _ or non-standard attributes containing -:

SELECT * FROM (
SELECT page, url, REGEXP_EXTRACT(LOWER(body), r'(<[a-z][a-z0-9-]*\s+(?:(?:data-|aria-|http-|accept-)?[a-z]+(?:\s*=\s*(?:"[^"]*"|\'[^\']*\'|[^>\s/"\']+\s+)|\s+))*(?:_[a-z]|(?:[b-ce-gj-z]|d[b-z0-9]|a[a-bd-qs-z0-9]|h[a-su-z0-9]|da[a-su-z0-9]|ar[a-hj-z0-9]|ac[a-bd-z0-9]|ht[a-su-z0-9])[a-z0-9]*-)[^>\s]*\s*=[^>]*>)') AS match
FROM [httparchive:har.2017_01_01_chrome_requests_bodies]
)
WHERE page = url
AND match != "null"
AND NOT REGEXP_MATCH(match, r'["\']\s*\+') # exclude JS string concats
AND NOT REGEXP_MATCH(match, r'<(altglyph|animate|circle|clippath|color-profile|cursor|defs|desc|ellipse|feblend|fecolor|fediffuse|fedisplacement|fedistant|feflood|fefunc|fegauss|feimage|femerge|femorph|feoffset|fepoint|fespec|fespot|fetile|feturb|filter|font|foreign|g\s|glyph|hkern|image|line|marker|mask|metadata|missing|mpath|path|pattern|polygon|polyline|radial|rect|set\s|stop|svg|switch|symbol|text\s|textpath|tref|tspan|use\s|view\s|vkern)') # exclude SVG elements

4068 results: https://gist.github.com/zcorpan/b54592e415a2f79f2ef7f79c0c37b2ed

Of those:

  • 26 have _moz_*
  • 531 have an attribute starting with _ (excluding moz prefix).
  • 22 have x-webkit-* or x-ms-* (the HTML spec for a while recommended vendor extensions to be prefixed with x-vendor-).
  • 57 start with x- (excluding webkit/ms prefixes).
  • 2015 have a prefix of 1 or 2 letters and a dash (excluding x-).
  • 1418 have 3+ letters before the dash.

Other things to note:

  • SVG font-face had x-height and v-alphabetic (etc) attributes. But this element is dead.
  • The HTML attributes with dash are aria-*, data-*, accept-charset, http-equiv.
  • I found an instance of typo of aria -- it would be good if conformance checkers could continue to catch this mistake:
    <button area-invalid="true" aria-required="true" aria-controls="checkincontainer" aria-label="checkin" id="checkinbutton" class="checkinbutton">
    
@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Jan 19, 2017

Member

For comparison, equivalent query for data-* gives 59,755 results. So data-* is about 15 times more common than non-standard custom attributes (excluding _moz_, x-webkit-, x-ms-).

Member

zcorpan commented Jan 19, 2017

For comparison, equivalent query for data-* gives 59,755 results. So data-* is about 15 times more common than non-standard custom attributes (excluding _moz_, x-webkit-, x-ms-).

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Jan 19, 2017

Member

So @LeaVerou's proposal is used by ~0.4% of pages in httparchive; @Marat-Tanalin's proposal is used by ~0.1%. data-* is used by ~12.1%. (The data set is 494,956 pages.)

Since the point here is to adopt what people like or use anyway, if we are to do this, it seems most reasonable to me to allow both. But we should disallow _moz_, x-webkit- and x-ms- and 3+ letter prefix followed by dash (to avoid clashes in SVG, and to make it possible to tell if an attribute is a "custom attribute" or not, and to catch typos in aria- or data-), as well as anything not XML-compatible. But no need to restrict the prefix to [a-z], I believe (data-* and custom element names allow other XML-compatible characters).

Member

zcorpan commented Jan 19, 2017

So @LeaVerou's proposal is used by ~0.4% of pages in httparchive; @Marat-Tanalin's proposal is used by ~0.1%. data-* is used by ~12.1%. (The data set is 494,956 pages.)

Since the point here is to adopt what people like or use anyway, if we are to do this, it seems most reasonable to me to allow both. But we should disallow _moz_, x-webkit- and x-ms- and 3+ letter prefix followed by dash (to avoid clashes in SVG, and to make it possible to tell if an attribute is a "custom attribute" or not, and to catch typos in aria- or data-), as well as anything not XML-compatible. But no need to restrict the prefix to [a-z], I believe (data-* and custom element names allow other XML-compatible characters).

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 19, 2017

Member

I still feel there's a strong advantage to sticking to a single sanctioned convention (data-) for custom data attributes, at least until we have a processing model for the "custom attributes".

If people want to go against that convention, that's their choice, but we shouldn't give them a free pass; they're making a conscious choice to trade conformance and ecosystem compatibility for convenience.

Member

domenic commented Jan 19, 2017

I still feel there's a strong advantage to sticking to a single sanctioned convention (data-) for custom data attributes, at least until we have a processing model for the "custom attributes".

If people want to go against that convention, that's their choice, but we shouldn't give them a free pass; they're making a conscious choice to trade conformance and ecosystem compatibility for convenience.

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jan 19, 2017

@domenic Sorry, but that’s just a purely theoretical statement totally detached from reality.

As a practicing web developer, I’m quite happy with what we already have currently feature-wise: getAttribute() / setAttribute() / removeAttribute() in JS and [attribute] in selectors.

The only issue here is the artificial validity limitation that could and should be easily removed on spec level. Having (or not) a processing model for custom attributes does not affect the ability to use such attributes right now (to be clear: I’m specifically about _-prefixed attributes that are 100% future-proof).

Marat-Tanalin commented Jan 19, 2017

@domenic Sorry, but that’s just a purely theoretical statement totally detached from reality.

As a practicing web developer, I’m quite happy with what we already have currently feature-wise: getAttribute() / setAttribute() / removeAttribute() in JS and [attribute] in selectors.

The only issue here is the artificial validity limitation that could and should be easily removed on spec level. Having (or not) a processing model for custom attributes does not affect the ability to use such attributes right now (to be clear: I’m specifically about _-prefixed attributes that are 100% future-proof).

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jan 19, 2017

Thanks for the data @zcorpan!! Very enlightening. I find it surprising that Angular and Vue would only be used by 0.4% of websites. Perhaps a lot of these attributes are added dynamically? Also, I'm not surprised that data- has such as high percentage: Small libraries that only add 1 or 2 attributes can easily use data- and be less worried about either collisions or verbosity. It only takes 1 such library for a page to qualify as having a data- attribute.

It's also an interesting idea to allow both proposals. I don't see any problem with that, flexibility is good!

@domenic Several people have commented about the problems with data-. Developers of popular libraries with many attributes are not using data-. Even those that supported both their own prefix- and a data-prefix- version of each attribute are dropping the latter because nobody is using it, probably because data-prefix- is a verbose abomination. And you resist legalizing anything other than data- because of some theoretical purity argument about "a single sanctioned convention"? What happened to the priority of constituencies? Doesn't author convenience come several levels before theoretical purity?!

LeaVerou commented Jan 19, 2017

Thanks for the data @zcorpan!! Very enlightening. I find it surprising that Angular and Vue would only be used by 0.4% of websites. Perhaps a lot of these attributes are added dynamically? Also, I'm not surprised that data- has such as high percentage: Small libraries that only add 1 or 2 attributes can easily use data- and be less worried about either collisions or verbosity. It only takes 1 such library for a page to qualify as having a data- attribute.

It's also an interesting idea to allow both proposals. I don't see any problem with that, flexibility is good!

@domenic Several people have commented about the problems with data-. Developers of popular libraries with many attributes are not using data-. Even those that supported both their own prefix- and a data-prefix- version of each attribute are dropping the latter because nobody is using it, probably because data-prefix- is a verbose abomination. And you resist legalizing anything other than data- because of some theoretical purity argument about "a single sanctioned convention"? What happened to the priority of constituencies? Doesn't author convenience come several levels before theoretical purity?!

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 19, 2017

Member

Several people have commented about the problems with data-. Developers of popular libraries with many attributes are not using data-. Even those that supported both their own prefix- and a data-prefix- version of each attribute are dropping the latter because nobody is using it, probably because data-prefix- is a verbose abomination.

This argument (and I would appreciate if you avoided phrases like "abomination" in reasoned discussion) is based on anecdotes, whereas @zcorpan shows soundly with data that it does not hold in the real world. A small minority of developers using custom attributes are unhappy with data; 15x more are happy with data than are unhappy. They can be vocal, as you are, but saying that this is a widespread problem is just not supported.

And you resist legalizing anything other than data- because of some theoretical purity argument about "a single sanctioned convention"? What happened to the priority of constituencies? Doesn't author convenience come several levels before theoretical purity?!

Sorry, but that’s just a purely theoretical statement totally detached from reality.

I don't think it's helpful or accurate to characterize the argument as one of theoretical purity, or start invoking the priority of constituencies before any such violation is apparent. This is about the practical impact of fracturing the ecosystem into multiple conventions for custom data. That has real impact on tooling, libraries, authors reading other authors' source code, API consistency and predictability (why do some data properties get a dataset API, and others don't?) and much more.


Again, I repeat that there is nothing stopping you from making a conscious choice between conformance and brevity. If you value brevity so much as to start calling data- attributes an abomination, I presume you value it more than conformant documents. That's fine! You can make that choice! As you yourself have noted, there's nothing stopping you. But it doesn't mean the spec should stop trying to keep the ecosystem coherent to the best of its abilities.

Member

domenic commented Jan 19, 2017

Several people have commented about the problems with data-. Developers of popular libraries with many attributes are not using data-. Even those that supported both their own prefix- and a data-prefix- version of each attribute are dropping the latter because nobody is using it, probably because data-prefix- is a verbose abomination.

This argument (and I would appreciate if you avoided phrases like "abomination" in reasoned discussion) is based on anecdotes, whereas @zcorpan shows soundly with data that it does not hold in the real world. A small minority of developers using custom attributes are unhappy with data; 15x more are happy with data than are unhappy. They can be vocal, as you are, but saying that this is a widespread problem is just not supported.

And you resist legalizing anything other than data- because of some theoretical purity argument about "a single sanctioned convention"? What happened to the priority of constituencies? Doesn't author convenience come several levels before theoretical purity?!

Sorry, but that’s just a purely theoretical statement totally detached from reality.

I don't think it's helpful or accurate to characterize the argument as one of theoretical purity, or start invoking the priority of constituencies before any such violation is apparent. This is about the practical impact of fracturing the ecosystem into multiple conventions for custom data. That has real impact on tooling, libraries, authors reading other authors' source code, API consistency and predictability (why do some data properties get a dataset API, and others don't?) and much more.


Again, I repeat that there is nothing stopping you from making a conscious choice between conformance and brevity. If you value brevity so much as to start calling data- attributes an abomination, I presume you value it more than conformant documents. That's fine! You can make that choice! As you yourself have noted, there's nothing stopping you. But it doesn't mean the spec should stop trying to keep the ecosystem coherent to the best of its abilities.

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jan 19, 2017

@domenic

15x more are happy with data than are unhappy.

The obvious reason of prevalence of data--prefixed attributes over other prefixes is that data- is the only formally valid option for now. This has nothing to do with whether people are actually happy with it.

Good web developers just usually prefer to keep their documents valid, and not just because that makes them “feel good”, but also to be able to use validators to easier see real errors not intermixed with fictious pseudoerrors related to artificial spec-level limitations not matching reality.

why do some data properties get a dataset API, and others don't?

Because not all custom attributes are data attributes. data- attributes are for data, custom-prefixed attributes are for custom needs whatever those are.

Marat-Tanalin commented Jan 19, 2017

@domenic

15x more are happy with data than are unhappy.

The obvious reason of prevalence of data--prefixed attributes over other prefixes is that data- is the only formally valid option for now. This has nothing to do with whether people are actually happy with it.

Good web developers just usually prefer to keep their documents valid, and not just because that makes them “feel good”, but also to be able to use validators to easier see real errors not intermixed with fictious pseudoerrors related to artificial spec-level limitations not matching reality.

why do some data properties get a dataset API, and others don't?

Because not all custom attributes are data attributes. data- attributes are for data, custom-prefixed attributes are for custom needs whatever those are.

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Jan 19, 2017

Contributor

@zcorpan wrote:

So @LeaVerou's proposal is used by ~0.4% of pages in httparchive; @Marat-Tanalin's proposal is used by ~0.1%. data-* is used by ~12.1%. (The data set is 494,956 pages.)

does that mean that some other form of prefix is used by the other 87%?

Contributor

stevefaulkner commented Jan 19, 2017

@zcorpan wrote:

So @LeaVerou's proposal is used by ~0.4% of pages in httparchive; @Marat-Tanalin's proposal is used by ~0.1%. data-* is used by ~12.1%. (The data set is 494,956 pages.)

does that mean that some other form of prefix is used by the other 87%?

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 19, 2017

Member

The obvious reason of prevalence of data--prefixed attributes over other prefixes is that data- is the only formally valid option for now. This has nothing to do with whether people are actually happy with it.

That's an interesting speculation. Fortunately, it's also one we can answer, or at least upper-bound, with data. That is, what percentage of those ~12.1% of pages are conformant? In other words, what percentage of people using data-* attributes are also people who care about conformance, and thus might have chosen data- over x- because of conformance concerns?

Similarly, what percentage of the ~0.5% using nonstandard prefixes are conformant-except-for-bad-prefixes? This number is especially interesting, because it indicates people who are interested in conformance but just aren't willing to change their prefixes. Certainly you and Lea might fall in that sub-bucket of the ~0.5%. (Although maybe not?) But how many of that ~0.5% are you representing?


Another point worth making is the analogy to a previous push to use <i> for icons. The reasoning was exactly the same: lots of people are doing it, because it's shorter than the recommendation in the spec (<span> with fallback text). We even did a HTTP archive search, and found that many more developers would "benefit" from allowing this than the fraction-of-~0.5% being discussed here. But allowing <i> for icons has many practical downsides---the same ones I listed before for allowing non-data- prefixes for custom data attributes. For that reason, we didn't do it.


does that mean that some other form of prefix is used by the other 87%?

I assume it means they are not using any prefixed attributes (data- or otherwise) at all.

Member

domenic commented Jan 19, 2017

The obvious reason of prevalence of data--prefixed attributes over other prefixes is that data- is the only formally valid option for now. This has nothing to do with whether people are actually happy with it.

That's an interesting speculation. Fortunately, it's also one we can answer, or at least upper-bound, with data. That is, what percentage of those ~12.1% of pages are conformant? In other words, what percentage of people using data-* attributes are also people who care about conformance, and thus might have chosen data- over x- because of conformance concerns?

Similarly, what percentage of the ~0.5% using nonstandard prefixes are conformant-except-for-bad-prefixes? This number is especially interesting, because it indicates people who are interested in conformance but just aren't willing to change their prefixes. Certainly you and Lea might fall in that sub-bucket of the ~0.5%. (Although maybe not?) But how many of that ~0.5% are you representing?


Another point worth making is the analogy to a previous push to use <i> for icons. The reasoning was exactly the same: lots of people are doing it, because it's shorter than the recommendation in the spec (<span> with fallback text). We even did a HTTP archive search, and found that many more developers would "benefit" from allowing this than the fraction-of-~0.5% being discussed here. But allowing <i> for icons has many practical downsides---the same ones I listed before for allowing non-data- prefixes for custom data attributes. For that reason, we didn't do it.


does that mean that some other form of prefix is used by the other 87%?

I assume it means they are not using any prefixed attributes (data- or otherwise) at all.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 19, 2017

Member

Let me also repeat that I do support exploring the concept of custom attributes, with a processing model similar to custom elements. That gives serious benefits beyond just brevity, that IMO outweigh the practical disadvantages. It's the simple conformance change with no processing model that I am not in support of.

Member

domenic commented Jan 19, 2017

Let me also repeat that I do support exploring the concept of custom attributes, with a processing model similar to custom elements. That gives serious benefits beyond just brevity, that IMO outweigh the practical disadvantages. It's the simple conformance change with no processing model that I am not in support of.

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jan 19, 2017

Again, I repeat that there is nothing stopping you from making a conscious choice between conformance and brevity. If you value brevity so much as to start calling data- attributes an abomination, I presume you value it more than conformant documents. That's fine! You can make that choice! As you yourself have noted, there's nothing stopping you. But it doesn't mean the spec should stop trying to keep the ecosystem coherent to the best of its abilities.
@Marat-Tanalin

Authors don't typically invent their own attributes, and when they do, data- is fine. Most custom attributes are used because a library/framework will utilize them. Therefore, the person using the attribute is not the same person that decided on its naming. It's not about my choice, it's about making the right choice for the users of my library. I don't want to impose verbosity on them and litter their markup with lengthy prefixes, and I don't want to impose nonconformance on them. Library devs should not be forced into this dilemma.

Re: fracturing the ecosystem, how does that not apply to custom element names?

whereas @zcorpan shows soundly with data that it does not hold in the real world

While I definitely commend the effort to get real data, I would take that percentage with a grain of salt:

  1. We're basically parsing HTML with regexes here
  2. None of this accounts for dynamically added attributes.
  3. It counts occurrence of each naming scheme per page, whereas I suspect that when ng- or v- attributes are used, A LOT of them are used.
  4. As I mentioned above, smaller libraries can use data- just fine. When you only have one or two attributes, the verbosity doesn't matter much and the collisions are more rare. It only takes 1 such library for a page to count in @zcorpan's data.
  5. As @Marat-Tanalin mentioned, data- is the only conformant option right now, don't you think that affects usage?
  6. These stats go against common knowledge: Angular and Vue are very popular, it seems weird that they'd be collectively used by only 0.4% of websites.

Fortunately, it's also one we can answer with data. That is, what percentage of those ~12.1% of pages are conformant? In other words, what percentage of people using data-* attributes are also people who care about conformance, and thus might have chosen data- over x- because of conformance concerns?

You're assuming here that everybody who cares about conformance is actually conformant. A parallel about religions and sins comes to mind. :) Many authors care about conformance, but don't actually validate, so they make mistakes that are never caught. However, conformance still influences their decision making.

LeaVerou commented Jan 19, 2017

Again, I repeat that there is nothing stopping you from making a conscious choice between conformance and brevity. If you value brevity so much as to start calling data- attributes an abomination, I presume you value it more than conformant documents. That's fine! You can make that choice! As you yourself have noted, there's nothing stopping you. But it doesn't mean the spec should stop trying to keep the ecosystem coherent to the best of its abilities.
@Marat-Tanalin

Authors don't typically invent their own attributes, and when they do, data- is fine. Most custom attributes are used because a library/framework will utilize them. Therefore, the person using the attribute is not the same person that decided on its naming. It's not about my choice, it's about making the right choice for the users of my library. I don't want to impose verbosity on them and litter their markup with lengthy prefixes, and I don't want to impose nonconformance on them. Library devs should not be forced into this dilemma.

Re: fracturing the ecosystem, how does that not apply to custom element names?

whereas @zcorpan shows soundly with data that it does not hold in the real world

While I definitely commend the effort to get real data, I would take that percentage with a grain of salt:

  1. We're basically parsing HTML with regexes here
  2. None of this accounts for dynamically added attributes.
  3. It counts occurrence of each naming scheme per page, whereas I suspect that when ng- or v- attributes are used, A LOT of them are used.
  4. As I mentioned above, smaller libraries can use data- just fine. When you only have one or two attributes, the verbosity doesn't matter much and the collisions are more rare. It only takes 1 such library for a page to count in @zcorpan's data.
  5. As @Marat-Tanalin mentioned, data- is the only conformant option right now, don't you think that affects usage?
  6. These stats go against common knowledge: Angular and Vue are very popular, it seems weird that they'd be collectively used by only 0.4% of websites.

Fortunately, it's also one we can answer with data. That is, what percentage of those ~12.1% of pages are conformant? In other words, what percentage of people using data-* attributes are also people who care about conformance, and thus might have chosen data- over x- because of conformance concerns?

You're assuming here that everybody who cares about conformance is actually conformant. A parallel about religions and sins comes to mind. :) Many authors care about conformance, but don't actually validate, so they make mistakes that are never caught. However, conformance still influences their decision making.

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jan 19, 2017

Let me also repeat that I do support exploring the concept of custom attributes, with a processing model similar to custom elements. That gives serious benefits beyond just brevity, that IMO outweigh the practical disadvantages. It's the simple conformance change with no processing model that I am not in support of.

Nobody is against that. As I said above, that would be incredible! It would make my life so much easier. What I was suggesting is making the conformance change first, since it's easy, and adding the (harder to design) API as a later step, once it gets implementor interest and a spec editor willing to do it.

LeaVerou commented Jan 19, 2017

Let me also repeat that I do support exploring the concept of custom attributes, with a processing model similar to custom elements. That gives serious benefits beyond just brevity, that IMO outweigh the practical disadvantages. It's the simple conformance change with no processing model that I am not in support of.

Nobody is against that. As I said above, that would be incredible! It would make my life so much easier. What I was suggesting is making the conformance change first, since it's easy, and adding the (harder to design) API as a later step, once it gets implementor interest and a spec editor willing to do it.

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jan 19, 2017

@domenic

(Although maybe not?)

I would appreciate if you avoided further trolling.

FYI, unlike what you’ve probably naively assumed, I am aware the pubdate attribute is currently not in the HTML spec, so using the formally invalid attribute is not accidental. I use the attribute intentionally since it was previously specced and perfectly valid, but then has been removed on a purely theoretical basis by someone who unfortunately has a sort of overformal logical approach (but who is still able to be respectful and deserves to be respected) somewhat similar to yours, and recommended to use the bolted-on verbose pseudosemantic surrogate called Microdata instead. (Btw, the same person also tried to remove the TIME element in favor of a new cool universal element called… DATA, but fortunately failed thanks to massive web-developers’ objections.) Violating the current version of the HTML spec by continuing to use the pubdate attribute solely on my own site is a sort of my conscious and consistent objection to that (wrong in my opinion) decision. Moreover, according to my experience, at least Google search engine does support the attribute regardless of that it has been removed from the spec, so its use still makes sense in practice.

Marat-Tanalin commented Jan 19, 2017

@domenic

(Although maybe not?)

I would appreciate if you avoided further trolling.

FYI, unlike what you’ve probably naively assumed, I am aware the pubdate attribute is currently not in the HTML spec, so using the formally invalid attribute is not accidental. I use the attribute intentionally since it was previously specced and perfectly valid, but then has been removed on a purely theoretical basis by someone who unfortunately has a sort of overformal logical approach (but who is still able to be respectful and deserves to be respected) somewhat similar to yours, and recommended to use the bolted-on verbose pseudosemantic surrogate called Microdata instead. (Btw, the same person also tried to remove the TIME element in favor of a new cool universal element called… DATA, but fortunately failed thanks to massive web-developers’ objections.) Violating the current version of the HTML spec by continuing to use the pubdate attribute solely on my own site is a sort of my conscious and consistent objection to that (wrong in my opinion) decision. Moreover, according to my experience, at least Google search engine does support the attribute regardless of that it has been removed from the spec, so its use still makes sense in practice.

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jan 19, 2017

Another point worth making is the analogy to a previous push to use <i> for icons.

Any analogy suffers from inaccuracies, is not a proof or an argument of any kind, and is often actually just irrelevant offtopic noise.

Marat-Tanalin commented Jan 19, 2017

Another point worth making is the analogy to a previous push to use <i> for icons.

Any analogy suffers from inaccuracies, is not a proof or an argument of any kind, and is often actually just irrelevant offtopic noise.

@Hixie

This comment has been minimized.

Show comment
Hide comment
@Hixie

Hixie Jan 19, 2017

Member

Let's please remain focused on the technical issues.

Member

Hixie commented Jan 19, 2017

Let's please remain focused on the technical issues.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jul 4, 2017

Member

So far none of the arguments here have sufficed to convince the editors or address their objections in a satisfactory way, so no. See #2271 (comment) for my latest thinking, at least. In fact it maybe time to close the issue without action.

Member

domenic commented Jul 4, 2017

So far none of the arguments here have sufficed to convince the editors or address their objections in a satisfactory way, so no. See #2271 (comment) for my latest thinking, at least. In fact it maybe time to close the issue without action.

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jul 4, 2017

Probably the best option is just to use the feature since it just works in all browsers regardless of what the spec says.

Marat-Tanalin commented Jul 4, 2017

Probably the best option is just to use the feature since it just works in all browsers regardless of what the spec says.

@bfred-it

This comment has been minimized.

Show comment
Hide comment
@bfred-it

bfred-it Jul 4, 2017

Sure, why not

  1. Willingly risk things breaking in the future
  2. Cause headaches for spec authors who will have to work around stubborn library authors' decisions?

bfred-it commented Jul 4, 2017

Sure, why not

  1. Willingly risk things breaking in the future
  2. Cause headaches for spec authors who will have to work around stubborn library authors' decisions?
@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jul 4, 2017

  1. No risk at least with the underscore prefix. Standard attributes will never start with underscore.

  2. If the spec authors would be forced to standardize the feature they otherwise wouldn’t, that’d be a nice intended outcome.

Marat-Tanalin commented Jul 4, 2017

  1. No risk at least with the underscore prefix. Standard attributes will never start with underscore.

  2. If the spec authors would be forced to standardize the feature they otherwise wouldn’t, that’d be a nice intended outcome.

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jul 4, 2017

See #2271 (comment) for my latest thinking, at least. In fact it maybe time to close the issue without action.

I can't help but wonder if a similar analysis was done for custom element names. Did you find that nonstandard elements with hyphens were so widespread already that you had to standardize them? I’m guessing not. In fact, I'd wager that the number of invalid attribute names in the wild is much bigger than the number of invalid element names in the wild, even now. You just saw the need for a reasonable naming scheme that is not unreasonably verbose. Given that element names are only used once per element, and attributes multiple times, the need is greater here. This is a rather long discussion, where many people have expressed opinions, especially if you count the silent votes. It's disrespectful to all these people to close this with "no action" just because the feature we're proposing is not sufficiently in use already (even though the absolute numbers are in the thousands, unlike most proposed features!). That's a level of scrutiny that I have not seen applied to any other proposed feature in the Web platform.

LeaVerou commented Jul 4, 2017

See #2271 (comment) for my latest thinking, at least. In fact it maybe time to close the issue without action.

I can't help but wonder if a similar analysis was done for custom element names. Did you find that nonstandard elements with hyphens were so widespread already that you had to standardize them? I’m guessing not. In fact, I'd wager that the number of invalid attribute names in the wild is much bigger than the number of invalid element names in the wild, even now. You just saw the need for a reasonable naming scheme that is not unreasonably verbose. Given that element names are only used once per element, and attributes multiple times, the need is greater here. This is a rather long discussion, where many people have expressed opinions, especially if you count the silent votes. It's disrespectful to all these people to close this with "no action" just because the feature we're proposing is not sufficiently in use already (even though the absolute numbers are in the thousands, unlike most proposed features!). That's a level of scrutiny that I have not seen applied to any other proposed feature in the Web platform.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jul 5, 2017

Member

The analogy with custom elements is a good one, especially from a cost vs. benefit perspective. Custom elements bring whole new capabilities to the platform, allowing you to hook into the parser and react to element lifecycles in a way that was impossible before. That's worth the downside, in our eyes.

On the contrary, the benefit of the change proposed here is that some people will be able to get both shorter custom attribute names and still have their pages validate. That's not worth the downsides that have been enumerated, especially given that people can do either of those things alone as long as they don't want to do them together.

Finally this lets me reiterate the point I've made several times now. Which is that if we had a true custom attributes feature, exposing low-level platform capabilities in the same way custom elements did, then it would be a worthwhile. In the absence of that, it's not.

Member

domenic commented Jul 5, 2017

The analogy with custom elements is a good one, especially from a cost vs. benefit perspective. Custom elements bring whole new capabilities to the platform, allowing you to hook into the parser and react to element lifecycles in a way that was impossible before. That's worth the downside, in our eyes.

On the contrary, the benefit of the change proposed here is that some people will be able to get both shorter custom attribute names and still have their pages validate. That's not worth the downsides that have been enumerated, especially given that people can do either of those things alone as long as they don't want to do them together.

Finally this lets me reiterate the point I've made several times now. Which is that if we had a true custom attributes feature, exposing low-level platform capabilities in the same way custom elements did, then it would be a worthwhile. In the absence of that, it's not.

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jul 5, 2017

Finally this lets me reiterate the point I've made several times now. Which is that if we had a true custom attributes feature, exposing low-level platform capabilities in the same way custom elements did, then it would be a worthwhile. In the absence of that, it's not.

Then let's do that! That's what we really need, only making them valid is a compromise, as it seems easier to implement.

LeaVerou commented Jul 5, 2017

Finally this lets me reiterate the point I've made several times now. Which is that if we had a true custom attributes feature, exposing low-level platform capabilities in the same way custom elements did, then it would be a worthwhile. In the absence of that, it's not.

Then let's do that! That's what we really need, only making them valid is a compromise, as it seems easier to implement.

@nuxodin

This comment has been minimized.

Show comment
Hide comment
@nuxodin

nuxodin Jul 5, 2017

I think html-syntax should not be influenced by DOM APIs

The advantages I see:

  • Same rules as custom-elements
  • Shorter (yes, there can be a lot of custom-attributes)
  • Standardizise what is allready in use and can not be overturned
  • Armed for a future API like "document.registerAttribute('my-title')"

nuxodin commented Jul 5, 2017

I think html-syntax should not be influenced by DOM APIs

The advantages I see:

  • Same rules as custom-elements
  • Shorter (yes, there can be a lot of custom-attributes)
  • Standardizise what is allready in use and can not be overturned
  • Armed for a future API like "document.registerAttribute('my-title')"
@bedeoverend

This comment has been minimized.

Show comment
Hide comment
@bedeoverend

bedeoverend Jul 31, 2017

FWIW re: Custom Attributes similar to Custom Elements, there's a custom-attributes library which follows the Custom Elements API very closely (almost identical), to allow a mixin style of functionality. Might be a good spot to test the waters / API.

As @annevk mentioned, it was discussed (briefly) at 2016 TPAC - see this tweet, and personally would love to see it discussed in more depth at this years 2017 TPAC. I feel Custom Attributes could solve a lot of of problems as well as this one, namely in the Custom Elements domain e.g. inheritance debate

bedeoverend commented Jul 31, 2017

FWIW re: Custom Attributes similar to Custom Elements, there's a custom-attributes library which follows the Custom Elements API very closely (almost identical), to allow a mixin style of functionality. Might be a good spot to test the waters / API.

As @annevk mentioned, it was discussed (briefly) at 2016 TPAC - see this tweet, and personally would love to see it discussed in more depth at this years 2017 TPAC. I feel Custom Attributes could solve a lot of of problems as well as this one, namely in the Custom Elements domain e.g. inheritance debate

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Jul 31, 2017

I was at TPAC 2016, shame I missed this discussion. I will be at TPAC 2017 too, I'll make sure not to miss it again :)

Custom elements and custom attributes are inextricably linked. If custom elements are going to act like normal HTML elements, their functionality could require annotating existing HTML elements too. For example, let's assume <datalist> did not exist and had to be implemented with a custom element (e.g. <foo-datalist>). We would need a custom attribute on <input> to go with it (foo-list). It seems odd to spec the element part but not the attribute part.

LeaVerou commented Jul 31, 2017

I was at TPAC 2016, shame I missed this discussion. I will be at TPAC 2017 too, I'll make sure not to miss it again :)

Custom elements and custom attributes are inextricably linked. If custom elements are going to act like normal HTML elements, their functionality could require annotating existing HTML elements too. For example, let's assume <datalist> did not exist and had to be implemented with a custom element (e.g. <foo-datalist>). We would need a custom attribute on <input> to go with it (foo-list). It seems odd to spec the element part but not the attribute part.

@digeomel

This comment has been minimized.

Show comment
Hide comment
@digeomel

digeomel Jul 31, 2017

Coming back to my practical Web developer's point of view, has anybody noticed what's going on with attributes in Angular (2+)? They have all sorts of (I would assume non-standard) symbols, stars, parentheses, brackets, square brackets, parentheses in square brackets... 😝
I guess the Angular team has not been reading this discussion or they just couldn't care less about W3C standards because... Google?

digeomel commented Jul 31, 2017

Coming back to my practical Web developer's point of view, has anybody noticed what's going on with attributes in Angular (2+)? They have all sorts of (I would assume non-standard) symbols, stars, parentheses, brackets, square brackets, parentheses in square brackets... 😝
I guess the Angular team has not been reading this discussion or they just couldn't care less about W3C standards because... Google?

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 16, 2017

Member

@digeomel interesting, thanks for pointing that out (see https://angular.io/guide/template-syntax for examples). If whatwg/dom#449 is successful, maybe we should allow such attribute names (despite the XML incompatibility).

Member

zcorpan commented Aug 16, 2017

@digeomel interesting, thanks for pointing that out (see https://angular.io/guide/template-syntax for examples). If whatwg/dom#449 is successful, maybe we should allow such attribute names (despite the XML incompatibility).

@strongholdmedia

This comment has been minimized.

Show comment
Hide comment
@strongholdmedia

strongholdmedia Aug 16, 2017

I guess the Angular team has not been reading this discussion or they just couldn't care less about W3C standards because... Google?

Seems like that, yep. Like the "don't be evil" times are way over.
(Too bad "vue" followed suit though.)

strongholdmedia commented Aug 16, 2017

I guess the Angular team has not been reading this discussion or they just couldn't care less about W3C standards because... Google?

Seems like that, yep. Like the "don't be evil" times are way over.
(Too bad "vue" followed suit though.)

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 17, 2017

Member

Please stop the attacks against Google. They're not welcome here as per https://whatwg.org/code-of-conduct.

Member

annevk commented Aug 17, 2017

Please stop the attacks against Google. They're not welcome here as per https://whatwg.org/code-of-conduct.

@snuggs

This comment has been minimized.

Show comment
Hide comment
@snuggs

snuggs Sep 10, 2017

Member

@LeaVerou @bedeoverend @Marat-Tanalin @rniwa @annevk @chaoaretasty @strongholdmedia please note that custom elements cannot have an empty prefix section i.e. -foo. Just a heads up as have recently had this discussion ad nauseam. Just wanted to be clear as this is the only naming caveat when comparing custom elements name conventions/restrictions to custom attributes being named similar to custom elements

Just thought i'd mention as @bfred-it stated he'd love the -foo syntax. For Custom Element definitions that wouldn't validate the PotentialCustomElementsName production restrictions

which enforces [a-z] (PCENChar)* '-' (PCENChar)*

capture d ecran 2017-09-10 a 12 15 22

Member

snuggs commented Sep 10, 2017

@LeaVerou @bedeoverend @Marat-Tanalin @rniwa @annevk @chaoaretasty @strongholdmedia please note that custom elements cannot have an empty prefix section i.e. -foo. Just a heads up as have recently had this discussion ad nauseam. Just wanted to be clear as this is the only naming caveat when comparing custom elements name conventions/restrictions to custom attributes being named similar to custom elements

Just thought i'd mention as @bfred-it stated he'd love the -foo syntax. For Custom Element definitions that wouldn't validate the PotentialCustomElementsName production restrictions

which enforces [a-z] (PCENChar)* '-' (PCENChar)*

capture d ecran 2017-09-10 a 12 15 22

@strongholdmedia

This comment has been minimized.

Show comment
Hide comment
@strongholdmedia

strongholdmedia Sep 10, 2017

Thanks for the follow up.
Of course, XML standard specifically prohibits "Name" (as per a subset of NMTOKEN) to start with anything non-alpha.
But it allows "Name" to start with underscore, no matter it be an element name or attribute name.
This is consistent with that part of the PotentialCustomElementsName specification too.
(As a side note, I personally think the "blacklisting the already-used names" exclusion method is kind of horrible and prone to future collisions. But then again, maybe it is better to have collisions than a beautiful garden nobody visits.)

strongholdmedia commented Sep 10, 2017

Thanks for the follow up.
Of course, XML standard specifically prohibits "Name" (as per a subset of NMTOKEN) to start with anything non-alpha.
But it allows "Name" to start with underscore, no matter it be an element name or attribute name.
This is consistent with that part of the PotentialCustomElementsName specification too.
(As a side note, I personally think the "blacklisting the already-used names" exclusion method is kind of horrible and prone to future collisions. But then again, maybe it is better to have collisions than a beautiful garden nobody visits.)

@tsteuwer

This comment has been minimized.

Show comment
Hide comment
@tsteuwer

tsteuwer Oct 9, 2017

I know I'm a little late but it would be great to not have to do the data-. Every developer I know thinks it's very annoying lol.

tsteuwer commented Oct 9, 2017

I know I'm a little late but it would be great to not have to do the data-. Every developer I know thinks it's very annoying lol.

@kumarharsh

This comment has been minimized.

Show comment
Hide comment
@kumarharsh

kumarharsh Nov 13, 2017

I found @strongholdmedia's suggestion of using a colon for denoting custom attributes to be a good solution, but seems like using colon would be invalid in HTML5 parsed as XML? (https://www.w3.org/TR/html5-diff/#syntax and https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax). Which leaves us with @Marat-Tanalin's _ style attributes.

I came here from @LeaVerou's mavo website and initially felt that it made sense to drop data- attributes. (I used them extensively in angular 1.4, but then angular itself moved away from it towards a very puzzling syntax). But after reading all the comments here, and in the linked issues above, I feel conflicted. As a developer, adopting the mv- style 2-letter attributes feels like an arbitrary restriction, even though it does save me time from typing out data- every time. The _ syntax feels ok but looks ugly in a sea of hyphens.

From the spec:

Attributes have a name and a value. Attribute names must consist of one or more characters other than the space characters, U+0000 NULL, U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), ">" (U+003E), "/" (U+002F), and "=" (U+003D) characters, the control characters, and any characters that are not defined by Unicode. In the HTML syntax, attribute names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that are an ASCII case-insensitive match for the attribute's name.

Then, you could also have -my-* style attributes, correct? I don't think there's any possible clash with SVG or other standard HTML attributes here? I'd serve the same as _-based proposition above, but would be more in-line with what is already there.


But, as a committee which has to decide on the spec to "set in stone" the validity of the attributes, and these solutions feel like only an iterative improvement over the existence of data- attributes, and probably might just work to fragment the developers' usage even more.

I still feel there's a strong advantage to sticking to a single sanctioned convention (data-) for custom data attributes, at least until we have a processing model for the "custom attributes".

I don't know what this means, and couldn't find a link describing the 'processing model', but it sounds promising.

kumarharsh commented Nov 13, 2017

I found @strongholdmedia's suggestion of using a colon for denoting custom attributes to be a good solution, but seems like using colon would be invalid in HTML5 parsed as XML? (https://www.w3.org/TR/html5-diff/#syntax and https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax). Which leaves us with @Marat-Tanalin's _ style attributes.

I came here from @LeaVerou's mavo website and initially felt that it made sense to drop data- attributes. (I used them extensively in angular 1.4, but then angular itself moved away from it towards a very puzzling syntax). But after reading all the comments here, and in the linked issues above, I feel conflicted. As a developer, adopting the mv- style 2-letter attributes feels like an arbitrary restriction, even though it does save me time from typing out data- every time. The _ syntax feels ok but looks ugly in a sea of hyphens.

From the spec:

Attributes have a name and a value. Attribute names must consist of one or more characters other than the space characters, U+0000 NULL, U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), ">" (U+003E), "/" (U+002F), and "=" (U+003D) characters, the control characters, and any characters that are not defined by Unicode. In the HTML syntax, attribute names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that are an ASCII case-insensitive match for the attribute's name.

Then, you could also have -my-* style attributes, correct? I don't think there's any possible clash with SVG or other standard HTML attributes here? I'd serve the same as _-based proposition above, but would be more in-line with what is already there.


But, as a committee which has to decide on the spec to "set in stone" the validity of the attributes, and these solutions feel like only an iterative improvement over the existence of data- attributes, and probably might just work to fragment the developers' usage even more.

I still feel there's a strong advantage to sticking to a single sanctioned convention (data-) for custom data attributes, at least until we have a processing model for the "custom attributes".

I don't know what this means, and couldn't find a link describing the 'processing model', but it sounds promising.

@strongholdmedia

This comment has been minimized.

Show comment
Hide comment
@strongholdmedia

strongholdmedia Nov 13, 2017

I found @strongholdmedia's suggestion of using a colon for denoting custom attributes to be a good solution, but seems like using colon would be invalid in HTML5 parsed as XML?

I am unsure if I was suggesting anything like it, IIRC, it is rather the XML spec itself that allows such namings/NMTOKENs.

seems like using colon would be invalid in HTML5 parsed as XML?

From what I read,

A node with a local name containing a ":" (U+003A).

it comes to my understanding that this is due to these being forbidden for they are used to reference other namespaces. So your suspicion seems correct.

I'd serve the same as _-based proposition above, but would be more in-line with what is already there.

Please note that standardising "what is already there", as opposed to premature optimization, is in reality the root of all evil.
Of course, there may be tried and true solutions and methods for different things, but just that something is widespread does not mean it is any good (just that, at a specific time, it was better than anything else widely known).

As for standardization, IMHO constructing a spec having a fixed - and lengthy - list of exceptions to it (on different bases mostly aggregating around things like "they was there first") pretty much nukes the purpose to begin with.

strongholdmedia commented Nov 13, 2017

I found @strongholdmedia's suggestion of using a colon for denoting custom attributes to be a good solution, but seems like using colon would be invalid in HTML5 parsed as XML?

I am unsure if I was suggesting anything like it, IIRC, it is rather the XML spec itself that allows such namings/NMTOKENs.

seems like using colon would be invalid in HTML5 parsed as XML?

From what I read,

A node with a local name containing a ":" (U+003A).

it comes to my understanding that this is due to these being forbidden for they are used to reference other namespaces. So your suspicion seems correct.

I'd serve the same as _-based proposition above, but would be more in-line with what is already there.

Please note that standardising "what is already there", as opposed to premature optimization, is in reality the root of all evil.
Of course, there may be tried and true solutions and methods for different things, but just that something is widespread does not mean it is any good (just that, at a specific time, it was better than anything else widely known).

As for standardization, IMHO constructing a spec having a fixed - and lengthy - list of exceptions to it (on different bases mostly aggregating around things like "they was there first") pretty much nukes the purpose to begin with.

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Dec 6, 2017

Another use case: Web Components that degrade gracefully.

For example, take a look at this carousel component

It’s used like this:

<skeleton-carousel dots nav loop>
  <iron-image placeholder="https://source.unsplash.com/category/nature/10x10"
              data-src="https://source.unsplash.com/category/nature/500x300"
              sizing="cover"
              preload
              fade
              ></iron-image>
  <iron-image placeholder="https://source.unsplash.com/category/food/10x10"
              data-src="https://source.unsplash.com/category/food/500x300"
              sizing="cover"
              preload
              fade
              ></iron-image>
  <iron-image placeholder="https://source.unsplash.com/category/buildings/10x10"
              data-src="https://source.unsplash.com/category/buildings/500x300"
              sizing="cover"
              preload
              fade
              ></iron-image>
</skeleton-carousel>

Wouldn't it be great if its content was proper <img> tags, so that something reasonable is visible in older browsers?
But if you do that, then the attributes would have to be data- prefixed with no indication of which attributes belong to the component and which ones don't.

LeaVerou commented Dec 6, 2017

Another use case: Web Components that degrade gracefully.

For example, take a look at this carousel component

It’s used like this:

<skeleton-carousel dots nav loop>
  <iron-image placeholder="https://source.unsplash.com/category/nature/10x10"
              data-src="https://source.unsplash.com/category/nature/500x300"
              sizing="cover"
              preload
              fade
              ></iron-image>
  <iron-image placeholder="https://source.unsplash.com/category/food/10x10"
              data-src="https://source.unsplash.com/category/food/500x300"
              sizing="cover"
              preload
              fade
              ></iron-image>
  <iron-image placeholder="https://source.unsplash.com/category/buildings/10x10"
              data-src="https://source.unsplash.com/category/buildings/500x300"
              sizing="cover"
              preload
              fade
              ></iron-image>
</skeleton-carousel>

Wouldn't it be great if its content was proper <img> tags, so that something reasonable is visible in older browsers?
But if you do that, then the attributes would have to be data- prefixed with no indication of which attributes belong to the component and which ones don't.

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 25, 2018

@LeaVerou

Wouldn't it be great if its content was proper tags, so that something reasonable is visible in older browsers?
But if you do that, then the attributes would have to be data- prefixed with no indication of which attributes belong to the component and which ones don't.

What am I missing? If you customised the img element, e.g.

<img is="iron-image" src="some.img" alt="what?"...>

You would use normal attributes where they existed, no? Isn't it only an issue where you are making up something completely new anyway?

chaals commented Apr 25, 2018

@LeaVerou

Wouldn't it be great if its content was proper tags, so that something reasonable is visible in older browsers?
But if you do that, then the attributes would have to be data- prefixed with no indication of which attributes belong to the component and which ones don't.

What am I missing? If you customised the img element, e.g.

<img is="iron-image" src="some.img" alt="what?"...>

You would use normal attributes where they existed, no? Isn't it only an issue where you are making up something completely new anyway?

@effulgentsia

This comment has been minimized.

Show comment
Hide comment
@effulgentsia

effulgentsia Apr 25, 2018

@chaals: I think the issue is that the current custom elements spec says:

Customized built-in elements follow the normal requirements for attributes, based on the elements they extend. To add custom attribute-based behavior, use data-* attributes.

So if you write a component as <img is="iron-image", then all attributes defined by the iron-image component need to be data- prefixed. But data-* attributes are also used by whatever other scripts (unrelated to the iron-image component) might be interacting with the page that contains an <img is="iron-image" element. Hence, @LeaVerou's observation that:

no indication of which [data-*] attributes belong to the component and which ones don't

effulgentsia commented Apr 25, 2018

@chaals: I think the issue is that the current custom elements spec says:

Customized built-in elements follow the normal requirements for attributes, based on the elements they extend. To add custom attribute-based behavior, use data-* attributes.

So if you write a component as <img is="iron-image", then all attributes defined by the iron-image component need to be data- prefixed. But data-* attributes are also used by whatever other scripts (unrelated to the iron-image component) might be interacting with the page that contains an <img is="iron-image" element. Hence, @LeaVerou's observation that:

no indication of which [data-*] attributes belong to the component and which ones don't

@LeaVerou

This comment has been minimized.

Show comment
Hide comment
@LeaVerou

LeaVerou Apr 28, 2018

@chaals They are not customizing the <img> element because they don't want data- prefixed attributes (and I don't blame them). They use custom elements just so they can use shorter attribute names, so there is no fallback.

LeaVerou commented Apr 28, 2018

@chaals They are not customizing the <img> element because they don't want data- prefixed attributes (and I don't blame them). They use custom elements just so they can use shorter attribute names, so there is no fallback.

@strongholdmedia

This comment has been minimized.

Show comment
Hide comment
@strongholdmedia

strongholdmedia Apr 30, 2018

But if you do that, then the attributes would have to be data- prefixed with no indication of which attributes belong to the component and which ones don't.

Following your logic, those attributes that display "something reasonable" in "older" browsers -or affect the appearance - do belong to the "component", while the others don't.

In my opinion, one should not use the markup layer for state and unpredictable side effects at all, for that is violation of the single responsibility principle. But this is exactly what Angular or Vue does.

I believe that people should not at all use something like your skeleton-carousel in the markup as well. For these types of things, there is - was and will be - XML/XSLT always, should anybody find the need.

After all, what could the benefits be of "knowing" what "attributes" do, according to the designer's own logic, belong to the component, if one could not reasonably deduce what attributes will actually affect the rendering in any conformant and well-specified client?
Does anyone really want to reduce the concept of well-formedness to having an even number of quotation marks or inequality marks?

I think, after following this discourse for a while, that perhaps the idea of a specific layer, just like XML/XSLT but maybe distinct, being promoted towards those people who are obsessed with this component-oriented thing that is, in my opinion, somewhat distinct and distant from the concept of DOM and what it was conceived for, that also conveys the abandon hope all ye who enter here type of note in and of itself for others; and that HTML be left to those who actually prefer documentation over convention of people with random mindsets that they may, at times, consider counter-intuitive or even marginal, is possibly better for both worlds.

strongholdmedia commented Apr 30, 2018

But if you do that, then the attributes would have to be data- prefixed with no indication of which attributes belong to the component and which ones don't.

Following your logic, those attributes that display "something reasonable" in "older" browsers -or affect the appearance - do belong to the "component", while the others don't.

In my opinion, one should not use the markup layer for state and unpredictable side effects at all, for that is violation of the single responsibility principle. But this is exactly what Angular or Vue does.

I believe that people should not at all use something like your skeleton-carousel in the markup as well. For these types of things, there is - was and will be - XML/XSLT always, should anybody find the need.

After all, what could the benefits be of "knowing" what "attributes" do, according to the designer's own logic, belong to the component, if one could not reasonably deduce what attributes will actually affect the rendering in any conformant and well-specified client?
Does anyone really want to reduce the concept of well-formedness to having an even number of quotation marks or inequality marks?

I think, after following this discourse for a while, that perhaps the idea of a specific layer, just like XML/XSLT but maybe distinct, being promoted towards those people who are obsessed with this component-oriented thing that is, in my opinion, somewhat distinct and distant from the concept of DOM and what it was conceived for, that also conveys the abandon hope all ye who enter here type of note in and of itself for others; and that HTML be left to those who actually prefer documentation over convention of people with random mindsets that they may, at times, consider counter-intuitive or even marginal, is possibly better for both worlds.

@chaals chaals referenced this issue Jun 19, 2018

Closed

HTML General Review: Custom Elements #244

1 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment