Meeting minutes
<oriol> Oriol Brufau, Igalia
<alisonmaher> Alison Maher, Microsoft
<florian> Florian Rivoal, Invited Expert
<matthieud> Matthieu Dubet, WebKit (Apple)
<rachelandrew> Rachel Andrew, Google Chrome
<astearns> Alan Stearns, Adobe
<iank_> Ian Kilpatrick, Google Chrome
<kbabbitt> Kevin Babbitt, Microsoft
<kizu> Roman Komarov, Invited Expert
<jarhar> Joey Arhar, Google Chrome
<ydaniv> Yehoatan Daniv, Wix
<futhark> Rune Lillesveen, Google
<bramus> Bramus, Google Chrome
Eric Meyer, Igalia
github-bot, take up 6900
<github-bot> emeyer, I can't comment on that because it doesn't look like a github issue to me.
<astearns> github-bot, take up w3c/
Republishing Tasks Permathread
<github-bot> OK, I'll post this discussion to https://
<TabAtkins> btw, I can hear Alan great, but not whoever else is talking right now
florian: Would like to republish css-contain-1
… When we maintain a rec as a rec and want to change but aren't sure if we're ready, we can put in informal notes about how we want to change it
… As these things mature, they fulfill all criteria and the notes come out
… We're at the point of those having been addressed
… There are three changes still proposed, which if we all agree to, we can reissue the rec
astearns: Any questions or comments?
… Proposed resolution: We request a updated recommendation, with the three proposed changes folded in
… No objections; we are resolved
<TabAtkins> I have no objections to the current order, if elika is happy with it
RESOLUTION: We request a updated recommendation, with the three proposed changes folded in
github-bot, take up w3c/
[css-anchor-1] position-visibility show/hide animations
<github-bot> OK, I'll post this discussion to https://
TabAtkins: While doing implementation work, Philip noted authors probably want to animate elements disappearing and reappearing
… How do we do it? Philip proposed properties for that
… My proposal is to have position visibility change the computed value, and key off of that to do transitions
… Either of these are potentially doable, but Roma has a comment just posted
kizu: The only thing I think we don't have is an entry animation
… There's no way to hook on to when that fires
TabAtkins: That's reasonable, and it points to a larger use case which is the ability to trigger an animation on a transition starting
… That seems generically useful for several cases and would avoid needing new properties
fantasai: Making that happen would let you control the flip point, but it won't give you the ability to animate things like color without JS
TabAtkins: Correct; doing more would require other things, but this seems like a big enough request for us to do
… I've thought about ways to trigger state properties and would be willing to defer animation in order to consider that, but I could see us doing this for properties now and considering the generic solution later
futhark: Isn't this quite simlar to the overlay property for popovers?
TabAtkins: The reason we mess with the overlay state is so it stays consistent across things that can't be described in the CSS
TabAtkins: Did we just trigger off a DOM state?
futhark: Yeah, but we don't have that possibility here
TabAtkins: I could go dig up my old notes, but do we want to defer this for a little while to make a more informed decision?
kizu: I think we can defer
bramus: Want to mention that a lot of authors have been aasking to trigger view transitions on a state change, such as clicking on an input
TabAtkins: Good point - we might be able to rely on subscribing to a transition, but that might be a frame delay
khush: Since you said it's a state transition, I was thinking of exposing it as a pseudo-class
… The only thing is, you dn't want anyone to put in a position change
TabAtkins: We can't generally do an allow/block list due to circular references, but you can certainly already cause those with :hover
… We consider that acceptable, so it would probably be okay to not restrict and assume authors won't do things that make the experience awful for their users
astearns: Sounds like we're going to defer for now, evaluate a more general solution, and decide if the general solution can be implemented in time
TabAtkins: Should we resolve to do visibility and leave them open as hooks for later?
fantasai: I think that's a good idea, but I'd want to ensure that will work with inheritance
<TabAtkins> s/do this/do the visibility:strongly-hidden thing/
fantasai: Probably want a better word than strongly hidden
TabAtkins: That sounds reasonable
TabAtkins: Proposing that when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value
<fantasai> "Making an element strongly hidden makes it act as if it and all of its descendants were visibility: hidden, regardless of what their actual visibility value is."
astearns: My question is: can authors use this force-hidden value?
ydaniv: If we have a value, we could do it with container style queries, right?
TabAtkins: Yes. I'm not super familiar with the limitations on style queries but it should still be available
kbabbitt: What's the interaction between this and !important on a descendant
<fantasai> container style queries query the parent of the element you're styling, so it's not quite ideal, but could do some stuff with it
TabAtkins: If your ancestor is force-hidden, you're force-hidden
… It's a display: none without blowing away the boxes
… So they still take up the space
fantasai: We might also want a value that keeps the boxes but takes them out of flow while not displaying them (more similar effect to display:none)
TabAtkins: Maybe
astearns: Anyone who would prefer to wait and digest before resolving?
<astearns> Proposing that when position visibility hides something, it does so by causing the visibility property to compute to a new forced-hidden value
<fantasai> "force-hidden"
astearns: RESOLVED: when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value
RESOLUTION: when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value
github-bot, take up w3c/
[css-anchor-position] Nailing down the position-try-options "flip" behavior
<github-bot> OK, I'll post this discussion to https://
<TabAtkins> https://
TabAtkins: Elika brought this up to bring it to WG attention
… As far as I know, this all is good and it works as expected in Chrome
… Happy to tweak as necessary if anything is wrong
fantasai: Do we flip the safe area sides on the env() function
… If you stick this into a `left` property, does it get flipped to the `right` property?
TabAtkins: Great question; right now, we already substitute variables and I think the answer is we substitute pre-flipping
… So what ever it resolves to on the left, it resolves to that and is flipped to the right
… This is what you want for vars, but for env() specifically, we could do something different if we need to
… I'm not certain what the ideal behavior would be, whether we want to do that before or after
… In general, env() is used fairly little, so we should be able to experiement and change if need be
astearns: Any other comments?
fantasai: I note that the margin properties are only mentioned in an example
TabAtkins: They don't need to be mentioned otherwise because it refers to the list of position-try properties and margins are on the list
astearns: Woiuld you like a resolution from the WG?
fantasai: Could or not, but I wanted to bring to the WG's attention that this is happening
astearns: So please take a look at this, and fantasai please look at where the swapping should happen
fantasai: I think it should happen before, but I'm not sure it's implementable
TabAtkins: We'll open another issue for that
github-bot, take up w3c/
[css-anchor-position-1][css-display-4] Anchor Positioning and Display Order
<github-bot> OK, I'll post this discussion to https://
kizu: I noticed sometimes we might want to only change behavior from one anchor element to another
… Mostly for cases like side notes and other things that are not covered by the popover API
… Given the API probably handles the most common cases, this may not be so pressing, but in a reading-order future, we might want to allow authors to make changes
una: I agree that with popovers you're covering tab-navigation as expected
… I agree we do need an implicit anchor relationship
… This feels like an HTML thing
… You also have other examples in that post that show the need
… I think an anchor attribute would be best
TabAtkins: Agreed; my major objection here is that anchoring can be used for lots of things and we can't reliably determine a relationship
… That's a complex and manual enough example that I don't think we can do this reliably
… Good announcement behavior is important
… The HTML AAM opened their own issue on this, and they're talking about how to bridge with us
… My proposal is that for the anchor positioning spec, we close with not changes but we keep working with other groups to figure out the solution, which is needed
fantasai: Agree with Una that this will need markup support, and it should be something in the HTML. And also should allow anchoring either before or after the element.
… The control is going to need to invoke a bunch of accessibility bindings
<TabAtkins> And then if there's an anchor attribute, that'll establish the "implicit anchor element" for anchor post, which'll mean authors don't have to repeat themselves in CSS
fantasai: But I don't think asking authors to use ARIA markup directly is the right approach, even though we'll rely on it underneath whatever markup there is
… If we want authors to be able to use these, it should be sufficiently convenient that they'd be willing to use it instead of CSS. For example, in CSS we have the ability to scope patterns so that you don't have to create unique identifiers for every instance of a repeated pattern; that needs to be available in HTML also
… We shouldn't change the spec normatively, but I think we should keep this open until we get the information on best practices so we can put it in the spec
masonf: +1 to HTML markup, like popover does
… Switching tab ordering between layout order and DOM order is trickier than it sounds
… There has been some pushback on the anchor attribute in general, so we might want to bring this up with the WHAT WG
una: There's new reasoning to have the anchor attribute
… I really think something like popover feels like the most seamless solution
… Handling multiple anchors like on Wikipedia is super annoying to do solely throught CSS
fantasai: I think the anchor attribute as currently specced is not going to be enough
… It only works with IDs, for example
… So dealing with repeated patterns on a single page doesn't work
… It also needs to be able to anchor an element before or after the element
… The current proposal doesn't hook into accessibility bindings, so it will have to do that
una: In the authoring process, if they have a new tooltip it will probably get a new ID, so I don't think having to do that here would be a major barrier for authors
fantasai: If CSS is significantly more convenient, then they'll use that
… Right now they use IDs because there are no other options
… We just need to design a syntax so we can extend in that direction
astearns: Soundsl ike we're going to keep this issue open, but for now will pursue a markup-based solution that can hit all the issues raised here
astearns: Moving on…
github-bot, take up w3c/
[css-anchor-1] Allow anchoring to a particular fragment
<github-bot> OK, I'll post this discussion to https://
TabAtkins: It was raised that there's several possible boxes of an anchor that could be anchored to
… Spec says the axis-aligned bounding box of fragments
… This is reasonable most of the time, but there are probably cases where we want to anchor to other boxes, like the margin box
… There's plenty of space in the syntax to declare which box or fragment you want to anchor to
… There are some proposed values like first and last; I might want first-fragment and last-fragment to be more clear
<fantasai> +1 to longer keyword for first/last fragment
TabAtkins: We would still default to the current behavior
… Does this sound like something reasonable to pursue?
astearns: Box keywords, absolutely; not so convinced about fragments
TabAtkins: If something's split across a column-break, you probably want to pick one of the two fragments at some point
iank_: Just making sure this is grounded in use cases
TabAtkins: Are any of the boxes a problem?
iank_: Inner boxes like content and padding, but implementations tend to ignore the existence of scrollbars
… In CSS shapes, browser get the padding box wrong when there's a scrollbar
… Fine to have these values, but just want to make sure people are asking for them first
TabAtkins: Border and margin are the most obvious to have, and I don't like subsetting, but I'm okay with it to the extent that values are working well
iank_: Generally, padding-box and content-box of everything is broken with respect to scrollbars
fantasai: I think a major use case for fragments is sometimes people want to put a doohickey at the beginning or end of an inline that can wrap to multiple lines
… I expect this would be used a lot when does against inline boxes
… Tab's CSS Day demo showed these box values would be valuable
… Content and padding are not as useful for a lot of use cases, but you could use them to place things on top of an anchor, like a "New" banner in the corner of some content
kizu: With wrapping inline elements, JS tooltips have this problem as well
… Wrapping through columns is the same case, but would we want to attach to whole column fragments?
una: I think fragments are confusing to authors
TabAtkins: I don't think we've really exposed fragments to authors; let's open an issue about terminology, or continue in this one
khush: When we did view transitions, this came up there as well
<khush> w3c/
khush: It would be nice if we had a generic syntax to deal with other cases of fragments
… I vaguely recall us talking about being able to put this in selectors
iank_: No no no
TabAtkins: Good to know
fantasai: Back to margin/border box keywords, we also need to be able to specify this for the default anchor
… IN our exploration last July, position-anchor was a shorthand that let you include name and box
… Not sure what to do with the fragments case
… What do authors call it when a thing splits across lines?
<Zakim> fantasai, you wanted to point out for margin-box etc need to add it to default anchor
<iank_> itsy-bitsy-splitsy-box
<fantasai> https://
TabAtkins: I suggest we resolve to add margin-box and border-box keywords to anchor functions and position-anchor, and I'll open an issue about padding-box and content-box keywords, and we resolve to do something with fragmentation but we need to figure terminology
<fantasai> position-anchor -> position-anchor-name + position-anchor-box
astearns: A general fragmentation thing would be useful, but in this case, do we only want to have access to the first and last fragments?
fantasai: Yes
TabAtkins: Yes
astearns: Any objections to the first resolution?
(silence)
RESOLUTION: add margin-box and border-box keywords to anchor functions
fantasai: We need to also resolve to add these to position-anchor property
… We probably want to split those into longhands position-anchor-name and position-anchor-box
… Any objections to adding those?
(silence)
RESOLUTION: add properties position-anchor-name and position-anchor-box as longhands of position-anchor
Break
<fantasai> s/the current proposal doesn't hook/Lastly, the current proposal doesn't hook/
github-bot, take up w3c/
[cssom] How safe is it really to shorthandify properties?
<github-bot> OK, I'll post this discussion to https://
fantasai: We often want to extend CSS by turning an existing proeprty into a shorthand
… There are compatiobility problems with that
… This shows up in ennumeration of CSS style declarations, which is only supposed to ennumerate longhands
TabAtkins: We have some compatibility issues with turning anything into a shorthand
… A few APIs only care about longhands
… Sudden losses of properties cause bugs in people's programs
… We saw this with white-space and another one that escapes me
… Chrome got some bugs reported and ended up implementing a third, worse behavior
<lea> Seems like the appropriate solution is to fix these APIs, not to stop shorthandifying properties. Shorthands not showing up in these APIs (when they could be serialized) is a common author pain point.
TabAtkins: we prefer not to do that again, especially for things like positoin
<dbaron> (were you thinking of vertical-align as the other one?)
TabAtkins: We suspect position is un-shorthand-able
<emilio> we did shorthandify something really old (overflow) without that much pain, right?
TabAtkins: David, you're right, it was vertical-align
… Emilio, I don't know how much pain there was with overflow
<fantasai> emilio, that was expanded out a very very long time ago; we just expanded the shorthand to allow two keywords recently
florian: Were you going to explain how to work around this with that behavior?
<dbaron> (I think overflow was a shorthand in WebKit from very long ago.)
TabAtkins: No, we really don't like it, and we don't want to do it any more
lea: Seems like we should fix the APIs, not stop fixing CSS
… Shorthands not showing up in APIs is a perpetual author pain point
<fserb> +1 to that
oriol: Don't completely agree with Lea
… if you ask for a shorthand, you get a list of all the longhands, which seems normal
… I think it's duplicated information to have both shorthands and longhands
… From Tab, I have concerns about duplicating things
… Inline styles can be modified by CSSOM and that concerns me
… If you remove some longhands, keeping the shorthands would be broken, so there would need to be checks to avoid that
… If you're iterating longhands from end to beginning, and removing some, that would mess up indexes and you could end up going out of bounds
… Depending on what the author is doing, the application can break
una: An example of where shorthands add confusion is recently we implemented transition-behavior with discrete value
<TabAtkins> transition-behavior: allow-allow-discrete
una: The transition acutally overrides the longhand
… This is one example where we'd let authors opt in, but we can't do that now
… Shorthands aren't always better and can add confusion
florian: Need to think about this further, but for these APIs that care about the difference between short and longhands
… If the values in use can be represented through the shorthand, then we include the shorthand only in the serialization
… If not, then we'd include the longhands only in the APIs
emilio: That causes really weird behavior
… The set of anuimated properties can become longer, and would change longstanding behavior
… You would maybe expect the four margin longhands, but suddenly you just get margin
… This would make computing the length of the ennumerator difficult
TabAtkins: I presume this would only apply for the handful of properties we list out
florian: I think emilio's point is good; there are a bunch of proeprties we can't do this for
… But could it work if we scoped it to certain properties?
… We could let existing proeprties continue to act as is, but open up new behaviors
dbaron: I think a bunch of this is going in a direction that's not the problem we need to address
… This is more about ennumeration and not about serialization
fserb: I'm confused about the scope of the question, whether it's about ennumeration or is it more generic?
florian: I think if you could serialize as the shorthand, you would do that; if you can't, then you wouldn't
<Zakim> fantasai, you wanted to discuss minimal compat fix
fantasai: I think as Tab said, we can't do this for all proeprties
… For transition stuff, perhaps we could include both shorthand and longhand safely
… For the ennumeration, we'd keep a list and if the longhands can be represented as a shorthanded value that's one of the values that are legacy-constrained
… If the longhands have extra values that can't be represented in that limited syntax, we ennumerate the longhands
… So for white-space, if you gave it some new unrecognized value, then you'd ennumerate the longhands
dbaron: My understanding of the ennumeration problem is that there's no concern whatsoever about the values
… I believe the problem is that if you do a JS ennumeration through CSSOM, it gives you a list of every longhand property in CSS
… It doesn't matter what's been specified, it's just a list of everything
… I think we've fixed the serialization problems
… We have problems with mechanisms that let you ennumerate weverything in CSS, which have no value dependences at all
… It's possible there are other problems here, but does anyone think I was wrong about that?
TabAtkins: No
<Zakim> lea, you wanted to say the current design is clearly problematic, and these don't seem like dealbreakers, just like the usual design decisions we need to make with every feature. And they certainly don't prove that we shouldn't even explore that avenue. I don't see how removing shorthands when the longhands are removed is that different from adding longhands when a shorthand is specified, it's not like what the author specified is preserved exactly
lea: Back to what Oriol was saying, we know the CSSOM is problematic
… We need to explore some of these avenues to see if what we come up with, we need to check if it will make things worse or better
… Authors specifying shorthands and getting back longhands is just as confusing as making shorthands disappear when longhnads disappear
… Authors almost never intend to get back the entire list of of all properties
<TabAtkins> These enumerations are used by some tooling, that's who reported compat bugs
lea: If authors ask for a border, they can't get any shorthands, they have to get a very specific longhand
<emilio> dbaron: In specified declarations, we do only enumerate specified longhands
oriol: If you ask for the border, you get the border, you get the serialized values
… I do agree with dbaron, this isn't a value problem
<emilio> It's only getComputedStyle() which returns all longhands
oriol: If you change the value of a longhand or a shorthand, a shorthand stops being serializable
… This would make things unreliable
lea: I was just writing that parts of the CSSOM seem to have improved
florian: I'm not approaching this as serialization, I agree it's about ennumeration
… It may be this is a bad idea, but I think all the cases you mentioned about ennumeration, they all depend on contexts where you could go on to get the value
… If there isn't the notion of being able to ask, then what I propose would become impossible
… If you can go on to ask about the values after you ennumerate, then this linkage can be made
… In order to preserve shorthands as standalone properties, this would introduce a dependency, and has the downside that the set of properties and their indexes would change
<lea> +1 to florian
florian: Itæs a tradeoff, but it might be a worthwhile tradeoff
dbaron: I think from the JS perspective, what Oriol is suggesting would be really strange
… I admit I haven't paid a ton of attention to JS engine optimizations, but back when I did, there was much done based on type inference
… Making an object have different properties means now CSS style isn't really a type, it's hundreds of types
iank_: It changes the shape
dbaron: We're talking at the boundary of the CSSOM and JS
florian: Not quite undoable, but very weird?
dbaron: Yes
fantasai: So you're saying this thing we're ennumerating always returns every property in CSS?
dbaron: Yes
… If you use an ennumeration in JS to ask what all the fields in a CSS style are, you get all the CSS properties
fantasai: And ennumerating the shorthands in question and their longhands would break in what ways?
<bramus> +1 to dbaron
dbaron: If we could do it, that might work, but I don't know if that would break anything
emilio: I don't know if that's true
… When you ennumerate specific CSS declarations, you get the longhands that are specified in that declaration
… .length is how many longhands you have in there
iank_: I believe dsome of our compatibility problems came from ennumerating
<dbaron> emilio, see above testcase
emilio: Preserving shorthands in specified styles is a relatively big change, but seems doable
… Doing it in getComputedStyle is a bit tricky
dbaron: I don't think that's the issue
<dbaron> dbaron: I think it was (for i in document.body.style)
<lea> dbaron's demo with values: https://
emilio: A lot of things we've been discovering have been different
lea: ASking David what is weird from the JS perspective
… Is the proposal to remove longhands?
dbaron: I'm not sure what you mean by dependencies and if there was a proposal
… I think maybe it was to include shorthands in a place that only has longhands
<emilio> `for (let i in document.body.style) { console.log(i) }` does include shorthands
<emilio> (In Gecko at least)
TabAtkins: That appears to be a requirement of whatever we settle on
florian: I think we effectively have three proposal to consider
… 1. Sometimes don';t include longhands
<lea> What I was proposing was to include *both* longhands and shorthands.
<dbaron> emilio, it doesn't include "font" in the url I gave above
florian: 2. The list of properties you ennumerate depends on the actual values
… 3. For a subset of properties, list both the shorthands and longhands only
… You'd have to make it a subset because there are historical properties where doing that would break things
<emilio> dbaron, it does for me? (the codepen console eats it because too many properties)
fserb: This is just about the ennumeration?
florian: Yes
<lea> emilio: Open the browser console
florian: I suspect alternative 3 is the simplest, but I don't know if it's possible
<Zakim> IanK, you wanted to clarify what exactly the problems are that we're running into
fantasai: Ian, what are the problems and what are we trying to solve?
iank_: I'd have to go back and see what we found
<dbaron> emilio, oops, you're right -- they're in a very strange order!
<emilio> lea, `{ let found = false; for (let i in document.body.style) { found = found || i == "font" } console.log(found) } ` logs true here
iank_: I worry that optoin 3 would open a separate can of worms
astearns: We could resolve on opening that can of worms to see what we find
<lea> emilio: Yes, that's what I'm noticing in Chrome too. Then what's the issue?
<emilio> dbaron, See above? ^
<fantasai> [note to scribe to keep lea/emilio chat as a side-converstaion, not as corrections to the minutes]
fserb: Can someone speak to the use case here?
… What's the use case for ennumeration?
<dbaron> ok, yeah, chrome and gecko both seem to include shorthands in enumeration... I'm not sure what the issue is
fserb: What do we care about, and what do we not?
florian: I'm not approaching this as any particular use case, but from the place where thaere are cases where it's useful
… But things are not posisble with how we do ennumeration now
<oriol> for...in just does the normal JS thing, right? I thought we were talking about for...of
fserb: This works when we query the properties, yes?
<emilio> dbaron, my understanding is that `style.cssText = "font: ...;"; [...style].includes("font")` is `false`, but that's the same `.length` bit that I commented above
fserb: There is a thing about people getting confused, but I would argue having both would make people more confused
<oriol> +1 that having both is just more confusing
fserb: If you want just a sense of properties, having to do the extra work of knowing the shorthand means you can't get the bag of properties
florian: The way I'm thinking about this is not about what makes sense in theory but what we can do that doesn't break compaibility
<emilio> oriol, so yeah, my understanding is that what you said is correct, but that might be solvable in different ways depending on whether compat issues are in the specified style and computed styles
florian: So I had a question to Ian, earlier, what kind of can or worms were you talking about?
… Did you mean there are some properties where changing this breaks things?
<Zakim> florian, you wanted to react to IanK
florian: Or is this more about the API shape itself?
iank_: My thesis at the moment is that properties that have been around since time immemorial is more likely to have author depending ont he ennumeration
… Things that are more recent, much less likely
… What we had to do with white-space was a lot more extensive
florian: So I propose for all properties that exist, we do what we've been doing, but for any new property or newly shorthanded properties, we list both shorthand and longhand
<dbaron> emilio, here's the actual testcase (thanks to Ian): https://
florian: Is that something we can do, whether or not we should?
<emilio> I think I have a proposal, if this is for the computed style
andruud: Would that help?
<lea> In terms of API design, that seems like the worst of all worlds. How are we supposed to explain this to authors?
andruud: In the position case, we don't touch that since it's been around since forever?
florian: No, if we shorthandify that, we would do the new thing, but we don't do it to things like margin
andruud: Can we research this can of worms without opening it?
iank_: I don't know
astearns: I've closed the queue since I'm not hearing consensus or conclusions
emilio: We need to distinguish the computed and specified styles
… We can have a shorthand list and the only thing we need to make sure is the whole longhand space can be represented by the shorthand
iank_: I think it depends on how it's being used
<oriol> +1 most of my concerns are about non-computed styles, since you can modify them
emilio: I propose that if this is about the computed style, we can do this easily
… If this is about the specified style, that's a bigger change
… When the CSS parser parses white-space, it ends up with a bunch of longhands
… We could make it not do that, but that would be a big change
… Having a flag on a shorthand would be trivial-ish?
dbaron: Ian and I have been test casing and one of the things I said earlier was wrong
… `i in foo` is wrong for where the compatibility exists
… it's more in `i to length`
… The ennumeration order has the shorthands first and then the longhands
… The problem may be computed-style only
<masonf> The `white-space` compat problem we encountered was that `for(s of getComputedStyle)` was missing `white-space`.
<Zakim> lea, you wanted to say This discussion makes me think we also need a data structure that allows authors to read what is a shorthand of what. Also relevant to this future TAG principle: w3ctag/
dbaron: Again, we probably need more test cases to be sure we're talking about the right thing.
lea: I think we have consusensus we don't want to stop shorthandifying properties
… Breaking properties into BC/AD seems like the worst solution
… How are we supposed to explain this to authors? I'd much rather add one-off exceptions, but I'm not convinced we even need to do that.
… By principle of least surprise and assuming most authors use lookup instead of ennumeration, we could make changes
… There should be a data structure for authors to read what is a shorthand of what, so that if they're doing some complicated thing they at least can figure out what is happening, which is incredibly tricky right now (I’ve tried to do it!).
<astearns> +1 to introspection of shorthand/longhand relationships
lea: This is also compatible with the TAG future design principle of allowing introspection
<oriol> You can currently know what is a shorthand of what with the current API. The proposals here would break that.
astearns: Sounds like we need more tests and finding the smallest can of worms we can open
fantasai: There was also an issue around transition events
dbaron: I think that's the harder half
… That said, I think we made the easy half hard by talking about what it is instead of solving it
… And I also think we still don't know
astearns: Leaving this for now
github-bot, take up w3c/
[css-anchor-position]: Question: Why is anchor-size() only valid in a sizing property?
<github-bot> OK, I'll post this discussion to https://
TabAtkins: An author asked why the anchor-size() functions were only allowed in sizing functions
… It was the obvious restriction at the time, but there are use cases to allow it elsewhere
… At minimum, we should be able to relax this to match the list allowed in position-try
… Ian can talk more about the reasoning in that restriction
… Roma had questions, but I don't understand them
… anchor-size is a size, but the function has to stay specific to the inset properties
… Let's talk about what properties should allow anchor-size()
kizu: In my experiments, I often wanted to use not just the anchor size, but the anchor itself
TabAtkins: Given that anchor size is a difference between two anchors, being able to provide two anchors and get the distance between them sounds doable
fantasai: We should take that as a separate issue
TabAtkins: Ian, could you talk about this?
iank_: I think it's basically the same as if we start messing around with the bits of abspos elements
… It starts to break a lot of optimizations
… I think the insets are fine, with no issues
futhark: I would assume this has the same limiations
TabAtkins: The restriction on not touching the any bits is related to not using it in padding
… I presume it's acceptable to do for paint-time properties like clip-path and background properties
… Is that accurate?
iank_: I'm not sure
… There are some things we think of paint things that do bleed into layout and I'm a little concerned about
TabAtkins: Example?
iank_: There's stuff in inlines and stuff for when we calculate overflow contributions, and then all the table internals may influence layout
… That's a small smattering; I'd need to talk with folks
fantasai: Having it apply only with the properties of position-try is a nice consistent thing to understand
… I think for now, starting with those properties is reasonable
iank_: Anders, any reason that would be bad?
futhark: That seems sensible, yes
TabAtkins: Yeah, we could start with that list and then look to see what we might add to that
fantasai: I don't want to add properties to @position-try because position-try doesn't participate in the cascade properly
… If we want to style more properties conditionally, we need a more generic solution to that problem
TabAtkins: That is a thing we can deal with later, we can use the list from position-try for now and open a new issue to discuss further onward
iank_: I think we're all in agreement about adding anchor-size to the set in position-try
… I think there's a different solution space for the wider problem
ydaniv: What about transforms? Is it possible to include them?
TabAtkins: That falls into the wider problem, but I agree this would be useful for transitions
… Add it to the list of future discussion
una: Is there a plan forward for generic styling properties?
… There are so many things authors want to adjust based on position and other things
… This general problem keeps coming up in various contexts, of which this is one
… Would really like to have a place to talk about the wider problem instead of hitting it in smaller problems
fantasai: Tab wanted to do that in level 2
iank_: I don't think we should do that with position-try
fantasai: We all do want to solve the problem, but it's not going into level 1
una: So we'd do that in 2?
fantasai: This isn't actually that problem, and I'd rather have a solution rather than confusing authors by throwing properties onto a pile one by one
… We need to have some kind of an answer that makes sense as to why a thing can be used for one property but not another
florian: We all want to solve the bigger problem some day, so the question is, does this immediate solution depend on the longer-term solution? if not (and it seems not), then let's not discuss the bigger problem _now_.
TabAtkins: propose to add anchor-size() into the values of properties that take lengths on the list of position-try, and tackle the wider problem later
astearns: Any comments or objections?
(silence)
RESOLUTION: add anchor-size() into the values of properties that take lengths on the list of position-try
github-bot, take up w3c/
[css-anchor-position] Resolution of percentages: area or track?
<github-bot> OK, I'll post this discussion to https://
fantasai: (goes to chalkboard)
fantasai: This is about percentage resolution on inset properties
… Here's an acnhor, inside a container
… For the inset area, we create a 3x3 grid
… You can address this by saying in which grid box an anchor should live
… Let's say we put the anchor positioned element in `bottom span-right`
… Let’s say I want to draw a box in that area that's positioned with its left at 50% minus some amount, say 30px. The issue is that the 50% is relative to the entire span, when I want it only to be the center
… We could create an anchor centerline, but that's only narrowly useful
… When we designed the inset area, we said 100% left would align with the right edge of the anchor
… For the inset properties, the percentage is relative not to the container, but to the track on that side
… That gives you an easy way to do a lot of positions
… Tab pointed out this is inconsistent with inset elsewhere, which is relative to the containing block instead of the tracks
<kbabbitt> fantasai's proposal: left: calc(50% - 30px) where percentage is relative to the track on that side
una: In this case, 100% doesn't mean the whole containing area, just the track?
fantasai: Yes
andruud: Did you consider a unit like container size query?
<kbabbitt> TabAtkins proposal: left: calc(anchor-size() * 0.5 - 30px) where percentage is relative to the entire size of the positioned element's containing block
fantasai: No, percentages seemed natural here
<TabAtkins> (I have a specific rebuttal for that point)
andruud: It seems weird that this changes meaning for different sides
… You said you could solve this with anchor-size()?
fantasai: That was Tab's proposal
andruud: A unit would give you that
TabAtkins: I'm more strongly on, this is not how percentages work anywhere else in CSS
… The consistency of always going off the containing block means you can use them and have an idea of what they will mean
… Changing this in left and right in this situation and making them distinct from all other percentage uses in incredibly confusing
… Using anchor-size() or coming up wihth a new unit are more preferable for me
nicole: Clarification about the diagram: the direction of the arrows is meaningful?
fantasai: Yes, it inidicate the left property refers to the leftmost track and right to the rightmost
miriam: I kind of like the unit idea
… If you're spanning all, does left give you left and right give you right and there's no access to the middle?
fantasai: Yes
miriam: And 150% would be consistent to the track, not the container?
fantasai: Yes
<miriam> (is there a way to use cq* units here?)
TabAtkins: The proposal means left: 100%; right: 100%; would fill the containing block, but left: 150%; right: 50% would not
una: I feel like as an author, I prefer consistency
… I probably wouldn't use span-right here
… If I did 100%, I would expect it span across both tracks
… This adds complexity if I change positions
… Because this conflicts with my understanding of percentages, it would be harder than using anchor-size() or some other approach
… This feels like it simplifies some use cases and complexifies other use cases
fserb: Was thinking about what would happen if the choice was the other one
… So if it was bottom span-left, you could only percent from the right?
… Or if you spanned the whole thing, what would happen?
fantasai: left: 50% would be halfway across the left track, and right: 50% would be halfway across the right track
<masonf> In that example, with 50%, the tooltip isn't centered.
<TabAtkins> More on the "this is inconsistent" drumbeat: this means you can't invert the property you're using with the `calc(100% - N)` math
fserb: And in other proposals, percentages would be relative to the whole area?
fantasai: Yes
<una> Also would this break/behave differently than translate: 50%?
bramus: Looking at the data between the code you have at the bottom of the drawing, and then comparing to the other code, I don't see a big delt between them
<TabAtkins> translate: 50% is relative to the item, not the CB, so that's already different
bramus: If you do the thing on the left, then you aren't changing the meaning of percentages
… The proposal seems very confusing
… If percentages were used here, I would expect them to resolve against the inset area
<TabAtkins> more inconsistency: this means that `inset: 0; inset-area: bottom span-right;` is different from `left: anchor(right); right: 0; top: anchor(bottom); bottom: 0;` - right now there is no difference between these (save for a bit of error-correction when the anchor is outside the CB)
fantasai: To take a simpler example, if I wanted to put a pin over the anchor with its base in the middle of the anchor, it would be `inset-area: center span-top; bottom: 50%`
bramus: You could also do anchor size * 0.5
fantasai: The alternative would be `inset-area: center span-top; bottom: calc(anchor-size()*0.5)`
<Zakim> florian, you wanted to comments on units vs percent
florian: At least in the two-column case, we can get what we want without new stuff using verbose syntax
… Maybe we could use it for the three-column cases?
… But if we want a compact syntax, we need something new
… The proposal for a new unit makes me feel strange
… You'd end up with a unit that's easy to understand why you don't want it
… It wouldn't mean anything in most properties
… It's odd to have percentage meaning change, but it's useful
… In sets of related properties, percentages don't always do the same thing
… It's stronger here, but it's not completely new
… It takes getting used to, but there's no alternative usage of percentage that makes sense, and explaining what a new unit does in situations where it doesn't apply also seems confusing
astearns: Is this analagous to positoining something inside a grid unit that spans tracks?
fantasai: Yes, but in that case I think it's a lot less clear what you want to result
astearns: I disagree, with my chair hat off
florian: Even if it's going to cause inconsistency?
astearns: I don't think it's any less inconsistent than the alternative
<Zakim> florian, you wanted to react to florian
florian: I don't see it as an inconsistnecy because we already define per-property what percentages means
ydaniv: Agree with Florian; we already define percentages differently in different contexts
… We made some things simple with ranges, but lost some things that way as well
fantasai: If you did end up with a use case where you needed to resolve against the whole inset area, you could use the anchor functions and do a lot of math
… So we do have an escape hatch
… In the set of things people are going to do, are the use cases of the using whole inset area more or less common than using tracks
… I suspect the whole inset area would be extremely rare
… I'd ask people to come up with examples and then decide what you feel more comfortable with
<TabAtkins> Also left:anchor(50%) already centers on the anchor, fwiw.
<TabAtkins> You need some more effort to center on the side tracks
kbabbitt: For the use case presented here, I don't understand why you need bottom span-right
… Couldn't you just set the left at 50% - 30px and then let the positioned element overflow?
fantasai: You can do that, but by default, if you're in the center track you're aligned with respect to the center track
… So if you overflow, you'd overflow in both directions
miriam: This would also impact position-fallback, right?
fantasai: Yes
kbabbitt: In a case where you are spanning all the bottom tracks, how do you hit the case where you want to be 50% of the center track?
fantasai: You wouldn't try to do that
kbabbitt: So your goal is to grow both directions, or to grow one direction or the other, and that informs your choices?
fantasai: Right
<Zakim> TabAtkins, you wanted to comment about the usage
TabAtkins: Two things from me…
… Any argument about left and right percentages being not useful to the whole containing block I think apply exactly equally to margin-left and -right
fantasai: I'm not sure I would use percentage margins here
… I suppose you'd want something more consistent
… It's worth noting all margins resolve against the inline axis
TabAtkins: Second note, the main obvious use case is positioning with relation to the center of the center track
fantasai: Yes
TabAtkins: If you put a percentage in the anchor() function, you get the placement you want
…`left: anchor(50%)` puts an edge right in the middle of an anchor
fantasai: Would that work with the inset properties?
TabAtkins: Yeah, it doesn't care about that
… It should automatically work
… In the cases you need something more precise, leaning on math is fine
… For the center ones, we can already do it
fantasai: So you're saying `left: anchor(50%)` would address this situation
astearns: Is that simplfication enough for you to withdraw the option you were presenting, Elika?
fantasai: I think so
astearns: Provisionally we might resolve this a closed, no change, but let's go to the queue
una: My main question is, are we seeing cases where developers run into percentage confusion?
fantasai: I don't think so, the question is more how easy can we make it to do the common cases?
una: I get that, but what if you want something that spans 90% of both tracks?
fantasai: You could put margin: 5%
una: So that wouldn't apply to the margins, just the insets
fantasai: Yes
bramus: I like the anchor() fix, but the main thing is you want access to the anchor block and inline sizes, so maybe in the future a unit would be useful; no need to resolve now
fserb: I think having units that behave differently on the same axis are weirder
<masonf> lol
fserb: I question that I cannot find a use case for the total size
… If you don't change, they aren't good for expressing anything
… For folks who don't like the percentages, is that a use case fo 30% of the total thing?
una: If you had a big block of text inside the positioned element, and you want to make it readable with a percentage margin, this is an example that you wouldn't have something small like this
fantasai: So something like a really long footnote
una: Yeah
fantasai: I think if you want spacing, margin is appropriate
una: Right, but if the percentages are different between margins and insets, that's weird
Nicole Sullivan: Having a lever over how things grow, that would be useful
fantasai: I think we have the right controls, but I'm willing to talk that through
astearns: Can we resolve close, no change?
fantasai: I think that works
RESOLUTION: Close with no change
lunch
<emilio> When's lunch over, 3PM?
<lea> emilio: 2:35 pm
<emilio> Cool, ty lea!
[cssom-view] Bring the segments property into visual viewport
<jarhar> what is alexis's username? if i dont have anything ill just say "alexis"
alexis: one of the gaps we have is support for layout in pop? and making content is not on the full section, and there was work done in the past by ms for css ??? and its already part of the media query
alexis: the bottom section of the screen, bringing parity to support the functionality in the javascript world
alexis: lets say youre in a canvas or a game, you cant necessarily use css so in the past we used ??? and css and javascript, that was the PR in the bug
alexis: requesting approval to add this feature to the CSSOM view? spec, and there were a couple questions raised
alexis: i went to great lengths to show how were not exposing anything new
alexis: there was a question about iframes and media queries
alexis: there was a question about whether this should be part of ???, and WPT support and webdriver support for us to test this
alexis: we need webidl support
alexis: thats basically it, im here for questions
<TabAtkins> +1 to this in general (i've been bad about supporting this issue)
alexis: the css viewport segment as well as the viewport - as well as the second compnent of visual viewport are in origin trial, we are seeing feedback on this feature, went through tag reviews
astearns: i wonder whether we could resolve on adding this to the cssom view spec, and create separate issues for each of the things that you got in your summary
astearns: we dont have to figure out if it has to be aprt of the visual viewport api, but if its in a draft you might get more traction on individual issues
alexis: yes, i would like to resolve this at some point
bramus: i havent read into what is in the spec, but im confused right now. do the segments expose the various viewports or the visual viewport?
alexis: they are multicol subdivisions of the visual viewport
alexis: for fullscreen, its logical subdivision of the visual viewport. im not sure if fingerprinting was an issue
alexis: that includes also figuring out the resolution of laptop
bramus: what about window.visualViewport? it doesn't get affected by page zoom
alexis: the only thing that would take into account is the scale factor of the device, thats the only thing we do
bramus: there is an issue 8709 where it was mentioned to have somtehing like window.viewport eventually, and maybe you should work on that where we expose the viewport. you have to postfix somewhere, we could tackle both in one go
bramus: and then you have segments as you described here
alexis: the reason it was there is that i wasn't the original author editing there, but because the visual viewport ?? are basically equivalent for intersection
alexis: so thats why it was built that way, it was visually speaking you see two segments, thats probably why it was put there in the first place
alexis: i agree with you, its not a window property
miriam: can we take the resolution alan suggested and then open issues?
bramus: we might want to move this somewhere
astearns: we would only be stuck if people started implementing and we got web content that relies on it. we need to have some draft text to be working on it
astearns: this will help us get more attention
alexis: if we move it then i will have to redo the origin trial
alexis: ??? css api as well as the js api, implementing a full fledged support on your app,
alexis: at some point we will ship the rest of the pieces
alexis: implementation in chromium, origin trial just for that js api, we are already late in terms of spec
alexis: speaking as an implementor, not as the spec side of things
flackr: this isnt an objection to this proposal, but that got me thinking about what pinch zoom means
flackr: im wondering if we need some better way to have multiple viewports
flackr: would you want to pinch zoom a segment of the display?
flackr: you probably dont want it to move content on one segment to another segment
alexis: true, but pinch to zoom implementation is stuck to the page
alexis: i see what you mean but then we are going to an implementation complexity thats crazy
alexis: do i want to zoom the app? or one section only?
flackr: im just trying to figure out if we could design it any way we wanted then where would we end up?
alexis: then how would we do this in css? theres the css part we have ??? so how would you...
flackr: this isnt an objection to your proposal, i think its fine
flackr: i was just throwing out the idea that maybe we should think of a css way or js to define viewports within your viewports or something like that
flackr: im not objecting to exposing what we have
alexis: but my question about pinch to zoom: what happens if you pinch to zoom? ok then dont change
flackr: you would be zooming into a particular viewport not the root visual viewport
alexis: the concern with the visual viewport - what happens with escape popover?
flackr: the device scale factor doesn't change
alexis: so we would not change anything, we would not expose the viewport
alexis: its not aligned for contet, but its the same for any page thats out of viewport
flackr: the visual viewport api is exposing the visual viewport, but the thing youre trying to expose is outside of that, the full browser viewport
alexis: one possible implementaion would be for me to resnap these values to one is visible and one is pinch to zoom right?
flackr: i dont know how that would work i would need to see an example
alexis: with pinch to zoom any portion is what i can see after the pinch to zoom
flackr: yes
alexis: lets see i pinch to zoom, ok i understand what you mean yes
miriam: are we ready to take a resolution or do we need to take this back to the issue?
bramus: what i would like to see and from peopple at apple would be: if you did window.viewport or window.visualViewport would we add some more things to that
flackr: right now windows kind of our container for this kind of thing
flackr: would it make sense to have more things on window?
<emilio> window.viewportSegments?
bramus: maybe this would be our opportunity to correct some things from the past and group it under window.viewport
fantasai: i dont know much about the CSSOM
fantasai: the one thought in myu head was about what coordinate system these are in, whether its zoomed coordinates or not and how does that related to other objects thats attached to
alexis: right now its ??? its just the device pixel value
bramus: you have the viewport, you draw a line in the middle, and the visual viewport still bounces around, you can show parts of various segments because its a subsection of the entire viewport
fantasai: wouldnt you and an author want segments of the entire viewport not the visual viewport?
flackr: yes
bramus: i think thats what we currently have
emilio: but in css pixels not device pixels?
fantasai: where is that defined?
alexis: right now the visualViewport property
<emilio> fantasai, https://
alexis: proposal to add a property in the visualViewport object
fantasai: where are we representing the segments in terms of the overall viewport?
fantasai: which object in js right now tells me that the hinge or whatever is 40% through the viewport?
flackr: my understanding is that its just css properties
alexis: you have two media queries that tells you the orientation and then you have css hover and variables that sets you each of the segments, including the width height in x and y
alexis: for each of the segments
fantasai: and those are required to the layout viewport
<fantasai> https://
fantasai: so what youre wanting to add is a method to access this information with rspect to eh visual viewport
alexis: yes and being able to use this in js without css in the first place like canvas
flackr: its not with respect to visual viewport its respect to the viewport
fantasai: whats the use case with knowing that this is with respect to teh visual viewport since pretty much everything is laid out wrt layout viewport?
flackr: there has been confusion, this doesnt belong in the visual viewport api
fantasai: then it doesn't belong on the visualViewport object
bramus: that was my point
alexis: but where then
bramus: id say window.viewport
bramus: and a way in javascript to get the small viewport height and the ??? viewport height
fantasai: does window.viewport exist already? and you want to create this that represents the visual viewport? that seems reasonable
fantasai: then i think the way forward here is to sketch out what this object would look like and include the segments information as well as the other information that bramus is mentioning
<emilio> This would probably be a good option to fix w3c/
alexis: if you need help to sketch out then whats the work ??? i would need help on writing the dom
<astearns> did I hear bramus volunteer to do that?
miriam: we could take a resolution that this is the path forward
bramus: i would take a stab at that
alexis: we can connect offline bramus if you want
fantasai: proposed resolution: define the segments on a new layout viewport object on window tbd
miriam: any objections to that proposed resolution?
RESOLUTION: define the segments on a new layout viewport object on window tbd
github-bot, topic w3c/
[CSS2] How do zero-width floats affect subsequent content
<github-bot> OK, I'll post this discussion to https://
oriol: this is an issue about floats. the issue that we have with floats is that fiwe have line boxes that come after floats they need to be shortened, same thing happens with block level elements that establish a formatting context
oriol: this question is what happens if the float has a width of zero or a height of zero or negative because of margin box
oriol: i started ?? web browsers in servo and they didnt get much agreement, i recommend looking at the last comment in this issue
oriol: basically the only case that is defined in the spec in css2 is just related to line boxes. it says that if a float has a height of zero or negative, then this shouldn't shorted line boxes
oriol: turns out that blink does not respect that, does the opposite
oriol: gecko obeys it. webkit obeys it
oriol: but yeah i would like to define what should happen in these cases. we should resolve that these cases should be consistent, whatever it should be
oriol: it would make sense for them to be the same
oriol: about the specific behavior, although its inconsistent with content-visibility because for that we observe for that it has an area of zero but it insertects the screen
oriol: im currently leaning maybe to what firefox is doing, which is that if a lfoat is zero pixels wide we allow overlapping that thing
oriol: it coudl be possible o handl the zero case - we could avoid overlapping that , but it would make it tricky with the zero case, so we could align with gecko. maybe others have thoughts
iank_: whats the issue with the negative case?
oriol: in the negative case we have the end of the float coming before the beginning. its tricker to define what it means to overlap that thing. if your element is before the beginning and after the end, maybe of the values in the middle
oriol: typically you dont consider it an intersection
iank_: i dont think thats a novel problem, we have overconstrained cases where one edge is befoe the other, and we just take the dom ? edge, i dont think the negative case is particuarly complex
oriol: i dont have a strong opinion here i think its simpler to go with firefox
oriol: what i think is that we should at least be consistent between shnortening line boxes and block elements in the formatting context
iank_: do all the engines respect clearance with zero area floats? how does that work?
<TabAtkins> table mics just cut out
oriol: for clearance its the block case, and then do you mean 0px wide or tall? what did yousay?
iank_: either. what happens with clearance in any of the case?
oriol: i didnt specifically test fo rthe clear property, but if you have a block level element aht is avoiding floats you move it downwards using clearance
iank_: no they dont. its a different mechanism
oriol: the spec says that its clearance
iank_: the spec says a lot of things
oriol: i didnt try using the clear property
dbaron: i just wanted to say that i agree with your principle that the lines going around floats and blocks going around floats in the inline direction should be consistent with whic floats they ? and which floats they dont
dbaron: you made another argument in the comment about zero width floats and zero height floats. widths of floats and heights of floats do different things
oriol: trying to be consistent seems like a good thing but yeah we could decide to do it different
iank_: specifically with there s a case where you can get ne wformatting context to overlap floats with negative margin. ill quickly draw it
iank_: so this is your formatting context and youve got a left float
iank_: and then you creat another block that is inset with amargin the same width as that float
iank_: if you have a new formatting context with a negative margin it will overlap that float
iank_: where this gets interseting is if you have this case but the float lives here instead then the nbew formatting context will avoid it
iank_: and so what happens when you shrink this down to zero which behavior do you get?
iank_: because then these two cases are the same
oriol: but are you suare about the empty margin it will float?
iank_: yes i have cuased regressions due to this
iank_: its the most annoying thing in the world
iank_: everyone does this
iank_: these two cases become the same when you go to zero
iank_: i think ill prefer this - youll just check that if youre at the edge, then youre not allowed to prorude into the negative space
iank_: so thats one quirk that needs to be considered
iank_: if you have a negative margin here, from this point the new formatting context point of view it can jsut see this. it doesn't see that float and it can just protrude into it
iank_: thats the hand wavy thing thats not in the spec
astearns: i just want to say that we should have a spec issue for this
iank_: theres lots of things in the css2 spec that don't exist
<Zakim> astearns, you wanted to say that the most annoying thing in the world should have a spec issue added for it
iank_: clearance - the spec says that htings clear but i think that they just wrote that because they wanted to ship it down but didnt have a good way of saying that, but clearance works idfferently in most ?
iank_: i would test that as well. that is likely going to have compat like - ill be sad if we ignore floats geometry but then dont ignore clearance for example, we might ahve compat with clearance and zero area things if that makes sense
iank_: people will create zero width things because they dont want a thing to show up at all but want to move it down without margins. i think wikipedia
iank_: if you test explicit clearance that would be good in test cases
oriol: so its your argument tah things with explicit clearance should be consistent with the case where we have a block that is avoiding floats without explicit clearance
iank_: maybe? like if we are going to - i suspect that all engines might behave the same with explicit clearance with zero area floats
iank_: but we should check that i might be wrong
iank_: so if thats the case, then yeah we could still for gemotry purposes ignore floats but that might be a bit weird
iank_: I think I tried what you tried with servo and blink and it wasnt too difficult. you have two valid things that do correct things but then when it goes to zero you have to choose a behavior
oriol: you would prefer that we would not allow overlapping flaot that is zero pixels tall or wide?
iank_: i would prefer it t overlap with zero width because at least the way that wedected this internally because the new formatting context is doconsidring the area here. if my left edge is here then im allowed to retreat into it. if youre trying to block on a zero width float, ? and so you cant detect it easily,
iank_: if you go down the path where you respect zero width floats ?
iank_: thats just from an implementation complexity point of view
iank_: is this opportunithy the full width? then allow it top protrude left and right
iank_: if you have a float on the right then you want it to protrude out this side and this side
nicole: and thats only if the floated thing is zero width?
iank_: yeah but it happens today also with regular things with width that line up with this boundary
nicole: in believe you but when im trying that im not seeing it
iank_: i can quickly chalk one up
nicole: i couldnt get it to work in a codepen
nicole: it was different in safari and chrome, didnt try firefox yet
<nicole> https://
<iank_> https://
iank_: youve gotta inset the inner block ? inset the width of the block by the float
iank_: the red formatting context overlaps the line ? in all browsers
iank_: which is great we have compat
iank_: yay!
iank_: oh the spec needs updating
fantasai: lets record a very clear resolution
miriam: whats the path forward?
oriol: i guess we could resolve that the two cases, line box and block should be consistent. if different browsers are doing different things they are consistent except blink in some cases
iank_: which case?
oriol: when you have 0px wide float in an independent formatting context, webkit sometimes avoids it and sometimes doesnt. for text i coudlnt get it to avoid the float
iank_: so webkits inconsistent but Blink is ok?
oriol: webkit is a bit self inconsistent i woudl say. in the case of zero pixels wide floats browsers are inconsistent
oriol: for zero pixels tall floats, blink is different from webkit and gecko since its avoids overlapping them against the spec
iank_: test cases for explicit clearance would help
iank_: i think your august 9 2023 comment is the triggerint that behavior tha ti just described
iank_: except that blink is avoiding the horizontal lines
oriol: i think that your case here is different because the float isnt zero or relative, the margin belongs to the other element
iank_: i think your august 9 comment is the same because all browsers today you iknow like if theres a zero width float here then all browwers alllow a new formatting context to overlap and intrude it because its on that edge
iank_: is the start of the opportunity the same as the available space? then allow it to go over otherwise not
iank_: thats i think like - i suspec tht at all browsers are doing this case by default
iank_: the only thtnig thats different is that blink when theres a float like this will try to avoid that
iank_: but i suspect that if you hadd clearance then browsers all might clear that for example. i could try ....
oriol: i guess you are saying that we should allow oferlapping flaots that are zero px wiwde except with clearance, all browsers agree except webit sometimes
iank_: what would be the resolution?
oriol: floats that are zero px wide are negative should not shorten line boxes or shift blocks that are independent
iank_: that might not be true though
iank_: i think thats only true in engines if they are on the edge of the available space. its possible to create a zero width float that isnt on the edge of the available space, you might get different results in different engines there
oriol: in the case i was trying it was not the edge and it was only webkit that was inconsistent
oriol: if yiou look at the last comment in the issue
oriol: for text all browsers agree
oriol: iank_: i think they are - they all avoid it if its a new formatting context
iank_: if its a block formattig context, then gecko and blink are still not avoid it, and webkit sometimes does and sometimes not
iank_/oriol/s
<iank_> https://
oriol: it should be the first table of images in the last comment - in gecko and blink they overlap
iank_: the test case i just pasted everyones avoiding it right?
oriol: in what browser?
iank_: all browsers
<emilio> Doesn't look like it?
iank_: or maybe everyones avoiding the ?
oriol: not sure if i should put my laptop in the cyan or something becuase im not sure we are talking about the same thing
<dholbert> (that 'the ?' is for iank's last scribed comment^)
iank_: i think theres at least two passes of test cases that lead to ? layout
iank_: one is explicit clearance with all interactions
flackr: im presenting firefox safari and chrome
oriol: so this is the text case which i guess i was using a smaller container because it seems like its ? on the side
iank_: i took the line test case and then just added anew formatting context
iank_: the line and the formatting context behave differently across browsers
iank_: i think that there maybe more ? that we wil need to consider
oriol: so what i was referring to beforehand in this case is that we have this orange float that is zero px wide and then the blue box is overlapping it
oriol: in this case i only saw a different behavior in webkit
oriol: for the text case...
oriol: the text is overlapping the magenta float
iank_: there might be a sublte difference between those two cases
iank_: i think test cases that we need - feel more comfrotable making a decision
iank_: new formatting context ?
nicole: and which were the various combinations?
iank_: basically if youve got a zero width fl-oat and then youre clearing htat zero width float what hpapens?
iank_: cause that will have different interactions. zero widht and height float
iank_: and then - we can deviate there but i suspect that explicit clearance and zero width and zero height wecan't change
iank_: and then what do we do based about clearance based on that
oriol: i guess, what im getting from you is that in this case we want to be able to overlap zero px wide floats but if theres explicit clearance we shoudln't
iank_: yes
iank_: css2 lies a lot. theyre 2 different mechanisms
iank_: the clearance is the way that - they walk through the entire list of floats and then pick and offset and thats different than this gemoetry calculation
oriol: i think explicit clearance and no explicit clearance are two different things, so we could resolve on that
iank_: but then what are the - whats the different thing
oriol: if you have explicit clearance you could avoid zero px wide, you would be allowed to overlap them
iank_: overlapping only happens interoperably when ? is on the edge of the available space
iank_: it might be different ifyouave got a szero width float and a container with negative margin
iank_: now that float is sitting in the middle of the space and now that calculation doesn't apploy anymore
oriol: i didn't see a difference in webkit but in the other browsers firefox and blink they seem to allow overlapping zeropx wide floats in all the cases i tested without explicit clearance
iank_: maybe? id like to see the test cases
miriam: if we take this back to the issue can we document test cases?
iank_: yeah
oriol: im fine with going back to the issue, resolution about line boxes and independent blocks consistent would make sense?
iank_: i dont think theyre consistent
iank_: ive got a test case here where theyre doing different things in all browsers and theyre rendering the same
oriol: ok you can pause this issue
miriam: resolve to close no change?
oriol: not closing no change but deferring until we can continue the discussion in the issue? if we lead to some agreement then we can move on
iank_: yeah this area its common cases thats constrained by that
iank_: im pretty sure i know most of them
oriol: there are cases where browsers are doing different things so i guess compat is not that improtant?
iank_: sure but i dont think you can say that they are the same where there are cases that are different
miriam: so if we take this back to the issue we need to document compat constraints and then what other test cases are needed
iank_: explicit clearance test cases of zero area then zero width zero height being on the availabl espace boundary and not being on the availba espace boundary since theyll be slightly different behaivors there
iank_: and then i think there are differences between line box and new formatting context
miriam: sounds like were taking it back to the issue?
iank_: yep
[css-position] Static position of abspos top layer elements inside fixed pos.
<TabAtkins> relative static position of absolute positions, fixed
<fantasai> emilio: This is the case where the static position of the abspos that depends on something laid out after it
<fantasai> emilio: annoying because cyclic
<fantasai> emilio: it seems what Blink does is making the static position at the end of the HTML element or something?
<fantasai> emilio: so mostly ignored
<fantasai> emilio: Gecko [missed]
<fantasai> emilio: And WebKit does something else that's incorrect
<fantasai> emilio: Tab's proposal is to ignore static position in top layer
<fantasai> iank_: I believe what happens is we reparent the top layer boxes in the box tree
<fantasai> iank_: so it's a box tree construction effect, not a layout effect
<fantasai> emilio: Conceptually they're reparented anyway because abspos
<fantasai> iank_: Blink doesn't have the concept of a static positoin placeholder like Gecko does
<fantasai> iank_: so as if you moved the placeholder and the thing during box tree insertion
<fantasai> emilio: Think it's best to ignore the static position
<fantasai> iank_: I think we've defined it to be, this happens at box tree time
<fantasai> iank_: or is it defined as something not that?
<fantasai> emilio: in Gecko we have two boxes for this element
<fantasai> emilio: but conceptually the abspos box (primary box) does get reparented
<fantasai> emilio: the static position, conceptually to me, is the position it would have if it wasn't abspos and thus not in top layer
<fantasai> iank_: but if this gets reparented during box tree...
<fantasai> iank_: when you insert abspos into tree in Blink, we don't reparent to the containing block. It sits whereever it lives
<fantasai> emilio: but it gets laid out and painted in a different order
<fantasai> emilio: behavior Blink has is super weird, so prefer to ignore it
<fantasai> iank_: you could just reparent the static position box to the same place?
<fantasai> emilio: yeah but I think it's super weird
<fantasai> iank_: but that's what the spec says?
<fantasai> emilio: I think that depends on whether the spec meant to include the static pos
<fantasai> iank_: staticpos is spec fiction
<fantasai> futhark: Spec currently says "rather than generating boxes as usual, generate boxes as sibling of root element"
<fantasai> futhark: so spec says what we do
<fantasai> futhark: if that's not what we want, then we need to change the spec
<fantasai> emilio: I'm not opposed to close no change and test+clarification in the spec but... it does feel a little unusual
<fantasai> emilio: idk if that would cause issues, because then when destroying boxes you cannot reach ... if you remove an element in the DOM, can't reach descendant elements that are top layer
<fantasai> emilio: prefer to behave as regular abspos, parented to the relevant containing block
<fantasai> emilio: I'm fine with either behavior
<emeyer> fantasai: Could someone describe the situation that creates a cycle?
<emeyer> fantasai: The top layer escapes the fixedpos to go into the top layer?
<emeyer> emilio: Right.
<emeyer> fantasai: Why is the top layer element not asbpos?
<emeyer> emilio: Top-layer things escape their usual containing block rules
<emeyer> iank_: Right, they get lumped on the end of the list for the ICB
<emeyer> iank_: The difference at the moment is Gecko doesn't do this well
<emeyer> iank_: In Gecko the placeholder isn't reparented so you need to lay out a second level of top layer thing to get the correct static position
<emeyer> fantasai: They're both top layer?
<emeyer> iank_: They're both direct descendants of the ICB
<emeyer> fantasai: I agree with Emilio it's super weird to reparent them and have them at the end of the static HTML element
<emeyer> fantasai: I suspect what the spec meant is similar to what happens with fixed position
<emeyer> fantasai: They wanted to make sure it would be painted on top
<emeyer> iank_: Pulling into a separate list at the ICB level achieves what's needed
<emeyer> fantasai: Yeah, the answer is just very weird
<emeyer> …I agree with Emilio that the static position of the element being at the end of the HTML element is super weird from an author's PoV even if that's easy or what the spec currently says
<emilio> https://
<emilio> > Unless overridden by another specification, its static position for left, right, and top is zero.
<emeyer> futhark: In section 3.1 in CSS-position-4, there's a list on top layer styling that the static position for left, right, and top is 0.
<emeyer> TabAtkins: I guarantee I forgot to list out all four
<emeyer> fantasai: I don't know how much review this rewrite has gotten
<emilio> Comes from https://
<emeyer> fantasai: I'm not sure how much reliance I'd put on the validity of the spec since it was copied over from another spec drafted by someone who isn't a CSS layout spec expert
<emeyer> TabAtkins: Since top layer is new, we probably don't have a lot in the way of meaningful compatibility troubles
<emeyer> …So let's just do the simplest possible thing!
<emeyer> …Which is 0,0 static position
<emeyer> iank_: With a zero-width-height static position?
<emeyer> TabAtkins: The concept of static position doesn't exist and everything resolves to zero
<emeyer> iank_: You don't want everything to resolve to zero
<emeyer> TabAtkins: Why not?
<emeyer> iank_: I think you actually just want the static position at 0,0
<emeyer> TabAtkins: I don't understand the objection
<emeyer> iank_: Anchor position sets the alignment differently and strethces
<emeyer> TabAtkins: Oh, yes, we probably want to fix that to not stretch
<emeyer> iank_: Other elements don't support alignment
<emeyer> TabAtkins: If we set it to 0,0 in the corner we don't get the auto-alignment, which we wanted to avoid in anchor positioning
<emeyer> …For legacy reasons, we can't get away with that in abspos
<emeyer> iank_: I think in UA styles, all these things have been set to zero anyway
<emeyer> …Like, you have to set insets to trigger this behavior, right?
<emeyer> emilio: For popover, I think so, but I'm not sure about other things
<emeyer> iank_: I'm fine with saying that static positioning is zeroed out
<emeyer> fantasai: Is that going to make sense for non-fixed-position cases like top layer elements that are halfway down the page?
<emeyer> iank_: Reparenting in the box tree up to the very top, when would that trigger?
<emeyer> fantasai: You scroll halfway down the page and you click on something that's in the top layer
<emeyer> …If it's fixedpos and not in the viewport you can't read the whole thing
<emeyer> …Sometimes it gets pushed into a static position, which makes it scrollable
<emeyer> TabAtkins: The generic answer is, if you want to attach to a thing on the page, use anchor positioning
<emeyer> …We don't need to rely on fixed things that are weird if we have a more powerful variant
<emeyer> (awkward silence)
<emeyer> miriam: I don't feel a need to preserve static positioning generally, and especially not going into the top layer
<emeyer> TabAtkins: Can we just say that then?
<emeyer> …If you're top layer, we do the same as anchor positioning?
<emeyer> fantasai: I think what makes more sense is to define the static position rectangle in the ICB, which I think gives you the right effects
<emeyer> TabAtkins: I don't see why it would, necessarily
<emeyer> …There'd be no connection to its normal position in the DOM
<emeyer> fantasai: I think we want to define the rectangle where it lives and define what that means
<emeyer> …If you set everything to zero then it will anchor to that edge
<emeyer> …We should talk about it offline
<emeyer> TabAtkins: Ah, I see what you mean
<emeyer> …We can resolve on doing something arbitrary
<emeyer> fantasai: Propose to make the static position of the top layer does not depend on the size or position of any other element on the page
<fantasai> fantasai: And probably define by making staticpos rectangle as ICB
<emeyer> miriam: Do we have a thing we can resolve on?
<fantasai> PROPOSED: Make the static position of top layer boxes not depend on the size or position of any other element on the page, likely by making static position rectangle the ICB
<emilio> sgtm
<emeyer> miriam: Any objections?
RESOLUTION: Make the static position of top layer boxes not depend on the size or position of any other element on the page, likely by making static position rectangle the ICB