- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Jun 2018 19:56:19 -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 Grid 2
----------
- RESOLVED: publish a new Working Draft of Grid Level 2
Filter Effects
--------------
- RESOLVED: If there is an explicit author-specified background,
that layer that has gotten propagated on top of the
canvas, filter does effect that. (FXTF Issue #282)
CSS Contain
-----------
- RESOLVED: Size containment doesn't apply to tables (Issue #2746)
CSS Shapes
----------
- There were two proposals for how to handle the author desire to
allow shape-outside to apply to initial letter, the initial
commit from dauwhe and a proposal from astearns. Both seemed
like they would work, so discussion will continue on GitHub as
to which is preferred (Issue #885).
===== FULL MEETING MINUTES =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0016.html
Present:
Rachel Andrew
Rossen Atanassov
Amelia Bellamy-Royds
Garrett Berg
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Chris Harrelson
Chris Lilley
Peter Linss
Anton Prowse
Liam Quin
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
Tab Atkins
Dael Jackson
Vlad Levantovsky
Michael Miller
Dirk Schulze
Scribe: melanierichards
CSS Grid 2
==========
<fantasai> https://github.com/w3c/csswg-drafts/issues/2564
<fantasai> https://github.com/w3c/csswg-drafts/issues/2592
fantasai: Requesting review on #2564, for #2592 can publish keeping
this issue open.
<chris> fantasai, Grid 1 is a CR. This is a transition request, not
a publication request
<chris> for updated CR
<fantasai> chris, grid 2 is WD
<chris> oh this is for grid 2, okay sorry
Rossen: would prefer to have this as an open issue.
Rossen: any objections to publishing as WD?
[no objections]
RESOLVED: publish a new Working Draft of Grid Level 2
Filter Effects
==============
Effect of filter on document element
------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/282
smfr: Question is whether this effects the root background color, by
which I mean HTML body element. The way the spec currently
stands it's possible to create unreadable text [paraphrased].
Wonder if it's possible to allow the canvas's background color
to be effected by filter()
smfr: Summarized in issue, but what happens if you apply filter() to
html element?
smfr: Informal poll on twitter, authors didn't expect currently
defined behavior, expecting inverted background
<smfr> https://twitter.com/LeaVerou/status/1001859421469855744
florian: Not sure about how the question was phrased, didn't seem to
be clearly about the html element and various interactions
<leaverou> (poll phrasing was exactly the same as smfr's
<florian> the poll phrasing asked if people expected the invert
filter "to make the default white background black" it did
not ask if people expected that it would "make the default
transparent background that is over a while background
black"
Rossen: One of the points being made is, when you do apply a filter
that happens to apply to the default canvas background
color, this is something that we have not specified. We are
keeping this UA dependent. We might want to have the window
or the canvas of the UA itself to be not necessarily want
particular color. We may have special filters applied to it.
In the more recent version of Windows, that's one of the
defining principles. I'm not particularly excited in losing
this ability in saying no, the background color would have
to be a specced color, black or white.
smfr: I don't think this is saying that. In webkit we have the
ability to make the canvas transparent and have other things
shine through. You would be apply to transparent pixels and
the filter would be applied in the correct way. If there was a
color, the filter would apply to that color
Chris: what if the filters make the pixels transparent?
Chris: I think we shouldn't allow a webview to become transparent
[general consensus]
smfr: When you're rendering with a filter, you essentially take a
snapshot of the page, render the filter, and apply the
snapshot.
Florian: It seems simpler to say that the filter on the background
effects the background color of the HTML element, and not
the background behind it, which is white
<chris> no, background on html is black (and background on root is
transparent) see https://drafts.csswg.org/css-color/#sample
Florian: From the twitter poll it seems to be referring to the white
background behind transparent background
AmeliaBR: Part of the problem is authors don't have a detailed
understanding of how the background layers work in the spec
chrisl: They don't understand the root behind html, those sort of
details
florian: Most people don't understand those, but can still ask the
question: what do you expect? instead of suggesting an
answer
* chrisl needs a couple of good examples in the spec, and a diagram
showing root, html, and body layers
AmeliaBR: Regardless of exact poll details, I think we can accept
this is a confusing topic and needs to be clearly defined
and explained. There are a couple layers of it. By the
fact that it hasn't come up, if you apply filter to html
that would apply to a background image on the element, is
everyone in agreement with that?
[general consent] So long as there's another color behind that
AmeliaBR: We have the canvas default color, behind that we have the
background image or color set on the root element, or set
on the body and propagated up to the root. The question is
what if that layer has not been set and it defaults to
transparent
smfr: What you proposed is actually a behavior change in Chrome and
FF
AmeliaBR: That is a change but I think we agree it's logical. Next
question: if there is no root bg on the element, then we
still have the default canvas background, which is a
separate layer. Used as separate in blend modes, where
blend modes never affect that default canvas layer. I'm ok
with saying that that default canvas layer is independent
from filters, but need to communicate clearly to authors.
AmeliaBR: If we let that never be effected by filters, we need to
deal with if the filter makes that ??? layer partially
transparent.
chrishtr: 3 layers: root background, canvas layer, root element
which may be different?
AmeliaBR: The root element never has a background of its own, it's
always propagated to the canvas.
chrishtr: I think we can always have two layers
Rossen: What we are getting at, if we have this model of 2 bg colors
on the canvas, one which is modifiable by whatever comes
from the root, and one which is not which is the very bottom
background layer, UA defined, but it's blend-able with
whatever's on top of it. The only way this could work is if
the intermediate one is transparent. If body or html
propagates to transparent, transparent is transparent. So
you see whatever is on the bottom layer (the UA background
canvas color)
Rossen: We have one bottom layer which is non reachable by any CSS
constructs, regardless of whether or not we are propagating.
We have the intermediate layer that allows you to blend what
you need to blend; author defined background color
propagates to here. Is this the model we're trying to get to?
smfr: Propagated color not necessarily opaque, rgba
Rossen: But still not effecting the bottom layer. Don't want to
punch a hole through webview by specifying transparent root
bg color
Florian: If the filter is applied to the transparent canvas, we
would still see the white background behind it, right?
Rossen: If we need to have an initial color on say html that gets
propagated to background root element, that is different
from transparent, we can discuss this
Florian: Would be ok with default being white
AmeliaBR: In spec we could have a warning that if you apply filter
to the html element, then also need an opaque background
for it to work correctly
AmeliaBR: Think it can be handled with note to authors to apply
background color to root element
<florian> +1 to AmeliaBR
smfr: What about applying filter to root elements for accessibility
reasons? (UA etc) might be different from the author of the
page
smfr: We have some interest in this from dark themes on Mac
fantasai: Could set white as default in that case, and user would've
had to set root bg color explicitly to transparent
Bo Campbell: Would like to look into this a little more from
accessibility, can you help me understand that use case
better?
smfr: Someone with accessibility issues might want to avoid bright
colors and apply a saturation filter to all the web pages they
look at. Or they want to turn down brightness (don't want to
see stark white background)
Florian: In the user style sheet, they could set it to white, and
only if author set to transparent would it break
smfr: An option to allow filters to apply to default page bg would
be to propagate the color from the bottom UA-controlled layer
to the intermediate layer
Rossen: The blending layer!
chrishtr: smfr's proposal seems reasonable
AmeliaBR: That proposal to always make the root background opaque,
may mess with how blend modes currently work
smfr: Will have to think carefully about blend modes w/ new
conceptual model
Rossen: Proposal is an intermediate layer where background from
UA-controlled layer is propagated by default. All of the bg
color propagation from HTML also propagates up to that
intermediary layer. Can we try to adopt that model and
resolve? otherwise take back to GH
Rossen: Objections to adopting this model?
Florian: Whether it gets the UA layer background color or not, I
think that's what we have to think about more
AmeliaBR: Quick test, looks like blend modes never effect the canvas
layer even if explicitly set on root element. Still need
careful consideration
Florian: Open question is whether or not we propagate from the
background layer or not
AmeliaBR: If there is an explicit author-specified background, that
layer that has gotten propagated on top of the canvas,
filter does effect that. need a resolution on that
Rossen: Objections to resolution in Amelia's comments?
RESOLVED: if there is an explicit author-specified background, that
layer that has gotten propagated on top of the canvas,
filter does effect that.
CSS Contain
===========
Size contain shouldn't apply to tables
--------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/2746
florian: We've already said that size containment doesn't apply to
table parts, haven't said anything about tables. The way
containment works, tables would end up smaller than their
contents
Florian: In the inline axis of tables we don't have a good
definition or interop. In block axis seems to do nothing.
In inline axis, in some browsers the borders go diagonal
Florian: Think we should skip this here
fantasai: I can imagine someone wanting to size constrain a table
and put a scroller on it
Florian: Proposal is to add tables to the list of things size
containment doesn't apply to
Rossen: Sounds reasonable
Rossen: Objections? opinions?
[none]
RESOLVED: size containment doesn't apply to tables
CSS Shapes
==========
Allow shape-outside to apply to initial letter
----------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/885
fantasai: [explained two open questions in issue]
fantasai: This is for initial letter in inline 3 spec. Should be
able to handle combo of initial letter and shape-outside,
we have to define that
<AmeliaBR> +1 to allowing shape-outside: glyph or self anywhere, not
just on initial-letter
<chrisl> +1 to fantasai
Rossen: One of the reasons we didn't want to add any geometric
abstractions for shapes in level 1 is much higher
implementation complexity. ??
astearns: My solution is to enable you to use all the initial wrap
values, either with the margin box or the shape outside.
We'd get the ink wrapping behavior once we add it for
shape outside
astearns: See my updated comment in issue
astearns: [reads out comment:
https://github.com/w3c/csswg-drafts/issues/885#issuecomment-397001523
]
astearns: There is a problem in that you wouldn't get the full ink
behavior until we define that for shape outside. That does
make the parallel between letter wrapping and floating
wrapping more solid.
fantasai: Means that the first value cannot work on the shape
specified on shape outside, Florian suggesting we make
that work. Either the shape outside is controlling what we
wrap the rest of the line to, or what we wrap that first
line to
astearns: Trying to match the rest of the word to the initial
letter. If I've got a letter and want to wrap most of it
around a circle, still want the rest of the word to move
to match typographically
fantasai: Could imagine someone would want to do that, but also see
someone being like "This shape is replacing the glyph
shape", wrap to that
astearns: In my proposal, first line would definitely use ink bounds
in every case. would get that, even with margin box
fantasai: For an initial letter, the shape that we're wrapping to is
the first letter shape, unless shape outside says
"actually I want you to wrap to this other shape". we use
glyph shape if shape outside is none, otherwise use
provided shape
florian: Both proposals seem valid and useful in different cases
Rossen: Let's discuss further on Github and revisit next week
Received on Thursday, 14 June 2018 00:57:16 UTC