Allow numbers in vendor prefixes

[gRegorLove]

Since 2016-02-28 the parsing spec has:

The "*" for root (and property) class names consists only of lowercase a-z and '-' characters.

Recently @aaronpk discovered this means his vendor prefix p3k- is no longer parsed.

As a conservative change to the specification, recommend changing this to:

The "*" for root (and property) class names consists only of lowercase a-z and '-' characters.

• Exception: if the class name has a vendor prefix, the vendor prefix component consists of only lowercase a-z and 0-9

[Zegnat]

I am 👍 on allowing digits.

I do wonder about including vendor prefixes, as there is no strict rule for recognising them as I understand it? In p3k-drank the p3k is a vendor prefix. But in in-reply-to the in isn’t. CSS doesn’t have this problem as all vendor prefixed properties start with an - to set them apart.

Without a way to detect “if the class name has a vendor prefix”, that if clause doesn’t make sense to me.

Maybe instead something like this?

The "*" for root (and property) class names consists only of lowercase a-z and '-' characters.

• Exception: to support more diverse vendor prefixes, if the class name includes any '-' characters, the substring before the first '-' characters may also contain 0-9.

[kartikprabhu]

The bleeding edge experimental mf2py now implements the rule proposed by @Zegnat

[tantek]

It makes sense to special case the [a-z] microformats2 class name segment requirement to allow numbers in vendor prefixes, since there are existing vendor/product names with numbers, e.g. (made up examples with actual (past) vendor/product names)

h-6prime-rev
p-p3k-special
u-revision3-source

(Originally published at: http://tantek.com/2018/079/t4/)

[kartikprabhu]

+1
cc: @tantek

[Zegnat]

Spec has been updated to allow an optional vendor prefix with numbers.

[gRegorLove]

🎉