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

[CSSWG] Minutes Telecon 2019-09-04 [css-mediaqueries] [css-overflow] [css-lists] [css-display]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 5 Sep 2019 08:38:15 -0400
Message-ID: <CADhPm3ukAKAQGAMzwX+j_8akzB+upeCLztaqC+uPmiN3OuRUjA@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.

Process updates from AB

  - fantasai introduced the proposed process changes that will be
      presented formally at TPAC. The presentation is here:
      Mailing list is: https://lists.w3.org/Archives/Public/public-w3process/
      and GitHub for issues is: https://github.com/w3c/w3process/issues
  - The goal of this new process is to make it easier to keep CR and
      REC level specs up to date by reducing the steps needed for
      Director approval and changing patent review triggers.

Media Queries

  - RESOLVED: Add navigation controls media query to MQ 5 (Issue #4187)
  - The group was leaning against issue #4162 (Expose User Preference
      Media Queries as HTTP Client Hint or HTTP Header) because the
      general feeling is that is would not have a significant benefit
      and may be another vector for fingerprinting. These concerns
      will be added to GitHub and discussion will continue there.

CSS Overflow

  - The main part of issue #4123 (It should be detectable whether an
      element ellipsized the text) can be closed, though there is a
      sub-issue on some APIs not reporting subpixels which will need
      to be addressed still.

CSS Lists

  - RESOLVED: No change re computed value of list-style-type (Issue
              #4210: Compute non-existent `list-style-type`
              <counter-style> to `decimal`?)

CSS Display

  - RESOLVED: Do not add table-cell/table-caption as display-outside
              values at this time (Issue #3940: Make `table-caption`
              and `table-cell` <display-outside> values)


  - Anyone unable to attend a call next week due to travel to Japan
      should say so early on so a determination can be made if there
      are enough people to get quorum next week or if the call should
      be canceled.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Sep/0004.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Brian Birtles
  Oriol Brufau
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Dean Jackson
  Peter Linss
  Myles Maxfield
  François Remy
  Florian Rivoal
  Devin Rousso
  Jen Simmons

  Rachel Andrew
  Christian Biesinger
  Dave Cramer
  Benjamin De Cock
  Dael Jackson
  Cameron McCormack
  Christopher Schmitt

Scribe: AmeliaBR
Scribe's Scribe: fantasai

  astearns: Any agenda additions?
  astearns: We may push multicol issues to next week / TPAC.

