Add block list for known conflicting root class names

[angelogladding]

Closes #170.

I'm seeing h-px, h-auto, h-full, h-screen, h-min, h-max, h-fit in the Tailwind docs. None of these seem to be good candidates for root class names so there shouldn't be an issue of vocabulary gatekeeping.

The general feeling I get from microformats/microformats2-parsing#59 is that parser experimentation would be a good path forward. This change can easily be reverted at a later date.

In the meantime we have a fix for the current landscape and a framework for solving similar issues moving forward.

[sknebel]

This should be behind a flag IMHO.

[angelogladding]

Or should there be a flag to turn it off? It'll do only good right now and if someone somewhere wants to experiment with e.g. h-screen they can use the flag. Consumers of their h-screen will have to explicitly use the flag as well but their consumption of a new microformat would probably already need other manual steps to support.

[sknebel]

I strongly believe default behavior of microformats parsers should be as similar as possible. Parser bugs already regularly cause confusion when someone checks their pages with one parser and then is confused why an application using a different parser does not understand it correctly.

[gRegorLove]

Agreed, I think it should be behind a flag and (probably) configurable, like an option to initialize the parser with a custom list of class names to block.

This would allow a specialized app like indiewebify.me to choose to ignore any conflicting classes that arise over time, without requiring an update to the list of static class names in the parser.

[angelogladding]

@sknebel @gRegorLove what's a good flag? leave the tailwind-specific classes out of the library entirely and just let the user bring their own block list?

>>> parser(url="example.com", block_roots={
...     "h-px", "h-auto", "h-full", "h-screen", "h-min", "h-max", "h-fit"
... })

[gRegorLove]

If it's behind a flag I don't have a strong opinion about including Tailwind classes in the package. If you do, maybe it could have three states:

• default (no blocked classes)
• block roots enabled (packaged list of classes is blocked)
• block roots enabled + custom list of classes provided (only the custom list of classes is blocked)

[sknebel]

One way might be to have the list be user-provided, but have a ready-to-use list as a constant available. filter_roots=mf2py.ROOT_FILTER_PRESET_TAILWIND ?

[angelogladding]

It's tempting to try to leverage this function https://github.com/microformats/mf2py/blob/main/mf2py/mf2_classes.py#L9 but it wasn't the right place to reject items.

As implemented, this method will only work on root (h-) classes. This works for the current Tailwind use case but won't extend to future elemental (u-, dt-, p-, e-) conflicts.

[tantek]

This seems worth experimenting with a flag as commenters have said. LGTM.