- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Aug 2020 06:25:54 -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 Cascade & CSS Scoping
-------------------------
- RESOLVED: Shift shadow dom cascade to cascade 4, remove scoping
from cascade 4, move cascade 4 to WD and republish
(Issue #5372: Define Shadow Tree in Cascade)
CSS Color Adjust
----------------
- RESOLVED: Make forced-color-adjust not animatable (Issue #5342:
Animation type of forced-color-adjust)
CSS Sizing
----------
- RESOLVED: Non-0 height as a result of aspect-ratio disables margin
collapsing between top and bottom (Issue #5328: Should
we mention aspect-ratio in margin collapsing?)
- Discussion will continue on issue #5328 about how to handle margin
collapsing when the height is 0.
Background 4
------------
- There's still some questions on expected behavior for issue #3949
(Switch to opt into transparent canvas for additive displays) so
discussion will continue on github.
CSS Text
--------
- fantasai will draft proposed spec text for the group to review
which will state that text-transform being a CSS property is not
intended to convey semantics. If you're using an accessibility
API it may take aspects of presentation into account but
text-transform should not be used for semantics. (Issue #3775:
text-transform's design, intent and reality resolution)
Pseudo Elements
---------------
- The group explored adding a ::punctuation pseudo class in order to
handle the need to style punctuation differently when it's in a
::first-letter (Issue #2040: Problems with styling
::first-letter with punctuation).
- If going with this approach it would be scoped to tree-abiding
punctuation.
- There is a need to be able to style the punctuation before the
first letter differently than after the first letter so this
proposal will need to be able to select between before and
after. People were okay with scoping so being able to do a
different style for two punctuation marks before the letter
would be out of scope.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Aug/0003.html
Present:
Rossen Atanassov
Amelia Bellamy-Royds
Elika Etemad
Daniel Holbert
Dael Jackson
Dean Jackson
Brian Kardell
Ian Kilpatrick
Peter Linss
Alison Maher
Myles Maxfield
Cameron McCormack
Florian Rivoal
Devin Rousso
Alan Stearns
Miriam Suzanne
Greg Whitworth
Regrets:
Christian Biesinger
Mike Bremford
Simon Fraser
Megan Gardner
Scribe: dael
Rossen: As usual, any additional agenda items or anything we need to
change?
Rossen: One question about this agenda, do we know if jcraig or
other Apple a11y folks will join?
myles: They will be available next week
Rossen: Perfect, thanks.
CSS Cascade & CSS Scoping
=========================
Define Shadow Tree in Cascade
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/5372
fantasai: Noticing they're defined in scoping spec. I think we
should import into cascade spec
fantasai: This would be normative because moving between specs but
no effect on impl.
fantasai: Assuming we do it correctly ^-^
Rossen: Any thoughts about this?
Rossen: Any reasons why not?
AmeliaBR: Spec statuses?
fantasai: Scoping is WD. Cascade 4 which I think is where we should
put it is CR
fantasai: Might consider pulling it to WD, adding this section,
removing scoping which I think no one implements. If we do
that only difference from L3 is revert keyword
fantasai: Process-wise maybe that's safest way to go since seems to
be where impl have landed
AmeliaBR: More shuffling than just this but end result is version of
cascade 4 with impl features?
fantasai: That's my proposal. Broader than issue scope but makes the
most sense
fantasai: Assuming no one impl scoping
florian: If we remove scoping it changes style attributes. We should
go back and define them in terms of specificity again.
fantasai: I think that's part of edits
fantasai: Proposal: Shift shadow dom cascade to cascade 4, removing
scoping from cascade 4, move cascade 4 to WD and republish
Rossen: Sounds like fine orchestration
Rossen: Objections?
RESOLVED: Shift shadow dom cascade to cascade 4, remove scoping from
cascade 4, move cascade 4 to WD and republish
fantasai: When we have cascade 5 we'll put scoping in that. I'll
leave 5 as ED with just scoping for now
CSS Color Adjust
================
Animation type of forced-color-adjust
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5342
Rossen: Raised by anders, not sure if he's on
iank: Middle of the night for them
AmeliaBR: I think it's straight forward
Rossen: Curious if we needed to ask their input
fantasai: Summary: In general we allow pretty much any property to
be animated. A couple we don't because have particular
impacts on cascade or animations. Direction and writing
mode are not because cascade-time interactions.
fantasai: forced-color-adjust also has cascade implications so
proposal is mark as not animatable. I don't know of a use
case for animatable so should be fine
AmeliaBR: Agree, not worth complexity
<florian> +1
Rossen: Yeah. We've never seen use case for it
Rossen: Any reasons why we should make it animatable? If not
objections?
myles: Surprised at reasoning for it being more complicated to not
animate. This is a good fit for switch halfway through
AmeliaBR: Getting special rules for lots of other properties like
background color is doing thing based on if you have
forced-color-adjust on. Not a simple dependency like
currentColor, lots of rules for other properties
fantasai: If there's an implementor that thinks this should be not
animatable we should make it not animatable. If all
implementors think it should animate then leave it.
Rossen: Dependency change is pretty complex here. Since we have had
this feature previously in high contrast adjust name this
has never been requested for animation. No signals
historically and complexity high. That is the reason not to
add additional complexity into the system.
Rossen: Does that satisfy myles or do you have other things to
consider?
myles: Nothing more to say
Rossen: Objections?
RESOLVED: Make forced-color-adjust not animatable
AmeliaBR: Follow up. Not sure how it works for animating other
properties like color and having a transition on it based
on if forced-color-adjust turns on it changes computed
value of other properties. Don't know what to expect but
need to define
florian: Some other properties that might not want to animate when
forced-color-adjust on?
AmeliaBR: If forced-color-adjust turns on it changes computed value
of many other properties. If those other properties have
transitions should they trigger?
florian: Understood.
fantasai: I don't know who implements. I don't think matters for
authors it's what's easiest for implementors
Rossen: Transitions between forced and not forced colors requires
system reset of user shell. If we run or trigger animations
after shell reset is questionable
AmeliaBR: I wasn't thinking about changing if forced-color mode is
on but if forced-color-adjust mode applied within css.
Lots of complex interactions so I'm happy to define as
simple as possible but it needs to be defined
Rossen: If we have a conditional color rule that applies under a
forced-color-adjust: none and that rule is evaluated whether
or not color change triggers animation. Is that fair?
AmeliaBR: Yeah
Rossen: I think we should open a new issue on if that will trigger
transitions
AmeliaBR: I'll file an issue
<myles> I don't understand the complexity argument because because
script can change the value of this property at any time
CSS Sizing
==========
Should we mention aspect-ratio in margin collapsing?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5328
fantasai: Question was let's say there's an aspect-ratio and the
width is 0 so height is therefore 0
fantasai: Should that trigger margin-collapsing between top and
bottom margin of box
fantasai: In CSS 2 top and bottom margins of box with 0 computed
height and no inflow children.
fantasai: aspect-ratio does not cause computed height to be 0, it's
auto.
fantasai: Question that came up was if the used value is 0 should it
be the same was computed value is 0
fantasai: In CSS 2 there's no way to get 0 used height that doesn't
fall into this category. If we change computed to used in
CSS 2 nothing changes. But not lots of ways for used
height of 0 where it's not computed 0. margin-collapsing
could be changed to based on used. But do we want to?
fantasai: Based on emilio comment and others in issue it seems like
Chrome is using used value. Seems their aspect-ratio impl
collapsed but Mozilla wants to use computed
iank: We use used heights and it falls out straight forward. It sort
of makes sense to do in light of everything else
florian: If aspect-ratio is the only thing causing top and bottom
margin to not be adjacent is that question solved?
fantasai: Good point. aspect-ratio causes height to be 1px. That
should not cause top and bottom to collapse.
fantasai: For continuity it would be weird if 1px does not collapse
but 0px does
iank: Same as height 0px
AmeliaBR: I think the most important case is it's clearly defined
that and auto height that's definite because aspect-ratio
is treated as a definite height for margin-collapsing. I
don't know if we need to special case aspect-ratio width:0
and therefore height:0.
AmeliaBR: For basic case of empty element with aspect-ratio there's
no way we can collapse margin through something with
definite height
florian: I don't think people have strong idea of if they should
collapse. But when margins are not visually next to each
other people are clear it should not collapse. Make sure
that's true and then we can be sensible about handling 0
because people don't have expectations
fantasai: Difference in expectations is from different impl. My take
is it was a mistake for height:0px and height:1px to have
different behaviors. Adding more cases that do that is not
good. So I would lean toward saying it should not collapse
if aspect-ratio takes effect
iank: Don't agree. Rule is simple at the moment. If used height is 0
margins collapse through
fantasai: Spec says computed
iank: Previously that was the same
fantasai: Back to css 2.0
iank: We had to do 0 work to get this to work correctly. It falls
out from what happens if you set height:0 on an element
fantasai: I don't think we have emilio or dbaron from Mozilla. I
think their input is important
heycam: dholbert and I are here. I have not looked at margin
collapsing much.
dholbert: I have not recently
Rossen: If we have concrete proposal everyone agrees on we can
resolve and when dbaron and emilio read we can revisit. Do
we have consensus?
florian: I don't think we do
Rossen: Then it's fine to postpone for another week until emilio is
here
florian: We have consensus on if it's non-0 the margins don't
collapse. I don't think anyone disagrees with that.
Rossen: That's good. I'd like to resolve on that one
fantasai: Proposal: Non-0 height as a result of aspect-ratio
disables margin collapsing between top and bottom
Rossen: Behaves similar to fixed height
florian: I think just the result. If it's non-0 due to aspect ratio
it does not collapse. Why we'll get to later
Rossen: Additional thoughts or objections?
RESOLVED: Non-0 height as a result of aspect-ratio disables margin
collapsing between top and bottom
Rossen: Any additional progress or back to GH?
fantasai: Back to GH. I think having people from Mozilla who are
familiar with this code is important. It's a complex part
of layout so people have opinions
Rossen: Agree. Just looking for other low hanging fruit
Background 4
============
Switch to opt into transparent canvas for additive displays
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3949
Rossen: Brought up by Rik. I don't believe he's on the call
Rossen: Silence suggests no
Rossen: Anyone here who wants to take this?
dino: I asked some questions, but I don't think it needs to be
discussed
myles: I think call doesn't have right people
Rossen: Doesn't feel like it
dino: Unless you just want me to make a decision ^-^
dino: General use case makes sense. I haven't quite understood
behavior and what people would expect with meta tag. I look
forward to a bit more explanation
Rossen: This'll go in minutes, hopefully more will come in github
CSS Text
========
text-transform's design, intent and reality resolution
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3775
<florian> https://github.com/w3c/csswg-drafts/issues/3775#issuecomment-652733256
AmeliaBR: Is Brian here?
[not here]
florian: I'd like to speak about it anyway
florian: I suggest everyone reviews the comment just posted
florian: Issue not suggesting we change spec. It was fundamental
design of text transform. If we can all agree fundamentally
text transform behaves in a certain way we can use that to
build other things. It seems clear we can't agree this is
the way it works
florian: I can give more details, but I think conclusion is no we
can't agree, please close this.
florian: I can give arguments why I think it's the opposite, but the
conclusion is we cannot agree it's this other thing.
Rossen: Anyone from Igalia here to talk about this?
myles: Are you proposing close?
florian: Yes, close with no prejudice. I have nothing against the
math features. Can we agree the fundamental meaning of the
document, no we cannot.
myles: I'm happy to close
AmeliaBR: I think we have to formally agree to disagree in sense of
accepting some values of text-transform might have
meanings that should pass to assistive and some should be
stylistic and that's just the way it is. We can't seem to
agree all one or the other
fantasai: I disagree with that. There are values that are clearly
only presentational. There are other values...entire
purpose of text transform being in css is to make it
presentational. a11y layer might want to know and it's
appropriate to pass some information to it. I think
text-transform being a css property is not intended to
convey semantics.
fantasai: If you're using a11y api it may take aspects of
presentation into account but text-transform should not be
used for semantics
florian: Personally I agree with fantasai but issue was that it is
in all cases semantic. We certainly have not agreed it's
always semantic and never presentational. Maybe we
convinced people of fantasai's view. There's nothing to be
done here.
fantasai: I'll take an action item to put some text in the spec
clarifying where we're at. We'll review text and decide if
we like it
AmeliaBR: If you write what you said it's an improvement and as far
as we can move forward with this.
ACTION fantasai put some text in the spec clarifying where we're at
on issue #3775
Pseudo Elements
===============
Problems with styling ::first-letter with punctuation
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2040
Rossen: Linked to a lengthier topic from the F2F
fantasai: As I'm sure many of you saw during F2F when debating
drop-caps typical way to present punctuation like opening
quote is style with different font and styling that's
closer to paragraph rather than initial-letter
fantasai: Not always the same as paragraph. Positioned in relation
to initial-letter
fantasai: Super common and a problem for people trying to use
drop-caps.
fantasai: A number of issues surrounding this aspect. Some are about
hanging punctuation, but also being able to select it.
fantasai: Proposal is we add a pseudo-element.
fantasai: Two proposal in github- one is first-punctuation and the
other is ::punctuation pseudo class attached to
first-letter
fantasai: You can have multiple characters but you can't have them
in the middle because only one letter
myles: Would ::punctuation apply outside of ::first-letter?
<fantasai> ::first-letter::punctuation
fantasai: I think that would be bad. I think it would be required to
be attached to first-letter. You could write ^ but
anything else invalid.
AmeliaBR: I don't want to get into complexity of general punctuation
pseudo element. This is parts of ::first-letter other than
letter.
myles: Sounds like the name "punctuation" is bad
fantasai: It's selecting punctuation
fantasai: One concern I have with that approach is in many cases the
special style you want is only punctuation before but not
after. There's the one in plinss comment. The em-dash in
opening quote would be styled vertically middle to the L
but the quote would not read properly there.
fantasai: If doing special alignment you only want leading but not
trailing.
florian: Is it not included in first-letter pseudo?
fantasai: It is. All the punctuation in plinss comment is in
first-letter pseudo
<AmeliaBR> In “I'm here.”, the “I' are all part of ::first-letter
<fantasai> –«L'
fantasai: You have ^ sequence. If we have ::punctuation it doesn't
make sense for the first 2 to be selected but not the
last, but you do need to be able to select them separately
AmeliaBR: Visual examples I've seen it's only the bits before styled
differently
AmeliaBR: Probably okay at this point to focus on that part. If we
see examples to style the after different we can handle it
florian: I think we've seen some
AmeliaBR: We need to distinguish them because styles not the same
AmeliaBR: first-letter before-the-letter
plinss: My proposal was apply pseudo classes to those pseudo elements
florian: So it selects a run and you can do first-of-type and
last-of-type
plinss: "L' you have two punctuation pseudo elements
florian: em-dash"L' do you get 2?
plinss: That was a question in my comment. Several ways of doing it.
If there's space definitely multiple pseudo elements. If no
space don't know
fantasai: An entire sequence of punctuation include the space might
be single unit. Flexible with U20 but not other space
plinss: Looking for use cases with em-dash and quote do you want to
style different
<fantasai> https://github.com/w3c/csswg-drafts/issues/5154#issuecomment-659129316
fantasai: Yes, there was an example ^
plinss: Then different punctuation pseudo elements
fantasai: em-dash and opening quote look same and following different
plinss: Is there a use case to style differently?
fantasai: I think that low level we say you should put markup. We
should do common case and opening punctuation being
adjusted is common. Multiple opening punctuation styled
independently might not be common enough for support
plinss: If you wrap punctuation in a span they're all in
::first-letter
fantasai: Inside of them
fantasai: The people who want to style multiple leading punctuation
differently is a very small case. I think when you have
the case you markup special without first-letter.
florian: I'm concerned with implementation complexity. If we go
character by character the pseudo will be tree abiding but
if we grab a bunch it's not always. first-letter is already
a mess so maybe not worse, but might be adding
myles: Why can't ask authors to surround punctuation with spans?
This is getting complex, can't we get authors to do it
explicitly?
fantasai: Once you do that you can't use first-letter. Also, this is
a common case. If it was unusual I'd say put a bunch of
spans, hope that implementers support initial-letter
styling on arbitrary spans soon. General case of opening
punctuation being different is part of basic drop-cap
styling. If we want drop-cap to be usable we'll need to
support it.
florian: A run of punctuation in punctuation pseudo and you can get
2 of them is good enough for general use case and if you
want more complex you pile in spans. I do wonder about impl
complexity
<heycam> +1 to the complexity concerns around having the run of
punctuation, since it will be non-tree-abiding
fantasai: I don't have strong opinion of individual or a run. If
they are wrap independently will they be kerned together?
If it breaks kerning it's a problem. If no doesn't matter
much
florian: If independent we need to get spaces in pseudo
fantasai: Yeah
myles: webkit breaks kerning between elements and we view that as a
bug. We shouldn't assume different pseudo elements break
kerning
fantasai: What if you have 2 elements side by side. Normally no
styling, but give both vertical-align:super will they
continue to be a single line? part of problem here is
aligning differently here.
<heycam> I am wondering whether the kinds of styles authors want to
apply to the punctuation is limited enough that we should
handle this with a property rather than more pseudos
<heycam> (for the common cases we want to support)
<fantasai> heycam, I don't think it is... because they want to tweak
the font (family, size, and color)
<fantasai> as well as vertical alignment
<heycam> random wondering: will this pseudo match quotes inserted
with the quotes property?
florian: Could we do a simplification here? In case of what to style
run of punctuation together you're not having span
boundaries in the middle. Maybe could make that a tree
abiding run?
fantasai: Yes, could work. Have allowances in first-letter if it
breaks browser not required to do first-letter. We could
do that
florian: Yeah, browser could do a weird thing that crosses boundary.
fantasai: Making it tree abiding should be completely possible
fantasai: So how do we select? punctuation selector, punctuation
selector attached to first-letter?
florian: Can you use first child or first of type?
AmeliaBR: I don't think anything else with first-child on pseudo
elements
myles: I think we're designing a new feature. Surely that should be
done outside a call.
AmeliaBR: Yeah. Probably back to issue. Whatever we do it must be
tree abiding is one resolution
plinss: What I wrote a proposal for pseudo classes applying to
pseudo elements
Rossen: I think we went 360 around plinss suggestion. Most was
restating how we arrive here.
Rossen: Do we have any reasons why ::first-letter punctuation should
have effect outside of first-letter? If not reduces choices
quite a bit and it comes down to how do we allow pseudo
class only on first-letter
plinss: One of the reasons why switching to ::punctuation we may
want to allow in other cases like inside of marker, though
not everything
fantasai: 1.3.4 it selects the period?
plinss: Maybe. We can look in the future. Why I'm suggesting a more
generic name.
AmeliaBR: In that case need to distinguish between before or after
main thing. Still needs a modifier on punctuation pseudo
element. If that's different name or combining pseudo
classes we have to design that.
plinss: Ulterior motive to push pseudo classes
<plinss> as i understand it, we currently don't allow any
pseudo-classes on pseudo-elements, but there are other
places where it's useful, like ::part. One of my goals is
to push us in that direction.
Rossen: It's top of hour and we're not ready to resolve. We can
continue next week if we're closer.
Rossen: Have a good rest of the week and we'll talk again next
Wednesday
Received on Thursday, 6 August 2020 10:26:37 UTC