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.

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

Non-recognized root class aborts element processing #230

Closed
josineto opened this issue Feb 23, 2022 · 6 comments · Fixed by #231
Closed

Non-recognized root class aborts element processing #230

josineto opened this issue Feb 23, 2022 · 6 comments · Fixed by #231
Assignees
Labels
Milestone

Comments

@josineto
Copy link

Hi! I'm trying to implement microformats2 in my website, which uses Tailwind as CSS framework. In that framework, there are classes such as h-4, h-12 etc (specifying height CSS property on element).

Problem is: when I try to validate my h-card, the parsing of an element is aborted when those Tailwind classes are present. A small example follows:

<div class="h-card">
  <img class="u-photo w-32 h-32" alt="Jon Doe"
       src="/image.jpg"/>
</div>

The photo property is not recognized; but if one removes h-32 class, photo is recognized. I tried this example on two different pages: Barnaby Walters' and pin13.net, and the results are the same.

It seems php-mf2 (used on those 2 pages) aborts the processing of an element when it finds a non recognized root class (which, in this case, isn't even a microformats2 class). This is problematic, I think, since HTML classes are not used only by microformats2.

@sknebel
Copy link
Member

sknebel commented Feb 23, 2022

Good catch, I assume this is ironically a bug introduced with changes to improve compatibility with such utility classes.

Maintainers: so #128 / #102 is likely where to start looking.

@kevinmarks
Copy link
Member

kevinmarks commented Feb 23, 2022 via email

@barnabywalters
Copy link
Collaborator

barnabywalters commented Feb 23, 2022

In this specific case it should be possible to fix this issue, as the utility classes are not valid mf2 root classnames (i.e. they have a number in). Hopefully tailwind and similar libraries don’t introduce any classes which would clash with mf2 classnames (e.g. h-not-numbers) — I wonder if it’d be worth getting in contact with the maintainers and letting them know about the potential issue.

I’ll try to take a look at it over the next few days.

Aside: one could argue that using tailwind in this way is contrary to the ideal of semantic markup which microformats2 builds upon, and that using single-use classnames like this is barely any different from just using inline style elements. It’s not an argument I’m particularly interested in having, but IMO if you want to make use of tailwind’s utility classes like this, the better solution would be to use a CSS preprocessor to collect all the utility classes you want to apply to a particular element as mixins. E.g. if you’re using less, it could look something like this:

.profile-photo {
  .w-32();
  .h-32();
}
<div class="h-card">
  <img class="u-photo profile-photo" alt="Jon Doe"
       src="/image.jpg"/>
</div>

Exactly why even this solution would be preferable to just

.profile-photo { width: 32px; height: 32px; }

eludes me, but I’m not judging ;)

@barnabywalters
Copy link
Collaborator

I merged a fix, which will be in the next point release. Thanks for bringing this issue to our attention!

@kevinmarks
Copy link
Member

kevinmarks commented Feb 25, 2022 via email

@barnabywalters
Copy link
Collaborator

@kevinmarks could be, yes — for example, checking that

<div class="h-card">
  <img class="u-photo w-32 h-32" alt="Jon Doe"
       src="/image.jpg"/>
</div>

parses correctly to

{
  "items": [
    {
      "type": [
        "h-card"
      ],
      "properties": {
        "name": [
          "Jon Doe"
        ],
        "photo": [
          "/image.jpg"
        ]
      }
    }
  ],
  "rels": {},
  "rel-urls": {}
}

Additionally, tests which ensure valid parsing of property vendor prefixes (which may contain numbers) and property name tail strings (which may not) e.g. p-vendor123 is invalid, p-vendor123-my-weird-property is valid, p-vendor123-property-1 is not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants