The color on the web/media and entertainment meeting is being minuted on #me

present+

do we define "property"/"descriptor" anywhere?

drafts.csswg.org/css-syntax-3/#declaration touches on this, but we don't actually have a <dfn>property</dfn> and <dfn>descriptor</dfn> anywhere seemingly?

Zakim, start meeting

I may be able to be around for a few bits and pieces of the meetings this week, but mostly I won't be able to be around.

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

ScribeNick: heycam

present+

present+

present+

present+

present+ myles

present+

present-

present+

I can if need be however this is me gesturing the touch UI of my iPad

present+

Scribes [Cam, Tab, Myles, Tantek]

present+

Topic: Introductions

Rossen Atanassov, Microsoft

present+

Alan Stearns, Adobe

Alison Maher, Microsoft

Cameron McCormack, Mozilla

Daniel Libby, Microsoft

present+

Elika Etemad aka fantasai, Invited Expert

Emilio Cobos, Mozilla

François REMY, Invited Expert

Brian Kardlel, Igalia

Javier Fernandez, Igalia

Florian Rivoal, Invited Expert

Manuel Rego, Igalia

Miriam Suzanne, Invited Expert

Oriol Brufau, Igalia

Myles C. Maxfield, Apple Inc.

PLH, W3C

Tantek Çelik, Mozilla

Theresa (Tess) O'Connor, Apple

Megan Gardner, Apple

Mike Bremford, BFO

Morgan Reschenberg, Mozilla

Brandon Ferrua, Salesforce

Ting-Yu Lin, Mozilla

q+

q-

Tab Atkins, Google

[[ Type q+ into IRC to add yourself into the queue ]]

Topic: Republishing tasks

github: w3c/csswg-drafts #5613

fantasai: we are super behind on keeping outselves up to date on TR pages

... as of Sep 13 the Process has been updated

... I created this issue to make sure we get around to publications

... Houdini is mostly not published, for several years

... open request for Sizing

... any other people who want to request publication, agenda+ this issue

... then we can use this issue to track whether it got published

... at astearns's request, I made an "estimated publication badness chart"

q+

fantasai: if you want to edit this file it's in GitHub

... there are lots of spec that need publication!

... it's causing confusion for other groups

... publishing is easy. if you're confused on how to do it, ask in IRC

... the one thing without resolution that needs it is sizing-4

... that's a WD

q?

present+

RESOLVED: Publish sizing-4

ack astearns

q+

q+

astearns: based on fantasai's analysis of things that haven't been updated on TR, I've started reaching out to editors to see if we can get the ones that are (in some cases) nearly a decade out of date published

fantasai: cascade-3 is blocked

... on various Proposed Rec things

chris: conditional-3 has the oldest one I think, 2013

... it's getting there, should we get an updated CR on that?

fantasai: CRD? we can do that

... Process 2020 has two types of CR publications

... the official snapshot, that goes through approvals etc. then there's Candidate Rec Draft, similar to WD, which allows some open issues

... a CRD has to represent WG consensus

Rossen_: any delta between what would be in the CRD and what is currently in broad horizontal review?

fantasai: yes. there a bunch of changes since the last PR

s/PR/CR/

Rossen_: do we have to go and review all the changes?

fantasai: no, purpose of CRD is so you don't have to do that, or the DoC

... have to list changes since the last CR, and WG consensus on material different from the last CR

florian: goal is equivalent in quality to CR, but less process heavy

dbaron: just need a resolution, if nobody objects, it's WG consensus

q?

s/dbaron/chris/

RESOLVED: publish CRD of conditional-3

ack chris

ack florian

present+

florian: back when Tess was an editor, we were going to have an event handler section in highlighter

... the rest of the spec is not final, but it's FPWD-ish

s/highlighter/highlight-api/

... proposing we publish it as is

... there's a placeholder in the ToC for event handling

... but having live material live off /TR for years is not good, so let's publish it

Rossen_: who are the authors?

+1

hober: editors will be Megan, Florian, Sanket

florian: I will fill that in, then work with Megan/Sanket to get issues resolved after publishing

RESOLVED: publish highlight-api

fantasai: just want to note that env and scroll-animations also should be published

s/should be published/have no FPWD/

florian: as Alan pings authors, we'll follow up with the env folks

s/florian/Rossen/

Topic: Fix aspect-ratio errors in css-grid-1

github: w3c/csswg-drafts #5615

fantasai: there was a commit which attempted to clarify interaction of aspect-ratio and grid item sizing

... that introduced an error, which I fixed

... I'd like to verify the fix with the WG

... and republish grid-1 and grid-2 with the correction

... as a CRD

Rossen_: is there a commit diff we should be looking at?

... or just that PR that you linked there

fantasai: commit I linked, that shows the fix to the problem, but the resulting text needs to be reviewed

q?

Rossen_: we resolved for this change that will be different from flexbox, right?

fantasai: this one wasn't supposed to be a change, just a clarification

... can grab a diff against the older version

rrsagent, here

rrsagent, make minutes

Rossen_: any comments or objections to accept this diff?

oriol: I think it's a good change, because there was a sentence saying that for stretch the rules would be modified to follow aspect-ratio. but impls were not doing that

... so if you have stretch, aspect-ratio is not taken into account

... so I think removing this sentence is good

I was hoping oriol had reviewed this. Given that he has, I feel confident it's fine :)

