[Meta][Editorial] Define bags of CSS properties to be referenced by allowlists

[LeaVerou]

We are starting to have a fair number of CSS constructs (mostly pseudo-elements, but also pseudo-classes and at-rules) that accept restricted sets of properties, defined ad hoc:

Name	Type	Allowlist	Defined in
Link history pseudo-classes (:link and :visited)	pseudo-class	Up to the UA	selectors
::first-line	pseudo-element	defined inline	css-pseudo
First letter pseudo-elements (::first-letter, ::prefix, ::postfix)	pseudo-element	defined inline	css-pseudo
Highlight pseudo-elements (::selection, ::target-text, ::grammar-error, ::spelling-error)	pseudo-element	defined inline	css-pseudo
::highlight()	pseudo-element	Same as highlight pseudo-elements	css-pseudo
::marker	pseudo-element	defined inline	css-lists
::placeholder	pseudo-element	same as ::first-line	css-pseudo
::tooltip	pseudo-element	Not yet defined	N/A
::cue	pseudo-element	defined inline	WebVTT
@try	at-rule	accepts inset, margin, border, padding, sizing, box alignment, properties	css-anchor-position
@page	at-rule	page properties and a margin rule accepts page margin properties. Both bags contain nested property bags. Nit: some of them refer to CSS2.	css-page
Rules in @keyframes	at-rule	animatable properties, which are properties whose Animation type is not animatable	css-animations

It may be useful to distill the intent behind each of these and create "sets" of properties that we can refer to (maybe in the CSS Indexes document?), so we don't have to update several locations when we add a new property, and especially so that non-CSSWG specs have to maintain lists of CSS properties, which is bound to get out of date. As you can see from the table above, this is already happening to some degree, with some allowlists referring to other allowlists. However, this is still rather ad hoc, and there are still multiple places to update every time we add a new property.

There are several advantages to this:

• Less error-prone, easier to update one place when a new property is added, rather than having to remember every single allowlist in CSS
• Encourages more alignment across different allowlists
• Easier to compile new allowlists
• Easier for authors to learn specific sets, rather than each pseudo having its own ad hoc allowlist.

Of course the question then becomes: what should the bags be?
To answer this, we need data. Once we have consensus to pursue this, someone should compile a table of all existing allowlists, so that the underlying concepts can emerge (e.g. cannot affect layout, etc), and we can take it from there.

[cdoublev]

Some CSS rules use property bags.

@try accepts inset, margin, border, padding, sizing, box alignment, properties.

@page accepts page properties and a margin rule accepts page margin properties. Both bags contain nested property bags. Nit: some of them refer to CSS2.

A keyframe rule accepts animatable properties, which are properties whose Animation type is not animatable.

---

It would be helpful if w3c/reffy could extract the definitions of these rules with the corresponding bag(s).

Instead of adding properties to CSS Indexes, property definition tables could have an (optional) field for bag identifers.

[LeaVerou]

Thanks @cdoublev, great examples! I updated the first post, and converted the initial list into a table.

---

Today I stumbled on yet another one: ::cue. This is especially bad because it forces another WG to maintain a list of CSS properties, which is bound to get out of date.

[SebastianZ]

I've added the first letter pseudo-elements to the table in the first post.

Sebastian

[cdoublev]

@try has been renamed to @position-try (in simple terms) and now accepts inset, margin, sizing, self-alignment properties.

