Skip to content
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

Closed
kevinmarks opened this issue Aug 1, 2017 · 14 comments
Closed

The p- prefix for padding clashes with microformats properties #14

kevinmarks opened this issue Aug 1, 2017 · 14 comments
Labels
question General questions about the project.

Comments

@kevinmarks
Copy link

Could you use pad- instead? It's almost as short, and clearer.

@claviska
Copy link
Member

claviska commented Aug 1, 2017

Possibly. What exactly is it conflicting with?

@claviska claviska added the question General questions about the project. label Aug 1, 2017
@kevinmarks
Copy link
Author

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
Copy link
Member

claviska commented Aug 1, 2017

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.

@pkill37
Copy link

pkill37 commented Aug 1, 2017

Are microformats even relevant anymore?

@claviska
Copy link
Member

claviska commented Aug 1, 2017

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 😆

@kevinmarks
Copy link
Author

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
Copy link
Member

claviska commented Aug 1, 2017

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
Copy link
Author

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.

@claviska
Copy link
Member

claviska commented Aug 1, 2017

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 😎

@UisgeBeatha436
Copy link

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
Copy link
Member

@UisgeBeatha436
Copy link

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
Copy link
Member

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
Copy link

Thanks for explaining.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question General questions about the project.
Projects
None yet
Development

No branches or pull requests

4 participants