(There was a line attributed to me above that wasn't me, btw.)

RESOLVED: accept aspect-ratio error changes in css-grid-1

Topic: Resolution of percentage row tracks and gutters with indefinite height

github: w3c/csswg-drafts #5566

rego: this is an old discussion

... this is about how we resolve percetange row tracks/gutters

... with a minimum height

... we resolve to intrinsic height that we compute

... that causes overflow in many cases

... and makes it more complicated, and no interop

... in Firefox it is doing the old behavior. %age tracks resolve to auto

... I was proposing here to change again, and get interop in this case

... and then also change how gutters work, which Firefox does do

... we have been discussing for a long time, checking compat issues, we already had a use counter for %age tracks, also for gutters

q?

... checking the results, grid tracks where 0.03% of page views

... that's going down, to not count 1 row with 100%

... we analyzed the pages from that, only 1 broke

... with gutters, the usage is very low. 0.003% of page views

... 40 pages, only 1 broke

... so this change will align us with flexbox, and get interop in the tracks part that we don't have right now

Rossen_: we did discuss this in the past, in the context of flexbox, grid and gutters. every time the discussion goes around and comes back to one of the main points/principles for grid

... which is to hold the behavior of rows and columns, and row gutters / col gutters, to be symmetric

... strong desire for this

... strong pushback against things going against this principle

... don't want to relitigate that

... so why should we change it for this one?

rego: it will break that principle. the reasons we should change are in the top of the issue

... it usually causes overflow when people use it

... it requires worse perf in track sizing

... and we don't have interop

... but I agree it will break that principle

q?

Rossen_: would like to hear from more people. personal preference to hold on to that principle

... it's an easy slippery slope to get on

... yes there are expectations when they compare other 1D layout systems like block and flexbox.

... with this particular one, I think we should hold a high bar in keeping that principle going forward

jensimmons: I haven't heard much about this kind of stuff at all

... feel like authors haven't quite grasped grid fully yet

... lack of compat is a problem, would like interop asap, even if the behaviour feels a bit buggy

... and stop using percents for gutters anyway

... so in some ways I don't really care about this, since they shouldn't be using percentages

Rossen_: I think the data agrees with your observations, few cases in the wild

... doesn't feel like it's strongly motivated

miriam: that's my experience as well

fantasai: I think it'd be good to hear from mats and rachel

... if nobody else had anything else to add, could defer to hear from them

Rossen_: in the meantime we can publish grid-1 and grid-2 as CRDs

Topic: Fix aspect-ratio errors in css-grid-1

github: w3c/csswg-drafts #5615

Rossen_: any objections to publishing a CRD for grid-1?

RESOLVED: publish a CRD for grid-1

Rossen_: and for grid-2?

RESOLVED: publish a CRD for grid-2

Topic: Clear 'aspect-ratio' for shipping

github: w3c/csswg-drafts #5598

fantasai: do we want to add aspect-ratio to the snapshot?

... suitable for shipping in impls yet?

cbiesinger: the intent to ship has been approved

... so we are planning to ship in the next version

q?

heycam: we are also making good progress, will be ready in the coming months

fantasai: this wouldn't be CR, needs more work before that

... we add it to snapshot-2020 in the "not CR but ready for shipping" section

heycam: issue status?

fantasai: thing most have been resolved

... Tab and I did a triage recently

Rossen_: will we reach CR if we go through these issues?

fantasai: sizing-4 is a WD

Discussion is about adding to w3.org/TR/CSS/#CR-exceptions

RESOLVED: add aspect-ratio to the "clear for shipping despite not being in CR" section of snapshot-2020

Topic: How widely should HTML's 'aspect-ratio' presentational attribute be applied?

github: w3c/csswg-drafts #5608

TabAtkins: Emilio brought up in the HTML spec that it would make sense to make the aspect-ratio attribute integration from width/height setting intrinsic size, to being them setting an intrinsic ratio pres hint

... I wrote the spec text for it

... Domenic asked which elemetns it should apply to

... prev spec text applied to img specifically

... (side discussion about <picture>)

... but there are other elements that we do use width/height on

... video, possibly embed/object

... canvas, <input type=image>

q

q+

... first question, does it make sense to widen the spec text from the previous img/picture only, and if so, which elements should we expand it to?

... I think we should, and go with elika's list

... embed/object applying an intrinsic ratio doesn't always apply)

q+

jensimmons: to remind everyone, this is about improving the experience for users while the page is loading

... the intention is that it has no affect on layout after these assets have loaded

ack jensimmons

... once an image has loaded, it should get the same layout it would've had

... should work the same way for video

... they do have an intrinsic aspect ratio

... should apply to any HTML element where this is true

... so does not apply to a typical iframe, since they don't have intrinsic aspect ratio

... it's also true that embed/object can sometimes have an intrinsic aspect ratio

q+

... but if there are complications it's not critical

emilio: I agree with this

ack emilio

... when we initially implemented this for img, we still didn't have the compat requirements

... I think this is pretty reasonable

florian: makes a lot of sense to me

ack florian

... given the text you're replacing didn't apply to these things, is the compat story different for img and the things that are like it?

... or it all falls into the same bucket?

emilio: when we did it for img, we override the aspect ratio, but people put wrong values

... the auto value is like a low priority hint

... I think the compat impact is going to be extremely low

florian: canvas loads a bit differently from these other things

... you don't load an external file

TabAtkins: intrinsic size is based on the backing store

florian: script controlled? and so if the script hasn't run yet it's a similar situation?

myles: it's based on the attributes on the element

TabAtkins: you're right

q?

... but it would still be consistent with images

florian: less useful but still doesn't hurt

Rossen_: in the case of picture/srcset, does it come from the first image?

emilio: I think it would be the actual <img> inside the picture

... but there's another PR to make width/height apply to src

... there's no precedent for other elements' attributes affecting intrinsics

TabAtkins: but that's behind discussed elsewhere

s/behind/being/

img, input type=image, video, canvas

RESOLVED: apply aspect ratio pres hint to img, <input type=image>, video, canvas

<br dur=10min> (back at :10 after your hour)

topic: break

ScribeNick: myles

Topic: zoom!

github: w3c/csswg-drafts #5623

dlibby: Last time this was discussed as 5 years ago. The zoom property came from IE. It was picked up by webkit / blink.

dlibby: it's a bit hacky tbh in the way it's implemented. multiplies the used values by a factor. Comes with a factor of bugs. Gecko doesn't implement it, so they've been running into compat issues

dlibby: There have been attempts to implement in terms of transform / transform-origin. It fixed some content, but didn't fix everything

dlibby: We should try to standardize this. What appetite is there for documenting existing bugs / odd behavior vs trying to fix them.

dlibby: Broader context: From MS, there are a few properties that have been looking at zoom as a low-cost way of zooming in on a webkit. They use it and get good results, and haven't had to rearchitect their app / change their layout structure.

present+ leaverou

dlibby: Others' thoughts?

present+ dbaron (intermittently)

emilio: I made my comment in the issue. I would not be a fan of standardizing the current behavior. It's extremely wrong.

emilio: There's a bunch of quirks that exist for compat. I only found out by chance. Like zoom affecting intrinsic sizing of some elements but not others, or zoom:0 = zoom:1, because why not. It feels to me like the property is really odd b/c it's a property that affects the computed style of pretty much all lengths, including font size, which is terrible. Ot

emilio: It's one of the biggest compat issues we have to fix. But we might break more content than we fix. If it was me, I would try to remove it from Chromium. But that's not a big [missed]. That may require Chromium implementing -moz-transform, which isn't great. it's a mess. I would be skeptical standardizing this as-is right now.

astearns: I don't think there would be much utility in documenting the existing weirdness in CSS-space. I would be much more interested if someone had a solution they wanted to have implementations move toward. Something that was interoperable and didn't have quirks

florian: I agree the current thing is messy, but it's used. If you want to write a browser that works with the web, you need this thing. That's what the usage data tells us. If's being used, it should be known how it works.

q+

ack emilio

florian: I am not sure it's only being used for its primary purpose. Maybe it's used *for* its quirks. Maybe it depends on its quirks. I believe they no longer care strongly about this, but Bloomberg could have used transforms, but font-rendering was different than that, and this is a quirk, and they were desired by Bloomberg. If we can't get rid of it, we should write down what it is

emilio: I would argue that you don't necessarily need to implement zoom to render the web. There's content that either depends on .... I think it would be interesting to disable the property in Chrome and see what breaks and what works in Firefox. The 2 solutions are prefixed -moz-transform + no zoom, or zoom + no prefix -moz-transform

emilio: You don't want double-scaling which sucks

florian: Is moz-transform cleaner?

emilio: -moz-transform is an alias to transform.

q+

fantasai: Would Chrome be able to remove zoom and add -moz-transform as an alias of transform?

ack dlibby

q+

dlibby: That might be worth exploring. The behavior is not identical between a scale transform and a zoom. To pursue something that would provide similar functionality sounds like there might be some interest in doing something like that from the group? Or at least no clear opposition? But that's an interesting experiment in Chromium - understanding the impact of turning off zoom.

dlibby: I don't know if there's precedence, thought. I'd have to consult with others. The idea is interesting.

florian: There is precedence for setting in stone things with odd names with vendors in them. Maybe not -moz- specifically though.

fantasai: It would be better for the web if we did that because it's one less quirky weird unspecified thing that needs to be embedded in the platform, if it's just an alias. If we can have a zoom feature that does what people want, it would be a good way forward. If it can't be removed, we have to spec it.

ack fremy

s/it can't/legacy zoom can't/

fremy: one question: The zoom property can, if you have grid + some elements, the zoom property, zoom:200%, it not only scales the element but also changes the size of the tracks.

florian: It is layout-affecting transforms.

fremy: You can't achieve that with transform

q+

florian: The way that zoom affects layout is weird. Can we remove the weird one, or do we have to spec it

fremy: Can we redefine how zoom works that's sane?

fremy: Can we look at this? What is the minimum amount of things that makes zoom useful and sane, but are more powerful than transforms.

s/The way that zoom/Layout-affecting zoom is useful and we should have a feature that does that. However, the way that legacy zoom/

fremy: If you don't know what all the tricks are, it's scary to implement, but if we all agree on something similar and that works, it's a safer bet than something nobody understands

florian: If we could do this, that would be good. I believe we had looked and concluded we couldn't change it. It's strange, but the sites we looked at relied on its weirdness

astearns: right.

ack jensimmons

q+

jensimmons: For a long time I've thought one of the thigns that was not exciting about transforms and motion-path is none of them affect sizing / calculation, especially for calculating flow. If you make something bigger or move it over, it doesn't affect anything around it. It's an interesting space. Zoom is one of the qualities we might want to look at about making transforms affect sizing and layout. I hate when the answer to a small problem is

"let's make something incredibyl complicated" but that feels like the right direction.

jensimmons: zoom is unspecified and has total lack of interop.

I think we had a working group resolution to pursue layout-affecting transforms. :-/ I remember an extensive discussion of it in a meeting -- and I remember SteveZ was there.

jensimmons: It was trying to do everything in one property. We should break it down and say "actually what we really want is have layout-affecting transformations" or "maybe there should be alternative ways that fonts should be rendered"

ack heycam

heycam: To follow-on from jensimmons, I'm curious dlibby what the specific things that these authors are trying to get out of it, and why regular transforms were not sufficient.

q+

q+

btw, I made this demo while listening to see what's different between zoom & transform scale: codepen.io/jensimmons/pen/gOMMJMz

zakim, close queue

dlibby: One of the compelling use cases was outlook web access to zoom in the reading pane for your emails. These emails were coming in with arbitrary styles / content / sizing, so enabling jsut that section, but no horizontal overflow, zoom gave them a low-cost way of doing it. "hey it could work" it keeps the layout constrained in the inline direction. They've been happy with results in Safari and Chrome and Edge so far. That's the main use case.

dlibby: There were a few other use cases that were less compelling.

dlibby: This one is the most compelling to me.

ack emilio

emilio: If you're zooming arbitrary content, zoom doesn't work. Percentages don't get scaled. Which is one of the quirks of the zoom property. I guess for email it kinda works because most emails are fixed sizes, but that's a very specific use case to justify adding this with the existing quirks.

ack smfr

lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0267.html at least recorded an action to post a proposal for layout-affecting transforms

smfr: Safari's command-plus zooming behavior is built on top of the zoom property. Makes images and text bigger while reflowing. Transforms aren't what you want.

emilio: Control-plus in gecko affects the CSS px scale. and viewport.

myles: We also have that zoom

smfr: That's what we have, it changes the size of css px

emilio: command-plus is interoperable, it just changes the size of a CSS px. But it's complicated / messy, maybe it's a mix of the two.

astearns: dbaron posted a link where we wanted to make layout-affecting transforms before

astearns: proposed resolution: avoid specifying zoom as it stands, but we will if we have to, and a new proposal about a better zoom property would be a good use of time

dlibby: Good discussion. Thanks.

dlibby: This is a clear path forward that ideally does not specifying the current behavior.

Topic: Updating the css `env()` function to enable selection by index from a list of pre-defined environment variables

GitHub: w3c/csswg-drafts #5622

dlibby: A continuation of the previous discussion. Targetting dual-screen devices. Creating primitives that are more extensible to target desktops or future devices. That could be better than the original proposal. Previously we described where a fold might exist in yoru viewport, but this changes to describe segments of your viewport and their dimensions. It's probably 2 issues: 1. Whether this set of env variables makes sense, and 2. the right way

to represent it syntactically. TabAtkins replies about 2. Focusing on the env variables themselves... these would be in visual viewport coordinate system. Targetting the top level layout constructs.

dlibby: We have not yet heard use cases for integrating into the various layout submodules.

q+ (after Tab gets an opportunity to reply)

zakim, open queue

q+

q+

dlibby: the ordering in the proposal for this issue is a row major order with a single index. Maybe there will be some discussion about whether that should be a 2-d index. -> Syntax question about whether env variables should be specified up front about the ones that are represented by the UA, or if an open-ended set of variables is sufficient for that spec.

dlibby: Our goal is to get something into the WD for css-env. But feedback on the concept / makes sense/ etc. would be appreciated.

ack TabAtkins

q+

TabAtkins: On the syntax question, the original proposal has an index(var name, integer) and represents an indexed variable name there. We don't' need a function, if we want a list or matrix value env variables, we can build them into the name like name-1 or name-2 but if we want to make them separable, which is reasonable, we can't target a particular screen if it's built into the ident, we can add 1 or more integers into the main argumetn part of

the [missed]

+1 to Tab

TabAtkins: I'm happy to add in 1+ integers after the variable name, that makes sense.

s/[missed]/env() function/

ack fremy

fremy: That mostly covers the thing I was going to say.

q+

fremy: One little thing: when I looked at this, one of the things you can do if you have a way of separating the numbers and the value is you can have the number be a variable. You cannot have the name of a variable be a variable. There can be use cases for that.

fremy: Why limit ourselves to integers?

fremy: Right now, the syntax for variable is [ident comma fallback]. What if instead we allowed the ident to be a list of identifiers or numbers, and then concatenate them. Then we could use variables in the name of variables, which would be cool. You could have a structure, like main color, secondary color, and then prefix them with the name of a theme, like dark-maincolor or light-maincolor, and use a variable to select which theme you're using on

an element.

fremy: Like what TabAtkins said, we don't need a function, but we can put any arbitrary ident there.

myles: Floating point values makes that tricky

TabAtkins: it would be ident | int

ack heycam

heycam: In the proposal, there's talk of 2d screen setup. Will this work with non-mobile device situations? 2d arrangements of monitors is usually for desktop machine.

ack bkardell_

<dlibby's connection is broken, he can't answer>

ack fantasai

q+ bkardell_

q-

fantasai: 2 questions: 1. Are we distinguishing between viewport and physical display, is env() returning the value for the viewport (if you move a window on the display) how does that effect the env()

fantasai: 2. Do we want to linearize the list? Or do we want to assume a gridded layout and have a matrix w/ 2 indices, one for each axis

astearns: If we decide to use a list syntax now, can we extend that to accommodate a matrix syntax?

fantasai: It depends on what exactly we decide to do. A linear form is ... the syntax would have different needs depending on what you wanted to do. It's interesting how exactly the syntax work and how it relates to the MQ and how it relates to each other and other things in CSS. It's important that we think of these two features together. The MQ + the env()

<dlibby is back>

fantasai: 2 questions: 1. Are we distinguishing between viewport and physical display, is env() returning the value for the viewport (if you move a window on the display) how does that effect the env()

dlibby: We are querying the viewport in relation to the physical/logical display regions.

fantasai: That needs to be clear in the name.

fantasai: and in the spec also.

fantasai: With the MQ we were talking about going toward a matrix form, where you've got rows and columns. For the env(), would we want to do that here also? Or a linearized version here for some reason? Both?

This sounds like pagination but for different shaped pages that are displays

dlibby: Perhaps having both would be useful, but the hesitation with the matrix is just for the set of hardware we know about currently, that extra metal load of the matrix-like syntax seems a difficulty for authors to get over. If there's consensus that having that consistency with the MQ.... We're amenable to having it for the syntax as well.

Also curious if this is meant to model complex non-rectangular amalgams of displays like adjacent Times Square video screens

fantasai: It would be good if the MQ + the env() would have consistent syntax. If we need the linear version for some reason, then maybe we can look into that. But we should aim for consistency

dlibby: Okay, we can take a look.

heycam: In the proposal, there's talk of 2d screen setup. Will this work with non-mobile device situations? 2d arrangements of monitors is usually for desktop machine.

q?

q+

dlibby: One thing we've been referring to is a semantic mode from the window manager. If there would be a desktop OS that supports an app window going into a configuration where it has a rectangular viewport that is spanning some number of screens, we would want it to apply. But if you're moving your window between displays and happen to let go of your mouse where a few pixels are bleeding into another monitor, that doesn't feel right for the

semantics of this.

window manager should be snapping that, probably

heycam: It seems like you would want to know the spatial arrangement of these displays. Even in a simple situation of two halves, if they are arranged vertically or horizontally, that would change how you woudl use the env() vars. Maybe we want the matrix syntax.

dlibby: Yes, it's important, and part of a separate issue related to the media issue that fantasai alluded to earlier. The proposal: Two media features, one in X direction and one in Y direction about how many you have in a certain axis.

dlibby: As newer form factors come into existence, they can fit into that

heycam: The author would have a MQ to select on arrangement, then within that, env() to index within that

dlibby: Yes. fantasai is right that we want consistency

ack smfr

smfr: I have a hard time evaluating these proposals b/c I don't understand the model w/r/t scrolling + zooming. When you scroll, do both screens move up and down at the same time? Is the right side showing the bottom of the left side down? Or can we do multicol thing where scrolling is <hand waves>

smfr: Or does the whole thing scroll as once? If you zoom, where is the origin? Is it all one big thing? I would like to see animated images how scrolling + zooming works.

dlibby: Okay. We can put that together. By default you have a single rectangular viewport / ICB which is the size of the rectangle, spanned across both screens. If you don't do anything special, the entire thing will scroll. The site could use the primitives that independently scroll themselves with overflow-scroll. We don't want these values to change on zoom. Similar principle on zoom - shouldn't change, like safe-area-inset. We don't want

relayouts on every zoom frame. To the exten that we can match that existing behavior we think that's a good model for these env() vars

smfr: I think it would be useful if your examples started with a simple case that didn't have a scrollable left column, and then add in teh scrollable left column wehre it makes sense to map things on to two screens.

smfr: Like a page with no columns. Wikipedia.

dlibby: At the bottom there's an example of an outlook application.

dlibby: Where it just flows across that seam or fold, across the 2 displays. It would scroll as if your viewport was just that size. This is about letting people customize that w/r/t the viewport.

smfr: I think that's fine.

astearns: I read through the proposals a few times. There's lots of layout described. Different kinds of layout across / separately. But to smfr's point, there isn't the extra stuff that he's asking for in terms of scrolling / zooming / other actions across both screens / independently. But it's a separate issue. smfr, can you raise a new issue about including more, specific examples?

smfr: Sure.

astearns: proposal: Develop a list and matrix version of variable references so that we can pull various pieces of an env() out, and resolve the syntax we choose for these variables should match the MQ for it

dlibby: That sounds like what i've been hearing?

RESOLVED: Develop a list and matrix version of variable references so that we can pull various pieces of an env() out, and the syntax we choose for these variables should match the MQ for it

Topic: [css-values-4] Ratio of `0/0`?

GitHub: w3c/csswg-drafts #4954

TabAtkins: A bit ago there was a question of what an aspect ratio of 0/0 means. Auto? Invalid? Something else? I opened an issue, but then closed it because I thought there was an obvious answer. But fantasai re-opened it because it wasn't obvious. I'll give my explanation, but if there's no easy answer, we can keep the issue open.

TabAtkins: The behavior of 0/0 is [should be?] Identical to 1/0. They produce an element that produces an element that wants to be infinitely tall/wide, depending. We have text in the values spec about what to do when you say width: 154892798542. Should be clamped to largest value you support. Nothing wrong with infinite or 0 ratio.

TabAtkins: So 0/0 should preserve the concept of an earlier meeting: a/b should be the same as calc(a/b).

TabAtkins: If you do calc(0/0) you get NaN which turns into positive infinity, which is the same a 1/0. It's an easy answer.

TabAtkins: So calc(0/0) is already defined, so just writing 0/0 should act the same.

aspect-ratio: calc(0/0) i salready well-defined (and same as aspect-ratio: 1 / 0)

TabAtkins: OTOH, 0/0 is a clear error case, so we can make it fall back to the initial value. We can't reject it at syntax time because the 0s could be produced by calc. But we could fallback to auto. Not unreasonable. But because infinite ratios already have well-defined behavior, and the behavior of treating it like 1/0 falls out of the calc behavior already, it's easier to be consistent with that.

honestly, why not

technically 0/0 is an "indeterminate form" en.wikipedia.org/wiki/Indeterminate_form

leaverou: I don't have an objection, but it seems weird to treat 0/0 == 1/0. 0/0 is indefinite in maths. It seems more reasonable to treat as invalid than infinity. If we can't change calc(0/0), then internal consistency is more important.

TabAtkins: Yes, 0/0 is definitely indefinite, but we censure (sensure? sensor?) it to infinity

did we consider animation implications here and is this the desired result? are aspect-ratio denominators animatable?

censor, I think

TabAtkins: Right now it always the case that calc() always produces a valid value. As long as you don't typecheck at parsing time, you can't produce a non-numeric value. That seems like a reasonable constraint to hold on to. Because you can approach 0 from different directions, there are multiple answers, but saying it's the same as 1/0 gives you *one* of the answers.

florian: Calc(0/0) can't turn into a keyword because it can be used in different properties

TabAtkins: When animation, we animate the division result, so the animation is consistent depending on whether you use calc(a/b) or use a / b, so animation behavior will be the same.

leaverou: If you animate 0/0 -> 0 / positive, you'll get disconuity.

TabAtkins: Don't do that.

TabAtkins: All the answers are arbitrary.

TabAtkins: We just pick one.

is it animated linearly or as the logarithm? Using the logarithm seems like it would give more consistent behavior between dimensions...

heycam: Are there other properties other than aspect-ratio that takes a ratio? Aspect-ratio does discrete animation.

TabAtkins: I have an issue open about aspect-ratio animation. I propose that it works like division.

TabAtkins: The only other place where ratio type is used is the MQ about aspect ratio.

astearns: Do people feel the argument about keeping the current calc behavior and make aspect ratio match it, is that compelling enough? Or should we leave the issue open?

I buy into TabAtkins 's logic

fantasai: The people who raised concerns were AmeliaBR and cbiesinger

I'm ok with TabAtkins logic though I'm going to s/indefinite/indeterminate per Wikipedia citation.

oriol: One argument about this, maybe we could say that saying the initial value is not possible, but we could resolve it to NaN and keep NaN into the outer calc, then bubble it up, and say if the number resolves to NaN it behaves as the initial value.

TabAtkins: If a top-level calculation ends up being NaN, the property would be invalid at computed value time. It's possible.

oriol: mhm.

q+

TabAtkins: I would prefer that aspect-ratio be consistent in both of its forms, but I don't have a strong opinion about which option we pick.

florian: For properties that take a single number or a single length, then sure. But if you're using calc() as one of many numbers in a property that takes many, like calc() in a shadow-spread, then maybe it's okay that you don't want to invalid the color just because the spread ended up being NaN.

cbiesinger: fantasai was poking me. I don't have an opinion. My suggestion is to treat 0/0 as the initial value. But I don't really have an opinion on how this should work with calc. But I don't really have an opinion

astearns: I'm inclined to resolve that we treat an aspect ratio of 0/0 as current calc(0/0). AmeliaBR isn't here, but we can always re-open the issue if she feels strongly about the resolution.

cbiesinger: calc(0/0) is a parse error in Chrome right now.

TabAtkins: We don't support dividing by zero yet (!!!)

RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio: calc(0/0)

topic: break

anyway, since it was a side comment, I mentioned my interpolation point at w3c/csswg-drafts #4953#issuecomment-712469770

is 'aspect-ratio' not a <ratio>?

dbaron: it's auto || <ratio>

Ah, dbaron, thanks for the comment there.

dbaron: ^

It would be nice if that were in the first 2 pages of results of google.com/search?q=site%3Acsswg.org+aspect-ratio

yeah... anyone have contacts at a search engine?

dbaron: Remember that drafts.csswg.org/indexes can locate any CSS property for you.

TabAtkins (IRC): that points to mediaqueries

ahaha nice

Oh maybe Sizing 4 isn't in the list of specs to look at yet!

('grid', for example, clearly handles both property and descriptor forms)

present+ James_Craig

Ah yeah, Sizing 4 is currently marked as an ignorable spec in Bikeshed's defaults. fantasai, sound good to remove that?

It'll mean links start going to 4 rather than 3 in other specs

Links should go to 3, not 4

But if something's only in 4, then link to 4...

idk if you can do that, but that's kinda where we're at

Sizing 4 is an unstable diff spec, not really a good reference

Yeah, if you *specify* that you want to link to Sizing 4 explicitly, you can still link into it, but otherwise it'll never resolve as a valid link destination

ScribeNick: TabAtkins

Topic: MQ serialization

github: w3c/csswg-drafts #5627

astearns: Proposed resolution is to drop the CSSOM-specified sorting of MQs in lexicogrpahic order when serializing

TabAtkins: No objection, but one example shows removing duplicates as well

TabAtkins: Should also make sure that is covered as well

astearns: Consensus in the issue, looks like

emilio: Don't think Gecko has ever sorted, and we don't seem to have an issue

astearns: Did you dedup?

emilio: Don't think so; maybe as part of MQList apis, but not serialization. will doule-check

astearns: So any objections?

RESOLVED: Do not sort or dedup MQs when serializing

Topic: forced-colors and prefers-contrast

github: w3c/csswg-drafts #5433

Morgan: We've been implementing prefers-contrast and forced-colors in Moz for a while

Morgan: Hoping to unpref adn ship soon

Morgan: Hesitant until this issue is resolved

Morgan: Don't have an opinion on the stances taken here

florian: Attempted summary of where we are

florian: We have two related things here

florian: prefers-contrast MQ, which is about letting the author know whether the user prefers higher or lower contrast on the page

florian: So author can change colors, add/remove borders, etc

florian: And notably, authors can use it without a specific value; (prefers-contrast) just indicates that they have *some* preference, but not whether it's high or low

florian: But general rule is that, regardless, removing visual clutter is often a good thing

florian: A related thing was added to css, forced-colors mode

florian: Not a user pref, it changes colors for the author automatically

florian: When responding to forced-colors, it can be useful for an author to do the same contrast adjustments, reducing clutter and such

florian: So we ahve a (prefers-contrast: forced-colors) value to indicate this

florian: So my feeling is that they're theoretically distinct, but in practice they're close together and can be addressed in similar ways

q-

Worth noting also that "forced colors" is called "high-contrast mode" in Windows, which developed it. It's clearly intended to handle a contrast preference.

florian: So right now we ahve both the (forced-colors) MQ as well, for legacy reasons

florian: We probably can't remove (forced-colors), for legacy compat reasons. We probably *could* remove the (prefer-contrast: forced), but I think it would be more useful to keep

jcraig: We also have prefers-reduced-transparency; I mention because we use it more to indicate reducing clutter

jcraig: Sometimes lower-vision users who would prefer contrast would also prefer less things floating with transparent bgs, so they'll often be set up together

jcraig: One unmentioned theoretical purity arg is that having forced-colors in here is the only instance so far with a prefers-* MQ having a value that does *not* correspond to a user preference

jcraig: Also reached out to aboxhall

jcraig: She shared this:

Alice: I am pretty convinced that the MS version (forced-colors: active) is better, but I don’t think I would have any critical arguments to add given there will presumably be MS folks there to articulate the reasoning (i.e. that forced-colours doesn’t necessarily have anything to do with contrast, since the color choices are arbitrary)

jcraig: So she doesn't have a strong opinion, but tends to agree that (forced-colors) is better

jcraig: Other thing I shoudl probably mention is that Apple doesn't ahve a forced-colors setting, so it's not particularly troublesome from Apple's perspective.

q+

jcraig: But I have opposite opinion from Florian for the author experience

jcraig: I think the convenience of being able to just write (prefers-contrast) doesn't outweight the clarity gained from writing (forced-colors)

ack fantasai

fantasai: It's worth noting that the forced-colors feature was developed as Windows High Contrast mode, so it was *intended* as forcing a particular contrast.

fantasai: Doesn't necessarily force a high contrast, but it does force a *fixed* contrast

fantasai: So not unreasonable for it to fall under the (prefers-contrast) MQ

fantasai: I have a side question on (prefers-reduced-transparency)

fantasai: If you have an opaque BG with a pattern on it, is that something that should be turned off if this pref is on?

fantasai: bc if it's actually about visual clutter, that's not stated by the name

q?

fantasai: Also, prefers-contrast *will* be true in the majority of cases where Windows High Contrast will be on

q+ to respond to Elika's q re background pattern versus transparency

fantasai: Because those forced colors will generally cause it to resolve to high or low (from the specification fo the forced-colors feature). ONly an indeterminate color scheme will not trigger it.

fantasai: So it's concerning a bit if authors are testing with High Contrast mode, and triggering (prefers-contrast), but then a user comes along with an indeterminate scheme, they might not get caught

fantasai: And in general, both (prefers-contrast) and (prefers-color-scheme) do reflect the choices made by Forced Colors mode

Morgan: Turns out I have an opinion

ack Morgan

Morgan: I added some info to the issue just a bit ago

Morgan: Firefox has a high-contrast mode built in, that's not OS-specific

Morgan: It triggers True when Windows High Contrast, or the browser-local HCM, is on

Morgan: So far we've found people using it for both high and low contrast reasons

Morgan: But also for things like photosensitivity

What does Firefox HCM "regardless of browser" mean?

Morgan: Those don't necessarily fall into high or low contrast bins

jcraig, suspect she meant "regardless of OS"

Morgan: So I agree with fantasai's concerns that they might not have their prefs reflected by authors

Morgan: Also, we find that devs often dont' have the ability to test with high contrast themes.

ack jcraig

Morgan: So if our local HCM doesn't trigger this query, they dont' have a way to test

q+

jcraig: So (forced-colors) just means colors were forced, not anything about the contrast. So I still think (prefers-contrast) isn't right to trigger it automatically

jcraig, sorry yeah regardless of OS :)

