UI Element Attribute about html HOT 5 OPEN

First, I love the thought and care that has been put into writing this proposal, props for that!

However, I'm missing a solid value proposition for either authors, spec editors, or implementors that would make the effort to add or use this worth it. Authors have had data- attributes for years that they could have used as style hooks — yet they prefer to use classes. Why do you think that's the case? My own hypotheses about this are here but I think the topic would benefit from more exploration.
However, I would be very surprised if saving them two characters makes that big of a difference.

Perhaps something like this could work if it also comes with conveniences to target these in selectors, or get their values in CSS. But still, why invent a new thing instead of paving the cowpaths and facilitating this for class names?

FWIW, there are also proposals to allow any hyphen-containing attribute, which would trivially allow ui-*as well, but as an authorland convention.

from html.

(random passerby comment) This feels like a self-inflicted problem of trying to bring CSS back into HTML markup. In any case, some of those things could be fixed with full support of attr():

[data-ui-bgcolor] {
  background-color: attr(data-ui-bgcolor color, var(--ui-bgcolor));
}

// Avoid doing that, seriously…

As for things like “ui-padding="top:0 bottom:2"”, at this point it's time to just use style="…", IMO.

from html.

FYI there's a related proposal by @LeaVerou in w3c/csswg-drafts#10001, although I'm not certain it'd solve all of your use cases.

from html.

@Malvoz and @LeaVerou thank you for your feedback. I have read through the linked proposals / comments. There are clearly still a lot of wrinkles in the proposal to iron out.

I do like the idea that any hyphen-containing attribute would be allowed, which immediately solves this proposal. It also aligns well with hyphenated, custom HTML elements.

During my experimentations with this idea, one of the value props I found from a developer perspective, was the potential for IDEs to auto-complete ui-* attributes; for example, how might we correlate this with Bootstrap classes as they exist today?

The following excerpt comes from Bootstrap:

Notation

Spacing utilities that apply to all breakpoints, from xs to xxl, have no breakpoint abbreviation in them. This is because those classes are applied from min-width: 0 and up, and thus are not bound by a media query. The remaining breakpoints, however, do include a breakpoint abbreviation.

The classes are named using the format {property}{sides}-{size} for xs and {property}{sides}-{breakpoint}-{size} for sm, md, lg, xl, and xxl.

Where property is one of:

• m - for classes that set margin
• p - for classes that set padding

Where sides is one of:

• t - for classes that set margin-top or padding-top
• b - for classes that set margin-bottom or padding-bottom
• s - (start) for classes that set margin-left or padding-left in LTR, margin-right or padding-right in RTL
• e - (end) for classes that set margin-right or padding-right in LTR, margin-left or padding-left in RTL
• x - for classes that set both *-left and *-right
• y - for classes that set both *-top and *-bottom
• blank - for classes that set a margin or padding on all 4 sides of the element

Where size is one of:

• 0 - for classes that eliminate the margin or padding by setting it to 0
• 1 - (by default) for classes that set the margin or padding to $spacer * .25
• 2 - (by default) for classes that set the margin or padding to $spacer * .5
• 3 - (by default) for classes that set the margin or padding to $spacer
• 4 - (by default) for classes that set the margin or padding to $spacer * 1.5
• 5 - (by default) for classes that set the margin or padding to $spacer * 3
• auto - for classes that set the margin to auto

(You can add more sizes by adding entries to the $spacers Sass map variable.)

Now, how does this translate to ui-*? There could be many flavours of this. (I prefer clarity over brevity, even at the expense of a few bytes here and there, however, this is ultimately down to the developer/designer of the design system). Let's take a subset of Bootstrap's classes, specifically padding, and make it work with ui-* attributes:

[ui-padding*="0"] {
  padding: 0;
}

[ui-padding*="1"] {
  padding: 10px;
}

[ui-padding*="2"] {
  padding: 20px;
}

[ui-padding*="bottom:0"] {
  padding-bottom: 0;
}

[ui-padding*="bottom:1"] {
  padding-bottom: 10px;
}

[ui-padding*="bottom:2"] {
  padding-bottom: 20px;
}

[ui-padding*="top:0"] {
  padding-top: 0;
}

[ui-padding*="top:1"] {
  padding-top: 10px;
}

[ui-padding*="top:2"] {
  padding-top: 20px;
}

/* utils */
[ui-bgcolor="red"] {
  background-color: red;
}

[ui-bgcolor="blue"] {
  background-color: blue;
}

We can then style our document like so:

<div ui-bgcolor="red" 
     ui-padding="2">
  padding: all=20px
</div>
<div ui-bgcolor="blue" 
     ui-padding="top:0 bottom:2">
  padding: top=10px, bottom=20px
</div>
<div ui-bgcolor="red" 
     ui-padding="2 bottom:1">
  padding: all=20px, bottom=10px
</div>

JSFiddle here if you want to play with it

At this point, you may be wondering "okay, so where does IDE auto-completion fit in?"

Currently, if you type in class="... your IDE will probably just display every class that it's aware of, so yes, you get auto-completion already, but it's everything and the kitchen sink thrown into one huge list.

The advantage of ui-* is that the moment you type in ui- you should be greeted with an auto-complete list of all ui-* attributes, but not necessarily their modifiers. When you select one, like ui-padding="... for example, then you are greeted with only the permitted modifiers, such as 0, bottom:1, or top:2.

Now, whilst writing this I've become very aware that the WHATWG doesn't/shouldn't care about how IDE vendors implement auto-completion...in all honesty, the argument does feel a bit "tail wagging the dog".

Perhaps a better way of looking at this particular value prop is to go back to "everything and the kitchen sink thrown into one huge list". class="... does not discriminate classes with regards to their purpose; i.e. m-0 (margin), p-5 (padding), card-header (higher level component styling), d-flex (flex layout), etc.

In contrast ui-* does provide that distinction, because it allows for clear separation of things like margin, padding, layout, and their allowed modifiers.

One final criticism before I sign out; I mentioned above "I prefer clarity over brevity, even at the expense of a few bytes here and there"...

This is a lot longer...

<div ui-padding="top:2 bottom:1" ui-margin="0 start:4">

...than this...

<div class="pt-2 pb-1 m-0 ms-4">

In this case, are front-end engineers going to equate clarity with verbosity, leading to markup that is bloated with ui-* attributes, and therefore favour the brevity they are used to when using classes?

In summary, I think that allowing all hyphenated attributes is probably the best approach and clearly has many use-cases, some of which are in existence already. I could envisage a future where design systems are partitioned by their prefix; i.e. rather than ui-*, Bootstrap might adopt bs-*, and Tailwind tw-*, allowing them to coexist without trampling over one another.

from html.

@flashymittens Yes, the more I think about it, this approach for utility classes probably is a worse idea than using classes. Even for more complex scenarios, it's not great. I think it has some use-cases, but probably not enough to warrant the "make ui-* an open attr." idea.

from html.