Make custom attribute rules consistent with custom element name rules

[LeaVerou]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

@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]

@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]

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]

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]

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]

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]

@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]

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]

Let's please remain focused on the technical issues.

[zcorpan]

Please don't add off-topic comments. This issue is about custom attributes.

To move this issue forward, a good step would be to ask implementers if there's interest in an API for observing changes to custom attributes as annevk suggested.

[nuxodin]

Since the css function attr() will be usable with all attributes, it might be a good time to think about a specification for custom attributes.
https://www.w3.org/TR/css3-values/#attr-notation

[Malvoz]

Since the css function attr() will be usable with all attributes

attr() may be limited to a subset of prefixed attributes, see w3c/csswg-drafts#5136.

[JoshuaWise]

I'm currently in the process of writing a framework built on Web Components (custom elements), and I'm having a very hard time figuring out how to handle the name-spacing of attributes. The way I see it, there are 3 different agents who may want to define attributes on custom elements:

• The consumer of the custom element. The intent may be to mark the element for querySelector() purposes or for CSS.
• The author of the custom element. The intent may be to provide an interface with the consumer for receiving initial state or reflecting the element's state.
• The user-agent (browser), which will inevitably define new global attributes in the future, for arbitrary purposes.

The first group of people (consumers of the element) can simply use data-* attributes, which are reserved by the spec for this purpose.

The third group of people (browsers) tend to define attributes that are single lowercased words, but I'm not confident that I can rely on that assumption.

The second group of people (authors of custom elements) seemingly have no good solution. They can't use data-* attributes because those are reserved for the consumers of the element. And without some guarantees about the naming of future global attributes, they have no way of protecting themselves against future name collisions.

As a software engineer, the obvious solution to me is namespaces. If we can't use colon (:) namespaces due to XML compatibility, then hyphen (-) namespaces seem perfectly fine. Each independent agent can define their own namespace to work in. The data- namespace is for the website author. The "empty" namespace (no hyphen) is for browsers. And every other namespace (except aria-, I guess) is for everybody in-between.

[strongholdmedia]

As a software engineer, the obvious solution to me is namespaces. If we can't use colon (:) namespaces due to XML compatibility, then hyphen (-) namespaces seem perfectly fine. Each independent agent can define their own namespace to work in. The data- namespace is for the website author. The "empty" namespace (no hyphen) is for browsers. And every other namespace (except aria-, I guess) is for everybody in-between.

You, sir, as your name suggests, are indeed very wise.
I also insisted that something similar be made / kept, but ran into the some actors doing what-when-ever they deem feasible attitude that turned out persistent, and thus gave up.

[enkelmedia]

This really needs attention, I don't understand why the standard is enforcing things that makes cross-browser functional code invalid "HTML" so that we have to either stop to care about the standard or over and over explain to customers that the standard is behind reality. Leaving them worries without no real reson.

It's time to get up to speed with how things are actually used and update the standards - otherwise the relevance of the standard will decrease and become something that people see as "something from the past".

There is plenty of good ideas from 3-4 years ago - why is this stale?

[zcorpan]

@strongholdmedia Please do not derail the discussion with issues that have nothing to do with the topic at hand.

@enkelmedia my previous comment suggests a next step for this issue.

[RouninMedia]

Amongst others, @JoshuaWise's comments (2020-12-14) suggest a clear outline for a practical, useful and consistent approach moving forward:

• non-hyphenated attributes: standard, attributes introduced by Spec Authors
• hyphenated attributes: custom attributes introduced by Custom Element / WebComponent Authors
• data-attributes: custom attributes applied by Consumers of standard & custom elements

This leaves Library / Framework / WebComponent Authors (the middle group) needing to take note of a couple of well-known, reserved hyphenated prefixes - eg. don't use the prefix http- (because it already exists in http-equiv) and don't use data- or aria- - but otherwise Library / Framework / WebComponent Authors retain a free hand to build their own hyphenated custom attribute names, constrained only by the same requirements which apply to custom element names.

This means both ng- and v- can be welcomed (at last) as valid custom attribute prefixes.

Arguably, the most significant issue to resolve remains what to do about SVG (as @LeaVerou mentioned at the very beginning) since standard attribute names are frequently hyphenated in SVG. This threatens a worst case scenario of many name collisions between standard (hyphenated) SVG attribute names and custom (hyphenated) attribute names: not only in the present but (worse) in the future.

Perhaps here is where the leading underscore can come into play? A leading underscore which the SVG parser always takes note of but which remains optional in HTML, because the HTML parser always ignores it? (In the same way that the HTML5 parser ignores any XHTML-style trailing slash in self-closing elements).

Thus, in HTML:

• enable-background
• _enable-background

