Support `5xx` syntax for response-targets

[spiffytech]

It appears that Rust's Maud HTML templating tool doesn't support asterisks in HTML attribute names, as used in the response-targets extension.

I wouldn't be surprised if there are other tools that don't support the syntax, given I can't recall seeing it used anywhere else.

I considered asking Maud to add support, but it looks like the asterisks might violate the HTML spec: while HTML built-in attributes seem allowed to use them, data- attributes and attributes on custom elements can't.

Given that, I request that the response-targets extension support an alternate wildcard syntax, hx-target-5xx, that's unambiguously HTML-compliant.

[alexpetros]

data- attributes and attributes on custom elements can't.

Do you have a citation for that? Looks like it's allowed to me.

[spiffytech]

Here you go!

Data attributes:

3.2.6.6 Embedding custom non-visible data with the data-* attributes

A custom data attribute is an attribute in no namespace whose name starts with the string "data-", has at least one character after the hyphen, is XML-compatible, and contains no ASCII upper alphas.

Custom elements:

Any namespace-less attribute that is relevant to the element's functioning, as determined by the element's author, may be specified on an autonomous custom element, so long as the attribute name is XML-compatible and contains no ASCII upper alphas.

The relevant part of the XML spec is the NameStartChar and NameChar patterns (note that * is 0x002A):

[4]   	NameStartChar	   ::=   	":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[4a]   	NameChar	   ::=   	NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[5]   	Name	   ::=   	NameStartChar (NameChar)*
[6]   	Names	   ::=   	Name (#x20 Name)*
[7]   	Nmtoken	   ::=   	(NameChar)+
[8]   	Nmtokens	   ::=   	Nmtoken (#x20 Nmtoken)*

As best as I can tell, the portion of the spec you linked applies to built-in attributes on built-in elements, but not to any custom stuff developers do.

[siefca]

Let me know, if this is still an issue. Some config setting for that could be added in such case.

[alexpetros]

I think I mostly agree with your interpretation of that spec, though it seems like that limitation only applies data-* attributes and the attributes you're describing do not start with data. Also, "custom elements" are different from "custom attributes on built-in elements" which is what we do, and it doesn't actually say that the broader definition of legal characters for attributes on elements are limited to the built-in ones, only that data-* attributes are limited by the XML spec.

I'm not opposed to adding an alternate wildcard character, but frankly, it seems like a templating engine should support the broadest possible attribute definition.

[spiffytech]

though it seems like that limitation only applies data-* attributes and the attributes you're describing do not start with data

Ah! Sorry, I should have clarified: the reason I brought up data- attributes and custom elements at all is because they're the only spec-valid way to use attributes that aren't enumerated in the HTML standard.

It seems like the reason the spec doesn't spell that out is because the philosophy is "any behavior that isn't in the standard is, by definition, non-standard.", and the data- prefix is the only place the spec explicitly allows extra attributes.

This rule is widely ignored because browsers make it work anyway and nobody cares. I don't care either, but it doesn't feel appropriate to me to argue to Maud that it should support syntax that exceeds either of the two mechanisms that enable custom attributes.

@1cg, would you mind weighing in on whether HTMX has a preference for which which of the two portions of the spec to honor?

---

I have found StackOverflow answer talking about this, and another claiming this is the case, and talking as if it's the only valid thing to do.

HTMX also supports the data- syntax, though it would be presumptive for me to say this is the motivation.

Also, here's the W3 validator saying a custom attribute isn't allowed because it isn't a "global attribute" (enumerated attributes + data-):

[alexpetros]

the reason I brought up data- attributes and custom elements at all is because they're the only spec-valid way to use attributes that aren't enumerated in the HTML standard.

Yup, my point was basically that I think the ship has sailed on this, hence data-* attributes being supported by htmx but not used as the default in any of the documentation. Perfectly reasonable for a template engine (or any project!) not to support that, but I don't think it's an unreasonable request of them either.

[alexpetros]

Alright got the thumbs up on this. @spiffytech are you interested in PRing the 5xx syntax?

[spiffytech]

Sure!

[siefca]

on it

[siefca]

Pull request: https://github.com/bigskysoftware/htmx/pull/1625

After changes will be merged the way to enable this functionality is going to be by adding:

<meta name="htmx-config" content='{"responseTargetPadX":"on"}'>

or by setting the htmx.config.responseTargetPadX to true in JS.

[spiffytech]

PR is up! #1629.