The p- prefix for padding clashes with microformats properties

[shoelace-style]

The p- prefix for padding clashes with microformats properties

[claviska]

This might be a slightly unpopular decision, but I decided to use padding-* and margin-* instead of pad-* and mar-*

One, it's more clear what's actually being applied at a glance. And they're only a few chars more than mar- and pad- anyway.

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 😎

[kevinmarks]

Data attributes are explicitly specified to only be for the site itself, not for external reuse:

Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.

These attributes are not intended for use by software that is independent of the site that uses the attributes.

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.

[claviska]

Possibly. What exactly is it conflicting with?

[kevinmarks]

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).
Because of this convention, your padding prefix could cause spurious properties to show up in a parsed structure, and potentially confuse people reading source as whether padding or an mf2 property was intended.

More info on the prefixes here: http://microformats.org/wiki/microformats2-prefixes

[claviska]

Ugh, why would they use classes? They should have used data attributes (or even better, JSON-LD).

If this gets changed, I'd prefer pad-* like you suggested, but also mar-* for consistency. They're still short and relevant, albeit more verbose.

I'm gonna let the community vote on this with 👍 (change) and 👎 (no change) to determine if this gets changed.

[darksonic37]

Are microformats even relevant anymore?

[claviska]

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 😆

[claviska]

Fair points, can't argue with the standard. How does pad-* and mar-* sound?

The other option is to use a BS-style naming convention: p[dir]-[size] and m[dir]-[size] but that sorta deviates from our own convention. 😕

[kevinmarks]

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.

[UisgeBeatha436]

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:

{if isset($entry->summary)}
    <div class="alert alert-light margin-t-20">
        <strong>{eval var=$entry->summary}</strong>
    </div>
{/if}

Thanks!

[claviska]

All the classes are here:
https://github.com/claviska/shoelace-css/blob/master/source/css/utilities.css#L200

[UisgeBeatha436]

Thank you. The following line does work. Is it also possible to give a number of pixels as argument?
<div class="row mar-t-sm">

[claviska]

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

[UisgeBeatha436]

Thanks for explaining.