jcraig: wrt transparency and backgroudn color, on Apple OSes we hav separate settings for these bc the user may want or not want each of them

jcraig: There's often overlap, but the clarity from breaking them into separate settings is worth preserving, I think

jcraig: With the patterned background - in iOS we have a lot of transparency, but not a lot of loud backgrounds

jcraig: So if we wanted to do something more general about legibility, we could do something for that, but trying to tie "increase legibility" to a contrast setting seems weird, it should just be about contrast

present+

ack fantasai

fantasai: So james had one point about "this is not a preference, so why is it in a MQ about preference)

fantasai: So it's *already* going to trigger that *in most cases* - Forced Colors mode will *usually* trigger (prefers-contrast) and (prefers-color-scheme)

fantasai: And an author will thus usually see those turned on when they test in forced colors mode

fantasai: Also, for testing now - if authors write (prefers-contrast) in their stylesheet, and it *usually* triggers in forced colors (not all users, but most, including themselves), it's likely they'll write code depending on that, which then doesn't trigger for users in the in-between state that coudl still usefully use the adjustments

fantasai: So it's easy to leave out a class of users by accident

q+

I don't agree that "most prefers-contrast users" will have forced colors on... iOS "increase contrast" doesn't force colors.

fantasai: So I think that's another reason why having forced colors *explicitly* fall under prefers-contrast helps out

