W3C

– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

11 June 2024

Attendees

Present
(irc-only for most of the morning tho), alisonmaher, andreubotella, andruud, bkardell_, bramus, dholbert, emeyer, fantasai, flackr, florian, fserb, iank_, kbabbitt, khush, kizu, lea, miriam, oriol, rachelandrew, TabAtkins, una, ydaniv
Regrets
-
Chair
-
Scribe
emeyer, jarhar

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/csswg-drafts#6900

Republishing Tasks Permathread

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900.

<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/csswg-drafts#10182

[css-anchor-1] position-visibility show/hide animations

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10182.

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/csswg-drafts#10049

[css-anchor-position] Nailing down the position-try-options "flip" behavior

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10049.

<TabAtkins> https://drafts.csswg.org/css-anchor-position-1/#swap-due-to-a-try-tactic

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/csswg-drafts#9356

[css-anchor-position-1][css-display-4] Anchor Positioning and Display Order

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9356.

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/csswg-drafts#8895

[css-anchor-1] Allow anchoring to a particular fragment

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8895.

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/csswg-drafts#8339 (comment)

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://fantasai.inkedblade.net/style/specs/css-anchor-exploration/#anchor-positioning

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/csswg-drafts#8398

[cssom] How safe is it really to shorthandify properties?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8398.

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

<dbaron> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20style%3D%22margin%3A%202em%22%3E%0A%3Cscript%3E%0Afor%20(var%20i%20in%20document.body.style)%20%7B%0A%20%20document.write(i%20%2B%20%22%3Cbr%3E%22)%3B%0A%7D%0A%3C%2Fscript%3E

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://codepen.io/leaverou/pen/KKLXqBw?editors=1111

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://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cscript%3E%0Avar%20cs%20%3D%20getComputedStyle(document.body)%3B%0Afor%20(var%20i%20%3D%200%3B%20i%20%3C%20cs.length%20%3B%20%2B%2Bi)%20%7B%0A%20%20document.write(cs%5Bi%5D%20%2B%20%22%3Cbr%3E%22)%3B%0A%7D%0A%3C%2Fscript%3E

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/design-principles#300

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/csswg-drafts#9827

[css-anchor-position]: Question: Why is anchor-size() only valid in a sizing property?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9827.

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/csswg-drafts#10314

[css-anchor-position] Resolution of percentages: area or track?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10314.

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://github.com/w3c/csswg-drafts/pull/9285#discussion_r1376720482

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://drafts.csswg.org/css-env-1/#viewport-segments

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/csswg-drafts#5260

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/csswg-drafts#2312

[CSS2] How do zero-width floats affect subsequent content

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2312.

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://codepen.io/stubbornella_old/pen/ExzwbNy

<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12813

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://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12815

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://drafts.csswg.org/css-position-4/#top-styling

<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://github.com/w3c/csswg-drafts/commit/051d37a64ca714fa0238df6db019967de2a086dd fwiw

<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

Summary of resolutions

  1. We request a updated recommendation, with the three proposed changes folded in
  2. when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value
  3. add margin-box and border-box keywords to anchor functions
  4. add properties position-anchor-name and position-anchor-box as longhands of position-anchor
  5. add anchor-size() into the values of properties that take lengths on the list of position-try
  6. Close with no change
  7. define the segments on a new layout viewport object on window tbd
  8. 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
Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/this/visibility/

Failed: s/do this/do the visibility:strongly-hidden thing/

Succeeded: s/forced-hidden/force-hidden/

Succeeded: s/forced-hidden/force-hidden/

Succeeded: s/might/might also/

Succeeded: s/doesn't display them/takes them out of flow/

Succeeded: s/of flow/of flow while not displaying them (more similar effect to display:none)/

Succeeded: s/end/env()/

Succeeded: s/not sure/not sure it's implementable/

Succeeded: s/sufficient/sufficiently convenient/

Succeeded: s/change things now/change the spec normatively/

Succeeded: s/instead of CSS/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/

Succeeded: s/should be something in the HTML/should be something in the HTML. And also should allow anchoring either before or after the element./

Succeeded: s/do it/use IDs/

Succeeded: s/anchors/fragments/

Succeeded: s/keywords/keywords to anchor functions/

Succeeded: s/anchor-position/position-anchor/

Succeeded: s/ARIA is the right approach/asking authors to use ARIA markup directly is the right approach/

Succeeded: s/information on what will be used/information on best practices/

Failed: s/the current proposal doesn't hook/Lastly, the current proposal doesn't hook/

Succeeded: s/discrete/allow-discrete

Succeeded: s/depend/dependence/

Succeeded: s/short and longhands/shorthands in question and their longhands/

Succeeded: s/ but very near>/ but very weird?

Succeeded: s/dbaron:/dbaron,

Succeeded: s/Exceptions make APIs really hard to explain/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./

Succeeded: s/We could really use methods that allow authors to ask what is a shorthand of what/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!)./

Succeeded: s/add to that/add properties to @position-try/

Succeeded: s/onto a pile/onto a pile one by one/

Succeeded: s/depend on the longer-term solution?/depend on the longer-term solution? if not (and it seems not), then let's not discuss the bigger problem _now_.

Succeeded: s/bottom span right/bottom span-right/

Succeeded: s/say 30px/say 30px. The issue is that the 50% is relative to the entire span, when I want it only to be the center/

Succeeded: s/alternate/TabAtkins/

Succeeded: s/meaningful/meaningful?/

Succeeded: s/right: 150%/right: 50%/

Succeeded: s/inset size * 0.5/anchor size * 0.5

Succeeded: s/what it means/what percentages means

Succeeded: s/margin: 10%/margin: 5%/

Succeeded: s/usint/units/

Succeeded: s/???/CSSOM view?

Succeeded: s/window.???/window.visualViewport

Succeeded: s/and ???/and group it under window.viewport

Succeeded: s/this model/the CSSOM/

Succeeded: s/???/visual viewport/

Succeeded: s/??/visual viewport/

Succeeded: s/since we are doing the layout viewport/since pretty much everything is laid out wrt layout viewport?/

Succeeded: s/claranace/clearance/

Succeeded: s/??/I think I tried/

Succeeded: s/link/Blink/

Succeeded: s/the ?/the cyan/

Succeeded: s/? to /explicit clearance and no explicit clearance are two /

Succeeded: s/?/they are the same/

Succeeded: s/crfeates/creates/

Succeeded: s/super weird/super weird from an author's PoV/

Succeeded: s/another spec/another spec drafted by someone who isn't a CSS layout spec expert/

Maybe present: alexis, astearns, dbaron, emilio, futhark, masonf, nicole, …`left

All speakers: alexis, andruud, astearns, bramus, dbaron, emilio, fantasai, flackr, florian, fserb, futhark, iank_, kbabbitt, khush, kizu, lea, masonf, miriam, nicole, oriol, TabAtkins, una, ydaniv, …`left

Active on IRC: alisonmaher, andreubotella, andruud, astearns, bkardell_, bramus, dbaron, dholbert, emeyer, emilio, fantasai, flackr, florian, fserb, futhark, iank_, jarhar, kbabbitt, khush, kizu, lea, masonf, matthieud, miriam, nicole, oriol, rachelandrew, TabAtkins, una, ydaniv