Nit: animatable properties are currently not equivalent to the properties accepted in a keyframe rule (see #2736). For example, in Chrome, will-change (not animatable) is accepted in a keyframe rule, whereas animation-duration is not. FF accepts both properties in a keyframe rule. But I hope one day someone will replace any CSS property except those defined in this specification by animatable properties, and exclude these properties from CSSKeyframeRule.style.

[css-meeting-bot]

The CSS Working Group just discussed [Meta][Editorial] Define bags of CSS properties to be referenced by allowlists.

The full IRC log of that discussion

<emilio> lea: not about author-facing feature, but organizing specs better
<emilio> ... we have a bunch of places which have some restrictions, like pseudo-elements, pseudo-elements (:visited), and a particularly egregious one is WebVTT
<emilio> ... they should not be maintaining external lists, but right now there's no other way
<emilio> ... proposal is to decompose these
<emilio> ... into defined lists with defined purposes
<astearns> ack fantasai
<florian> q+
<emilio> ... some of these point to each other (like pseudos depending on each other)
<emilio> ... but they probably shouldn't
<emilio> fantasai: I think it's a great idea in theory
<emilio> ... the problem is that it's very ad-hoc per pseudo-element
<lea> q+
<emilio> ... aside from highlights we don't really have a good grouping
<emilio> ... and highlights are already well defined
<emilio> ... I think in the future we might have a better idea about how to do this
<emilio> ... currently I don't really see a lot of commonality
<emilio> ... we could define set of properties that are related, like "inline layout related"
<emilio> ... but there's some interesting edge cases
<emilio> ... I like the idea in theory but not sure about practicality
<emilio> ... none of these properties relate to ::cue
<emilio> ... in the future we might come up with stuff easy to coalesce
<emilio> ... I see the problem but I don't see how to reasonably solve it
<emilio> q+
<astearns> ack florian
<fantasai> s/reasonably/practically/
<emilio> florian: another thing is that if these existed it'd be more convenient if they are centrally defined
<schenney> q+
<emilio> ... what's more maintainable is a yes/no on the property definition
<emilio> ... it's a lot less usable
<astearns> automation can make that usable
<emilio> ... because then we need bikeshed to generate the thing
<emilio> ... having to choose between usable and maintainable is not amazing
<astearns> ack lea
<emilio> lea: I don't think it should be an either / or
<emilio> ... there's lot of value even if we find some common groups
<emilio> ... like "this group minus that" or "this group plus these three"
<emilio> ... an external group like WebVTT is much more likely to refer to a group
<emilio> ... rather than having a random pseudo-element that happens to have the same restrictions
<emilio> ... replying to florian I think it makes sense to make this part of a property definition
<emilio> ... we could probably have something that is basically tags
<fantasai> "Categories"
<emilio> ... like, categories that these properties already belong to
<emilio> ... maybe it's crucial enough that we wanna keep it separate
<emilio> ... but yeah we could introduce a single "groups" property rather than any individual group
<astearns> ack emilio
<dholbert> emilio (IRC): I agree this is rather messy
<dholbert> ... The binary-switch thing is kinda how it works in browsers. Each property has a "does this apply to ::first-line,..." etc. we have that centrally defined somewhere. Easy to map to the spec. Would be nice to have it defined on the property itself (in the spec)
<dholbert> ... I'm not sure that historically implementations and the spec match on a lot of these restrictions. e.g. for ::first-line, one of the restrictions is that it doesn't support non-inherited stuff. Not sure how to best-define it
<dholbert> ... maybe nice to have on-off buckets for various pseudos. Hard to define more generic groups. "inherited text properties"? "color properties?" "properties that don't affect layout"?
<dholbert> lea (IRC): seems like reasonable bags
<dholbert> fantasai (IRC): but which will be actually used
<dholbert> fantasai (IRC): hightlight pseudos could be considered "stuff that shows the bounds of the box"
<emilio> fantasai: most of them are pretty ad-hoc
<fantasai> s/shows/does not show/
<astearns> ack schenney
<emilio> schenney: I think I'm supporting some of the things that emilio said. non-layout-modified is the basis for highlight pseudos. The other one is properties that do not affect overflow
<emilio> ... key point is that it's rather useful in preparing specs
<astearns> ack dbaron
<emilio> dbaron: one concern about putting them in propdef (although it's not really a new problem, just makes it more visible) is that we need a good description of what makes a property go into a set
<emilio> ... we need to write down what the principles about these sets are
<emilio> ... so that someone writing a propdef table can actually get it right
<lea> q+
<emilio> ... this is sort of already a problem that we have
<emilio> ... but we should try and avoid making it worse
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<emilio> ... and we should try to make clear what rules each group follow
<astearns> ack lea
<emilio> s/follow/follows
<emilio> lea: I think dbaron makes a very good point, even though kind of orthogonal
<emilio> ... that's why we are pushing for design principles in w3c
<emilio> ... we could have design principles in w3c
<emilio> ... but it's important to have proper design principles
<emilio> ... not something in the wiki
<emilio> astearns: my suggestion was going to be putting it in the wiki
<emilio> ... not sure we're ready for a resolution
<emilio> ... we should keep thinking about it
<emilio> ... continuing in the issue or documenting / listing proposed bags / the criteria for them in the wiki
<dholbert> emilio (IRC): one suggestion
<dholbert> emilio (IRC): for things that have restrictions currently, can we resolve on documenting them?
<dholbert> emilio (IRC): the restrictions that we've got are there for a reason. Not changing overflow when you change selection, etc
<dholbert> ... first-line, placeholder, marker, ... for some of these, it's not written down. Can we get together and write the reasoning down
<dholbert> astearns (IRC): we should have separate discussions for the existing lists, yeah (separate from general defining-the-bags idea)
<dholbert> astearns (IRC): please also continue discussing this in the bags issue