- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 May 2020 19:09:04 -0400
- 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.
=========================================
CSS Color Adjust
----------------
- RESOLVED: The color computed values are defined as used values
using the color-mix function (Issue #4915: Is forced
background-color computed or used value?)
CSS Selectors
-------------
- RESOLVED: Expose this selector and name it ::file-chooser-button
(Issue #5049: Can you standardise a pseudo-element
selector for file inputs?)
CSS Cascade
-----------
- The concerns about the spec allowing a 'revert' at computed value
time (Issue #4155: Revert at computed-value time) may be
addressed by the proposed !override property so as that's
written this issue will be re-reviewed.
CSS Sizing
----------
- RESOLVED: Percent based gaps for flex in the cause of undefined
constraint resolve to 0 (Issue #5081: Make flex %
row-gap resolve to 0 when height is indefinite (only
flex, not grid))
Media Queries
-------------
- Most of the group was okay with deprecating speech (Issue #1751:
Deprecate 'speech' media type as well?) but needed to hear from
others before resolving.
- There wasn't enough time on the call to dive deeply into issue
#5044 (length units in video-* media features) but there was
interest to continue conversation about the expected behavior
for the video-* properties on github.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020May/0021.html
Present:
Rachel Andrew
Tab Atkins
Rossen Atanassov
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
David Grogan
Chris Harrelson
Daniel Holbert
Dael Jackson
Peter Linss
Stanton Marcum
Myles Maxfield
Nigel Megitt
Anton Prowse
Manuel Rego Casasnovas
François Remy
Florian Rivoal
Jen Simmons
Miriam Suzanne
Scribe: dael
CSS Color Adjust
----------------
Is forced background-color computed or used value?
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4915
Rossen: This is in the context of forced-colors-adjust.
Rossen: Short summary is in the previous impl of what used to be
ms-high-contrast and is now forced-colors we were reverting
colors including background and override with system color
Rossen: At the time at MS we didn't consider taking in the alpha
channel of the color value.
Rossen: That meant simply all overrides were stable during computed
and alpha was always opaque
Rossen: When working on forced-colors one addition to the feature is
addition of considering alpha channel of the color. For
background-color it means we now have to compute the final
color value during used time
Rossen: That's how issue came about. Is it supposed to be computed
or used.
Rossen: Is AmeliaBR or fantasai on?
TabAtkins: We have me and I commented
TabAtkins: Seems clear this needs to be used value time
transformation
TabAtkins: Because we can't do anything with a system color until we
resolve it which is at used value time because need to
know color scheme
TabAtkins: This is to make it reasonably work. Amelia's comment
brings up the very good point that color mix function
would be useful for this.
TabAtkins: If you want to define a computed value that's this system
color but with the other alpha you can do it simply with
color mix function.
TabAtkins: We could and should define computed value of color
becomes a color mix function with alpha from previous
color and mix with system color
Rossen: What do we serialize in OM? used value?
TabAtkins: All current properties do used
Rossen: Okay, that continues to work
TabAtkins: Not 100% clear/remember what happens in image properties.
But plain colors do used value.
Rossen: The ones covered by color-adjust are covered.
TabAtkins: Yeah
emilio: Not quite used value because :visited and so on
Rossen: Sure
TabAtkins: Ignoring :visited hacks they are always used values
Rossen: Sounds like a good path forward for this behavior
Rossen: Any other considerations or proposals to consider?
TabAtkins: If we go with this is means implementors should
prioritize color mix.
TabAtkins: Also solves that you can't transition system colors since
you can use color mix for that.
Rossen: Sounds good
<TabAtkins> color-mix(appropriate-system-color, specified-color
a(100%))
Rossen: Proposal: The color computed values are defined as used
values using the color mix function
Rossen: Objections?
RESOLVED: The color computed values are defined as used values using
the color-mix function
CSS Selectors
=============
Can you standardise a pseudo-element selector for file inputs?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5049
emilio: Apparently all others than FF have a pseudo-element for this.
emilio: Is anyone planning to remove it? If not, can we add a
specific pseudo for this?
Rossen: Is question about if component model for the control will
change so there's no button?
emilio: No, question is that all of them have a button and all UIs
except FF expose it as a pseudo-element. Only reason to not
make a standard version is if underlying model will change.
I don't see a reason not to add this unless there are
objections
TabAtkins: Still vaguely uncomfortable about exposing internals of
form controls, but I'm comfortable with this one. All
files must have button and I expect will in future.
emilio: Ideas on name?
TabAtkins: Name in issue works for me
Rossen: Can we future proof more?
Rossen: Currently ultra specific to the input type = file. If we're
going down the path of exposing selectors to target form
controls I would hope more generic so if there are other
input types that can have a button that this selector will
match with them
emilio: Not sure I agree. All different input types have values,
mostly prefixed pseudo-elements. I don't think you
want...I'd rather it be specific than potentially expand in
the future and websites change because of that
TabAtkins: Comfortable with button name. This is a naming convention
that we could extend
smfr: I don't like upload in the name. It's choose a file. Not sure
it should look the same because this is a specific behavior
about trigger UI file selection. If it says only image types
it opens photo picker. Name needs to be generic
emilio: Edge name is ::msbrowse
<smfr> ::file-chooser-button
<fremy> ::file-picker-button
Rossen: We spent quite a bit of time bikeshedding that name back
when we expanded our control model. I think it was debated
quite a bit and I was on the other side of the argument. If
everyone else is fine with it, sure.
jensimmons: Curious about work around form control styling coming in
the next few years. Will there be a pseudo-element for
buttons? What's the names that have been discussed there.
TabAtkins: I believe gregwhitworth and Nicole Sullivan have been
working on that and doing user research. Work is ongoing
but not sure the results.
jensimmons: I know it's massive and lots of questions, but this
feels like it should be designed in the context of that.
Though I don't mean don't push for 2 years
TabAtkins: I feel you. I think the use cases and name are clear
enough I think this would be an alright one off to do.
Rossen: Sounds like general agreement around the reasoning to expose
this. Naming-wise let's not spend the hour bikeshedding.
::file-chooser-button or ::file-picker-button sort of fit
what has been explained even if case you open an image
gallery it's still a file
Rossen: Can we pick one and move on? file-chooser or file-picker are
good enough for now?
<fremy> +1 to either
<jensimmons> I'm ok with file chooser or picker or upload, etc. I
don't really like "browse" — it's far too generic in
the context of "browser" and plus a younger generation
of people don't really know what 'browsing files'
means....
Rossen: I'll choose ::file-chooser-button. We can rename later
<fremy> Rossen: ^_^
Rossen: Objections to expose this selector and name it
::file-chooser-button
RESOLVED: Expose this selector and name it ::file-chooser-button
<gregwhitworth> yeah, can we at least do anatomy investigation in
Open UI for this?
<gregwhitworth> emilio: I added a comment regarding the Open UI work
to the issue:
https://github.com/w3c/csswg-drafts/issues/5049#issuecomment-631582242
Feel free to setup some time with me so we can begin
defining that and inform the pseudo element naming
and if there is need for anything else
CSS Cascade
===========
Revert at computed-value time
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4155
Rossen: Brought up by Anders who would be best to summarize.
Rossen: Base of issue is when and how do properties overwritten by
forced colors get reverted
Rossen: Based on the issue there is a pushback against if the revert
rules can apply at computed value time and if this creates
dependency between properties and the way revert and
override work
Rossen: Couple weeks ago took a resolution where we introduced the
!override that can be used to override all the properties
and all the adjust properties. At that point
forced-colors-adjust property is not needed
Rossen: Questioning if this issue will go away and we can close no
change needed
Rossen: Noted TabAtkins and fantasai as you made edits in this space
you may or may not have gotten to this work. Can you tell us
where you are with this?
TabAtkins: We haven't gotten to it so not comfortable with details
yet.
Rossen: On the face value would you think if we had !override (tbd
name) specified and impl would that simply allow us to
resolve this issue?
TabAtkins: Given that this is the default...whenever forced-color
is auto the UA stylesheet overrides. This is about
effects of forced-color-adjust mode. The property just
lets you turn things off. THe revert is what happens by
default not something the author turns on
Rossen: Yeah. My hope was we could use !override UA declaration
instead of current revert
TabAtkins: mmmm...possibly
TabAtkins: If UA hid it behind MQ maybe
<TabAtkins> And then authors could use !override to win over the UA
style when necessary...
Rossen: If UA spec color with !override forced-color and no user
style matched with the equivalent you have the forced-color.
If user wants to expose they can. That's why going down the
path that override will solve this issue as well.
Rossen: Given we don't have Anders on I'm fine pushing this by a
week to see if we can make progress
fremy: Quick note- Basically revert at computed time kind of does
exist with :visited. We have stored in browser real style for
rendering and style for :visited. If I understand spec we
only need it for 2 properties, color and bg-color. Doesn't
sound like a huge deal
fremy: Doesn't seem complex. Examples in issue don't seem like
reason examples. They're crazy scenarios. Works for scenarios
in the spec right now.
Rossen: I think we won't be able to make progress on this issue
CSS Sizing
==========
Make flex % row-gap resolve to 0 when height is indefinite (only
flex, not grid)
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5081
TabAtkins: We had a number of complicated threads about how to deal
with percent gaps in grid. Had a good resolution. Gaps
should act like tracks without content. Thus behavior of
percent in gaps is same as tracks. Resolve to content
size for intrinsic and do percent against it. Limited
value for fixed size, but if everything is percent it's
nice
TabAtkins: We tried to apply different argument to move this to
flex. Flex should work same as grid and resolve percent
same way. Break symmetry argument we tried to apply. If a
flex gap is empty percent than percent on flex item
always behaves as auto. Never goes against initial size
of container
TabAtkins: More consistent is gaps act like empty items and make it
so in a flexbox a percent gap resolved against indefinite
size becomes 0. Avoids annoying extra work and makes
percent consistently the same in flexbox.
TabAtkins: We don't know if we put this in flex or grid or
centralize in alignment, but we'll figure that out when
we get to it
Rossen: Agree we should have consistency on resolve percent against
indefinite constraints. We do this is large number of places
like intrinsic size with width undefined for all items in
float, percent goes to 0 initially. Then when we layout with
defined constraint we'll resolve
Rossen: With that rule said the rest of rules for block layout where
for example has same behavior as shrink to fit but in block
direction things that depend on height don't make sense.
Rossen: That is not true for when percent computed based on resolved
height. Items positioned absolutely in box percent resolve
fine because constraint of containing block is defined. Want
to make sure we're not introducing a new behavior for how
percent resolve during a layout regardless of layout types
being considered
Rossen: I sympathize with issue but I think in this case we have to
decide do we consider percent gaps as resolvable during
final layout pass of flex when all empty space if computed
and all flexing is done? Is the height defined? Because
that's when gap percent will be resolved and items positioned
TabAtkins: We decided that. Percent on flex items do not consider
that to be resolved. They stay as auto. Changing that in
general is fine, but different for gaps vs flex items is
concerning
Rossen: I was going other way, keeping same. If we have resolution
for flex items that percent in undefined are 0 same should
be true for gaps
TabAtkins: Yeah. Resolve to be auto, but same deal. No content so
become 0.
TabAtkins: If you're in agreement and no one else is disagreeing
cool.
rego: I don't like that we're changing for flexbox only because will
be different between flexbox and grid since same property
works different. In grid percent row gutters work nicely
because you have overflow. I showed example in issue. In the
end you have overflow items. I don't think it's useful and
we'd have issues because not interoperable with tracks.
rego: We can do what's proposed for flex but should do same for grid
TabAtkins: You want to revert grid so percent gaps become 0 in grid
and then we should be consistent so percent tracks don't
resolve to size
TabAtkins: I'm fine with that. It's consistent.
Rossen: Not sure I'm on same page for grid. It will make grid row
and column gaps behave asymmetric. If grid is in a block
with defined width which is always the case (assuming left
to right, top to bottom writing mode) the gaps of the
columns resolve and gaps of rows go to 0
Rossen: That will be bad, we've gone to lengths to keep rows and
columns symmetrical. Grid is 2d by its inception and we felt
keeping the symmetric true. Flex is 1d stack layout, even
with multi-line. Applying a principle that's 1d in its
conception to grid which is 2d doesn't always apply. In this
case I don't believe it applies
Rossen: Would rather go back and say percent gaps don't make sense
which is argument I made when we added gaps. That solves all
the issues. If people want defined gaps they can do it in px
or fr in any layouts. Percent rarely makes sense in gaps
TabAtkins: I disagree. jensimmons has examples of people using
percent to build column with and than it makes sense to
do percent in gaps
Rossen: No, I won't say remove percent gaps. Pushing back on
transferring rules
rego: So in grid we have different behavior for column and row gaps,
that's true. But you'll have different behavior in flexbox
too. Some people switching from grid to flex and reusing gap
will get strange behavior. Also my point is we implemented
this 2 years ago and still don't have interop so we're not
having issues here.
rego: I don't like flexbox and grid different, it's very confusing.
Rossen: Agree. Agree that column for flexbox will resolve gaps and
row will not is terrible.
rachelandrew: I don't necessarily think it's that confusing if
flexbox and grid are different in this. Have
difference in not being able to align items in main
axis. Need to be clear about it. Grid the same in both
dimensions is really important. Grid different rows
and columns is confusing. Once people get their head
around how flexbox is different it's okay, wouldn't
like to change grid
<TabAtkins> Agree with Rachel here.
<Rossen> Strongly +1 to Rachel
<TabAtkins> Also: percent gaps *only* do something reasonable if
you're using percent item/tracks as well; percent gaps
with non-% tracks automatically cause overflow, it's
weird and bad.
cbiesinger: Grid and flexbox already differ in some stuff. 1d vs 2d
e.g. implied minimum size applies only main axis in
flexbox and both in grid. There's precedent for
difference.
Rossen: I think there's a general agreement around flex and how flex
gaps should resolve. percent based flex gaps.
<TabAtkins> I'd still be fine with changing percent behavior for
Grid here to match Flexbox and Block.
<rego> I guess Mozilla is fine doing the change for flexbox (as the
spec behavior has been implemented in flexbox since 2 years
ago)
Rossen: If I'm reading the call correctly most people don't want to
transfer to grid and keep grid symmetric. Happy to resolve
for flex now, but if this comes back to grid we can discuss
in the future. We shouldn't say keep the same on principle.
They're not the same.
<TabAtkins> Note that we can bring up the Grid-% change separately;
if we make this decision for Flexbox it'll be consistent
later to change Grid.
Rossen: rego mostly looking to you
rego: If it's only me it's fine. I thought it was important to be
consistent here. If it's only me I don't mind. I think it will
cause confusion. FF had behavior for a while so I don't think
web compat, but I'd like to know that they're fine.
dholbert: I'm fine changing.
dholbert: One note on grid situation, with grid in block axis there
is a special scenario with indefinite height but something
reasonable to resolve percent against. Pixel value grid
template rows create implicit value. There's cases like
that where you get definite height without content and
useful to be symmetric for grid. I'm okay with proposed
resolution
Rossen: Let's try to resolve
Rossen: Proposal: percent based gaps for flex in the cause of
undefined constraint resolve to 0
RESOLVED: Percent based gaps for flex in the cause of undefined
constraint resolve to 0
<dholbert> example of the grid scenario I was mentioning (indefinite
height on the grid container, but still indirectly a
definite height from the grid-template-rows/columns
properties: https://jsfiddle.net/dholbert/ebopac3n/
<rego> dholbert: still you get overflow there, in both directions
(not very useful to me); and also you can have the very same
case in flexbox https://jsfiddle.net/h8u53ows/ (that will
work different only for row gaps)
<dholbert> rego, (right, there's overflow, but it's consistent/
symmetric for grid there, and it doesn't have any
percentages depending on content-measurement, which makes
it a case that feels less terrible. *shrug*)
Media Queries
=============
Deprecate 'speech' media type as well?
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1751
florian: Nowadays MQ are about media features where you can test
aspects. Back in HTML4/CSS2 it was about media types that
are exclusive. We had a bunch, some were speculative, some
were made but not useful. Deprecated all media types except
screen, print, and speech
florian: Media types are exclusive so speech is not screen readers
which still present visual on the screen. Speech is only to
audio for example alexa reading a webpage or an audio book.
Logical possibility for it to exist and some software is
roughly like this. But I have not run across any software
that implements speech media type. Others have also looked
<Rossen> +1 to deprecating
<fremy> +1
florian: At the same time it happens repeatedly that people get
confused and believe that speech is screen reader. So we
should probably drop it and move it to deprecated media
types where syntactically valid but defined to never match
TabAtkins: Strong agree
fantasai: I don't think this should be resolved until we've given
Léonie an opportunity to comment
Rossen: Is she on the call? She's part of the group
fantasai: Nope
nigel: Second we should wait
nigel: Other thing that would be useful is, it described clearly
there's lack of impl. If we take the suggestion to deprecate
and never match if interest grows is there a backout route
where we undeprecate it?
florian: I don't think it would be a problem. There's no compat
dependency so there's nothing that would block us from
later declaring.
<TabAtkins> Or, even if 'speech' gets poisoned, we can always add an
'audio-only' type later if we end up wanting it.
florian: If you want to wait for Léonie lets do so
Rossen: Seems like most of WG is okay to deprecate. Reasonable to
wait to hear from Léonie on this.
length units in video-* media features
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5044
florian: As we know length in CSS are interesting. All units fixed
ratio to each other and either to physical measurements or
pixel. For length in video what are we expecting?
florian: I think a third one. video-width and video-height if this
is 4k I'm expecting an answer in terms of pixels.
florian: I don't think we discussed use case and usage in much
detail. Do we expect video plane into angular css pixel?
Maybe, but if that's the case do we need this? If it's the
physical pixel we need to write that
nigel: For using video pixels I think something exists in TTML specs
where you can define root container region and say how big it
is in pixels. If you're not doing that you get pixel
resolution of video. So you can spec location and size which
defines where you want stuff
nigel: Similarly define font size in pixels. Very typical to use
video pixels when authoring in that sense
nigel: Bit of a push away because makes more sense to use relative
dimensions to the rendering area as a percentage. For font
size calc became complicated using percent fonts based on
parent element.
nigel: We introduced rw and rh which is relative to rendering area,
not overall page
florian: Another confusing thing is we're defining width and height
of video plane but not saying what's in there. Assumption
is that's only hardware generated so you wouldn't size
fonts, but maybe I'm wrong?
cpn: I think you're right. In full screen we're interested in
knowing device resolution so we can select appropriate media
representation for streaming
cpn: Returning in device pixels is ideal
florian: But for images we're not doing that but asking API to
describe the sources and let the UA pick the appropriate
one. Are we not doing that here? I believe you can desc
multiple sources, no?
cpn: If you're using video element you could. If you're using media
source extensions that becomes web app's responsibility not the
UA's
Rossen: We're at top of hour
florian: I think I have a direction, but we should explore on github
Rossen: I would encourage Chris and Nigel to interact on that issue.
You've got the people to solve this
Rossen: We're at the top of the hour. Have a great rest of your
week. Stay safe and happy and we'll chat next week.
Received on Wednesday, 20 May 2020 23:09:46 UTC