ocsigen / tyxml

Build valid HTML and SVG documents
https://ocsigen.org/tyxml/
Other
163 stars 57 forks source link

Provide escape hatch for non-standard HTML attributes #295

Closed cemerick closed 2 years ago

cemerick commented 2 years ago

Many Javascript libraries/frameworks depend upon HTML markup that includes non-standard attributes. Examples I've come across the past couple of days include:

Of course, tyxml rejects these attributes, e.g. this hello-world example from htmx:

<button hx-post="/clicked" hx-swap="outerHTML">
  Click Me
</button>

It is desirable to be able to use tyxml and benefit from the things it does well, while still being able to produce markup as required by libraries like these.

Conceptually, these custom attributes are basically just data-* attributes, and so there's no need for tyxml to do any kind of validation or checking on their values. All that is required is for tyxml to pass them along unharmed.

(The notion of configuring tyxml ppx and jsx-ppx (via dune ppx arguments) with a set of allowable additional attribute names was suggested in discord and discarded.)

cemerick commented 2 years ago

Another idea would be to use e.g. an underscore prefix as an escape hatch for arbitrary attributes, not unlike the treatment of data- (or data_ in jsx) prefixes. Then the example above would be constructed via

<button _hx-post="/clicked" _hx-swap="outerHTML">
  Click Me
</button>
cemerick commented 2 years ago

I was eager to push along using htmx with my existing tyxml-based rendering setups, thus the quick PR. I understand that the approach suggested above wasn't agreed to, but it was easy enough and a pretty tiny addition that can be stacked on top of HEAD as need be (just in case it is decided that supporting non-standard attributes is a non-goal after all). :wave:

Drup commented 2 years ago

I agree it's a decent idea. The syntactic marker is rather reasonable.

Another option, would be to have something of the form [@@@tyxml.foreign_prefix "hx"] at the top of the document, and then all things that start with hx- are treated as data-. Would you prefer that, or just the unstructured version with a starting underscore ?

cemerick commented 2 years ago

I don't personally find the floating attribute option compelling; the underscore prefix happens to rhyme nicely IMO with the escape hatch for attributes with reserved keyword names like type and class. Doing more than that feels unnecessary?

FWIW, my plan was to tweak the PR to address the minor critiques you provided in https://github.com/ocsigen/tyxml/pull/296#issuecomment-1032834491 (once I got back to front-end-land, sometime this month hopefully). If you'd prefer to move forward with a floating attribute approach, then I can do that, but it will probably take a little longer since it is a distinct approach.

Drup commented 2 years ago

Well, _type is of a pretty different nature (it's a work around caml's reserved keywords) so the analogy doesn't hold very well.

Maybe we should have another syntactic marker.

cemerick commented 2 years ago

Well, _type is of a pretty different nature (it's a work around caml's reserved keywords) so the analogy doesn't hold very well.

Sure, that's why I said it rhymed; in both cases, we're saying something that the underlying language(s) do not allow in their "external" form.

Maybe we should have another syntactic marker.

I'd be happy with any alternative you'd prefer. The syntactic window is pretty narrow given what refmt will allow IIRC.

ethanthoma commented 4 months ago

Hello, I am trying to use hyperscript with tyxml. My issue is that there is no support for alternatives like hs or data-hs in hyperscript (which I created an issue for here on their GitHub). However, I cannot use _ as __ becomes -. Is there no escape hatch for this case? Thanks.

cemerick commented 4 months ago

@ethanthoma Sure, I use hyperscript, too. Replied on the issue you created on the hyperscript repo, here.

Drup commented 4 months ago

thanks @cemerick.

I must admit not being fully convinced by the whole thing, I hoped we had a more straightforward general solution ...