Process updates from AB

  <fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_16
  fantasai: We will be presenting these slides ↑ at TPAC
  <fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
  fantasai: Maintaining a spec that is in late stages up to date is
            difficult. Want to reduce overhead of frequent updates.
  fantasai: While maintaining wide review & making sure that is
  <fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
  fantasai: Proposal is to update W3C Track Process. E.g., get royalty
            commitments earlier in the process (CR or WD).
  fantasai: For CR, want to automate more routine Director approvals
            for updates — e.g., if there has been no disagreement/
  fantasai: Ideally, you just fill out a form. If all checks are OK,
            the director isn't going to object anyway.
  fantasai: But frequent updates are a problem for patent review;
            don't want patent reviews more often than 6 months. So we
            want to split CR publication updates from reviews.
  fantasai: While do the approvals & reviews periodically, but not
            every time you push a minor update.
  fantasai: We'll also be formalizing the system that Tantek &
            (missed) started, annotating spec with notes about what
            has changed and why. So the review is more predictable.
  fantasai: So we can issue a call for review on those specific
            changes. And everything can be reviewed at the same time.
  fantasai: (This is specifically about changes to a REC spec)
            Changes can go through full review without re-reviewing
            entire spec.
  fantasai:  For these easier updates to REC specs, you can only do
             this if chartered for "extensible specs".
  fantasai: Some specs have a need to be predictable and fixed.
  fantasai: (something about registries. I got behind, sorry)
  <florian> thanks fantasai for the nice summary

  astearns: How do we give feedback?
  <fantasai> https://lists.w3.org/Archives/Public/public-w3process/
  <fantasai> https://github.com/w3c/w3process/issues
  fantasai: Here is the mailing list & process repo.
  astearns: Are issues on the repo recommended?
  fantasai: Yes. Minor questions about the slides can be sent direct
            to me. But issues on repo.

  astearns: If these changes go through, should CSS WG change to
            Living Standard specs for each module?
  fantasai: I'm mostly happy with how we work with versioned specs.
            Switching to updating recs would mean all new development
            would need to be isolated to note boxes until ready to
  fantasai: And I wouldn't want to change until we see how this works.
            But other changes will help.
  TabAtkins: I mostly agree. But I'd like to get CSS Syntax as a
             permanent REC. So that all updates get immediately
  fantasai: And we're not adding many features to Syntax.

  <florian> https://w3c.github.io/w3process/everblue/
  florian: One comment about that repo link: Most of what fantasai
           described hasn't yet been merged into the main branch.
  florian: But most of it is in this branch of the Process [link]
  florian: except a few bits, e.g. ...
  florian: the bit about only some CRs triggering reviews.
  astearns: I'd add, if you are an AC rep for / part of an org that
            cares about patent law, make sure your lawyers see this
            presentation. It doesn't have all info they need, but they
            should know what's coming.

  <fantasai> https://lists.w3.org/Archives/Member/w3c-ac-members/2019JulSep/0024.html
             Patent Policy Survey
  fantasai: There's an open survey for AC reps on Patent Policy. One
            of many surveys likely going forward.
  fantasai: (brief summary of Patent Policy survey questions)
  <fantasai> Open questions other than the patent policy application
  <fantasai> Depending on results, we may be able to update things
             more smoothly.

Media Queries

