-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Add anchor attribute #9144
base: main
Are you sure you want to change the base?
Add anchor attribute #9144
Conversation
The anchor attribute can be used to set up CSS anchor positioning by setting an implicit anchor element: https://drafts.csswg.org/css-anchor-1/#implicit-anchor-element
This patch also adds WPTs for the anchor attribute (without popovers) to support the HTML PR whatwg/html#9144 Fixed: 1432016 Change-Id: I3e80326268008e6beaf74389bb32c01050406a81
This patch also adds WPTs for the anchor attribute (without popovers) to support the HTML PR whatwg/html#9144 Fixed: 1432016 Change-Id: I3e80326268008e6beaf74389bb32c01050406a81 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4434155 Commit-Queue: Joey Arhar <[email protected]> Commit-Queue: Xiaocheng Hu <[email protected]> Reviewed-by: Joey Arhar <[email protected]> Code-Coverage: Findit <[email protected]> Auto-Submit: Xiaocheng Hu <[email protected]> Cr-Commit-Position: refs/heads/main@{#1131479}
This patch also adds WPTs for the anchor attribute (without popovers) to support the HTML PR whatwg/html#9144 Fixed: 1432016 Change-Id: I3e80326268008e6beaf74389bb32c01050406a81 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4434155 Commit-Queue: Joey Arhar <[email protected]> Commit-Queue: Xiaocheng Hu <[email protected]> Reviewed-by: Joey Arhar <[email protected]> Code-Coverage: Findit <[email protected]> Auto-Submit: Xiaocheng Hu <[email protected]> Cr-Commit-Position: refs/heads/main@{#1131479}
This patch also adds WPTs for the anchor attribute (without popovers) to support the HTML PR whatwg/html#9144 Fixed: 1432016 Change-Id: I3e80326268008e6beaf74389bb32c01050406a81 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4434155 Commit-Queue: Joey Arhar <[email protected]> Commit-Queue: Xiaocheng Hu <[email protected]> Reviewed-by: Joey Arhar <[email protected]> Code-Coverage: Findit <[email protected]> Auto-Submit: Xiaocheng Hu <[email protected]> Cr-Commit-Position: refs/heads/main@{#1131479}
…r attribute changes, a=testonly Automatic update from web-platform-tests [anchor-position] Update layout on anchor attribute changes This patch also adds WPTs for the anchor attribute (without popovers) to support the HTML PR whatwg/html#9144 Fixed: 1432016 Change-Id: I3e80326268008e6beaf74389bb32c01050406a81 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4434155 Commit-Queue: Joey Arhar <[email protected]> Commit-Queue: Xiaocheng Hu <[email protected]> Reviewed-by: Joey Arhar <[email protected]> Code-Coverage: Findit <[email protected]> Auto-Submit: Xiaocheng Hu <[email protected]> Cr-Commit-Position: refs/heads/main@{#1131479} -- wpt-commits: db5d9506cb37895b200037877628911afd3fac14 wpt-pr: 39576
Before looking at this I'd like to see
topic: popover
|
I've moved my previous comment to #9311. |
@annevk I'm not sure I understand why this work is blocking on popover. Although popover is one place anchor would be useful, of course, it's not the only scenario - and it seems like popover's needs are addressed here. What is the scope of your concern for what needs to be investigated before anchor work can proceed? |
@josepharhar @tabatkins My initial thought looking at this is whether we can leverage presentation hints in some way instead of an "implicit anchor element", while still making it work conveniently for developers. The idea behind this seems fine to me though. |
@cwilso my concern is that popover landed in the standard with lots of issues that need to be addressed and it's been taking quite a long time for them to be addressed. That makes me uncomfortable about new features. |
I'm not sure how that would be possible. Without an implicit anchor element, you need a named anchor element, which means that, assuming we could craft an appropriate selector (not certain that's true, haven't thought about it enough) we'd have to reserve a name just for this use-case. And an element can only have one anchor name, so it would conflict with authors using an anchor name on the element for other purposes. (Even if we change to allow multiple anchor names, which there's an open issue about, we'd still conflict since CSS has never gained a way to add to a list.) So I don't think it's possible to do this, no. Skipping past the feasibility, tho, can I ask why you want to do this? If there's a particular reason you want to lean on presentational hints instead, I'd like to know in case it impacts other things architecturally. |
We want to ship this soon in chrome along with CSS anchor positioning so they can be used together. |
Fix the backlinks to the attribute definitions, which has the effect of causing the attribute definitions to show up in the input and button element definitions. (The newlines here are, unfortunately, important.) Also make popovertarget use the same "ID*" value space as other ID-accepting elements, as noted in #9144 (comment).
Hearing no further suggestions after my comment above, other than one comment supporting the addition of an attribute, I'd like to Agenda+ this once more to discuss. Of the listed options in my comment, my preference is still to add an explicit attribute like I'm very open to bikeshedding the attribute name to be more clear and avoid potential confusion around whether |
I had a think on this and it dawned on me that this is currently the only way to do cross root anchoring (other than exposing a part and setting anchor name inside of that from the host). This kinda of cross root element reference is incredibly limited for reasons I'm not entirely sure of, but it does work. For that reason alone I think this is useful. |
That's right. To be a complete cross-root solution, reference targets needs to also land. But yeah that's another reason to want this attribute. |
Discussing this with colleagues our main concern is that this attribute appears to be entirely presentational. We don't think we should be adding new presentational attributes to HTML. |
It's kind of a layering violation. The platform has generally moved in the other direction (making html element names not meaningful for styling, via UA style sheet, and attributes syntax sugar for CSS, via attribute mapping). My preference would be to at least make clear in the name that CSS overrides it... I'm also curious about @jwatt's and @fantasai's opinion on this. |
Hah, I mid-aired with Anne of course :) |
Just to summarize, here are the non-presentational rationales for this attribute:
What about the changes to the At least this isn't a traditional presentational attribute, because it needs to affect the style of the anchor element in addition to itself.
Certainly there are idref relationships for other things like
I'm totally supportive of renaming it. I proposed
Me too. The entire implicit anchor element concept was minted for this HTML attribute. |
It seems we could accomplish the implicit anchor aspect of #9144 (comment) without a new attribute. By exposing the relationship between the activating element and the popover to CSS. I suspect we also have to expose that to AT and w3c/html-aam#481 seems to back that up. (Which by the way is a problem we need to avoid going forward. We should not land new markup features without the a11y side being ready.)
Can you clarify what it does when we leave layout out of it? |
Mason's two points about anchoring across shadow boundaries and changing the topmost popover ancestor algorithm leave layout out of it, right?
If we can't have the anchor attribute, then I suppose it would be nice to automatically anchor position popovers to their invoker buttons but I wonder if that would be too much of a breaking change now that we have interop with popovers.
Should anchor positioning make AT changes when only used in CSS without the anchor attribute? If not I imagine this attribute would be great for that. |
The HTML attribute for anchor positioning was just discussed again at the CSSWG F2F: w3c/csswg-drafts#9356 (comment) The desire for this attribute was re-iterated in that conversation. Also, another (non-layout) reason for the attribute was found: it could be used to fix up sequential focus navigation order in the case that an anchored element wants to come after (or before) the anchor element in focus order. Similar to how Popover works, but for the case where popovers aren't desired. |
Both of those points are presentational. They're all about how anchor positioning hooks up two elements together for layout, and not anything about what it means otherwise. I'm not saying that we don't need markup to represent anchoring. But that markup needs to be about the semantics of anchoring, not about its layout. So consider these cases:
The first two use CSS anchor positioning. The first and last (but not the middle) need HTML anchoring of some kind. This proposal doesn't address HTML's need for anchoring. It's only about presentation. To answer HTML's needs for anchoring it needs to address:
|
The fact that CSS would override this means that we should either look at CSS for the aria semantics, or make the priority the other way around instead, somehow? |
@emilio Mmm, no, like I said in #9144 (comment), there are cases where the CSS and HTML anchoring should match, and cases where it shouldn't. So CSS shouldn't override, it should just take the HTML anchoring relationship in as a default. We just need to make sure that for cases where authors should provide those semantics in HTML rather than CSS, that they're able to do so conveniently enough that they will actually do it in the HTML. |
Rough cut of the minutes (Dael will post the final version) at https://www.w3.org/2024/06/27-css-minutes.html#t02
|
This comment was marked as spam.
This comment was marked as spam.
Hi Team What is the current status of this feature ? Thanks |
We will get a spec PR put together for these two, soon. I've gotten started on prototyping these in Chrome.
This one comes back to your comment from above:
Isn’t this use case also semantic? I.e. “New!” is semantically connected to the shopping item. It describes the item as being “new”. Right?
Can you give an example of this case? I’m having a hard time visualizing an example.
@scottaohara or @aleventhal, any thoughts on this question?
To clarify, “before” or “after” mean just semantically (and perhaps focus order), but not presentationally, right? I.e. anchor positioning handles where it physically goes, e.g. via Separate from that, can you please give an example of an anchored element that should come semantically before its anchor? All of the examples I can think of seem semantically “after”.
For anchored elements that come “after” their anchor element, it would seem that they should be immediately next in focus and reading order, akin to how popover invokers act as focus navigation scope owners. This relationship would be a bit more difficult to implement, given that the relationship goes the other way (attribute pointing from anchored element to anchor element), but it seems solvable. It also raises questions in the case that there are multiple elements all anchored to a single anchor. Likely those could be resolved also. One difficulty that I don’t know how to solve is the “before” case. The focus navigation scope owner concept is what popovers currently use to make the popover come “just after” its triggering element, and that works well. But I’m not sure how to do the reverse - have the anchored element come just before. The natural way would be for the anchored element to be a scope owner, which owns the anchor element. But that actually means the anchor element moves in the focus order, to come just after the anchored element. They’re in the right order relative to each other, but likely not in the right order relative to the rest of the document. Additionally, the case where there are multiple anchored elements gets really tricky - I think only one of them can own the anchor element. Any ideas for how to spec/implement this? This is why I asked above about actual use cases for "before" - it might help us understand how it should work.
This is a good question: I think as long as it’s as simple as an idref, the answer is likely “yes”. I’ve already tried to reach for this concept in internal implementations of elements such as
Good question. I think the answer should be “yes”, but I think that depends on the complexity of the feature. If it’s just |
The anchor attribute can be used to set up CSS anchor positioning by setting an implicit anchor element: https://drafts.csswg.org/css-anchor-1/#implicit-anchor-element.
The CSS properties used to set up anchor positioning relationships are perfect for repeating patterns, such as:
However, for structural patterns, such as when using a Popover, an HTML attribute has less boilerplate and makes the relationship much more directly observable:
This structural pattern can apply to other use cases also, where unique elements are paired.
When used with the Popover API, the
anchor
attribute also naturally helps to create a relationship that ensures popovers are properly nested:This PR adds the
anchor
attribute to HTML and connects it to the Popover API./dom.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/popover.html ( diff )
/references.html ( diff )
/rendering.html ( diff )