are functionally identical and in practice - or most of the time, at least - only the former will ever tend to be used.

Whereas, in SVG:

• enable-background
• _enable-background

the former is parsed as a specced standard attribute, while the latter may be immediately recognised (by developers and user-agents) as a custom attribute.

Is that too confusing? To have _enable-background mean the same thing as enable-background in HTML, but for the two names to mean two different things in SVG? There certainly is a precedent for syntax not always meaning the same thing in HTML and SVG - not least in that SVG is case-sensitive, while HTML is case-insensitive.

Advice to custom element authors would be:

• if you wish to, you can, in every context, always prefix your hyphenated custom attributes with an underscore
• though, for all practical purposes it makes no difference whether you do or not in HTML
• however in SVG, it absolutely does make a difference, so when writing SVG, be sure to always prefix with an underscore

[zcorpan]

We can't ignore a leading _ in attribute names in HTML, that would likely break content that uses it and expects the underscore to not be ignored.

[RouninMedia]

Three (genuine) questions in response:

1. Are there already standard attribute names in HTML which begin with a _ ?

2. Are there any frameworks / libraries / environments where a pair of distinct custom attributes exist which have identical names, save for the fact that one begins with a leading underscore and the other does not?

3. Are there any frameworks / libraries / environments which introduce (or allow for) a custom attribute which has an identical name to an already-existing standard attribute, save for the fact that it begins with a leading underscore?

[zcorpan]

1. No
2. It seems unlikely, but I don't know.
3. There are such instances in https://gist.github.com/zcorpan/b54592e415a2f79f2ef7f79c0c37b2ed e.g. <img _src=...>

Last time I looked at non-standard attributes in HTTP Archive (see #2271 (comment) ), there were 531 instances with a leading _ excluding _moz_. Those pages might use those attributes from JS or CSS and therefore rely on the _ not being ignored (e.g. removed by the HTML parser).

[RouninMedia]

Many thanks for that clarification, @zcorpan.

Yes, I concede: we can't make a leading _ character ostensibly superfluous in custom HTML attributes if attributes such as _src are already in use alongside src.

Not wishing to sound absurd, but if a single _ as an arbitrary prefix is out of the question, then what about a double __?

After all, in this suggestion, the HTML-optional / SVG-obligatory underscore(s) aren't being introduced as prefixes for the benefit of the HTML parser - the HTML parser is already capable of recognising that any attribute which includes two hyphenated words (of which the first isn't aria-, http- etc.) must be a Custom Attribute.

The purpose of introducing HTML-optional / SVG-obligatory underscores is so the SVG parser may immediately distinguish between regular attributes with hyphens and Custom Attributes which (also obligatorily) include hyphens.

That is:

1. a hyphen is enough of a distinguishing feature in HTML to indicate that the attribute is a Custom Attribute (subject to not using a small handful of reserved hyphenated prefixes)

2. a hyphen is an insufficiently distinguishing feature in SVG, so another feature - in this case a double underscore prefix - is utilised

3. the HTML parser knows to ignore the double underscore prefix when it sees it, since this is an SVG convention and instead will only look for whether the attribute name is hyphenated or not

[mangelozzi]

@ domenic

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.

I would like to state that the deduction of looking at the data reveals what people prefer is not 100% valid. People currently use data because that is currently endorsed and people have no other option (or can rebel). E.g. I use data- because I want to be conform, however I would love to use custom attributes that start with a prefix. So it you polled my website you would say I am in favour of data- only. I think data- is great, and use it all the time, but in addition to that there are many good use cases for custom prefixes. data- is more end user centric, custom prefixes is very nice for frameworks (to avoid collisions with user's data- attributes).

Its exact reason that native HTML components have their own attributes, instead of using class names, so they don't step on user's class names. We need something that sits between the native spec and the end user for framework developers.

If browsers ate their own dog food (e.g. web components), it would make web developement much better.

[WebReflection]

to whom it might concern, also as possible playground, there's a proxy-pants dsm export that, if tree-shaked, or required as proxy-pants/dsm, allows lazy one-off creation of dataset like namespaces, as long as the suffix is set.

const {ngset: ng} = dsm(element);

// set ng-test attribute
ng.test = 'value';

// remove ng-test attribute
delete ng.test;

It works for const {vset: v} = dsm(element); too, and retrieving the same set multiple times is weakly created/referenced once, to mimic what DOMStringMap via dataset do.

Not sure this is the answer anyone is looking for, but as use case/utility to test/play with, maybe it's useful, and it's also extremely tiny in size and logic.

[alexpetros]

This issue has been around for a while, but now is a great time to make some progress on it again. Declarative front-end libraries are having a small (maybe medium?) moment, and a lot of them make use of the *-attribute pattern:

• x-attribute for AlpineJS
• hx-attribute for htmx
• data-turbo-attribute for Turbo (and I'm sure they would be very happy to omit the data)

In addition, of course, to established libraries like Angular and Vue.

This emergent behavior exists for exactly the reason that @JoshuaWise describes: library authors want to namespace their attributes, and they will do so with the most ergonomic mechanism available to them. Some, like Turbo, decide that not using data- isn't worth the risk, but I also agree with @Jamesernator's point that every official example of data- attributes shows them being used to store... data, not functionality. data- attributes are clearly not intended to be the basis for future-proof attribute extensions to HTML, and I don't see anyone suggesting that they should be.

So there a lot of new people (myself included) who, after years of writing JSX that compiles down to HTML, are newly-interested in HTML as an authorship language in its own right. And the first thing they'll discover is that the tools that brought them back from SPA-land are, according to the standards body, invalid HTML. They will draw either one of two conclusions from this. Either:

a) the libraries brought this issue to their attention in the first place made a mistake
b) WHATWG is too slow/out of touch and validation doesn't matter.