Proposal for Navigation Controls
  github: https://github.com/w3c/csswg-drafts/issues/4187

  TabAtkins: Request for a way to tell if there is a back button or
             similar (e.g., PWA shells don't always have this), as a
             media query. Normal browser it would be true. PWA may be
             false, so you might want to add a back button in your
             page UI.
  TabAtkins: For now, the request is only for back button, but the
             proposal is designed in an extensible way.

  dino: I don't understand the scope of "back button". Would a
        back-swipe gesture count? Generally support the idea, but we
        need to define it.
  dino: I can also see other use cases, like is there a share button?
  TabAtkins: Question on back swipe is interesting. Not all UI options
             are equal. Keyboard controls might not be well known. But
             depends on the platform.
  dino: That's just an example. My concern is that the query should
        focus on the functionality rather than the "button" nature.
  <jensimmons> +1 to being generic... not too focused on How People Do
               Things in 2019.

  florian: Individual parts of the media query are useful. But how
           would it be collapsed to a boolean level, without breaking
  TabAtkins: Current proposal is boolean means any navigation control,
             of which back button is the simplest. If we can't make
             that assumption, that the boolean mode is probably

  myles: Some browsers are designed as standalone apps; other browsers
         integrate with a system, like an iOS webview. Whether there's
         a backbutton or not depends on the embedding app. Webview
         doesn't know, may be difficult to implement.
  TabAtkins: In that case, if the rendering agent doesn't know, they
             should probably be conservative & assume there isn't
  florian: And maybe embedded web views could add an API for the
           environment to tell them if they're handling navigation.
  myles: That doesn't help with existing apps
  florian: But it could help in combination with sensible defaults.
  TabAtkins: And the default wouldn't be any worse than today.

  Rossen: Is there a reason we're only talking about back button right
          now & not navigation controls as a group?
  TabAtkins: No reason to avoid other features. It's just that
             back-button has the strongest use case & is the one that
             is most commonly available.
  TabAtkins: But I made sure syntax would work with other buttons, too.
  TabAtkins: If we find anything that is really important we can add
             them too.
  Rossen: If we are only doing back-button for now, why not just use
          that in a boolean sense?
  TabAtkins: I didn't want "any"/"none" because that could be more
             complicated for adding things.

  AmeliaBR: Would a URL bar be included inside this general concept of
            navigation controls?
  TabAtkins: If people think that's a useful thing to expose, sure
  TabAtkins: Number of possibilities we could
  AmeliaBR: URL bar allows copy/paste of current URL and also allows
  AmeliaBR: Also can be used to share
  TabAtkins: Interesting question of whether that should be distinct
             from share button
  florian: Wrt URL bar, I could imagine a UI which has URL bar only
           but not back button
  florian: so assumption of always having a back button might not be
  TabAtkins: Theoretically, but I don't think that will happen
  florian: Without a time machine

  drousso: One clarification: Are we talking about the *presence* of
           these buttons, or whether they are enabled? E.g., in a new
           tab, back button is disabled.
  TabAtkins: I could be convinced either way, I think it's best to say
             "is it present", regardless of whether currently
             disabled. Probably don't want to toggle this on and off a
             lot. Might be used via JS to download extra scripts.

  AmeliaBR: What is the request at this time?
  TabAtkins: To add to draft. Can discuss specifics later.
  astearns: Any objections to adding to a media queries draft?

  RESOLVED: Add navigation controls media query to MQ 5

  astearns: We should also get in touch with the original proposer
            (fallaciousreasoning) for giving credit.

Expose User Preference Media Queries as HTTP Client Hint or
    HTTP Header
  github: https://github.com/w3c/csswg-drafts/issues/4162

  TabAtkins: Idea is that some of the preference media queries trigger
             fairly substantial changes to a page. E.g., reduced
             motions might trigger more than just CSS fix-ups.
  TabAtkins: If you want to make changes on first display, need that
             before the page downloads.
  TabAtkins: Idea is to pass this info to server as a client hint &
             server can respond with the good stuff
  TabAtkins: Some debate on the invalidation logic. The settings can
             change over the course of a session.
  TabAtkins: But overall, idea seems reasonable. But I'm not well
             versed on client hints.

  dino: My preference is that this shouldn't happen. Media queries are
        supposed to be dynamic & can cause page changes.
  <tantek> +1 dino
  dino: Changing which JS you download doesn't seem to conform.
  dino: Could also make pixel tracking techniques even easier.
  TabAtkins: I disagree that changing downloads is a minor benefit.
             Could help make sure that initial payload is as small as
             possible, good for many use cases.
  TabAtkins: Already, sites can *try* to do this by setting server
             cookies based on previous MQ results. That's more likely
             to mess things up than using HTTP headers.

  <tantek> CSS is a tiny fraction of what G sends down compared to the
           heaps of JS. Not buying the "send less CSS" argument as a
           practical impact here
  <tantek> LMK if there's a noJS version of G properties that has well
           designed CSS for normal/dark mode and what % of the page
           download that would impact

  drousso: Using the example of dark mode, downloading only a
           slimmed-down dark mode CSS. If that MQ changes, then the
           cache invalidation must need to handle the change in state,
           to know what to download.
  TabAtkins: I suspect this is similar to state handling in many JS
             based apps, but I'm not an expert.
  drousso: Would probably need to add query parameters to CSS so that
           it can be invalidated.

  dino: I think the savings for cutting out a bit of CSS is probably
        not worth the overhead. Cookie tracking might not be that bad
        an alternative.
  <tantek> +1 dino thanks for making the right argument. sending both
           normal/dark CSS rules are tiny compared to all the rest of
           the page load size
  TabAtkins: Sounds reasonable. Can you add these comments to the
             issue so we can close it with reasons?
  <tantek> I'd say, the additional fingerprinting from Client Hints
           for this are not worth the fractional anticipated
           performance gain by less CSS compared to the massive JS in
  florian: Another concern is privacy. If we allow this on HTTP as
           well as HTTPS, preferences get leaked everywhere. Also,
           logged on all sorts of servers

  dbaron: I am also generally skeptical. But I think some arguments
          given here aren't correct & what to make sure those are
          clarified. Client hints spec integrates with vary headers,
          so that caching can handle it. And designed so
          fingerprinting is active rather than passive as suggested.
  dbaron: I'd also want more details on proposal anyway before
  astearns: OK. So let's follow-up on issue.

CSS Overflow

It should be detectable whether an element ellipsized the text
  github: https://github.com/w3c/csswg-drafts/issues/4123

  TabAtkins: Issue comes down to some APIs not reporting subpixels,
             which can give weird results sometimes. That's worth
             addressing but I think we can close main issue.
  florian: Worth mentioning that the use case is JS code to *show*
           ellipsized text. If more browsers offered that as a
           built-in feature, wouldn't need to hack around it.

CSS Lists

Compute non-existent `list-style-type` <counter-style> to `decimal`?
  github: https://github.com/w3c/csswg-drafts/issues/4210

  TabAtkins: fantasai discovered this when cleaning up lists spec.
             Issue is what should computed style be if you set the
             list-style-type to a custom ident that doesn't currently
  TabAtkins: The used style is decimal. But computing that eagerly (as
             Firefox used to do) can be problematic, since @-rule
             could be added later.
  TabAtkins: I don't think any other browsers yet implement custom
             idents; they reject at parse time. I think best to follow
             current Firefox. Computed value is the custom ident.
  astearns: There are Firefox folks in thread pointing out that
            current behavior wasn't really intentional.
  TabAtkins: That's OK. It's still good behavior. Let's spec it
  dbaron: If Emilio's OK with it, I'm OK with it.
  TabAtkins: He wrote the current Firefox behavior, so I hope so.
  astearns: And this will just be no-change to current spec.

  RESOLVED: No change re computed value of list-style-type


  <dbaron> btw, are we having a call next week? (Will a lot of people
           be en-route to Japan or already there?)
  <florian> a call next week would not be very convenient for me, but
            I could probably make it
  astearns: I was planning to have a call next week. dbaron notes many
            will be travelling.
  astearns: We can try to have a call, but see if we will have quorum
            or not.
  <florian> I would like to know in advance, cause staying up till the
            middle of the night and then not have a call isn't nice

CSS Display

Make `table-caption` and `table-cell` <display-outside> values
  github: https://github.com/w3c/csswg-drafts/issues/3940

  fantasai: Mats wanted to support allowing flex/grid inside table
            caption. Maybe also table-cell, but there are more layout
            issues there, so the focus is on caption right now.
  TabAtkins: Chrome would have issues with doing this for table cell,
             although that makes me sad. But I think caption is OK.
  iank: I think it's OK to do this with table-caption. Will need to

  dbaron: Do table captions affect the table size, or does the table
          size affect the table caption's size?
  fremy: They can in that if the caption is wider than the table, the
         table gets stretched to the wider size.
  florian: That doesn't seem like a very hard interaction to handle.
  dbaron: The harder interaction would be if the table layout affected
          the caption size.
  iank: Was there any demand from authors, or just requesting for
  iank: Can we delay this, then?
  florian: So, no to table-cell since it's too hard. And not yet to
           table-caption as there isn't strong enough demand.

  astearns: objections to wontfix?

  RESOLVED: Do not add table-cell/table-caption as display-outside
            values at this time

Scheduling (part 2)

  fantasai: It would be nice to know before next meeting if there will
            be a meeting or not. Especially for those calling in very
            late from Japan.
  <tantek> posting regrets for next week's call now :)
  <dbaron> Definite regrets from me -- can't do a 1am-2am call and
           then be ready for a 9am all-day TAG face-to-face meeting
  <iank> regrets for next week.
  <smfr> i can show up
  <plinss> regrets for next week
  <myles> I will not attend next week. Tokyo FTW
  <florian> I don't wanna show up next week
  <AmeliaBR> regrets for next week. I will be in a plane if all is as
  <fantasai> next week is inconvenient but possible for me, week after
             TPAC should be no problem
Received on Thursday, 5 September 2019 12:39:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:16 UTC