-
-
Notifications
You must be signed in to change notification settings - Fork 766
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
The p- prefix for padding clashes with microformats properties #14
Comments
Possibly. What exactly is it conflicting with? |
Microformats uses short prefixes on class names to indicate that they should be parsed as data. A prefix of h- defines a structure, and within that other prefixes define field names. The p- prefix is used for plaintext properties (the most common case). More info on the prefixes here: http://microformats.org/wiki/microformats2-prefixes |
Ugh, why would they use classes? They should have used data attributes (or even better, JSON-LD). If this gets changed, I'd prefer I'm gonna let the community vote on this with 👍 (change) and 👎 (no change) to determine if this gets changed. |
Are microformats even relevant anymore? |
That's sorta what I'm wondering, plus I feel it's a poor implementation. I used JSON-LD for Postleaf and everything gets parsed fine. I get that it's supposed to be "easier" for humans to write (is it though?) but it really clutters up markup and I think we have better alternatives nowadays. Of course, I'm not the only one using the Internet so I'll let others provide feedback 😆 |
Data attributes are explicitly specified to only be for the site itself, not for external reuse:
They are also meant for non-visible data. Using microformats means you can use the text shown on the page as data, rather than a parallel version that may go out of date. This DRY issue is the problem with JSON-LD too, as well as its complexity. I wrote about this with examples. Microformats are in active use by the indieweb protocols including webmention and micropub. I've written about possible collisions with u- prefixes before too. Microformats 2 are explictly designed to minimise clutter, and are terser than alternatives that require extra versions of the text like JSON-LD and OGP. |
Fair points, can't argue with the standard. How does The other option is to use a BS-style naming convention: |
I think pad-* and mar-* are a good compromise between terseness and clarity. Certainly much better than the overloading of u- in the article I linked. |
This might be a slightly unpopular decision, but I decided to use One, it's more clear what's actually being applied at a glance. And they're only a few chars more than Two, it's more consistent with the rest of the utility classes: .float-left {}
.width-50 {}
.height-100 {}
.text-center {}
.padding-y-big {}
.margin-x-none {} I don't think the extra chars will be a problem since in all likeliness you'll only ever apply one or two to the same element: <div class="padding-y-big margin-x-small">
...
</div> And at least now we don't have microformat collisions 😎 |
A little bit off topic, could you please clarify what's the correct syntax to use the margin and / or padding? Based on this post I did some experiment, however neither mar-t-20 or margin-t-20 is working:
Thanks! |
All the classes are here: |
Thank you. The following line does work. Is it also possible to give a number of pixels as argument? |
No — the spacing utilities are designed to be relative to the spacing variables. If you need exact pixels, the recommended approach is a custom class (or an online style if that’s your preference). |
Thanks for explaining. |
Could you use pad- instead? It's almost as short, and clearer.
The text was updated successfully, but these errors were encountered: