locomotive-boilerplate icon indicating copy to clipboard operation
locomotive-boilerplate copied to clipboard

New Typography prefix and default styles

Open lucasvallenet opened this issue 2 years ago • 4 comments

The typography styles shouldn't be treated as a components or an object but as a different entity. I'm introducing a new concept of how to manage typography styles within a dedicated folder typography and using a new class prefix .t-*. Each different styles should be using this prefix and be located within this folder: .t-text, .t-wysiwyg, .t-link, ...

I'm also updating the heading class: .c-heading.-h1 > .t-h1 This will lighten the html markup and simplify the sass @extends. The heading font sizes are stored within a css custom property in elements/_page.scss to allow responsive sizes and the use of a heading size for an other component.

I added default styles for wysiwyg fields with margins, title and list styles

lucasvallenet avatar May 02 '22 09:05 lucasvallenet

Hrm. I don't know what the others think but so far we've been following Harry Robert's CSS namespaces wherein the .t- prefix is reserved for "themes". Maybe we want to move away from that, if so, we should define this in the documentation section.

mcaskill avatar May 02 '22 13:05 mcaskill

Why do you think we shouldn't treat typography styles as a component or an object? I'm not against the idea, but I'm not sure to see the benefits. Could you explain why such a change should happen?

Regarding the themes thing, as far as I recall we never really used that concept in a project - at least since I'm at Locomotive - so it wouldn't bother me to hijack that prefix. @mcaskill is right about defining it in the doc though.

Great idea to use the CSS variables for the heading font sizes 👍

Thanks for the PR @lucasvallenet 🙏

Jerek0 avatar May 02 '22 20:05 Jerek0

@mcaskill I don't recall using a theme in any website, it's not really common so we could easily find a workaround if necessary.

@Jerek0 In my opinion, a component is a complexe block that can have different children blocks depending on use case, and can also contain objects as children (a c-card_tag | o-tag withing a c-card for example). An object is more straight forward and should always have the same children html markup, it could be used for an icon or a loader for example. An object shouldn't contain another object, even less a component. Based on that, the text rules could be an object, but they are usually single elements selectors. It could be treated as a utility class, but I think that it would make sense to have a dedicated prefix for these typographic rules.

Use cases:

<span class="o-tag">
    <span class="o-tag_name | t-h4"></span>
</span>

It's more readable and it would also reduce the use of @extendswithin the sass to avoid duplicated styles within the css and more consistency on the html markup.

That's just an idea and a methodology I use to have, I'm really open for discussion or to drop the pull request no harm done :)

lucasvallenet avatar May 03 '22 08:05 lucasvallenet

Outcome from meeting on 2022-10-05

  • Status: Changes barring approval
  • Revert .t-wysiwyg back to .u-wysiwyg.
  • Exclude .t-link.
  • Approved .t-*.

mcaskill avatar Oct 05 '22 14:10 mcaskill