- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Jun 2018 20:52:15 -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 Fonts 3
-----------
- RESOLVED: Change to 'should' in L3 [for synthesizing super/
sub-scripts] and push for it in L4. (Issue #2796)
- RESOLVED: Request transition to proposed rec for Fonts L3.
Filter Effects
--------------
- The group discussed the proposal to have the filter apply to the
viewport when applied to the root element. (PR:
https://github.com/w3c/fxtf-drafts/pull/263/files
FXTF issue:
https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933 )
- There were concerns that this would yield unexpected behavior for
authors since they would expect the filter to be applied to the
entire page, not just the viewport, and might see a shimmer when
scrolling.
- Applying to the entire page was thought to be extremely
complex, if not impossible, implementation-wise for some
filters like blur.
- There was no agreement on how best to balance author expectations
and implementation needs, so use cases will be gathered on
github to further the conversation.
- The original resolution that lead to this proposal, "non-none
values of filter induce a containing block for all positioned
descendants", may also need to be revisited since it's what
necessitated this proposal.
CSS Transforms
--------------
- RESOLVED: Use Edge behavior [interpolation per transform function
for all CSS supported transform functions] (Issue #2684)
- RESOLVED: Make rotate() with 3 values transition to a matrix and
do matrix decomposition (Issue #2684)
- RESOLVED: Add these keywords [content-box and stroke-box] to
transform-box property. (Issue #999)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0022.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Tantek Çelik
Alex Critchfield
Elika Etemad
Tony Graham
Chris Harrelson
Dael Jackson
Bbrad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Liam Quin
Melanie Richards
Florian Rivoal
Dirk Schulze
Jen Simmons
Alan Stearns
Lea Verou
Greg Whitworth
Jeff Xu
Regrets:
David Baron
Emilio Cobos Álvarez
Dave Cramer
Benjamin De Cock
Vlad Levantovsky
Manuel Rego Casasnovas
Geoffrey Sneddon
Scribe: dael
astearns: We'll skip items 6, 8, and 10 on the agenda
astearns: Anything anyone would like to add or change?
fantasai: Did you mean 9 instead of 8?
astearns: You said 6 and 10
fantasai: Yes. For 9 we wanted Oriol.
astearns: Oh, I'm sorry. it is 6 9 and 10 to skip
CSS Fonts 3
===========
Dropping "synthesizing super/sub-scripts" requirement
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2796
chris: Let me give a DoC link
<chris> https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018
<fantasai> https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018#issue-9
chris: One remaining issue. There's an advisement in the spec if you
have open type font that has some...
chris: If it has some open type features for sub scripts and super
scripts but doesn't cover all glyphs the spec advises not to
use and to synthesize them. No one does that and it's at risk
in CR. As it's at risk and there's not implementor interest I
opened issue to downgrade to should or may.
chris: There was some objections, florian not happy
florian: My concerns is since the glyphs supported won't line up it
may be semantically confusing. Non-lined up may be multi
level superscript.
chris: That's possible. The example was chosen to be particularly
bad.
chris: This isn't a new issue. The advice to switch off the real
superscript and sub script is well intentioned but not impl.
We could defer the entire thing to L4. We didn't get
consensus around changing html stylesheet.
fantasai: This isn't the reason for html stylesheet. That's because
can't do many levels subscript.
chris: Agree.
florian: I agree that just because this is bad we don't have an good
answer. I don't want to block and if downgrade to should is
what we can do that's what we have.
chris: We have downgrade to may, should, or move to L4. I prefer
should.
florian: We should put pressure as well as doing should.
liam: I wanted to point out it's not an edge case. content-editable
the user adds an unsupported character. It's an edge case, but
it has to work.
chris: Yes, it would mean previously superscript character would
have to be rendered differently. But I'm not aware of anyone
doing it.
florian: I'm okay with this.
astearns: Obj to change to should in L3 and pushing for it in L4
fantasai: As long as it's clear you have to synthesize individual
super and sub script
chris: Yes.
RESOLVED: Change to 'should' in L3 and push for it in L4.
Request transition to Proposed Recommendation
---------------------------------------------
astearns: Last issue done. Test suite passes?
<chris> https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/filter/1/
chris: There's one non-passing test and that's [missed] and that
feature is only in L4. We are good to go.
astearns: Objections to request transition to proposed rec to fonts
L3?
fantasai: Looking at edits. Looks like they're not correct
<fantasai> https://github.com/w3c/csswg-drafts/commit/1a5b9bcb0a2aac317c08f95bb63d6158d22eb862
fantasai: ^ second switch from must to should shouldn't be changed
afaict
chris: Let me look
chris: You're correct. I'll fix.
fantasai: As long as that's fixed I'm fine.
astearns: Objections with that change?
florian: Do we have a report detailing the tests or jsut a statement
tests are fine? An impl report.
chris: Yeah. [missed] If you remove filter
<chris> https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/
astearns: chris put the link in IRC.
chris: There's 475 tests that pass from before.
fantasai: One more question.
fantasai: The 3rd change from must to should "In situations where
text decorations are only applied to runs of text
containing superscript or subscript glyphs, the
synthesized-glyphs should be used to avoid problems with
the placement of decorations." I'm trying to understand
what it's about. I think it's that font metrics for super
and sub script don't match actual glyphs and if you apply
text decoration it'll be misplaced if you use those
metrics. But in a proper font where the metrics match
correctly you don't want to synthesize you want to use
actual glyphs.
fantasai: I think that one should be a may. If the UA can detect
there won't be a problem it should ideally use
non-synthesized. I think it was incorrect as a must in the
first place
chris: Another thing when we get to this in L4 with optical sizing
the font itself can change its size. I want to re-open this
on fonts 4.
fantasai: Yeah, but I think go to a may in this level should be fine.
chris: Okay.
astearns: Anyone concerned?
astearns: Okay, let's do that.
astearns: Any additional changes?
astearns: With the two changes, objections to proposed rec for fonts
L3?
RESOLVED: Request transition to proposed rec for Fonts L3.
astearns: Congrats and thanks chris for the work getting the test
suite up to snuff and everything tidied away
<chris> welcome!
florian: Where are we with UI?
chris: [missed] Thursday
<chris> and waiting for your response florian on the other spec
Filter Effects
==============
Containing block of filter, plus effect when applied to the root
element
----------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933
<astearns> PR under discussion:
https://github.com/w3c/fxtf-drafts/pull/263/files
chrishtr: I believe we skipped this last week because dbaron wasn't
there. Is that correct?
astearns: It was because you weren't. If we have you and krit we can
discuss.
chrishtr: We resolved in same issue to make filter containing block
for all elements except when filter is on root. Reason for
carve out the exception is to avoid breaking fixed pos
elements
chrishtr: Example is applying an a11y filter on entire webpage and
you don't want that to break fixed pos, just be more
readable.
chrishtr: As currently stands root element is not the containing
block for fixed pos elements. Means scroll of the fixed
position element escapes the filter. Problem because in
general it doesn't really make sense to have clips and
scrolls escape filters because they can move pixels and it
becomes strange or impossible to impl.
chrishtr: I proposed that filter on the root gets applied after
scroll and clip but before scrollbars. Can still apply
filter to the whole page, but it will apply clip and
scroll correctly and scrollbar is on top.
chrishtr: Any feedback on this?
smfr: Sounds fine. I think that means the filter on the root
propagates to the canvas
chrishtr: Right, last week it was details of how it applies to the
canvas and this is making sure it pushes up to canvas and
not apply before scroll and clip.
bradk: Don't quite understand the scrollbar comment.
chrishtr: Only root scrollbars of the frame. Scrollbars of root
frame would never be able to be filtered
bradk: Why is that bad compared to other scrollbars?
bradk: Would it be good if I'm reversing screen?
chrishtr: In some use cases I don't think it is. Root of a UA thing
the web page should effect. Scrollbars in page are an
effect of the page. It's a gray area but makes sense to
carve out.
rbyers: No strong feeling, but seems odd.
chrishtr: Applies to iframes as well. If you had it on the root of
the iframe it wouldn't be filtered. I don't feel super
strongly but it seems good to not let content mess up the
root scrollbar of the page.
Rossen: I want to make sure I get proposal. Currently filters will
establish a stacking context as well as containing block and
being containing block for fixed pos?
chrishtr: Unless it's on the root of the page. Proposal is in
addition w/ apply filter after scroll and clip.
Rossen: Initial containing block in this case?
chrishtr: I don't think it's changed.
Rossen: Way we defined so far is this is the root containing block
which in your description...that's what confuses
me...currently if nothing becomes a containing block the
initial one will be the containing block. It's defined as it
being the root containing block. You're trying to reverse
that which means to me something above containing block or
I'm missing something.
chrishtr: I don't think this changes containing blocks, just order
in which things apply.
fantasai: I'm trying to understand what we're doing. Seems changes
are very aggressive and I don't understand why it's a good
thing. There's several things...first, we're making
anything with a filter be a containing block for abspos
and fixed pos elements. And the filter is fixed for
viewport in the same way as a background is fixed.
smfr: I don't think that's true.
smfr: It's only if filter is on the root.
fantasai: Yeah.
fantasai: So if I want a filter for the entire page and not this
weird layered thing I can't do that. But that seems what
I'd want most of the time. THe filter being a fixed thing
that doesn't move it re-filters every time I scroll and
the page could shimmer as I scroll. Seems weird
fantasai: Also don't understand why making it fixed pos containing
block. I think we did that for transforms because figuring
out static pos is confusing, but I don't know why doing
that for filters.
Rossen: And more confusing because if you have filters become
containing block for fixed pos and opacity for example is a
containing block but not for fixed. This whole thing is kind
of messy.
chrishtr: WG already resolved to make filter a containing block
except for on root.
krit: And it's in the spec.
chrishtr: This is an adjustment. 2nd, why should it be a containing
block: Because otherwise the drawing algorithm to the
screen is ill defined. Filter can move pixel and so can't
commute with a clip. There's also a performance reason
with compositing and GPU acceleration. That's one of the
main reasons transform is containing block.
fantasai: Does clipping clip abspos element whose ancestor is a
container?
chrishtr: Follows containing block chain. And that's the problem.
That's what leads to these obnoxious cases.
fantasai: I have an element with clip applied. Inside element there
is a child that's abspos and the containing block is an
ancestor of the element with clip. If I use overflow then
the abspos is not clipped. But if I use clip what happens?
<TabAtkins> <relpos><clip><abspos/></clip></relpos>
chrishtr: Then clip:rect will clip. Or clip-path
fantasai: But if I say overflow:hidden no clip?
chrishtr: Correct.
fantasai: Seems weird.
chrishtr: Containing block and overflow clip and scroll are weird
and unfortunate.
smfr: That's a fundamental design mistake with CSS.
chrishtr: And this discussion is a result of that. Making filter
containing block is one of a series of changes we need to
make it make sense.
fantasai: My view is when I'm applying a graphical effect to an
element I expect it to be everything in the element. Seems
odd at a higher level. Fixed pos being effected seems odd
to me. Seems weird that I want to apply a filter would
change layout.
chrishtr: Yep.
fantasai: Random set of properties that effect look of something in
a subtle way, but these ones effect layout.
chrishtr: Yep. Consequence that they apply to whole subtree but
containing block is defined elsewhere
smfr: How does this work with opacity?
chrishtr: It doesn't effect px so it can be special cased.
fantasai: Why can't filter apply to containing block chain and not
subtree? Wouldn't that solve it?
chrishtr: Leads to other problems. I wrote a bunch of design docs on
ideas like that and it's just really difficult to resolve
these issues. The containing block thing is different then
subtree for stacking context.
chrishtr: The WG resolved the thing on the containing block. Best
not to re-litigate.
Rossen: We resolve and revisit. So that we resolved doesn't mean we
can't rediscuss.
chrishtr: Okay.
astearns: On the other hand since the thing under discussion depends
on that resolution and is required for that previous
resolution we could resolve on this because it makes
current spec consistent and then revisit containing block
bit.
krit: Even then there's do we want entire page with filter or just
what's on the viewport. Has impact on things like blur.
chrishtr: If you want filter to apply to fixed pos descendants you
need to define how that works.
fantasai: And in a large part of cases without fixed pos it'll be
strange and unexpected.
fantasai: What kind of filters do people use? A whole bunch. Do you
expect recalc as you scroll? Page will shift as you
scroll. When I look at a page and it's a thing I expect it
to be a static thing that shifts under viewport. With a
filter it doesn't do that.
chrishtr: An invert filter. You won't be able to tell. Only a blur
where you can see. Blur is the problematic and is
ill-defined otherwise.
TabAtkins: For blur to do what you want fantasai you have to render
the entire page to a texture and then clip what's in your
viewport. That's untenable.
fantasai: That is what I'd expect.
TabAtkins: It's impossible to do in a reasonable way
fantasai: If you define root to not do that then authors who don't
want shimmer as you scroll they'll apply to the descendant
of the root and you're in the same place for perf.
smfr: It's important to try and define filter for the way you want
[missed]
chrishtr: Suppose you apply scroll after blur, what does that mean?
A filter is applied atomically to a texture. Then you have
two textures, one for fixed and one for not. For me it's
not perf, it also leads to simpler compositing algo.
fantasai: If I had fixed pos elements on my page and I decided to
blur the entire page I would expect that the entire page,
everything under fixed pos, would be blurred all at once.
If you're imaging viewport as a cutout in a cardboard and
the paper is under as you move the cardboard it's all
blurred. And the fixed position things on the cardboard I
would have applied the blur. If there was a red boarder at
the top of the footer it would bleed over the page.
fantasai: As an author that's what I would expect
chrishtr: The problem is fixed pos content isn't fully separated
because containing block and stacking context aren't
related. z index and interweave with rest of page.
krit: I'm not sure we're getting to a conclusion. Should we discuss
at Sydney F2F? I won't be there but maybe all parties
discussing.
chrishtr: I won't be there, but I'm okay with others talking at F2F.
smfr: I won't be there.
fantasai: I'd rather get common cases to work and if necessary
change how we do stacking rather then do something that's
not what people expect to preserve current rules of
stacking context.
smfr: Sounds like a complexification of the current rules not
simplification.
krit: Impl mostly do what spec says. It would be interweaved on the
page, not composited.
fantasai: I haven't looked at stacking context rules in details. Yes
they're interweaved, but how many pages do that? not many.
You can say if there's a filter on the root we don't
interweave anymore. Most pages won't see that but then you
can have the filters applied in the way authors would
expect.
astearns: I suggest we take discussion back to github and bring up
use cases. We've talked generally about kinds of pages
authors would want, but concrete examples would be
helpful. Of fixed pos and interweaving. Have those in mind
as we come to discuss again.
chrishtr: Okay
astearns: Thanks for taking us through this chrishtr. We'll come
back to this.
CSS Transforms
==============
Presentation attribute as start or end value of a CSS transition
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2684
krit: In SVG we have the transform attribute which is a presentation
attribute which means it contributes to css pipeline and we
can set a transform and it would interfere in hierarchy with
itself.
krit: If we have a transform with a list and define a transition on
the same element, should it take transform into account or
just ignore? I'm asking for ignore. 2 browsers do that and 2
take it into account.
<krit> https://codepen.io/krit/pen/XqvqyG?editors=1100
krit: codepen^
krit: You can see that there's a transform on the rect and a
transition in css. For webkit you see it transforms and then
transforms. Blink and Edge take the transform from the
transform attribute and then transition to the value.
krit: I'd like to ignore as that makes the most sense. So can a
transform attribute contribute as a start or end value?
krit: I'm asking for edge or blink behavior.
astearns: Concerns with standardizing on blink or edge?
smfr: Good to match other presentation attributes
<chris> LGTM
astearns: And there's a Mozilla comment saying it's because they
haven't made transform a presentation element yet.
RESOLVED: Use Edge behavior.
krit: Syntax and some transforms are different then on css. Example
is rotate which is 1 value in css, 3 in SVG.
krit: If we have a transition from a transform presentation
attribute with 3 value rotate to css, css would not
understand. Edge here ignores the origin so the element jumps
and then continues. Blink composes from one matrix to another.
krit: Webkit and FF ignore.
krit: Proposal would be to make this rotate with 3 values to a
matrix and do matrix decomposition
astearns: This is an edge case because 3 value isn't used much?
krit: Yes. Edge case because css does not have 3 value so it's not
often used.
smfr: Unfortunate that you fall back to matrix for something that's
a rotate...you'll never do rotate [missed] turning into rotate
translate
krit: You could change rotate to a rotate translate, but that could
be worse because it doesn't match any transform function. So
we'd still fallback
<TabAtkins> (I support the rotate(3-arg) being incompatible with
anything.)
krit: Proposal is if there's a rotate with 3 values and have a
transition it gets composed to a matrix and we have matrix
decomposition for a animation
smfr: No alternate proposal and I don't object. It's okay, it's just
that if author is trying to rotate we will fallback.
krit: Can we agree on matrix decomposition?
astearns: Objections to make this rotate with 3 values to a matrix
and do matrix decomposition.
<chris> ok I guess
RESOLVED: Make this rotate with 3 values transition to a matrix and
do matrix decomposition
The used value for border-box
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/999#issuecomment-391431901
krit: transform-box has a couple of defined boxes. Issue is we have
mapping defined for fill and stroke fallbacks. The mapping
between html and svg boxes it requests more values to
supported value of transform-box. border-box on svg falls back
to stroke-box but we don't have that exposed.
krit: Proposal is every fallback we define would also be definable
on transform. We'd add content-box and stroke-box.
smfr: Which spec will define the boxes?
krit: Each spec defines mapping.
fantasai: It would be fine to import the mapping to transform spec
as it's more mature then fill/stroke
krit: Currently transform and masking do what we defined for fill/
stroke. We're adding the keywords for the spec behavior so
users can spec directly.
astearns: Concerns with adding these values?
fantasai: sgtm
smfr: I think I'm okay with [missed]
astearns: Sounded like smfr if okay but is not sure transforms is
right place for definitions
fantasai: Not sure where else. I guess fill/stroke is fine, but it's
a very early-stage WD.
krit: That's why masking and transform already define it, but they
do it the same way.
astearns: Given things move in different velocities we may defer to
fill and stroke in a future transforms.
astearns: Objections to add these keywords to transform-box property?
RESOLVED: Add these keywords to transform-box property.
astearns: Thanks everyone and we'll talk next week. If you're not on
wiki for Houdini and CSS and you're coming, please add
yourself.
<fantasai> https://wiki.csswg.org/planning/sydney-2018
Received on Thursday, 21 June 2018 00:53:18 UTC