- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Jul 2019 20:29:25 -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.
=========================================
Writing Modes
-------------
- RESOLVED: Make this undefined in L3. Define interoperable behavior
in L4 and add tests to L4 test suite (Issue #4139: White
space collapsing/processing in text-combine horizontal).
- RESOLVED: Publish updated CR of Writing Modes L3
- RESOLVED: Republish Writing Modes L4
Resize-Observer
---------------
- There was not a resolution on issue #3554 (device-pixel-border-box
size) but the discussion helped those on the call understand
further the issue so that discussion can continue on GitHub.
- The need to to balance performance with being able to respond
to a repaint occurring.
- Conversation was converging on there needing to be a way to
know that it has been determined resize didn't happen so
other painting can proceed rather than just a notice that
resize did happen.
Text Decoration 3
-----------------
- RESOLVED: Update CR of text-decor L3
CSS Shapes
----------
- RESOLVED: Treat shape-image-threshold as an opacity prop and allow
percentages (Issue #4102)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0027.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Tantek Çelik
Benjamin De Cock
Elika Etemad
Simon Fraser
Jeff Gilbert
Chris Harrelson
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Thierry Michel
Florian Rivoal
Devin Rousso
Ken Russel
Dirk Schulze
Jen Simmons
Alan Stearns
Greg Whitworth
Regrets:
Dave Cramer
Melanie Richards
Scribe: dael
astearns: Any changes to the agenda before we start?
smfr: Number of people for resize, should we move earlier?
astearns: Let's move it to #2 on the agenda
astearns: device-pixel-border-box thing?
smfr: Yep
Writing Modes
=============
White space collapsing/processing in text-combine horizontal
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4139#issuecomment-513589921
fantasai: There was an issue on www-style on how we handle
whitespace at the beginning of a tate-chu-yoko (縦中横)
string where we want all text combined. Spaces within text
straightforward how it's for whitespace, but question on
start and end
fantasai: Makes sense handled same as if inline block. Collapsible
whitespace is collapsed away. Changes to make this
explicit. Currently say composition of text is as if
inline block. Makes it explicit whitespace collapses in
that manner.
<fantasai> https://github.com/w3c/csswg-drafts/commit/53a5349823a794923be057e29038e021f523451f
<fantasai> testcase
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%22%3EA%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3Etext%3C%2Fspan%3E%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3Etext%20%20%3C%2Fspan%3EB%3C%2Fp%3E
astearns: Matches impl except Safari. There's a safari engineer to
make the change?
fantasai: I haven't tested all impl. Safari engineer said it's
reasonable
<fantasai> Looks like Gecko would need changes to comply
Rossen: For the TR portion or writing modes?
fantasai: For L3
Rossen: Why make this behavior change that late?
florian: Clarification, not behavior change. Already said lay text
out as if inline block. Points out that that means you have
to handle whitespace at beginning and end in a specific way
Rossen: Proposing add a note
fantasai: Proposing add normative text
florian: It's clarification of existing text that says do layout as
inline block. It's phrased as normative that you're
supposed to layout as inline block which means do this
thing and pointing to css text
Rossen: What would be effect...reading to catch up on IRC. Listing
to fantasai and she was saying we will have to enter CR for
this?
florian: Already have to go through CR due to other changes. Since
there was some disagreement on what this meant we clarify
AmeliaBR: L3 and L4 are as CR we're republish CR anyways.
florian: As fantasai mentioned a safari engineer was willing to
change. afaict this does not match impl though it matches
spec
astearns: Rossen was asking process. We'd like L3 as fast as
possible. If we clarify we need to update test suite and
make sure we have enough impl passing. From process might
be easier to clarify in L4.
florian: L3 needs to republish anyway so no difference. In terms of
passing maybe. Given disagreement leaving it undefined for
now and clarify in L4 might make it easier for publications
fantasai: In at risk?
Rossen: Thought it was.
florian: All value is in L3. Automatic was at risk and removed.
Behavior wasn't at risk.
astearns: And putting this in L3 at risk if we take it out means
there's another publishing churn
florian: No, at risk you can remove without repub
astearns: True
florian: Need new CR due to other normative changes
astearns: Why is it necessary to put in L3 given L4 is the thing
we're working on. Clarifications in later modules is
appropriate
florian: Given L3 text is ambiguous if we want it in L4 we can
explicitly undefine in L3. Does that work for you fantasai?
fantasai: Seems fine
astearns: Proposal: Make this undefined in L3. Define interop
behavior in L4 and add tests to L4 test suite
<Rossen> sgtm
florian: I've written the tests
astearns: Excellent
astearns: Objections to make this undefined in L3. Define
interoperable behavior in L4 and add tests to L4 test suite
RESOLVED: Make this undefined in L3. Define interoperable behavior
in L4 and add tests to L4 test suite
Publication
-----------
florian: Only open issues on writing modes are expected to be
resolved editorially. Can we republish CR with other
changes and this resolution?
florian: Editorial can happen without patent wait. We have normative
edits so pushing those seems useful
astearns: sgtm
Rossen: List of editorial changes?
florian: It's open issues
<AmeliaBR> Changes already integrated in ED:
https://drafts.csswg.org/css-writing-modes-3/#changes-201805
<AmeliaBR> Open issues:
https://github.com/w3c/csswg-drafts/labels/css-writing-modes-3
Rossen: [missed] having test suite complied against the PR which was
the organized test suite. Have we changed version for retest?
florian: Implementation report I'm planning to update. Would like to
update on basis of CR. We have open issues fantasai thinks
will be editorial. Not proven. If are editorial we can roll
them in. I'm trying to update impl report from koji but
easier against CR
astearns: And against most recent CR is what will satisfy review
florian: And if we need changes it's easier to change something
scoped. A stake in the ground now would be helpful.
Rossen: It is disappointing to see it's been so long since we were
almost REC with so much work. We have another meeting in
Japan and I'm sure folks there will be interested in
progress. Doesn't sound like we're close to ready.
Rossen: This is quite disappointing to see we are where we are.
We're trying to get more and more into this spec which means
it'll take longer and longer and not focus on L4
florian: That's what I'm trying to do. Get to PR or know why we
can't so that we publish what we have resolved on and
update koji's report. Not sure we'll be at PR but updating
the report is the first step to know if we can.
Rossen: This is fantastic. Comments aren't toward you and I
appreciate the effort you put. We as a group are tending to
try and put more into L3 rather then get it out the door.
Your efforts are appreciated
astearns: Proposal is publish updated CR of Writing Modes L3
RESOLVED: publish updated CR of Writing Modes L3
astearns: Any other writing modes progress we can make?
Resize-Observer
===============
device-pixel-border-box size
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-513045449
chrishtr: I'm the one that added it to the agenda
chrishtr: Main thing is resolving that this is a good approach to
resolving responsive design for canvases.
chrishtr: Exact details of API can be followed up if agree on first
step
jeff: The main thing on figuring out how this works is when we're
thinking about scheduling we get a request at beginning of
frame so can render WebGL
jeff: Then main thing is take stock of width and height and that's
usually when resize happens. I understand resize is only later
after RAF when browser thinks we can take current layout
jeff: Then resize observer kicks off events and says to canvas
you're resized. Issues for WebGL is that time is non-trivial.
Late in the frame is hard to respond. You can realize in time
for end of frame you rendered wrong and can do minor fix but
can't render at new resize if observer after RAF
chrishtr: Design of resize observer is to support this responsive
design where decentralized action causes layout to change.
If resize observer callback thinks sized changed
non-canvas can change internal layout. If there's change
it causes another layout. non-canvas the frame is twice as
long and I think that's unavoidable.
chrishtr: Key is resizes are uncommon and it's only when user
changes browser or orientation. Could be doing layout
animation but one that changes layout in every frame is
perf problem
chrishtr: For webGL canvas it is an unavoidable slowdown
gregwhitworth: Is your issue that you may potentially miss a frame
due to asynchronous nature?
jeff: yeah
gregwhitworth: In current state you're sync. Feels you prefer have a
performance thing where effecting frame vs the inverse
jeff: Not clear. If you rely on resize to tell you size and can't
correct ahead of time it's hard to from the get go render
frame with proper size
dbaron: Almost think for this use case resize-observer feels like
wrong thing due to structure. Request animation frame was
designed as a callback where can write layout information.
dbaron: One of the problems here is that RAF, you get a RAF [echo
issues]
dbaron: RAF is early in cycle and you can do it before layout.
Layout as result of resize is after RAF. Some things people
do will flush layout anyway and may layout twice. What you
want here is to know canvas size and then do WebGL stuff
dbaron: If you want to know size of canvas can do resize-observer
but it's designed to not flush layout and you might not need
changes. In your use case you want to know this is the new
size of box after layout this cycle. Way you do that is use
a sync method that flushes layout. Assuming 1 canvas
dbaron: What works for this use case is late in the RAF you get
width and height of canvas, do WebGL work, don't use
resize-observer. You did minimum layout and get new canvas
size
jeff: That's what I've been centering on the solution for the common
case. Where it gets muddy is part of the goal is
device-pixel-border-box size. This is predominantly useful for
canvas and WebGL.
jeff: A big chunk of WebGL cases will have this workflow and not
want resize-observer to get late resizes. Want the early
layout to get box sizes.
jeff: What we'd be lacking is a way to sync query the
device-pixel-border-box
jeff: Right now can get bounding client rects but it's not device
pixel. That's what we want for WebGL.
jeff: Sounds like what we want is a a getBoundingDeviceRects or
something sync to get pixel size. Then resize-observer is
helpful for the other use cases. WebGL where they flush layout
uses this other command
chrishtr: Two things wrong about your description dbaron.
Resize-observer is not async. Delivered immediately and
cause another layout on same frame. Second is you can't
actually know size of WebGL canvas even if you calls a
sync method because there can be a different callback
registered by someone else that dirties layout.
chrishtr: Can't do it the way you desc
dbaron: Those are fixable.
dbaron: Problem with resize-observer is jeff's use case is a
notification every time, not just resize.
dbaron: There's tricks to put yourself after next RAF. There's
always problem of multi-observers.
dbaron: I think fundamentally people want to do different things.
This property makes a set of data only available in
resize-observer but not in other ways and I don't think we
want to put to use only resize-observer and other solutions
chrishtr: Good to only provide right information in right spot
dbaron: Think it's the wrong spot
ken: resize-observer solves a lot of problems. Fantastic all
browsers are implementing v0 so that we can encourage everyone
to use that. We'd like to recommend just use
device-pixel-border-box if they want it exactly correct.
Synchronous APIs have a host of problems like going to while
loops to make layout settle down. resize-observer callback
solves problems
jeff: It does, but it has remaining problems. If WebGL content wants
to render...there's no way to deterministically always try and
render correct frame size and not occasionally double-paint
ken: I see that. The live resizing case is vanishingly small. You're
moving a handle on the webcase. In the steady state you'll
render normally. If you end up double painting during live
resize not end of world
Rossen: A little under statement. Let's not diminish value of
resizing and only put it in a corner. I can see multi frame
being in same overall app layout each with own observer and
then the drawback will be magnified. Let's not diminish
effect of this
<bkardell> if it was really only based on the size of the window,
this feature wouldn't be necessary
emilio: Did we figure out...what this device wants to add is a
snapped rect. We figured for some combo of transforms that
can create non-rect we also need to do transform calcs to
get right device snap rect
emilio: It stashes a bunch of paint information onto an API. Want a
reminder of what the web repercussions of that discussion
were
gregwhitworth: Talked about that at SanFran F2F. Most people thought
okay because scope was to canvas. Use case for canvas
we won't have transforms and those types of scales so
we don't need to go that far down stack. I think
chrishtr said they are doing that. You are stashing,
but primary case is you want pixel snapping because
we're WebGL and want draw to pixel snapping and want
to know about resize to get perfect frame
gregwhitworth: Not opposed to dbaron where we can't do this anywhere
else. But in this specific case where the resize gets
a less clean seam and it's only on resize
gregwhitworth: To your point you have to shove painting knowledge
into it. And you don't have all information.
chrishtr: I think transforms shouldn't apply at all
chrishtr: Exact definition or impl of pixel thing is different then
other discussion. even if want to do something to instruct
dev to always resize at beginning of frame you can't get
bounding rect and multiple by pixel. Needs to be fixed or
canvas can't render
jeff: Can do work to estimate eventual pixel boundaries. I'm told
people who know pixel snapping rules find it sketchy because
rules aren't defined and we'd have to guess. Need a library
that sniffs for UAs and gets right rules.
<gregwhitworth> they're not defined and vary by UA
chrishtr: That's something where it's not going to be a great
solution. Dev will hack around and that's not good
smfr: Remind people not all UA have pixel snapping before paint. We
don't know before we go to paint. Even if added the device
pixel we'd have to do a fake paint. That's non-trivial for WK.
And makes forced layout be even more expensive and they're
already a source of perf issues. Hesitant to add an API that
makes fake paints
jeff: Maybe alternative for WebGL use case is if there were a
callback following RAF like resize-observer but happens as
early in the frame as possible and deterministically every
frame might be more workable if people object to a sync call
for pixel layout
jeff: Solves double paints, gives webGL a way to know this is final
size as long as nothing else changes it. As long as nothing
else changes it is a problem we can't ever get around. might
be the way forward there.
<smfr> https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering
smfr: HTML 5 has rendering steps. Where in those would callback fire?
jeff: I don't know
dbaron: Not sure I believe rendering steps in HTML5 make sense. I
have an open issue to fix some of it.
dbaron: I support basic idea from Jeff. I think there's a similar
Google proposal. Requires people have separate callbacks to
separate writing layout and reading layout. In a refresh you
want all writing before all reading
smfr: Good idea except APIs we have make it easy to do wrong things.
That only works is everyone does reading and writing at same
time. Need a whole new set of DOM APIs that read without
forcing layout
dbaron: resize-observer feels designed for this, but it's a very
particular solution
chrishtr: It's providing a responsive decentralized layout at one
time.
chrishtr: What you described about post layout callback if you have
arbitrary code running it dirties layout
jeff: Not solvable
chrishtr: Resize-observer solves it. If you dirty layout should you
layout again? If yes it's same as resize-observer.
jeff: Keep in mind my objections to have resize-observer isn't
determinatively fired. If we're trying to solve WebGL problem
here, the solution shouldn't be half baked. There are problems
with as exists resize-observer.
jeff: Main problem is we can't hit our frame times if we get
resize-observer late. Solutions are sync call or get
device-pixel size and other is a resize call that always
happens early in the frame. That solves WebGL problem.
jeff: Getting confident WebGL problem isn't solved by current PR
ken: Using resize-observer is simpler to explain. It gets 80-90% to
solution. I realize poss of duplicate renders but that
resize-observer takes into account re-layouts that may happen
is I think good design. I would advocate adding
device-pixel-border-box to resize observer API as a pretty good
solution. We can iterate on it in the future to maybe get
layout earlier and less change of duplicate frames
jeff: I have an 80% solution in hand already
ken: But it doesn't implement the real pixel snapping the browsers
do. Need access at app level
jeff: But my JS hack sounds like a better solution then the API
chrishtr: I don't think that's true. resize-observer 100% solves get
size of canvas
jeff: Do you think my recommendation to have deterministic frame
that says we finished layout is unworkable.
gregwhitworth: That's what it does.
jeff: But we can't hit frame times because takes 12ms
dbaron: jeff wants a notification if it does or doesn't change size.
For resize-observer when you register a new one do you
always get one notification?
<bkardell> you always get 1 yes
??: Yeah
dbaron: What happens if you re-register resize observer every frame?
Does that solve?
jeff: Depends how early it fires. Is it designed to fire as soon as
possible?
gregwhitworth: Following layout for as accurate as poss. To get
pixel snapping need to get into paint. I don't
understand as early as possible, has to be late to
understand layout
dbaron: Wants it before he does WebGL painting to canvas
gregwhitworth: Which is fine if not respond to resize. That's what
RAF does now
dbaron: What Jeff wants is to do layout, know what size results, and
then paint to canvas
gregwhitworth: It's a callback to say hey we changed
dbaron: He wants to paint when no resize too
<tantek> sounds like maybe you want to both register a RO and a RAF
callback, RO for the first notification, and RAF for
no-resize notifications, and RO when there is an actual
resize
<tantek> painting when no resize is what RAF is for right?
<gregwhitworth> tantek: that's my confusion
<gregwhitworth> if you don't want resize calls you add it to RAF
<gregwhitworth> and what chrishtr just said if you want both
chrishtr: You're describing a post-layout animation callback which
doesn't exist. One objection is it gets in the way of
running layout off main thread. resize probably has same
problem
chrishtr: Can get same thing except potentially slower during resize
with resize-observer but need request animation callback
as well.
astearns: Nearly at time. I don't think we will resolve today, but
good to have back and forth
astearns: Interesting to have fuller proposal for the post layout
callback. I think should continue in GH and come back.
many people: thanks
<tantek> jeff, does that solve your use-case? using *both* RO and
RAF?
Text Decoration 3
=================
Update CR for text-decor L3
---------------------------
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2019JulSep/0024.html
fantasai: Just call for resolution. Fairly minor, listed in email ^
astearns: Update CR of text-decor L3
<tantek> +1
astearns: Objections?
RESOLVED: Update CR of text-decor L3
CSS Text and CSS Sizing
=======================
When to/not to include preserved trailing spaces
------------------------------------------------
florian: Can't cover, but would like koji to look at this issue.
Once he has we can resolve.
CSS Shapes
==========
Accept percentage for shape-image-threshold
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4102
emilio: Recently gecko added alpha value syntax.
shape-image-threshold takes an alpha makes sense
astearns: Makes sense to me. Any concerns?
astearns: Proposal: Treat shape-image-threshold as an opacity prop
and allow %
RESOLVED: Treat shape-image-threshold as an opacity prop and allow
percentages
Writing Modes
=============
Writing Modes L4 Publication
----------------------------
astearns: Also CR?
fantasai: Yes
astearns: Will include changes discussed this call?
fantasai: Yeah
<tantek> +1
astearns: Objections to Republish Writing Modes L4?
RESOLVED: Republish Writing Modes L4
astearns: Thanks everyone for calling it
Received on Thursday, 25 July 2019 00:30:19 UTC