jcraig: I think elika said taht most prefers-contrast people will ahve forced colors...

q+

florian: No, other way around. If they have forced colors, and they are high-contrast, then you'll trigger (prefers-contrast: high). And same for (prefers-color-scheme) if they're light or dark, etc

florian: So *most* of the time forced colors will cause these other MQs to trigger, but if you have a middling color scheme, you'll be in a rare bucket that won't trigger the boolean form at all

florian: So adding the 'forced' keyword in makes sure they trigger at all times

jcraig: So as an author, I'm not sure whether to check for (prefers-high-contrast: high) or (prefers-high-contrast: forced)

jcraig: And then it's just weird still to have another setting to the exact same thing

q?

ack florian

florian: Both in terms of transparency and patterns and this argument, I think there's a general tension between a11y features here

florian: On the user side, general desire to express complex needs, because users have many needs and preferences

s/(prefers-high-contrast: high) or (prefers-high-contrast: forced)/(prefers-contrast: more) or (prefers-contrast: forced)/

florian: But if we expose too many fine-grained prefs, it's likely authors won't respond to everything. The more we group them, the more likely the response isn't *perfectly* targeted at their need, but more likely they'll get a *reasonable* response.

florian: So trade-off of perfect responses (that ar eless likely) vs okay responses (that are more common)

