W3C home > Mailing lists > Public > www-style@w3.org > November 2019

[CSSWG] Minutes Telecon 2019-11-06 [css-shapes] [css-text-3] [css-nav-1] [resize-observer] [css-fonts] [css-ui-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 7 Nov 2019 18:54:50 +0300
Message-ID: <CADhPm3uP5aMmVAtVwthVA2M15CV_UVfbL_BhPOCHZAaewUzvTQ@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.

CSS Shapes

  - RESOLVED: Accept the change that astearns put into the ED,
              handling the case where margin = 0 for very small values
              of shape-margin (Issue #675: Calculation of corner radii
              by margin-box and border-radius)

CSS Text 3

  - RESOLVED: The line ending trailing space is applied after bidi
              (Issue #4422: Bidi and pre-wrap end of line spaces)
  - RESOLVED: Publish a new WD of text-3


  - It was agreed that the spatial-navigation-action property will
      continue to behave as defined and does not inherit (Issue #4449:
      Proper definition of 'spatial-navigation-action' property). If
      there are use cases for the inheritance the group will re-look
      at this issue.
  - RESOLVED: Publish WD of CSS-Nav-1

Resize Observer

  - RESOLVED: To remove the constructor and remove the language about
              how to populate the object into a different point in the
              spec (Issue #3946: ResizeObserverEntry either needs to
              have its JS constructor removed, or define how its
              members are initialized when constructed)

CSS Fonts

  - RESOLVED: Add ui-sans-serif (Issue #4468: Add a ui-sans-serif
              keyword to go with ui-serif)


  - RESOLVED: Add pointer-events to css-ui level 4 (Issue #4438: Spec
              the pointer-events property for non-SVG elements)


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Nov/0000.html

  David Baron
  Amelia Bellamy-Royds
  Elika Etemad
  Simon Fraser
  Daniel Holbert
  Jihye Hong
  Sanket Joshi
  Brian Kardell
  Daniel Libby
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Cameron McCormack
  Devin Russo
  Jen Simmons

  Christian Biesinger
  Oriol Brufau
  Emilio Cobos Álvarez
  Syed Idris Shah
  Dael Jackson
  Manuel Rego Casasnovas
  Florian Rivoal
  Christopher Schmitt

Scribe: myles

  astearns: We'll skip transforms and the table row issue today.
  astearns: Additional changes?
  fantasai: The lists-3 issue needs a concrete proposal or set of
            proposals, so we shouldn't discuss it today

CSS Shapes

Calculation of corner radii by margin-box and border-radius
  GitHub: https://github.com/w3c/csswg-drafts/issues/675

  astearns: This is a small change to existing change dealing with an
            edge case when margins hit 0. There was some discussion.
            The person who raised the issue seems okay with the
            change, as does dbaron. I wanted to have a WG resolution.
  astearns: Anyone have anything to add?
  astearns: The proposed resolution is we accept the change that I put
            into the ED, handling the case where margin = 0 for very
            small values of shape-margin
  astearns: objections?

  RESOLVED: Accept the change that astearns put into the ED, handling
            the case where margin = 0 for very small values of

CSS Text 3

Bidi and pre-wrap end of line spaces
  GitHub: https://github.com/w3c/csswg-drafts/issues/4422

  astearns: Suggestion is to resolve to accept the PR
  fantasai: The PR says that we do the hanging after bidi. The
            implications of exactly what that results in in the test
            cases in the issue depends on implementations fixing their
            bidi implementation to add a rule that Safari implements
            correctly. As far as the spec is concerned, we need a
            clarification that the line ending trailing space is
            applied after bidi.
  fantasai: There are some bugs in implementation but those are out of
            scope for this issue.
  <AmeliaBR> The one-line PR, for reference:
  myles: +1
  astearns: This is just fine to resolve to accept the PR. Objections?

  RESOLVED: The line ending trailing space is applied after bidi

Publish WD of CSS-Text-3

  fantasai: We should publish a WD. There are other issues but they
            aren't about to close
  astearns: This is a standard WD?
  fantasai: Yes
  astearns: Objections?

  RESOLVED: Publish a new WD of text-3

  <ChrisLilley> +1

  heycam: I recall discussions about automatic allowance for
          publishing WDs. Discussion maybe a year or so ago. Is that
          the case?
  astearns: There is the tooling in place for editors to just update
            working drafts continuously. I don't recall where we as a
            WG settled when we last discussed this.
  <ChrisLilley> yes, you can
  fantasai: I can find it if you give me a few minutes. The policy is:
            If the differences since the last WD are purely in tone or
            if there are specific things that the WG resolved in
            (wording) then you can just publish it because it's
            reasonable that the WG has consensus on it. If there are
            issues that may or may not have come before the WG, or the
            resolution was a general statement that had to be
            translated, then we're still going to request a WG
            approval for the WD publication
  <heycam> thanks

  astearns: For text-3, I expect there are only resolutions.
  fantasai: Nope. There are minor fixes, and some general resolutions
            rather than specific resolutions. It's not as clear cut.
            Not everyone has had a chance to review everything.
  astearns: For css-shapes, it would not have been okay to publish a
            new WD until just now when I got a resolution for the
            latest change that I made. Everything else I added to the
            draft has a resolution
  fantasai: Yes. Shapes is CR also.
  AmeliaBR: If you want to review this heycam, it was a TPAC we made
            these resolutions about publishing rules.
  AmeliaBR: If I find the minutes I'll stick a link in
  <chris> Amelia, https://wiki.csswg.org/spec/publish
  <AmeliaBR> thanks Chris (probably a better reference than the
             minutes, anyway!)


Proper definition of 'spatial-navigation-action' property
  GitHub: https://github.com/w3c/csswg-drafts/issues/4449

  astearns: In the issue, you asked florian for an opinion. We don't
            have his opinion, and he's not here.
  astearns: Should we discuss this now?
  jihye: I also asked another member of CSSWG about this issue. This
         is general CSS questions. I think we can proceed
  astearns: OK
  jihye: This issue is about spatial navigation actions, and CSS

  jihye: Before going into the detailed discussions, I'd like to
         introduce spatial navigation actions. They are a CSS
         property, which can define the behavior for a scrollable
         element. The spatial navigation behavior is when a scrollable
         element has focus, and the user triggers spatnav, if there is
         a focusable element in the scrollable element, the focus goes
         to the focusable element. Otherwise, scrolling happens.
  <jihye> https://wicg.github.io/spatial-navigation/demo/sample/api_spatial_navigation_action.html
  jihye: If the focus value is given to this property, spatnav on the
         scrollable element only works to move. If the scroll value is
         given, spatnav only works for scrolling the scrollable
         element. You can see how it works with this link ^^^
  jihye: I'd like to ask that if the definition of this property is
         proper. Currently, the spec describes this property as "which
         is applied to scroll element, and not inherited" but the
         point that I'm confused about is the attempted behavior of
         this property is it also affects the spatnav behavior for
         children element of the scrollable element. The description
         says it is only applied to the scrolled element, not all
         elements. So it sounds like the property will not affect the
         children element of the scrollable element, which the spatial
         navigation action property is specified.

  jihye: It seems like the intended behavior and the description in
         the spec don't match. Is this proper or not?
  myles: I thought we resolved to get rid of all the "applies to" lines
  <fantasai> no, we resolved to get rid of Media Type
  AmeliaBR: There was some discussion about whether it was normative
            or informative. The question here is you want to change it
            so the property both affects the scrollable container
            directly and the children of the scrollable container as
            far as how it affects whether they trigger scrolling on
            the parent
  jihye: I researched another CSS property which can affect its
         children elements. From my understanding, that property
         creates a stacking context, but that property is about
         layout. But this spatnav property isn't about layout, so it
         doesn't seem like a match
  AmeliaBR: We don't have anything equivalent
  AmeliaBR: Any other CSS property that defines whether a scroll is
            triggered separate from whether a scrollbar appears on
            this element or a parent element
  AmeliaBR: It seems to me perfectly natural to say that this also can
            work on a property on a child element and it affects the
            scrollers going up. The concern then is what happens if
            you have nested scrolling containers. Is there a way to
            control where that scrolling affect stops? Vs if you
            specifically set the property on the scroll container
  AmeliaBR: Then it's more obvious what it applies to, because nothing
            bubbles up like an event

  bkardell: If you have focusable items ....
  bkardell: As I understand it, the reason this is desirable is
            because you have potentially a limited number of controls.
            You don't have tab buttons and shift-tab and things like
            that, so we want to define how that works with a d-pad
            controller. "spatially" navigate. So you want to move
            focus with those sorts of mechanisms. But in this example,
            you have a scroll container that contains focusable items.
            But if you use scroll, does it make it effectively not
            focusable anymore?
  bkardell : How would someone focus the child?
  jihye: If the value is "scroll" of this property, then the focus
         will not move inside or move between the child elements in
         the scrollable element. But pressing down or up arrow key
         will only scroll the scrollable element. If the focus or auto
         value is given to this property, the child element inside the
         focusable element will be focused and the focus will move
         between them.
  bkardell: right.
  AmeliaBR: The issue isn't that you can't focus elements when you're
            using the scroller thing, it's that you don't jump to the
            next focusable element, you jump to the next element
            whether its focusable or not, and in that way you end up
            scrolling the scroll container. Otherwise, it skips the
            next items and jumps to the next focusable one
  jihye: Yes, that's right
  bkardell: "auto" makes sense to me, "focus" makes sense to me. They
            are a different experience of the same thing. But "scroll"
            ... do we have other CSS properties that prevent your
            normal focusability?
  myles: we have display:none...
  bkardell: but it's not on the screen
  jihye: The "scroll" value is at risk. It can be useful when there is
         an iframe which can scroll but the user doesn't want to move
         inside it.
  jihye: But I think this is a little bit out of the topic that I
         wanted to discuss.
  jihye: I wanted to discuss - this property can apply to child
         elements of scrollable elements. Is this proper or not?

  heycam: Generally, the "applies to" line is informative and not
          normative (as AmeliaBR was saying). It's just a general
          description of where you expect the property to have an
          effect. The behavior of scrolling will depend on the child
          elements and their focusability. It makes sense to say it
          applies to the scrollable element. The rest of the
          definition can say what it wants about the child elements
          and how they are focused.
  <fantasai> yes, it's about on what elements can you set the property
             to have an effect
  AmeliaBR: You mentioned in the issue, if we switch to that model
            where its a property of the individual elements rather
            than a property of the scroller, it needs to be inherited.
  AmeliaBR: It would be a normative change
  myles: Can we make this match how scroll snapping works?
  AmeliaBR: How does scroll snapping work?

  fantasai: scroll-snap sets something on the scroll container to
            define how snapping happens, and there are additional
            properties on child elements about whether that child
            should be paying attention to it. <provides an example>
  myles: Sounds to me that this should go on the scroller for spatnav
  astearns: Another argument for putting it on the scroll container
            and having it not inherit, is we might get an incoherent
            set of things to do if the some subset of elements
            disagree about which value is specified. Inheriting to the
            children means the children can override what's on the
  jihye: If we match the spatnav action navigation property with
         scroll snap, then we'll change the definition to say it
         applies to all elements and its inherited?
  astearns: I'm arguing for it to stay the way it is. Where it applies
            to scroll containers and does not inherit. You can define
            how the children behave as saying "look at your nearest
            ancestor that its a scroll container and see what its
            spatnav action is"
  jihye: It means that the current definition of the spec is
         reasonable and doesn't have to change.
  astearns: Yes
  AmeliaBR: Yes, unless you can come up with a specific example where
            you'd want the behavior to change partway through a
            scrollable container. I don't know what that might look
            like. Where you actually want different children to have
            different behaviors.
  astearns: Can you think of a case where you'd have a scroll
            container where some of its children would want to focus
            and others would want to scroll?

  astearns: Why don't we resolve on this issue, saying we are not
            going to change the definition of how
            spatial-navigation-action at this point, but if come up
            with a use case for making the property inherit, we can
            change it at that point.
  jihye: Okay
  jihye: The spatial-navigation-action property behaves as defined,
         and does not inherit.

  astearns: Is there an issue for the scroll value? Is that why it's
            at risk?
  jihye: It seems like the scroll value is less important than other
         values such as "auto" or "focus". This is the main reason.
  astearns: bkardell could I have you take a longer look at this, and
            if you have concerns about the "scroll" value changing the
            focus behavior, have you raise an issue on it?
  bkardell: Yes. It's been a while since I looked at this.
  bkardell: In Toronto, we had David Bokan from google present an
            interesting related thing. jihye, have you worked with him?
  jihye: Yes, I talk with him regularly. We are investigating about
         that concept. I think this concept is not mature enough. We
         have to think about more details about that. We are working
         on that.
  bkardell: He would be good to review the question I raised. I can
            talk to him
  jihye: Thank you.

Publish WD of CSS-Nav-1

  jihye: I'd like to publish a WD of spatnav. It's FPWD. There have
         been changes in the spec such as adding a new API for spatnav
         functions, and modifying the processing model which is the
         default behavior of spatnav.
  jihye: I think the spec is stabilized. It has been implemented in
         blink. Also there won't be the significant change in the spec
         for a while. It would be nice to publish the new WD.
  <chris> +1 to publish
  astearns: I think we should update the draft. Also, I do see that
            there is not a "changes" section. We don't really require
            a changes section on normal WDs, but it's a nice thing to
            have for people who have not been keeping up.
  jihye: I will add it.
  astearns: Any other concerns?
  chris: This will be a FPWD?
  astearns: No. Regular WD.

  RESOLVED: Publish WD of CSS-Nav-1

  astearns: Thank you jihye for your work on this.

Resize Observer

ResizeObserverEntry either needs to have its JS constructor removed,
    or define how its members are initialized when constructed
  github: https://github.com/w3c/csswg-drafts/issues/3946

  dlibby: This issue is a historical oddity. WICG spec language made
          it into an ED, despite it not being implemented in blink.
          Gecko realized this discrepancy, and after some debate,
          didn't implement this constructor. There's some conversation
          about what the constructor should be because it doesn't fit
          into JS. The point of resize observer is to give
          asynchronous notifications when layout changes to the size
          of elements
  dlibby: So given that this doesn't exist in either current
          implementation, it seems worth removing from the spec and
          updating the language in a different section about
          implementation details of how a browser would populate a
          resize observer entry at runtime
  bkardell: There's an implementation in webkit as well.
  dlibby: I'll check it
  smfr: Is there a WPT test?
  dlibby: No.
  AmeliaBR: Seems easy to remove this from the spec. If there is
            desire for it later, add it back in.
  AmeliaBR: But it doesn't seem like we're blocking anything for the
            future to remove it for now
  astearns: Anyone want to argue for keeping it in?

  RESOLVED: To remove the constructor and remove the language about
            how to populate the object into a different point in the

CSS Fonts

Add a ui-sans-serif keyword to go with ui-serif
  GitHub: https://github.com/w3c/csswg-drafts/issues/4468

  AmeliaBR: With the new ui- font family keywords. Based on the
            resolution, we had ui-serif, ui-monospace, and ui-rounded
            keywords. ui-sans-serif wasn't initially added because the
            system ui fonts of current systems are all sans-serif, so
            we didn't need a new keyword
  AmeliaBR: Logically there's nothing in system-ui that says it must
            be sans-serif, and in the future, system-ui might be
            serif. A more logical system would have ui-sans-serif
            keyword, so if you care about it, you can specify it
            explicitly, vs system-ui gives you the default system font
            regardless of its styling. In most systems these would map
            to the same font
  chris: I agree it's currently not like that, but it could change in
         the future
  chris: I agree with this suggestion
  <fantasai> +1 to proposal
  chris: We've already clarified that these names can all point to the
         same thing

  myles: Mildly against this just because it's building infrastructure
         for a computer that doesn't exist
  astearns: I can see the future possibility, we could add the
            additional keyword when it becomes necessary.
  chris: But people will use it in the interim to mean sans-serif will
         be surprised.
  astearns: I'm not sure people aren't already going to make that
            assumption regardless of another keyword
  fantasai: But this means they have to make that assumption
  chris: It lets authors be more precise
  fantasai: If we don't add this, then they have to make the
            assumption. If we add this keyword, they don't have to
  astearns: I'm not strongly opposed to adding it
  plinss: I have slippery slope concerns here. It sounds like we're
          re-inventing things we had in the 90s. <lists many system-
          prefixed font names like dingbats and swashes>

  AmeliaBR: We've already made the agreement on adding a set of
            stylistic system fonts. Do we acknowledge that system-ui
            is by default a sans-serif, or do we include a sans-serif
            in a stylistic set of keywords
  chris: The people arguing against this are arguing against the
         keywords in the first place
  plinss: I don't think it should be serif or sans-serif
  chris: Yes, system-ui shouldn't include that. But we've already got
         ui-serif and ui-monospace. Those are 2 of the generic font
         families. I don't think anyone is asking for more
  plinss: People will ask for stylistic, semantic implications, one
          being used for body text or headings ... again, it seems
          like it's going to get out of hand. Not a strong objection,
          I'm just concerned
  chris: I can understand that.
  astearns: I'm not a big fan of ui-serif and ui-monospace, but we
            have decided to add them, and I'm somewhat convinced by
            the argument that, since we have ui-serif, we should also
            have ui-sans-serif to future-proof
  plinss: We shouldn't have ui-serif in the first place. The
          connotations of what it means will change over time. I don't
          see how that's getting you anything
  plinss: ui-monospace has a functional difference.

  astearns: Does anyone want to really object? Or shall we put it in
            for now?
  <fantasai> I think given we have ui-serif/ui-rounded/ui-monospace, I
             think it's important to have ui-sans-serif
  astearns: The proposal is to add ui-sans-serif (as a sibling to
  astearns: Sounds like we're leaning toward it.
  astearns: Objections?
  plinss: I'd like to reconsider ui-serif
  astearns: Oh, certainly, we can re-litigate adding the pair of them,
            but if we have one, the proposal is we should have the
  plinss: I agree.
  chris: Do these set size and style as well?
  AmeliaBR and myles: no

  RESOLVED: Add ui-sans-serif


Spec the pointer-events property for non-SVG elements
  GitHub: https://github.com/w3c/csswg-drafts/issues/4438

  AmeliaBR: The pointer-events property defines whether an element is
            clickable or not. If something has pointer-events: none,
            it's treated as transparent for clicks and you can click
            through it for whatever's underneath. It's not defined in
            any CSS spec. It's defined in SVG, which also has lots of
            extra values that relate to fill areas or stroke areas are
            clickable and other variations
  AmeliaBR: The reason to discuss this is we got a bug report on SVG
            complaining that a particular behavior wasn't defined, and
            that behavior wasn't SVG-related. It was about CSS boxes
            and stuff that wasn't SVG related. So, what about writing
            up a spec for pointer-specs?
  chris: SVG would be happy to see it turn up in another spec, so they
         can delete it from theirs
  AmeliaBR: One thing that chris did discover when we were discussing
            it, there was a spec text in CSS-UI that got pulled when
            trying to stabilize that spec because speccing out the
            actual details turned out to be complex. It seemed to have
            been pulled and never reappeared in a later draft.
            Speccing it won't be nice and easy because we have lots of
            legacy behavior
  chris: This is widely implemented
  AmeliaBR: We have lots of implementations of a property without a
            spec. But we should still do it, difficult or no
  <heycam> +1 to moving pointer-events to css-ui
  chris: This is valuable by itself to define what pointer event
         handling is for CSS

  astearns: Since the editor of css-ui is not on the call, we can pile
            it on him
  astearns: But, chris, you mentioned SVG would like to delete it ...
            you'd only be deleting a tiny part of it, because all of
            those other values would still be an add on for SVG
  chris: They would until css-fill-n-stroke. So those parts would move
  astearns: I would expect that the current work that we are proposing
            for css-ui would only be the currently supported values.
  AmeliaBR: That sounds like a good strategy. The SVG spec would
            continue to be a partial definition adding in the extra
  chris: Yes. which is fine.
  fantasai I do what I can
  astearns: Anyone concerned about defining pointer-events in a CSS

  RESOLVED: Add pointer-events to css-ui level 4

  AmeliaBR: One final note: The first step is going to be putting
            together some tests to understand existing behavior and
            compatibility issues. If anyone wants to take the
            initiative to look at their implementation, that would
            be great
  AmeliaBR: We only have parsing tests in WPT
  astearns: Thanks everyone! Next week is a non-APAC time.
Received on Thursday, 7 November 2019 15:55:21 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:12 UTC