- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Feb 2024 20:05:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[Meta][Editorial] Define bags of CSS properties to be referenced by allowlists`. <details><summary>The full IRC log of that discussion</summary> <emilio> lea: not about author-facing feature, but organizing specs better<br> <emilio> ... we have a bunch of places which have some restrictions, like pseudo-elements, pseudo-elements (:visited), and a particularly egregious one is WebVTT<br> <emilio> ... they should not be maintaining external lists, but right now there's no other way<br> <emilio> ... proposal is to decompose these<br> <emilio> ... into defined lists with defined purposes<br> <astearns> ack fantasai<br> <florian> q+<br> <emilio> ... some of these point to each other (like pseudos depending on each other)<br> <emilio> ... but they probably shouldn't<br> <emilio> fantasai: I think it's a great idea in theory<br> <emilio> ... the problem is that it's very ad-hoc per pseudo-element<br> <lea> q+<br> <emilio> ... aside from highlights we don't really have a good grouping<br> <emilio> ... and highlights are already well defined<br> <emilio> ... I think in the future we might have a better idea about how to do this<br> <emilio> ... currently I don't really see a lot of commonality<br> <emilio> ... we could define set of properties that are related, like "inline layout related"<br> <emilio> ... but there's some interesting edge cases<br> <emilio> ... I like the idea in theory but not sure about practicality<br> <emilio> ... none of these properties relate to ::cue<br> <emilio> ... in the future we might come up with stuff easy to coalesce<br> <emilio> ... I see the problem but I don't see how to reasonably solve it<br> <emilio> q+<br> <astearns> ack florian<br> <fantasai> s/reasonably/practically/<br> <emilio> florian: another thing is that if these existed it'd be more convenient if they are centrally defined<br> <schenney> q+<br> <emilio> ... what's more maintainable is a yes/no on the property definition<br> <emilio> ... it's a lot less usable<br> <astearns> automation can make that usable<br> <emilio> ... because then we need bikeshed to generate the thing<br> <emilio> ... having to choose between usable and maintainable is not amazing<br> <astearns> ack lea<br> <emilio> lea: I don't think it should be an either / or<br> <emilio> ... there's lot of value even if we find some common groups<br> <emilio> ... like "this group minus that" or "this group plus these three"<br> <emilio> ... an external group like WebVTT is much more likely to refer to a group<br> <emilio> ... rather than having a random pseudo-element that happens to have the same restrictions<br> <emilio> ... replying to florian I think it makes sense to make this part of a property definition<br> <emilio> ... we could probably have something that is basically tags<br> <fantasai> "Categories"<br> <emilio> ... like, categories that these properties already belong to<br> <emilio> ... maybe it's crucial enough that we wanna keep it separate<br> <emilio> ... but yeah we could introduce a single "groups" property rather than any individual group<br> <astearns> ack emilio<br> <dholbert> emilio (IRC): I agree this is rather messy<br> <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)<br> <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<br> <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"?<br> <dholbert> lea (IRC): seems like reasonable bags<br> <dholbert> fantasai (IRC): but which will be actually used<br> <dholbert> fantasai (IRC): hightlight pseudos could be considered "stuff that shows the bounds of the box"<br> <emilio> fantasai: most of them are pretty ad-hoc<br> <fantasai> s/shows/does not show/<br> <astearns> ack schenney<br> <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<br> <emilio> ... key point is that it's rather useful in preparing specs<br> <astearns> ack dbaron<br> <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<br> <emilio> ... we need to write down what the principles about these sets are<br> <emilio> ... so that someone writing a propdef table can actually get it right<br> <lea> q+<br> <emilio> ... this is sort of already a problem that we have<br> <emilio> ... but we should try and avoid making it worse<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <emilio> ... and we should try to make clear what rules each group follow<br> <astearns> ack lea<br> <emilio> s/follow/follows<br> <emilio> lea: I think dbaron makes a very good point, even though kind of orthogonal<br> <emilio> ... that's why we are pushing for design principles in w3c<br> <emilio> ... we could have design principles in w3c<br> <emilio> ... but it's important to have proper design principles<br> <emilio> ... not something in the wiki<br> <emilio> astearns: my suggestion was going to be putting it in the wiki<br> <emilio> ... not sure we're ready for a resolution<br> <emilio> ... we should keep thinking about it<br> <emilio> ... continuing in the issue or documenting / listing proposed bags / the criteria for them in the wiki<br> <dholbert> emilio (IRC): one suggestion<br> <dholbert> emilio (IRC): for things that have restrictions currently, can we resolve on documenting them?<br> <dholbert> emilio (IRC): the restrictions that we've got are there for a reason. Not changing overflow when you change selection, etc<br> <dholbert> ... first-line, placeholder, marker, ... for some of these, it's not written down. Can we get together and write the reasoning down<br> <dholbert> astearns (IRC): we should have separate discussions for the existing lists, yeah (separate from general defining-the-bags idea)<br> <dholbert> astearns (IRC): please also continue discussing this in the bags issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9453#issuecomment-1944508823 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 February 2024 20:05:46 UTC