[css-anchor-position] Default alignments for inset areas are wrong #10313
Comments
|
(Just to be clear, the first two bullet points (in the second group listed above) are current spec behavior; it's the third, covering span-* keywords, that's different.) It turns out that the Chrome impl already does what you're requesting, rather than what I wrote in the spec. I'm happy to update the spec to match; I agree it's better. Here's an example. (IIRC, the current behavior for a span-* value was written when anchor-center automatically "un-aligned" for overflow, which resulted in a similar behavior to what you're suggesting. I just didn't revisit this when the sliding behavior was deferred; it definitely needs to be changed.) Do you think we need a resolution for this, or are you okay with just an edit? |
|
I think a resolution would be helpful. This is a change for the better, but it's a change. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<emilio> fantasai: initial value for align/justify-self is normal<emilio> ... generally depends on context to an appropriate behavior <emilio> ... for inset-area we try to make the default alignment for the area useful <emilio> ... so if you're in the center track we center <emilio> ... if you're on the edge we align toward the area <emilio> ... if you're spanning into two tracks <emilio> ... and there the default is anchor-center, but that's generally not what you want <kizu> q+ <emilio> ... the usual thing is to align towards the track you're excluding <emilio> ... it's easy to center if needed <TabAtkins> q+ <astearns> ack kizu <emilio> kizu: tested r/n, I think it works well when the anchor is smaller than the positioned element <emilio> ... when the anchor is bigger it looks better with anchor-center <emilio> fantasai: typically in that case you keep aligned to one edge and overflow <emilio> kizu: can we define anchor-center to try not to shrink to the center area <emilio> ... only if it's not fitting shifted it'd work better <emilio> TabAtkins: tracked on a different issue <emilio> ... not on the agenda this week <astearns> ack TabAtkins <emilio> kizu: no objection then <emilio> TabAtkins: no objection from us either <emilio> ... what kizu described was the originally what I wanted <emilio> ... but I deferred the shifting <emilio> ... because I wanted to fix it more generally <emilio> ... so tldr agree with the change <emilio> ... also our impl actually matches that resolution because engineers misread the conditions <emilio> PROPOSED: If inset-area spans both of the tracks we'll align toward the missing track instead of centering <emilio> RESOLVED: If inset-area spans both of the tracks we'll align toward the missing track instead of centering <TabAtkins> s/both of the/two/ |
(I thought we had already edited this in, but apparently not...)
The current resolution of
normalalignment is defined as follows:anchor-centerend.But actually it should be:
This behavior for the double tracks gets you the correct behavior for more cases, and is easier to switch to the other common behavior (centering) because centering isn't conditional on which area you're in.
The text was updated successfully, but these errors were encountered: