Re: [csswg-drafts] [css-anchor-position-1][css-display-4] Anchor Positioning and Display Order (#9356)

The CSS Working Group just discussed `[css-anchor-position-1][css-display-4] Anchor Positioning and Display Order`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> kizu: I noticed sometimes we might want to only change behavior from one anchor element to another<br>
&lt;una> q+<br>
&lt;emeyer> …Mostly for cases like side notes and other things that are not covered by the popover API<br>
&lt;emeyer> …Given the API probably handles the most common cases, this may not be so pressing, but in a reading-order future, we might want to allow authors to make changes<br>
&lt;astearns> ack una<br>
&lt;TabAtkins> q+<br>
&lt;emeyer> una: I agree that with popovers you're covering tab-navigation as expected<br>
&lt;emeyer> …I agree we do need an implicit anchor relationship<br>
&lt;emeyer> …This feels like an HTML thing<br>
&lt;emeyer> …You also have other examples in that post that show the need<br>
&lt;emeyer> …I think an anchor attribute would be best<br>
&lt;astearns> ack TabAtkins<br>
&lt;emeyer> TabAtkins: Agreed; my major objection here is that anchoring can be used for lots of things and we can't reliably determine a relationship<br>
&lt;emeyer> …That's a complex and manual enough example that I don't think we can do this reliably<br>
&lt;emeyer> …Good announcement behavior is important<br>
&lt;masonf> q+<br>
&lt;emeyer> …The HTML AAM opened their own issue on this, and they're talking about how to bridge with us<br>
&lt;emeyer> …My proposal is that for the anchor positioning spec, we close with not changes but we keep working with other groups to figure out the solution, which is needed<br>
&lt;astearns> ack fantasai<br>
&lt;emeyer> fantasai: Agree with Una that this will need markup support, and it should be something in the HTML<br>
&lt;emeyer> …The control is going to need to invoke a bunch of accessibility bindings<br>
&lt;TabAtkins> And then if there's an anchor attribute, that'll establish the "implicit anchor element" for anchor post, which'll mean authors don't have to repeat themselves in CSS<br>
&lt;emeyer> …But I don't think ARIA is the right approach, even though we'll rely on it underneath whatever markup there is<br>
&lt;una> q+<br>
&lt;emeyer> …If we want authors to be able to use these, it should be sufficient that they'd be willing to use it instead of CSS<br>
&lt;astearns> ack masonf<br>
&lt;emeyer> …We shouldn't change things now, but I think we should keep this open until we get the information on what will be used so we can put it in the spec<br>
&lt;fantasai> s/sufficient/sufficiently convenient/<br>
&lt;emeyer> masonf: +1 to HTML markup, like popover does<br>
&lt;fantasai> s/change things now/change the spec normatively/<br>
&lt;emeyer> …Switching tab ordering between layout order and DOM order is trickier than it sounds<br>
&lt;emeyer> …There has been some pushback on the anchor attribute in general, so we might want to bring this up with the WHAT WG<br>
&lt;astearns> ack una<br>
&lt;fantasai> s/instead of CSS/instead of CSS. For example, in CSS we have the ability to scope patterns so that you don't have to create unique identifiers for every instance of a repeated pattern; that needs to be available in HTML also/<br>
&lt;emeyer> una: There's new reasoning to have the anchor attribute<br>
&lt;emeyer> …I really think something like popover feels like the most seamless solution<br>
&lt;fantasai> s/should be something in the HTML/should be something in the HTML. And also should allow anchoring either before or after the element./<br>
&lt;emeyer> …Handling multiple anchors like on Wikipedia is super annoying to do solely throught CSS<br>
&lt;astearns> ack fantasai<br>
&lt;emeyer> fantasai: I think the anchor attribute as currently specced is not going to be enough<br>
&lt;emeyer> …It only works with IDs, for example<br>
&lt;emeyer> …So dealing with repeated patterns on a single page doesn't work<br>
&lt;emeyer> …It also needs to be able to anchor an element before or after the element<br>
&lt;emeyer> …The current proposal doesn't hook into accessibility bindings, so it will have to do that<br>
&lt;emeyer> una: In the authoring process, if they have a new tooltip it will probably get a new ID, so I don't think having to do that here would be a major barrier for authors<br>
&lt;emeyer> fantasai: If CSS is significantly more convenient, then they'll use that<br>
&lt;emeyer> …Right now they do it because there are no other options<br>
&lt;fantasai> s/do it/use IDs/<br>
&lt;emeyer> …We just need to design a syntax so we can extend in that direction<br>
&lt;emeyer> astearns: Soundsl ike we're going to keep this issue open, but for now will pursue a markup-based solution that can hit all the issues raised here<br>
&lt;emeyer> astearns: Moving on…<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9356#issuecomment-2160157237 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 11 June 2024 08:52:05 UTC