- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jul 2024 16:47:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-anchor-position-1] Bikeshed name of `inset-area` ``, and agreed to the following: * `RESOLVED: Change inset-area back to position-area` <details><summary>The full IRC log of that discussion</summary> <flackr> ntim: right now anchor positioning has a property called inset-area. It's confusing as it suggests by it's prefex that you can't use this and inset at the same time but they're independent properties that can work together<br> <flackr> ntim: in some ways this is a property to pick the containing block, these usually have a position prefix. So I'd suggest position-area<br> <TabAtkins> q+<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to add a historical note<br> <kizu> +1 to position-area, not a strong one, but convinced by the arguments in the issue<br> <flackr> fantasai: When we first proposed it, it was called position-area. It was renamed to inset-area because it didn't use to contain the containing block, just the interpretation of auto on the properties so it was more closely tied to other inset properties<br> <astearns> ack TabAtkins<br> <flackr> fantasai: since then we've switched it back to changing containing block, so i agree it would make sense to rename back<br> <flackr> TabAtkins: I'm neutral on the name either way. I do still like inset-area as it's named because it occupies the same mental area as insets. Most of the time you won't use both because inset-area does most of what you need so having them in the same syntactic space seems nice<br> <flackr> TabAtkins: more broadly, because it's a value neutral rename, it's late enough in the spec lifecycle i'm happy to pushback on renames that don't hvae a clear value. I was happy to rename fallbacks but there are impls / tutorials that use the existing name. If there's no problem with the existing name would prefer not to change it<br> <flackr> astearns: prefer but not object?<br> <flackr> TabAtkins: lightly objecting, not formally<br> <flackr> TabAtkins: we've changed a lot of things where there was a good argument for it<br> <flackr> astearns: in terms of the timing, this was put on in may. The lateness was in part because we didn't get to it in a timely fashion<br> <flackr> TabAtkins: this was originally filed a few days after I2S after years of discussing the spec<br> <astearns> ack kizu<br> <flackr> kizu: I am more inclined for position-area. Thinking as an author it works as an inset, but many authors don't use insets for positioning things so there's no disconnection. Thinking about positioning something position-area is a good name and removes the connection to insets<br> <flackr> kizu: I was convinced by the arguments for position-area in the issue<br> <fantasai> Note, it wasn't years after discussing the spec -- the proposal for position-area (and inset-area) wasn't presented until about a year ago.<br> <flackr> astearns: with chair hat off, i also am convinced to change back to position-area<br> <flackr> jen: i think what matters most is developer ergonomics when someone is writing things so that they don't have to look things up<br> <flackr> jen: inset-area feels like an oddball compared to the other position properties<br> <TabAtkins> position-container + position-area both also seem to do very similar things (and they kinda do); the slight difference that the changed prefix brings might be a good thing.<br> <flackr> TabAtkins: I was saying the association with inset seems good to me, but seems fairly neutral either way<br> <flackr> TabAtkins: I'm merely pushing back on the grounds that it has been out for a while<br> <flackr> astearns: it sounds like others believe the reasons are strong enough to make the change<br> <ntim> q+<br> <flackr> TabAtkins: I will say there are many here who feel against making the change<br> <astearns> ack ntim<br> <flackr> ntim: the chrome team did say they would be okay making breaking changes even after shipping. This rename has developer experience benefit as jensimmons said and better describes what the property does, also implying inset can be used alongside it<br> <flackr> ntim: so i think this is a general improvement for dev exp<br> <ntim> q+<br> <flackr> TabAtkins: point of order, we promised we would be happy to make reasonable changes even if they are breaking, not any and all changes. We will still push back on changes that don't have a strong argument for them<br> <astearns> ack fantasai<br> <dbaron> Here's a list of breaking changes that are implemented or in progress in Chrome: https://groups.google.com/a/chromium.org/g/blink-dev/c/jGTYNuidPRs/m/4oY6JFVyBAAJ<br> <flackr> fantasai: 2 more spec things about the rename. 1. we should consider this in conjunction with position-try fallbacks. This takes inset-area directly into it. Sharing a common prefix helps associate them.<br> <fantasai> position-area: top left; position-try: bottom left, bottom,etc.<br> <flackr> fantasai: if that's inset area it's harder to associate that those represent the same idea<br> <miriam> q+<br> <ntim> q-<br> <flackr> fantasai: 2nd, if we do figure out shorthanding, having it prefixed with position sets us up better for this relationship<br> <astearns> ack miriam<br> <ntim> +1 to what fantasai said :)<br> <jensimmons> q+<br> <flackr> miriam: I'm unconvinced by some of the arguments, e.g. having inset as a prefix doesn't imply it can't be used with inset. But I find fantasai's argument convincing. It sounds worthwhile for this<br> <astearns> ack jensimmons<br> <ChrisL> fair point about no resolution on the earlier name change<br> <flackr> jensimmons: For process, is it too late to change the name if the name change isn't a certain amount of benefit? This was originally proposed as position-area. The name was changed when it was written into the spec but we didn't have a CSSWG resolution for the name change. Apple has repeatedly felt like we were being obnoxious about bikeshedding names to wait for things to mature, now we're circling back to say we still believe this is better<br> <flackr> astearns: any other comments?<br> <flackr> ntim: fantasai also reminded me why inset-area was chosen, becuase it was defined differently before, to change the computed value of insets. Now it doesn't so it's complementary to insets, not replacing them<br> <TabAtkins> I don't understand this argument - we have complementary properties both with and without common prefixes all the time.<br> <flackr> astearns: I think i'm hearing we should resolve on changing it back to position-area<br> <ChrisL> +1<br> <flackr> astearns: TabAtkins okay with resolving on this?<br> <flackr> TabAtkins: okay<br> <flackr> RESOLVED: Change inset-area back to position-area<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 July 2024 16:47:44 UTC