Re: [csswg-drafts] [css-anchor-position-?] Add a ::tether pseudo-element (#9271)

The CSS Working Group just discussed `[css-anchor-position-?] Add a ::tether pseudo-element`, and agreed to the following:

* `RESOLVED: mark ::tether as at risk and leave note in the draft`

<details><summary>The full IRC log of that discussion</summary>
&lt;bramus> TabAtkins: we had an issue about a way to style an arrow in response to abspos relative to anchor. this was more explicty in apple’s proposal with ::tether<br>
&lt;bramus> … this is a great idea.<br>
&lt;bramus> … having a border around the whole box + arrow seems like a need<br>
&lt;bramus> … but also very difficult<br>
&lt;bramus> … proposal to move to level 2<br>
&lt;bramus> … apple’s proposal had good &lt;missed><br>
&lt;bramus> … to be clear it’s the styling, not the position<br>
&lt;bramus> … this might block us now, so like to push it furhter down the future<br>
&lt;bramus> astearns: are you talking about deferrint he styling or the ::tether allogehter?<br>
&lt;bramus> TabAtkins: the ::tether alltogehter. styling is essential and i think we need to get right<br>
&lt;florian> q+<br>
&lt;astearns> ack fantasai<br>
&lt;bramus> fantasai: curious to hear you expand a bit about styling that needs to be worked out<br>
&lt;astearns> for tooltips the tether (whether you can style it or not) seems pretty important<br>
&lt;bramus> TabAtkins: simple case: abspos is  a solid bg with no border.tether is a triangle with same color. that is easy.<br>
&lt;bramus> … you might need to to a little bit of neg margin<br>
&lt;bramus> … hard part is a border or border-radius. getting tether to integrate with those and having border flow with it and not visibly be underneath it is hard to solve<br>
&lt;bramus> … and people want to do that based on existing example<br>
&lt;bramus> … also see examples outside of the web<br>
&lt;fremy> q+<br>
&lt;bramus> … i want to make sure we can handle that or recognize that we cant<br>
&lt;florian> q- later<br>
&lt;bramus> … border is the one that really bothers me. e.g non-linear border around anchor en tether<br>
&lt;bramus> fantasai: you can hack with drop shadows<br>
&lt;bramus> TabAtkins: a little bit<br>
&lt;bramus> fantasai: but i would like to do better<br>
&lt;bramus> … you can get pretty far with drop shadow, but do undrstand concern<br>
&lt;bramus> TabAtkins: potentially<br>
&lt;bramus> … needs more time to bake, and dont want to delete rest of the spec<br>
&lt;florian> q- later<br>
&lt;fantasai> s/delete/hold up/<br>
&lt;astearns> ack fremy<br>
&lt;kizu> q+<br>
&lt;bramus> fremy: similar question. i have impression that implementin tether itself is not a lot of work and will solve a lot of cases<br>
&lt;bramus> … maybe needs some trickery, but most cases it would solve the problem<br>
&lt;bramus> … you *want* a tether<br>
&lt;bramus> … do you really believe we need to defer, tab?<br>
&lt;bramus> … or do you believe it is too much effort?<br>
&lt;bramus> TabAtkins: if one feature takes a lot more work than rest of spec … don’t like to add things that will delay baking time<br>
&lt;bramus> … there are rendering concerns. As much as possible i would like tether to do right thing for authors and not give them a bad result to be angry about<br>
&lt;bramus> … we need a resonable rendering result with the styles in the UA. common cases should work out of the box<br>
&lt;bramus> …if we put it in L2 and do find it easy to solve, happy to pull it back into L1<br>
&lt;astearns> ack florian<br>
&lt;bramus> florian: I think agree with tab that this has extra complexity that will take time<br>
&lt;bramus> … but i don’t think we are at that point to go to CR yet, so seems premature to push it back now<br>
&lt;bramus> … even if incomplete, we should work together with the rest<br>
&lt;bramus> … as we evolve the spec, we should keep working with it<br>
&lt;fantasai> s/rest/rest, to ensure it all integrates together properly<br>
&lt;fantasai> +100 florian<br>
&lt;bramus> … my recommendatoin would be to keep it in for now with the understanding that impls might not start there and do the rest first, and spec wise it is not unlikely that we would evntually push it to L2<br>
&lt;astearns> we have a process for at-risk things<br>
&lt;bramus> kizu: other concerns outsid eof border issues<br>
&lt;bramus> … how to position it in more edge cases<br>
&lt;bramus> … is ok when position on TRBL<br>
&lt;bramus> … but on corners it is much more cmoplicated<br>
&lt;florian> s/we should keep working with it/we should keep working with it together with the rest, to make sure that the model stays coherent/<br>
&lt;bramus> … e.g. what if element is completely over other element? where to draw the tether and how to show it (pointing to left or right)<br>
&lt;bramus> … also depends on how we do fallback and conditional styling<br>
&lt;bramus> … tether with conditions maybe?<br>
&lt;bramus> … would be happy with basic implementation in L1 to be able to play with it<br>
&lt;astearns> q?<br>
&lt;bramus> … but lot of small issues –its a complicated topic<br>
&lt;astearns> ack kizu<br>
&lt;bramus> fantasai: agree with florian on keeping it in L1 that it helps us think about how it works with rest of styling model, e.g. fallback model<br>
&lt;TabAtkins> q+<br>
&lt;bramus> … how would that work with tether.<br>
&lt;astearns> ack TabAtkins<br>
&lt;bramus> … dont want to defer to L2, even if florian says it might end up there<br>
&lt;bramus> TabAtkins: I realize I am hypocretical at this as I dont like 2 levels of ED. Fine to not put it in L2, but want to mark it as risk in L1 saying that it is *super experimental*<br>
&lt;florian> seems fine to me<br>
&lt;bramus> proposed resolution: mark ::tether as at risk and leave not in the draft<br>
&lt;bramus> astearns: proposed resolution: mark ::tether as at risk and leave not in the draft<br>
&lt;florian> s/not in/note in/<br>
&lt;bramus> RESOLVED: mark ::tether as at risk and leave note in the draft<br>
</details>


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


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

Received on Friday, 15 September 2023 16:30:10 UTC