- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 16 Dec 2021 06:42:17 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Media Queries
-------------
- RESOLVED: Drop video-width/height/resolution media queries (Issue
#5044: MediaQueries length units in video-*)
- RESOLVED: dynamic-range: standard also matches when dynamic-range:
high matches (Issue #6793: dynamic-range media queries)
- RESOLVED: Accept change to allow empty functional notations in
<general-enclosed> (Issue #6803: Allow empty functions in
<general-enclosed>)
CSS Pseudo
----------
- RESOLVED: 'color: currentColor' on a highlight takes the next
*active* highlight color, so that text is drawn as if
highlight weren't taking effect (Issue #6818: Highlights
and color:currentColor)
- RESOLVED: getComptuedStyle() with a highlight pseudo takes color as
if that highlight applied and no other highlight applied
(Issue #6818)
- RESOLVED: Author origin rules, and not user-origin rules, trigger
paired cascade fallback (Issue #6386: Clarify
paired-cascading behavior)
- There was general agreement that the testcase mentioned in issue
#6774 (Compat risk for ::selection defaulting one color from
originating element) should continue to pass, but discussion will
continue in the issue about the best way to achieve that.
Publications
------------
- RESOLVED: Publish Conditional 3 as CR
- RESOLVED: Publish a CR of Conditional 4, adding just the selector()
function
- RESOLVED: Publish fpwd of Conditional 5 with remaining features
- RESOLVED: Publish new versions of Fonts 4 and 5
- RESOLVED: Republish MQ4 and MQ5
CSS Compositing
---------------
- RESOLVED: Add plus-lighter and plus-darker to mix-blend-mode in
Compositing 2.
- A request for FPWD of Compositing 2 will be made early next year.
CSS Values
----------
- RESOLVED: Writing-mode sensitive viewport units (and analogous
units) use the writing mode of the element they're used
on. (Issue #6873: Logical viewport units (vi, vb, etc)
and writing-mode propagation)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/28
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Delan Azabani
Oriol Brufau
Tantek Çelik
Dan Clark
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Brian Kardell
Jonathan Kew
Vladimir Levin
Daniel Libby
Chris Lilley
Peter Linss
Alison Maher
Manuel Rego Casasnovas
Morgan Reschenberg
Jen Simmons
Alan Stearns
Miriam Suzanne
Scribe: fantasai
Scribe's scribe: TabAtkins
Media Queries
=============
MediaQueries length units in video-*
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5044
florian: Issue has evolved since opened
florian: Reminder, we specified video-width/height/resolution
florian: Video prefix is about video playing that some devices like
TVs have, where they superimpose a special canvas with
different characteristics for playing video
florian: About a year ago we were talking about this and thinking
that actually, maybe MQ isn't what's wanted
florian: The typical query of width is about whether bigger or
smaller than some value
florian: but not used for that
florian: Use cases were that people wanted to ask "what is the size
of the screen, in physical pixels"
florian: The only way to do via MQ is via binary search in MQ, which
is not great
florian: So conclusion of discussion is not to have an MQ, and
instead have some extension to CSSOM where you can query for
the pixel ratio of the video playing of the device
florian: Since can already know size of viewport, can get the size of
the whole screen
florian: or if interested in size of an element, can go from the size
of that element
florian: So the suggested resolution for MQ is to remove video-width/
height/resolution MQ
florian: and another resolution would be for CSSOM to add
window.deviceVideoPixelRatio
Rossen: Opinions on this?
smfr: I'm a little concerned about multi-screen systems
smfr: Window is associated with a single screen
smfr: if showing video, is it on the same screen/window?
smfr: idk how to know that
smfr: imagine you have two screens, right hand is dedicated to video
presentation
smfr: somehow magically when you present video, it shows up on the
right
smfr: but window object is associated with the left hand screen
smfr: so would be weird if it reported characteristics of right hand
screen
chcunningham: Is this possible today?
smfr: UA thing, UA could decide to send fullscreen video to a
particular screen
florian: I think as far as TVs are concerned, and things with this
multiplane rendering, it doesn't behave the way you described
florian: more general browsers/setups, could be other setups
florian: The window object is probably not designed for that, but
this is a more generic problem than video specifically
florian: 2nd Screen effort is trying to deal with that
florian: but for the TV use case, I don't believe that's how they work
Rossen: To go one step further, in conjunction with some of the newer
foldables and dual-screen efforts
Rossen: I know of at least one effort that is work happening on ???
that have to do with dividing up the window into multiple
segments
Rossen: multiple screen divided by segments or hinge
Rossen: Here we have one window spanning two surfaces
Rossen: Video having controls on one different screen is very typical
florian: Does this device have a multiplane rendering thing?
florian: Typically TVs do this, typical screens don't have two planes
that can be queried separately
Rossen: We have one window object that will be present on both
physical screens
Rossen: Is expectation that devicePixelRatio returns ...
florian: I think the question is legit, if you have this multiplane
thing with two resolutions on one screen, we have this
problem for the window object in general
florian: This is a good problem to address if such devices exist, but
there's nothing specific to video about it
Rossen: There are some laptops that have a pane over the keyboard, so
you can present into those
Rossen: but might be represented by two different screen objects
fantasai: Don't smfr's concern apply to the regular to the regular
device pixel ratio as well?
fantasai: If so, we need to address it there as well
smfr: devicePixelRatio doesn't have this same issue
smfr: If I drag window over, devicePixelRatio will change
fantasai: I understand the concern. We need to address the
multi-resolutions for devicePR and other API. Adding a
parallel API for these is what makes most sense.
smfr: Issue with video one is that video presentation is special, and
UA chooses that it will be displayed in magic extra plane with
different properties
florian: We're not talking about picture in picture or displaying
window in other places
florian: but for TVs, they have two framebuffers layered over each
other in the same spot
florian: They have the normal layer transparent, punch video through
to underlying layer
florian: which has different resolution
florian: In current devices, this would be on the same screen
florian: a browser could have two different videos on different
screens, but that's a very different setup than here
smfr: I understand, I just don't want us to design a problem for
foldables
florian: Let's just resolve to remove the MQ for now
florian: and maybe we can open an issue for the deviceVideoPixelRatio
florian: I don't quite see the problem, because whatever problem
you're describing seems to apply equally to devicePixelRatio
Rossen: Anyone from the video group want both resolutions?
fantasai: smfr, why does your concern apply to deviceVideoPixelRatio
and not devicePixelRatio?
smfr: Because it applies to fullscreen, which is more likely to be on
a different screen
florian: This isn't necessarily about fullscreen video.
florian: If you have youtube playing in the middle of your web page,
you would apply this ratio within the video
smfr: No, I don't think so, I think it only applies to fullscreen
Rossen: If presentation spans multiple screens, e.g. projector, very
different characteristics than PC, wouldn't problem apply to
that as well?
florian: And doesn't necessarily apply to fullscreen only, that's up
to the author
florian: Yes, youtube or hulu or whatever video service can be played
fullscreen sometimes
florian: but might also want to query in normal rendering mode
florian: and since hardware accelerated, would still go into special
plane
smfr: Wouldn't be the case in Apple devices
smfr: I think we should ask experts for feedback
smfr: I think it would be very confusing for author
Rossen: Let's go with resolving to drop the MQ
Rossen: it's clear we need to work more on the rest of the API
Rossen: Any objections to dropping MQ?
smfr: I support that
RESOLVED: Drop video-width/height/resolution media queries
Rossen: Send rest of conversation back to the issue
florian: Should I re-title the issue, or file a new one?
Rossen: New issue might be helpful to have clear slate, but history
etc. might be useful
dynamic-range media queries
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/6793
florian: Had a discussion awhile ago, explored idea that
dynamic-range was a complicated concept
florian: because maybe some devices have modes where high dynamic
range is active or not
florian: and maybe UA supports for videos, but not CSS, or for images
but not canvas
florian: Could say the same thing in theory about other things like
color depth, but we didn't expose this per element or
anything
florian: Idea is to clarify and fix the spec to match what Safari is
currently shipping
florian: One difference is that we have standard and high as values,
and want to align this media feature to the same sort of
behavior we have with color-gamut
florian: Where the smaller one matches when larger one is matched
florian: so that modes nest
florian: so that if more extended values exist in the future,
compatible with content now
florian: Wrt querying device or UA
florian: Text puts more emphasis that needs to be the combination of
UA and device
florian: but no particular need to draw attention to that here, since
true of all MQ
florian: tldr is spec what Safari does, because that's what we want
Rossen: Proposal is?
florian: Currently spec doesn't say that standard and high can match
simultaneously, it's either-or
florian: change it that if match high also match standard
florian: Everything else is editorial
Rossen: We have other MQ like that
<smfr> I agree
<fantasai> +1
RESOLVED: dynamic-range: standard also matches when dynamic-range:
high matches
Allow empty functions in <general-enclosed>
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6803
TabAtkins: We had some leftover grammar from a previous change that
accidentally implied that if you had a <general-enclosed>
in functional form it had to have something inside the
parens
TabAtkins: previously could be empty
TabAtkins: Small change to make the value optional, so that foo()
would be valid
<TabAtkins> @media fn() {...}
<TabAtkins> @media fn(foo) {...}
TabAtkins: Wanted to make sure this counts as <general-enclosed> with
unknown value rather than syntax error
florian: asking for approval because spec is in CR
RESOLVED: Accept change to allow empty functional notations in
<general-enclosed>
CSS Pseudo
==========
Highlights and color:currentColor
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6818
delan: Started discussing this issue last week, but only got partway
through
delan: about special case of setting 'color: currentColor'
delan: Outside of highlights, it means 'color: inherit'
delan: for highlights, actually means something else
delan: There were 2 questions originally, now 3
delan: 1st question, double-checking, spec says when setting to
currentColor, do we want to grab color from next highlight
layer below regardless, or only active highlight layers
delan: fantasai said it only makes sense to use active highlight
layer, and I think everyone agrees on that
florian: I'm a little unsure, agree with that assessment, but
discussion last time suggested maybe there was a whole
different way to think about this
delan: That's the 3rd question, whether this is the right way to
solve the problem that it solves
delan: 2nd question is, if it is the next active highlight
specifically, then what happens when you getComputedStyle?
delan: getComputedStyle needs to return resolved colors, so has to
return an actual color
delan: if you have an element with multiple underlying colors, what
do you do
delan: Currently a few ideas on how to address that
delan: 3rd question, which emilio brought up, this exceptional
behavior of currentColor for highlights is odd and complicated
delan: Wondering if this was the right way to solve the problem, or
if better way to solve the problem
delan: To clarify, best example of a use case for this, is the
spelling and grammar error pseudo-elements
delan: A typical styling for that would be to add a red or green
squiggly line to the text
delan: but you're just adding the decoration, you don't want to
change the color of the text
delan: If you spell a word, still want to have the same text color
delan: but given way highlight painting works, if we didn't have this
rule for currentColor, then there would be no way to highlight
something without changing the color to 'initial' (black)
delan: It's complicated and an odd exception, but we need some
solution to this problem
florian: One extra bit, suggestion last time is that this might be
similar to ::first-line
florian: We don't redefine how currentColor works, we redefine what
inherits from what
florian: If you set currentColor on first line, it'll get its color
from ::first line
TabAtkins: I'm not certain about best way to handle property itself,
but for purpose of getComputedStyle I think it's
reasonable to say "pretend it's not selected at all", so
just get underlying style
TabAtkins: That seems the most straightforward, and doesn't leak info
about spelling/grammar errors
fantasai: We also have to consider that when you set the - we have
paired cascading, and it sets to "the color it would have
already been" it sets the background, so this behavior
needs to represent that as well
emilio: Does this really only apply to currentColor? Seems applies to
inherited properties applied to highlights
emilio: Maybe color is the only one atm
emilio: Seems you'd have the same problem with text-fill and other
things
emilio: So, in general, I think the right fix would be inheritance,
but that might be annoying to implement
delan: Tab, is it true that you mean same thing as emilio, wrt Q2, my
understanding is that if you ask for getComputedStyle for
::selection, we pretend everything is selected and no other
highlights apply
TabAtkins: No opinion on pretending selected or pretending not
selected, defer to impl on that question
TabAtkins: but ignoring any other highlights is the important bit
delan: Sounds like a straightforward solution to that, I agree
delan: With regards to Q3, inheritance and possible parallels with
::first-line
delan: I'm not that fresh on ::first-line and ::first-letter
delan: Can someone explain how it would work for us to sometimes
inherit from another highlight (grab color from ancestor
highlight) while still inheriting within this inheritance tree
for ???
emilio: I think that's the hard part
emilio: My selection styles inherit from my parent selection styles
emilio: E.g. selection style inherits from other highlight which
inherits from regular text which inherits from parent
selection style
delan: ...
delan: ::target-text inherits from ::selection style??
emilio: whichever order we decide on...
emilio: For simplicity, say we have ::selection and ::spelling-error
emilio: Say ::selection inherits from ::spelling-error, and
::spelling-error inherits from parent ::spelling-error
emilio: I think that would get you the right behavior
fantasai: It would not, because if ::selection inherits from
::spelling-error, and that inherits from parent
::spelling-error, it'll never inherit from the parent
selection
emilio: ::spelling-error inherits from ::selection
fantasai: Why would spelling-error inherit from selection?
emilio: ::spelling-error inherits from ::selection
fantasai: That doesn't work
fantasai: can you give me an example of the zigzag?
fantasai: there's two pseudos - selection paints over spelling-error
- what's the inheritance chain?
delan: So you go in a zigzag, our ::selection inherits from our
::spelling error, and our ::spelling-error inherits from our
parent's ::selection, which inherits from parent's
::spelling-error, etc.
<TabAtkins> child selection -> child spelling error -> parent
selection -> parent spelling-error
fantasai: Why would it make sense for ::spelling-error to inherit
from parent's ::selection?
emilio: I guess it doesn't quite...
delan: When you jump back in the zigzag, you have a lower layer
inheriting from a higher layer
delan: It's hard for me to imagine this
fantasai: Imagine spelling was red, selection was blue
fantasai: you highlight some things
fantasai: The zigzag means you'll get red text when you highlight, if
the parent has an spelling error
fantasai: Seems weird
<tantek> This (special inheritance across pseudo-elements) seems
confusing enough to the WG that I can't imagine authors
actually coming up with a predictive mental model for what
is going on.
Rossen: Seems work to do here, need to decide if we are going to
rethink through inheritance or to tweak existing model
delan: This is a valid conversation, about solving via other mechanism
delan: but wondering if we can resolve Q1 and Q2, based on assumption
that things work the way specified now using currentColor
delan: and later if we want to solve a different way, we can do that?
Rossen: Makes sense to me
<dbaron> I *think* one of the goals here is that which of
grammar-error/spelling-error/target-text/selection's styles
wins does *not* depend on which elements are associated with
the selectors (and how they nest), but rather on a
spec-defined order of the pseudos.
florian: I support doing this. Earlier Tab suggested that you put
either everything selected or nothing is, suggest assuming
everything because otherwise no point in querying ::selection
delan: I thought question was between nothing or pretending that just
the pseudo you asked for
florian: That's the one
florian: Answering that just the pseudo you asked for is everywhere
and nothing else
florian: It's not useful to assume no highlights at all
emilio: I think that's the current behavior
emilio: I'm moderately sure that querying ::selection will get you
the ::selection styles
delan: Pretending everything else not selected also solves, what
happens if ::selection leaks a color from ::spelling-error or
::grammar-error, which we made it forbidden for privacy
reasons so this solves that problem
emilio: It's also simpler, fixes privacy leak
florian: Alternative we mentioned last time was to fragment things,
and answer question about first one, but overkill for no
good reason
delan: Don't think anyone needs that answer
florian: If we really needed that answer, we'd need an API to reply
on each individual fragment
delan: For Q1, proposing that we say that when you say
'color: currentColor' on a highlight pseudo, you grab the next
active highlight's color
delan: so that color is as if this highlight wasn't applying
emilio: ...
fantasai: currentColor computes to itself
emilio: except in 'color' property
emilio: I'll double-check
emilio: Anyway, seems fine
RESOLVED: 'color: currentColor' on a highlight takes the next
*active* highlight color, so that text is drawn as if
highlight weren't taking effect
delan: For Q2, when you call getComputedStyle() with a highlight
pseudo, the color of the result should behave as if the pseudo
you passed in is highlighted, but all other highlight pseudos
are not highlighting
delan: we pretend
<florian> +1
RESOLVED: getComptuedStyle() with a highlight pseudo takes color as
if that highlight applied and no other highlight applied
Rossen: we'll take Q3 back to the issue
<br until="??:12">
<emilio> fantasai everyone implements `color: currentColor` like I
mentioned, actually computing it to a non-currentColor value
<fantasai> do you mean for inheritance or getComputedStyle?
<emilio> fantasai I mean in the actual computed stage, not resolved
<fantasai> that gives bad results on inherited properties other than
color, and we had clear resolutions to not do that
<emilio> fantasai yeah, only `color` does this
<fantasai> oh, I see
<emilio> otherwise you'd need to do a whole style tree walk to
resolve all colors, which is not something you want to do
Clarify paired-cascading behavior
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6386
delan: For compat reasons, highlights have a "paired cascade", at
least for ::selection (but we decided to apply to all)
delan: For background-color and color
delan: if you have some browser default colors for ::selection, e.g.
white on blue
delan: if you then go and set one of those two properties, then both
of the defaults get suppressed
<delan> ::selection { background: yellow; }
delan: defaulting to their initial value
delan: e.g. if you set selection's background to yellow, then the
default foreground color at used value time is no longer going
to be white
delan: This issue was pretty big, I asked 7 questions about it in the
issue
delan: Pretty much none of the questions have disagreement in the
issue
delan: The main open question is, which origins should this apply to?
delan: Original spec text says that when author sets one of these two
properties, then we suppress highlight color
delan: but there's also animation and transition origins, and also
user origin
delan: Will talk about animation and transition first
delan: I think it doesn't matter whether animation or transition is
included in this rule or not
delan: We used to think it mattered for consistency with
'appearance', but I realized it doesn't matter because the
animation and transition properties are not applicable for
highlights
delan: So as far as I'm aware, can't use them in highlights
emilio: I think ?? you should be able to
emilio: Don't know if properly supported, though
dholbert: Can a property that is inherited be animated or
transitioned?
delan: Wondering if it is allowed by the spec right now
delan: If not allowed, then doesn't matter whether those origins
included in this rule
delan: at least until they become allowed
florian: I believe delan is right, not part of the list of allowed
properties
delan: No way for some way for them to sneak in, despite not being
applicable properties?
florian: I don't think we designed one
emilio: if animate color of parent, and it inherits through?
fantasai: That wouldn't be in the animation or transition origin on
the highlight itself
delan: If not possible to come into highlight overlay, and it doesn't
matter
florian: I think we should talk some other day whether they should,
but until they do...
delan: For the user origin, I did some playing around with user style
sheets
delan: As far as I can tell, the question here about user origin and
paired cascade comes down to
delan: if the user sets one of the two properties (bg color or color)
in their user style sheet
delan: do we want that to suppress the UA default for the other
property or do we want it to not suppress it and leave the
other property as UA-default
florian: Can implementations guide us? This rule was just for compat
emilio: I don't think there's any compat requirements on user origin
emilio: User origins don't disable appearance, so let's follow that
precedent
fantasai: My reading is that we really don't care, so we should do
whatever is easiest
delan: Works out
delan: Even if you go with compat angle, it doesn't suppress default
UA colors in Firefox
Rossen: Other opinions?
RESOLVED: Author origin rules, and not user-origin rules, trigger
paired cascade fallback
delan: In the issue, we all agree on the other 7 questions
delan: Do we need resolutions?
fantasai: IIRC they're minor enough that I'd close them under Editor
Discretion
Compat risk for ::selection defaulting one color from originating
element
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6774
<delan> https://github.com/w3c/csswg-drafts/issues/2474
delan: The highlight inheritance and cascade in the spec is a pretty
big change compared to processing model in implementations
right now
delan: Previously our position was that we consider the compat risk
of this big change to be acceptable
delan: because the old model that exists in old browsers is kind of
useless and broken
delan: The styles don't inherit so you have the set them everywhere,
unless writing a really awkward selector
delan: While implementing in Blink, we found a WPT that broke as a
result of turning on highlight inheritance
delan: Unclear if aware of that breakage, are we still happy with the
compat risk?
<delan> span { background-color: red; color: fuchsia; }
<delan> span::selection { background-color: green; }
delan: What the test did is essentially it has the originating
element with colors of fuchsia on red
delan: There's a selection rule that just sets a green background
color
delan: paired cascade from earlier means that because one of the two
highlight properties
delan: There is no UA default for 'color', so we use whatever color
we get normally
delan: Existing model in browsers has ::selection inherit styles from
originating element
delan: so test expects color to be fuchsia
delan: but now the test fails
delan: because under new rules, we don't inherit color, it's black
fantasai: I think the test is correct, actually, and paired cascading
is also correct
fantasai: Inheriting all the way up, should get currentColor, not
black
fantasai: though I'm not sure the spec is clear about that
emilio: Goes back to currentColor discussion
emilio: All implementations resolve 'color: currentColor' to an
actual color
emilio: so I think we need to solve the problem of 'initial' and
'currentColor' being different
emilio: and we need a resolved color
emilio: I think the computed value is wrong, and it uses a computed
color
emilio: Nobody implements that, it has terrible perf implications
florian: Delan, can you point out to which bit of the spec made you
think that you would go to black rather than originating
element?
florian: Wondering if it's ambiguous or wrong
delan: ... value found by inheritance ... do we say what happens when
we get to the top?
delan: I don't think it says what to do if you get all the way to the
root
delan: was it wrong to assume it would work the same way as in the
the normal tree?
emilio: I think the spec is right
emilio: but if everything worked by spec, color is initial which is
currentColor and it would work
emilio: but that's not how it works right now
delan: So we'd change spec so that for highlights, we get to root,
and have a value we get essentially what currentColor does now
emilio: Per spec should get currentColor as computed value
emilio: so I think the spec for the color property is wrong
delan: If we did that for all properties ...
emilio: I think the only issue is with the color property
emilio: All current impls store as computed color
emilio: Otherwise need to go figure it out every time resolving a
color for a given style
emilio: I think the spec doesn't reflect that
emilio: Didn't make a difference until now, that we want currentColor
to behave specially
Rossen: So do we need to move this discussion back to GH?
delan: I suppose these questions are useful and interesting, but I'm
not sure they necessarily change the original question, which
was do we still want to move to new cascading and inheritance
model
emilio: I think we want the testcase to continue to pass
emilio: Depending on how we resolve the issue
delan: So can take to GH
emilio: This seems complex enough discussion
emilio: per spec everything works magically and it's great
emilio: but I don't think that's reasonable
emilio: so we should figure out the solution that works as we want
delan: ok sounds good
Publications
============
Scribe: TabAtkins
Topic: Publications
Conditionals publication
------------------------
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2021OctDec/0116.html
fantasai: I wanna publish another level 3 CR. A couple of minor fixes
we'd agreed to.
fantasai: Very close to REC, just a few bugs in impls, and one
interop issue to review.
fantasai: So first ask for repub as CR
Rossen: Objections?
RESOLVED: Publish Conditionals 3 as CR
fantasai: Next is Conditionals 4, published as fpwd in march 2020
fantasai: Only contains new selector() function, been shipping in
browsers for a while.
fantasai: We resolved to add a bunch of features to conditional, but
since this feature is CR-ready, I propose we defer the rest
and take this to CR.
TabAtkins: If this is CR-ready, why not fold into 3?
fantasai: 3 is Rec-ready, it'll pull us back
chris: Agree, this sounds like a good plan
Rossen: Opinions or objections?
RESOLVED: Publish a CR of Conditional 4, adding just the selector()
function
fantasai: For level 5 we proposed font-format(), font-tech(), @when,
@else
fantasai: Propose we publish as fpwd
chris: So this seems easy since it's basically copying the current 4
ED and changing it to 5
Rossen: objections?
RESOLVED: Publish fpwd of Conditional 5 with remaining features
Fonts
-----
chris: Fonts 4 and 5 have new bits, like tech()
chris: I wanted to make sure Conditional 5 and Fonts get published
together, since the font stuff links between each other
Rossen: Opinions?
RESOLVED: Publish new versions of Fonts 4 and 5
Media Queries
-------------
florian: Neither MQ 4 nor 5 are free of issues, but the EDs are ahead
of the TR copies, and I don't think there's issues with
what's in there right now. More to do, but nothing
problematic.
florian: level 4 will be CRD, level 5 will be WD
Rossen: Objections?
<fantasai> +1 to republishing
RESOLVED: Republish MQ4 and MQ5
Compositing
===========
Add lighter composite operator to mix-blend-mode
------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/445
vmpstr: We'd like to add a plus-lighter to mix-blend-mode, and smfr
says WebKit already supports plus-lighter and plus-darker
vmpstr: They're comp operations, not blend, so they'd work in the
same way that canvas works, where if you set a blend mode the
comp op is src-over; if you set a comp op the blend mode is
normal
smfr: Issue says lighter, but you're asking for plus-lighter?
vmpstr: I think the difference is just whether the color is clamped
to 1
vmpstr: Okay for our use-case either way
smfr: Preferable to me, because our graphics framework doesn't
support lighter. plus-lighter is fine
vmpstr: That's fine for us, yes.
chris: Good to see the alignment between CSS and Canvas as well.
chris: This'll be in Compositing 2? Have we had FPWD?
Rossen: Don't think so
chris: Okay to request that?
Rossen: Resolve on this issue first.
Rossen: Objections to adding plus-lighter and plus-darker?
RESOLVED: Add plus-lighter and plus-darker to mix-blend-mode in
Compositing 2.
fantasai: Might want to give a chance to review, so fpwd next year.
Rossen: Yeah, let's call for it next year.
CSS Values
==========
Logical viewport units (vi, vb, etc) and writing-mode propagation
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6873
fantasai: Issue was raised to simplify some edge cases around body
propagation and writing modes and viewport units
fantasai: Also brought up the question - I think we got the issue
wrong, as it says to resolve against the root element's
writing mode, but I think generally you want the element's
writing mode.
fantasai: So proposed resolution is to use the element's writing mode
to resolve vi/vb, rather than the root element.
TabAtkins: I agree
smfr: Does that make inheritance complicated?
fantasai: No, they compute to lengths before inheritance
florian: Yeah, I think I remember that being what I wanted. If you're
doing a font-size in viewport units, you want the logical
axis you're using.
miriam: Might be confusing with container queries which have to be
set up to be inline or block
miriam: So you set up a container with "inline", this might not match
the container you've established.
emilio: What do we resolve our units against, the container or the
element?
fantasai: So this is about the container-relative units.
emilio: We added a way to resolve against different containers. It
would be very bad if we resolved relative units against
different axises for each property.
emilio: So think we should resolve them against the element's writing
mode.
miriam: So when you use the "cq inline unit" it looks for the nearest
container with inline containment.
miriam: Could potentially be confusing if the inline unit doesn't
resolve against a container declaring "inline"
TabAtkins: I agree that the potential of inline not matching inline
is a general problem with mismatched writing modes, and
agree that within an element you want inline to match what
that element thinks its inline axis is
fantasai: So proposed resolution is that viewport units (and
analogues) use the writing mode of the element they're used
on.
Rossen: objections?
RESOLVED: Writing-mode sensitive viewport units (and analogous units)
use the writing mode of the element they're used on.
fantasai: Just realized we should probably add Color Adjust to the
rough interop section of the snapshot.
Rossen: We'll take it over email.
Received on Thursday, 16 December 2021 11:44:01 UTC