- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 18:35:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-align][css-position][css-anchor-position] Introduce "document containing block" for some purposes?`, and agreed to the following: * `RESOLVED: Adopt the concept of document containing block (better name TBD) into position-4 and have anchor positioning use it by default instead of ICB` * `RESOLVED: Publish FPWD of position-4` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: Anchor positioning exposes details of the containg block a lot more than abspos did<br> <kbabbitt> ...generally this works just fine, inset-area cares about how it's positioned relative to cb<br> <kbabbitt> ...or if it's outside, it's an exceptional case and is also handled fine<br> <kbabbitt> ...exception is when you're fixpos, because then you end up using the ICB which while is reasonably sized, is not a reasonably positioned rect<br> <kbabbitt> ...ICB just sits at the top of the document<br> <fantasai> scribe+<br> <kbabbitt> ...and most of the document is outside of that rectangle<br> <kbabbitt> ...which means that almost all of your acnhors need the exceptional behavior of anchor outside of CB<br> <kbabbitt> ...while we have as reasonable as we can behavior, it's not ideal<br> <kbabbitt> ...all an error case and always recovering<br> <kbabbitt> ....all you really want for something like an element acnhored to something far down is to avoid flowing outside the bounds of the doc<br> <kbabbitt> ...e.g. offscreen<br> <kbabbitt> ...and that doesn't work well in the case we have here<br> <kbabbitt> ...what you want is a CB that is the size of the visible document<br> <kbabbitt> ...what that means is part of this issue<br> <kbabbitt> ...My proposal is that this sort of request is useful outside of anchor positioning<br> <kbabbitt> ...relatively common for people within a scrollable area to position in the bottom right area of ths scrollable content<br> <kbabbitt> ...can't do that today wiothout an additional wrapper<br> <kbabbitt> ...if you go to the bottom right with insets and it positions you in th ebottom right of the scroll container not the scrollable content<br> <kbabbitt> ....people work around that today by using a replos wrapper around all of their scrollable content<br> <kbabbitt> ...so their abospos can go to the bottom right of the scroll container<br> <kbabbitt> ...making this behavior easier to opt into, and making anchor positioning generally work better when your CB is the document is worth fixing<br> <kbabbitt> ...my proposal is that we have a new concept: the document containing block<br> <kbabbitt> ...which is a rectangle size to contain all the stuff in the document<br> <kbabbitt> ...we use that by default for anchor position ing if we would use the ICB<br> <kbabbitt> ...also have some way to explicitly opt normal abspos into being able to reference this concept both for document and for any scrollable content<br> <kbabbitt> ...two big questions: first what is this rectangle, how do you define it in a way that's reasonbly chjeap<br> <kbabbitt> ...iank_ has an answer that works in Chrome and sounds approximately right<br> <kbabbitt> ...don't know how generalizable that is<br> <Rossen0> q+<br> <kbabbitt> iank_: when you calculate the scrollable overflow for a scroll container<br> <kbabbitt> ...you need to know where the end ? is<br> <kbabbitt> ...and that's one of the calculations that goes into the whole scrollable area<br> <kbabbitt> ...e.g. for grid this is defined as the end of the grid<br> <kbabbitt> ...this is relatively cheap, the calculation is only based on the in-flow children at that point<br> <emilio> q+<br> <kbabbitt> ...w/o transforms, usually what people wnat for this calculation<br> <kbabbitt> TabAtkins:: other questio would be how we can let normal abposes opt into it<br> <kbabbitt> ...probably a position subproperty, don't want to solve for it now, can still devault anchor positioning to right default today<br> <kbabbitt> Rossen0: I missed the reasoning about, does top line get redefined as well?<br> <miriam> q+<br> <kbabbitt> ...so that when you scroll, that positioned element also gets scrolled with it?<br> <kbabbitt> TabAtkins: No, the DCB will start still at the top left of the entire ducoument just like ICB, will just grow downward and rightward to contain entire contents of the page<br> <kbabbitt> iank_: not growing into negative space beyond the scrollable region<br> <kbabbitt> ...there are cases .eg in rtl container where right would stay 0 and flips like that<br> <Rossen0> ack Rossen0<br> <Rossen0> ack fantasai<br> <kbabbitt> fantasai: curious about the definition in the inline axis<br> <kbabbitt> ...this totally makes sense, we probably want a similar concept for non-document scrollers<br> <kbabbitt> ...agree with most of what you're trying to do here<br> <kbabbitt> iank_: easiest thing is unify behavior when we fixed the end point for the scrollable behavior<br> <kbabbitt> TabAtkins: I'm calling it DCB, need a better name<br> <kbabbitt> ...intend it applies equally to other scrollers, if your anchor is inside a scroller you want same behavior<br> <miriam> q- (I was going to ask about applying to other scrollers)<br> <miriam> q-<br> <kbabbitt> fantasai: you're suggesting for inline axis we calculate padding ??? I agree with that<br> <Rossen0> q?<br> <Rossen0> Rossen<br> <kbabbitt> ...have to think about exactly where else it would be used, using it for anchor positioning seems reasonable<br> <Rossen0> ack Rossen<br> <kbabbitt> iank_: when I as doing webdev stuff, I ran into this problem constantly<br> <flackr> +1<br> <kbabbitt> emilio: agree this a good thing in general<br> <kbabbitt> ...esp when you get into edge cases e.g. rtl<br> <kbabbitt> ...having something that consistentl covers scrollable areas gets tricky<br> <fantasai> s/we calculate padding ???/we use the point where we attach the inline padding?/<br> <kbabbitt> ...2 questions, one: with regards to scrollable padding we add, you mean that CB would be included or excluded?<br> <kbabbitt> iank_: included<br> <kbabbitt> emilio: so it would cover everything, sounds good<br> <kbabbitt> iank_: we're not changing the fact that abspose references padding box by default<br> <Rossen0> q+<br> <kbabbitt> fantasai: any box that is scrollable when it gerneates a CB, genreates 2 CBs, inner and outer<br> <Rossen0> ack emilio<br> <kbabbitt> ...I guess it generates 3, you have the content one too<br> <kbabbitt> emilio: if you have something that overflows that cb, you have something that scrolls down<br> <Rossen4> q?<br> <kbabbitt> iank_: the reason the padding edge definition is useful is, you don't need to calculate the entire scrollable area<br> <kbabbitt> iank_: based on flow content this is where the padding edge is, then you run abspos layout<br> <kbabbitt> iank_: then you gather up scrollable area<br> <kbabbitt> fantasai: this comes from when we decided to add padding to scrollable ??? ... it only considers input<br> <TabAtkins> s/input/in-flow content/<br> <kbabbitt> emilio: sounds good<br> <fantasai> s/???/area/<br> <kbabbitt> iank_: that ? is also nice because it doesn't consider transforms<br> <TabAtkins> s/?/box/<br> <kbabbitt> emilio: wonder if there are use cases like, I want to ? the whole scrollbar<br> <kbabbitt> iank_: [missed]<br> <Rossen4> ack fantasai<br> <Rossen4> ack Rossen<br> <kbabbitt> fantasai: we've got each box generates 3 CBs, inflow CB which is content area, local CB which is this padding edge that takes over the area that scrolls, then outer CB which is the background attachment scroll box<br> <kbabbitt> ...we need better terms for these<br> <kbabbitt> ...in your comment you suggested position area would be one way to capture this entire area<br> <kbabbitt> ...that reads really well<br> <kbabbitt> ...issue says only when there's a valid anchor<br> <kbabbitt> ...do we make position area do it always since it doesnt rely on anchor><br> <kbabbitt> TabAtkins: potentially. I feel like that's a bit hacky and probably wnat CB control to be done via a more focused properly, more things in that vein you want to select between<br> <kbabbitt> ...somewhat uninclined to fix things in this hacky way but could be convinced in another issue<br> <kbabbitt> fantasai: making it contidional on the validity of anchor is a little weird<br> <kbabbitt> ...making it not that would be great, I have a few ideas<br> <kbabbitt> Rossen4: the position area bounds you define is based on the static content only but it doesn't include any abspos content?<br> <kbabbitt> TabAtkins: correct, no abspos no transforms<br> <fantasai> I'm thinking maybe `position-area` always applies, it's just that if you have no valid anchor then you always get the entire area<br> <kbabbitt> Rossen4: what about relative<br> <kbabbitt> <crosstalk><br> <kbabbitt> iank_: it does not include relative<br> <kbabbitt> iank_: when it comes to adding padding to scrollable end, we have basically alignment on that<br> <TabAtkins> q?<br> <kbabbitt> Rossen4: sounds like a very useful feature<br> <kbabbitt> TabAtkins: suggest resolution: Adopt the concept of document containing block (better name TBD) into position-4 and have anchor positioning use it by default instead of ICB<br> <kbabbitt> Rossen4: additional comments or objections?<br> <flackr> +1<br> <kbabbitt> fantasai: we should proably actually publish position-4<br> <kbabbitt> RESOLVED: Adopt the concept of document containing block (better name TBD) into position-4 and have anchor positioning use it by default instead of ICB<br> <kbabbitt> [discussion about contents of position-4]<br> <kbabbitt> Rossen4: any objection on publishing FPWD of position-4?<br> <kbabbitt> RESOLVED: Publish FPWD of position-4<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10861#issuecomment-2379849260 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 18:35:53 UTC