- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Mar 2020 19:29:45 -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.
=========================================
April F2F
---------
- The April meeting will be held as a virtual F2F instead of in
Cork. Exact details are still being discussed on the private
mailing list and members are encouraged to add their thoughts in
that thread.
Constructable Stylesheets
-------------------------
- RESOLVED: @import doesn't parse in constructable stylesheets and
as a result throw syntax errors (WICG Constructable
Stylesheets Issue #119: Add a note about the reasoning
to forbid `insertRule(@import)`, or remove the
condition?)
- There was concern that not supporting @import will lock in that
lack of support. Discussion will happen on getting CSS Modules
to resolve the @import module graph question that had blocked
@import support.
Feature introduction, subtree-visibility CSS property
-----------------------------------------------------
- chrishtr introduced the re-written proposal (Issue #4843) for
subtree-visibility which is created to allow authors to control
element subtree visibility and provide rendering performance
hints to the UA. He requested full review of the proposal
( https://wicg.github.io/display-locking/index.html ) so the
spec can move toward implementation.
CSS Transforms
--------------
- RESOLVED: No change [to transform serialization] (Issue #3305: Is
it necessary to serialize all 3 components of translate
given the 3rd component is 0px)
CSSOM
-----
- RESOLVED: We define this [rule serialization] in CSSOM to match
browser compat as much as it exists. (Issue #4828:
Serialization of rules)
CSS Pseudo Elements
-------------------
- RESOLVED: Allow transitions on ::marker and allow animations with
animations happening and animation rules applying the
style (Issue #4814: Animations on ::marker?)
CSS UI
------
- The group will wait and see the results of Chrome's experiment on
changing to Firefox's behavior for auto-disabling native
appearance prior to changing spec text (Issue #4777:
Auto-disable native appearance when cascaded value has author
origin).
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Mar/0007.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Daniel Libby
Stanton Marcum
Anron Prowse
Manuel Rego Casasnovas
Florian Rivoal
Devin Rousso
Christopher Schmitt
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Rachel Andrew
Tantek Çelik
Scribe: dael
April F2F
=========
Rossen: Before we do the agenda I have one item
Rossen: We did cancel the April meeting in Cork Ireland which was to
be hosted by Apple due to the COVID-19 outbreak.
Rossen: It was decided to be a virtual F2F.
<Rossen> https://github.com/w3ctag/meetings/tree/gh-pages/2020/05-distributed
Rossen: We will work on details for exactly how to do this and
format. If you have idea feel free to bring it to mailing
list or ^
Rossen: We don't have good coverage for East Coast US but we can add
that if there are members. It will be a highly distributed
virtual F2F and we'll make sure there's chairing
capabilities. We don't have exact details to talk format
yet, but I did want to give the heads up
CSS Alignment & CSS Grid
========================
Do grid items that have "no baseline set" participate in baseline
alignment?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4675
Rossen: Mats brought this and lajava added to agenda
TabAtkins: I'm not ready here, I looked into it and realized it
wasn't easy so I haven't done enough to dig in and get
the right answer. I'll try and take care of it next week
Rossen: If this encourages progress I'm fine with that.
<fantasai> I thought we assumed that items can baseline-align if
they are orthogonal / have no baseline ?
<fantasai> https://github.com/w3c/csswg-drafts/issues/721#issuecomment-264272653
fantasai: I saw we had discussions about this and had resolved.
There was about how do orthogonal grid items align or not
when placed in grid. I understand there's wording to
clarify but I thought we discussed. Not sure how this is
different
TabAtkins: I had same feeling but couldn't find wording in spec that
defines it well. We didn't write it down
fantasai: We need to add to spec but we've had WG discussion
Rossen: I'm happy to move on. Let's see if we can make progress and
close with previous resolutions or bring it back next week
Constructable Stylesheets
=========================
Add a note about the reasoning to forbid `insertRule(@import)`, or
remove the condition?
------------------------------------------------------------------
github: https://github.com/WICG/construct-stylesheets/issues/119#issuecomment-594873154
TabAtkins: emilio is best to take it. I'm fine with it but I have an
answer I want and I'm not sure what others feel
chrishtr: We want to discuss if it throws an exception with an
illegal rule. Not about allowing imports
TabAtkins: Yeah. It's if we silently ignore or if we throw an error
when you try and create a sheet, replace text, or insert
an import rule directly
Rossen: Is there a proposed path forward with exception or silent?
TabAtkins: Not a decision yet. I'm for throwing because more
consistent with CSS Modules. This makes it easier to fix
later. If we end up allowing imports it's less likely
authors depend on it if the module is completely broken.
For consistency and friendly to future decisions I think
we should throw entirely for now if you try and include
an import
emilio: I disagree. I don't think it's different than syntax that
doesn't work and eventually works. We should be consistent
about syntax we want to eventually support. If we add
@import supports and silently ignore but if we have
syntactically valid we throw
Rossen: Sounds like we have consensus around throwing
emilio: I'm arguing to not throw
chrishtr: I agree with emilio not throwing is better. Can't we
change css modules to not throw?
TabAtkins: We can. It would mean we're slightly more likely to pick
up a dependency if we don't decide soon
TabAtkins: I agree silent ignore is better overall. Consistency and
reason css modules does it is compelling to me.
Rossen: There were lengthy discussions on css modules and how they
should work. Part of the recent tag review about event loop.
Chasing down the thread between those that were
there...there were a lot of discussions on this and pointers
between groups saying css should define if we throw and us
not. Lots of what's on WICG assumes we're throwing. It would
be good to reconcile these discussions
Rossen: If we have strong proposal to not throw that's fine but I
think we will need to reopen the larger discussion
Rossen: I don't think this will be end of conversations if we
change. But do we have consensus on not throwing
TabAtkins: If we can take it back to css modules I'm fine with not
throwing
Rossen: So update this issue to say this will be consistent with css
modules?
chrishtr: [missed] not to throw
Rossen: If modules define not it's fine
emilio: Modules defines just replacing. If modules wants to throw
they might need to do a general thing to throw. I still
would argue that's not great
chrishtr: Suggest we resolve not to throw and someone takes and
action to check this is okay with modules. If it's not
okay we come back to the group
emilio: Sounds great
chrishtr: We should also resolve insert rule throws syntax error
emilio: Can say @import does not parse in constructable stylesheets
and that gives implicit syntax error
Rossen: Proposal: Do not parse @import which will cause a syntax
error and also not throw
Rossen: Objections?
emilio: @import doesn't parse in constructable stylesheets and as a
result throw syntax errors
TabAtkins: Agree that's right wording for it
<dbaron> Not supporting @import seems like it's becoming
progressively more and more complicated...
RESOLVED: @import doesn't parse in constructable stylesheets and as
a result throw syntax errors
Rossen: dbaron do you want to add to conversation?
dbaron: Worried we're piling on more stuff to not support @import.
Seems it's getting progressively more complex
emilio: I don't know how throwing or not makes this more complicated.
dbaron: More complicated may not be right, but there's more
decisions about it because it's different
emilio: Our constructable stylesheets implementation we plan to show
a warning if you stash an @import
emilio: Doesn't seem situation is worse by not throwing. In fact I
think it's better
dbaron: I would be pessimistic about ever being able to change this.
If we don't support @import we'll be stuck with that
emilio: That's a different discussion though? At least in replacing
you have to define a way to [missed]
<TabAtkins> Phew, I simply can't hear Emilio.
emilio: I was saying we need to define an error handling for
replacing. Doesn't seem to me...we need to define error
handling either way. I see dbaron's point about not
supporting @import but it's a different conversation. For
replacing you need error handling and I think this is most
consistent
Rossen: dbaron do you want to reconsider the resolution? Back to the
issue and discuss there?
TabAtkins: Alternative is we go resolve the issue for css modules
about if imports are shared or independent in module
graph. We're trying to avoid because we couldn't decide
on that question and didn't want to lock in api
emilio: And about sharing cross document which we're not doing
<dbaron> I think we'd be much better off if we just resolved the CSS
modules thing one way or the other.
Rossen: Given this is in WICG still by no means is this final final.
If you need more time to work with module folks that would
be good to do so and see if we can help close the issue for
the design and the @import decisions will be taken care of
here by time modules are complete
<dbaron> I suspect that supporting @import either way would be less
bad than not supporting @import.
* emilio agrees with dbaron, but even with that
`CSSStyleSheet().replaceSync()` should handle @imports in
some way
chrishtr: Need decision on throwing because it impacts something
being implemented. If we can preserve resolution of
exception that would be good
Rossen: We did record a resolution
chrishtr: Checking it still holds
Rossen: Yes. Trying to see if dbaron wants to object and keep
working on this or keep as is as a stop gap until modules is
in better shape. dbaron can you comment on your preference
to move forward?
dbaron: If you give me enough opportunities to object at some point
I will
Rossen: You've got an opportunity to object right now
dbaron: Having all this depend on one decision in css modules is
weird. But I won't object
Rossen: Then previous resolution holds. I'd encourage everyone in
this to re-engage with modules and see if we can make
progress
Feature introduction, subtree-visibility CSS property
=====================================================
github: https://github.com/w3c/csswg-drafts/issues/4843
chrishtr: At TPAC 2019 I presented a dom attribute with purpose to
allow browser to avoid rendering of stuff not drawn to
screen. Based on feedback there and from other vendors
since proposal has changed a lot. Semantics are about same
but API shape changes to improve dev semantics and now
fits well within css. It's a css property called
subtree-visibility. Semantics are about same as
visibility:hidden. One difference is when content is
skipped, aka not visible
chrishtr: Element is contain-size. This property is meant to be
paired with contain-intrinsic-size so when content is
visible you can have placeholder size
chrishtr: 3 properties: visible|auto|hidden. Auto controlled by the
browser so when content is on screen or focused to it's
visible or not skipped. If it's not visible on screen to
user and not part of a focus or selection it's auto marked
as skipped so browser is free to skip style layout. Not
required but allowed
chrishtr: Can view this as another addition to contain spec where
it's a way to augment contain so it's easier for browser
to optimize work off screen
chrishtr: hidden is dev controlled and meant for virtual scrollers
and single page app
chrishtr: Would like feedback. Is naming good? I think it's better
because clear it's a hint. Semantics are about boxes and
block trees.
chrishtr: We've implemented and you can try it on demos by enabling
it in chromium
Rossen: Thank you chrishtr. I'd encourage people to engage on the
issue and refresh yourselves on the property and how it
fits. If/When needed we'll bring back to WG call to make
decisions
CSS Transforms
==============
Is it necessary to serialize all 3 components of translate given the
3rd component is 0px
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3305
Rossen: TabAtkins you brought this back?
TabAtkins: Yes. Originally spec for individual transform properties
distinguished between author writing 2d and 3d transform
TabAtkins: Firefox and maybe others objected because having z
component of 0 is same as 2d translate.
TabAtkins: I objected at time because Chrome and WK had quirk where
we used 3d transform presence as a hint to move to
compositing layer. We were going to try and remove the
quirk which is why we accepted FF proposal
TabAtkins: Turns out we can't remove. We see a lot of extra paints
from things not moving to compositing layer. Because this
is unacceptable amount of lost performance we're keeping
the hack for now and may need it forever.
TabAtkins: Want to revert spec to keep track of if something was 2d
or 3d so you can round trip.
<flackr> I think interpolations are also different between 2d and 3d
emilio: This quirk is transform specific. Don't get why you need more
TabAtkins: All 3d transforms do it right now
emilio: I think that translate could be changed. I don't think
people are doing translate(0,0,0)
TabAtkins: I doubt they are. But if this is being kept around I'd
like to be consistent across platform if we keep 2d and 3d
emilio: But transform is different because people use transform set
TabAtkins: Impacts how we serialize. Matrix or Matrix3d for example
emilio: Seems wrong
dbaron: Does 2d or 3d influence animation?
TabAtkins: Only with rest of the quirk we talked about
flackr: I think this effects decomposition when interpolating
between matrix
AmeliaBR: Animating between 2 2d transformations then your animation
is entirely 2d. 2d to 3d it gets upgraded so animation
becomes 3d
flackr: If there were a case where 3d matrix becomes 2d at 0 it
could cause different interpolation. But only when fallback
to matrix interpolation
emilio: And doesn't apply to individual transform properties right
flackr: Right, I don't think have to fall back to individual
transform property
smfr: WK hasn't implemented individual properties and it would be
nice as a break to get away from the hack.
<TabAtkins> I was wrong - it doesn't affect whether we serialize as
matrix() or matrix3d()
emilio: TabAtkins I tested and it's not what you were saying
TabAtkins: Yep, I jsut tested and found the same
TabAtkins: smfr I agree I would love if authors use will-change but
it won't effect if we can remove translate-z hack. It
means have to be inconsistent in typedOM because right
now they track 2d or 3d and they'll want to serialize
transformed values.
TabAtkins: I'm not happiest with hack being limited to just 3d
transform functions. I don't like inconsistent if you
turn transform into individual transform. Doesn't feel
right to me. Even if we don't like hack existing I don't
like inconsistency in platform
emilio: Will be inconsistent one way or the other
TabAtkins: If something is promoted to compositing is inconsistent.
But the more obvious to authors as to if it's in typedOM
I'd like to be consistent
emilio: Still don't think you should get is3D transform
TabAtkins: We want to change if you set with 3 we serialize to 3
AmeliaBR: And that's is3D for typed OM, right?
TabAtkins: Not sure what you're asking about
AmeliaBR: Clarify what emilio thinks is inconsistent. I understand
proposal is we consistently keep track of if it's 2d or 3d
emilio: Computed serializes 2d for translateZ(0)
TabAtkins: Yeah we've already got inconsistency in there. That's
annoying.
TabAtkins: I'm fine accepting it's just transform functions that
preserve 3d. And not even computed value. This is
terrible. Everything is terrible
emilio: Agree
TabAtkins: I'm fine no change.
Rossen: Proposed: Close no change
Rossen: And then hopefully someone will make TabAtkins feel better
emilio: I can say I'm sad too
Rossen: We all share the pain
florian: There's precedent for writing this is sad within spec
<florian> "this is sad":
https://github.com/w3c/csswg-drafts/blob/master/css-text-3/Overview.bs#L2753
RESOLVED: No change
CSSOM
=====
Serialization of rules
----------------------
github: https://github.com/w3c/csswg-drafts/issues/4828
TabAtkins: Merged a PR to spec how to serialize @property. Decided
to serialize in one line.
TabAtkins: Fine but wanted consistent. I looked around and couldn't
find one spec on how to serialize rules. But I think we
tend to serialize multi line.
TabAtkins: I would like to define this, probably in CSSOM, with
descriptors. Then we need to decide if it's on a single
line or multi-line with indents
florian: I have vague memory of doing something like this in Presto
and trying to align to where a line is broken. I vaguely
remember compat problems
emilio: style rules seem to be one line
Rossen: Is proposal to allow multi-line but not define how and where
you should break?
TabAtkins: No, no. I would like precise spec. We have it for
whitespace and we need that level
florian: I support doing this, write something sensible, and then if
compat says we can't at least we know where
emilio: I think impl are somewhat consistent so I don't think would
be hard. Happy to help
Rossen: Don't see pushback on multi line
emilio: Biggest is that's not what browsers do
Rossen: Compat risk?
TabAtkins: If there's compat we should follow that. emilio is right
style is one line so we should consistently do that
florian: Seems sad too but okay
Rossen: Prop: Specify serialization is one line?
TabAtkins: Prop: We define this is CSSOM to match browser compat as
much as it exists.
TabAtkins: emilio or I can write it out
Rossen: Objections?
RESOLVED: We define this is CSSOM to match browser compat as much as
it exists.
CSS Pseudo Elements
===================
Animations on ::marker?
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/4814
fantasai: We have an allow list for properties on ::marker because
haven't figured out layout. Pointed out animations and
transitions not allowed but makes sense they should work.
Suggestion is add them to list
Rossen: Other thoughts?
oriol: Seems reasonable but a note it may be inconsistent since
first-letter and first-line restrict properties and you can't
animate them. It would be inconsistent but could make sense
since marker is tree-abiding.
oriol: May be a bit annoying for impl because it will bypass filters
for which properties apply. Shouldn't be hard to do I guess
AmeliaBR: So that's practical implementation issue if makes harder
to tell which properties can be animated. Should be able
to set transition property but only ones where it works
are those where allowed. But logically if you can set
color you should be able to animate color
dbaron: Note thing with filtering isn't an issue with transitions
since they can only go between those that apply
AmeliaBR: Making sure keyframes are properly filtered out so only
those that should have an effect do
Rossen: Hearing some feedback this might be somewhat challenging to
impl but from user expectation and behavior I don't hear
reasons why it shouldn't be allowed
dbaron: I don't think that's challenging. But not with animations
there's two technical ways to do it and they're
distinguishable. You can say animation happens and an
animation rule applying the style doesn't apply or you say
animation doesn't happen. First I suspect is easier but
second is better api
fantasai: Plan to add more properties to ::marker once we have a
layout model. Probably want to go with way animation
happens because then don't need infrastructure in style
system. Hopefully a temporary situation
flackr: Also prefer first approach
dbaron: Do have to have infrastructure because that they don't apply
has implications for computed value. Not sure
emilio: Have a filter but if impl in FF it's a one
Rossen: Consensus seems to be allow transitions on ::marker and
allow animations with them happening and animation rules
applying the style
flackr: Animation is applied, style not observed because doesn't
take effect
Rossen: Objections?
RESOLVED: Allow transitions on ::marker and allow animations with
animations happening and animation rules applying the style
CSS UI
======
Auto-disable native appearance when cascaded value has author origin
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4777
florian: We have appearance property with auto look native. When in
native there's a number of properties where if you set to a
value it disables native-ness. Example is border-bottom
florian: 2 things undefined. What's the set of properties that have
this effect and on which elements. Other thing, this issue,
is how do these properties disable. One is FF which if
author sets to any value it disables nativeness. Chrome is
the values is set different then UA it disables nativeness.
Chrome plans to switch to FF behavior
florian: Not spec anywhere, but an attempt in HTML and a placeholder
in CSS UI 4. Mostly a heads up from Chrome they are trying
this. But if people think it's a bad idea it's good to say
so before they try
smfr: I think Chrome inherited from WK. Would be interested in
seeing experiment. If successful WK probably willing to follow
florian: Since appearance are sensitive to compat I'm interested to
wait out experiment before changing spec
Rossen: We're at top of hour. Anyone from Chrome that could have
feedback on success now? If not we push back to GH and
discuss next week
florian: No experiment yet. Pinging us before hand in case it sounds
like a terrible idea. Doesn't sound like it is so we should
let them run and report back.
Rossen: I see.
Rossen: Let's end here and then hopefully we'll get data back from
Chrome experimentation
Rossen: Thank you. If you've got ideas or constraints about virtual
F2F feel free to chime in on the thread. We'll start
figuring that out.
Received on Wednesday, 11 March 2020 23:30:28 UTC