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.

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 ;)

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

@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.