- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Oct 2022 16:20:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[mediaqueries] Merge error handling section into evaluating section`, and agreed to the following: * `RESOLVED: Properly define resolution of media type and top-level MQ` * `RESOLVED: Clarify the spec text to reflect intended unknown mechanics` * `RESOLVED: Replace "replace by not all" with "evaluates to false", open a separate issue on serialization` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [mediaqueries] Merge error handling section into evaluating section<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7595<br> <fantasai> gsnedders1: We currently don't have interop with some types of errors around invalid media features<br> <florian> q+<br> <fantasai> gsnedders1: because essentially we don't define clearly how any of this is meant to work<br> <astearns> ack lea<br> <fantasai> gsnedders1: there were proposals to put this into Interop 2023<br> <fantasai> gsnedders1: need to know what exactly we'll be testing<br> <fantasai> gsnedders1: a few sections<br> <fantasai> gsnedders1: First, we don't define how to evaluate media type or the top-level media query at all<br> <fantasai> gsnedders1: and we just say that an unknown media type is treated as not matching<br> <fantasai> gsnedders1: whereas unknown media feature [logic]<br> <fantasai> gsnedders1: Suggest to define how to evaluate MQ with handwavy definition of media types matching if appropriate<br> <fantasai> TabAtkins: Agree<br> <astearns> ack florian<br> <fantasai> florian: I agree, media type is not properly defined, but that's not hard. Can be more specific than mentioned<br> <fantasai> florian: since most deprecated by now<br> <fantasai> florian: so only two cases where we differ from screen<br> <fantasai> florian: for top-level MQ, what it ought to be is fairly obvious but we should write it down<br> <fantasai> gsnedders1: Proposed resolution is to define how to evaluate media query and media type<br> <fantasai> gsnedders1: in somewhat obvious way<br> <fantasai> astearns: any objections?<br> <fantasai> RESOLVED: Properly define resolution of media type and top-level MQ<br> <fantasai> gsnedders1: Next, unknown media name or ???<br> <fantasai> gsnedders1: results in value of uknown<br> <fantasai> gsnedders1: but we don't say what exactly is given unknown<br> <fantasai> gsnedders1: an MF name or MF value doesn't have a value<br> <fantasai> gsnedders1: Currently FF and Chrome differ<br> <fantasai> gsnedders1: FF makes the entire MQ uknown if any media feature name or value is unknown<br> <fantasai> gsnedders1: whereas Chrome only makes that specific one unknown<br> <fantasai> florian: Chrome is right, the whole point of this logic is doing this<br> <fantasai> TabAtkins: [agrees]<br> <fantasai> gsnedders1: I can justify both behaviors from current spec text<br> <fantasai> florian: We'll clarify, the intention is 100% clear to the spec editors, so we just need to fix the tet<br> <fantasai> RESOLVED: Clarify the spec text to reflect intended unknown mechanics<br> <fantasai> gsnedders1: Final bit is, MQ whose value is unknown must be replaced with "not all"<br> <fantasai> gsnedders1: but not clear what it means to replace an MQ<br> <fantasai> gsnedders1: maybe need to define MQ serialization?<br> <fantasai> TabAtkins: I think that's right, but...<br> <fantasai> TabAtkins: I think it's a serialization issue<br> <fantasai> gsnedders1: I think we need to say that unknown MQ evaluates to false, and serializes to "not all"<br> <fantasai> florian: makes sense to me<br> <fantasai> emilio: We don't have this thing to support ... with generalized enclosed<br> <fantasai> emilio: is that a compat requirement?<br> <fantasai> florian: part where unknown MQ evaluates to false, that is absolutely desired intent<br> <fantasai> florian: whether accidentally replaced with "not all" with no effect on serialization or whether was intended to talk about serialization, then I don't know<br> <fantasai> gsnedders1: I think it goes back to CSS2<br> <TabAtkins> MQ has a bunch of legacy weirdness that I didn't replace<br> <fantasai> gsnedders1: It could literally just be copy-pasted from earlier level with no thinking<br> <fantasai> emilio: WE don't implement this update to the spec, but if we did we'd probably want to be consistent with @supports<br> <fantasai> emilio: and @supports when you throw something random at it, you serialize that<br> <fantasai> emilio: rather than a false statement<br> <fantasai> florian: should we say, gets evaluated as false? or does that lose something important?<br> <fantasai> emilio: I think so, but not sure how that maps. I think spec said this had to be some value with 3-way state...<br> <fantasai> florian: when you propagate unknown ...<br> <fantasai> emilio: That was not the desired behavior, and we changed it. Unknown just evaluates as false<br> <fantasai> emilio: so probably we want to be consistent, and unknown evaluates as false?<br> <fantasai> TabAtkins: we very specifically want @supports unknown to be false, because if you can't parse it you definitely don't support it<br> <fantasai> TabAtkins: but for MQ, whether you are that type of media or not, you don't know if you can't parse the MQ<br> <fremy> +1 to what TabAtkins just said<br> <fantasai> florian: I think that the "gets replaced by not all" is an ancient and imprecise way of saying evaluate as false, and we should replace this and not talk about serialization<br> <fantasai> gsnedders1: with prior resolution, very few if anything will result in the whole MQ being unknown<br> <fantasai> TabAtkins: not necessarily true, e.g. combine with and and you'll get unknown propagate up<br> <fantasai> gsnedders1: yes, nevermind<br> <fantasai> astearns: Should we resolve, or need more time?<br> <fantasai> emilio: Fine as long as we're all on the same page<br> <fantasai> florian: Instead of "replace by not all" say "evalutates to false"<br> <fantasai> gsnedders1: define serialization of unknown MQ to be "not all", is that still the intention?<br> <fantasai> florian: Let's open a separate issue for serialization, since might have compat concerns<br> <fantasai> florian: Want to look into that offline<br> <fantasai> RESOLVED: Replace "replace by not all" with "evaluates to false", open a separate issue on serialization<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7595#issuecomment-1284268421 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 October 2022 16:20:30 UTC