Open tabatkins opened 1 year ago
Hi @tabatkins,
For formatting purposes I have moved your guidance to avoid other css sessions to the instructions session.
If possible can this be later in the afternoon (after 2pm?)
(It is now at 2:30pm local time.)
[css-anchor-position] Anchor positioning proposal comparison https://github.com/w3c/csswg-drafts/issues/9117
Plan to go thru the table and make sure that every interesting difference has been captured. We can add more if necessary. Afterwards, can work thru individual issues.
[css-align-3][css-position-3] Better interaction of auto insets and self-alignment properties? https://github.com/w3c/csswg-drafts/issues/9124
We have agreement on single-auto behavior, but need to get consensus on double-auto behavior.
[css-anchor-position-1] Interaction with anchor-center and scrolling https://github.com/w3c/csswg-drafts/issues/9223
This issue, and the previous, affects the behavior of anchor-center
and so are relatively high priority
even if they'll take a little longer.
[css-anchor-position-1] Ability of logical / physical combo positioning https://github.com/w3c/csswg-drafts/issues/9268
As far as I can tell, given our inset-area
addition,
this issue is now moot.
[css-anchor-position-1] Automatic alignment / justification https://github.com/w3c/csswg-drafts/issues/9269
auto
inset behavior already aligns as expected.
For inset-area
, should we imply anchor-center
alignment
if the area covers one of the center tracks
(but doesn't cover the central area)?
[css-anchor-position-1] Do we need area-list fallback position syntax? https://github.com/w3c/csswg-drafts/issues/9270
Current plan is simple mirroring/rotating fallback for simple cases,
and full-bore @position-fallback
for complex cases.
Do we need the middle-ground of inset-area
-focused fallback?
[css-anchor-position-1] Better reusability of anchor names https://github.com/w3c/csswg-drafts/issues/9045
Plan is to add anchor-scope
property,
parallel to similar scoping properties.
[css-anchor-position-?] Add a ::tether pseudo-element https://github.com/w3c/csswg-drafts/issues/9271
I suspect there's too many issues with this at the moment, and would like to push it to level 2, despite the obvious importance of the feature.
[css-anchor-position-1] Define interaction with the cascade in @try https://github.com/w3c/csswg-drafts/issues/9149
[css-anchor-1] Need ability to say "don't render" when anchor is off-screen https://github.com/w3c/csswg-drafts/issues/7758
Should we add anchor-clip
? (I think yes.)
Should we clip by default? (I think no.)
[css-anchor-1] Transitioning when the anchor element with a given name changes https://github.com/w3c/csswg-drafts/issues/8181
Reasonably straightforward answer in terms of specs (capture the target element as part of computed value), but much more difficult implementation-wise. How to proceed?
@tabatkins, do you have a link to minutes for this session? Thanks!
Session description
Compare the current spec of CSS Anchor Positioning and the alternative proposal by Apple, list the individual issues where the current spec can be improved, and try to reach consensus or resolve those issues.
Session goal
Close the gap between the current spec and the proposal as much as possible.
Additional session chairs (Optional)
No response
IRC channel (Optional)
css
Who can attend
Anyone may attend (Default)
Session duration
60 minutes (Default)
Other sessions where we should avoid scheduling conflicts (Optional)
3, #20, #55
Estimated number of in-person attendees
Don't know (Default)
Instructions for meeting planners (Optional)
In addition to the named sessions, avoid other directly CSS-related sessions. Afternoon slot if possible.
Agenda, minutes, slides, etc. (Optional)