Meeting minutes
<fantasai> astearns: It looks like https://github.com/w3c/csswg-drafts/issues/3731 didn't make it onto the agenda?
<astearns> fantasai: argh - it still had a milestone from the last FTF, so I missed it. It's in the agenda now
<astearns> zaim, start meeting
<astearns> waiting for a quorum
containing block of column spanners
github: https://github.com/w3c/csswg-drafts/issues/5612
rachelandrew: Good details in the issue
rachelandrew: We dont' have interop
rachelandrew: If you have abspos in a column spanner, not clear the what containing block should be
rachelandrew: Three different options currently
rachelandrew: In the issue it came down that probably either #2 or #3 would be most likely, either viewport (WebKit and EdgeHTML) or the column spanner itself
rachelandrew: I suspect authors would assume the spanner is the containing block, or at least would want that ability
rachelandrew: Option 1 is probablematic anyway
rachelandrew: In gecko it would be harder to implement option 2
rachelandrew: So it's between 2 and 3, viewport and spanner
fantasai: I think option 3 is a little weird - it doesn't ahve relpos
fantasai: And so unless there's something particularly interesting happening on, like transform, elements dont' trap abspos unless they're relpos
fantasai: So I'm totally fine with skipping the fragmenting grandparent
fantasai: But I think it woudl be weird to stop at the spanner and not go up to the multicol itself if *that* has relpos
fantasai: and otherwise fall up to the ICB
iank_: Chrome broadly agrees with that
florian: I was thinking as well
Rossen_: EdgeHTML as well, the spanner is nothing special, you just walk the ancestor chain as normal until you find a positioned element
florian: That's a little different from what fantasai described, i think
florian: If you have a relpos parent of the spanner, if you go by ancestry in the tree, that would capture the abspos
florian: elika was talkinga bout skipping past that straight to the multicol, to avoid fragmentation issues
iank_: Part of the problem is that the spanner isn't really positioned in flow, it's positioned by the multicol, so option 2 is kinda in that direction
fantasai: I think from an author's perspective, yeah, skipping from spanner to multicol would make the most sense since the spanner isn't fragmented
fantasai: That's option 2, yeah; option 3 makes the spanner the containing block regardless of its 'position'
fantasai: So the CB chain should go spanner -> multicol -> normal ancestry from there
florian: I'm confused, option 2 says viewport
astearns: if you read the text it goes into more detail
fantasai: there's no relpos in the example, that's why it goes up to viewport
TYLin: I think option 2 is best, Gecko is buggy in edge cases
astearns: So it sounds like option 2 has consensus, cb chain goes spanner -> multicol and then normal from there
astearns: objections?
Resolution: CB chain goes straight from spanner to the multicol container
end
rachelandrew: I'd also like to publish
chris: I suggest you put "Wide Review" in the SOTD, that serves the same purpose as Last Call used to
<fantasai> https://www.w3.org/Guide/documentreview/
fantasai: And issue review requests, documented in ^^^
chris: If you need help, let us know
iank_: as an fyi, google/microsoft are working on a new fragmentation engine, which is why these issues are coming up now. we might find more; we'll file as we do
astearns: So any objectiosn to publishing a new draft?
Resolution: publish a new WD of multicol after these edits have been committed
Grid and % row tracks and gutter
github: https://github.com/w3c/csswg-drafts/issues/5566
rego: We discussed on Monday, asked for feedback
rego: Rachel had some comments
rachelandrew: The reason I'm seeing %s in use is because people are putting a grid component in an older layout that uses %s, becuase that's how we did things with floats or even flexboxes
rachelandrew: And people generally only cared about columns, then
rachelandrew: I like staying with the symmetry, but I don't know whether authors really expect symmetry. Probably more important that Flex and Grid behave similarly, so I'd be generally okay with the change.
astearns: Can yo usummarize for a resolution?
rego: resolve % of row tracks and gutters of grid with indefinite height to auto for tracks and 0 for gutters
Rossen_: Gonna be the shining voice on the hill
Rossen_: Symmetry was an important part of grid and made it what it was
Rossen_: We're trying to break that principle here. I object to this decision.
Rossen_: But before I do that I want to go back and understand what the current interop is
Rossen_: Because we don't have a 2d layout system that we can have precedent with
Rossen_: We can only have interop between the Grid impls themselves
Rossen_: So are we talking about interop with 1d layout systems like Block and Flex, or between the UA impls?
astearns: Is there a consensus across impls yet?
rego: There are no track interop, there's interop on gutters. Firefox would have to change track, but Mats says he wants to change.
rego: With regards to Rossen's other issues, I don't know about that.
astearns: Rossen, do you have a plan to bring people around to your objection?
Rossen_: Not as part of this call.
Rossen_: Issue is, what's the pressing issue? Why do we need to resolve now? Take it another way - we've discussed this in the apst many times, another fix is to get rid of % in gutters.
fantasai: Far too late for that
Rossen_: But not too late to break grid, apparently?
fantasai: %s in gutters works just fine between columns, and people are using
fantasai: This is just about between rows
(and in an indef height)
fantasai: So what we need is interop between browsers. And right now we have interop on the behavior you want for gap between rows.
fantasai: But we don't have interop for sizing tracks
fantasai: Chrome/webkit have one behavior, the one you wanted iiuc, Firefox has another behavior
fantasai: This is causing problems bc we have impls behaving differently, so rego wants to fix that.
fantasai: So either Firefox has to change their behavior for tracks, or Chrome/WebKit has to; one of those has to happen, then we have interop
fantasai: And if Chrome/WebKit changes behavior, we should make gaps behave the same way as well, which is further change
fantasai: We could theoretically go either way, but we need at least one group of people to switch their behavior.
florian: One step I didn't follow - if Chrome/WebKit align with Firefox, that would mean % on gaps and tracks dont' work the same?
fantasai: Yeah, which is why the issue says if we do that we shoudl also switch the gap behavior, even tho we currently have gap interop.
fantasai: I think that % gaps between rows are rarely used so their behavior isn't a big issue, it's mainly just a cleanup step to keep them consistent.
fantasai: It's really about which behavior we end up with for row sizing
Rossen_: So if current impls impl % row-gaps behavior the same, it's essentially the same behavior that they need for row tracks?
Rossen_: I'm curious about the new Chrome Grid rewrite, which behavior is currently there
Rossen_: It seems like it's the symmetric one, right?
rego: I dunno if the new grid impl has this behavior done yet
[iank_: yo]
Rossen_: What I see currently is that Chrome/Firefox/WebKit have same beahvior
rego: For gutters, yes. For tracks Firefox has the different behavior
<iank_> ops sorry - no currently implemented yet afiak.
<iank_> not*
rego: Firefox resolves % rows to auto, and that's not following the spec, it's alone in that behavior
rego: So if we keep the spec as is, only Firefox has to change.
rego: This proposal would take Firefox's behavior, so the other browsers would change.
rego: When I did back-compat analysis, there were three pages that did better in Firefox and only 1 that did worse
rego: But Chrome/WebKit aren't getting bugs reported on this, despite the lack of interop
astearns: So sounds like we won't have agreement here
rego: Should ask the layoutng people about things
rego: And Mats
astearns: yeah he said yes one way, should see if he's okay with the other way
astearns: So we'll table this for now
:modal pseudo-class for HTML
Dialog element
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/4645
<florian> TabAtkins: there's a discussion in HTML about fixing the dialog element to use CSS instead of being a hack
<florian> TabAtkins: they realized that there's a big difference between
<florian> TabAtkins: when it's opened normaly vs as a modal
<florian> TabAtkins: it's based purely on which js method you use to open it
<florian> TabAtkins: so we need some way to distinguish, and a pseudo class seems most natural
<florian> TabAtkins: the proposal is :modal
<florian> TabAtkins: seems good to me, but we need to make sure we don't want to use it for something else
<florian> leaverou: feels like defining a pseudo class to work around a problem with the API
<florian> leaverou: seems to me that there should be a modal attribute
<florian> leaverou: don't see why we need to fix it in css
<fantasai> +1
<miriam> +1
<brandon> +1
<florian> leaverou: seems weird that you need to use JS, and cannot do it in markup, when you can already use the `open` attribute to open it in a non-modal way
<florian> emilio: toggling the attribute is not the same as calling dialog.open
<florian> emilio: it's bad, but that's the way it is
<emilio> https://github.com/whatwg/html/issues/5802
<florian> iank_: it is a strange API, don't want to add more attributes to it
<leaverou> if the API is messy, maybe it needs more work before we add things to CSS for it?
<florian> gregwhitworth: if this is so bad, and is so confusing, why are we ducktaping this?
<florian> iank_: many sites use it, so there's a big compat risk
<florian> iank_: we aren't happy with how the modal works today, and we're willing to change
<florian> iank_: ... to make it describable in css
<florian> iank_: if we were doing it from scratch today, we'd do it differently
<florian> smfr: modal go in a magic layer of over the page
<florian> smfr: ...
<florian> iank_: ......
<gregwhitworth> smfr: I would like to define the top layer to be used by other elements, it could be used here
smfr: I suggest to use UA stylesheet rules to also describe the top-layer behavior of the modal dialog
iank_: Broadly speaking, this is what the HTML pull request does today. It adds one new pseudo-class, :modal, and removes all of the special-case rendering logic
iank_: and replaces it basically with one additional UA stylesheet rule
iank_: What gives me confidence in this approach is that this is what Gecko does today, using an internal pseudo-class
iank_: One thing it doesn't describe, broader issue, is how does the "top layer" work.
iank_: Tab has previously wanted to explain how that works somewhere else
iank_: This fixes all the special-casing text that was there previously, except fixing top-layer
iank_: Moves us significantly closer
bkardell_: There are a few proposals going back to 2014/15 or so
bkardell_: to explain top layer
bkardell_: not in CSS
bkardell_: but there's prior attempts that exist that are worth looking at
<TabAtkins> fantasai: Going back to Lea's point, why isn't this an attribute on the element?
<TabAtkins> fantasai: We could do all this in the UA stylesheet keyed off an attribute, wouldn't that be more consistent?
<TabAtkins> fantasai: Maybe removing/adding modal doesn't do anything because it's really the show()/hide() methods and how they sync with [open] that's important...
iank_: the open attribute is very special and strange
iank_: wouldn't want to add anything like that
emilio: adding/removing the open attribute doesn't fire the relevant events
emilio: dialog element is expected to be used via JS APIs
<gregwhitworth> iank_: emilio and it wouldn't be web compatible to add those linkages?
emilio: already weird that it has this reflection already
gregwhitworth, if you're talking to someone, use a comma
gregwhitworth, that looks like you're correcting the minutes
emilio: ...
astearns: Her proposal is to add a new modal attribute, not to re-use open
leaverou: can the issues be fixed?
emilio: tangential to this
emilio: removing [open] doesn't fire the right events and fix the behavior currently
emilio: it's not great
emilio: might want to fix it, but it's a separate issue
gregwhitworth: I agree fixing them is a separate issue, but not separate wrt this discussion
gregwhitworth: because I like what leaverou is proposing here
gregwhitworth: In order to make dialog more cohesive, I think we should go back and fix it
gregwhitworth: Is there a massive web-compat problem with making open do the right thing and fire all the events?
iank_: There's a few other pressures here
iank_: I would be concerned with any compat change around that area. Been there for a long while.
iank_: Took us 6 months to do compat analysis just for this change
iank_: and it's a bit pressing
iank_: and with any major compat change, the window closes the longer it exists
<leaverou> it seems to not have shipped in Gecko or WebKit, how popular can it be? https://caniuse.com/?search=dialog
iank_: Yes, we can potentially fix open and how that work, yes we can add modal, but that would take a long time
emilio: My other concern with magic attributes that fire events is XSS
emilio: DETAILS fires an event even when you parse it
emilio: and we only realized about DETAILS way too late
iank_: I don't think having an attribute API for dialog is a good idea
iank_: I would push back against adding a modal attribute on that basis
gregwhitworth: Then, channeling Rossen from Grid, I think we should be going for symmetry
gregwhitworth: Not fixing open maybe but get rid of it
astearns: This discussion seems to be opening wider and wider. Maybe kick over to Open UI?
astearns: to discuss pseudo vs. attribute vs. no attribute?
iank_: If we want to get rid of Chrome's special dialog behavior here, we can only do this for another few months
iank_: People will be relying on dialog, and will rely on our behavior. So would like a decision now.
iank_: At the request of this group and other browser vendors, did a lot of compat analysis
iank_: ...
<gregwhitworth> fantasai, I'll scribe ya
emilio: My other bit about why I think modal attibute is not a great idea is that it breaks how the JS APIs structure
emilio: Whether modal pseudo-class applies depends on how you open the dialog
emilio: but you could toggle modal attribute while the dialog is open
<leaverou> re: webcompat, <dialog> is used in <0.005% of websites (6000 in HTTPArchive): https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/edit#gid=781932961
emilio: At the point you can toggle modal, ...
emilio: I think that would be great
emilio: but fixing dialog positioning is important, would rather not get side-tracked
<gregwhitworth> fantasai: so I agree with iank_ we should fix the styling issue for compat
<gregwhitworth> fantasai: clearly, it will take a while for a modal attribute - maybe that's still a possibility
<gregwhitworth> fantasai: one is that we intro a new pseudo class that everyone can use
<gregwhitworth> fantasai: other option is to do one internally the way that FF is doing
<gregwhitworth> fantasai: then we decide how to move forward via a pseudo class and attribute
TabAtkins: We seem to have fairly broad implementer agreement that they likely don't want to add modal
TabAtkins: Going back, we could maybe pursue removing open attribute
TabAtkins: so that's a possibility for us
leaverou: Adding a modal attribute is just a possibility. Could alternately add a value to open
leaverou: open=modal
leaverou: But goes back to ???
leaverou: Introducing HTML elements that can't be used without JS is an issue
leaverou: Shouldn't we fix this generally?
<leaverou> It sounds like the same arguments apply to <details> as well
<leaverou> Is the direction we want to go to be adding interactive HTML elements that can't work without JS?!
<leaverou> shouldn't these issues be addressed instead of giving up on HTML attributes altogether?
emilio: leaverou, and gregwhitworth, would you be opposed to defining a hidden pseudo-class, so we can move forward with the styling issue without changing the public API of this ?
emilio: It's nice to expose the pseudo-class from the UA stylesheet
emilio: but also fine with keeping it internal
<iank_> i can live w/ that as well.
emilio: and address the open/modal attributes separately from this
astearns: So proposed solution is to add a hidden :modal pseudo-class for now.
florian: Do we need to define that a hidden pseudo-class exists? Do we need to spec anything?
TabAtkins: no
emilio: Define in HTML spec using prose instead of a pseudo, but that's fine
astearns: We'd spec as browser-internal thing, and then if it proves out, then we write spec text to expose it
leaverou: Is a hidden pseudo-class undocumented or unusable by authors?
TabAtkins: only usable in UA style sheet
gregwhitworth: I think it's a good compromise.
gregwhitworth: Deals with compat issue, but leaves the door open to imprve the API
gregwhitworth: Maybe worth noting it somewhere?
iank_: We'll be adding this to the HTML spec , most likely way to specify this
<TabAtkins> Yes, this is the correct way to do it
iank_: is to define the :modal pseudo-class and define that it's only usable in UA stylesheet
iank_: maybe call it :-internal-modal
Resolution: Add a hidden pseudo-class for this purpose, in order to solve styling issue while leavine open the possibility of HTML improving its API
css logical properties ordering
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3029
fantasai: Probably best to look at this diagram at the bottom
<fantasai> https://github.com/w3c/csswg-drafts/issues/3029#issuecomment-712953765
fantasai: We've got a set of logical props and physical props
fantasai: So if we ltr parent and rtl child
fantasai: ltr parent has some set of properties on it that give it margins on either side
fantasai: and the child has specified "margin-start: inhert"
fantasai: So what does that mean
fantasai: From the parent's left margin (the parent's start) or the right amrgin (the child's start)
<myles> ```
fantasai: Currently impls map start/end to a physical side on the child, using the child's writing mode, then inherit from the parent's corresponding physical margin
fantasai: The other possible behavior, which is possibly better, is that the child inherits its start value from the start value of the parent
<myles> <div id="outer" style="padding-left: 20px padding-right: 30px;" dir="ltr">
<myles> <div id="inner" style="padding-inline-end: inherit" dir="rtl"></div>
<myles> </div>
fantasai: Note taht by the time we ahve computed values, which is what we inherit, the left&start margins are set to the same value, and the right&end are set to the same, regardless of how they were specified
florian: We don't have any property that is logical & inherited where this shows up without you explicitly saying 'inherit', right?
fantasai: Right, not so far.
fantasai: But if we did, I suspect we'd want the start margin of the child to inherit from the start margin of the parent, not from the amtching physical side
fantasai: That's my suspicion, at least
fremy: That's also my assessment
fremy: If you wanted to inherit the right margin, you'd have said "margin-right". If you say margin-start, you want the start margin
fremy: If you had text-indent, you want the text-indent value, whether it's ltr or rtl.
myles: We're positive on this change to have the writing mode resolved based on the parent, not the child, for inheritance
myles: Two reasons for this
myles: fremy gave an argumen tfrom the author's perspective
myles: But i think the user wants it too - if they're reading a book where paragraphs have a padding on one side, and one paragraph is has a different wm, the padding should probably flip sides
myles: Second is that it makes logical props more of a first-class citizen
myles: This means inheritance doesn't "prefer" physical props, you inherit what's specified, so that logical properties are more of a first-class citizens
myles: That's good for the world and authors, but also good for impls
myles: Right now our code is a little more complicated than it could be to make it prefer physical props
astearns: I'm assuming, r12a, that you're okay with this proposal?
<fantasai> /citizens/citizen/
r12a: Yes, I think I suggested this in the first place, so I'm happy with it
proposed resolution: inheritance of logical properties inherts the corresponding logical proeprty on the parent
emilio: A bit skeptical that this is easier to implement. you only store one value in the computed style, a physical one
emilio: So this breaks some computed-style optimizations
emilio: When two props map to one value, you have to choose one or the other, and right now impls agree with using the physical one, which they store in the style
emilio: So this means you have to add a pass after applying declarations, to know if your writing mode is different, you should inherit them differently
astearns: So you're saying the impl may be more difficult than stated, but are you objecting?
<Zakim> myles, you wanted to react to emilio
emilio: I think it woudl be unfortunate, especially given current interop, but I dont' think I have an objection until I try to implement and it's gross
myles: So you mentioned that we only store one set of values. That's true; netiehr proposal requires us to store multiple values
emilio: Right, but when you inherit a style you have a coypable part of the style which is what inherits
emilio: All impls separate inherited data and non-inherited
emilio: So if any of them come from a logical prop, you'll need to do the work and inherit it specially with the writing mode of the parent
emilio: So it breaks the simple "pointer bump" impl
myles: I agree that would be an issue if this was a common thing
emilio: Right. So I think maybe your'e just moving a special case from on eplace to another, but...
astearns: So, any objections?
Resolution: inheritance of logical properties inherts the corresponding logical proeprty on the parent
<br until=":30">
end
which direction to use when slicing inline borders/backgrounds
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4989
dbaron said the rules for box-decor-break slice are not clear
fantasai: but the spec is not clear on which direction you should use for the splicing
fantasai: either the inline element itself
fantasai: or the parent block
fantasai: and I would suggest to use the inline
fantasai: for example if you used a rainbow gradient it should splice in the direction of the element
florian: I am confused about what the alternative would do
florian: but I agree that what you described sounds like the right solution
Rossen_: ok sounds reasonable
Rossen_: any objection to resolve this?
Rossen_: (repeats r12a question on irc)
r12a: if you add unicode ?conference? you can move to the next line, not unicode
r12a: and in this case it would not to that in terms of what the text actually does
r12a: but in terms of rendering maybe it does
florian: for the border, you want the side that is the side on the end of the line to be open
florian: but that doesn't match what we just discussed with the background
r12a: yes, we should probably look at a few examples
r12a: I can provide examples if the group wants
Rossen_: that sounds great
Rossen_: (the examples)
Rossen_: fantasai does that change your mind?
<r12a> https://r12a.github.io/scripts/tutorial/part5#latin-in-rtl
fantasai: yes, let's take another look after we considred all the examples
Rossen_: ok, if the examples don't break everything (no pun intended) we will resolve what we decided
Rossen_: but otherwise we will rediscuss
Specify that ink overflow doesn't fragment?
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4099
fantasai: we don't specify if ink-overflow gets paginated or not
fantasai: I think we should say it does not
fantasai: that's my proposal
<astearns> +1 from me
Rossen_: that sounds like a reasonable resolution indeed
<jfkthame> +1
myles: if it doesn't cause scrollbars it shouldn't cause new pages
fantasai: that was my reasoning
Rossen_: ok, any objection?
smfr: also box-shadow?
fantasai: yes
fantasai: if it renders across adjacent columns, that's fine
fantasai: but it should not fragment in the fragmentation direction
Rossen_: so if the box shadow is long, and it goes beyond the end of the page
Rossen_: then we don't create a page for that shadow
Rossen_: but if there is content that generate the page, then we don't drop the shadow
smfr: yes, both cases were things I considered
florian: ink overflow does not cause new fragmentainers to exist
florian: I don't think we have reached consensus on the first question if the fragmentainer exists anyway
fantasai: these are things you don't want to slice though, such as parts of glyphs that are outside the bounding box
fantasai: so if the things that generate the shadow is in two fragmentainers, you get it in both places
<astearns> I agree with fantasai on where ink overflow should get rendered
fantasai: but if there is no reason to draw it because the item itself doesn't fragment, then you don't draw it
Rossen_: we can split in two resolutions
Rossen_: the first one is mature
Rossen_: whether or not you create a new fragment
Rossen_: depends on content
Rossen_: and ink overflow does not cause the creation of a new fragment
fantasai: what I want to define is that you don't fragment ink overflow. Neither can it cause new fragmentainers, nor can it be sliced across them if they exist
Rossen_: that would be the combination of the two resolutions
<faceless2> +1 to Elika's proposal.
jensimmons: something I have seen is that the shadow sometimes appear at the top of the next column and it's weird
iank_: we consider that a bug indeed
Rossen_: let's try to take the super resolution
Rossen_: the ink overflow does not cause new fragments to exist, and does not fragment
Resolution: ink overflow does not cause new fragments to exist, and does not fragment
orphans and widows for fragmented monolithic replaced elements
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3405
fantasai: this is a feature request for fragmentation level 4
fantasai: it would be nice to control widow/orphan in a more monolithic way
fantasai: it would be a length instead
fantasai: and thus cannot inherit so we need a new property
fantasai: it would say how much space you need on the page to accept to start flushing in the container
fantasai: proposal would be widow-something: <length> or something
faceless2: I don't think the name should be widow/orphan its a different concept
florian: maybe I misrember but I think we are not supposed to split monolithic elements at all
florian: so the default value should be 100% right?
florian: (split only happens if you cannot fit)
fantasai: we want to control that
fantasai: and that is the next issue
florian: why a different toggle?
florian: if you have 100%
fantasai: yes, but break-inside is more reasonable to find for authors
florian: yes, that's true
Rossen_: are we discussing accepting the proposal?
myles: is my understanding correct to say that they don'
myles: t like when 3px of their image appears at the end of a page
myles: and the rest gets displayed on the next page?
fantasai: yes
myles: ok
Rossen_: any other thought?
florian: I am not sure it's a different than the break-inside thing
florian: for example on some images there might be only three points where you want to break
<tantek> interesting, the image breaking equivalent of soft-hypens
Rossen_: is that a reason to hold off on the proposal?
florian: I think it's weird to have a toggle for something
florian: that we can't do yet
fantasai: we slice if it doesnt fit
florian: but we might want different if it is forced or not
JonathanNeal: seems to be refinements of break-inside to me
<florian> +1 to jfkthame
JonathanNeal: so sub-properties of break-inside
fantasai: we don't control where you can break in break-inside
fantasai: break-inside, so far, is only whether you can break or not
fantasai: I think this is a good separation to have
myles: also, there are two values, bottom and top
myles: if the sum is bigger than 100%, what happens?
fantasai: can't break anywhere
florian: but then you are back to the case where you have to differentiate whether you are in the normal case or the error case
fantasai: if needed you slice wherever
myles: in the case I described, we would not slice though, right?
fantasai: you slice
myles: I am confused
myles: let me restate
<myles> you have an image that's 100px tall
<myles> the fragmentainer is 75px tall
<myles> and you use both of these properties to say "don't break within 80px of the top and don't break within 80px of the bottom"
<myles> <fin>
<myles> this would overflow, right?
Rossen_: (btw we only try to decide if we want to work on this, don't need to have all the details nailed in)
fantasai: several things happen
fantasai: let's start with 120px fragmentainer
fantasai: in that case, we move the image to the next fragmentainer
fantasai: now, if the fragmentainer is smaller
fantasai: we are going to ignore the restrictions
fantasai: so we do slice at 75px
fantasai: though in theory, the ua is allowed to break anywhere
fantasai: there is a further proposal to add toggles for this, but this would remain an opt-in
fantasai: by default we make sure all the content is rendered
myles: got it
Rossen_: so, do we feel we want to pursue this?
Rossen_: and add to break-4
Rossen_: any objection?
Resolution: work on a mechanism to control where slicing is allowed as a length from either side of the monolithic element
Controlling fragmentation of block-level replaced elements
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3404
Should fragmentation of block-level replaced-elements be configurable? (“object-slice”)
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3404
fantasai: the issue is that, for replaced elements, we can't control whether they are breaking or not
fantasai: we would like to add a control to say "hey, even if you could avoid slicing, you don't need to"
fantasai: the proposal would be to add a new property for this
fantasai: I would rather add a value for break-inside
fantasai: then if you add "allow" then we trigger this behavior
fantasai: auto is avoid for replaced and allow for non-replaced
fantasai: in the future, we can also add "never" which is not like "avoid" because it doesn't even slice, it justs get clipped
fantasai: this should be a different issue though, let;s walk back
fantasai: I would like to propose "break-inside: allow" that would enable to slice a replaced element
florian: we should accept this otherwhise what we accepted in the previous issue doesn't make much sense
florian: so I am in support
Rossen_: any other thoughts?
Rossen_: hearing no other remark, let's call for objections
Resolution: add "break-inside: allow" to enable slicing of images even if they could fit in the next page
fantasai: can we discuss the "never" value?
fantasai: I would like to suggest taking this here
fantasai: we add "never" which prevent slicing if slicing would be necessary, and then we just clip
fantasai: it's fine because it's an opt-in
Rossen_: do we want to resolve this now?
Rossen_: the name "never" seems a bit too strong
florian: that's not the meaning of never we want here
fantasai: we just overflow and clip
myles: the last issue we said the reverse
florian: yes, that is the 'avoid' behavior
florian: the proposal is to add a new behavior
faceless2: but you have to print it right?
faceless2: engines don't slice an image now
fantasai: I am pretty sure it's not true
fantasai: avoid allows to slice across pages as a last resolt
<jfkthame> +1 to florian
florian: this proposal is to disallow that
Rossen_: the name confused me
Rossen_: but this could be lack of caffeine
Rossen_: do we really want to take this now?
Rossen_: it's a break 4 thing, let's maybe open a new issue
Rossen_: unless fantasai you feel strongly we should resolve now
fantasai: no we don't need to, but it would be nice
Rossen_: and the resolution we just took covers that no?
fantasai: no it's a different behavior. We discussed allowing things to break without avoidance, that currently avoid breaking (by moving to a next page first). The other option discussing now is to forbid breaking.
Rossen_: ok, let's resolve on keep working on this
Rossen_: but with keyword tbd
myles: reading through the thread, one of the issue is that there are no example use cases
myles: and I think it would be useful to have them, because we could hit cases
myles: like what you can fit in the first column would be 1px
myles: so we should think about this more
Rossen_: the way I'm perceiving this is very similar to ink-overflow, it's just decorative like it's an image but it works like a shadow or something
Rossen_: I need that decoration to take some space, but when printing I don't care about it
Rossen_: at least that's what I understood
Rossen_: but I don't know how frequently this is needed
florian: if that's the use case, you don't need that behavior
florian: because you don't want to push if possible to the next page
myles: yes, in this case, you don't want the decoration at the top of the next column
myles: so this is not what we described there
florian: ok, let's open a new issue to review use cases
Rossen_: let's move to the next issue
CSSOM scrollWidth/scrollHeight behaviour of “overflow: clip”
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5572
Rossen_: iank_ raised this and emilo last added to the agenda
Rossen_: who want to bring us up to speed?
emilio: me
emilio: we considered what scrollWidth/Height should return when overflow-clip is set
emilio: there is not scrollbar
emilio: but there is content out there
emilio: the question is should we return the size as if there was scrollbar
<TabAtkins> +1 to behaving the same as visible, at least from first thoughts
emilio: I think acting as visible is easier
emilio: but iank_ said there is an optimization
iank_: if you have overflow:hidden can be scrolled
iank_: for visible, it still makes sense to return the full value, because it will cause scrollbars on ancestors
<TabAtkins> Hm, okay, Ian's making sense
iank_: when you clip though, it's not useful, because it really does not exist
iank_: but if you don't do that, you can return early
iank_: because you don't need to calculate the scrollable overflow for the element when the value is fetched
iank_: but it's not super important and only works if clip is in both directions
smfr: the other option was what?
iank_: report as if you had no children
iank_: if the size is definite and you clip overflow, you don't need to layout the children
iank_: but it's a small case
smfr: and offsetWidth/offsetHeight?
iank_: yes, this is the same as what I had in mind
smfr: oh, in that case, yes, I prefer that option slightly
Rossen_: other opinion?
iank_: if I had to choose I would probably try to keep things consistent, but I really don't mind
iank_: we just need to do something
Rossen_: ok, let's get a summary of the two options and resolve
iank_: option 1 is to do what we do when overflow:visible is applied (you need to layout the children to report that width)
iank_: option 2: (ignoring overflow-clip-margin) report the size of the element ignoring whether or not you have something that will be clipped
iank_: but if you have a clip margin, you need to do the full computation to see where inside that margin you land
Rossen_: (restates the two proposals)
fantasai: scrollWidth scrollHeight are asked on an element which is not scrollable
fantasai: does that mean they are defined on all elements
emilio: yes
fantasai: ok, then, if we have a clipping, what happens if you have a border?
iank_: they return content-box sizes, so it's a bit complicated
fantasai: padding box you mean?
iank_: yes, padding box size
iank_: if you have no children, this is clientWidth/clientHeight, which is the padding box
iank_: if you have a child, it returns whichever is bigger (the padding box or that child)
iank_: so if you set overflow-clip with no margin, you can return the padding box because the child will not overextend
iank_: but this only works if you dont have a margin
iank_: if you have a margin, there could be an overflow
iank_: so you need to do the full computation
fantasai: the advantage of the doing like visible is that you get the value that tells you "how big should it be not to overflow"
fantasai: the advantage of taking the clip into account, is that you know how much you will ask the parent scroller
iank_: with proposal 2 you can't get answer 1
iank_: but with proposal 1 you can compute the difference yourself
Rossen_: this seems more clear now
Rossen_: for "what you see is what you get" option 2 is nicer
Rossen_: I don't want to do a straw poll, let's try to resolve
Rossen_: can we resolve on option 2 which takes into account the visual clipping?
emilio: I lean towards option 1
emilio: because I don't see strong arguments
emilio: and for testing purposes, we can copy all the tests
emilio: and we have shipped like that
emilio: but this is not a super strong argument
emilio: but given option 2 removes your ability to get the value of option 1
emilio: I would rather we did 1
Rossen_: if you want to get the bounds for the clip, what do you do?
iank_: in script, you get the style of the clipping, then you do Math.min
iank_: between scrollWidth and offsetWidth + the clip margin
Rossen_: authors might not think about it
Rossen_: and very often it's more useful to consider what is visible
emilio: I don't disagree it's useful
emilio: but scrollWidth is not the right API for that
emilio: it's weird and legacy, so I would rather not change it
Rossen_: ok let's do a poll
<fantasai> Given the arguments in favor of emilio's position, and the fact that you can get answers to the second question fairly easily with the first option but not the other way around, I'd be in favor of emilio's position
Rossen_: because it's pretty split
smfr: if we have scrollWidth behave like overflow:visible
smfr: then you can't get the data and know if you can flip to visible without overflow
fantasai: yes, option 2 hides info from authors you can't get otherwise
fantasai: it's not great
Rossen_: ok, then le'ts resolve for option 1
Resolution: scrollWidth/scrollHeight ignore overflow:clip when computing the value
Break
Existence of ::marker::marker
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/1793
<fantasai> https://github.com/w3c/csswg-drafts/issues/1793#issuecomment-708072107
<florian_irc> fantasai: This is a follow to previous decisions on ::marker
<florian_irc> fantasai: we didn't want to have infinite markers
<florian_irc> fantasai: so you cannot have ::marker::marker
<florian_irc> fantasai: right now ::marker doesn't accept the display property
<florian_irc> fantasai: so, is ::marker::marker invalid?
<florian_irc> fantasai: and, in the future, if we want to allow display on ::marker
<florian_irc> fantasai: then, do we force it to compute display so that it loses its list item
<florian_irc> Rossen_: so, taking things one at a time, should we allow ::marker::marker
<florian_irc> fantasai: I'd like to make it invalid
<florian_irc> TabAtkins: browsers don't support it
<tantek> +1 on no ::marker::marker
<florian_irc> oriol: implementations are behind flags, so not too relevant
<florian_irc> oriol: in firefox, no nested pseudos
<florian_irc> oriol: in chrome ::before::marker and ::after::marker work, but ::marker::marker doesn't
<florian_irc> oriol: but then the styles don't quite work anyway
<florian_irc> oriol: so I'd prefer to keep it invalid
<florian_irc> Rossen_: any objection to ::marker::marker being invalid
Resolution: ::marker::marker is invalid
<florian_irc> fantasai: in the future, when display applies to ::marker, should it lose the list itemness
<florian_irc> oriol: seems reasonable
<florian_irc> Rossen_: me too
Resolution: accept proposal above
accent-color
masonfreed: Summary is I closed the "interopability thread" - question I was trying to ask was whether we wanted precise control over where accent colors should go on a control
masonfreed: Think I got the answer I needed - we dont' want to do so.
<astearns> github: https://github.com/w3c/csswg-drafts/issues/5187
masonfreed: Majority opinion seems to be that we want this to be more of a hint to the UA - "accent-color: purple" means "use purple on this control if you can if it makes sense".
masonfreed: Not "put this purple on the checkbox background", more of a hint instead
masonfreed: So I'd like to get a reoslution from the grou pon this direction
<fantasai> sgtm
<fantasai> TabAtkins: I'm not sure this is exactly the right direction, fine with it as long as we adopt something like what fantasai said, where we require the UA's chosen colors contrast appropriately with the accent-color
<fantasai> TabAtkins: UA can't put black on black ifyou specify accent-color:black
<fantasai> TabAtkins: With that, sounds fine
<fantasai> Rossen_: you can't ignore the accent color?
<fantasai> fantasai: can always ignore it...
jensimmons: I think how Mason described it is good and realistic
<fantasai> jensimmons: I think the way Mason described is really good, more realistic to where we are
<fantasai> jensimmons: more time to solve the problem of robus styling
jensimmons: Allows us to give authors something useful and gives us time to solve the problems more robustly
florian: Roughly in line with all that. As long as the hint involves the requirement that contrast must work.
florian: Don't think we have a resolution on one vs many colors, but we can decide that later
<Rossen_> acj florian
florian: I think there is an appetite for precise control, but that requires a more robust solution. Should od that too, but shouldn't conflate with this.
Rossen_: Taking the lack of queue as meaning we've said everything we need. Objections?
proposed resolution: adopt accent-color as a hint to the UA, with requirements on contrast
<tantek> I think we're ok with that too
Resolution: adopt accent-color as a hint to the UA, with requirements on contrast
masonfreed: We probably need to discuss the 1 vs many colors question later
Rossen_: yes
fantasai: I think we should put this into UI 4, should we let the editors put that in, and discuss 1 vs many colors separately?
astearns: Would Mason like to become an editor?
masonfreed: "want" is strong, but I'm willing to do it
florian: Happy to have help
fantasai: There is proposed text already
Rossen_: Objections to adding Mason as UI 4 editor?
Resolution: Mason Freed added as UI 4 editor
::selection vs ::inactive-selection
github: https://github.com/w3c/csswg-drafts/issues/4579
<masonfreed> tantek, thanks. I think.
fantasai: We'd talked about replacing the selection/inactive-selection distinction with a MQ for whether th eparent window is inactive
fantasai: So question is if we're actually doing that, should I remove ::inactive-selection from Pseudo and open an MQ issue?
florian: Seems good, but it seemed there was an active question about how much nuance there is about active vs inactive iframes?
fantasai: It seemed commented that we could get by with just the two, but we can make this an issue for the WG.
TabAtkins: Since impls dont' have ::inactive-selection anyway, we can decide that later?
GameMaker: Looking at the PDF at the bottom, I made a comparison of all browsers
GameMaker: Can't recall exact thoughts at the time, but based on these results, I was fine with making a MQ
Rossen_: So what's the proposed resolution?
fantasai: Removed ::inactive-selection from Pseudo 4, and add an issue on MQ to add an active-window media feature
Rossen_: Objections?
florian_irc: Are we removing it while we're thinking about it, and it's gone? Or will we maybe put it back?
florian_irc: Asking because we have tests for this - should I mark as tentative, or delete?
fantasai: Mark as tentative until we're totally finished on this issue. Good chance we can just revise later
Resolution: Remove ::inactive-selection from Pseudo 4, and add an issue on MQ to add an active-window media feature
end
<tantek> might want to check out the #tpac and #tpac-chat channels too