As @LeaVerou correctly pointed out six years ago: "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."

The last comment we got from WHATWG about moving this forward was from @zcorpan, who said that if we should reach out to implementers to see if there's any interest in adding events to attribute changes to make them observable. This is an excellent idea, but I don't see why it should hold up standardization of custom attributes with hyphens. The existing solutions for observing attributes are clunky, but they work well enough to build successful libraries. If the only way to move this issue forward to convince a company to devote engineering resources to it, I expect it will continue sitting for a long time.

Simply reserving non-extant hyphenated attributes in the standard, which requires no work from implementers, would demonstrate the demand for this feature. If people made increased use of it, then it would be easier to convince implementers that adding additional observability features is worth their time. I likewise suggest punting on the SVG question by just not reserving hyphenated attributes in SVGs (but if that doesn't work, at least we can move the discussion forward by saying "we can do this once we resolve the SVG question").

I think it's extremely encouraging that this issue has remained open, because it demonstrates interest from both the applicants and WHATWG in resolving this. I also have immense respect for the standards body being conservative with the standard, so that we can ensure its essential backwards and forwards compatibility. In light of that, let's take the smallest possible victory—reserving non-extant hyphenated attributes in HTML—and see if it generates some momentum for custom attributes more generally. I'm happy to open a new issue if you feel that's appropriate, and am also generally available to push this forward in any way I can.

[bkardell]

@alexpetros note the several links just above your comment from this year, including positive movement and discussion at TPAC this year in w3c/tpac2023-breakouts#44 (which links to several relevant issues). People are still interested, and I think we're much closer to hitting a moment in which focus and progress are more likely to be made.

[alexpetros]

@bkardell, first of all, it is very heartening to see the positive movement from the breakout sessions, and to see some people who gave up on this discussion actively participating in them.

That having been said, focusing on those issues is precisely what I think has led to the decision paralysis here. Custom behavior raises the following questions:

1. Should users be able to extend HTML with custom behavior?
2. If so, are custom attributes a reasonable place to put that behavior?
3. If so, is reserving attributes with hyphens for custom behavior correct? <---- we are here
4. If so, what should the JavaScript interface be for specifying the behavior declared in those attributes?

Questions 1 and 2 are resolved by the existence of JavaScript, and data-* attributes, respectively. The issues from the breakout session that deal with custom attributes deal with Question 4.

Question 3 is not an easy question, but is much easier than Question 4, and is also a priori. Resolving "should WHATWG reserve future kebab-case attributes for user-specified behavior" will not only help clarify one of the many questions raised by this proposal, it will inject it with momentum by erecting fences around the cowpath, for future pavement.

While this issue has been a little contentious, it has also been extremely focused—almost all the comments are salient points in either direction. I'm not saying that we should rubber-stamp kebab-case attributes tomorrow, but that it can (and should) be resolved on its own merits; logrolling the declarative specification (Question 3, this issue) and imperative implementation (Question 4) will only serve to delay both.

Question 3 also has the advantage (and the urgency) of having been resolved by the library market, while Question 4 resolutely is not. To use a practical example, both htmx and AlpineJS allow for declaring arbitrary even listeners (i.e. x-on:click, but the click could be any event). Since querySelector doesn't support wildcards in attribute names, AlpineJS finds these by walking the entire tree (h/t @dz4k for this) while htmx uses a mildly outrageous XPath query. But they both use custom-prefixed kebab-case attributes. Future developments in the declarative HTML extension space will likely do the same.

We can take the pressure off the committee doing the implementation work by sanctioning kebab-case attributes first. Then the libraries can kludge along successfully (and with valid HTML!) until a more efficient and streamlined JavaScript API is available.