- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 May 2024 16:18:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-anchor-position] `position-anchor` should be defined as a longhand of `position` ``, and agreed to the following: * `RESOLVED: Make position a shorthand of position-anchor and a new position-type property. The shorthand resets both.` <details><summary>The full IRC log of that discussion</summary> <flackr> fantasai: in earlier issue we renamed anchor-default to position-anchor, motivation was to allow position to be shorthand of this and poss other stuff later. We didn't resolve on short-handing relationship. Designing a syntax that accomodates everything can be deferred but we need to decide whether position reset it now<br> <florian> +1<br> <kizu> +1<br> <masonf> +1<br> <emilio> g+<br> <flackr> TabAtkins: sounds good, we don't have a strong opinion either way<br> <emilio> q+<br> <flackr> astearns: do we need a resolution for both the shorthand and that it reset?<br> <flackr> fantasai: yes<br> <flackr> emilio: It feels weird that if you had an anchored thing that is abs pos, and you want to make it fixed pos you now need to fight with the reset on position-anchor. Authors may find that confusing<br> <flackr> fantasai: the current values of static | absolute | fixed | etc should probably be their own longhand as well so you don't have to have that fight<br> <iank_> Modulo any compat constraints, shorthanding properties which have existing since the beginning of time a higher risk than others.<br> <flackr> fantasai: i.e. we'll have a longhand for those position values<br> <flackr> emilio: I think people will do position: fixed or position: absolute anyways without thinking that it reset but this is fine as a proper solution<br> <flackr> fantasai: our proposal for the longhand is position-type<br> <flackr> TabAtkins: it would be nice to have the additional longhands, i don't htink this blocks anything. It's slightly awkward but I think okay that you need to reset the anchor<br> <flackr> emilio: but you need to define the longhands?<br> <flackr> TabAtkins: not necessarily. Since it's reset only the other longhands don't need to exist<br> <flackr> fantasai: They do need to exist<br> <flackr> TabAtkins: right, internal property<br> <flackr> emilio: I don't think this works even if it is an internal property because shorthands aren't typically included in enumerations<br> <flackr> astearns: there might be a web compat risk?<br> <flackr> emilio: def<br> <flackr> TabAtkins: is that a general issue we would have with any properties becoming shorthands?<br> <flackr> emilio: we have the issue when it becomes a shorthand it stops getting enumerated and the longhands become enumerated. We don't have the issue that the longhand is hidden so you can't access the property<br> <flackr> s/can't access/ isn't enumerated<br> <flackr> TabAtkins: then i propose position-type<br> <flackr> fantasai: or position-style like text-wrap-style or list-style<br> <kizu> +1 to `position-type`<br> <flackr> florian: i like type better<br> <flackr> astearns: me too<br> <flackr> astearns: at this point, can we resolve on making position a shorthand of position-anchor and position-type?<br> <flackr> astearns: and then worry about the enumeration issues later<br> <flackr> emilio: I think this is fine. The big risk is someone enumerating styles and copying them over. If we have both longhands then it's not as much of a worry<br> <flackr> iank_: it's more of a risk for people manipulating styles directly. When the enumeration disappears they may be relying on position always being in the enumeration<br> <flackr> iank_: we've seen this before, most recently white-space, where people assume the property will read back the same as the property they set<br> <flackr> astearns: is this something where you would like to wait on the decision until we have a compat assessment? Would you object to a resolution?<br> <emilio> ack emilio<br> <flackr> iank_: taking a resolution is fine, but we might get regressions and have to revert and take another resolution<br> <astearns> ack fantasai<br> <flackr> iank_: shorthanding properties that have been around since time immemmorial carries risk<br> <flackr> fantasai: can we update the way we handle this to include shorthands in enumeration for these cases to avoid the problem?<br> <flackr> iank_: i think this may break things even more<br> <flackr> astearns: this might be worth opening another issues to discover whether the pitfalls are better or worse<br> <flackr> emilio: if you do this you get redundant properties. We could special case some legacy ones, but this is iffy. The order is lexicographical if you have cases where a shorthand shows up between longhands<br> <flackr> astearns: Okay, let's have a separate issue for enumerating shorthands, for this issue the proposed resolution is we make position a shorthand of position-anchor and a new position-type. The shorthand resets both<br> <flackr> fantasai: and we should add a shorthand syntax that's not resetting<br> <flackr> florian: but that's not urgent<br> <flackr> RESOLVED: Make position a shorthand of position-anchor and a new position-type property. The shorthand resets both.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10321#issuecomment-2112965730 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 May 2024 16:18:52 UTC