2 ms·

Practically, you are allowed to do so. I understand both sides of the argument, so I set it up so you could choose which one you preferred. I don't see a reas

Practically, you are allowed to do so. I understand both sides of the argument, so I set it up so you could choose which one you preferred. I don't see a reason to force my preferences on anyone.

kzrdude 6y ago
Using data- which is the niche made for this in the standard, seems to be the solution that's more likely to still work 15 years down the line.
- recursivedoubts 6y ago
  fine by me
- wongarsu 6y ago
  The only real practical concern is that if you don't use data- you might use an attribute that will become meaningful to future browsers. But what are the chances of html gaining an attribute that starts with hx-?
  - err4nt 6y ago
    When you camp on the platform namespace it ties the hands of standards bodies - we will not get <modal> in HTML for real because too many people already went ahead and did it. Same for <accordion>, etc. Look up 'Smooshgate' for a similar example in JavaScript. Our workflows should have us practice writing _valid_ code, which our tools can then take and transform into other _valid_ code. Any workflow where the humans practice doing the _invalid_ thing so the tool can magically fix it later is a bad idea IMO. Practice writing good code and use tools to make it even better!
clarkevans 6y ago
Not only do browser manufacturers disregard that request, I observe that IETF has gone back on their idea of prefixing application protocols with 'X-`. See RFC 6648: "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols" https://tools.ietf.org/html/rfc6648 https://tools.ietf.org/html/rfc6648 If the HTML standard changes so much as to collide with 'hx-` then application developers using HTMX will likely have bigger compatibility problems to deal with. Besides, regex replacement on your HTML templates isn't hard.

2 ms·

Practically, you are allowed to do so. I understand both sides of the argument, so I set it up so you could choose which one you preferred. I don't see a reas

by recursivedoubts 6y ago

Practically, you are allowed to do so. I understand both sides of the argument, so I set it up so you could choose which one you preferred. I don't see a reason to force my preferences on anyone.

kzrdude 6y ago
Using data- which is the niche made for this in the standard, seems to be the solution that's more likely to still work 15 years down the line.
- recursivedoubts 6y ago
  fine by me
- wongarsu 6y ago
  The only real practical concern is that if you don't use data- you might use an attribute that will become meaningful to future browsers. But what are the chances of html gaining an attribute that starts with hx-?
  - err4nt 6y ago
    When you camp on the platform namespace it ties the hands of standards bodies - we will not get <modal> in HTML for real because too many people already went ahead and did it. Same for <accordion>, etc. Look up 'Smooshgate' for a similar example in JavaScript. Our workflows should have us practice writing _valid_ code, which our tools can then take and transform into other _valid_ code. Any workflow where the humans practice doing the _invalid_ thing so the tool can magically fix it later is a bad idea IMO. Practice writing good code and use tools to make it even better!
clarkevans 6y ago
Not only do browser manufacturers disregard that request, I observe that IETF has gone back on their idea of prefixing application protocols with 'X-`. See RFC 6648: "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols" https://tools.ietf.org/html/rfc6648 https://tools.ietf.org/html/rfc6648 If the HTML standard changes so much as to collide with 'hx-` then application developers using HTMX will likely have bigger compatibility problems to deal with. Besides, regex replacement on your HTML templates isn't hard.