- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jan 2024 17:45:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-conditional] testing support of properties and values with partial implementations`, and agreed to the following:
* `RESOLVED: adopt keyword based feature queries, with names to be bikeshedded later, with the expectation that we will use them rarely and test and message their addition carefully`
* `RESOLVED: Add a keyword for alignment on blocks, with the specific name TBD`
<details><summary>The full IRC log of that discussion</summary>
<flackr> dbaron: one of the design goals of @supports is we don't want to require impls to maintain large sets of data about what is supported that's separate from the code which supports the thing<br>
<flackr> dbaron: in the past doing this tends to result in them getting out of sync<br>
<flackr> dbaron: so we originally defined it in terms of property syntax being accepted, and is in sync with a certain definition of whether features are supported<br>
<Rossen_> q?<br>
<flackr> dbaron: @supports has not been very effective for certain types of interactions, e.g. a propery that was once only supported on flexbox being supported elsewhere<br>
<flackr> dbaron: people have wanted a syntax for these sorts of interactions in a general way. There's no proposal for a general syntax that satisfies the original design constraint<br>
<flackr> dbaron: The proposal I put in the issue, is that we don't try to solve this generally, but add a solution that we use in rare cases where we feel it's important with one-off keywords<br>
<flackr> dbaron: I propose calling this a feature function where we add a keyword for a particular interaction<br>
<flackr> dbaron: The idea is we'll use this rarely, e.g. 1 per year is okay, 1 per month is probably too much<br>
<florian> q+<br>
<emilio> q+<br>
<flackr> dbaron: I'd like feedback on the general idea, we can bikeshed names<br>
<Rossen_> ack florian<br>
<oriol> q+<br>
<flackr> florian: one of the other reasons for original design constraint is not just that they might eventually get out of sync but could initially be out of sync if the detection is done independently<br>
<flackr> florian: you might do one and forget to do the other<br>
<flackr> florian: this problem remains with the alternate proposal, as you might forget to add the detector<br>
<flackr> dbaron: I agree this is a concern, this is part of the reason we want to do it rarely and have process / tests to make sure we don't forget<br>
<Rossen_> ack emilio<br>
<flackr> emilio: I agree with the concern, but having an escape hatch for this makes sense.<br>
<rachelandrew> q+<br>
<flackr> emilio: the thing florian mentioned has also happened in reverse accidentally, e.g. shipping & selector before nesting support??<br>
<flackr> emilio: having this general one-off escape hatch makes sense<br>
<Rossen_> ack oriol<br>
<flackr> oriol: i'm not a big fan, these features when they're used will assumed to be false initially and become true and authors will stop checking them. But it's something we'll add to the platform and will need to keep these checks even though they're sort of obsolete after a while<br>
<flackr> oriol: this is an ongoing cost needing to keep around<br>
<Rossen_> ack rachelandrew<br>
<bkardell_> q+<br>
<flackr> rachelandrew: I quite like this. In an ideal world we'd have a more general thing, but this doesn't come up often. This feels like a pragmatic solution to an edge case that comes up once in a while.<br>
<flackr> rachelandrew: this gets developers what they need / are asking for.<br>
<flackr> rachelandrew: it's also easy to explain to devs<br>
<bramus> +1 to what rachelandrew said there.<br>
<flackr> bkardell_: it feels pragmatic and easy enough to explain if it's like what dbaron said where we have maybe 1/year. I feel like this is the max. If more, this feels like it's not a good solution and we need to find the more general way<br>
<flackr> bkardell_: i'd really like to find the general solution as this is only a part of the issue<br>
<SebastianZ> q+<br>
<flackr> bkardell_: people want to detect all manner of things<br>
<Rossen_> ack bkardell_<br>
<flackr> bkardell_: e.g. you should be able to do custom media queries<br>
<florian> q+<br>
<Rossen_> ack SebastianZ<br>
<flackr> SebastianZ: when we introduce such keywords we should also make clear these features need to ship together with the keywords, clearly stated in the spec<br>
<Rossen_> ack florian<br>
<noamr> q+<br>
<flackr> florian: I think it's interesting bkardell_ mentioned media queries, this might be the generic solution to not solve it directly, but detect the behavior of the feature<br>
<flackr> florian: we could make all sorts of changes that might need to be tested, and could be exposed through a JS media query<br>
<flackr> florian: there might be a commonly used library which exposes a set of features needed<br>
<bkardell_> q+<br>
<flackr> florian: I am concerned about the ability to become out of sync and start of sync, not objecting though<br>
<iank_> fwiw libraries already use JS tests then add classes on html element to say if a particular feature "works"<br>
<bkardell_> if some of those are _very_ common then a solution like this could still work - so I don't think they are mutually exclusive where we know there is a specific/popular one like this necessarily<br>
<flackr> noamr: custom media queries doesn't add much relative to performing the test and putting a class or data attribute on the root element<br>
<Rossen_> ack noamr<br>
<flackr> noamr: in general if your test is some JS which deals with the document, maybe the whole feature belongs in userspace<br>
<flackr> noamr: the user defines it in their own way and doesn't seem to be a web platform feature<br>
<Rossen_> ack bkardell_<br>
<flackr> bkardell_: I don't think they're mutually exclusive ideas<br>
<flackr> bkardell_: I think we should add a mechanism where people can do this in author space and we can decide to add the occasional extremely common one<br>
<Rossen_> ack dbaron<br>
<flackr> dbaron: responding to using data from what authors are doing, we would be doing the addition too late and it would be out of sync. I see this for cases where we know ahead of time that it's going to be a big deal<br>
<florian> +1 to dbaron<br>
<bkardell_> ok<br>
<flackr> Rossen_: i'm hearing general support with some concerns with how many we'll have, any other comments/concerns?<br>
<chrishtr> q+<br>
<flackr> fantasai: a common pattern is property X adds to display type Y, we should have a consistent pattern for representing these cases to avoid each being slightly diff when introduced<br>
<Rossen_> ack chrishtr<br>
<flackr> chrishtr: The proposed resoltion is dbaron's latest comment, right?<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/3559#issuecomment-1868169502<br>
<flackr> chrishtr: adding a custom keyword specific to quirk? assuming so, do we know of any case we can put in the spec as a first example?<br>
<flackr> dbaron: I think the first example would be support for alignment property on blocks, as this is a thing we're talking about doing soon that has this concern<br>
<dholbert> q+<br>
<flackr> chrishtr: how about we add this to the resolution with candidate wording?<br>
<SebastianZ> q+<br>
<flackr> fantasai: I think we should have 2 resoluitons, one for keyword based resoluiton and one for align on block<br>
<flackr> fantasai: for align on blocks, i want to make sure we have a consistent pattern<br>
<chrishtr> @supports (align-content-block-flow)<br>
<flackr> dbaron: I'd like to make these two resolutions and have further discussion to bikeshed the names<br>
<Rossen_> ack dholbert<br>
<fantasai> align-content-on-block<br>
<flackr> dholbert: one q, this proposal lets authors opt in to using css alignment on blocks, but i don't know if it fixes some site that sets * { align-content: center; } and that suddenly starts applying to everything<br>
<flackr> dholbert: do we have a similar proposal to address this?<br>
<flackr> dholbert: it seems like we may need both in order for these sorts of changes to be shippable<br>
<iank_> fwiw we've blocked rolling out align-content:center due to some compat issues with large existing sites.<br>
<flackr> dbaron: I agree it doesn't address this problem, we need to find out whether this will be a problem<br>
<Rossen_> ack SebastianZ<br>
<flackr> SebastianZ: I also had a proposal for custom support queries. I'll create a separate issue for this for discussion. I don't want to derail though<br>
<flackr> Rossen_: dbaron can you summarize resolution?<br>
<flackr> Proposed resoluiton: To adopt keyword based feature queries with names to be bikeshedded later.<br>
<flackr> Rossen_: one of the main concerns was how we keep this to a small number, do we want to capture this in the resolution?<br>
<flackr> iank_: FWIW, it'll be clear when this adds value vs not. These will only have value for a couple of years. What most devs use is modernizr library which have queries for e.g. old grid vs new grid<br>
<flackr> iank_: i suspect we can address this on a case by case basis<br>
<flackr> iank_: currently for us we blocked align on blocks due to breaking some sites<br>
<dbaron> s/align/align-content/<br>
<flackr> iank_: i'm okay with general idea. we'll hear from web devs when this will make their lives easier but we shouldn't add this for every sub feature we roll out<br>
<flackr> Rossen_: I propose let's keep a low number and see if we can agree on this<br>
<flackr> florian: I think there's enough people concerned that we won't be tempted to do this too oftenn<br>
<flackr> Rossen_: is 2 the right number?<br>
<dbaron> Proposed resolution: adopt keyword based feature queries, with names to be bikeshedded later, with the expectation that we will use them rarely and test and message their addition carefully<br>
<flackr> RESOLVED: adopt keyword based feature queries, with names to be bikeshedded later, with the expectation that we will use them rarely and test and message their addition carefully<br>
<dbaron> (I think Rossen maybe wanted <2/year in the resolution?)<br>
<flackr> s/with the expectation that we will use them rarely/less than 2 per year<br>
<flackr> RESOLVED: Add a keyword for alignment on blocks, with the specific name TBD<br>
<flackr> Rossen_: SebastianZ please go ahead and open the issue you mentioned and we can open an issue for names<br>
<flackr> dbaron: separate issue?<br>
<flackr> Rossen_: if it's going to turn into a thing it will be helpful<br>
<flackr> dbaron: sure<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3559#issuecomment-1885332213 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 January 2024 17:45:58 UTC