- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Apr 2019 19:48:38 -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: Leave inverted colors as is, add webkit UA stylesheet as
an example implementation for MQ L5 (close no change)
(Issue #3858)
- RESOLVED: Add inversion rule to the UA stylesheet (Issue #3858)
- The authors were asked to revisit and update the security and
privacy section for levels 4 and 5.
CSS Color
---------
- RESOLVED: Add the original list of colors from TabAtkins and
fantasai as well as ones by smfr and ActiveText (Issue
#3804) [List: Canvas, Text, LinkText, VisitedText,
Highlight, HighlightText, GrayText, ButtonFace,
ButtonText, ActiveText, Field, FieldText]
CSS Lists
---------
- There are use cases to support solving issue #3667 (Need a way to
return the max value of a counter within a scope). Google is
looking more to see if they're interested in implementation a
solution.
- RESOLVED: Publish new WD of Lists
- RESOLVED: Add fantasai as editor CSS Lists L3
CSSOM
-----
- The original use counter for issue #3814 (Figure out what to do
with non-standard CSSStyleSheet methods in WebKit / Blink) was
too high for the methods to be dropped, however the data will be
looked at more closely to ensure it's not erroneously high.
- RESOLVED: Non-initial custom properties should be exposed on
computed style objects, open a new issue about defining
order (Issue #1316)
CSS Images
----------
- The group was actioned to review and give feedback on the request
from WHATWG around lazyload (
https://github.com/w3c/csswg-drafts/issues/3659 )
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0017.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez (IRC Only)
Dave Cramer
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Chris Lilley
Anton Prowse
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Jen Simmons
Greg Whitworth
Regrets:
Alan Stearns
Scribe: dael
Media Queries
=============
Remove or expand inverted-colors
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3858
florian: I think the initial issue was raised because wording wasn't
clear. I've done an edit. It's supposed to trigger when
entire screen is flipped pixel by pixel. Author needs to
know to double invert images and the like.
florian: Because wording was ambiguous there were questions if it
triggered during a smart invert. Also expand to all things
like night mode.
florian: My take is don't change. Full invert MQ is useful because
there's a predictable way to react. A general 'your screen
has been filtered somehow' doesn't have a strong way to
respond so no use case. Having made the editorial
correction I think close no change
dbaron: Is spec clear on what inversion means in this context?
florian: Probably not. It's graphical operation that effects all
pixels. It's not clear if it's different for every pixel
dbaron: And if you want to correct images you need to know what
inversion operation to do
florian: Good point, should clarify. I don't know if there's
multiple ways done in practice
TabAtkins: 2 ways. Safari does fancy that doesn't invert images
florian: Not that one. It's within the non-smart is there a hue
rotate, inversion around gray point?
TabAtkins: I think math is the same between everybody.
florian: Smart one doesn't match this. This is all the pixels have
been flipped. If it's smart we don't need to react so don't
need MQ
TabAtkins: Disagree with this. There are multiple mitigations for
the page. Some apply across several different types of
inversion. If you do smart inversion page wants to still
remove shadows. Having images not be inverted but the
rest does means the pages with smart will not have their
shadows with fixed
florian: But if we conflate the 2 you get the wrong answer for a
system
TabAtkins: Yes. Given that inversion exists to flip light vs dark
mode of the page and we have light/dark mode happening
maybe we can assume inversion will decrease in use and
drop the MQ.
florian: I suspect smart version usage will fade to dark/light mode.
Does that apply to dumb which is easier for OSs? Those
trying to be smart will be smart
TabAtkins: Android has every single pixel inverts mode
florian: OSX has that
TabAtkins: These MQ are for when an author should apply mitigations.
Either design around mitigations themselves or don't do
it at all. Doing around a feature that has multiple
mitigations isn't a good design for the future
TabAtkins: I propose that invert colors as current defined is not
good because limits to every px inverted. We should
either drop it completely and assume it's a corner case
due to new functionality or we make it more complex and
break it down by mitigations authors would apply
florian: Please invert images, please remove shadows?
TabAtkins: Yes
fantasai: It's a bit overkill
TabAtkins: Agree. Removing is better
fantasai: Design where you don't know what you're responding to
doesn't have purpose. Current definition that you've
inverted entire screen has usefulness. It's nice that
we're moving toward place that people recognize that
inversion is to handle dark mode and they're doing smarter
inversion is good.
fantasai: As long as full screen inversion does exist and it seems
likely to continue to exist for a while...iOS isn't the
only browser. There are smaller devices that are doing
what they're doing. We'll have to deal with full screen
inversion for a while. MQ on that isn't unreasonable
Rossen: Windows supports inverted and it's used quite a bit. I
sympathize with TabAtkins that this one query that only
covers one case isn't sufficient. Might consider adding to
this so you can handle the smart invert iOS supports. I
didn't hear if there's anything on Android. But there's 2
cases that capture everything. Full inversion or smart which
is no image and control
TabAtkins: I expect we can get as far as we need by splitting into
2. Are images inverted and is everything else inverted?
MS would respond yes to both, Safari yes to 1. That's all
authors need to mitigate. Will images look weird and will
the rest of the page look weird. We should address those
two directly
AmeliaBR: When talking 2 MQ is it 2 keyword values for inverted
colors?
florian: I think it's 2 separate. Media features can be used without
an argument and if you have multi keyword it's muddled
AmeliaBR: Disagree. Some mitigations we want for both. Removing
shadows is if inverting colors is true for any keyword.
For keyword that specially indicates not images you can do
something specific for images
florian: Could, but easy to misuse.
AmeliaBR: Up to the spec to be more specific about what things mean
florian: I don't think can fix bad API design with good documentation
TabAtkins: Most usable as 2. You can do mitigations on images for on
MQ and color on the other.
florian: Existing stays as is and add one for inverted images?
fantasai: No, current is full screen inversion.
TabAtkins: Defined as that but can change definition
fantasai: Shipping now
<tantek> this is iOS 12.1 BTW
<tantek> Interesting, I just found the iOS setting in Settings >
General > Accessibility > Display Accommodations > Invert
Colors - then two mutex radio buttons: Smart Invert (* ),
Classic Invert (* )
TabAtkins: iOS would start matching inverted color. I think they do
now so no behavior change I believe. New query for
inverted images would match android and edge but not iOS
dbaron: I wanted to mention it's worth considering if users expect
this information to be exposed. Not clear to me that they do
or that a user choosing to use inversion would expect
webpages to know. It's additional information to fingerprint
and users might not want web pages to know about that.
<tantek> +1 to that
florian: Fair
fantasai: I think we opened that door with all the other preferences
like color-scheme and reduced-motion. Not sure this is a
big different in exposure
dbaron: Users are choosing or not to expose that information. They
can not expose if they prefer. I guess that's true here too.
But those seem more like a preference. I guess it's OS
level. It's just more bits of information
* fantasai would like to hear from smfr
AmeliaBR: To follow up dbaron point I agree with the general concern
about fingerprinting and this is a a11y functionality.
Less of a fingerprinting vector than others as it's
something people toggle on and off. Worth talking about.
Every MQ is a fingerprinting vector
AmeliaBR: It is exposed in iOS but it doesn't mean they looked into
what users want. Especially since benefit of this MQ we
can only come up with 2 rules that would make sense
AmeliaBR: I went on queue to say that when talking about the 2 MQ
option we have to start looking at that this has shipped
in one UA. I'd like someone who is familiar with iOS to
talk if they're on the call and how they impl smart
inversion and if they currently recognize in the MQ when
someone does a double inversion and if they're avoiding a
triple inversion. I was thinking smart inversion came
through CS mechanism
AmeliaBR: Through cascade it wouldn't hurt to have author rule, but
maybe incorrect if it's from OS level compositor. Before
we agree to 2 MQs lets talk to people using feature to see
if necessary.
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/3807#issuecomment-481868265
Comment from Dean about history of Apple's inversion
smfr: As far as I understand, iOS and I think Mac is when the user
toggles the a11y setting the entire screen is inverted and WK
applies a CSS filter to image elements and likely others. It's
possible an author could re-invert the images if they only
looked at inverted colors MQ. No smarts to avoid extra invert
florian: If you're using CSS it wouldn't be a double invert.
AmeliaBR: Would cascade cancel?
smfr: Maybe you're right. Not sure if it's CSS or programmatic. I
think you're right
florian: Should check.
tantek: Couple of things. First is I don't think we should use
reasoning door is open to justify adding something. Always a
false dichotomy. We do things on spectrum where it can be
better or worse.
<tantek> https://drafts.csswg.org/mediaqueries-4/#priv-sec
tantek: Looked at security and privacy of MQ draft and it's out of
date for reflecting how MQ can be used for fingerprinting.
Granularity of fingerprinting from MQ has greatly increased
since L3. Needs a callout
<fantasai> https://drafts.csswg.org/mediaqueries-5/ ?
tantek: If it's a CR and not a REC we should update. Since it's in
formating we should be able to edit during CR
<chris> +1 to updating the S&P section
tantek: Given potential negative aspects I would like to see some
actual use cases where feature is a strong benefit to an
author. What is the actual strong use case where an author
needs this today. Otherwise not sure it meets bar to include
it over potential drawbacks
TabAtkins: Inverting images is main thing. Images of real stuff like
people looks horrifying when inverted naively. Removing
shadows is good, but not necessary. If we can focus on if
images are inverted or not that's highest value
<smfr> WebKit UA stylesheet has:
@media (inverted-colors) {
img:not(picture>img), picture, video {
filter: invert(100%);
}
/* Images and videos double-inverted. */
}
Rossen: Sounds like smfr found the UA stylesheet that supports that
WK does this through CSS because author style sheet won't
double invert it
Rossen: I see florian on the queue. I want to try and close on this.
florian: Brief comment. To tantek on privacy and security the one in
L4 is outdated. This feature is in L5 which doesn't even
have a privacy and security so we need to create one.
tantek: L5 needs to exist, L4 needs updated because it's not
honestly reflective
Rossen: Back to topic at hand. We know what WK does. We know
inverted colors on both android and windows apply to full
screen. What do we do with this MQ. Leave as is? Bring
additional query that's excluding images or something?
florian: Include the bit of UA stylesheet WK has so if authors want
this they know exactly how so we don't fight with WK
<AmeliaBR> +1 to standardizing the UA rule
Rossen: You propose leave the feature definition as is and add
example of WK UA stylesheet of how they do inversions and
how can be used to mitigate.
AmeliaBR: I'd suggest most UAs impl
Rossen: It's up to UAs to do it or not
AmeliaBR: We can standardize UA stylesheet and important we do. WK
rule filters on picture elements, not images inside so if
someone filters all images you get a double inversion
<fantasai> +1 to AmeliaBR
AmeliaBR: Having a standard rule this is how you do it is more
reliable
<chris> +1 to AmeliaBR
<florian> +1
Rossen: Would that need to include SVG?
AmeliaBR: It wouldn't need to
Rossen: Proposal: Leave inverted colors as is, add webkit UA
stylesheet as an example implementation for MQ L5
Rossen: Additional comments or objections?
florian: I'm good with it as a normative addition to UA stylesheet
Rossen: 2 resolutions then
TabAtkins: If you're going to fix images automatically you must do
it via this CSS would be the second
Rossen: First is about the original issue which is no change to
invert colors MQ. Objections?
RESOLVED: Leave inverted colors as is, add webkit UA stylesheet as
an example implementation for MQ L5 (close no change)
Rossen: Second is Add inversion rule to the UA stylesheet.
Objections to that?
RESOLVED: Add inversion rule to the UA stylesheet
Rossen: Third is an ask to authors to revisit privacy and security
section for L4 and L5
CSS Color
=========
Support high-contrast/dark mode colors
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3804
TabAtkins: Working from the presentation of Rossen and
melanierichards. fantasai and I put together proposal for
high contrast stuff in CSS. Defining system colors, some
exist and some new, that map to categories from Rossen
and melanierichards
TabAtkins: Only addition is a visited link color in addition to
normal and that's because it's already in system colors.
MS could set to same color if they want.
TabAtkins: Idea being is we adapt MS rules for how to apply that
says you apply these system colors where ever necessary.
There's a MQ that says these are on and you may want to
adjust your styles.
fantasai: Resolved on that earlier, need to add the colors. Resolved
on the MQ and properties. This is about making changes to
CSS color L4 to un-deprecate a subset of the system colors
and add a couple of new ones
fantasai: New is page background, scrollbar, link text, visited link
text
dbaron: Active link text?
fantasai: Might need to add that, yes
<TabAtkins> Canvas* (we'd have liked to call this “Background” but
that's already used for something else)
<TabAtkins> Text*
<TabAtkins> LinkText*
<TabAtkins> VisitedText*
<TabAtkins> Highlight
<TabAtkins> HighlightText
<TabAtkins> GrayText (could be aliased to InactiveText or
DisabledText for clarity)
<TabAtkins> ButtonFace (could be aliased to Button for consistency)
<TabAtkins> ButtonText
AmeliaBR: Couple other suggestions in thread of colors used in UA
stylesheets. Some of which not named
fantasai: Discussion about adding field values for text inputs. I
don't have a strong opinion on that. Wanted to make sure
got minimum set MS was using in high contrast mode. If WG
wants to add field and field text can add
<TabAtkins> Looks like additional stuff is just "Field" and
"FieldText"
Rossen: High contrast PoV your set of colors maps to what's
required. I don't have strong pref for additional ones, I
don't know use cases. I guess people creating own components
and want closer to current system controls sounds reasonable.
<AmeliaBR> and ActiveLinkText
<fantasai> or ActiveText
Rossen: Want to hear from the rest of group
Rossen: Taking silence as supportive
Rossen: Proposal: un-deprecate or add the list above
fantasai: * is added
AmeliaBR: IRC discussion mentions the others
fantasai: ActiveLinkText and Input field background and foreground
color
fantasai: We pulled old names for those, don't know if they're
necessary. I think we at least need to minimum set for MS
high contrast. If people want to add others I'm fine
Rossen: Objections to add the original list of colors from TabAtkins
and fantasai as well as ones by smfr and ActiveLinkText
RESOLVED: Add the original list of colors from TabAtkins and
fantasai as well as ones by smfr and ActiveText
fantasai: On ActiveLinkText we have LinkText and VisitedText. We
went shorter version of names because match selector
Rossen: Shorter makes sense
AmeliaBR: There's already ActiveButtonText so that's only confusion
AmeliaBR: If it needs to be clear ActiveText is color for active
links
fantasai: Active button can be own thing
Rossen: Okay. Previous resolution stands
Rossen: Resolution is ActiveText not ActiveLinkText
Pseudo Elements
===============
Should CSSPseudoElement have a pseudo() method?
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3836
Rossen: heycam or emilio or anyone else want to cover this?
TabAtkins: Rather move on
CSS Lists
=========
Need a way to return the max value of a counter within a scope
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3667
fantasai: This was a feature request to add ability to retrieve
highest value a counter picked in a document for something
like numbering page 2 or 5. Functional notation like
counter. Asking WG if interested now, future, or never?
[silence]
<dbaron> I don't think I'm particularly interested...
Rossen: Not sure how to read the silence. Can we say never?
<tantek> [silence] seems like enough reason to postpone discussing,
maybe til f2f?
TabAtkins: Functionality exists in paged CSS via special pages
counter. Bit of a special case. Use case is clear there.
TabAtkins: Added to triage list so can get answer from engineers
soon, but no answer now. Personally in favor
dauwhe: Have use cases for this in paged media. See utility for long
publications
Rossen: Hearing some favorable comments and the need for it. It's
not never, but doesn't sound like we can resolve now. Let's
close, move one, and revisit when have more information from
impl.
Publication
-----------
fantasai: On topic of lists, css lists has been updated with a major
clean up and resolutions folded in
<fantasai> https://drafts.csswg.org/css-lists-3/
fantasai: If want to review can do this next week, but want to pub
new WD
Rossen: We can publish it. I don't know if anyone will come up with
reasons
RESOLVED: Publish new WD of Lists
CSSOM
=====
Figure out what to do with non-standard CSSStyleSheet methods in
WebKit / Blink
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3814
Rossen: Anyone to take this?
<emilio> Given the comments, I'll just spec them
<emilio> sorry, can't join via audio / video, on the phone
TabAtkins: Based on eric's numbers, unless someone can make argument
that our numbers aren't actual usage they're too high to
drop. .rules is almost a full percentage point of page
loads
TabAtkins: If not removing, should look to add. But emilio says no
one cares on their side. I don't know best thing, but
removing isn't in the cards for us
AmeliaBR: Clarification: implementation of these they're aliases for
standard features?
TabAtkins: There's one that's slightly different, but yes
dbaron: Will impl these in browsers that don't have them break
feature detection?
TabAtkins: Don't know. I just have use counter data, not information
on how they're actually used. But numbers of use is too
high
* emilio was hoping not, but that's a very good point
dbaron: Seems weird because I don't recall pages broken due to not
having them
TabAtkins: Feature detection- I didn't mean they're to tell you're
in blink but something that iterates over a bunch of
properties to see what exists. That's caused high use
counters in the past. That might be the case at which
point we might remove, but as of right now can't remove
Rossen: Other action if we don't remove? Add to CSSOM?
TabAtkins: Not right now. emilio asked if should or should remove
Rossen: Current data says cannot remove unless you want an action to
see if you can get deeper into data to figure out if it's
meaningful or triggering from auxiliary detection rules. Up
to you
TabAtkins: Put it for triage. I'll get back to you
Rossen: Reasonable.
Should custom properties be exposed on computed style declarations?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1316
Rossen: heycam added and then lively discussion. Who wants this?
TabAtkins: I can. I support it. If we allow interaction of custom
properties via OM we should expose what's non-initial.
Makes sense to make when you gCS from there. Technical
questions on the API, but can be resolved by emilio as he
feels fit.
TabAtkins: Should resolve non-initial custom prop should be exposed
on computed style objects
Rossen: Other opinions?
Rossen: Objections to non-initial custom properties should be
exposed on computed style objects
<emilio> There's an issue with ordering of properties
<emilio> Also, what happens with registered properties that have an
initial value
Rossen: emilio points out issue with ordering?
Rossen: Does that change opinion?
<emilio> Basically, order in WebKit is just hash ordering, Gecko is
cascade order. Defining alphabetic ordering or such may be
problematic (need to sort every indexed operation and such)
<emilio> Leaving ordering undefined might be ok
TabAtkins: I think it's still useful. Need to figure out the answer.
I'm confident emilio will put something good in the spec.
What's the order you all use?
Rossen: Gecko says cascade
Rossen: Order undefined would be a lot of contradictory behavior
Rossen: Resolve on adding and open issue on dealing with order?
TabAtkins: Okay
<emilio> Sgtm
Rossen: Support overall behavior. Technical order issue should be
separate.
Rossen: Prop: non-initial custom prop should be exposed on computed
style objects, open a new issue about defining order
RESOLVED: Non-initial custom properties should be exposed on
computed style objects, open a new issue about defining
order
CSS Images
==========
lazyload
--------
github: https://github.com/w3c/csswg-drafts/issues/3659
Rossen: Ask from WHATWG. fantasai you want to introduce?
fantasai: Mostly I wanted to call attention to the thread to make
sure we respond in a timely manner
Rossen: Action for everyone to read up and engage in github. I'll
add to agenda next week if not high response
Rossen: One minute left. Let's push the remaining topic to next week
CSS Lists
=========
fantasai: Can we add me as a List L3 editor?
Rossen: There's a spec you're not an editor of??????
Rossen: Objections to add fantasai as editor CSS Lists L3?
TabAtkins: No objections
RESOLVED: Add fantasai as editor CSS Lists L3
Rossen: Thanks and we'll chat next week
Received on Wednesday, 24 April 2019 23:49:35 UTC