W3C home > Mailing lists > Public > www-style@w3.org > March 2020

[CSSWG] Minutes Telecon 2020-03-11 [css-transforms-2] [cssom] [css-pseudo-4] [css-ui]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Mar 2020 19:29:45 -0400
Message-ID: <CADhPm3tJVmnS5tX1ZixUVzzT343wCR0eCgYTEgqVhMpVY_HVQg@mail.gmail.com>
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
  - 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)


  - 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?)


  - 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

===== FULL MINUTES BELOW =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Mar/0007.html

  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

  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
  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
  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

  Rossen: So update this issue to say this will be consistent with css
  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
  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

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

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

  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":

  RESOLVED: No change


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


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

This archive was generated by hypermail 2.4.0 : Wednesday, 11 March 2020 23:30:29 UTC