- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Jan 2023 17:34:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility`.
<details><summary>The full IRC log of that discussion</summary>
<bramus> miriam: discussed before but implementers have been pushing back<br>
<bramus> miriam: issue that in CQ we are just looking to see if it resolve to true or false but that something to resolve against<br>
<bramus> miriam: in that finding container step we look at question ask: if looking for width we are looking for container with inline size set<br>
<bramus> miriam: height block size, both<br>
<bramus> miriam: problem if when asking for width or height, it can resolve true even though half of it is recognized<br>
<bramus> miriam: feels fine for now, as it could become recognized later<br>
<bramus> miriam: as we add queries it not only changes if it resolve to true or false but also which container to look at<br>
<bramus> miriam: causing possible backwards compat issue<br>
<bramus> miriam: where something resolves differently whether its recognized as a query feature or not<br>
<bramus> miriam:<br>
<bramus> miriam: some vendors have shipped, so changing now is a breaking change<br>
<bramus> miriam: would love to resolve sooner than later<br>
<bramus> miriam:<br>
<bramus> miriam: resolved previously was to split on the or [missed]<br>
<bramus> miriam: browsers said that would be difficult and not logic to split on or<br>
<bramus> miriam: other direciton sth with unknown query feature can match container<br>
<bramus> astearns: there is no container that can asnwer all sides of the query<br>
<bramus> miriam: yes<br>
<bramus> miriam: width or height would then not resolve<br>
<oriol> q+<br>
<astearns> zakim, open queue<br>
<Zakim> ok, astearns, the speaker queue is open<br>
<astearns> q+ oriol<br>
<astearns> ack JonathanNeal<br>
<bramus> s/width or height/width or unkonwn/<br>
<bramus> miriam: width or height would also not match<br>
<astearns> ack oriol<br>
<bramus> oriol: agree that there are problems with or. what if you have [missed] and? seems strange<br>
<bramus> oriol: also want to consider third option to consider: could be possible that each queried feature could evaluate to different container<br>
<astearns> s/[missed]/negated and/<br>
<bramus> oriol: that is what we do with container units<br>
<bramus> astearns: not sure I understand<br>
<bramus> oriol: for example at container rule "width > 100px and height > 100px"<br>
<bramus> oriol: parent that only has inline size witll be able to match height. other parent would match the width query<br>
<bramus> oriol: might be confusing though.<br>
<bramus> oriol: just wanted to list for completeness<br>
<bramus> oriol: fine with 2nd option: if feature not recognize, just resolve as unknown<br>
<bramus> miriam: in the or case it could resolve on one side of the query still<br>
<florian> q+<br>
<bramus> oriol: we would resolve each feature against the nearest container that supports it and if there is an unknown feature that we do not support by any ancesstor then it would resolve entirely to unknown<br>
<bramus> bramus: a unknown is then false?<br>
<bramus> oriol: it does not apply the rule<br>
<TabAtkins> (I'm strong against resolving a single query against multiple elements.)<br>
<bramus> oriol: it only becomes false at the top level<br>
<bramus> astearns: option 3 would allow to keep prev resolution<br>
<bramus> astearns: would get past implementer objection?<br>
<TabAtkins> q+<br>
<bramus> oriol: what are the objections? probably third option more complex than option 2. havent considered if easy to implement or not<br>
<astearns> ack florian<br>
<dbaron> I do feel that it's strange that @container (width > 100px) { @container (height > 100px) { ... } } is different from @container ((width > 100px) and (height > 100px)) { ...}, and I think oriol's option 3 fixes that... but it's also strange on itself, and maybe we should be thinking about use of container names as the "good practice" and these being sorts of error cases.<br>
<bramus> florian: I understand optoin 3 and find it interesting. fairly hard time deciding whether that is confusing to authors or not<br>
<bramus> florian: opens up extra possibility<br>
<bramus> florian: would need examples to back up any reasoning<br>
<astearns> ack TabAtkins<br>
<bramus> TabAtkins: in the discussion with anti he was having a different view of optoin 1?<br>
<bramus> TabAtkins: rahter than looking at query and using that as a prefilter for containers to look at, we instead will look at each possible container and if the query can be resolved against that we will do that, otherwise unknonwn<br>
<florian> s/find it interesting/find it interesting in the abstract/<br>
<bramus> TabAtkins: in the case "width or height" will work on inline-size container because container can handle a part of that<br>
<bramus> TabAtkins: but if you do "width and height" this would fail because of the 1 unkown<br>
<bramus> TabAtkins: that was optoin 1, right?<br>
<bramus> miriam: no, dont think so but that could work<br>
<florian> s/to authors or not/to authors or opens up a new and maybe convenient option/<br>
<bramus> TabAtkins: dont really understand what antti’s understanding is so I can‘t comment on what it might mean<br>
<bramus> TabAtkins: but what I said is what I voted for<br>
<bramus> miriam: that would work, as does oriol’s proposal<br>
<bramus> miriam: I dont see problems with oriols proposal and potentially does match author intent<br>
<bramus> TabAtkins: disagree with that. you almost certainly want both conditions to match against same element, not a parent higher up<br>
<astearns> agrees single container evaluation makes more sense<br>
<bramus> TabAtkins: (mentions dbaron‘s note)<br>
<astearns> ack dbaron<br>
<bramus> TabAtkins: while you may want to target 1 element, you almost never want to target 2<br>
<bradk> +1 to what Tab said<br>
<TabAtkins> TabAtkins: While you might sometimes want to write nested queries and target the same element both times, you probably never want to write a single query and have it target two separate elements<br>
<bramus> dbaron: trying to understand option 1. it seems very strange to me that you would take a query "height or width" and then evaluate against 1 part of that against 1 element and ignore the 2nd part of the query<br>
<bramus> dbaron: seems strange. would expect to evaluate against a single element that answers to all parts<br>
<bramus> TabAtkins: that’s the compat issue: unknown query<br>
<bramus> florian: no element<br>
<bramus> miriam: option 1 may have been poorly written<br>
<bramus> miriam: i think tab’s and oriol’s could work<br>
<bramus> miriam: 1 container or loosen that?<br>
<bramus> dbaron: could tab clarify?<br>
<astearns> ack fantasai<br>
<TabAtkins> So then my proposal: attempt to match the queries against each possible container. If the container *can* match a given query, good; if not, it evaluates to unknown. (Unknown queries are always unknown.) Then if the top-levle result is unknown, move to the next possible container.<br>
<bramus> fantasai: RE 1 container or 2: it does seem weird that combining […]. if you wanted to match against single container we have explicity type argument right?<br>
<bramus> miriam: no, we don’t<br>
<bramus> fantasai: ok, all implicit<br>
<bramus> fantasai: if we had explicit type then author could define<br>
<astearns> ack dbaron<br>
<TabAtkins> So (true or unknown) will match, (true and unknown) will fail to match (and stop), (false or unknown) will continue looking.<br>
<bramus> dbaron: auto-finding parent based on query might be bad idea. it should search using name or nearest<br>
<bramus> miriam: that creates other probs such as style queries where we determined that you usually want direct parent so elements are style container by default so that you can query nearest but we dont want them getting in the way of size queries. going with nearest is going to be fragile.<br>
<bramus> TabAtkins: my proposal is going to match nearest that can possibly match. in worst case its going to be […] right away.<br>
<bramus> astearns: I see couple of ways forward<br>
<oriol> q+<br>
<bramus> astearns: resolve on tab’s reworking of option 1 or take back to issue<br>
<dbaron> I'm OK with Tab's proposal.<br>
<bramus> astearns: anyone need more time to review?<br>
<astearns> ack oriol<br>
<bramus> oriol: not sure if I understand proposal; what does it mean that container matches query?<br>
<bramus> TabAtkins: it means that you satisfy the contditiions to potentially mathc. mainly that you have right container type.<br>
<bramus> oriol: how do the binary operators work?<br>
<bramus> TabAtkins: if you arent capable of matching, then evaluates to unkown. e.g. inline size vs width and height, one will be true/false and other unknown. if finale result at top level is unknown: skip and move up tree. if true/false: use that.<br>
<bramus> TabAtkins: true + unknown = skip<br>
<bramus> TabAtkins: true and false = false<br>
<bramus> florian: i am going back to issue and throwing some examples in issue<br>
<fantasai> s/am going/would like to go/<br>
<astearns> ack dbaron<br>
<fantasai> s/throwing/throw/<br>
<bramus> dbaron: weird consequence of tabs proposal: nested containers: inner one has inline and outer one haas both containmenbts. there is going to be a point where you siwtch from using inner one to outer one. that jump seems pretty weird<br>
<florian> s/examples in issue/examples in issue to compare Tab's option and Oriol's/<br>
<bramus> dbaron: i guess we need to work through examples<br>
<bramus> astearns: OK. let’s take back to issue<br>
<dbaron> dbaron: ... to see if it does backwards jumping or not<br>
<fantasai> I believe with Tab's logic you would choose different containers depending on whether you support 'unknown'<br>
<bramus> miriam: other part of this: do we need use counters as this is breaking?<br>
<fantasai> s/would/might/<br>
<bramus> astearns: good idea. put it in 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/7551#issuecomment-1387458142 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 January 2023 17:34:30 UTC