Meeting minutes
scribenick emeyer
[css-backgrounds] Specify exact pixel values for border-width: thin, medium, thick
Github: https://
TabAtkins: Was noticed that we still leave the keyword thicknesses undefined. But all browsers agree on widths at 1px, 3px, 5px.
… Not sure of the exact history, but absent that, the widths are very consistent and don’t see a good reason to leave them undefined.
fantasai: Maybe it was that these were like font-size keywords and left open to interpretation. We should maybe recommend but not require specific widths.
<fantasai> My suggested wording was “For Web compatibility, it is recommended that these keywords be mapped to 1px, 3px, and 5px, respectively.”
TabAtkins: On the other hand, we specify a lot of things that could be adjusted by e-readers. I don’t know that this needs to be left undefined.
… I argue we should go stronger than suggested.
dbaron: This is one of those things that was left up in the air in CSS1, and I don’t remember a proposal to define more precisely. I support the precise definition.
fantasai: If everyone else agrees, that’s fine.
RESOLUTION: thin, medium, and thick will be defined as 1px, 3px, and 5px respectively.
[css-lists] counter-reset in UA sheet causing some compat issues.
[css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties?
Github: https://
TabAtkins: Issue 4431 asked to turn box-shadow into a shorthand. Very reasonable. Because it’s a list-valued property, we’d have to make all longhands the same. It was brought up by dbaron that whenever you have these groups of longhands and have to sync up all the values, it’s problematic for implementations.
… What exactly are the reasons, and to what degree should we be avoiding them? This touches on some things being proposed and probably coming, like Toggles. It would be good to know how careful we need to be.
dbaron: I’m most familiar with an implementation that no longer exists, so this may be questionable input, but my experience was that it was a LOT of code to implement these.
… Given that, it’s not a that strong a preference. It’s a case where you can get properties where 90% of the work is parsing, not implementation on the other end.
<lea> syncing up list-valued longhands is also a problem for authors. This does not match a human's mental model about this at all
TabAtkins: Do you recall if it was a particular type of syncing up, or if it was all equally hard.
dbaron: I think it was they were all equally difficult and yet things were sufficiently different that you couldn’t coalesce.
TabAtkins: We should get input from people working on extant rendering engines. Anyone on the call that knows about that?
astearns: Doesn’t sound like we have current implementation experience here on the call. Lea did mention a problem for authors.
<fremy> +1 leaverou
lea: When authors think about list-value properties, they think of each thing as a unit. They think, I want this image at this size in this place, and the syntax forces them to do things in a way they don’t think about it.
TabAtkins: Agreed.
lea: Right, this makes sense with single values.
TabAtkins: We’re asking if it’s okay to expand for things that are list values.
florian: When used with a single value on the list, it’s useful to break up. Authors can help by defining custom properties that define certain combinations.
TabAtkins: That’s partially true. Authors can work around the present situation, and that’s good. But forcing them to work around a lot when we could take that need away isn’t great.
… If we can avoid this being necessary in common cases, that would be great.
astearns: The issue is whether we’re going to more closely specify computed values of list values.
Sebastian: It’s not completely defined yet but most or all list-valued properties base their logic on the definition for background. So they’re just referring to that and still differ on implementation. Even within one engine.
astearns: The difference is something we need to address even if implementation difficulty is a problem. I’m wondering whether we can get to a resolution about that specific difference and then people can start implementation to give feedback on difficulty.
TabAtkins: I’d like to have an idea of the matrix of current possibilities.
fantasai: The main question is are the lists truncated or extended at compute time or use-value time? Specification says use-value. It was suggested this might be easier if compute time was used. The difference in behavior will affect inheriting, which most of these properties don’t do, and might affect result of getComputedStyle.
… I don’t think it would be a problem to switch over to say list-matching happens at computed value time, but don’t know if that would make implementation easier.
astearns: We need to clarify what the current implementations do, how difficult it would be to change, and what we’d like to do in general at computed value time. We should take it back to the issue.
[css-overflow-3] Clarify padding in overflow content
Github: https://
iank_: Browser have been very inconsistent about when something is a scroll container to apply block- or inline-end padding.
… Chrome very slowly has been moving towards end padding in both inline and block directions in block layout mode.
iank_: I added an exhaustive set of tests that’s linked in the comment. This test creates a zero-area div and then relposed out of the way, but that zero area div is used to push padding out in either inline or block direction is various writing modes.
… As I was reading back through the issue, there was a conception that there are two cases that should behave the same. If you’ve got inline content that’s very long in a scroll behavior, it should behave the same as if it’s been warpped in a div. But the div isn’t intrinsically sized and won’t push parent padding out.
astearns: The test cases you’re talking about are supported by spec text?
iank_: Yes.
florian: We have a conceptual agreement that adding the padding would be good, but there might be web compatibility issues because if scrollbars show up where they didn’t used to be, that could be a problem.
iank_: The spec text has written down our current behavior. We’re shipping that behavior now.
<TabAtkins> spec text: "Including this padding is optional for block containers in the inline axis if align-content is normal." with a note saying "hopefully this isn't optional, we're waiting for web compat"
fantasai: Do we want to tighten up the spec now, or wait to tighten it up once there’s field data?
astearns: Has there been enough time to evaluate web compatibility?
iank_: We think so. We shipped the “scary” behavior a couple of months ago and got zero pushback.
florian: If other implementors are happy with it, would be happy to tighten the spec now.
dholbert: This sounds fine to me, speaking from Firefox’s perspective. Having the Web-compat concern removed makes this pretty straightforward.
smfr: Seems reasonable.
RESOLUTION: Always require inline-end padding to be added against the inline-end alignment edge for block/flow layout when it’s a scroll container, thus matching the tests.
[css-pseudo] highlight pseudos and emphasis/underline properties
Github: https://
delan: Highlight pseudos have a restricted subset of applicable properties. Not all properties in the text-decoration spec start with text-decoration-*. Question originally was, can we add those and make them applicable. I initially thought we should. fantasai and rego have mentioned most of the text-emphasis-* properties shouldn’t be applicable.
… Maybe only text-emphasis-color should be applied. That’s where we are now.
astearns: I’m a little worried that the proposed patch is still a little vague. Should we be very specific about what can be applied?
fantasai: I don’t think we should be very specific, because as more things are added elsewhere, user agents should be free to add them here. I think the proposed wording is good enough for now.
<tantek> +1 fantasai
delan: In general, we’re happy with all the properties related to line decorations being applicable?
fantasai: Right.
delan: So it’s the emphasis marks that are contentious.
smfr: Are we avoiding properties that can cause ink or layout overflow?
delan: Ink overflow yes, layout overflow no.
fantasai: Ink overflow doesn’t trigger scrollbars. We want to avoid anything that could cause scrollbars.
delan: So actually ink overflow no, layout overflow yes. Sorry, got those backwards.
astearns: Ink overflow is okay, layout overflow is not okay. We could have a note in the specification saying that’s how we determine the list of properties.
delan: We sort of do say that about the layout, but we could be more explicit about ink overflow.
<iank_> changes in layout overflow implicitly effects layout.
astearns: The bit we have about not affecting overflow layout is sufficient, I think.
RESOLUTION: Accept the proposed PR
<fantasai> fwiw fwiw spec says “The highlight pseudo-elements can only be styled by a limited set of properties that do not affect layout and can be applied performantly in a highly dynamic environment—and additionally (to ensure interoperability) whose rendering within the required area is not dependent on the exact (UA-determined) bounds of the highlight overlay.”
[filter-effects-2] backdrop-filter and visibility
Github: https://
emilio: Browsers are weird and inconsistent about backdrop-filter, which we hit when starting our own implementation.
… We haven’t found content with visibility: visible in the backdrop in the wild, but we should be clear about what should happen.
smfr: My mental model is that you generated a bimap the size of the element with the filter and render the content. So you end with a texture with transparent around the edge and then use that to composite with the backdrop.
… So to my thinking, the Safari behavior looks correct, minus the toggle bug.
emilio: Doesn’t that mean you should render the whole thing even when the backdrop filter is hidden?
smfr: That is a bit weird, I guess.
smfr: I think we’d be willing to change to what you suggest.
emilio: I think determining the visibility by the element the filter is on is simpler, rather than rendering the whole thing.
… Are there other filters that depend on the background behind the element? For most stuff you end up filtering transparent.
smfr: mix-blend-mode is the only one I can think of.
… I think the way forward is to test with the filter property and maybe propose that visibility hidden will always hide the whole backdrop.
dbaron: For what it’s worth, I think of visibility: hidden as a paint-time effect. It should be mostly independent of this compositing things.
… It’s sort of inherited and controls whether things are painted or not.
emilio: That’s what Gecko did, but breaks sites that are set to have backdrops hidden.
… I’ll add some links to examples.
smfr: To dbaron’s point, it’s like saying it’s basically opacity: 0 but affects hit testing.
<emilio> https://
astearns: Sounds like we need more information and will need to do testing around filter as well as backdrop-filter. Take back to the issue?
<dbaron> I was saying I think it's like a middle ground between color:transparent and opacity:0
<dbaron> (I might have been muted when I said it)
[css-lists] counter-reset in UA sheet causing some compat issues.
Github: https://
emilio: This is about pages that do their own counters and adding them makes things add oddly. Not many examples of this, but we found some.
… I tend to think there should be a magical reset, which is unfortunate, but there are things you wouldn’t be able to do otherwise.
TabAtkins: Elika had two objections. 1: this wouldn’t be overridable, as it is now. If you mention a counter, it gets reset. There’s no way to do a no-op. But we got lucky here. We could allow `none` as a counter-reset value alongside integers, which would mean “don’t reset the counter”.
… 2: this triggers on specific HTML elements with no CSS reason for it. We’d like to avoid that if possible. I’m okay with some weird rules, especially around lists, but Elika strongly believes that’s a problem.
fantasai: I think we should avoid it if we can. How strong of a web compatibility problem is it?
<jfkthame> +1 to fantasai
fantasai: So that’s a question for the Safari and Blink teams.
<iank_> i'd need Rune to comment.
smfr: No info at the moment from the WebKit side.
astearns: Who should we ping at WebKit?
smfr: I’ll be the conduit.
<fantasai> Question is, can we get Blink and WebKit to align with Firefox on this, or do we really need to introduce this magic into the Web platform
astearns: So we’re taking this back to the issue for more information.
… It might be good to outline the possible ways forward for this there as well. if someone could add a summary after minutes are posted, that might help.
That’s all, folks!
<florian> reminder: please go vote for the MQ3 proposed corrections: https://
astearns: Similar; I’ll be attending BlinkOn.