Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ignore Tailwind's h- prefixes #59

Open
tommorris opened this issue Nov 14, 2022 · 7 comments
Open

Ignore Tailwind's h- prefixes #59

tommorris opened this issue Nov 14, 2022 · 7 comments

Comments

@tommorris
Copy link

tommorris commented Nov 14, 2022 •
edited
Loading

Copied from mf2py issue 170.

Tailwind is a CSS framework that uses h- prefixed values for styling, specifically height.

Therefore, the following example won't parse well in any correct implementation of microformats2.

<html class="h-full">
...
<span class="h-card p-name">Johnny Appleseed</div>
...
</html>

The options for dealing with this seem to be:

  1. make Tailwind go away permanently (honestly, I'm not a fan, but each to their own)
  2. tell HTML authors to not use Tailwind with height properties if they're also using microformats2
  3. ignore Tailwind's height properties (by default, ideally there should always be a way to get strict parsing) - the parsing spec apparently already excludes h-[0-9]* but we could also the other h- properties used by Tailwind

Given Tailwind doesn't seem to be going away, and given priority of constituencies ("consider users over authors over implementors over specifiers over theoretical purity"), the third option may be the least bad, even if it does make parsing marginally more complicated.
@jalcine
Copy link

jalcine commented Nov 14, 2022

If we go with the third option, I'd be slightly pressing the suggestion to parsers to allow for an option to restrict any of the h- values to be ones that can represent known values, namely those with defined specifications

This could be an evolving list, which is already done with Micropub extensions and new specifications of objects themselves. This also could break backcompat with those parsers that fallback to being a h-entry or the like, but I see that as very unlikely.

(Originally published at: https://jacky.wtf/2022/11/9QFM)
@barnabywalters
Copy link

barnabywalters commented Nov 15, 2022 •
edited
Loading

As the list of tailwind-specific false-positive root classnames is short and knowable, it’s possible to take parsed mf2 output and restructure it as if the false positives had not been there. This is then available as a customisable post-processing step which consumers can choose to do, or not. There’s a draft implementation here https://github.com/barnabywalters/php-mf-cleaner/blob/main/src/functions.php#L629 (relevant test here for reference)
@capjamesg
Copy link
Member

@barnabywalters Thank you for sharing your draft implementation!

I would be in favour of collating a whitelist of all accepted microformats values, rather than ignoring tailwind-specific values. If tailwind adds new attributes, we will need to release new versions of all parsers, which is an external decision made by the tailwind team. I don't think we should be reactive to external tools that use the h-* pattern.
@gRegorLove
Copy link
Member

The generic parsing of vocabularies is a key feature of microformats2 and improvement from mf1, so I don't think an allowlist can be part of the core parsers.
@capjamesg
Copy link
Member

capjamesg commented Jun 27, 2023 •
edited
Loading

@gRegorLove Thanks for sharing! Do you think we should take any action on this at the parser spec level?
@gRegorLove
Copy link
Member

I don't see an immediately obvious way to. Most of the Tailwind height selectors have numbers (.h-0) so will be ignored during parsing:

The "*" for root (and property) class names consists of an optional vendor prefix (series of 1+ number or lowercase a-z characters i.e. [0-9a-z]+, followed by '-'), then one or more '-' separated lowercase a-z words.

It's those handful like .h-full .h-auto .h-min .h-max that will be parsed and I don't see an easy way around that without going down the route of allowlists, unfortunately. It does feel like more of mf2 utility add-on like Barnaby's implementation.
@sknebel
Copy link
Member

sknebel commented Jun 29, 2023

It'd be interesting to experiment with user-provided filtering inside the parser (in many ways easier than trying to save it in post-processing), but I'm wary of adding this to the spec without extensive experimentation.
@willnorris willnorris mentioned this issue Oct 20, 2023
Open
@angelogladding angelogladding mentioned this issue Nov 12, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
6 participants
@tommorris @jalcine @barnabywalters @sknebel @gRegorLove @capjamesg