- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Jul 2020 06:23:05 -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.
=========================================
CSS Images
----------
- RESOLVED: Make from-image's none value apply to background and any
other images (Issue #5245: Clarify which images
image-orientation applies to)
CSS Color
---------
- RESOLVED: Publish a version with all keywords but 'longer' (Issue
#4735: When mixing hue, there are two ways round the hue
range)
Form Controls
-------------
- There was wide interest in trying to specify a color for the
accent color of form controls (Issue #5187: Allow specifying the
"accent color" of a form control element) however there were
some concerns about if it's possible
- Specifying form controls is being looked at by several people
and this was a small step toward that which needs to be
compatible with larger efforts.
- Maintaining appropriate contrast may be hard if the accent
color is sometimes against background and sometimes against
foreground or text.
- The solution needed to work with all existing browser/OS
combinations and also support OSs that don't have accent
colors so it is important to do more research before
proceeding with moving into spec text.
CSS Sizing
----------
- RESOLVED: Accept proposal [
https://github.com/w3c/csswg-drafts/commit/9594b70729ff481ea933a3e3d07a85423122e0eb
]
(Issue #5151: Should aspect-ratio be used for abspos
`top: 0; bottom: 0;`?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0000.html
Present:
Rossen Atanassov
David Baron
Christian Biesinger
Mike Bremford
Tantek Çelik
Elika Etemad
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Dean Jackson
Brian Kardell
Chris Lilley
Peter Linss
Alison Maher
Myles Maxfield
Cameron McCormack
Tess O'Connor
Florian Rivoal
Devin Rousso
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Scribe: dael
Rossen: I wanted to ask for any last minute agenda items or changes
Rossen: I'm aware of 3 changes; items to skip because already
discussed or will be covered further in GH. Issue #4, #8,
and #9
Rossen: Besides skipping 4, 8, and 9 other changes?
Rossen: I'll take that as a no
CSS Images
==========
Clarify which images image-orientation applies to
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5245
heycam: We have image orientation property that allows us turn off
auto-reorientation.
heycam: Some discussion about widening to all images a few months
ago. Resolution from there was orientation meta data should
be honored for decorative images. Makes sense.
heycam: Wasn't discussed if properties should be extended. As Mike
noticed we have contradictory WPTs. Should image-orientation
apply to decorative images?
heycam: My feeling is it should because real purpose of property is
let authors opt-out and it doesn't make sense to limit that
to a subset of images
dino: My question is what would you do if want decorative to do one
thing and non-decorative do another
heycam: You would need to introduce some other way of override
orientation, maybe with image value syntax, or correct images
dino: Sort of leading question. In many cases will have to fix image
or change content. Is it worth having this apply everywhere? I
don't know
heycam: From experience of bug reports they were all content images.
jpegs with image data rotated but tool didn't update meta
data so new image-orientation made them wrong. Didn't get
cases on decorative
fantasai: We had this discussion before and I believe resolution was
only to apply to content. Idea was if we needed to apply
to other we would introduce image notation syntax. This
discussion was before auto EXIF but that was original
discussion and conclusion
Rossen: Is that 4165?
fantasai: Older
fantasai: Let me check DoC
Rossen: Where does this leave the current issue?
<fantasai> https://lists.w3.org/Archives/Public/www-style/2012Mar/0412.html
fantasai: Here's the issue. #50 in DoC. Conclusion was replaced
elements and generated content but not background image
fantasai: Or any other images in CSS
fantasai: Images which are considered part of content are effected
but no other
faceless2: If purpose is undo EXIF makes sense to apply, but it's
not weird to not. As long as it's documented.
<fantasai> "It applies only to content images (e.g. replaced
elements and generated content), not decorative images
(such as background-image)."
fantasai: Spec says ^.
<fantasai> https://drafts.csswg.org/css-images-3/#the-image-orientation
fantasai: Anything that's a replaced element in css model it applies
to that. Everything else is not effected.
<fantasai> This was issue 50 in the 2012 LC Disposition of Comments
https://drafts.csswg.org/css-images-3/issues-lc-2012
heycam: Seems like notion of this property has changed over time.
Originally I want to set an orientation on an image. Now
property is for I have a problem caused by change in
browsers default and this gets me the old way back so I
don't have to fix images I'm serving. In that PoV makes
sense to apply as broadly as possible. Lets author set one
property which goes to all images
chrishtr: I agree with heycam reasoning and that's what Chrome impl.
There were cases where it was useful behavior for site
compat
<smfr> webkit agrees with cameron too
fantasai: If we make this change it should only effect none value
and others shouldn't apply to decorative
heycam: I think we have resolution to remove other values.
fantasai: It's deprecated but has been impl and shipped in multiple
implementations, just not browsers. We can remove from
next spec level, but there needs to be a spec with those.
chrishtr: Who implements?
fantasai: Some printer based technology shipped with onboard layout
in printer chipset.
chrishtr: Okay so we say rotate ones won't apply to style images
fantasai: And support for that is marked as optional so browsers
don't need to impl. But there needs to be spec for it
Rossen: Any changes to L3 images?
fantasai: Yes if we want to make from-image none value apply to
background and other images we need to change spec to say
it's all images associated with element
Rossen: Is this going to be still valid for printer or are they okay
because L2?
fantasai: They don't impl from-image I believe
Rossen: Sorry, confused by statement that there were implementations
fantasai: If we make change for other values than yes. That's why
I'm saying it shouldn't apply to the other values
Rossen: Would that solution work for everybody?
heycam: sgtm
Rossen: Proposal: Make from-image and none value apply to background
and any other images?
fantasai: Angle only applies to content
Rossen: Sorry, I meant none value on from-image
Rossen: Additional comments?
smfr: Can we resolve on cursor behavior and linked meta that are in
GH issue?
Rossen: Would this be the exception on cursor?
smfr: Makes sense for cursor to have same. Link and meta I don't
know since usually don't apply CSS to them
fantasai: Not sure what a link or meta element would do
heycam: Some cases about favicons and similar images
smfr: First comment in issues has list of interesting items like
embed object. We need to be explicit which of these we include
chrishtr: Canvas is an imperative API
smfr: Not sure about canvas I think right is API to expose EXIF to
JS or extend draw image API
<tantek> presumably you can put images on link or meta via
background-image or ::before and content property etc.
fantasai: Rest it should apply, every image associated to the
element is effected as far as CSS is concerned. If it's a
replaced element it's applied. Decorative elements would
include background image and cursor
smfr: Source graphic in SVG
fantasai: Replaced element, isn't it?
smfr: I think it's paint source or whatever it's called
heycam: I think that's rendered content of some sub-element on dom
tree
fantasai: Do you do image orientation of source, using, or neither
element
heycam: Similar to canvas-draw-image because can reference another
image element. Have minor incompat on where to look already.
I think those cases can be handled in specs that define what
it's referencing
smfr: Agree. We can resolve on what we discussed and say SVG may
need refining
heycam: I'm happy to make cursor effected.
Rossen: Should we try to resolve on this and heycam or someone can
open an issue on SVG to makes sure there's no additional
items to associate to this decision?
heycam: sgtm
Rossen: Still previous resolution. Objections?
RESOLVED: Make from-image's none value apply to background and any
other images
CSS Color
=========
When mixing hue, there are two ways round the hue range
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4735
leaverou: When interpolating between hues usually you don't want
interpolate in same way. If going between hue 0 and hue
400 you don't want a whole rainbow
leaverou: What we put in spec is by default use shortest arc which
does expected in common. Have keywords for longest arc etc
and also as-specified keyword to allow raw interpolation
leaverou: Wasn't sure if all keywords needed. Especially the
specified one. If impl want to store value as normalized
keyword doesn't allow
leaverou: I put algorithm in spec which tweaked by dbaron. Good to
get sanity check.
<smfr> https://drafts.csswg.org/css-color-5/#hue-interpolation
fantasai: Can you summarize?
leaverou: Do we need all 5 keywords?
leaverou: We need shorter because that's what you expect in most
cases. Do we need specified which is interpolate as
specified so if you go between 0 and 720 you get 2
rainbows. Need increasing, decreasing, longest or is that
completest?
fantasai: Are there use cases? We can add keywords. If there's not a
use case might want to note possibility for future
reference in case we need to add later. If not a use case
don't need to add.
fantasai: I think it's useful to think of all and make sure keywords
are a set that make sense even if we only include 1 or 2
in spec
dbaron: Intent is these would eventually apply to all gradients,
animations, and color mix functions or only some?
leaverou: Good to design with that in mind. Not sure how to write
text for animations and gradients but if we have a syntax
making sense it would be good to have the option
<astearns> for gradients and animations the workaround would be to
add more steps/stops to mimic the non-short behavior?
fantasai: My suggestion is draft all in spec, put an issue in saying
we're not sure if we need all and we might limit to a
subset with the subset that makes sense to you and also
note might expand to gradients. Encourage people to think
what that would look like
<tantek> +1 to publishing at least one draft with more keywords to
get the ideas published
fantasai: Early stage WD so makes sense to put ideas and poke at
them with people like Una and Adam to make cases
<leaverou> https://drafts.csswg.org/css-color-5/#hue-interpolation
leaverou: Does math make sense? This is the section ^
miriam: Thinking of specified I'd have use cases when comes to
gradient. As pointed out in chat that could be do with extra
stops.
miriam: Can't think of cases when mixing colors. I don't know if
that's separate but might be. Math makes sense. Shorter and
longer fall apart at 180 which maybe implies need to
determine direction without them
florian: I haven't reviewed math for correctness, but intuitive
seems right. Longer seems least useful. Wanting longer for
being longer seems odd. Might pick if gives right thing.
<miriam> +1 to longer being less useful than increase/decrease
florian: Approach about putting in spec now with note for use cases
sounds good
dbaron: On math have a PR to tweak. I think set notation doesn't
match pseudo code and I think pseudo code is right. I have
some tweaks for 180 case but it's not clear that's what we
want
leaverou: 180 case chris said we can pick one as long as it's well
defined. Doesn't matter increasing or decreasing
florian: Makes sense. If you have a preference you can say it.
fantasai: We use 'closest' in radial gradients so maybe that instead
of 'shorter'?
leaverou: Than what longer?
fantasai: 'farthest'?
florian: I don't think longer is needed so I don't mind not having a
good replacement
<tantek> near and far, close and distant, short and long ?
fantasai: We have farthest and closest side
leaverou: That's differ than angles
Rossen: Apart from bikeshedding I hear 2 proposals. 1) let's push a
version of the spec with all the keywords initially or as
many as we want so we encourage more incubation.
Rossen: 2) I hear agreement that longer doesn't seem useful. I
didn't hear a use case to prove otherwise.
Rossen: I don't want to bikeshed.
Rossen: Should we resolve to keep the keywords besides longer and
publish?
leaverou: I'd rather hear from Una and Adam before we resolve.
fantasai: This isn't final. We're drafting for discussion to
encourage participation. I think it's fine to put it all
in the draft, explain the thoughts, and encourage
feedback. We can publish often.
<fantasai> "Publish early, publish often"
Rossen: Objections to publish a version with all keywords but longer?
<tantek> +1
RESOLVED: Publish a version with all keywords but 'longer'
CSS Values
==========
Fallback value of ex height
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/5243
fantasai: There's been discussion since I did agenda+ so might want
to kick to GH to see if there's changes to spec text. Does
seem like point 8 is not what's implemented
Rossen: Sure. Chatter on issue started after posted agenda. Let's
give it more time.
Form Controls
=============
Allow specifying the "accent color" of a form control element
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5187
chrishtr: Form controls are styled and painted in UA specific way in
all browsers
chrishtr: There tends to be a concept of an accent color used to
indicate checked or marked state of form controls.
chrishtr: UAs pick a default color for that that's consistent in
page. There are also OS settings on some OSs to change
accent color which is respected by some browsers.
chrishtr: Color might conflict with brand of site, like site with
orange theme but checkboxes are blue
chrishtr: Proposal is to have css property which says form controls
should use this color as basis of accent color when
painting form control
Rossen: Opinions on this?
<tantek> the other big use-case is for sites that want to make
"darker" versions of form controls that match their site
styling, similar to scrollbar colors
<fantasai> tantek, that use case is handled by the 'color-scheme'
property fwiw
<fantasai> tantek, https://www.w3.org/TR/css-color-adjust-1/#preferred
<tantek> fantasai, not talking about not dark mode. hence I said
darker deliberately
fantasai: Main concern is it's not clear what accent color is used
for. Because that it's not clear what's expected contrast
between that, text, and background.
<tantek> +1 agree with fantasai, needs to be predictably specified
so it makes sense across OSs and devices
fantasai: Concern people will choose colors that are good on some OS
but won't contrast with background enough in other rows.
For example a select multiple it needs to contrast with
text. But on a selected checkmark it's background
fantasai: Understand what you're trying to do but concerned we won't
get something robust across browsers
<tantek> needs to be sufficiently predictable across browsers
florian: Can we split into foreground and background or does that
not generalize well?
myles: We had internal discussion and general feeling is good for
web in general. Not sure mechanism to expose. We have a
general idea good to style lots of form control aspects. Good
to do in general not just one piece. In general feel this has
value for web.
<tantek> +1 myles that's a good summary
chrishtr: Re: general styling point. Agree that there are other
things devs wish to style and hopefully can. This one
seems to be simple and common and immediately solves a
specific concern. That's why I think do it as a one-off
for the moment and general in future
florian: General will take time. Seems most of time accent color is
related to background but not always. If it's background or
foreground matters. Having the pair would be a step which
could make sense. There can be many aspects of form control
we can do later. Knowing if you're in foreground or
background matters.
heycam: Ignoring select multiple issue which might not be accent
color all other colors are contrasting separately. For
checkbox and radio you'd got icon inside which authors can't
control. I think for most cases where accent color can be
changed any contrasting color can be painted by UA.
jensimmons: Has anyone working on open UI on the call? I know a lot
of work has gone into form controls and what it means to
style them
myles: On iOS there's no concept of the accent colors. Whatever is
in spec needs affordances for OS where it doesn't apply
florian: If we look at range of historical OS to get diversity the
buttons were a shade of blue. If that was still the fashion
accent color wold be there and it's very background-y
<florian> https://66.media.tumblr.com/e0c02215356306ee52298451ac25685e/tumblr_o5a0h4UIDN1v0jfsto2_1280.png
<florian> http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif
chrishtr: Answering jensimmons, I'm working with gregwhitworth and
others on longer term project for form controls. I don't
know if enough to discuss here. In general I think compat.
I don't think there's enough to say about OpenUI to clarify
Rossen: Is there a resolution you're looking for?
chrishtr: I'm hoping to get to agreement on name and set of text
what's it's supposed to be for UA and says UA should make
sure sufficient contrast and only where it makes sense
fantasai: Fine to try and draft language. Requires more review to
make so it works on a variety of OSs. I'm a little
skeptical this will work but understand we want it. I'm
concerned about having it work for all OSs.
fantasai: If we can show that would be the case across current and
past OSs and there's a reasonable interpretation for all
the OS/browser combos I would feel more comfortable moving
forward
<jensimmons> +1 to what fantasai said
chrishtr: Hearing general support but need more research to
understand compat as well as foreground/background comments
fantasai: I think we should do that evaluation in GH. Might be right
design, but might be diversity of form controls requires
something different.
<tantek> we're also looking preliminarily at a more longer term
project for form controls as well, if existing work is
happening in the open, please share that in CSSWG! Thanks!
chrishtr: We'll come back with more concrete proposal
florian: What I'd like to see in research is wide variety of form
control and show form controls is always background or
neither. If it's in foreground sometimes we need to split
it up.
<tantek> just going to note that existing OS UI use of color is
insufficient to determine feature flexibility, new OS's may
and will do new things with colors etc.
CSS Sizing
==========
Should aspect-ratio be used for abspos `top: 0; bottom: 0;`?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5151
<astearns> PR:
https://github.com/w3c/csswg-drafts/commit/9594b70729ff481ea933a3e3d07a85423122e0eb
fantasai: Issue raised was if you have abspos element with top,
bottom, left set non-auto but right is auto should that
use aspect-ratio in sizing width. TabAtkins and I thought
it made sense so drafted spec of that.
fantasai: If width and height are both auto we ignore aspect-ratio
for width and use it for height. In this case it's easy to
determine height. Width has only one constraint so it's
variable and makes sense to use height for deterministic
value
fantasai: Drafted wording into positioning spec. Wanted to check
with WG if it's acceptable
Rossen: Would align-stretch work the same or have same behavior in
this case?
fantasai: Don't remember which align-stretch does
Rossen: My understanding is align-stretch should behave same as if
fixed height which should then have the same expected
behavior for aspect-ratio, wouldn't it?
Rossen: Not sure if this is related to position spec
fantasai: align-stretch takes precedence over aspect-ratio. If
neither is stretch, width and height auto, but can stretch
because top:0 bottom:0. Take that as a definite height
where we can calculate the width
Rossen: Back to top and bottom 0. Other opinions or reasons why the
aspect-ratio shouldn't behave this way?
cbiesinger: On behalf of Chrome I support
Rossen: This isn't just about top:0 bottom:0 it would be same with
top:10.
fantasai: Right. It's non-auto
dholbert: This is any element with an aspect ratio?
fantasai: Problem is we have compat requirements for images. For a
replaced element it's slightly different. Replaced
elements don't stretch between constrained insets and we
can't change due to compat. aspect-ratio on non-replaced
we figured we can do the thing that makes most sense.
fantasai: Question is do we use it to resolve height or width in
this case since height can come from size of containing
block.
Rossen: Objections or other comments?
RESOLVED: Accept proposal [
https://github.com/w3c/csswg-drafts/commit/9594b70729ff481ea933a3e3d07a85423122e0eb
]
Rossen: Let's call it for today and we'll chat again next week.
Thank you everyone and we'll chat on the 8th
Received on Thursday, 2 July 2020 10:23:57 UTC