florian: I think the current design is about right for this reason, but we can disagree on the limit

ack TabAtkins

ack Morgan

TabAtkins: Florian made the exact point I was going to

Morgan: Last time this discussed, no definition of "more" or "less" ratios

more than default, less than default

Morgan: Saw this as a sliding scale of more and less as higher and lower ratios defined by user agent

s/ar eless/are less/

Morgan: So if you see this as a continuum, makes sense to me that the middle values also trigger the MQ, rather than there being a threshold that turns it on only for more extreme values

jcraig: Responding to florian's, I agree we ahve a decision to make about granularity

jcraig: My opinion is that it should be towards granular side.

q+

florian: The people who ask for it know what they want, but if too granular, they just wont' get what they want often

jcraig: How i understand windows hcm right now, it'll match both 'forced' and either 'more' or 'less' if appropriate

jcraig: I think it's quite reasoanble to match 'more' if HCM is on

jcraig: is on with a high-contrast scheme

jcraig: And if we want to have a separate granular reference to forced colors in general, still don't understand why it needs to be the same

jcraig: You're talking about a boolean match for contrast that is high, or low, or in the middle.

q+

ack TabAtkins

TabAtkins: wrt granularity choice, directly related to what you were saying

TabAtkins: our current proposal has that granularity

TabAtkins: You can target high contrast, low contrast, and forced contrast specifically and independently

