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 <[email protected]> =
wrote:
>=20
>> * 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.
>=20
> 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/c11da77a4b7a7c4b0e43011dc4b11e0=
0e0213f6e

>> * 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"
>=20
> 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/f2e24e66c9eb77de99f10058d19ea66=
27c2ce39a


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

Should be good now: =
https://github.com/w3c/csswg-drafts/commit/f3e5bddc5cccf3771f0db0ec97efdc2=
a2592ff9d

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=3D"<self-position>, <content-position>">flex-start</dfn>
to
> <dfn for=3D"<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.
>=20
> 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.
>=20
> 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.

=E2=80=94Florian=