Htmx 1.0.0 Release

Re:Htmx 1.0.0 Release by err4nt on Friday November 27, 2020 @07:20PM (#25233872)

> It's worth mentioning that, if you prefer, you can use the `data-` prefix when using htmx

I don't know why people who make frameworks either prefer invalid HTML, or if they do allow people to write valid HTML they seem to show the invalid code in the docs

You are not allowed to invent any old attributes you want and add them to any element and have it be valid HTML, but you can invent any attribute you want so long as it begins with `data-`.

https://html.spec.whatwg.org/multipage/dom.html#embedding-cu...

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by recursivedoubts on Friday November 27, 2020 @07:36PM (#25233969)

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.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by clarkevans on Friday November 27, 2020 @09:13PM (#25234553)

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

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.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by kzrdude on Friday November 27, 2020 @08:03PM (#25234161)

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.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by wongarsu on Friday November 27, 2020 @08:50PM (#25234418)

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-?

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by err4nt on Monday November 30, 2020 @08:04PM (#25261060)

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!

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by recursivedoubts on Friday November 27, 2020 @08:05PM (#25234178)

fine by me

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by tmpfs on Friday November 27, 2020 @07:31PM (#25233942)

I agree, the `data-` variant should be enforced so that the markup is always valid.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by oconnore on Friday November 27, 2020 @08:22PM (#25234270)

There seems to be a bit of irony citing whatwg in your attempt at shaming here —- the standard that was created to be a living document tracking what web developers and browser creators were implementing in the real world.

I’m not sure there is a good reason to require web authors to type an extra 5 character prefix every time they want to attach data to an element. This is supported by the fact that browsers can figure this out.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by err4nt on Monday November 30, 2020 @08:07PM (#25261074)

Those five letters are the difference between safe code and unsafe code. If you've used data-* you can rest assured your attributes will always be author-defined and not interfere with any future real attributes defined by HTML, whatever those may be.

But if you invent and use invalid attributes, any browser could do something with that, any day, for any reason, and it wouldn't be a bug - you're the one that would have chosen to build on top of undocumented and non-standard behaviour. Does that sound like a reasonable approach to you when the safe and future-proof approach is so clearly marked and cheap and easy to do?

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by satvikpendem on Friday November 27, 2020 @07:39PM (#25233985)

But prepending with data can be annoying both from a "quickly reading" perspective, and an aesthetic one. The goal isn't to provide valid HTML necessarily but just allow the library to parse it correctly.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by err4nt on Friday December 04, 2020 @06:01PM (#25309479)

How does writing invalid HTML help toward the goal of correct parsing exactly? To me it would seem to open up an infinite variety of edge cases that simply don't need to exist if you're working with 100% standard code.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by satvikpendem on Monday December 07, 2020 @09:06PM (#25340754)

That assumes that HTMX wants to be fully compliant HTML code, which, by the author's optionality on data- vs non data- attributes, does not seem to be the case. This then is basically like JSX, it looks like HTML but isn't really, just syntactic sugar over structure, presentation, and logic operations.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by tarsinge on Saturday November 28, 2020 @03:36AM (#25236246)

Custom attributes are used since many years now and work on every browsers. Maybe the spec should be updated to reflect the usage.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by err4nt on Friday December 04, 2020 @06:00PM (#25309470)

Custom attributes (without data-*) are invalid HTML unless you're using them on a custom HTML element. If you're defining a custom element, you're responsible for defining what its attributes mean - outside of that, no they aren't allowed and yes they are unsafe to use, and restrict the standards bodies from being able to move forward freely without risking breaking the web because of invalid code in the wild.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by ezequiel-garzon on Friday November 27, 2020 @07:41PM (#25234003)

I don't know why people who make frameworks either prefer invalid HTML

I’m guessing people do this to make it less likely to have a name conflict with a custom attribute used by another library.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by err4nt on Monday November 30, 2020 @08:10PM (#25261101)

The HTML spec mentions this:

    JavaScript libraries may use the custom data attributes, as they are considered to be part of the page on which they are used. Authors of libraries that are reused by many authors are encouraged to include their name in the attribute names, to reduce the risk of clashes. Where it makes sense, library authors are also encouraged to make the exact name used in the attribute names customizable, so that libraries whose authors unknowingly picked the same name can be used on the same page, and so that multiple versions of a particular library can be used on the same page even when those versions are not mutually compatible.

This is saying that if you have `data-thing`, then putting your own name in there is better, like `data-mylib-thing` to tell it apart from `data-yourlib-thing`, but the ultimate in flexibility and compatibility is if the end-user of your library can configure this part so they can safely tell `data-yourlib-v3-thing` apart from `data-yourlib-v4-thing` etc.

[ Parent | on HN ]

Re:Htmx 1.0.0 Release by aecay on Sunday November 29, 2020 @06:07PM (#25248943)

> If you want to stop polling from a server response you can respond with the HTTP response code 286 and the element will cancel the polling.

Oh wow, it gets a lot worse...

[ Parent | on HN ]