- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 May 2020 19:10:02 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Media Queries
-------------
- RESOLVED: Deprecate 'speech' and have it have the same behavior as
other deprecated MQs (Issue #1751: Deprecate 'speech'
media type as well?)
- RESOLVED: Put dynamic-range and video-* in MQ L5 (Issue #5042:
Which levels should the dynamic-range and video-* media
features be in)
- RESOLVED: Remove the no-preference value (Issue #3857: UA guidance
on light vs no-preference)
- RESOLVED: Add a note that no-preference used to exist but was
removed due to lack of implementations (Issue #3857)
Pseudo Elements
---------------
- Exposing the browser styling for selection/inactive-selection
(Issue #4579) requires first defining what the browsers are
doing. On the call there was exploration of Firefox's behavior.
More details of testing as well as webkit behavior information
will be added to github in order to further discussion.
CSS Positioning
---------------
- RESOLVED: Close issue #5005 (Physical inset properties), add a
note to the spec trying to explain the confusion
Ruby
----
- RESOLVED: Make the proposed change to make processing of ruby only
work on in-flow content (Issue #4958: siblings/children
vs in-flow siblings/children in box fixup)
CSS Multicol
------------
- In order to address image support for column rules in multicol
(Issue #5080) there needs to be a solution for all layout modes
so that the solution doesn't block any use cases. Discussion on
a design will continue on github.
Color Adjust
------------
- RESOLVED: Remove 'only' keyword, simplify the table, add a note
about dropping only (Issue #3881: Limits on the `only`
color scheme keyword)
CSS Text
--------
- RESOLVED: Remove at-risk label on 'anywhere' value of line-break
(Issue #5072: The 'anywhere' value of line-break)
- RESOLVED: Close no change (Issue #4993: Should enclosed counting
rods / tai xuan jing / yi jing hexagrams be
space-discarding?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020May/0026.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Dael Jackson
Sanket Joshi
Brian Kardell
Peter Linss
Myles Maxfield
Alison Maher
Florian Rivoal
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Rossen Atanassov
David Baron
Tantek Çelik
Chris Harrelson
Daniel Holbert
Adam Jolicoeur
Stanton Marcum
Nigel Megitt
Scribe: dael
Media Queries
=============
Deprecate 'speech' media type as well?
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1751
astearns: We wanted to wait for input. Seems fine. Proposed
resolution is deprecate speech
fantasai: I think it shouldn't always return false
florian: Opposite of every other deprecated thing
fantasai: Deprecated doesn't mean things stop working
florian: In MQ all deprecated media types are defined as you should
parse and defined to never match. It's what deprecation
means in that spec
TabAtkins: If someone in the future says we want speech we can
undeprecate. Until then no false promises about doing
this. It should be false forever
fantasai: I don't see why we wouldn't just leave definition, say
it's deprecated. Who says author would come to WG if they
wanted to do speech in the future?
florian: If we leave a definition we'll continue to have the problem
that people think it applies to screen readers
fantasai: Don't see why having it return false changes that
florian: Because we remove definition. No definition except it
doesn't match
TabAtkins: Which matches behavior of every user agent
astearns: I suggest we resolve to deprecate 'speech' and have it
same behavior as other deprecated MQs
<fremy> +1
astearns: Resolve on that unless you object fantasai and if you
think it's worth a separate issue you can raise it.
astearns: Objections?
RESOLVED: Deprecate 'speech' and have it have the same behavior as
other deprecated MQs
Which levels should the dynamic-range and video-* media features be in
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5042
florian: Given the other open issues the video things it's a strong
signal these are not CR ready
fantasai: Yeah, definitely L5
astearns: Proposal: put dynamic-range and video-* in MQ L5
astearns: Objections?
RESOLVED: Put dynamic-range and video-* in MQ L5
florian: We're close to ready for a republish CR of MQ4. If anyone
doesn't agree it's a good time to look. Once I'm done
reviewing I'll request one
UA guidance on light vs no-preference
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-631126143
TabAtkins: Discussed at a F2F a bit ago with no conclusion. Since
UAs have firmed up their behavior. Every UA I have access
to...I don't have iOS but was told they only have light
and dark...Android is light dark and so is windows. No
one maps to no-preference.
TabAtkins: Rather than define it we should drop it and acknowledge
authors should test light and dark. Right now it gives a
false impression and we can re-introduce later if there's
a third value
florian: Sad but agree
<jensimmons> +1 to all of that.... well stated TabAtkins — the sense
of the current state of reality
AmeliaBR: Syntax thing. Defined open ended syntax so if there's
author code that says prefers dark or no-preference that
would parse, correct?
TabAtkins: Yes parse and be true. no-preference is unknown and
unknown or true is true
fremy: Windows has light, dark, custom
TabAtkins: Windows custom is defined based on light or dark and
matches light or dark MQ.
fremy: In your impl. Windows has 3 values and you're saying we don't
match it so we don't care
TabAtkins: I didn't test FF on windows. I'd be surprised if they do
tri-state
astearns: Custom isn't the same as no-preference
fremy: Custom is the default. Light is not the same. Custom means
some dark some light. Default on windows is custom. Light
theme is different.
florian: This is what TabAtkins strongly expressed a preference for,
but given no UA is doing that that's why we're moving away.
If a UA wants that it would be interesting
AmeliaBR: Coming to the browsers it's one thing if OS allows
light|dark|default that's the model we wanted. But if
browsers don't expose it to webpages we shouldn't say they
do in the spec
fremy: That's called a bug. I don't see point of removing a feature
that's used on most used platform
florian: But if it's not in all browsers on that platform it doesn't
exist in the web
TabAtkins: Yeah, it doesn't exist on those browsers
fantasai: We've had a number of discussions and all browser vendors
are aware of no-preference. They're clearly choosing not
to do it. I don't agree that's right, but that's what
they're doing
fremy: I won't object but this makes no sense. It's saying we the
browser doesn't want to represent all values because we don't
care
myles: I agree with TabAtkins formulation that there's a long
history of modifying CSS spec to match reality
astearns: Proposal: Remove the no-preference value
AmeliaBR: Question: where are we in publication and is it reasonable
to add it as at-risk and give it a timeline? Or have we
done that?
astearns: Given it's been under discussion for a long time and no
indication from any implementor they're considering it's
right to remove
fremy: Is anyone from MS in this discussion?
alisonmaher: I'm from MS
fremy: If someone from MS is okay I don't care. If you're fine it's
good.
alisonmaher: I worked on forced colors in blink and we were doing
no-preference for forced colors mode
jensimmons: We're not debating on best for authors, but I feel
simpler is better. Since the long conversation at F2F
I've seen little interest from authors about doing
anything for dark mode. I think we're choosing on
reality but this is better
fantasai: On interpolate forced-colors spec requires mapping to
light|dark|no-preference: It shouldn't be mapping to
no-preference when the chosen colors are clearly light or
dark. But what do we map to if you're middle gray?
astearns: We will be talking about color adjust later in the meeting
if we get to it.
AmeliaBR: Issue from fantasai isn't about color-adjust. Browsers
asked to take forced-color and determine if it's light,
dark, or in-between.
AmeliaBR: If it's in-between like blue on red is that light or dark
mode? How does that calculation work
TabAtkins: I presume we spec browsers should lean toward light. Even
if we thought value of no-preference for this case I
still wouldn't support keeping because it's not tested.
Sounds like a recipe for bugs rather than help user.
astearns: alisonmaher would you be okay resolving to remove or would
you rather a week to talk to colleagues.
alisonmaher: I think it's okay to resolve and then open a new issue
if it comes back.
astearns: Proposal: Remove the no-preference value
astearns: Sounds like mostly agree we should do it even if we don't
want to
RESOLVED: Remove the no-preference value
fantasai: I think put a note in the spec that there was a value and
removed because no implementation
TabAtkins: Good with that
fantasai: And if someone wants to implement we're happy to add it
back
astearns: Come talk to us about it!
astearns: Objections?
RESOLVED: Add a note that no-preference used to exist but was
removed due to lack of implementations
CSS Pseudo Elements
====================
::selection vs ::inactive-selection
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4579
fantasai: Looked like going to use pseudo class combo but I didn't
have anything to move forward with what it would be. Some
comments on window for active but selection can be
inactive when window is active. I'm not sure all behaviors
intended or if we can do it all. I need help figuring it
out. Does anyone have enough familiarity to know where we
need the switch?
AmeliaBR: Browsers must have this code because they have default
highlight styles. I guess it's a question to dig into code
bases and look for consistency we can build on
emilio: Somewhat familiar with Gecko. Inactive selections in active
window are just not rendered. An input can have
selection-start and -end but if you select outside we don't
render selection on input
fantasai: Selected but invisible?
emilio: Yes
florian: Feels like different things
fantasai: Than it is selected, right? Maybe that's another state.
It's selected and selection has default background
emilio: Opposite. Two states, window-active and -inactive. I think
confusing to users if you allow display selection of
something they can't edit because it's not focusable
emilio: afaict in FF there's active and inactive selection and
that's it. Inactive matches the inactive window
fantasai: Active selection in active window, selection in inactive
window, invisible selection?
emilio: Active selection in do that's main or not and that's only
when they are active and rendered.
fantasai: I'm playing with it so I can see it.
fantasai: Question on what other browsers do.
fantasai: Also, can you from the DOM tell if content in the
invisible input selection is selected?
emilio: I think so from DOM APIs. Only want to access is
selection-start and -end. This is from memory
florian: Actually selected? If you copy do you copy from it?
emilio: Only from active section of active window
florian: Feels like it could not be a selection
emilio: If you programmatically focus you should it
florian: It's a memory of where selection would be created if you
focus the element
florian: If you do operations it acts on that selection?
emilio: I don't think so
fantasai: florian's concept makes sense but how is it in the DOM?
There's active, inactive, and remembered selection.
emilio: Also things like defining page 1 which is different states.
Don't know if we want to expose to authors
fantasai: Still need info on blink and webkit
AmeliaBR: Quick test. Chromium on windows is same as FF in that it
remembers selections in inputs but no style if move focus
away
AmeliaBR: One difference is if you have selection inside iframe and
tab away FF it's same as inactive window selection,
chromium no highlighting, same as regular input
AmeliaBR: Both have the style where inactive window gets different
style effect
AmeliaBR: If point is represent browser default in CSS having
inactive in combo with selection is sufficient. Can't
check webkit, but chromium and FF that's the main
requirement
fantasai: Good to hear from webkit. In terms of window active vs not
I think that's a MQ not pseudo class
astearns: Sounds like we need test cases to outline scenarios and
see if there's concordance between browsers and than
decide how we'll express
fantasai: Seems like we could replicate what we know of with active
window MQ and ::selection and need to know if works on
webkit.
smfr: I'll get webkit data for next week
fantasai: Okay
fantasai: Current state of proposal is we propose no active vs
inactive media query [missed] Any comment on that approach
assuming it checks out?
astearns: We'll leave this open. Keep on the agenda or wait on data?
fantasai: Wait on webkit
CSS Position
============
Physical inset properties
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/5005
TabAtkins: In position spec physical is top/left/bottom/right.
Logical inset properties names -start etc. incl inset
shorthand
TabAtkins: Jonathan Neal suggested corresponding names for physical
so they're under same inset prefix. Rejected because only
do aliases when original name is bad. Not the case here.
TabAtkins: Slightly bad that t/l/b/r are not unified, but they're
perfectly good names.
TabAtkins: I wanted to confirm with WG that rejection is okay
<oriol> +1
astearns: Seeing +1 from heycam and mostly +1 from miriam in issue
astearns: Proposal is close no change
miriam: I think there is a clear potential for confusion here, but I
don't know this is right solution. I don't have something
else in mind. Confusion I see is less that they're not all
unified and more that inset is a shorthand for something
different than it looks like a shorthand for
TabAtkins: I forgot, inset shorthand does set physically unless use
the logical keyword. True...I don't think we want
president of when both physical and logical if there's a
shorthand we default logical. Worth calling out in the
spec. Still think current definition is right for overall
consistency
fantasai: Needs to be consistent with margin
TabAtkins: Happy to add a call out for potential of confusion that
it by default sets physicals though can set logicals
miriam: Works for me.
astearns: Proposal: Add text to the spec trying to explain away the
confusion
TabAtkins: It'll be a notes
astearns: Nice to figure out some solution to this.
astearns: Objections to Close issue?
<miriam> +1 to further attempts
RESOLVED: Close issue, add a note to the spec trying to explain the
confusion
CSS Ruby
========
siblings/children vs in-flow siblings/children in box fixup
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4958
florian: Fixup step. Ruby has structure and needs right boxes.
florian: Steps written as if they're exhaustive. But they're not
because ignoring out of flow children of a ruby structure
florian: I think if something is abspos of ruby it isn't meant to be
fixedup. I think things out of flow are left as is. If
that's the intent it should say inflow children where it
says children. If intent is something else I need to know
what
fantasai: Ruby should only be in-flow stuff.
fantasai: Out of flow should be ignored to extent we can ignore it
florian: I've written text in issue, but it's adding inflow in
places where it's implied
fantasai: Let's add it
fantasai: We can move on unless there's anything else
astearns: Objections to make the proposed change to make processing
of ruby only work on in-flow content
RESOLVED: Make the proposed change to make processing of ruby only
work on in-flow content
CSS Multicol
============
Image support for column rules
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5080
fantasai: Need to figure out grid before we resolve it. Proposal is
in right direction, but need to figure out intersections
and how they fit together
astearns: Any opinions or ideas on how to work with grid?
AmeliaBR: Clarification- If someone wants to slice an image so
column rules and row rules have nice overlap. That is a
lot more complicated than proposal
AmeliaBR: Do we have general interest in proposal with details TBD?
fantasai: I think a fair amount of interest from authors. If
interest from implementors we should try and have it. But
since we haven't figured out intersections we shouldn't
add this. Shouldn't block into a place where we can't make
intersections work
fantasai: We should let discussion continue until we have proposal
for all layout modes with this kind of rules. We can than
subset but we should solve intersections and spanning
elements to the point where we know we can make it work
fantasai: Also don't think this is particularly urgent
rachelandrew: I don't hear lots of requests in multicol. Yes in
grid, particular wrt lines rather than images, but not
constantly asked for in multicol
astearns: Let's go back to github
Color Adjust
============
Limits on the `only` color scheme keyword
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3881#issuecomment-631115953
<TabAtkins> https://drafts.csswg.org/css-color-adjust/#color-scheme-prop
fantasai: Should we do color adjust when we've got Rossen?
astearns: This would be good to get to
TabAtkins: Now that we resolved to drop no-preference from color
scheme the table I linked to above to showcase
interaction gets simpler
TabAtkins: If we drop no-preference column than light and dark look
similar. Only difference is if the author says light and
user wants dark or other way neither gets what they want
and we use browser default. In all other cases author
preference wins.
TabAtkins: Since only cases are author wins or no one wins and we
get browser I think we should simplify and make it so
that if you say light or dark that's what you get. We
drop the only keyword as meaningful value
TabAtkins: Existing pages using only will continue to work exactly
as they have
<fremy> lgtm
TabAtkins: Drop the only keyword and make light or dark respect
author preference. If it's 'light dark' (allowing light
or dark, preference to light) it's user preference
TabAtkins: Objections?
emilio: Uneasy about overwriting user preference. Not really
objecting
TabAtkins: User preference if honored if author is okay with light
or dark. Existing preference wasn't respecting user
preference either, just author preference or going to
browser default.
astearns: Other concerns with this change?
astearns: I like simplification. It's something we could complicate
in future. At this point in time simplification makes
sense.
astearns: Proposal: Remove the 'only' keyword and simplify the table
in the spec
AmeliaBR: No objections. Same as with MQ a not mentioning the
dropped value would be useful if people try and look up
TabAtkins: Happy to do that
fantasai: Need text to parse
TabAtkins: Parses due to property extensibility. It's a dropped
unknown keyword
RESOLVED: Remove 'only' keyword, simplify the table, add a note
about dropping only
CSS Text
========
The 'anywhere' value of line-break
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5072
fantasai: Remove from at-risk, it seems to be implemented
astearns: Test cases?
florian: Yes, we do have them
florian: Are they of every possibility, maybe, but we definitely
have some
astearns: Objections to remove at-risk label on 'anywhere' value of
line-break
RESOLVED: remove at-risk label on 'anywhere' value of line-break
Should enclosed counting rods / tai xuan jing / yi jing hexagrams be
space-discarding?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4993#issuecomment-633723924
fantasai: Line breaks between these character categories are
dropped. Do we include these symbols in that set? Prop in
issue is no
fantasai: Reason is to keep hexagrams consistent with misc symbols
block. koji and I think this is good idea, checking with
WG. Proposal: close no change
astearns: Richard's opinion?
fantasai: Mentioned counting rods might be used in western context
so keeping space is better idea. That's in favor of no
change
astearns: Other comments?
astearns: Proposal: Close no change to current spec
<florian> +1
astearns: Anything clarifying?
fantasai: No, it's an explicit list of codepoints
RESOLVED: Close no change
astearns: Thanks everybody for calling in, we'll talk next week
Received on Wednesday, 27 May 2020 23:10:53 UTC