- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Jun 2020 18:31:58 -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.
=========================================
Media Queries
-------------
- While discussing how to handle length video-* features (Issue
#5044: length units in video-* media features) the group spent
time working out what the use cases are that lead to this
request.
- The conclusion was that the use case to know the dimensions
was very similar to the discussion that led to srcset. There
are possible fingerprinting vectors when exposing this data
which need to be carefully considered.
- Additionally, there were some questions as to if this was
properly a media query or should change more to be UA driven
to decide what content to serve.
- A call will be coordinated between the CSSWG and the Media WG
with representation from TAG in order to dive into these
questions further.
- Issue #5043 (Definition of video width and height) is related to
issue #5044 so will also wait on the coordinated call before a
resolution can be reached.
Dialog Element
--------------
- RESOLVED: We switch dialog positioning to rely on centered fixed
container with max-height and overflow:auto pending use
counter data (Issue #4645: <dialog> positioning should
be describable in CSS)
Color Adjust
------------
- RESOLVED: Do not honor non-URL background images in forced color
adjustments (Issue #4916: Should probably not honor
non-url background images)
- There was interest in looking into a more nuanced solution to
issue #4916 using the alpha channel.
Color Adjust/Media Queries 5
----------------------------
- RESOLVED: Add the forced value to prefers-contrast (Issue #3856:
Fold `forced-colors` and `prefers-contrast`?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jun/0012.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Luke Dary
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Sanket Joshi
Brian Kardell
Greta Krafsig
Chris Lilley
Peter Linss
Stanton Marcum
Alison Maher
Nigel Megitt
Chris Needham
Tess O'Connor
Anton Prowse
Florian Rivoal
Cassondra Roberts
Jen Simmons
Miriam Suzanne
Regrets:
Megan Gardner
Daniel Holbert
Scribe: dael
astearns: Anyone have any changes for the agenda?
astearns: We are going to take #12 and #13 and move them to next week
astearns: Other changes?
Media Queries
=============
length units in video-* media features
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5044
florian: I can remind where we're at. Not sure how to solve.
florian: We have a set of MQ which are specific to video. I'm going
to focus on width but have height too
florian: Just like normal web pages render to viewport, some players
render video to a separate plane. We have video-width and
properties like that.
florian: Proposed with same syntax as normal width and height. On
devices where planes are different they accept same syntax.
That implies they take any kind of length and what do those
units mean? Goal is the for a 4k device it would return 4k.
florian: Should it be pixel with a different definition and if so
what do the others mean. Should it be a unitless, separate
unit. Underlying that is how are they expected to be used.
TabAtkins: For the use case people want to know physical density of
screen. If it's a 4k screen they want 4k video no matter
if it's full screen
TabAtkins: Given that I agree with fantasai we should do an int
hober: I think I would like there to be a principle for answering
questions like this. Here on a device with only one plane in
a UA that supports video prefix they should be same as if
alias for equivalent.
florian: That's where we started but introduces problems
TabAtkins: Explain why you think that's a useful principle?
hober: Sure. I think...I worry this 2 plane model is a contingent
fact of present limited hardware.
hober: I would like in the future if this hardware goes away I would
like the maintenance burden for browser to be minimized.
Great if simple alias. Working backwards is how I get here.
hober: Future is longer than the past and I doubt devices with these
characteristics are a thing in 100 years, but I hope CSS is a
thing in 100 years and I hope we don't burden future
implementors
<emilio> hober++
AmeliaBR: Following up on hober's comment, I do agree we shouldn't
have similar but different things. px with a different
interpretation is dangerous.
AmeliaBR: I don't know if that means they have to be alias but we
need to think question and purpose of this MQ. If we do
the integer value where it gives you raw dots on the
screen we need to ask how is that interpreted by all UAs,
even ones not doing special video rendering
AmeliaBR: Does defining factor become this isn't about separate
plane but this is a way to get raw pixel resolution to
render graphics and will that be expected in all UAs?
AmeliaBR: If it isn't just an alias for existing width and height we
have to talk about what does it means and what's the
purpose
florian: A few things. Minimizing maintenance burden is good. If we
define this as none or similar I think it's not height.
florian: Mapping to an alias is odd. You want to deliver 4k on a 4k
screen you don't want to deliver 4k if there's one plane.
florian: Starting to think is it useful as a MQ. It's not to select
stylesheets, it's for API things that want to know screen
information and download assets. Wouldn't this be better as
an API?
<emilio> What is the expected usage of this media query?
<AmeliaBR> `<video><source media>`
AmeliaBR: MQ are used to select video sources in HTML attributes
florian: For that purpose I think the best practice is not to select
on device resolution but describe resolution of videos and
let UA choose. This is for the cases you can't do that
because managing it yourself in JS
astearns: florian you're suggesting?
florian: srcset is better for that. I'm thinking this isn't a MQ and
this number is exposed in API
fantasai: Also a question of this is the device...viewport size not
device.
florian: It's device
fantasai: Describing number of pixels or length of viewport.
Question if use case if for viewport size or device size.
Need to be clear if we need one or both for the use case
fantasai: We could make something only available in JS but still
seems fundamentally a MQ. Doesn't make sense to create and
API that's not a MQ even if we think it's only useful in JS
florian: MQ don't give numbers, they answer a question. If people
want a resolution they have to search the MQ. Seems not
great
plinss: Orthogonal, I want to object to 4k or 4000 because it's a
marketing term not an exact specification. It is a hot mess
so let's not use it in a technical context.
faceless2: florian people are binary searching MQ to get approx
resolution already. Ultimately if you're proposing a
value to describe physical px I can think of multiple
issues over the last 6 months that wanted that. It's a
useful problem to solve and not restricted to video
florian: Then different question. Number of physical pixels across
the screen on the video plane is different than one across
viewport.
faceless2: Device with a single screen is it different?
florian: Yeah, if browser not full screen it's different
nigel: I got impression idea is combo of queries for that. if you
have Info about whole device video plane you can do other
queries to realize actual viewport is a subsection of that
astearns: We have video width return px on video plane and other MQ
gives you px width of browser window and we can't convert
between I'm not sure how useful
florian: Resolution gives density and that's in MQs
<emilio> faceless2: hmmm, why are people bin-searching media-queries
instead of `window.devicePixelRatio` / `window.screen` /
`window.{inner,outer}Width`?
<faceless2> A fair question, I didn't write the library that did it
:-) Will dig it up and post here
AmeliaBR: One thing to mention, I can't pull exact resolution but
original discussion is MQ were part of solution but also
going to be CSSOM API that exposed exact numbers. Screen
API and screen.video
AmeliaBR: That people want exact numbers doesn't mean MQ are
inappropriate. Might be 2 parallel solutions. Can't
remember what we resolved on
florian: Another comment, we used to have device-width and -height
MQ in CSS px but we deprecated them for privacy reasons. If
we introduce this we're re-opening the problem. It's a
trade-off so I don't have a decision, but want to remind
people
smfr: Strong support florian. For srcset the UA picks the source and
we should push in that direction so we don't have to expose
all device information b/c fingerprinting
ChrisN: Like we discussed src requires knowing the device
characteristics to know what media to pick
florian: API to tell what resolutions are available and you can than
tell which to load?
ChrisN: Potentially
florian: With an observer of some kind so if it moves from high to
low density screen you get told
ChrisN: Feels like need to take this to Media WG. Looking at history
and we had 3 options, one of which was to add properties to
screen object.
AmeliaBR: I was reviewing that discussion and last comment was
someone saying open a separate issue to discuss how API
should look and I don't think that issue was ever filed
emilio: I feel like florian and smfr. It doesn't feel to me like
using a MQ is right. For video there's a lot UA would want
to do. Seems sensible that even if high res screen you want
to take low bandwidth into account. Leaving source decision
to UA seems better to me and not clear how use MQ
<Rossen> strong +1
florian: I suggest we leave this open, go back to media working
group to talk and with a suggestion to look at discussion
for images and how srcset came to be because that was a
similar item. People should look and have in back of mind.
Doesn't mean we have to do same but it's related
nigel: I want to observe there's an architectural side. There's a
bunch of MQ about video and some make sense in API and others
don't. Need to think about if we want consistent across all
or if it makes sense to differ. Video size is an obvious
thing to decide on resource. Another might be indicate if
display can do a color gamut where you can choose a different
version
nigel: Might also want to select different colors for text in that
case.
nigel: It's complicated and would be neat if single approach to
extend.
florian: We do have color gamut and dynamic range for video. These
seem fine to me. Width and height seem harder
nigel: If users have to go to different places for info about same
device that makes their job harder
florian: But it's different. Picking different color of text you
would do in CSS so a MQ is appropriate. If math in JS to
figure out resource not obvious MQ is convenient.
nigel: Yeah, just different things to balance
ChrisN: I think that's how we ended up with this proposal. We have
color gamut, let's put these in same place. Can revisit
astearns: On face it seems reasonable people have shown issues with
this MQ, especially with privacy. Appropriate to go back
to media WG and see what is really required for MQ.
Example usage is great
hober: Joint call might make sense and be faster than going back and
forth. Media WG telecon is monthly
<fantasai> +1 to hober
astearns: Excellent idea
astearns: Possible to invite CSS people to media WG call? Or should
we host?
hober: Imagine either
nigel: I don't think we have Media group chairs on the call
ChrisN: It could work either way and may depend on timing.
florian: Would be good in same discussion to have someone, maybe TAG
who can represent responsive image discussion
hober: With my TAG hat on and since I was part of srcset creation I
guess I'll have to be on
TabAtkins: Same here since I'm also responsible for srcset
astearns: I'll reach out to Media WG chairs to get a time for a
joint call
florian: Next issue is related but different
Definition of video width and height
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5043
florian: Summary and than we move on.
florian: Just like we copy/paste what they mean we also copy/paste
about video plane on paper.
florian: Needs a degree of revisiting. Related to what the units
mean but when we define that we need to see what we change
in this definition.
astearns: We'll take both these issues to the Media WG joint call
Dialog Element
==============
<dialog> positioning should be describable in CSS
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4645
emilio: Started looking into dialog and whole positioning for abspos
dialog is weird. Have to snapshot scroll position at time
you open.
emilio: I think it's not common since most dialogs I know are
fixedpos and height of screen at most
emilio: Some discussion in the past. I wonder what is model people
feel we should have. fantasai proposed snapshot scroll
position in dom and apply that
emilio: I think I would like simpler and make dialogs fixedpos,
scrollable with max-height is the screen height. Only Chrome
ships dialog so I'd like to know their feelings
<fantasai> issue was about describing the behavior specced in HTML,
didn't look into making fundamental changes to it :)
TabAtkins: Played a bit. Does ability to anchor a dialog to a mouse
event or another element exist or is it limited to dialog
center on screen
emilio: I don't think we can attach to an element
TabAtkins: If we ever do want to attach to an element some mechanism
is the thing being used to position non-anchor dialogs.
If we switch non-anchor to fixedpos we have to figure out
how to do it for non-anchored.
iank: I think a different solution for anchoring down the road
iank: I tried to work out where this originally came from. It was
something like 8 years ago. Only concern I have is webcompat.
Given we're only shipping it might be fine. Want to add use
counters to see what sites are triggering. Otherwise changing
to fixed height and overflow auto sounds fine
emilio: Other weird thing is reposition dialog when viewport
resizes. That just feels weird.
iank: Dialog should always be centered given abspos constraint
emilio: Agree. Whole snapshot is redone when viewport is resized
iank: Sure. Don't disagree this is crazy behavior
iank: I'll add a blink use counter to determine when we're
snapshotting a non-0 scroll position. That should cover it and
give us insight in web compat
TabAtkins: Okay resolve pending data showing we can't this is the
way to go?
iank: Fine.
TabAtkins: Proposal: We switch dialog positioning to rely on
centered fixed container with max-height and
overflow:auto pending use counter data
smfr: Only for modal and therefore in top layer?
TabAtkins: Yeah
smfr: Don't have to worry about transforms because not in top layer?
TabAtkins: Yeah
chrishtr: Does this amount to styling same as full screen element?
TabAtkins: Yeah
chrishtr: It would just allow a margin?
iank: top left at 0 but margins are auto which centers
chrishtr: Only difference is margins, sounds good to me. Recently
reviewed full screen so this is not a problem
hober: Seems good if they converge since intended to use same
underlying
astearns: Do we need to be explicit about connection?
hober: Are since use notion of top layer. A lot of refactor on full
screen spec that could move some of this to other specs
chrishtr: Is dialog in a css spec?
TabAtkins: Just in HTML right now
chrishtr: Can we define where we'd put it when work is done?
TabAtkins: I think it's still fine for special styling rules to live
in html spec. Only if we're adding new functionality
should it be in css.
chrishtr: The rendering monkeypatches need to be moved
TabAtkins: We're planning to kill those
AmeliaBR: One new magic thing is idea of top layer. Is that
described?
TabAtkins: Have an open issue for it in positioning spec
AmeliaBR: Needs to be defined and then html can define dialog as
rendered in top layer with these properties. Then we solve
dialog being described by css terms in the html spec
chrishtr: Sounds right and same for full screen
florian: And if there is not css terms to describe we should create
it rather than have it be magic
fantasai: Describing the top layer is a separate open issue
astearns: Any magic aside from top layer?
TabAtkins: Assuming we use proposal from earlier no. It's just a
fixedpos container
chrishtr: Top layer is in a special place because it's above
scrollbars
TabAtkins: Yes. As fantasai said describing the top layer is a
separate issue
astearns: Have open issue for top layer, we will define that. For
this issue we're going to resolve that We switch dialog
positioning to rely on centered fixed container with
max-height and overflow:auto pending use counter data
astearns: Any objections?
RESOLVED: We switch dialog positioning to rely on centered fixed
container with max-height and overflow:auto pending use
counter data
astearns: Good to get to top layer definition soon so we can remove
the magic.
Color Adjust
------------
Should probably not honor non-url background images
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4916
emilio: When we implemented we initially allowed all background
images like spec says. We had to revert and only allow url
based because things like gradients cause undesired effects.
High contrast dark theme with white gradient you don't want
to show
emilio: Not sure what Edge on new Blink implementation does, but we
got a lot of complaints from high contrast users
AmeliaBR: End user point of view gradients act more like background
color than background image which we'd preserve?
emilio: Right
Rossen: Current impl is evolving in this respect
Rossen: Issue you raised I checked one of the linked URLs. I didn't
see why but that didn't reproduce the issue.
Rossen: Regardless two options you listed which is not honor or do
something further and allow alpha blending of non-color
background to blend with override from system colors. That's
an interesting approach but not sure effect on gradients and
if that's more desirable
Rossen: Either approach seems reasonable.
Rossen: Before the call smfr linked to a proposal from dino a while
back
smfr: Linked because had a mechanism to describe how change colors
and gradients. Instead of magic text you can say
color-filter-saturation:0
Rossen: Defined background color as a color-mix to be able to blend
with computed color of system colors. That's the case and I
was thinking if the color mix would be enough in this case
emilio: Need to color-mix all colors in image. color-filter more
tricky because if applies to system colors it's opposite.
Need to prevent it from applying to UA colors which is not
ideal
smfr: Had notion in webkit, but I don't think we specified anything
on it
emilio: Doesn't that mean default color isn't filtered? I guess it
depends
Rossen: Could go more restrictive and not honor non-url background
images and than figure out if we can alpha-blend gradients
emilio: sgtm
astearns: Proposal: Not honor non-url background images for color
adjustments
astearns: Or non-URL background images people can use color
adjustment MQ to make own changes?
fantasai: No because we're not allowing them
astearns: But you can have rules in stylesheet to use different
gradients
AmeliaBR: Same as forced-color changing any other forced-color rule.
It turns off forced color on certain element
fantasai: But that turns off all rules which is next issue
astearns: Any objections to not honor non-URL background images in
color-adjustments?
AmeliaBR: Can you say forced color?
astearns: Prop: Do not honor non-URL background images in forced
color adjustments
fantasai: I'm okay with it to start. Looking at other ideas in issue
might be worthwhile, but we can start here
Rossen: Agree. I think this is a reasonable first step on the path
RESOLVED: Do not honor non-URL background images in forced color
adjustments
Fold `forced-colors` and `prefers-contrast`?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3856
fantasai: I think we're not going to fold them together because due
to web compat we need to keep forced color MQ.
fantasai: Could add it to trigger when forced-colors is active so
you can know if there is a contrast requirement in place.
emilio: Who ships prefers-contrast? MS?
Rossen: Yes
florian: Not convinced this can work. With prefers you're supposed
to pick. With forced it's done for you. Knowing something
is changed doesn't tell you what to do
fantasai: People will likely want to not use gradients or other
content layering. Pull back effects with visual
complexity. Those changes which aren't colors are things
you'd want with low, high and forced contrast
Rossen: Synergy between forced-colors and the other prefer
properties makes sense for same reason we made initial
change for prefers color scheme. Seems reasonable based on
forced-colors mode people can allow the effect of
forced-colors on large parts of content while providing
reasonable experience either for contrast or adjust for
appropriate color scheme.
<fantasai> I'm suggesting we make @media (prefers-contrast) { ... }
handle high, low, and forced contrast modes
Rossen: I would argue for this change for similar reasons fantasai
pointed out but also to underline that being able to escape
large parts of content and do your own thing is important
for this feature.
Rossen: I think the current contrast hint is missing here and if
people do more with prefers-contrast this is a nice addition
AmeliaBR: I would argue opposite. Important to keep independent.
Forced-color mode can force low-contrast. It's not common.
If we treat forced as prefers-contrast people will assume
it means high contrast when it's not true. Keeping them
independent options recognizes it's more
fantasai: prefers-contrast also can acknowledge low contrast.
forced-colors says I want a particular contrast. Adding it
to prefers-contrast adds a preference be it high or low.
That's why I think it's appropriate.
<florian> I started skeptical, but I now support the proposal
AmeliaBR: How works in authoring boolean perspective? Forced-colors
is independent and media prefers-content doesn't match?
<fantasai> https://drafts.csswg.org/mediaqueries-5/#prefers-contrast
fantasai: We add a keyword of forced to prefers-contrast. If you use
it without anything it means you have a preference be it
high or low and the author should respond
<fantasai> prefers-contrast: no-preference | high | low
<fantasai> proposed to make that
<fantasai> prefers-contrast: no-preference | high | low | forced
florian: Author you can query to prefers-contrast: high to
prefers-contrast: forced and with forced you can reduce
visual complexity
AmeliaBR: With that I'm okay with proposal. Need clear authoring
guidance to not assume the preference is in a specific
direction
<fantasai> The fact that 'low' and 'high' both exist as values makes
that pretty obvious imho
astearns: I'm hearing support
astearns: Objections to add the forced value to prefers-contrast?
RESOLVED: Add the forced value to prefers-contrast
Received on Wednesday, 10 June 2020 22:32:50 UTC