How should we style variants for new v2 styles/components

[gfellerph]

There are multiple ways native html elements can be styled.

1. Classes

1.1. <p class="size-large"></p>
1.2. <p class="size:large"></p>
1.3. <p class="large"></p>

+ We're already doing that
+ Maximum compatibility
- Not namespaced, could clash with project class names (or third party class names like tailwind)
- Possible naming clashes or different meanings based on which element it's used on

2. Prefixed attributes

<p post-size="large"></p>

+ No naming clashes when using a dash in attribute names (as long as we're not using the aria- prefix)
+ Namespaced, so projects can use whatever class names they prefer
+ More speaking than classes
- Can't be backwards compatible everywhere if we don't keep the previous class styling as well
- Not the most concise

3. Non prefixed attributes

<p size="large"></p>

+ Concise
- Possible clash with native attributes (but with foreseeable consequences, known native attribute names can be avoided)

4. Non prefixed direct attributes

<p large></p>

+ Most concise
- Possible naming clashes

[oliverschuerch]

Something like _size="large" would be possible as well, we just need to check, which chars can be used within a attribute name.

[gfellerph]

whatwg/html#2271

[oliverschuerch]

Would you like to refer to a specific post or should we all read the entire thread? 😄
Considering the two last posts, something like p-size="large" should be fine.
And also the w3c validator validated _size="large" as valid html, while -size="large", $size="large" was of course validated as wrong.

Independent form how the attribute could look like: Before we start doing something like this, we need to also make sure, the new CMS can handle it.

[gfellerph]

The first and last posts are interesting. The new CMS is headless, so it does not care about markup or selectors. Leading with a special char seems strange, I would imagine it raises a lot of questions.

[alizedebray]

On second thought, I have some doubts about styling through attribute selectors.

Personally, I find it less readable and would prefer a more concise approach for both writing the styles and using them in projects.
For example, it would prevent us from taking advantage of basic Sass nesting features, such as:

.size {
  &-big {/* some styles */}
  &-small {/* other styles */}
}

More importantly, I believe this approach wouldn't be fully compatible with IDE auto-completion, which reduces the ease of use for our styles.

[gfellerph]

While this is a neat feature, one downside to this is, that when you try to do changes to this class and you search for it, you're not gonna get any results for .size-big, so you'd have to know where it's specified.

[alizedebray]

That's right.

[alizedebray]

I’m also curious about how breakpoints would work with attributes.
More generally, I believe it's important to have strong reasons before moving away from established standards. Have we seen enough name conflicts to justify doing things differently from all other libraries?

[alizedebray]

Regarding Approach 1.2, I’d love to use it for pseudo-class utilities similar to those in Tailwind!

[gfellerph]

Decision: go with 1.1