- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Feb 2020 19:30:21 -0500
- 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 Device Adaptation & CSS Viewport
------------------------------------
- RESOLVED: Remove @viewport, retire the spec, move the meta tag to
a new spec (CSS Viewport) (Issue #4766: Remove @viewport)
- RESOLVED: Move layout/visual viewport spec into CSS Viewport spec
- smfr will be added as an editor to the new CSS Viewport spec
CSS Contain
-----------
- RESOLVED: Accept proposal as phrased in comment from florian [When
calculating the size of the containing box, including
when computing its intrinsic size, it must be treated as
having no contents.] (Issue #4741: It should be clearer
that size containment inhibits effects of contents on
intrinsic sizes)
CSS Pseudo Elements
-------------------
- fantasai will draft up proposed text for issue #4720 (Clarify
::selection background-color in presence of fill/stroke)
creating a keyword so that the UA can set that keyword and it's
only used if both color and background-color compute to the
keyword.
CSS Sizing
----------
- RESOLVED: Syntax order is physical for intrinsic-size (Issue
#4531: intrinsic-size lost the thread)
- RESOLVED: Switch initial keyword [of intrinsic-size] from 'none'
to 'auto'
CSS Color
---------
- RESOLVED: Add clarifying text that all system values are
reflecting the browser settings (Issue #4533: Clarify to
what extent new system color are about system settings
versus browser settings)
CSS Color Adjust
----------------
- RESOLVED: Accept proposed definition [do not apply forced colors
to SVG <text>, and only apply forced-color-adjust: auto;
to <foreignObject> SVG elements.] (Issue #3855: Define
what happens to SVG in forced colors mode)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Feb/0004.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Daniel Libby
Chris Lilley
Peter Linss
Florian Rivoal
Christopher Schmitt
Jen Simmons
Scribe: dael
CSS Device Adaptation
=====================
Remove @viewport
----------------
github: https://github.com/w3c/csswg-drafts/issues/4766
smfr: Since @viewport hasn't traction on shipping browsers I propose
we remove and just specify the metatag which has wide support
TabAtkins: Support
florian: Yeah, I'm editor. I like @viewport but I can't disagree. It
doesn't have traction
florian: Related; we resolved to define the viewports and CSSOM View
as the host. If device adaptation doesn't contain @viewport
this is a good host for them. Should we move?
smfr: Don't agree because spec of layout and visual viewports is
about layout, not about adapting to devices. That's why I
think I would like it elsewhere. This is right for tap
highlight color or things only for devices.
florian: Why I'm not happy with them in CSSOM View is not all things
care about viewports have OM. Where else it should live,
this felt okay. I can live with elsewhere. I don't feel OM
view is a better home
smfr: I think OM View is a bad name for a spec.
fantasai: I agree with them in device adaptation. Less convinced
with things that are touch specific. It's fundamental to a
lot of devices and I think it goes in UI. But I agree with
dropping @viewport and shifting meta viewport into device
adaptation
florian: If device adaptation name is the problem we can retire as a
note and have a new spec called viewports
smfr: That would be fine. If layout and viewport is moved to another
spec I should be editor on that.
smfr: Layout and visual viewport will tie into scrolling and
coordinate system for getBoundingClientRect. That's why I
think more closely with OM View
florian: A bunch need to refer to them but that's not defining what
they are
Rossen: We are moving away from original topic. Given that we don't
have layout and viewports spec yet we can decide where to
host once we have spec text closer.
Rossen: Back to original proposal to remove @viewport. I didn't hear
any challenges and I hear support.
Rossen: Objections to removing @viewport?
florian: Don't object. Suggest we retire spec
smfr: Need live spec for meta viewport
florian: Yeah, call it viewport spec
tantek: Drop is from lack of implementor interest?
many: Yes
florian: Proposed by Opera, adopted by MS, and then both companies
switched to engines that lack that feature and Google had
concerns
Rossen: And we didn't have any use of it. Adding it didn't add to
capabilities we had. No one has asked for it after we
decided to move on to Blink platform
<tantek> Gecko BTW: https://bugzilla.mozilla.org/show_bug.cgi?id=747754
tantek: Checking Mozilla bug ^
Rossen: tantek are you trying to push back on resolution?
tantek: I read the GitHub and hearing reasoning from absence of
evidence. I wanted to site relevant Gecko bugs and I guess
Blink.
florian: Google has objected to it
tantek: I didn't see that in the bug. It wasn't linked. That's a
strong claim so I'd like a link
<smfr> https://github.com/w3c/csswg-drafts/issues/258
smfr: There's a link to ^ from Google saying @viewport is loader
hostile
florian: That's the one
tantek: They think it's bad idea
smfr: And WebKit agrees
tantek: So it's bad design not neglect?
florian: Both.
tantek: Can't be both.
Rossen: Let's try to resolve on this. tantek do you object to the
resolution? If you object let's record it and move on.
tantek: I can't find a reason to object
<dbaron> I'm not sure what I think about the objection of being
preloader-hostile -- I think many good features may not fit
nicely with preloading but that doesn't mean we shouldn't
do them for other reasons.
RESOLVED: Remove @viewport, retire the spec, move the meta tag to a
new spec (CSS Viewport)
florian: And make smfr an editor of that
smfr: Okay with that
smfr: Also okay with layout and visual viewports being in this new
spec
Rossen: Proposal: Move layout visual viewport spec into CSS Viewport
Spec
RESOLVED: Move layout visual viewport spec into CSS Viewport spec
smfr: Should it be Viewport or Viewports?
<smfr> “viewport” or “viewports”?
TabAtkins: Prefer singular. Maybe only have one plural in backgrounds
smfr: Fine
<fantasai> +1 to css-viewport
Rossen: Let's stick singular for now
CSS Contain
===========
It should be clearer that size containment inhibits effects of
contents on intrinsic sizes
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4741
dbaron: I don't think this is controversial but it seemed to me it
should be implied by size containment it doesn't impact
intrinsic size in addition to final computed size
dbaron: Ran into this while writing something that referenced size
containment.
florian: Agree it was the intent. Proposed rephrasing is in the
issue to clarify. dbaron said he was fine.
florian: [reads original sentence]
florian: Would insert including when computed as intrinsic size.
Suggest we add to L2. Clarification so I'll probably edit
it into L1 too.
Rossen: Proposed resolution?
florian: Accept propose as phrased in comment
Rossen: Objections?
RESOLVED: Accept proposal as phrased in comment from florian
fantasai: Republish a REC?
florian: Rather not, not worth process hassle
florian: Happy to update ED so if we do need to update REC it's
folded in
Rossen: fantasai do you feel strong to republish?
fantasai: Not super strong. Want to keep things in sync but this is
minor
fantasai: I do want us...if something doesn't effect sizing it
should mean any type of sizing. I don't think
clarification is a problem but I think problem if "Size"
doesn't include "intrinsic size"
CSS Pseudo Elements
===================
Clarify ::selection background-color in presence of fill/stroke
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4720
fantasai: I don't have proposed change, it's a question. Special
rule that says if either color or background-color is set
on selection then UA default colors for both are not used
and we use initial value for not set property
fantasai: What if author sets fill or stroke, should that remove the
UA default color and background-color or is that part of
properties that nulls UA rule or applied in addition to UA
rule?
dbaron: Why do we have that behavior in the first place?
dbaron: We remove the UA rules?
fantasai: Yes and I'm pretty sure that's required for web compat.
Haven't tested, but implemented in all browsers that way
tantek: Don't know how to evaluate without tests
fantasai: No one implements fill or stroke right now
tantek: Test for existing behavior so we can understand effect and
what desired/undesired would be
fantasai: Will make a test case
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%3A%3Aselection%20%7B%20color%3A%20blue%3B%20%7D%0A%3C%2Fstyle%3E%0A%0A%3Cp%3ETest%20%3Cspan%3Ethis%3C%2Fspan%3E
<fantasai> testcase ^
<fantasai> demonstrates that setting 'color' removes background-color
<emilio> fantasai: I'm pretty sure browser behavior is _any_
property removes background-color
<fantasai> emilio, yes, but I don't think that's a web-compat
requirement, and I think it's reasonable that e.g. adding
text-decoration doesn't remove colors
dbaron: Seems like this behavior is kind of silly and removes
possibility of using one of the colors. Maybe not silly.
What's trade off between preventing things authors would
like to do but can't so with this rule vs the fact that spec
one color but not the other will break when defaults aren't
expected
florian: More that case
Rossen: Clarifying question- if what you're proposing is adopted if
I set a stroke or fill are you suggesting selection
background will be discontinuous?
fantasai: Transparent, yes
Rossen: That on its own is questionable
florian: If you set stroke and color and color-background you get
intended. If only set stroke you expect the rest to be set
to something
emilio: I'm pretty sure browser behavior is as soon as have a
selection pseudo element then you apply UA colors. You put
anything in and browser suppresses default colors
fantasai: I don't think that's good
emilio: But it's current. Agree not great. May not be great
Megan: Do we know why this is there in the first place?
emilio: Once you get to rendering you only have computed style.
Gecko can in theory do it, but it's easier saying does
pseudo match any rule vs saying did the author specifically
set this color which could be same as UA color
<Rossen> What about the use case for
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-stroke
<AmeliaBR> Test case for SVG:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7755
AmeliaBR: There was statement earlier that we can't test browser
because they don't impl fill and stroke. Not true with
SVG. We have existing use. Made a quick test. In Chrome if
you set a fill color in a selection for SVG text it
doesn't draw default selection background. Have to look at
other browsers to see if consistent
florian: True in FF
??: Have looked in Safari
AmeliaBR: If we want to keep it's another question. In SVG have no
way for author to define background-color for selection.
Don't have a property that's span background-color.
AmeliaBR: Either way selection styling is limited in SVG. It's
something to think of.
smfr: These examples show what emilio stated. UA assumes author
knows what they're doing and provides style to make selection
look okay.
florian: We can keep spec as is and increase scope. Or we say if you
have a selection pseudo things change
emilio: I'm pretty sure it's consistent behavior except blink and
webkit don't handle empty decoration blocks.
florian: Empty because syntax or just empty
emilio: Just empty. Discarded with unknown property. If declaration
top line is 0. I think it's styling optimization doing
unexpected
florian: If it discards unknown syntax that's annoying
emilio: I think that's a bug.
Rossen: Implementation issues aside. I think a guiding principle
should be whatever behavior we land on can't break user
expected behavior of visual selection
Rossen: I think one of the challenges is if I accidentally create an
empty selector I'm breaking the user expected behavior. That
sounds like a counter-argument to have the behavior
currently proposed.
Rossen: From there if this is obviously not the case main question
is how smart should this rule behave and how are these
interdependent properties are supposed to behave. One is put
it in the hands of the author and trust or provide safe
defaults in browser to guaranteed expected behavior. That's
the top level fork
fantasai: For as long as selection only accepted background-color
and color it made sense if you choose one or the other you
drop UA selection color because it could be any random
color and you want to know the contrast. That does have
utility in that author can't assume and if they set color
can't predict background-color
fantasai: As we extend selection to allow for more properties should
I add a text decoration in that rule some browser it will
have effect and in some it won't because not impl. but it
will blow out existing color so browser without support
will have no indication of what's happening.
fantasai: That's bad for the user and we don't get benefit from
dropping colors when adding text decoration
<AmeliaBR> What fantasai is describing is exactly what happens with
my SVG test in Firefox: you don't get the
author-specified selection fill color, but you also don't
get the browser default selection styles.
fantasai: From PoV that we're adding more properties any property
blowing out the colors is a problem for transition
especially as transition could be continuous as we add
more properties. Indefinite period of transition and any
property will blow out color in browsers that don't
support it.
fantasai: Would be best for us to not have any property blow out all
the colors behavior. I don't think it's good. Given
current behavior and contrast concerns having that
behavior for background-color and color we can't and
shouldn't change.
fantasai: fill and stroke have same contrast concerns so should fall
in same bucket. If you set any of those 4 you drop, any
other property does not
<florian> +1
emilio: I kinda agree with Rossen that current is sometimes
undecided. These 4 properties disable and rest do not seems
weird to me. Can we add a note to spec say UA should ensure
selection has visible effect?
emilio: Not sure. 4 properties that disable not sure it's the best.
Maybe it is.
fantasai: There's 2 reasons why background-color and color reset
should be kept. One is that if author sets
background-color they make assumptions about text color of
selection and that might be incorrect on another platform.
If you're not testing all platforms you can get bad
contrast
fantasai: Second is this is current behavior so if people are
setting it's with background-color and color. not sure if
anyone is depending on not setting these. If they are
might be depending on fact that setting background-color
causes reset
emilio: Setting background-color should retain inherited color. Not
sure that contradicts my proposal to ensure there's enough
contrast. I think some UA restrict transparency.
emilio: I agree we can't break that case of just changing background
plinss: Opportunity to instead of magic where one property blows out
another can we have a value UA can set that has that
behavior?
plinss: That way UA can set magic value for color and
background-color and then setting values acts normally.
AmeliaBR: Logic would be UA says `color: selection-style;
background-color: selection-style` but rule is you only
use them if both values compute to the keyword and
otherwise go back to inherit. Is that what?
plinss: Something like that. not exact mechanics. I want not having
magic behavior, just magic in value of property
florian: Have similar in text decor. Value of text-decoration-line
that's supposed to be used on ::spelling-error has a value
of spelling-error.
plinss: The UA stylesheet says selection color something like
selection color. Behavior is normal as far as web property
is defined. Make sense?
fantasai: Yes.
Rossen: Should we put this back to issue and work out details later?
Rossen: Once proposed magic is baked enough we bring it back for
resolution?
fantasai: I think that works. I'll try and draft plinss suggestion
as AmeliaBR described and see if that's acceptable
Rossen: Sounds great. Adding guiding principles of expected behavior
would be good.
[agenda wrangling]
CSS Sizing
==========
intrinsic-size lost the thread
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4531
TabAtkins: Whether intrinsic-size should order sizes in logical or
physical. I objected to physical ordering on idea that
we've been doing logical lately. fantasai leaned
physical. I went through list of css properties that take
2 lengths and categorized
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/4531#issuecomment-585321048
TabAtkins: List ^
TabAtkins: Pattern is clear. There are 4 properties that are logical
and they're all specs fantasai and I have done in last
few years. All others are physical. More physical then
logical
TabAtkins: Unhappy about overall split but if fantasai is thinking
we should stick with physical I think data agrees and we
should switch to physical where we can
fantasai: Agree with conclusion, though not all details leading to
it. Useful to switch to logical for layout. Block first
was a mistake. I think size property close align to
properties that background size that are physical. All box
sizing is physical. So this should fall into that category
TabAtkins: List is split between offset and sizes. Properties that
are background like agree so let's do it. Size is
physical.
Rossen: Last time we called for objections you were the only one.
Objections now?
AmeliaBR: What's the resolution?
TabAtkins: Syntax order is physical for intrinsic size
Rossen: width and height
RESOLVED: Syntax order is physical for intrinsic-size
cbiesinger: One other thing, I think we need initial value as a
keyword that is auto. Thoughts on that?
florian: Agree
fantasai: Why need?
cbiesinger: Because 0 isn't always the default. If have flexbox with
gaps initial value would take gaps into account so 0
can't be initial
fantasai: How if don't know number of items?
florian: Hard coded quantity of columns
TabAtkins: To clarify, initial value that's a keyword is decided
with examples. Question is if keyword name should be
'auto' or 'none'. I think spec is 'none' but fine to
switch to 'auto'
AmeliaBR: Agree 'auto' is better because 'none' is easy to confuse
with 0
cbiesinger: Agree
<fantasai> +1 to Amelia's reasoning
Rossen: Objections to switching initial keyword from 'none' to
'auto'?
RESOLVED: Switch initial keyword from 'none' to 'auto'
CSS Color
=========
Clarify to what extent new system color are about system settings
versus browser settings
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4533
dbaron: To some degree a question. Might help to get it sorted out
for us to implement. A bunch of new system color keywords in
Colors 4. One thing unusual is they're both and OS and a
browser setting and may be different
dbaron: Are these about getting browser or OS setting?
fantasai: Browser setting
TabAtkins: Agree
fantasai: It should default to match OS but if user sets different
we should honor
AmeliaBR: Should always be about respecting user preference. If set
something specific in browser it should override the OS.
Rossen: From tooling you should be able to allow the dev tools to
change and override system colors and they see fit so
authors can play.
Rossen: Browser has the right to override the system color. Author
running code should never see system except through lens of
browser.
Rossen: Back to issue; dbaron does that answer your question?
dbaron: It does. That was my preference.
dbaron: Good to get it written so can land patches
Rossen: Do you propose clarify in spec?
dbaron: I think it should yes
Rossen: Objections to adding clarifying text that all system values
are reflecting the browser settings
RESOLVED: Add clarifying text that all system values are reflecting
the browser settings
CSS Color Adjust
================
Define what happens to SVG in forced colors mode
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3855
Rossen: I can introduce this
Rossen: This issue defined how forced colors are supposed to effect
SVG. Previous resolution was that forced colors should apply
to text element and foreign object element. Foreign object
makes sense because switching to HTML and all forced color
rules apply
Rossen: Additional complication and proposed change is what seemed
reasonable to expect text element effected by force colors
but in effect when text gets forced color applied in
addition a background plate should be rendered so overall
contrast ratio is as defined through system. This proved to
be ineffective and counter intuitive for SVG
Rossen: A few cases where this might make sense but in general since
no SVG elements except these are effected by forced colors
overall effect becomes incongruent. Proposing to revert
including font
Rossen: Computing backplate on a path is hard to define and
detrimental. You either get bounding box is is more then
necessary or you do per glyph which is bad
Rossen: Proposal: exclude text elements of svg from being effected
by force colors
chris: Agree, makes most sense
AmeliaBR: sgtm
AmeliaBR: Example in spec may be useful about using MQ to make SVG
work with high contrast. Default it's best not to try and
do too much
AmeliaBR: Do we need to call out foreign object or do colors
naturally apply to content inside? Do we need to add
colors to the foreign object itself or enough content
inside has the rules if it's html
fantasai: We should set force color adjust none on SVG root and
switch to auto on foreign object
<AmeliaBR> +1 to fantasai's solution
<fantasai> which is what's posted in the issue at
https://github.com/w3c/csswg-drafts/issues/3855#issuecomment-485023552
:)
chris: agree [missed]
chris: You don't want color value set outside inheriting in. Need to
be explicitly set on foreign object
Rossen: That's the impl we landed on. +1 to fantasai
Rossen: Other suggestions or objections for that resolution?
RESOLVED: Accept proposed definition
Rossen: Please engage on GH with remaining issues. We'll prioritize
these items for next call
Received on Thursday, 13 February 2020 00:31:04 UTC