- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Apr 2021 19:41:19 -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.
=========================================
Scoping
-------
- @scope work will be done in the next level of CSS scoping; miriam
will be added as an editor
CSS Display
-----------
- RESOLVED: Have display:math behave as mrow and ping a11y to see if
that's an issue (Issue #5388: math/inline-math (whether
display:math on a non-MathML context should be more
inline or block))
- RESOLVED: We are interested in defining all the math display types
necessary for MathML layout to not be element-dependent
(Issue #5866: MathML individual display types)
- There were three possible paths forward in handling
<display-legacy> parsing (Issue #5575: Should <display-legacy>
values be aliased at parse time?):
1) Alias at parse time
2) Define the new and old values as 2 independent values with
same behavior so they always parse differently
3) Do in between where some APIs return old and some return new
if you specify new values
- Most of the debate was between options 1 and 3:
- Those arguing for option 1 believed it would be the easiest
for authors to understand.
- The argument for option 3 is it allows newer APIs to return
the new values but prevents changing the return of older
APIs when a new value is used. This would prevent breakage
when using scripts that do not accept the new values.
- More data about possible breakage will be added to the issue in
order to further conversation.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Apr/0000.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
David Baron
Christian Biesinger
Mike Bremford
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Sanket Joshi
Brad Kemper
Jonathan Kew
Chris Lilley
Peter Linss
Alison Maher
Tess O'Connor
Morgan Reschenberg
Florian Rivoal
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Greg Whitworth
Scribe: dael
astearns: We're a little light but should start
astearns: Welcome felipeerias, thanks for joining
astearns: One change to the agenda, scrollbar topics, 6 & 7, will
postpone to next week
astearns: Any other changes people would like to suggest?
CSS Scoping
===========
astearns: Housekeeping- miriam reminded me we had resolved to start
work on the scoping proposal and to write spec text
astearns: Didn't decide where it should go. New draft? In a present
draft? Thoughts?
fantasai: @scope?
TabAtkins: Yeah. I think in scoping spec
fantasai: Or cascade 6. Might fit better there
TabAtkins: I don't think I agree. It's not directly about cascade
fantasai: About specificity and which elements something applies to.
People think in context of cascade and not in
terms...scoping is all about shadow dom
TabAtkins: Didn't used to be. I think confusing if scope rule not in
scoping spec
fantasai: Fair. Then scoping next level
TabAtkins: Fine with it in current level. Nothing pressing to
scoping pass cr
fantasai: I'm not. I think what's in scoping is a lot more solid.
Want a line between super experimental
astearns: Does scoping need update anyway?
fantasai: Yep. And it's mainly shadow dom which should be in cr
astearns: Argument to put in current so we have better chance to
publish
fantasai: @scope rule should be newer draft. Current level should go
to CR soon, and if there's anything blocking that we
should be working on it. We can always pub a FPWD of
anything we want
astearns: Proposal is add miriam as editor to next level of CSS
Scoping and have them work up spec text in an ED which
will become FPWD
astearns: Sound good?
miriam: Sounds great
CSS Display
===========
math/inline-math (whether display:math on a non-MathML context should
be more inline or block)
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5385
astearns: Has been waiting on math people to weigh in. afaict all we
need to deal with is display:math on non-MathML
fantasai: Decided it should be inline
fantasai: Issue from Mozilla is having it behave different if in
MathML context or not is not great. Not difficult to impl
but more tricky because context sensitive. Not necessary
for any reason.
fantasai: Mats asked for it to behave like mrow regardless of if on
math element or not
emilio: And discussion of if need >1. Supposed to be magic depending
on element. If not might need more than one
florian: Assume behavior of making it an math which doesn't contain
math is well defined?
iank: Yeah, triggers mrow layout algorithm
iank: In simple terms layout things on a row and I think baseline
align all
iank: I think MathML defines internal types fine. Sometimes mrow if
it has more children than expected.
iank: I think not having talked to the MathML people I think I am
supportive of adding each display type as FF folks suggest.
Seems consistent with everything else. Would like to hear
other thoughts.
iank: Also works with polyfill story
fantasai: Two issues. One is display:math outside mathML is mrow
behavior. Second is add more display types per mathML
element
plinss: I think we have precedent to just rely on display property.
I would like to see all math in layout not rely on semantics
plinss: Have it default style
iank: If you put display:grid on mrow it has an internal layout type
of grid algorithm. Have consistency there
florian: Do we need to check with a11y people, a11y tree, to see if
the way the build right now will break? My understanding is
for some things they build from box rather than element
tree. We should check. I don't know
florian: We've been accused of being careless about this in the past
florian: I hope it doesn't. In theory I support plinss
plinss: Agree worth investigating. Might justify a bug on AT. We can
evaluate when we find out answers
astearns: Sounding like consensus to have display:math always behave
as mrow
fantasai: Outside MathML context and unless otherwise specified
astearns: Proposal: have display:math behave as mrow and ping a11y
to see if that's an issue
RESOLVED: Have display:math behave as mrow and ping a11y to see if
that's an issue
astearns: Separate issue for other math display types?
fantasai: I believe there is
MathML individual display types
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5866
astearns: Is there consensus to resolve that now or postpone to
future meeting?
iank: I would like to ask people more familiar with MathML
iank: Does seem like consensus in this group
astearns: Dim recollection is mathML asked for the display types and
Igalia folks thought it too many
iank: My recollection too.
astearns: Math WG just spun up. Maybe we can ping them on this
astearns: I'll take an action to send this along
plinss: I'm in favor of more display types. Maybe not 100, but 2 or
3 with other properties to control sub-behaviors. Early
design philosophy in Gecko. I don't want layout and design
tied to semantics. I want it all in css
iank: Quite probably quite a few, 5 or 6. Makes sense because
distinct layout algorithms.
<bradk> These would be display-inside?
<fantasai> bradk, some of them might be more like internal table
display types, have to check
<bradk> @fantasai I see. Thanks
florian: Are these things only useful in context of math? Or are
they potentially useful in general? In favor either way
plinss: If we give tools people will have create ways to use them.
People will find fun ways to display content we didn't dream
of
iank: mtable has display:table and display:tablecell so this
normalizes to that behavior.
iank: display:mrow there might be. We should give that power
<florian> +1
emilio: Agree. If we want to style math with css using display we
have to do all or none. SVG does no such thing, it's its own
box type. I like the direction of exposing all MathML
display types
astearns: This will go into issue. I'll ping the new math WG and
come back
fantasai: I'd like to propose we take a resolution. csswg believes
this is the right direction to go and we propose that to
math wg. Useful to capture we're on the same page
astearns: Unless anybody has reservations?
astearns: Proposal: We are interested in defining all the math
display types necessary for MathML layout
astearns: as individual display types or separate properties in css
that let us control the variations
RESOLVED: We are interested in defining all the math display types
necessary for MathML layout to not be element-dependent
Discussion about the block cross-folding screen
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5882
fantasai: I had brought this up. It looks like need discussion. I
don't have a proposal. I think I proposed for F2F
astearns: Yeah, even for virtual F2F we need something to go on
astearns: By my reading this is about what to do with text elements
since we do have split and mask capabilities for images
fantasai: No, screen folding. Different ways to handle the effect.
One is where you move the boxes apart. Another is mask so
stuff appears. Need to expose to author so they don't put
content inside the fold
fantasai: If impl creates a gap and cutting content, need no content
in gap. When there's masking there is content in the gap
and author needs to know. Need to make adaptable so author
can layout. Means conveying information.
astearns: I don't see MS people on call who are working on this stuff
astearns: Maybe we kick back to issue
fantasai: Yeah, needs a proposal
Should <display-legacy> values be aliased at parse time?
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5575
fantasai: Question of if new display types, we have things like
inline-block. Now that we have separate keywords we have
inline-display-flow-root is same as inline-block. Defined
as same. When you do getComputedStyle wanted to return
inline-block because shortest serialization
fantasai: Should this be handled at parse time. I think no, author
should get what they specify. I think rachelandrew and
others have had value in talking as outer and inner
display type. If we merge in APIs harder to conceptualize
emilio: Much easier to do at parse time for impl. Don't feel super
strong. Seems unfortunate display won't compute as
specified, but I guess okay
oriol: While FF does at specify value time, chromium does this for
combinations and they are considered to be different. It
preserves specified keywords
florian: emilio, does it make it awkward for impl long term
complexity or just when you write
emilio: Probably fine. Once it computes it's okay. oriol your
comment is slightly different. inline-math should be just
math.
fantasai: Agree with emilio that's a different concern
oriol: Then it should be different if eq possibility one is legacy
css2 and other is new?
emilio: That's why I prefer just alias at parse time. Each has a
serialization and you're done
emilio: A bit unfortunate that you say inline-flow-root and get back
inline-block. But that's what you get in the computed styles
fantasai: I propose we continue to define newer values as computing
to legacy keywords but not process any earlier
emilio: That's more complicated. New thing to old thing. Ideally
want other way around
emilio: So you just worry about inner and outer display value
fantasai: You want to compute to the new ones but resolved is older?
emilio: Serialize as the [missed].
fantasai: Reasonable that resolved value for getComputedStyle is
legacy. Need that for compat.
emilio: That does change the behavior of the Houdini APIs.
emilio: We probably don't mind
emilio: If we want computed style map to return the new thing and
then resolve into the keyword is the way to go
emilio: Sooner you alias the better
fantasai: From author PoV system is easier to understand with 2
value keyword. If it's just a parse time alias that's
helpful but could get a bit confusing. If we can get away
with it being 2 keyword values in Houdini that's reasonable
emilio: Then what does specified style do? 3 values we expose; spec,
computed, resolved
emilio: What Gecko impl is computed and resolved are same, serialize
legacy
emilio: Moving the legacy thing to computational stage...that's okay
but we also change behavior of Houdini API
emilio: More work to basically keep the new values in the specified
style, return old in computed, return new in Houdini. You're
uncomputing what you computed. Fine. A bit more annoying
fantasai: TabAtkins or rachelandrew?
emilio: If we can get away with keeping parse time alias. Serialize
to legacy. I don't know
emilio: Prefer if each combo had single serialization. Only
getComputedStyle exposes legacy. But that's breaking change
for specified.
emilio: Maybe only Houdini exposes new
TabAtkins: No opinion either way
astearns: Other opinions?
rachelandrew: I think as fantasai said from author PoV the two
values are understandable and confusing if you get
back something other than expected.
rachelandrew: Prefer we keep the 2 value all the way through if
that's possible
emilio: That's another proposal. May be okay. But inline-block and
inline-flow-root compute to different thigns but behave same
iank: I feel like serialization should go to legacy if they can
iank: Worried about the web compat here
emilio: Right. If you keep as specified it's nice if you're in
control. But you prevent adoption. If you use jquery and it
expects a return of inline-block and it starts returning
inline-flow-root because you used it in your style sheet,
you can't use it because scripts break
fantasai: That's an argument to not introduce new display types
fantasai: It's a new display type with same behavior. If your
scripts break it's a problem with your script
emilio: Perhaps. But you cannot say in our css codebase we'll only
use new display types because they break stuff.
emilio: I don't have super strong opinion. Can implement whatever.
Least complex is parse time
<jensimmons> I'm a bit lost. I'd love for us to compute to the new
syntax. Get the world of Authors to move on.
iank: I think I'm with emilio. From maintenance PoV and being a
previous webdev this would be somewhat concerning. You don't
always controls what people are setting display types to.
astearns: Resolve these return most backwards compat serialization
except houdini and houdini has 2 value?
iank: You mean typedOM API?
astearns: Yep
emilio: Should be fine
emilio: Should also be fine to match computed style either way. As
long as same value serializes to the same thing it's fine.
Backwards compat trumps. Up to chrome if they want existing
users of inline-grid to have breaking change
jensimmons: I understand if there's a compat problem, but I would
love to see us for sake of authors compute and return
new syntax. I'd love to be able to teach new syntax.
Thinking about where will we be 5 years from now. Having
to continually teach the old syntax and why? Always a
fan of clear the decks and move forward
jensimmons: I think new display values with 2 parts are so elegant,
don't want the old to stick around
astearns: Which is why I want new to return the 2 value. But we
serialize to least backwards compat for a reason
fantasai: Could decide this is new independent value. Has same
behavior but don't compute to each other. We've got 3
possible options:
fantasai: 1) Alias at parse time.
fantasai: 2) 2 independent values with same behavior
fantasai: 3) Do in between where some APIs return old and some
return new if you specify new
fantasai: Seems first 2 are most elegant. For sake of authors I vote
1 with jensimmons and rachelandrew
<miriam> +1
emilio: I'm okay with saying that. Basically question is how much
work does adopting this become. Script authors need to care
about both values. That's great for authors of css but not
great for authors of script
iank: With emilio. I don't think this is great to go down for script
dev that queries style
astearns: Yeah, if we go with independent values it could slow
adoption because not compat
fantasai: I'm not convinced it would be compat problem
iank: From what I've seen on getComputedStyle and display I think
there's a significant chance of people accidentally breaking
and not realizing it
astearns: Option 3 would not be alias at parse time because need to
preserve values for TypedOM?
<bradk> I’m also leaning towards option 3
fantasai: Can't do it at parse. Variations on option 3. One would be
2 independent values but have getComputedStyle do an extra
computation to return old version. We do all kinds of
extra lift for getComputedStyle.
astearns: Do people have objections to the version 3?
fremy: Small question based on minutes. Why can't we do option 3 at
parse time? I don't understand. They're exactly the same.
inline-block will always be same 2 values in Houdini.
fremy: I have one serialization for getComputedStyle. You always
have 2 value in Houdini. Never get 2
emilio: That how we impl it probably. Have same value but serialize
differently for TypedOM
fantasai: If you put something in specified style do you get 2 value
or 1?
emilio: Legacy serialization
fantasai: .style.display do I get inline-block?
emilio: You would get inline-block
fantasai: What's point of having weird in typed OM?
emilio: It's the one place where we can not go to legacy
emilio: You have issue of script authors having to care about both
values if you don't
fantasai: But if you do inline-list-item they need to handle. We
keep adding display values
fantasai: We add them all the time. If script doesn't handle new you
have to tell the person that my script only handles the
old ones. If you're putting limits on script you have to
negotiate with user. I don't see why this is a particular
problem
emilio: There's a lot of code that won't update
fantasai: Sure, and when using them don't use new things
emilio: Problem is, people are not going to be able to use new
display values. Moving backwards compat from browser to
author. That's fine
florian: Seems we have same problem in many areas. Script for colors
there's may ways to spec red. They all look the same. But
we don't serialize LAB space back
emilio: Take all hsl and serialize as rgb for that reason
<TabAtkins> Note that we *only* serialize the older color forms to
rgb(). Newer forms, even ones that are absolutely
equivalent to rgb(), stay as they are.
astearns: Not hearing consensus
astearns: Does anyone want to try coming up with something we agree
on?
emilio: Won't object if we serialize the new thing, but I don't
think it's best
astearns: iank you had concerns?
iank: I don't think it's the way we should go
astearns: And others don't think we should be cutting off new
display types at serialization time
astearns: Any way we can get evidence of compat problem?
fantasai: TabAtkins points out [reads IRC] so to bring florian's
question back, why do you think this applies to display
and not color
TabAtkins: We have new color forms that are equivalent to rgb but
don't serialize. We color turn color into rgb but want to
keep in same form. Only older turn into rgb.
emilio: I have same concern. It's common for script to just parse
rgba output
iank: With color example there are scripts that will add a11y
dynamically and insert a color. I had similar concerns there
iank: I think less bad because breakage is more minor in that case.
There's a lot of scripts that will check if display is
inline-block do something
fremy: Talking about inline-style or getComputedStyle? I think
getComputedStyle everything is rgb serialization
chris: Thing about rgba is the spec says regardless of how you spec,
rgb or rgba, rgb can get an alpha, but if it's 1 it's thrown
out. Only reported if not 1
chris: Clarifying
<chris> Serialization of rgb() or rgba() only reports non-unity alpha
leaverou: Comment about scripts that parse rgba, that ship sailed.
Not every color can be rgba so scripts need to support
other forms. Shouldn't be a concern. With typed OM
hopefully devs wouldn't parse colors manually anymore
astearns: I think color discussion is a little far afield. Scripts
dealing with display values. I would hope scripts with
display values would have an i don't know what this is
default.
<chris> Sure, people seemed to be arguing by analogy though so I
wanted to be sure the analogy was accurate
florian: I think we need data for compat argument. If we show up we
can say doing serialization might break things. In theory
all sorts of things could break. Do they?
fremy: We have a rule of serializing to old if we can, I don't think
we need to prove every instance that there is web compat, we
can safely assume there is and not break things for the sake
of it.
florian: At computed time, yes. Not at specified
emilio: Isn't that general serialization rule?
florian: I don't think so. Am I wrong?
fantasai: When defined to be equal, we do. If defined to equivalent.
It will serialize to shortest. Debate is do we define to
be same at computed or specified value time.
fantasai: One proposal is they're distinct and different. We do that
in other places. We have places in css with same behavior
but serialize independent
iank: Quick search, jquery uses this. Likely some cases will break
astearns: Can you put references in issue iank?
iank: Not exhaustive. Just a litmus test
astearns: Nearly out of time. I suggest iank puts his in the issue.
Others search and add to the issue. We can see what would
break and come back at a later date
astearns: Sound alright?
astearns: Thanks everyone for calling in and we'll talk next week
Received on Wednesday, 14 April 2021 23:42:01 UTC