- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Aug 2023 16:00:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] Alternative syntax for auto position fallback`, and agreed to the following: * `RESOLVED: accept proposal in the draft with details to be worked out over time` <details><summary>The full IRC log of that discussion</summary> <dbaron> TabAtkins: xiaochengh was exploring space for position stuff. While thinking about use cases brought up for alternate proposal, realized the current stuff we have in the spec for auto fallback isn't sufficient. auto and auto-same keywords. Current behavior is that they resolve to appropriate side of anchor and auto-generate try blocks that flip to other side. Only thing changed in try blocks are side -- margins don't change as well.<br> <dbaron> TabAtkins: That seems less than useful.<br> <dbaron> TabAtkins: xiaochengh's alternate proposal is to separate the automatic try block generate to an explicit fallback property that has keywords that say how to generate the fallbacks, a bunch of keywords listed in proposal. (flip-both and compass try all 4 possibilities)<br> <dbaron> TabAtkins: This affects more than just the inset properties. Also affects other box model properties. So margin-bottom after a flip-y ends up as a margin-top.<br> <dbaron> TabAtkins: This seems substantiallly better to me.<br> <dbaron> TabAtkins: In the simplest cases it's identical, but in nontrivial cases it does much better behavior. I'm happy to acccept these.<br> <dbaron> TabAtkins: Other use for auto and auto-same keywords -- automatically resolving to the appropriate side -- can use in the inset shorthand and get all the sides specified. Can keep that behavior and rename the keywords to not imply auto-fallback.<br> <jensimmons> q+<br> <dbaron> TabAtkins: I think this opens up possibilities for more fallback. Could build some position-area stuff in here. Could specify position-area spots and it could do appropriate flipping as well. I think it has growth area to fill in remaining fallback cases.<br> <astearns> ack fantasai<br> <dbaron> fantasai: I think this is interesting. I find the auto keywords inside ?? to be confusing. I can never remember what the auto thing does. Can we use more descriptiive keywords?<br> <dbaron> TabAtkins: suggested keywords are same and opposite. So top: anchor(same) means top.<br> <TabAtkins> top: anchor(same)<br> <TabAtkins> means top: anchor(top)<br> <iank_> we can bikeshed with authors<br> <dbaron> fantasai: another idea would be 'inside' and 'outside'<br> <astearns> ack jensimmons<br> <fantasai> top: anchor(inside) is top: anchor(top) -- it anchors it inside the anchor box<br> <fantasai> top: anchor(outside) is top: anchor(bottom) -- it anchors it outside the anchor box<br> <dbaron> jensimmons: Comparing this idea to current spec, not much to say. But comparing to proposal we presented at f2f, the higher-level idea of fallbacks. In the position-area/inset-area model, where you say you want above, in both right and center columns... at the bottom do you want it right and center. What if you want above all the way across, falling back to just center if below. But maybe just flipping is what people usually want. No<br> <dbaron> opinion on whether a good iteration on current spec.<br> <nicole> Here is a doc of examples we worked through (you'll need to ask for access) https://docs.google.com/document/d/1Dsu91zGfhG-qBbZvwOz13SS_m5dTb_ZHbDbonUf1qnM/edit?usp=sharing&resourcekey=0-8b2dD7pNg1Ruovm0QlhNkA<br> <dbaron> TabAtkins: Three levels of fallback precision: (1) is simply mirror. (3) is arbitrary things in next fallback, can use try blocks in @position-fallback. (2) between those is to adjust as necessary, mostly just moving to different area. I think this syntax is extendable to take position-area keywords as well.<br> <xiaochengh> q+<br> <dbaron> TabAtkins: So you could start out as top center and move to bottom all and have it work out appropriately, with the necessary flips.<br> <dbaron> TabAtkins: I think that ends up addressing your concern.<br> <dbaron> jensimmons: I'm not a fan of the try blocks, but maybe a discussion for a different day.<br> <fantasai> +!<br> <fantasai> s/!/1<br> <nicole> +1<br> <dbaron> TabAtkins: We have use cases that you need the try blocks for, but ideally we should make it so 80% of cases don't need to touch that.<br> <nicole> q+<br> <dbaron> jensimmons: I wonder if we can iterate to something where people can do the complicated stuff without try blocks.<br> <astearns> ack xiaochengh<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about relationship to position-fallback<br> <dbaron> xiaochengh: Wanted to add something to Tab's second case: a little more complicated but not arbitrary: This property can also be used in try blocks so that we can auto-generate fallback from try blocks. It doesn't eliminate all the try blocks but it can significantly reduce the length of the try list.<br> <dbaron> fantasai: Relationship of this to position-fallback property? Should this be a longhand of this or separate properties?<br> <dbaron> TabAtkins: What posiotion fallback property?<br> <dbaron> TabAtkins: If you don't specify position fallback, these entries get auto generated, if you do specify then you ignore it.<br> <dbaron> fantasai: should they then be the same property?<br> <dbaron> TabAtkins: maybe<br> <dbaron> xiaochengh: I don't think so -- position-fallback property cannot be used in a try block but this property can<br> <lea> in general we should avoid designing syntax that just ignores specified values, as that tends to lead to author confusion. Maybe if we combine both somehow?<br> <lea> q?<br> <dbaron> TabAtkins: setting up one try block with the things you need and then saying auto to generate a couple more, that's fair.<br> <fantasai> yeah, maybe make position-fallback for both<br> <dbaron> astearns: can we resolve to add to the draft, and add issues such as one property or two, how it works in try blocks?<br> <lea> I can easily see the auto values being useful both by themselves, as well as fallbacks to more specific fallbacks specified via @try blocks<br> <dbaron> fantasai: I think that's fine if we make it clear there's open questions.<br> <dbaron> RESOLVED: accept proposal in the draft with details to be worked out over time<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9196#issuecomment-1690225805 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 August 2023 16:00:52 UTC