TabAtkins: But something you are likely to want to do for all of them is to simplify the page

TabAtkins: If this is indeed the case, then we should have something that catches everything simply

TabAtkins: And certainly should be something that catches the more common and less common cases the same way

TabAtkins: I would rather authors have an general switch, rather than needing to list each thing independently

TabAtkins: If your argument is that there is no reasonable thing to do that applies to all these contrast modes

TabAtkins: then we don't need it

Loss audio in the middle of Tab's comment

TabAtkins: but if there is, then we need a good syntax for doing so

jcraig: if ... about syntax, then happy to take it to a vote

jcraig: I don't think authors are going to see (prefers-contrast) or even (prefers-contrast: forced) and jump to conclusion of needing to reduce decoration on the page

astearns: Any input from ppl not yet part of the conversation?

ack emilio

Going for a more general "prefers-simple" MQ doesn't sound unreasonable...

emilio: Conversation was we cannot remove 'forced-colors: active'

emilio: Convo started with "we can't remove (forced-colors)

emilio: I don't see 'prefers-contrast: forced' adding a lot of value

emilio: I dont' see (prefers-contrast: forced) having a lot of value here

emilio: prefers-contrast and forced-colors are technically unrealted and they should be separate MQs

florian: On the one hand, I don't think this is a breaking point; I'd be willing to yield if necessary.

