-
astearns
The color on the web/media and entertainment meeting is being minuted on #me
-
» myles me
-
bkardell_
present+
-
» astearns is not following the technical bits of the color discussion, but really liking the idea of “color excursions”
-
gsnedders
do we define "property"/"descriptor" anywhere?
-
gsnedders
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?
-
Rossen_
Zakim, start meeting
-
Zakim
inviting RRSAgent
-
RRSAgent
-
Zakim
RRSAgent, make logs Public
-
RRSAgent
I have made the request, Zakim
-
Zakim
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
-
» florian is anyone able to join the google meet already?
-
» Rossen_ not yet
-
» florian is stuck on "asking to join…"
-
» florian Ok, I guess I'm stuck in the right place then :)
-
dbaron
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.
-
-
emilio
present+
-
alisonmaher
present+
-
Rossen_
present+
-
miriam
present+
-
fremy
present+
-
rego
present+
-
plh
present+
-
astearns
present+
-
oriol
present+
-
lajava
present+
-
heycam
present+
-
dlibby
present+
-
faceless2
present+
-
cbiesinger
present+
-
» TabAtkins very "whose line is it anyway" vibes with these points
-
TabAtkins
present+
-
heycam
ScribeNick: heycam
-
» TYLin present+
-
Morgan
present+
-
TYLin
present+
-
fantasai
present+
-
» TabAtkins I'll take the last session today
-
tantek
present+
-
myles
present+ myles
-
Guest60
present+
-
Guest60
present-
-
GameMaker
present+
-
tantek
I can if need be however this is me gesturing the touch UI of my iPad
-
jensimmons
present+
-
Rossen_
Scribes [Cam, Tab, Myles, Tantek]
-
» TabAtkins huh, looks like I can run polls in Meet now
-
bkardell_
present+
-
fantasai
Topic: Introductions
-
Rossen_
Rossen Atanassov, Microsoft
-
brandonferrua
present+
-
astearns
Alan Stearns, Adobe
-
alisonmaher
Alison Maher, Microsoft
-
heycam
Cameron McCormack, Mozilla
-
dlibby
Daniel Libby, Microsoft
-
» florian waves to Mini Baron
-
» astearns the baby looks like they are warily watching the Mozilla poster
-
hober
present+
-
fantasai
Elika Etemad aka fantasai, Invited Expert
-
emilio
Emilio Cobos, Mozilla
-
fremy
François REMY, Invited Expert
-
bkardell_
Brian Kardlel, Igalia
-
» fremy JS joined the chat!
-
lajava
Javier Fernandez, Igalia
-
florian
Florian Rivoal, Invited Expert
-
rego
Manuel Rego, Igalia
-
miriam
Miriam Suzanne, Invited Expert
-
oriol
Oriol Brufau, Igalia
-
myles
Myles C. Maxfield, Apple Inc.
-
plh
PLH, W3C
-
tantek
Tantek Çelik, Mozilla
-
hober
Theresa (Tess) O'Connor, Apple
-
GameMaker
Megan Gardner, Apple
-
faceless2
Mike Bremford, BFO
-
Morgan
Morgan Reschenberg, Mozilla
-
brandonferrua
Brandon Ferrua, Salesforce
-
TYLin
Ting-Yu Lin, Mozilla
-
» fantasai loves how everyone is typing their names and affiliations into IRC, so hard to get other groups to do this :)
-
Rossen_
q+
-
» Zakim sees Rossen_ on the speaker queue
-
Rossen_
q-
-
» Zakim sees no one on the speaker queue
-
TabAtkins
Tab Atkins, Google
-
» TabAtkins whoops
-
» tantek fantasai this is a well-trained WG :)
-
fantasai
[[ Type q+ into IRC to add yourself into the queue ]]
-
» fantasai I know <3
-
heycam
Topic: Republishing tasks
-
heycam
-
-
» astearns fantasai has done most of the training
-
» TabAtkins [[ type qq+ if you have an *urgent* point to bump yourself to the front of the queue ]]
-
» fantasai :P
-
heycam
fantasai: we are super behind on keeping outselves up to date on TR pages
-
heycam
... as of Sep 13 the Process has been updated
-
heycam
... I created this issue to make sure we get around to publications
-
heycam
... Houdini is mostly not published, for several years
-
heycam
... open request for Sizing
-
heycam
... any other people who want to request publication, agenda+ this issue
-
heycam
... then we can use this issue to track whether it got published
-
heycam
... at astearns's request, I made an "estimated publication badness chart"
-
heycam
-
astearns
q+
-
» Zakim sees astearns on the speaker queue
-
heycam
fantasai: if you want to edit this file it's in GitHub
-
heycam
... there are lots of spec that need publication!
-
heycam
... it's causing confusion for other groups
-
heycam
... publishing is easy. if you're confused on how to do it, ask in IRC
-
heycam
... the one thing without resolution that needs it is sizing-4
-
fantasai
-
heycam
... that's a WD
-
Rossen_
q?
-
» Zakim sees astearns on the speaker queue
-
chris
present+
-
heycam
RESOLVED: Publish sizing-4
-
Rossen_
ack astearns
-
» Zakim sees no one on the speaker queue
-
chris
q+
-
» Zakim sees chris on the speaker queue
-
florian
q+
-
» Zakim sees chris, florian on the speaker queue
-
heycam
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
-
heycam
fantasai: cascade-3 is blocked
-
heycam
... on various Proposed Rec things
-
heycam
chris: conditional-3 has the oldest one I think, 2013
-
heycam
... it's getting there, should we get an updated CR on that?
-
heycam
fantasai: CRD? we can do that
-
heycam
... Process 2020 has two types of CR publications
-
heycam
... the official snapshot, that goes through approvals etc. then there's Candidate Rec Draft, similar to WD, which allows some open issues
-
heycam
... a CRD has to represent WG consensus
-
heycam
Rossen_: any delta between what would be in the CRD and what is currently in broad horizontal review?
-
heycam
fantasai: yes. there a bunch of changes since the last PR
-
fantasai
s/PR/CR/
-
heycam
Rossen_: do we have to go and review all the changes?
-
heycam
fantasai: no, purpose of CRD is so you don't have to do that, or the DoC
-
heycam
... have to list changes since the last CR, and WG consensus on material different from the last CR
-
heycam
florian: goal is equivalent in quality to CR, but less process heavy
-
heycam
dbaron: just need a resolution, if nobody objects, it's WG consensus
-
florian
q?
-
» Zakim sees chris, florian on the speaker queue
-
heycam
s/dbaron/chris/
-
heycam
RESOLVED: publish CRD of conditional-3
-
Rossen_
ack chris
-
» Zakim sees florian on the speaker queue
-
Rossen_
ack florian
-
» Zakim sees no one on the speaker queue
-
drousso
present+
-
» tantek remembers when CRD expanded to Customer (or Client) Requirements Document
-
heycam
florian: back when Tess was an editor, we were going to have an event handler section in highlighter
-
heycam
... the rest of the spec is not final, but it's FPWD-ish
-
fantasai
s/highlighter/highlight-api/
-
heycam
... proposing we publish it as is
-
heycam
... there's a placeholder in the ToC for event handling
-
heycam
... but having live material live off /TR for years is not good, so let's publish it
-
» TabAtkins my brain just automatically expands CRD as Carly-Rae Depson
-
heycam
Rossen_: who are the authors?
-
hober
+1
-
heycam
hober: editors will be Megan, Florian, Sanket
-
heycam
florian: I will fill that in, then work with Megan/Sanket to get issues resolved after publishing
-
heycam
RESOLVED: publish highlight-api
-
» fantasai q+ to ask about env
-
» Zakim sees fantasai on the speaker queue
-
» fantasai q-
-
» Zakim sees no one on the speaker queue
-
heycam
fantasai: just want to note that env and scroll-animations also should be published
-
fantasai
s/should be published/have no FPWD/
-
» TabAtkins Me and Dino are the env folks
-
heycam
florian: as Alan pings authors, we'll follow up with the env folks
-
heycam
s/florian/Rossen/
-
heycam
Topic: Fix aspect-ratio errors in css-grid-1
-
-
heycam
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5615 ([css-grid-1] Fix aspect-ratio errors in css-grid-1).
-
» florian Megan, I plan to get in touch shortly to work out how we make progress on css-highlights. If I don't, please ping me.
-
heycam
fantasai: there was a commit which attempted to clarify interaction of aspect-ratio and grid item sizing
-
heycam
... that introduced an error, which I fixed
-
heycam
... I'd like to verify the fix with the WG
-
heycam
... and republish grid-1 and grid-2 with the correction
-
heycam
... as a CRD
-
heycam
Rossen_: is there a commit diff we should be looking at?
-
heycam
... or just that PR that you linked there
-
fantasai
-
heycam
fantasai: commit I linked, that shows the fix to the problem, but the resulting text needs to be reviewed
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
heycam
Rossen_: we resolved for this change that will be different from flexbox, right?
-
heycam
fantasai: this one wasn't supposed to be a change, just a clarification
-
heycam
... can grab a diff against the older version
-
fantasai
-
fantasai
-
chris
rrsagent, here
-
RRSAgent
-
chris
rrsagent, make minutes
-
RRSAgent
I have made the request to generate
w3.org/2020/10/19-css-minutes.html chris
-
heycam
Rossen_: any comments or objections to accept this diff?
-
heycam
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
-
heycam
... so if you have stretch, aspect-ratio is not taken into account
-
heycam
... so I think removing this sentence is good
-
florian
I was hoping oriol had reviewed this. Given that he has, I feel confident it's fine :)
-
dbaron
(There was a line attributed to me above that wasn't me, btw.)
-
heycam
RESOLVED: accept aspect-ratio error changes in css-grid-1
-
» heycam dbaron I fixed that
-
heycam
Topic: Resolution of percentage row tracks and gutters with indefinite height
-
-
heycam
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5566 ([css-grid] Resolution of percentage row tracks and gutters with indefinite height).
-
heycam
rego: this is an old discussion
-
heycam
... this is about how we resolve percetange row tracks/gutters
-
heycam
... with a minimum height
-
heycam
... we resolve to intrinsic height that we compute
-
heycam
... that causes overflow in many cases
-
heycam
... and makes it more complicated, and no interop
-
heycam
... in Firefox it is doing the old behavior. %age tracks resolve to auto
-
heycam
... I was proposing here to change again, and get interop in this case
-
heycam
... and then also change how gutters work, which Firefox does do
-
-
» github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
-
heycam
... we have been discussing for a long time, checking compat issues, we already had a use counter for %age tracks, also for gutters
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
heycam
... checking the results, grid tracks where 0.03% of page views
-
heycam
... that's going down, to not count 1 row with 100%
-
heycam
... we analyzed the pages from that, only 1 broke
-
heycam
... with gutters, the usage is very low. 0.003% of page views
-
heycam
... 40 pages, only 1 broke
-
heycam
... so this change will align us with flexbox, and get interop in the tracks part that we don't have right now
-
heycam
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
-
heycam
... which is to hold the behavior of rows and columns, and row gutters / col gutters, to be symmetric
-
heycam
... strong desire for this
-
heycam
... strong pushback against things going against this principle
-
heycam
... don't want to relitigate that
-
heycam
... so why should we change it for this one?
-
heycam
rego: it will break that principle. the reasons we should change are in the top of the issue
-
heycam
... it usually causes overflow when people use it
-
heycam
... it requires worse perf in track sizing
-
heycam
... and we don't have interop
-
heycam
... but I agree it will break that principle
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
» florian thanks chris . I had 99% forgotten FPWD needed Director approval, given that's it's pretty much always given. Thanks for filing the request
-
heycam
Rossen_: would like to hear from more people. personal preference to hold on to that principle
-
heycam
... it's an easy slippery slope to get on
-
heycam
... yes there are expectations when they compare other 1D layout systems like block and flexbox.
-
heycam
... with this particular one, I think we should hold a high bar in keeping that principle going forward
-
» chris no problem, plus plh is on the call right now so could easily approve it instantly :)
-
heycam
jensimmons: I haven't heard much about this kind of stuff at all
-
heycam
... feel like authors haven't quite grasped grid fully yet
-
heycam
... lack of compat is a problem, would like interop asap, even if the behaviour feels a bit buggy
-
heycam
... and stop using percents for gutters anyway
-
heycam
... so in some ways I don't really care about this, since they shouldn't be using percentages
-
» fantasai suggests deferring and pinging rachelandrew and mats
-
» plh chris, done
-
heycam
Rossen_: I think the data agrees with your observations, few cases in the wild
-
heycam
... doesn't feel like it's strongly motivated
-
heycam
miriam: that's my experience as well
-
heycam
fantasai: I think it'd be good to hear from mats and rachel
-
heycam
... if nobody else had anything else to add, could defer to hear from them
-
heycam
Rossen_: in the meantime we can publish grid-1 and grid-2 as CRDs
-
heycam
Topic: Fix aspect-ratio errors in css-grid-1
-
» astearns I’ll put the topic also into Friday’s agenda
-
-
heycam
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5615 ([css-grid-1] Fix aspect-ratio errors in css-grid-1).
-
heycam
Rossen_: any objections to publishing a CRD for grid-1?
-
heycam
RESOLVED: publish a CRD for grid-1
-
heycam
Rossen_: and for grid-2?
-
heycam
RESOLVED: publish a CRD for grid-2
-
heycam
Topic: Clear 'aspect-ratio' for shipping
-
-
heycam
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5598 ([css-2020] Clear 'aspect-ratio' for shipping).
-
heycam
fantasai: do we want to add aspect-ratio to the snapshot?
-
heycam
... suitable for shipping in impls yet?
-
heycam
cbiesinger: the intent to ship has been approved
-
heycam
... so we are planning to ship in the next version
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
heycam
heycam: we are also making good progress, will be ready in the coming months
-
heycam
fantasai: this wouldn't be CR, needs more work before that
-
heycam
... we add it to snapshot-2020 in the "not CR but ready for shipping" section
-
heycam
heycam: issue status?
-
» florian fantasai TabAtkins speaking of the snapshot, we should figure out what we need to do to get it out. I recall a few open issues
-
heycam
fantasai: thing most have been resolved
-
heycam
... Tab and I did a triage recently
-
heycam
Rossen_: will we reach CR if we go through these issues?
-
heycam
fantasai: sizing-4 is a WD
-
fantasai
Discussion is about adding to
w3.org/TR/CSS/#CR-exceptions
-
heycam
RESOLVED: add aspect-ratio to the "clear for shipping despite not being in CR" section of snapshot-2020
-
heycam
Topic: How widely should HTML's 'aspect-ratio' presentational attribute be applied?
-
-
heycam
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5608 (How widely should HTML's 'aspect-ratio' presentational attribute be applied?).
-
heycam
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
-
heycam
... I wrote the spec text for it
-
heycam
... Domenic asked which elemetns it should apply to
-
heycam
... prev spec text applied to img specifically
-
heycam
... (side discussion about <picture>)
-
heycam
... but there are other elements that we do use width/height on
-
heycam
... video, possibly embed/object
-
heycam
... canvas, <input type=image>
-
jensimmons
q
-
» Zakim sees no one on the speaker queue
-
jensimmons
q+
-
» Zakim sees jensimmons on the speaker queue
-
heycam
... 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?
-
heycam
... I think we should, and go with elika's list
-
heycam
... embed/object applying an intrinsic ratio doesn't always apply)
-
emilio
q+
-
» Zakim sees jensimmons, emilio on the speaker queue
-
heycam
jensimmons: to remind everyone, this is about improving the experience for users while the page is loading
-
heycam
... the intention is that it has no affect on layout after these assets have loaded
-
Rossen_
ack jensimmons
-
» Zakim sees emilio on the speaker queue
-
heycam
... once an image has loaded, it should get the same layout it would've had
-
heycam
... should work the same way for video
-
heycam
... they do have an intrinsic aspect ratio
-
heycam
... should apply to any HTML element where this is true
-
heycam
... so does not apply to a typical iframe, since they don't have intrinsic aspect ratio
-
heycam
... it's also true that embed/object can sometimes have an intrinsic aspect ratio
-
florian
q+
-
» Zakim sees emilio, florian on the speaker queue
-
heycam
... but if there are complications it's not critical
-
heycam
emilio: I agree with this
-
» astearns likes the word ‘suss’
-
Rossen_
ack emilio
-
» Zakim sees florian on the speaker queue
-
heycam
... when we initially implemented this for img, we still didn't have the compat requirements
-
heycam
... I think this is pretty reasonable
-
heycam
florian: makes a lot of sense to me
-
Rossen_
ack florian
-
» Zakim sees no one on the speaker queue
-
heycam
... 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?
-
heycam
... or it all falls into the same bucket?
-
heycam
emilio: when we did it for img, we override the aspect ratio, but people put wrong values
-
heycam
... the auto value is like a low priority hint
-
heycam
... I think the compat impact is going to be extremely low
-
heycam
florian: canvas loads a bit differently from these other things
-
heycam
... you don't load an external file
-
heycam
TabAtkins: intrinsic size is based on the backing store
-
heycam
florian: script controlled? and so if the script hasn't run yet it's a similar situation?
-
heycam
myles: it's based on the attributes on the element
-
heycam
TabAtkins: you're right
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
heycam
... but it would still be consistent with images
-
heycam
florian: less useful but still doesn't hurt
-
heycam
Rossen_: in the case of picture/srcset, does it come from the first image?
-
heycam
emilio: I think it would be the actual <img> inside the picture
-
heycam
... but there's another PR to make width/height apply to src
-
heycam
... there's no precedent for other elements' attributes affecting intrinsics
-
heycam
TabAtkins: but that's behind discussed elsewhere
-
heycam
s/behind/being/
-
TabAtkins
img, input type=image, video, canvas
-
heycam
RESOLVED: apply aspect ratio pres hint to img, <input type=image>, video, canvas
-
TabAtkins
<br dur=10min> (back at :10 after your hour)
-
astearns
topic: break
-
-
» tantek needs to run and get coffee & snack. will likely be back more like :20 (obv don't wait, thx)
-
myles
ScribeNick: myles
-
myles
Topic: zoom!
-
astearns
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5623 (Revisiting standardization of the `zoom` property ).
-
myles
dlibby: Last time this was discussed as 5 years ago. The zoom property came from IE. It was picked up by webkit / blink.
-
myles
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
-
» fantasai myles, if you want to participate, I can scribe this session
-
myles
dlibby: There have been attempts to implement in terms of transform / transform-origin. It fixed some content, but didn't fix everything
-
» myles fantasai I don't think i will participate
-
» florian chris what was your background during the media call? It looked like you were inside a giant poppy flower or something
-
» myles fantasai thanks
-
myles
dlibby: We should try to standardize this. What appetite is there for documenting existing bugs / odd behavior vs trying to fix them.
-
myles
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.
-
leaverou
present+ leaverou
-
myles
dlibby: Others' thoughts?
-
dbaron
present+ dbaron (intermittently)
-
» chris it was an actual physical background. A bright red wall and a wrought-iron foliate bedhead. Plus a massive failure of auto whitebalance in the software
-
myles
emilio: I made my comment in the issue. I would not be a fan of standardizing the current behavior. It's extremely wrong.
-
myles
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
-
myles
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.
-
myles
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
-
myles
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.
-
emilio
q+
-
» Zakim sees emilio on the speaker queue
-
astearns
ack emilio
-
» Zakim sees no one on the speaker queue
-
myles
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
-
myles
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
-
myles
emilio: You don't want double-scaling which sucks
-
myles
florian: Is moz-transform cleaner?
-
myles
emilio: -moz-transform is an alias to transform.
-
dlibby
q+
-
» Zakim sees dlibby on the speaker queue
-
myles
fantasai: Would Chrome be able to remove zoom and add -moz-transform as an alias of transform?
-
astearns
ack dlibby
-
» Zakim sees no one on the speaker queue
-
fremy
q+
-
» Zakim sees fremy on the speaker queue
-
myles
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.
-
myles
dlibby: I don't know if there's precedence, thought. I'd have to consult with others. The idea is interesting.
-
myles
florian: There is precedence for setting in stone things with odd names with vendors in them. Maybe not -moz- specifically though.
-
myles
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.
-
astearns
ack fremy
-
» Zakim sees no one on the speaker queue
-
fantasai
s/it can't/legacy zoom can't/
-
myles
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.
-
myles
florian: It is layout-affecting transforms.
-
myles
fremy: You can't achieve that with transform
-
jensimmons
q+
-
» Zakim sees jensimmons on the speaker queue
-
myles
florian: The way that zoom affects layout is weird. Can we remove the weird one, or do we have to spec it
-
myles
fremy: Can we redefine how zoom works that's sane?
-
myles
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.
-
fantasai
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/
-
myles
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
-
myles
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
-
myles
astearns: right.
-
astearns
ack jensimmons
-
» Zakim sees no one on the speaker queue
-
heycam
q+
-
» Zakim sees heycam on the speaker queue
-
myles
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
-
myles
"let's make something incredibyl complicated" but that feels like the right direction.
-
myles
jensimmons: zoom is unspecified and has total lack of interop.
-
dbaron
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.
-
myles
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"
-
astearns
ack heycam
-
» Zakim sees no one on the speaker queue
-
myles
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.
-
emilio
q+
-
» Zakim sees emilio on the speaker queue
-
smfr
q+
-
» Zakim sees emilio, smfr on the speaker queue
-
jensimmons
btw, I made this demo while listening to see what's different between zoom & transform scale:
codepen.io/jensimmons/pen/gOMMJMz
-
astearns
zakim, close queue
-
Zakim
ok, astearns, the speaker queue is closed
-
myles
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.
-
myles
dlibby: There were a few other use cases that were less compelling.
-
myles
dlibby: This one is the most compelling to me.
-
astearns
ack emilio
-
» Zakim sees smfr on the speaker queue
-
myles
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.
-
astearns
ack smfr
-
» Zakim sees no one on the speaker queue
-
dbaron
lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0267.html at least recorded an action to post a proposal for layout-affecting transforms
-
myles
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.
-
myles
emilio: Control-plus in gecko affects the CSS px scale. and viewport.
-
myles
myles: We also have that zoom
-
myles
smfr: That's what we have, it changes the size of css px
-
myles
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.
-
myles
astearns: dbaron posted a link where we wanted to make layout-affecting transforms before
-
myles
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
-
myles
dlibby: Good discussion. Thanks.
-
myles
dlibby: This is a clear path forward that ideally does not specifying the current behavior.
-
myles
Topic: Updating the css `env()` function to enable selection by index from a list of pre-defined environment variables
-
-
myles
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5622 (Updating the css `env()` function to enable selection by index from a list of pre-defined environment variables).
-
myles
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
-
myles
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.
-
myles
dlibby: We have not yet heard use cases for integrating into the various layout submodules.
-
fremy
q+ (after Tab gets an opportunity to reply)
-
» Zakim whispers to fremy that the speaker queue has been closed
-
astearns
zakim, open queue
-
Zakim
ok, astearns, the speaker queue is open
-
TabAtkins
q+
-
» Zakim sees TabAtkins on the speaker queue
-
» TabAtkins there you go, fremy
-
fremy
q+
-
» Zakim sees TabAtkins, fremy on the speaker queue
-
myles
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.
-
myles
dlibby: Our goal is to get something into the WD for css-env. But feedback on the concept / makes sense/ etc. would be appreciated.
-
astearns
ack TabAtkins
-
» Zakim sees fremy on the speaker queue
-
heycam
q+
-
» Zakim sees fremy, heycam on the speaker queue
-
myles
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
-
myles
the [missed]
-
fantasai
+1 to Tab
-
myles
TabAtkins: I'm happy to add in 1+ integers after the variable name, that makes sense.
-
fantasai
s/[missed]/env() function/
-
astearns
ack fremy
-
» Zakim sees heycam on the speaker queue
-
myles
fremy: That mostly covers the thing I was going to say.
-
bkardell_
q+
-
» Zakim sees heycam, bkardell_ on the speaker queue
-
myles
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.
-
myles
fremy: Why limit ourselves to integers?
-
» fantasai q+ to ask about viewport vs display
-
» Zakim sees heycam, bkardell_, fantasai on the speaker queue
-
myles
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
-
myles
an element.
-
myles
fremy: Like what TabAtkins said, we don't need a function, but we can put any arbitrary ident there.
-
myles
myles: Floating point values makes that tricky
-
myles
TabAtkins: it would be ident | int
-
astearns
ack heycam
-
» Zakim sees bkardell_, fantasai on the speaker queue
-
myles
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.
-
astearns
ack bkardell_
-
» Zakim sees fantasai on the speaker queue
-
myles
<dlibby's connection is broken, he can't answer>
-
» tantek RRSAgent, pointer?
-
-
astearns
ack fantasai
-
Zakim
fantasai, you wanted to ask about viewport vs display
-
» Zakim sees no one on the speaker queue
-
» florian array indices? multiple degrees of deferencing? pointer arithmetics in css? the future looks bright :)
-
astearns
q+ bkardell_
-
» Zakim sees bkardell_ on the speaker queue
-
bkardell_
q-
-
» Zakim sees no one on the speaker queue
-
myles
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()
-
myles
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
-
myles
astearns: If we decide to use a list syntax now, can we extend that to accommodate a matrix syntax?
-
myles
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()
-
myles
<dlibby is back>
-
myles
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()
-
myles
dlibby: We are querying the viewport in relation to the physical/logical display regions.
-
myles
fantasai: That needs to be clear in the name.
-
myles
fantasai: and in the spec also.
-
myles
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?
-
tantek
This sounds like pagination but for different shaped pages that are displays
-
myles
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.
-
tantek
Also curious if this is meant to model complex non-rectangular amalgams of displays like adjacent Times Square video screens
-
myles
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
-
myles
dlibby: Okay, we can take a look.
-
myles
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.
-
astearns
q?
-
» Zakim sees no one on the speaker queue
-
smfr
q+
-
» Zakim sees smfr on the speaker queue
-
myles
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
-
myles
semantics of this.
-
fantasai
window manager should be snapping that, probably
-
myles
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.
-
myles
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.
-
myles
dlibby: As newer form factors come into existence, they can fit into that
-
myles
heycam: The author would have a MQ to select on arrangement, then within that, env() to index within that
-
myles
dlibby: Yes. fantasai is right that we want consistency
-
astearns
ack smfr
-
» Zakim sees no one on the speaker queue
-
myles
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>
-
myles
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.
-
myles
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
-
myles
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
-
myles
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.
-
myles
smfr: Like a page with no columns. Wikipedia.
-
myles
dlibby: At the bottom there's an example of an outlook application.
-
myles
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.
-
myles
smfr: I think that's fine.
-
myles
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?
-
myles
smfr: Sure.
-
myles
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
-
myles
dlibby: That sounds like what i've been hearing?
-
myles
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
-
myles
Topic: [css-values-4] Ratio of `0/0`?
-
-
myles
-
-
myles
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.
-
myles
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.
-
myles
TabAtkins: So 0/0 should preserve the concept of an earlier meeting: a/b should be the same as calc(a/b).
-
myles
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.
-
myles
TabAtkins: So calc(0/0) is already defined, so just writing 0/0 should act the same.
-
TabAtkins
aspect-ratio: calc(0/0) i salready well-defined (and same as aspect-ratio: 1 / 0)
-
myles
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.
-
fremy
honestly, why not
-
tantek
technically 0/0 is an "indeterminate form"
en.wikipedia.org/wiki/Indeterminate_form
-
myles
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.
-
myles
TabAtkins: Yes, 0/0 is definitely indefinite, but we censure (sensure? sensor?) it to infinity
-
tantek
did we consider animation implications here and is this the desired result? are aspect-ratio denominators animatable?
-
fantasai
censor, I think
-
myles
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.
-
» fantasai tantek, if you have a question pls add yourself to the queue
-
myles
florian: Calc(0/0) can't turn into a keyword because it can be used in different properties
-
myles
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.
-
myles
leaverou: If you animate 0/0 -> 0 / positive, you'll get disconuity.
-
myles
TabAtkins: Don't do that.
-
myles
TabAtkins: All the answers are arbitrary.
-
myles
TabAtkins: We just pick one.
-
dbaron
is it animated linearly or as the logarithm? Using the logarithm seems like it would give more consistent behavior between dimensions...
-
myles
heycam: Are there other properties other than aspect-ratio that takes a ratio? Aspect-ratio does discrete animation.
-
myles
TabAtkins: I have an issue open about aspect-ratio animation. I propose that it works like division.
-
myles
TabAtkins: The only other place where ratio type is used is the MQ about aspect ratio.
-
» fantasai pokes cbiesinger
-
myles
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?
-
florian
I buy into TabAtkins 's logic
-
myles
fantasai: The people who raised concerns were AmeliaBR and cbiesinger
-
tantek
I'm ok with TabAtkins logic though I'm going to s/indefinite/indeterminate per Wikipedia citation.
-
myles
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.
-
myles
TabAtkins: If a top-level calculation ends up being NaN, the property would be invalid at computed value time. It's possible.
-
myles
oriol: mhm.
-
cbiesinger
q+
-
» Zakim sees cbiesinger on the speaker queue
-
myles
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.
-
myles
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.
-
myles
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
-
» tantek been a while since I've had to use L'Hôpital's rule
-
myles
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.
-
myles
cbiesinger: calc(0/0) is a parse error in Chrome right now.
-
myles
TabAtkins: We don't support dividing by zero yet (!!!)
-
myles
RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio: calc(0/0)
-
astearns
topic: break
-
-
dbaron
anyway, since it was a side comment, I mentioned my interpolation point at
w3c/csswg-drafts #4953#issuecomment-712469770
-
» github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
-
» TabAtkins tantek, luckily no `derive()` function in css yet
-
» TabAtkins YET
-
» fantasai notes there's no issue open on aspect-ratio animation
-
dbaron
is 'aspect-ratio' not a <ratio>?
-
» cbiesinger wonders if there's a use case for animating aspect ratio
-
cbiesinger
dbaron: it's auto || <ratio>
-
» dbaron isn't sure where the spec for 'aspect-ratio' is
-
TabAtkins
Ah, dbaron, thanks for the comment there.
-
cbiesinger
-
cbiesinger
dbaron: ^
-
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
-
cbiesinger
yeah... anyone have contacts at a search engine?
-
TabAtkins
dbaron: Remember that
drafts.csswg.org/indexes can locate any CSS property for you.
-
dbaron
TabAtkins (IRC): that points to mediaqueries
-
TabAtkins
ahaha nice
-
TabAtkins
Oh maybe Sizing 4 isn't in the list of specs to look at yet!
-
TabAtkins
('grid', for example, clearly handles both property and descriptor forms)
-
» dbaron is unlikely to be around for the remainder of the call
-
jcraig
present+ James_Craig
-
TabAtkins
Ah yeah, Sizing 4 is currently marked as an ignorable spec in Bikeshed's defaults. fantasai, sound good to remove that?
-
TabAtkins
It'll mean links start going to 4 rather than 3 in other specs
-
» jcraig assumes the meeting is on break but secretly wonders if audio is not working. heh.
-
fantasai
Links should go to 3, not 4
-
fantasai
But if something's only in 4, then link to 4...
-
fantasai
idk if you can do that, but that's kinda where we're at
-
fantasai
Sizing 4 is an unstable diff spec, not really a good reference
-
» cbiesinger dbaron, I did report the poor search results internally
-
TabAtkins
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
-
» miriam in my head: "0/0 looks like a very small square to me. Can we spec that? Square, but very small?"
-
TabAtkins
ScribeNick: TabAtkins
-
TabAtkins
Topic: MQ serialization
-
astearns
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5627 ([cssom] [mediaqueries] Media query serialization doesn't work for newer spec features).
-
» myles miriam++
-
» fantasai miriam++
-
TabAtkins
astearns: Proposed resolution is to drop the CSSOM-specified sorting of MQs in lexicogrpahic order when serializing
-
fantasai
TabAtkins: No objection, but one example shows removing duplicates as well
-
fantasai
TabAtkins: Should also make sure that is covered as well
-
TabAtkins
astearns: Consensus in the issue, looks like
-
TabAtkins
emilio: Don't think Gecko has ever sorted, and we don't seem to have an issue
-
TabAtkins
astearns: Did you dedup?
-
TabAtkins
emilio: Don't think so; maybe as part of MQList apis, but not serialization. will doule-check
-
TabAtkins
astearns: So any objections?
-
TabAtkins
RESOLVED: Do not sort or dedup MQs when serializing
-
TabAtkins
Topic: forced-colors and prefers-contrast
-
-
TabAtkins
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5433 ([mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced`).
-
TabAtkins
Morgan: We've been implementing prefers-contrast and forced-colors in Moz for a while
-
TabAtkins
Morgan: Hoping to unpref adn ship soon
-
TabAtkins
Morgan: Hesitant until this issue is resolved
-
TabAtkins
Morgan: Don't have an opinion on the stances taken here
-
TabAtkins
florian: Attempted summary of where we are
-
TabAtkins
florian: We have two related things here
-
TabAtkins
florian: prefers-contrast MQ, which is about letting the author know whether the user prefers higher or lower contrast on the page
-
TabAtkins
florian: So author can change colors, add/remove borders, etc
-
TabAtkins
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
-
TabAtkins
florian: But general rule is that, regardless, removing visual clutter is often a good thing
-
TabAtkins
florian: A related thing was added to css, forced-colors mode
-
TabAtkins
florian: Not a user pref, it changes colors for the author automatically
-
TabAtkins
florian: When responding to forced-colors, it can be useful for an author to do the same contrast adjustments, reducing clutter and such
-
TabAtkins
florian: So we ahve a (prefers-contrast: forced-colors) value to indicate this
-
» fantasai q+
-
» Zakim sees cbiesinger, fantasai on the speaker queue
-
TabAtkins
florian: So my feeling is that they're theoretically distinct, but in practice they're close together and can be addressed in similar ways
-
cbiesinger
q-
-
» Zakim sees fantasai on the speaker queue
-
fantasai
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.
-
TabAtkins
florian: So right now we ahve both the (forced-colors) MQ as well, for legacy reasons
-
TabAtkins
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
-
TabAtkins
jcraig: We also have prefers-reduced-transparency; I mention because we use it more to indicate reducing clutter
-
TabAtkins
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
-
TabAtkins
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
-
TabAtkins
jcraig: Also reached out to aboxhall
-
TabAtkins
jcraig: She shared this:
-
jcraig
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)
-
TabAtkins
jcraig: So she doesn't have a strong opinion, but tends to agree that (forced-colors) is better
-
TabAtkins
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.
-
» cbiesinger I will have to leave for the rest of the meeting, see yall tomorrow
-
Morgan
q+
-
» Zakim sees fantasai, Morgan on the speaker queue
-
TabAtkins
jcraig: But I have opposite opinion from Florian for the author experience
-
TabAtkins
jcraig: I think the convenience of being able to just write (prefers-contrast) doesn't outweight the clarity gained from writing (forced-colors)
-
astearns
ack fantasai
-
» Zakim sees Morgan on the speaker queue
-
TabAtkins
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.
-
TabAtkins
fantasai: Doesn't necessarily force a high contrast, but it does force a *fixed* contrast
-
TabAtkins
fantasai: So not unreasonable for it to fall under the (prefers-contrast) MQ
-
TabAtkins
fantasai: I have a side question on (prefers-reduced-transparency)
-
TabAtkins
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?
-
TabAtkins
fantasai: bc if it's actually about visual clutter, that's not stated by the name
-
jcraig
q?
-
» Zakim sees Morgan on the speaker queue
-
TabAtkins
fantasai: Also, prefers-contrast *will* be true in the majority of cases where Windows High Contrast will be on
-
jcraig
q+ to respond to Elika's q re background pattern versus transparency
-
» Zakim sees Morgan, jcraig on the speaker queue
-
TabAtkins
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.
-
TabAtkins
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
-
TabAtkins
fantasai: And in general, both (prefers-contrast) and (prefers-color-scheme) do reflect the choices made by Forced Colors mode
-
TabAtkins
Morgan: Turns out I have an opinion
-
astearns
ack Morgan
-
» Zakim sees jcraig on the speaker queue
-
TabAtkins
Morgan: I added some info to the issue just a bit ago
-
TabAtkins
Morgan: Firefox has a high-contrast mode built in, that's not OS-specific
-
TabAtkins
Morgan: It triggers True when Windows High Contrast, or the browser-local HCM, is on
-
TabAtkins
Morgan: So far we've found people using it for both high and low contrast reasons
-
TabAtkins
Morgan: But also for things like photosensitivity
-
jcraig
What does Firefox HCM "regardless of browser" mean?
-
TabAtkins
Morgan: Those don't necessarily fall into high or low contrast bins
-
fantasai
jcraig, suspect she meant "regardless of OS"
-
TabAtkins
Morgan: So I agree with fantasai's concerns that they might not have their prefs reflected by authors
-
TabAtkins
Morgan: Also, we find that devs often dont' have the ability to test with high contrast themes.
-
astearns
ack jcraig
-
Zakim
jcraig, you wanted to respond to Elika's q re background pattern versus transparency
-
» Zakim sees no one on the speaker queue
-
TabAtkins
Morgan: So if our local HCM doesn't trigger this query, they dont' have a way to test
-
florian
q+
-
» Zakim sees florian on the speaker queue
-
TabAtkins
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
-
» fantasai q+ to re-explain her point
-
» Zakim sees florian, fantasai on the speaker queue
-
Morgan
jcraig, sorry yeah regardless of OS :)
-
TabAtkins
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
-
TabAtkins
jcraig: There's often overlap, but the clarity from breaking them into separate settings is worth preserving, I think
-
TabAtkins
jcraig: With the patterned background - in iOS we have a lot of transparency, but not a lot of loud backgrounds
-
TabAtkins
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
-
plinss
present+
-
astearns
ack fantasai
-
Zakim
fantasai, you wanted to re-explain her point
-
» Zakim sees florian on the speaker queue
-
TabAtkins
fantasai: So james had one point about "this is not a preference, so why is it in a MQ about preference)
-
TabAtkins
fantasai: So it's *already* going to trigger that *in most cases* - Forced Colors mode will *usually* trigger (prefers-contrast) and (prefers-color-scheme)
-
TabAtkins
fantasai: And an author will thus usually see those turned on when they test in forced colors mode
-
TabAtkins
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
-
TabAtkins
fantasai: So it's easy to leave out a class of users by accident
-
TabAtkins
q+
-
» Zakim sees florian, TabAtkins on the speaker queue
-
jcraig
I don't agree that "most prefers-contrast users" will have forced colors on... iOS "increase contrast" doesn't force colors.
-
TabAtkins
fantasai: So I think that's another reason why having forced colors *explicitly* fall under prefers-contrast helps out
-
TabAtkins
jcraig: I think elika said taht most prefers-contrast people will ahve forced colors...
-
Morgan
q+
-
» Zakim sees florian, TabAtkins, Morgan on the speaker queue
-
TabAtkins
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
-
TabAtkins
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
-
TabAtkins
florian: So adding the 'forced' keyword in makes sure they trigger at all times
-
TabAtkins
jcraig: So as an author, I'm not sure whether to check for (prefers-high-contrast: high) or (prefers-high-contrast: forced)
-
TabAtkins
jcraig: And then it's just weird still to have another setting to the exact same thing
-
jcraig
q?
-
» Zakim sees florian, TabAtkins, Morgan on the speaker queue
-
astearns
ack florian
-
» Zakim sees TabAtkins, Morgan on the speaker queue
-
TabAtkins
florian: Both in terms of transparency and patterns and this argument, I think there's a general tension between a11y features here
-
TabAtkins
florian: On the user side, general desire to express complex needs, because users have many needs and preferences
-
jcraig
s/(prefers-high-contrast: high) or (prefers-high-contrast: forced)/(prefers-contrast: more) or (prefers-contrast: forced)/
-
TabAtkins
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.
-
TabAtkins
florian: So trade-off of perfect responses (that ar eless likely) vs okay responses (that are more common)
-
TabAtkins
florian: I think the current design is about right for this reason, but we can disagree on the limit
-
astearns
ack TabAtkins
-
» Zakim sees Morgan on the speaker queue
-
astearns
ack Morgan
-
» Zakim sees no one on the speaker queue
-
fantasai
TabAtkins: Florian made the exact point I was going to
-
TabAtkins
Morgan: Last time this discussed, no definition of "more" or "less" ratios
-
jcraig
more than default, less than default
-
TabAtkins
Morgan: Saw this as a sliding scale of more and less as higher and lower ratios defined by user agent
-
fantasai
s/ar eless/are less/
-
TabAtkins
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
-
TabAtkins
jcraig: Responding to florian's, I agree we ahve a decision to make about granularity
-
TabAtkins
jcraig: My opinion is that it should be towards granular side.
-
TabAtkins
q+
-
» Zakim sees TabAtkins on the speaker queue
-
TabAtkins
florian: The people who ask for it know what they want, but if too granular, they just wont' get what they want often
-
TabAtkins
jcraig: How i understand windows hcm right now, it'll match both 'forced' and either 'more' or 'less' if appropriate
-
TabAtkins
jcraig: I think it's quite reasoanble to match 'more' if HCM is on
-
TabAtkins
jcraig: is on with a high-contrast scheme
-
TabAtkins
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
-
TabAtkins
jcraig: You're talking about a boolean match for contrast that is high, or low, or in the middle.
-
emilio
q+
-
» Zakim sees TabAtkins, emilio on the speaker queue
-
emilio
ack TabAtkins
-
» Zakim sees emilio on the speaker queue
-
fantasai
TabAtkins: wrt granularity choice, directly related to what you were saying
-
fantasai
TabAtkins: our current proposal has that granularity
-
fantasai
TabAtkins: You can target high contrast, low contrast, and forced contrast specifically and independently
-
fantasai
TabAtkins: But something you are likely to want to do for all of them is to simplify the page
-
fantasai
TabAtkins: If this is indeed the case, then we should have something that catches everything simply
-
fantasai
TabAtkins: And certainly should be something that catches the more common and less common cases the same way
-
fantasai
TabAtkins: I would rather authors have an general switch, rather than needing to list each thing independently
-
fantasai
TabAtkins: If your argument is that there is no reasonable thing to do that applies to all these contrast modes
-
fantasai
TabAtkins: then we don't need it
-
jcraig
Loss audio in the middle of Tab's comment
-
fantasai
TabAtkins: but if there is, then we need a good syntax for doing so
-
» fantasai hopes she caught everything, kinda quiet so filling in the gaps...
-
fantasai
jcraig: if ... about syntax, then happy to take it to a vote
-
fantasai
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
-
fantasai
astearns: Any input from ppl not yet part of the conversation?
-
» fantasai q?
-
» Zakim sees emilio on the speaker queue
-
astearns
ack emilio
-
» Zakim sees no one on the speaker queue
-
TabAtkins
Going for a more general "prefers-simple" MQ doesn't sound unreasonable...
-
fantasai
emilio: Conversation was we cannot remove 'forced-colors: active'
-
TabAtkins
emilio: Convo started with "we can't remove (forced-colors)
-
fantasai
emilio: I don't see 'prefers-contrast: forced' adding a lot of value
-
TabAtkins
emilio: I dont' see (prefers-contrast: forced) having a lot of value here
-
TabAtkins
emilio: prefers-contrast and forced-colors are technically unrealted and they should be separate MQs
-
TabAtkins
florian: On the one hand, I don't think this is a breaking point; I'd be willing to yield if necessary.
-
TabAtkins
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
-
TabAtkins
florian: I don't think we're wrong that the syntax is convenient, but are we wrong about the use-case?
-
TabAtkins
astearns: Is the user-case enabled by (forced-colors)?
-
TabAtkins
florian: No, it's not about responding to forced colors specifically.
-
jcraig
q+
-
» Zakim sees jcraig on the speaker queue
-
TabAtkins
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.
-
TabAtkins
florian: The way they'd write that code is with the common code in (prefers-contrast), then specific ones in (prefers-contrast: more)/etc
-
jcraig
(prefers-contrast) versus (prefers-contrast or forced-colors)
-
TabAtkins
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?
-
TabAtkins
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
-
TabAtkins
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.
-
fremy
FWIW I agree with @fantasai's latest comment; authors will not expect the block to turn off
-
emilio
q+
-
» Zakim sees jcraig, emilio on the speaker queue
-
TabAtkins
fantasai: So having pages fall into codepaths that aren't tested is a great way to have a broken page
-
» myles isn't it time to end?
-
astearns
ack jcraig
-
» Zakim sees emilio on the speaker queue
-
» astearns yep
-
TabAtkins
jcraig: I see the point, and the mild syntax convenience
-
astearns
zakim, close queue
-
Zakim
ok, astearns, the speaker queue is closed
-
TabAtkins
jcraig: Potentially could match something that might provide a convenience in the interface to an author that wants to reduce complexity.
-
TabAtkins
jcraig: If we assume that authors will know that and respond to it.
-
TabAtkins
jcraig: But I think the risk is that authors will conflate different things
-
TabAtkins
jcraig: Recent years, authors conflate small viewport widths to mean it's on mobile
-
TabAtkins
jcraig: Or check the user agent and see iOS and assume it's a phone and not an iPad
-
TabAtkins
jcraig: Apple had to do a lot of work to make sure iPads get desktop sites, for example
-
fantasai
The reason authors are conflating those things is because they had no other way to detect the things they were interested in
-
TabAtkins
jcraig: So even tho these are somewhat conflated, risk of conflating them
-
fantasai
e.g. knowing you're on a touchpad is important consideration in design, but there was no ability to query that directly
-
fantasai
so authors made a lot of assumptions
-
TabAtkins
emilio: I get fantasai's point, but we can solve it without ahving to expose the 'forced' value
-
fantasai
We don't have that problem here because we already have the individual options available to query
-
jcraig
s/somewhat conflated/somewhat related/
-
TabAtkins
emilio: You can just say if you're forcing colors you *must* match high or low
-
TabAtkins
emilio: When forcing colors you most can't override system colors
-
» TabAtkins dunno what that last statement means
-
TabAtkins
emilio: I think having two MQs mean the same thing isn't amazing either
-
» fantasai yeah, so we deprecate the old one and move to the new one
-
» fantasai it's new enough we can do that effectively
-
astearns
topic: end
-
-
emilio
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
-
fantasai
emilio, yeah, it's possible
-
fantasai
problem is that (prefers-colors) will match almost all but not all users of forced-colors
-
emilio
fantasai: having media queries that have different keywords like `(prefers-contrast)` is a bit confusing I suspect, and I'd avoid it, though...
-
jcraig
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"
-
emilio
Right
-
fantasai
s/fantasia/fantasai/
-
» jcraig sorry, autocorrect I guess
-
» fantasai np
-
astearns
zakim, end meeting
-
Zakim
As of this point the attendees have been emilio, alisonmaher, Rossen_, miriam, fremy, rego, plh, astearns, oriol, lajava, heycam, dlibby, faceless, cbiesinger, TabAtkins, TYLin,
-
Zakim
... Morgan, fantasai, tantek, myles, Guest, GameMaker, jensimmons, bkardell_, brandonferrua, hober, chris, drousso, leaverou, dbaron, (intermittently), James_Craig, plinss
-
Zakim
RRSAgent, please draft minutes
-
RRSAgent
I have made the request to generate
w3.org/2020/10/19-css-minutes.html Zakim
-
Zakim
I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
-
emilio
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...
-
emilio
fantasai: all this discussion reminds me of the `(prefers-color-scheme)` discussion fwiw
-
fantasai
emilio, I don't think you want to trigger high/low in middling cases
-
emilio
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...
-
emilio
fantasai: but anyhow fair
-
fantasai
that's not true, emilio
-
fantasai
images aren't affeted
-
fantasai
affected
-
fantasai
you can use any colors you want in an image
-
emilio
fantasai: true, that
-
fantasai
or in a `forced-color-adjust: none` subtree
-
emilio
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
-
fantasai
That would be really confusing :)
-
emilio
fantasai: right
-
fantasai
It has to match one of the keywords to match the boolean
-
fantasai
forced colors was invented for people who wanted a particular contast preference
-
TabAtkins
yeah, the current model requires *some* value to match, and I don't think it's worthwhile to break that
-
emilio
I mean, my preference is to not have forced and not match the boolean in middling color schemes, just keeping them separated
-
TabAtkins
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"
-
emilio
I guess lacking that fantasai / florian's alternative is the best. I'm not convinced that `forced` provides a lot of value
-
emilio
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
-
emilio
But I guess for that WebKit / Blink would need to implement `or` in media queries ;)
-
fantasai
oooh, snap