Re: [css-position-3] Rewrite Completed

On 4/29/20 1:28 AM, Florian Rivoal wrote:
> 
>  From an editorial standpoint, I like it a lot. Well done! For a correctness standpoint, it looks right on a first read, but we all should certainly spend some time looking at it closely; some of this is very subtle.
> 
> Here are a few comments/suggestions, all in one place for now, in case you find a number of them easy to just fix without further debate, but for anything you think needs substantial discussion, I'm happy to move to github.
> 
> * Throughout the document, linkify "out of flow"

Filed https://github.com/w3c/csswg-drafts/issues/5027

> * in the definition of sticky positioning, there's "in whichever axes the inset properties are not both auto". Negated conjunctions are confusing, and sticky positioning isn't easy. Maybe just skip that part of the sentence, and defer details to the later section on sticky positioning instead of providing a terse but hard to grok summary.

Authors shouldn't need to read past the value definition to have a basic sense 
of what it does, so I don't think removing it is appropriate...

> * I think that "fixed positioning containing block" is new terminology. It seems to me that css-contain (level 2) should be updated to use it, and maybe there could be a note in css-positioning pointing to layout and paint containment.

It's a new term, as is "absolute positioning containing block". It exists so 
specs like css-contain and css-transform can hook into it without redefining 
what it means.

> I don't recall anything else creating "fixed positioning containing block", but if there's such a thing, it'd be nice to mention it in that note as well.

Added.

> * Section 3.4 on sticky positioning is really dense. It looks right, but I found this to be the part of the document I had to re-read the most to convince myself I understood what it meant. I don't have any particular advice as to how to make it better just yet, but I think we should try to improve it some more, because as it is, it's hard. Until something more profound, a couple of minor tweaks:
>    - within that section, linkify "scrollport"

They're all linked, we have to wait for the cross-referencing system to 
bootstrap...

>    - "then the effective end-edge inset in the affected axis is reduced<ins>, possibly becoming negative if necessary,</ins> to bring the sticky view rectangle’s size up to the size of the border box in that axis"

Added.

> * In section 3.5 on absolute positioning:
>    - a couple of things aren't cross-linking properly: "self-start", "self-end"

No idea why.

>    - "then the weaker inset in the affected axis is reduced<ins>, possibly becoming negative if necessary,</ins> to bring that size up to zero."

Added.

> * In section 3.6 on Fixed positioning: unlike the definition of fixed positioning in 2 and 2.1, this does not use the " fixed positioning containing block" term, and just directly talks about the viewport and the page area. It should use that term, and say that  viewport and the page area are the "fixed positioning containing block", unless some closer ancestor of the positioned element establishes another one (which css-contain can do). It could be worth accompanying that with a note that very few things establish one of those, so it's almost always the viewport/page area.

Ah, yeah, this bit needs fixing. Fixed separately.

> * In section 6, linkify "absolute positioning" in the first sentence

Fixed.

> * This spec used to speak more of floats, and this latest revision doesn't anymore, except in section 2 and 5 to define the interaction between the float, display, and position properties, and in 3.5.1. to talk about resolving automatic insets. That's good, as this isn't a float spec. But then it feels like section 6.3 which gives a generic example about floats and clearance, without any interaction with positioning, is out of place, and should be removed as well.

The entire section is lifted out of CSS2 and we didn't really bother to change 
anything about it. I get your point about scope, but also I don't think it 
would be as effective if it were not comparing all three, so unless you have a 
better solution I'm going to leave it here for now.

~fantasai

Received on Wednesday, 29 April 2020 23:19:22 UTC