florian: But I feel like fantasai and TAb and I are making an argument for it being useful, but y'all keep saying "i dont' see why it's useful" - we just *said* why it was useful

florian: I don't think we're wrong that the syntax is convenient, but are we wrong about the use-case?

astearns: Is the user-case enabled by (forced-colors)?

florian: No, it's not about responding to forced colors specifically.

q+

florian: In the case of an author that has a low and high contrast mode, it seems reasonably likely they'd have some bit of the code specific to those modes, and a shared chunk applied to both high and low modes that, for example, disables backgrounds.

florian: The way they'd write that code is with the common code in (prefers-contrast), then specific ones in (prefers-contrast: more)/etc

(prefers-contrast) versus (prefers-contrast or forced-colors)

florian: Assuming they do that sort of code organization, should we allow that to still work when the user has HCM set to a middlign contrast, or should we say that authors should know to pay attention to the (forced-colors) MQ as well specifically to handle these cases?

fantasai: And more complexity here - the people using HCM will get those shared styles *if* their chosen colors are high-contrast or low-contrast. And users in the middle have the same *needs* as high and low, but without 'forced' they wont' get it

fantasai: And from a dev POV, devs will very likely test HCM with a high-contrast theme, and they'll assume their page is working in a particular way when forced-colors is on and in a high-contrast mode. But users not matching that case won't get hit.

FWIW I agree with @fantasai's latest comment; authors will not expect the block to turn off

q+

fantasai: So having pages fall into codepaths that aren't tested is a great way to have a broken page

ack jcraig

jcraig: I see the point, and the mild syntax convenience

zakim, close queue

jcraig: Potentially could match something that might provide a convenience in the interface to an author that wants to reduce complexity.

jcraig: If we assume that authors will know that and respond to it.

jcraig: But I think the risk is that authors will conflate different things

jcraig: Recent years, authors conflate small viewport widths to mean it's on mobile

jcraig: Or check the user agent and see iOS and assume it's a phone and not an iPad

jcraig: Apple had to do a lot of work to make sure iPads get desktop sites, for example

The reason authors are conflating those things is because they had no other way to detect the things they were interested in

jcraig: So even tho these are somewhat conflated, risk of conflating them

e.g. knowing you're on a touchpad is important consideration in design, but there was no ability to query that directly

so authors made a lot of assumptions

emilio: I get fantasai's point, but we can solve it without ahving to expose the 'forced' value

We don't have that problem here because we already have the individual options available to query

s/somewhat conflated/somewhat related/

emilio: You can just say if you're forcing colors you *must* match high or low

emilio: When forcing colors you most can't override system colors

emilio: I think having two MQs mean the same thing isn't amazing either

topic: end

fantasai: so florian started with the premise that we couldn't do that. If we can, I don't particularly object. Though I think `@media (forced-colors) or (prefers-contrast)` is not significantly worse than what you're proposing, and it's way more clear on when it can match

emilio, yeah, it's possible

problem is that (prefers-colors) will match almost all but not all users of forced-colors

fantasai: having media queries that have different keywords like `(prefers-contrast)` is a bit confusing I suspect, and I'd avoid it, though...

Notes for posterity (I think it's clear to attendees) that fantasia's comment "deprecate the old one and move to the new one" is the opposite of what Emilio suggested: "deprecate the new one since we have to keep the old one for interop and the new one does not provide enough additional benefit"

Right

s/fantasia/fantasai/

zakim, end meeting

fantasai: if we take the path that I was suggesting (just keep `forced-colors`, don't ship `prefers-contrast: force`), and we realize that pages are just using `(prefers-contrast)` and hurting `(forced-colors)` users with non-high/low-contrast colors, the UA could pretty easily choose one of the `high` / `low` variants I suspect...

fantasai: all this discussion reminds me of the `(prefers-color-scheme)` discussion fwiw

emilio, I don't think you want to trigger high/low in middling cases

fantasai: but if you're forcing colors you can't use non-system colors anyways (well I guess if you use force-color-adjust), so I don't think it'd be a meaningful difference in most cases...

fantasai: but anyhow fair

that's not true, emilio

images aren't affeted

affected

you can use any colors you want in an image

fantasai: true, that

or in a `forced-color-adjust: none` subtree

fantasai: I guess you could always match the boolean query even though you don't match `high` nor `low` nor `no-preferecence`... But I still think that contrast preference and forced colors are two different things

That would be really confusing :)

fantasai: right

It has to match one of the keywords to match the boolean

forced colors was invented for people who wanted a particular contast preference

yeah, the current model requires *some* value to match, and I don't think it's worthwhile to break that

I mean, my preference is to not have forced and not match the boolean in middling color schemes, just keeping them separated

we could have named the middle value "middle", but "forced" more accuratelly communicates "you have no idea what they're wanting, please use the system colors rather than your own colors"

I guess lacking that fantasai / florian's alternative is the best. I'm not convinced that `forced` provides a lot of value

I guess in the end depends on how authors end up using it. Ideally people would advocate just `@media (forced-colors) or (prefers-contrast)`, then specific high/low settings

But I guess for that WebKit / Blink would need to implement `or` in media queries ;)

oooh, snap