Meeting minutes
<alisonmaher> https://
<astearns> thanks, alisonmaher!
<noamr> Meeting is going to be held at the MS office in NYC, April, see wiki link
<astearns> github-bot, take up w3c/
[css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order
<github-bot> OK, I'll post this discussion to https://
<noamr> miriam: we discussed this at the f2f. we seem to have a solution in the thread. the goal is being able to name layers that are stronger than unlayered styles
<noamr> miriam: the proposal is to have a character before the name that marks that a layer is stronger rather than weaker than unlayered style
<noamr> miriam: we suggested the caret, a concern was raised that the character should not be part of the name. this sent us back. in that thread we've agreed on a path forward, if we're ok going with this
<noamr> miriam: 1. resolving that we're taking on the caret approach at the beginning of the layer name. 2. The caret is syntax rather than a layer name.
<noamr> miriam: this allows one issue to discuss, whether we allow name conflicts between strong and weak layers of the same name
<noamr> miriam: sounds OK?
<noamr> TabAtkins: seems fine. It would have been ok in the name but this is acceptable. for name conflicts, everything gets more complex if we try to prevent conflicts
<noamr> TabAtkins: it's reasonable if weak/strong names are different in the CSSOM, works similar to important
<kizu> +1
<bramus> +1
<noamr> miriam: seems right
<kbabbitt> +1 to the proposal, I had someone ask about this feature the other day
<noamr> rossen: anyone wants to add? challenge?
<noamr> PROPOSED RESOLUTION: we use a caret approach. It's part of the syntax and not part of the name. Weak/strong with the same name is ok
<noamr> bramus: also something about CSSOM?
<noamr> miriam: we expose strength in CSSOM
names come in "strong" and "weak" versions, in the CSSOM there's a bool that reflects this; in the @layer rule a ^ prefix indicates it's strong
RESOLUTION: we use a caret approach. It's part of the syntax and not part of the name. Weak/strong with the same name is ok
<noamr> PROPOSED RESOLUTION: strength is exposed in CSSOM, detailxz TBD
<noamr> rossen: objections?
RESOLUTION: strength is exposed in CSSOM, details tbd.
<noamr> rossen: miriam, you're going to follow up?
<noamr> miriam: sure
<astearns> github-bot, take up w3c/
[css2][css-tables] Do collapsed tracks also shrink the table wrapper box or only the table grid box?
<github-bot> OK, I'll post this discussion to https://
<astearns> github-bot, take up w3c/
[css-borders] Add a 'hairline' border-width value
<github-bot> OK, I'll post this discussion to https://
<noamr> TabAtkins: people look for a hairline border-width, usually "as thinner as visible", something like device pixels
<noamr> TabAtkins: we saw that it's not something that we want to expose because it varies across devices. Authors don't anticipate this change
<noamr> TabAtkins: we'd like to avoid this
<noamr> TabAtkins: device pixels is not always well defined
<noamr> TabAtkins: also it's not clear what happens if it's zoomed
<noamr> TabAtkins: this can become very small
<noamr> TabAtkins: kbabbitt suggested to declare that hairline is exposed as 1px, but rendered in an implementation-defined way, probably something like device pixel aligned
<noamr> TabAtkins: we can define how hairline works for each CSS property, e.g. border/column etc
<noamr> TabAtkins: this would allow accessibility options for users who need to scale the hairline, and this won't mess up design
<noamr> TabAtkins: I suggest we take Kevin's proposal and add it to the border-spec and columns spec for multicol rule, perhaps to other specs that need this
<noamr> smfr: I'm concerned that the painted width is different from the background. it means that the background is going to leak out of the hairline
<noamr> smfr: we can apply the same heuristic, but it seems weird that the geometry doesn't match
<noamr> TabAtkins: we should define that background area extends, but doesn't paint
<noamr> smfr: it doesn't work with box-shadow, adjacent boxes
<noamr> TabAtkins: I think it's a good thing, but probably usually fine
<dholbert> RE the gap, you'd *only* get a gap on a HiDPI screen, which is weird
<noamr> smfr: my suggestion would be that the border-width would be some fractional implementation defined value rather than being different
<noamr> Rossen: I can see how this would work if it takes the outermost part of the pixel, e.g. there should never be background that extends out, same for shadows etc. Anywhere else, you're asking for all of the trouble smfr pointed out
<noamr> TabAtkins: I was describing it wrong. The details in the thread are to have it on the outside, exactly for these issues
<noamr> TabAtkins: let's go with that
<emilio> It reveals the underlying background unless it uses `padding-box` or so right?
yes
<noamr> Rossen: it's going to break things that align, like snapping/abs position etc
<noamr> joshtumath: similar note, the stripes function (not implemented yet). what would happen when we want multiple hairline-width stripes?
<noamr> TabAtkins: I think hairline wouldn't be a generic width value, it's a value for specific properties like border-width
<kizu> Fun fact: Chrome paints `2px double` border as 2 hairline lines with a gap
<noamr> TabAtkins: we'd probably won't paint stripes in a hairline-widdth border
<noamr> emilio: I was going to raise a lot of smfr's concerns. I don't object to hariline value, but I think we can change the border bounding algorithm we have to bound towards the nearest hairline
<noamr> emilio: the UA already aligns pixels e.g. 0.01 border-width to something that's hairline-like
<noamr> emilio: I would prefer to tweak the current border-width rounding to a hairline
<noamr> emilio: for shadows, it's not a huge issue. maybe it's just a matter of implementing stripes
<noamr> emilio: I much rather expose the current border-width rounding and allowing the UA to tweak it, or expose a round-ish function
<smfr> Blink and WebKit round a 0.0001px border up to a hairline; Gecko doesn't draw it
<noamr> Rossen6: also what does this mean for two hairline borders to collapse
<emilio> smfr: Probably pixel precision issue, `0.01px` does get rounded up
<noamr> kbabbitt: I heard that in border the hariline would be painted on the outermost hairline, and the background would fill under that
<noamr> TabAtkins: it's not that the background fills in, it's that the background is drawn under the border area
<noamr> kbabbitt: I want to avoid something where when a designer defines something on a high DPI device it breaks on a different device with lower DPI
<noamr> Rossen6: I'm not sure where this was going. There are still some questions
<noamr> Rossen6: this sounds like a great proposal and something that people are trying to do today
<noamr> Rossen6: is that something we want to pursue? Do we have a good starting point?
<noamr> TabAtkins: we don't have all the details yet
<noamr> TabAtkins: I propose we take this back to the issue
<emilio> TabAtkins: wdyt of `border-snap(<length>)` which just snaps that length as a border or so?
emilio, that's part of why I don't *want* to rely on border rounding. "if you want a hairline, put in a value that is *probably* too small to actually paint, but not *too* small, and you have to guess what "too small" means"
<emilio> I think it's not incompatible with `hairline`, if we make hairline resolve to pixels and affect geometry...
<emilio> fair
<noamr> leaverou/leaverou_: join the call?
<astearns> github-bot, take up w3c/
[css-shapes] Overload `path()` for CSS-y SVG path syntax instead of taking up `shape()`
<github-bot> OK, I'll post this discussion to https://
<lea> on it
<noamr> yay
lea: there's been dsicussion around making paths easier in CSS
lea: so far it's still very closely mapped to SVG paths
lea: taking the design of paths, with its concepts, segments, commands, args, and supporting a CSS syntax for them
lea: that's what we've done with the other shapes already too
lea: polygon(), circle(), etc
lea: so it seems weird that we leave path() as this weird function that just takes a string of SVG, and make a different shape() function for the cssy one
lea: less discoverable and inconsistent
lea: when i filed this issue, thought we might leave shape() for another feature
lea: but now I think overloading path() is better even disregarding that
noamr: shape() does already ahve a few features that SVG doesn't, or does it differently
noamr: order of control points, you can combine rel/abs in the same shape
noamr: now adding corner shapes, that'll probably get added to shape()
noamr: but also, I think path() can still be extended to make it actually usable, by giving it viewbox and fit
<lea> q_
(lea, he meant combining in one command)
noamr: i don't have a strong opposition to calling this path(), but I do think they're a bit different
noamr: shape() is a recipe to create a shape
noamr: once you combine the shape with a reference box, the path you get can be vastly different from what svg coudl make
noamr: so i think keeping shape() separate makes sense as it's a recipe to create paths rather than the path itself
noamr: also the mental model fo path() is closely related to SVG, and if it's extended as I propose it'll stay close to SVG
lea: you mention rounding
lea: i think we eventually want to backport some of these improvement to path, at least those that are feasible
lea: but in general i think a better shape function is useful, it just worries me that we're leaving this gap
lea: authors will expect a CSS syntax for <path> like the other functions/elements have, and they'll find path() and shape() is a different thing
noamr: we dont' have proposals to backport the new stuff to SVG, or filling in gaps
<smfr> +1
noamr: so right now, is this better to give a new name with the intention that it'll continue growing, or should we name it path() and say it's a CSS-ified <path> but with extensions
noamr: I think it ends up just being a name thing
noamr: No strong opinion, but weak pref for shape()
<Rossen6> acl lea
lea: replying to "no proposals for backport"
lea: when designing syntax, it's not just about what proposals exist now, bute what future direciton the language might go to
lea: that's the challenge with standards
lea: things like backporting rounding to <path> is a low-hanging fruit I think we could end up with
lea: so we shoudl plan around it
smfr: I feel more strongly than Noam that shape() is right
smfr: it's more discoverable, search for "css shape function" you'll find it
smfr: I see it being used a lot with future border-shape, so shape() seems natural
smfr: i sympathize with lea that we shoudl design for the future, but we can choose a different name in the feuture if needed
<noamr> TabAtkins: re any backporting/future extensions of path(), to the extent we want to backport anything into SVG, we'll still be spelling it in the SVG way and would probably want to maintain this in-string capability
<noamr> TabAtkins: if we don't backport to SVG, but just add to the string that SVG defines, it would look quite different from what shape is doing, because you can't drop things as easily into a command because of the parsing
<noamr> TabAtkins: anything we add to SVG would probably not make it into the path itsself. I'm not hopeful
<noamr> lea: another benefit is that it's convertable
<noamr> lea: I'm convinced that the current design is good enough. I wonder how much can be backported to path?
<noamr> TabAtkins: what kind of improvements?
<noamr> lea: same segments with CSSified names, length-percentage etc
<noamr> smfr: a more restricted grammar of this
<noamr> lea: sounds perfect
noamr: i'm also okay with taht possibility, think it's doable to take the subset of shape() be ported back to path()
<lea> PROPOSED RESOLUTION: shape() remains as-is, spec subset that is more tightly tied to SVG <path> for a path() overload
Rossen6: so I'm hearing keep shape() as is... [basically restates lea's proposed resolution]
<noamr> +1
<TabAtkins> +1
<smfr> +1
<chrishtr> +1
RESOLUTION: shape() remains as-is, spec subset that is more tightly tied to SVG <path> for a path() overload
<astearns> github-bot, take up w3c/
[css-view-transitions-2] Elements with content-visibility in new Document
<github-bot> OK, I'll post this discussion to https://
noamr: issue with how cross-document VTs, the order that things are discovered for an incoming VT
noamr: We check for the names, and only after check if the element is visible (based on content-visibility:auto)
vmpstr: for initial c-v:auto determination, it happens during "update the rendering" in html
vmpstr: if we ahve an incoming VT, we need to determine which elements are matched to the old doc *prior* to running "update the rendering"
vmpstr: so we have an issue, all the c-v:auto things aren't matched even if they're in the viewport, because we haven't determined their visibiility yet
vmpstr: so proposal is, if we ahve an incoming VT, we run the c-v:auto determination first
vmpstr: this might also apply to same-doc transitions if you've added an element to the DOM with c-v:auto
vmpstr: but it's less clear that's needed, since the same-doc steps happen in a different spot. but we do want the same ability
emilio: are you proposing to run the determination steps again/first, or *move* them?
vmpstr: the initial determination has to just run before the VT matching steps
vmpstr: so i'm proposing that we do it *again* if there's an incoming VT
vmpstr: doesn't duplicate work because the second time it's not the initial determination, it's a subsequent
emilio: I thought VT operations already happened after this, maybe I was wrong
vmpstr: for the cross-doc case, it happens before
vmpstr: it needs to happen before frames are drawn in the new doc
vmpstr: so "udpate the rendering" hasn't run yet
emilio: okay, so cross-doc VT runs the c-v:auto determination explictly, outside the rendering loop
vmpstr: yeah
emilio: it's a little sad, might expect intersection observers to also work...
emilio: maybe it's better to run the whole rendering loop but not point, that seems tricky to define tho
emilio: maybe that's fine, but wondering if we've consdiered larger changes like that
vmpstr: we haven't
vmpstr: the c-v case was a bug report
vmpstr: haven't seen other cases reported yet
vmpstr: don't thi8nk we want to run the rAF handlers without them producing paint
emilio: maybe not, but also it might not be too bad?
emilio: but if you did a c-v:auto-like thing with IO you might want that to run
emilio: seems a bit whack-a-mole if we need to keep adding things for the VT step
vmpstr: if there's script involved, yeah, that won't trigger. but c-v is a CSS thing, so as long as things are declarative they should all "work"
vmpstr: but script is tricky
<smfr> +1 to emilio
emilio: i think my pref would be to try running one frame without painting, that might work, but that's a bit awkward. dont' want to block if you're certain on this approach, just feels a bit special-casey for my taste
bramus: wanted to underline the c-v part affects whether the element is captured or not, authors have reported that
bramus: maybe we can resolve on just the c-v part and then experiment with the frame render?
bramus: some people are blocked on this right now, they can't add the c-v perf improvement to their website due to VTs
emilio: there are two approaches, right? a third is to make c-v:auto not behave as hidden for VT. i think scrollIntoView() already acts like you're visible
emilio: so it's not unheard of
vmpstr: with find-in-page there's no difference, but this would defeat the style optimation for c-v:auto on navigations that have an incoming VT
vmpstr: there's no user action besides the navigation, and we need to run style on the whole document to find names then
vmpstr: we've previously decided that in same-doc, if a c-v auto is off-screen then a sub-element won't be available for VT
emilio: right, point is that you don't have to paint it, you just check for names
Rossen6: out of time on the call, don't feel like we're ready to resolve.
Rossen6: continue discussion in the issue
github-bot, end topic
Rossen6: reminder, breakout on HDR taking place in two hours (noon pacific)
TabAtkins: HDR using this zoom?
astearns: no, different zoom, link in private list
<astearns> HDR zoom link in https://