Re: [csswg-drafts] [css-anchor-position] position-try: inset-area() does not reflect CSSWG resolution (#10320)

The CSS Working Group just discussed `[css-anchor-position] position-try: inset-area() does not reflect CSSWG resolution`, and agreed to the following:

* `RESOLVED: position-try: none | [ [<dashed-ident> || <try-tactic>] | <'inset-area'> ]# i.e. remove the inset-area()`

<details><summary>The full IRC log of that discussion</summary>
&lt;keithamus> fantasai: when we discussed position-try proposal we talked about inlining inset area syntax in the list of things to try<br>
&lt;keithamus> ... for a lot of simpler cases you only need to set inset area<br>
&lt;keithamus> ... you wouldnt need a position try rule and manage namespacing etc<br>
&lt;keithamus> ... edited in the spec is a new inset-area function<br>
&lt;keithamus> ... not generally how we pull syntax from one area into another<br>
&lt;keithamus> ... we've never created a function with a syntax that maps to that property<br>
&lt;keithamus> ... not necessary here<br>
&lt;TabAtkins> q+<br>
&lt;keithamus> ... I think the change should be reverted. inset-area value space should be in the position-try list as discussed when we resolved on this<br>
&lt;keithamus> TabAtkins: as I said in the issue - the precise syntax wasn't significantly discussed<br>
&lt;keithamus> ... it was introduced in an IRC comment. Not meaningfully picked over<br>
&lt;keithamus> ... the resolution was weak on syntax<br>
&lt;keithamus> ... editors have had similar leeway<br>
&lt;keithamus> fantasai: not really. if it's ambiguous you should come back to the WG<br>
&lt;keithamus> TabAtkins: in any case it was ambiguous so I found it not to be the most readable. I found a decent change we'd want to inline more stuff in the future<br>
&lt;Rossen4> ack TabAtkins<br>
&lt;keithamus> ... the syntax space might overlap with future extensions<br>
&lt;keithamus> ... so that with the readability right now... I thought the function made it much easier to understand<br>
&lt;keithamus> ... the function, dashed ident... three distinct syntaxes<br>
&lt;fantasai> position-try: top, bottom, left span-bottom, right span-bottom; seems perfectly readable to me<br>
&lt;keithamus> ... the flip keywords, the inset-area function, the dashed ident naming the position try block<br>
&lt;keithamus> ... I'm comfortable with other syntaxes, making it clear the inset-area keywords are specifying that. Maybe the keyword, or area, or whatever<br>
&lt;keithamus> ... I'd like something to indicate what the value is doing<br>
&lt;keithamus> fantasai: I think we haven't ever done this before. Inlining the syntax is perfectly reasonable<br>
&lt;keithamus> ... I'm not sure why listing a bunch of values is unreadable<br>
&lt;keithamus> ... they're not generally combined with the other aspects<br>
&lt;keithamus> ... if we want to intro alignment keywords later we can disambiguate<br>
&lt;keithamus> ... .e.g with a slash<br>
&lt;keithamus> ... this syntax is unprecidented. I'd prefer not to introduce it<br>
&lt;kizu> q+<br>
&lt;Rossen4> ack kizu<br>
&lt;keithamus> kizu: I think I incline towards fantasai's proposal. Later alignment with slash will sound better. Especially if we want to allow using these properties in the try block<br>
&lt;keithamus> ... if you have some specific case<br>
&lt;keithamus> ... new syntax that is unprecedented, authors could later think other properties could have the same thing<br>
&lt;keithamus> ... maybe a separate issue if we want to use it in more properties<br>
&lt;keithamus> TabAtkins: I can live with it<br>
&lt;TabAtkins> (I'm not sure what you mean by "allow in the try block" fwiw, kizu. inset-area *is* allowed in the try block<br>
&lt;TabAtkins> )<br>
&lt;fantasai> PROPOSED: position-try: none | [ [&lt;dashed-ident> || &lt;try-tactic>] | &lt;'inset-area'> ]# i.e. remove the inset-area()<br>
&lt;keithamus> RESOLVED: position-try: none | [ [&lt;dashed-ident> || &lt;try-tactic>] | &lt;'inset-area'> ]# i.e. remove the inset-area()<br>
&lt;kizu> (TabAtkins, I meant self-alignment properties, but I forgot that they're already allowed, yes)<br>
</details>


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


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

Received on Wednesday, 29 May 2024 17:03:00 UTC