-
Notifications
You must be signed in to change notification settings - Fork 676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-anchor-position] Anchor positioning proposal comparison #9117
Comments
@stubbornella Thank you for this compilation! I'm slowly working on an article with my thoughts about this proposal, and this comparison is very helpful. TL;DR for what I think: I really like some of the aspects of this proposal, and I think there could be a way to combine both the existing spec and it, merging the best parts of both. I really like the flexibility of the current implementation in Chrome, but I can see how the new exploration covers the areas the current spec lacks in — centering/aligning things, grid-like positioning, the A few quick notes (not exhaustive) regarding the comparison:
|
Not sure if it's just me, but the table was confusing because github displays |
To clarify, this issue is more on the Chromium implementation side, not on the spec side. The proposal in #8181 should be sound on its own, but it requires a lot of change to Chromium's current implementation. The change should still be doable, though. So if someone can convince me that this is a super important must-have part of the feature, then I'll prioritize the implementation in Chromium, which should then be enough to close the spec issue. |
To phrase this a little more clearly for others, changing from Fixing that is easy on the spec side (as outlined in #8181, it just requires resolving the anchor name into an element reference at computed-value time), but as Xiaocheng said it's harder in our impl right now (but possible). |
Afaict the problem is much more fundamental. That change in their proposal (going from the spec's "last" back to "first") was largely incidental; the issue is instead that the grid proposal has no way to refer to multiple anchors at all, and it's not immediately clear how it would be extended to do so. |
[css-anchor-position]
Putting them in code helped somewhat but it was still a little hard for me to tell apart. I've swapped the "not currently, but probably could" |
Given some recent progress, here's an updated comparison table:
|
Not sure there's anything specific to discuss on this issue at TPAC, since we have individual issues for everything listed here? |
It’s likely the breakout session on Wednesday will be enough for this issue https://www.w3.org/2023/09/TPAC/breakouts.html#b-3d55226e-0fdd-4836-b5fa-edaa77e10d34 |
The CSS Working Group just discussed The full IRC log of that discussion<ntim> TabAtkins: Listed out all the use cases, and what proposals can do them well, not well, etc.<astearns> updated list: https://github.com//issues/9117#issuecomment-1698431865 <flackr> q+ <astearns> ack flackr <ntim> flackr: I don't see transitions between anchors, which none of the proposals cover, but is very common <ntim> una: I see transitions between fallbacks <ntim> dbaron: look at the second list that astearns linked to <dbaron> Is there an item in that list for the sidenotes / doc comments use case? <ntim> TabAtkins: you can animate between 2 distinct anchors, the problem is animating when what an anchor name refers to changes <ntim> fantasai: transition between two anchor names is in the table <nicole> https://docs.google.com/document/d/185yzaofuMP2p1KK00e2J0cmL8vAxOY3LF7NxhpjveRo/edit <ntim> (what flackr was referring to) <nicole> This is the document of examples <ntim> TabAtkins: does anyone see something obviously missing in the table? <dbaron> ntim: "anchor reference changes" is a confusing term because it can mean either "a change to which anchor is referenced" or "the anchor that is referenced changes (e.g., moves)"... and we care about both <ntim> fantasai: the ability to style based on fallbacks <emeyer> q+ <dbaron> s/ntim:/dbaron:/ <flackr> q+ <astearns> add https://github.com//issues/9332 to the list <TabAtkins> https://github.com//issues/9332 <flackr> q- <astearns> ack emeyer <ntim> emeyer: multiple anchors is something I'm interested in, there is no issue <ntim> fantasai: not in the issue, because Tab's proposal already covers it <ntim> fantasai: Not sure if it's covered, but cascading behavior on the @Try blocks is terrible <TabAtkins> (it's on th elist of topics to discuss) |
Please let me know if I'm opening this issue incorrectly!
@xiaochengh and I created a feature by feature comparison of the two anchor positioning proposals [1, 2] so we could better understand which features they each support.
As we were doing that, we realized that both had features they could support, but didn't yet. We'd like to explore extending the two proposals to the full feature set. To do so, we need your help, we are likely missing whole features and in some cases wrong about whether the feature is supported by each proposal, so please do add comments with corrections and I'll update the issue accordingly. There are also several where I didn't have enough information to be sure if it was supported. I marked those with a "?"
Feature table
🔶
= not currently, but probably could❌
= not currently, would be difficult or impossible✅
= supportedMost features could be supported by either proposal. But, each has weak areas that we can focus on improving before we compare the two.
🔶
✅
🔶
✅
✅
❌
❌
❌
🔶
✅
🔶
✅
🔶
🔶
🔶
🔶
✅
❌
?✅
🔶
✅
🔶
🔶
?✅
✅
✅
🔶
✅
🔶
🔶
✅
🔶
✅
🔶
🔶
✅
🔶
✅
✅
✅
✅
❌
?✅
🔶
✅
❌
?✅
The text was updated successfully, but these errors were encountered: