Re: [css-position-3] Rewrite Completed

Skipping the bits that had reached their conclusion in your mail (thanks), answering the rest inline.

> On Apr 30, 2020, at 8:19, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
>> * 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.

Done for css-contain: https://github.com/w3c/csswg-drafts/commit/c11da77a4b7a7c4b0e43011dc4b11e00e0213f6e

>> * 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...

Should get picked up now: https://github.com/w3c/csswg-drafts/commit/f2e24e66c9eb77de99f10058d19ea6627c2ce39a


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

Should be good now: https://github.com/w3c/csswg-drafts/commit/f3e5bddc5cccf3771f0db0ec97efdc2a2592ff9d

Alternatively (or in addition), if we want to avoid the same problem later in another spec, we could adjust the css-align spec from
> <dfn for="<self-position>, <content-position>">flex-start</dfn>
to
> <dfn for="<self-position>, <content-position>, justify-self, align-self,  justify-content, align-content">flex-start</dfn>
(and do the same for the other values)


>> * 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.

Did you mean "filed" rather than "fixed"? Either-way, I cannot find it.

>> * 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.

I am unconvinced confusion between positioning and floating is an actual problem people face often enough that it needs addressing, so I wouldn't miss this if it were gone. But no real objection to leaving it there either.

—Florian

Received on Thursday, 30 April 2020 07:21:18 UTC