W3C home > Mailing lists > Public > www-style@w3.org > August 2021

[CSSWG] Minutes Telecon 2021-08-18 [cssom] [css-overflow-3] [css-display] [css-highlight-api]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Aug 2021 18:47:58 -0400
Message-ID: <CADhPm3tM1BotTXdUg3Hm5=Lx_rNrx9eZPPMXy_CHR4vbDewUfw@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.
=========================================


CSSOM
-----

  - RESOLVED: Return empty style if string begins with a colon, return
              element style otherwise (Issue #6501: Throwing on invalid
              pseudo-elements in getComputedStyle is not web-compatible)
  - RESOLVED: Accept edits (Issue #6253: Shorthands should serialize as
              empty string when longhands have variables)

CSS Overflow
------------

  - RESOLVED: overflow-clip-margin uses the same corner-adjustment
              formula as margin/etc (Issue #5896: overflow-clip-margin
              + border-radius continuity adjustment)
  - RESOLVED: Accept dbaron's editorial feedback about making the
              "accidental" case more explicit (Issue #5896)

CSS Display
-----------

  - RESOLVED: Serialize specified value of display using keywords
              specified (Issue #5575: Should <display-legacy> values be
              aliased at parse time?)
  - RESOLVED: close wontfix (Issue #4022: display:contents list-item)
  - RESOLVED: Close no change (Issue #3998: The 'flow' keyword is
              redundant)
  - RESOLVED: Publish new CRD of css-display-3 (after today's edits)
              (Issue #6516: Horizontal review)

Highlight API
-------------

  - Though the group ran out of time for discussion, the expectation is
      that next week the we be able to resolve issue #4597
      (Invalidation of Static Ranges) as close no change.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Aug/0014.html

Present:
  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Christian Biesinger
  Dan Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Sanket Joshi
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Alison Maher
  Morgan Reschenberg
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Regrets:
  Chris Harrelson
  Daniel Holbert
  Florian Rivoal

Scribe: fantasai

CSSOM
=====

Throwing on invalid pseudo-elements in getComputedStyle is not
    web-compatible
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6501

  emilio: Resolved to throw in these cases
  emilio: I implemented it
  emilio: but people do silly things
  emilio: and it's not Web-compatible
  emilio: One error is passing property names as pseudo-element names
  emilio: and one is passing 'false'

  emilio: Question is, should we try to do something smarter? Should we
          return an empty style? Should we not throw and return the
          element's own style?
  emilio: Blink and WebKit return the element's own style
  emilio: Firefox does that, but not if pseudo-element starts with two
          colons
  emilio: which is at least a bit more forwards-compatible
  astearns: Not returning element style with two-colon strings means
            we're less likely to have problems when we introduce new
            pseudo-elements
  emilio: Errors we're seeing seem to be mostly typos
  emilio: ...
  emilio: We could special-case in the IDL

  dbaron: Seems the Web-compat problems are strings without
          double-colon, so could throw on double-colon strings that are
          also errors
  emilio: I'd be OK with that
  TabAtkins: Don't have a strong opinion, whatever is both Web- and
             forwards-compatible
  TabAtkins: document legacy weirdness

  astearns: We'd resolved on throwing rather than empty style before,
            why did we decide that?
  emilio: Usually better, but optimistic that we could get away with it
  <dbaron> the cases where we need to worry about forwards compat are
           (we think) the start-with-colon cases

  emilio: Anyone object to returning empty style if string begins with
          colon, otherwise return element style?
  iank: Does this paint us into a corner for slot pseudos or anything
        like that?
  emilio: I don't think so
  emilio: If you do '::slotted' there's no style to return, multiple
          elements can match it
  astearns: Objections?

  RESOLVED: Return empty style if string begins with a colon, return
            element style otherwise

Shorthands should serialize as empty string when longhands have
    variables
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6253

  TabAtkins: Variables spec has text about handling situations when
             shorthand contains variable and you ask for longhands
  TabAtkins: At that time, we don't know what they will be, until
             computed value
  TabAtkins: Same problem opposite direction, if variables in
             longhands, trying to serialize shorthand
  TabAtkins: Can get two completely invalid longhand that creates a
             valid shorthand, for example.
  TabAtkins: So spec specifies the same thing, if longhand contains
             variable and you ask for shorthand, considered
             unserializable shorthand.
  TabAtkins: Wanted to confirm edits with WG
  emilio: This is the only thing that makes sense
  TabAtkins: Firefox and Chrome do specified behavior, WebKit does
             incorrect behavior
  TabAtkins: Currently
  astearns: Any concerns about this?

  RESOLVED: Accept edits

CSS Overflow
============
  Scribe: TabAtkins

overflow-clip-margin + border-radius continuity adjustment
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5896#issuecomment-892995385

  fantasai: I think dbaron's comments are mostly editorial
  fantasai: So I'll ask the main question
  fantasai: Do we want to accept that the overflow-clip-margin follows
            the same corner-adjustment rules as margin/border/padding
            edges (so pointy corners stay pointy, round corners stay
            round)
  fantasai: When you have a curved border edge, and we calculate the
            equivalent padding or content-box edges, we subtract the
            border/padding widths, flooring at zero.
  fantasai: Similarly when you're going out to the margin edge or box
            shadows, we *add* the margin/shadow size to the radius, but
            with a special adjustment that keeps zero radius at zero.
  fantasai: Some math keeps it continuous between the two cases without
            causing noticeable changes in most cases
  <fantasai> https://drafts.csswg.org/css-backgrounds-3/#corner-shaping
  <fantasai> https://drafts.csswg.org/css-backgrounds-3/spread-radius

  dbaron: Another complexity is that a corner might be an inset on one
          side and outset on the other. Already possible with negative
          margins
  dbaron: This probably makes that case more common, since it's an
          offset from the padding edge
  dbaron: I think the spec actually does something reasonable for this
          right now, but it's by accident. I think it's right, though
  dbaron: It probably should look more intentional to make sure impls
          think about that case
  fantasai: I just posted the testcase we used when we were figuring
            out the continuity formula
  fantasai: So proposal is to use the same formula for
            overflow-clip-margin
  astearns: Any other opinions?
  [no objections]

  RESOLVED: overflow-clip-margin uses the same corner-adjustment
            formula as margin/etc

  astearns: Should we also resolve about being more clear about the
            positive-and-negative margin case?
  fantasai: Sure
  astearns: So proposal is to accept dbaron's feedback, making the
            "accidental" correctness more explicit.

  RESOLVED: Accept dbaron's editorial feedback about making the
            "accidental" case more explicit.

  dbaron: I don't think there's more to discuss, but I did raise more
          substantive editorial issues that I think could confused
          implementers.
  dbaron: Do think we need to deal with those, but don't think we need
          group time for them.
  astearns: So fantasai you'll go thru those and either implement or
            bring back to the group if necessary?
  <fantasai> yes

CSS Display
===========
  scribe: fantasai
  scribe's scribe: TabAtkins

Should <display-legacy> values be aliased at parse time?
--------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5575#issuecomment-893899115

  TabAtkins: Awhile ago, Oriol brought up that we have the short
             display values like inline-block, inline-table, etc.
  TabAtkins: after attempt of splitting display property and then
             re-unifying
  TabAtkins: we have two-keyword values
  TabAtkins: Question was whether these two ways of writing the same
             value should be canonicalized at parse time or some other
             time
  TabAtkins: Argument for canonicalizing at parse time is that code
             written before these values were valid, might be expecting
             inline-foo pattern
  TabAtkins: If author writes 'inline flow-root' for some reason, that
             code won't correctly respond
  TabAtkins: counter-argument is that it can be confusing when we
             return something different from what author wrote,
             especially for specified values
  TabAtkins: and code written in the past will continue to work, just
             not with the new syntax
  TabAtkins: and that code wouldn't work for new display values in any
             case
  TabAtkins: fantasai and I come down on the side of not canonicalizing
             at specified-value time
  TabAtkins: It doesn't create Web-compat issues
  TabAtkins: and it lets authors work in the syntax they specified

  emilio: Is proposal to canonicalize at computed value time?
  fantasai: Don't we have a requirement for shortest-serialization for
            getComputedStyle?
  TabAtkins: Separate question
  emilio: It's very easy to check for one and not the other
  emilio: I think it's better to canonicalize at parse time
  TabAtkins: It sounds like you're saying that canonicalize to happen
             at some point, and while prefer at specified value but ok
             if only at computed value?
  iank: Not concerned about Web compat?
  emilio: I am, but figure they're accounted for?
  iank: I don't think anyone's done research on this
  iank: If Firefox implements this and it breaks or doesn't break a
        bunch of sites...
  TabAtkins: Not canonicalizing can't have Web-compat impact, because
             legacy code written with inline-block will still return
             inline-block
  TabAtkins: New code written against old libraries would not work
             maybe, but that's not compat
  emilio: Firefox has shipped the new syntax for awhile now
  emilio: so could have compat
  emilio: I don't think it's super useful not to canonicalize
  emilio: Useful for authors that write JS code and browsers

  astearns: I suspect whether or not we canonicalize at parse time is
            much less web compat concern than if we do it at
            computed-value time
  astearns: but there's argument of if computed-value is simplified,
            might be simpler to do it at parse time
  iank: Whether we do it at parse time...
  TabAtkins: fwiw, I agree that at computed value time they should be
             canonicalized, because they are in effect the same value,
             and shortest serialization would require it

  iank: Are we ok with backing out if there's a compat problem?
  emilio: This proposed resolution is the behavior of the only existing
          implementation
  TabAtkins: Yeah, so this is completely web-compatible if anything
             can be
  fantasai: The existing rule is "shortest most backwards-compatible
            serialization"
  astearns: So want to be clear that they're the same

  RESOLVED: These values compute to each other and thus serialize as
            "shortest most backwards-compatible" which is the older
            keywords

  TabAtkins: 2 objections to canonicalizing at parse time
  TabAtkins: First, specified value should reflect what the author
             specified
  TabAtkins: if put .style="inline flow-root" should get that back when
             request it
  TabAtkins: Also, canonicalizing back out would make it harder to
             split back out into two longhands
  emilio: I don't see why
  fantasai: When teaching CSS, Jen and Rachel have found the split
            keyword syntax useful for explaining the difference between
            inner and outer display roles
  fantasai: If they disappear from the OM as soon as they're inputted,
            that creates a strong bias against using them, they're not
            so real anymore
  <jensimmons> yup to useful for teaching. Once they are in every
               single browser everywhere, I expect developers to start
               using them exclusively. (AKA, 2027?)
  [missed exchange]

  emilio: I don't feel super-strongly, can compromise at computed-value
          time
  emilio: I think it's weird one way or the other
  emilio: Computed value of 'display' is more looked-up than specified
          value
  TabAtkins: In general specified values aren't looked at too much
             anyway, unless looking at value of style attribute
  emilio: I don't see this as super useful, but if fantasai disagrees,
          it's OK I trust her

  jensimmons: I haven't been completely following, but +1 to what
              fantasai said
  jensimmons: about the syntax of inner and outer is super useful
  jensimmons: Teaching now, and later once all browser support it, will
              likely switch to it
  emilio: But if we serialize into old syntax, doesn't seem so useful?
  emilio: Serializing the old value increases time to adoption, while
          serializing the new value which is nicer, but...
  astearns: I do agree with Tab's first point, that we do try to keep
            the serialization of specified values as close to what
            author inputted as possible
  astearns: and sounds like Emilio is OK with that, and didn't hear
            concerns about having specified vs computed being different
  astearns: So proposed resolution is that for specified values we
            serialize as written
  astearns: and for computed value, we canonicalize
  emilio: Not quite as written, if you write "inline flow"... do you
          want to serialize to "inline"?
  emilio: Nevermind
  emilio: sounds OK

  jensimmons: Not sure what issue is, but if this affects what appears
              in the computed panel in devtools, idea of browsers
              saying "I took old value for you and put it into the new
              style" that would be a good thing
  emilio: The computed panel, you can put whatever there. Doesn't
          affect specified.
  jensimmons: I think what happens in parsing engine, nobody knows,
              doesn't matter to authors
  astearns: So can we resolve?
  <bradk> +1

  RESOLVED: Serialize specified value of display using keywords
            specified

display:contents list-item
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4022

  astearns: Proposal is close wontfix?
  TabAtkins: Brought up that there's nothing theoretically wrong with
             'display: contents list-item' which would generate a
             ::marker
  TabAtkins: Currently the grammar doesn't allow combining these two
  TabAtkins: My objection to this is just that we don't have any
             particularly strong reason to do so
  TabAtkins: but there's nothing wrong with it
  TabAtkins: So suggesting close no change
  TabAtkins: but no objection to making it possible if someone thinks
             this is a useful thing that we should allow
  astearns: My case in the comments is completely theoretically
  TabAtkins: I can see it, but I think it's one more thing that we
             don't necessarily need
  emilio: Seems like one more edge case that we should avoid, so ok
          with no change
  astearns: Any objections to no change?

  RESOLVED: close wontfix

  astearns: If Mats feels strongly, he could reopen it

The 'flow' keyword is redundant
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3998

  TabAtkins: Mats pointed out that the 'flow' keyword doesn't
             technically do anything
  TabAtkins: The display-outside value you pair it with, if don't
             specify anything else, it's implied
  TabAtkins: was wondering why it's there
  TabAtkins: There are 2 reasons
  TabAtkins: It was a remnant of display-inside/display-outside as
             separate properties
  TabAtkins: did need a keyword for ordinary flow
  TabAtkins: when we collapsed back to shorthand, combined values
  TabAtkins: and then I'm personally not a fan of states which are
             expressed by a lack of a keyword
  <miriam> +1
  TabAtkins: So prefer when a particular state allows an explicit
             keyword, even if getComptutedStyle omits it
  TabAtkins: Lastly, Firefox already shipped with it
  TabAtkins: So my preferred resolution is to close no change, keep the
             keyword
  astearns: Any other comments?

  RESOLVED: Close no change

  jensimmons: Sounds to me like this would have a big impact on authors
              for the reason we discussed earlier, and we want this
  jensimmons: so all in favor of the resolution

Publishing Display
------------------
  github: https://github.com/w3c/csswg-drafts/issues/6516

  astearns: Proposed resolution is to publish CRD
  astearns: We have changes list and DoC
  <chris> looks good to me
  TabAtkins: The one thing, we will need to do slight modifications to
             make that resolution about canonicalization clear, but I
             think that's the only change not reflected in the draft
  fantasai: We're actually set to publish a new CR Snapshot, which is
            the one that invokes patent policy
  fantasai: But we don't have horizontal review when we pulled in
            'order' and 'visibility'
  fantasai: We need review on those because they're major changes
            compared to previous CR
  <fantasai> https://drafts.csswg.org/css-display-3/#visibility
  fantasai: Also want the WG to take a look at the 'visibility' section
            in particular. We didn't just copy from CSS2, we added more
            text, especially for interactivity (clicking, etc) which
            wasn't clearly specified in CSS2
  fantasai: So after we get review on this new CRD, our intention is to
            request a new CR snapshot
  astearns: Objections to publishing CRD after edits from today?

  RESOLVED: Publish new CRD of css-display-3 (after today's edits)

Highlight API
=============

Invalidation of Static Ranges
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4597#issuecomment-892202307

  dandclark: Static ranges can get into weird states, like if I remove
             one boundary from the DOM
  dandclark: Sanket came up with criteria for deciding if a range is
             valid or invalid
  dandclark: but the question is, if user adds range to a highlight
             should we use a live range, or use static range internally
  dandclark: Reason to use live range, don't have to check validity in
             the same way because they're kept up to date
  dandclark: We discussed awhile, and decided not to back static ranges
             with a live range
  dandclark: First, performance reasons -- live ranges, they can slow
             down DOM mutations because live ranges have to be notified
             every time there's a DOM mutation
  dandclark: Static range doesn't have that issue
  dandclark: We did some research showing that this performance issue
             is observable
  dandclark: and we also found that with caching, it's possible to
             cache static range validity
  dandclark: which reduces performance cost during painting
  dandclark: But if they were backed by live ranges internally, that
             wouldn't hold
  dandclark: because DOM mutations would have to update, so lose
             performance benefits
  dandclark: Sanket also raised some issues with using live ranges
             internally
  dandclark: Authors don't have direct references to those live ranges
  dandclark: so difficult, how would they remove or modify a highlight
             that they added?
  dandclark: Even if we added a map, can become out of sync with tree
  dandclark: and not clear when safe to drop live range, because author
             might de-register and re-register a static range
  dandclark: so confusing developer-confusing scenarios there, tricky
             answers for spec
  dandclark: So proposal is to allow static ranges and live ranges to
             be added to highlights
  dandclark: and there's no live range backing for static ranges
  astearns: My first question was, can developer use either
  astearns: Is it clear to devs that live range could have performance
            implications?
  dandclark: It's in line with current use of live ranges
  dandclark: Spec issue states that static ranges solve this performance
  dandclark: Use of live ranges in general, here or otherwise, has
             these performance costs
  dandclark: I think it's a documentation and devrel issue
  dandclark: of when live ranges vs static ranges are appropriate
  sanketj: HTML doc also mentions this (?)
  sanketj: It has been documented
  sanketj: Static ranges are fairly new concept, previously only had
           option of live ranges

  astearns: OK, out of time
  astearns: My understanding is that with this impl experience, you
            would like to close issue no change?
  dandclark: Yes
  astearns: OK, we'll expect to close no change, and will resolve next
            week
Received on Wednesday, 18 August 2021 22:48:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 18 August 2021 22:48:42 UTC