Closed jalcine closed 5 years ago
A fixed list of known h-
types and passively allowin h-x
properties could work.
Hm yeah, I see the problem. I will have a look at this tonight, in Europe the work day just started :-)
There's specific rules what names are allowed to look like (quoted from end of http://microformats.org/wiki/microformats2-parsing#parse_an_element_for_class_microformats):
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.
Please do not hardcode a list of supported types or property names.
Ooh didn't know that - thanks for that update @sknebel!
Well, that specification would still parse h-100
and the likes as microformat information; which it isn't.
So it'd be up to the user to ignore these things, it seems.
Ah okay so from IRC: https://chat.indieweb.org/dev/2019-01-03#t1546553927565100
There's a bit of clarification: should be a test something like h(<vendor-prefix>)-(type)
such that vendor prefix can be an alphanumeric string but the type can only be letters
I use a CSS framework that makes use of the
h-
prefix for heights. Currently, this is breaking my use of this library when attempting to look forh-entry
orh-cite
information on a page.The output (in JSON):