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

Minutes Telecon 2017-11-01 [css-values] [css-ui-3] [css-text-decor] [css-cascade] [cssom] [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 1 Nov 2017 20:44:28 -0400
Message-ID: <CADhPm3tBn5dG7SoxHzRJUtS+BNA8qxQuh+-8+WBeDJidoNNRLQ@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.

Values & Units

  - astearns created a bunch of tests for clamping behavior and
      requested review before TPAC:


  - RESOLVED: Publish an updated CR of CSS UI 3.

Text Decoration 3

  - Text Decoration 3 should be ready for CR as soon as
      internationalization finishes their review.

CSS Cascade

  - RESOLVED: Remove this (Override Declarations) from both levels of
              CSS Cascade and replacing the reference with a note.


  - RESOLVED: Take 'stretch' and 'fit-content' to level 4 and drop a
              note in level 3 noting where they went and pointing to
              next level.
  - The github issue (https://github.com/w3c/csswg-drafts/issues/1913)
      to restrict 'stretch' and 'fit-content' to width/height and
      max-* (excluding min-*) didn't have any strong opinions.
      Individuals were encouraged to review and see if they can think
      of a use case before TPAC.


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

  Rachel Andrew
  David Baron
  Tantek Çelik
  Elika Etemad
  Dael Jackson
  Dean Jackson
  Tomoya Kimura
  Myles Maxfield
  Michael Miller
  François Remy
  Melanie Richards
  Florian Rivoal
  Alan Stearns

  Tab Atkins
  Dave Cramer
  Benjamin De Cock
  Tony Graham
  Thierry Michel
  Naina Raisinghani
  Shane Stephens
  Sergio Villar Senin
  Greg Whitworth
  Eric Willigers

Scribe: dael

Agenda Setting & Announcements

  astearns: I have 5 minutes after. We can start and get through what
            we can.
  astearns: Any extra items?

  florian: I have a small one. Nothing extra to discuss, but something
           remind people.
  florian: I asked people a while back to review my line-height
           testing. I'm not seeing anything in github. Discussion will
           be better if people look.
  astearns: Is it on TPAC agenda?
  florian: I'll make sure it is.
  <florian> https://github.com/w3c/csswg-drafts/issues/1796
  <florian> (and the issues linked from that one)

  dino: I wanted to let people know we update our blog post about what
        was called constant() and now called env() and the beta OSs
        that shipped yesterday support that.
  <fantasai> \^_^/
  dino: Our shipping impl is now in line with the group decision.
  astearns: Thanks for that quick change.

Spec Rec Progress

Values & Units

  astearns: I needed to make some tests for clamping at used value
            time for V&U. I finally got to that today.
  <astearns> https://github.com/w3c/csswg-drafts/issues/434#issuecomment-341267463
  astearns: I posted my tests here ^
  astearns: I think this is something we should review at TPAC to give
            people time to take a look and see if there's something
            wrong with my tests.
  astearns: Anything else to volunteer?


  florian: CSS UI we resolved to try and go to PR. Chris and I reached
           out to PLH to see if we could do PR, he thinks not due to
           changes and we should do a short CR loop.
  <tantek> wow what were the normative changes?
  florian: Normative changes were on cursor: auto which added that you
           should look like text over selectable as well as editable
           text. Minor but normative.
  <tantek> but it was non-substantial because it was done to match
  <tantek> that makes no sense, that category of normative change is
           supposed to be ok from CR->PR
  <tantek> frustrating
  florian: The other normative seemed like the kind that wouldn't
           block, but that's the one that would be trouble. Normally
           that's Ralph's call, but PLH doesn't believe Ralph would
           rule differently.
  florian: I'd rather go along with the process then try and argue. I
           would rather try and change process later.
  <tantek> Florian can you add me on any email thread on this?
  <tantek> This is inconsistently enforced
  <tantek> No this is not part of the process formally
  <tantek> This is plh being more nitpicky than he should
  <tantek> and inconsistently with other CR->PR transitions
  astearns: tantek I'll forward the email thread.

  fantasai: What's the writing modes status?
  astearns: Before that, shall we resolve on publishing updated CR of
            CSS UI?
  astearns: Objections?

  RESOLVED: Publish an updated CR of CSS UI.

  <tantek> updated CR would add 4 weeks right?
  <florian> tantek: yes, +4 weeks
  <tantek> and then we may run into publication bans
  <tantek> ugh
  <gsnedders> tantek: if there's a new exclusion period, yes

Writing Modes

  astearns: Writing modes.
  astearns: Who took on the publishing tasks?
  fantasai: No idea.
  astearns: Okay. I'm not sure either. I'll follow up on that.
  <fantasai> https://drafts.csswg.org/Transitions
  fantasai: Status on transitions page says working on how to move at
            risk features, but the edits were done a while ago. CR
            doesn't need tests, so that shouldn't be holding it up.
  astearns: I'll follow up this week and we can revisit at TPAC.
  astearns: Anything more on spec progress?

Text Decoration 3
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013

  fantasai: I have DoC for CSS 3 text decoration mostly complete. I'm
            waiting on i18n to respond. Everything has been edited in.
  fantasai: There's one issue where I don't know what to do.
  astearns: Do you expect to get more than an okay from i18n?
  fantasai: I don't know. I'll track Richard down next week.
  astearns: And does the one remaining issue need to go on TPAC agenda?
  fantasai: 16 requires i18n to say they want a change. The other one
            had concerns raised but nothing actionable.
  astearns: And the one where you don't know what to do?
  fantasai: For 16. There was a discussion on it on the mailing list
            and I asked if they wanted the issue re-opened and I
            haven't gotten a response.
  astearns: So it's waiting on feedback.
  fantasai: Yes, unless anyone knows a lot about emphasis marks they
            can comment.

  astearns: Given we have a small number of people on the call, does
            anyone feel there are items on the agenda that should
            wait? Or are there some we can get through?

CSS Cascade

Are 'Override declarations' still a thing?
  github: https://github.com/w3c/csswg-drafts/issues/1385

  fremy: From the look I took it's not referenced by CSS. I think it's
         fine to drop, but I don't know if somebody has a strong
         opinion. Not easy without enough people on the call.
  dbaron: I think we (Gecko) did remove the override stylesheet API if
          we had it.

  astearns: Let's leave it as that. We have two options and we'll come
            back when there's more people.
  fremy: Or we can resolve and if someone disagrees we re-open.
  fremy: In the interest of progress.
  astearns: That's fair. I would have liked to see an opinion from Tab
            with the issue.
  fantasai: Tab and I don't have an opinion. We discussed last week.
  astearns: Looking at the issue the last comment suggests to make a
            note in last level of cascade spec that we can simplify
            and have a note.
  fantasai: I'm happy to take edits to remove but we can add a note
            pointing to it that there was a thing that no one
  astearns: This is only next level of CSS cascade?
  fantasai: Both. If the feature doesn't exist, it doesn't exist
  fantasai: Both are in CR anyways.
  astearns: Objections to removing this from both levels of CSS
            cascade and replacing the reference with a note?

  RESOLVED: Remove this from both levels of CSS cascade and replacing
            the reference with a note.

  astearns: Thanks for taking on these edits fantasai


Clarify behavior of window.getComputedStyle on detached subtrees,
    and the definition of "the root element"'
  github: https://github.com/w3c/csswg-drafts/issues/1548

  fremy: I just took a look at the rest of the agenda and I don't
         think we can resolve on anything except maybe 5. They're not
         editorial. It would be weird to resolve without someone from
         chrome team.
  dbaron: One comment on this issue. The issue so far is a
          conversation between multiple Gecko people. It would be nice
          for another impl to look.
  fremy: Point taken. I will.
  astearns: Let's get a few more browsers commenting before we take
            this on again.


Define which replaced elements are affected by width: % rule zeroing
  github: https://github.com/w3c/csswg-drafts/issues/1889

  <fantasai> https://drafts.csswg.org/css-sizing-3/#min-content-zero
  fantasai: We added an appendix that lists the elements that should
            be 0ed out. We put all of dbaron's comment in the issue.
            We're asking for review
  fantasai: Please let me know if there's something to add or remove.
            We'll close once there has been review and dbaron has
            given a yes.
  astearns: dbaron have you looked?
  dbaron: I haven't.

  <fantasai> https://drafts.csswg.org/css-sizing-3/#intrinsic-contribution
  fantasai: Behavior is in the 2nd paragraph of section 4.2
  astearns: Sounds like we need to call for review of this change.
            Then we can resolve to close.
  astearns: It's a pretty minor change.
  astearns: Anything else on this?

Defer 'stretch' and 'fit-content' keywords to level 4
  github:  https://github.com/w3c/csswg-drafts/issues/1912

  fantasai: TabAtkins and I noticed the majority of open issues or
            things we need to add is related to 'stretch'. The rest
            have a consistent definition, have been or have been
            discussed being shipped.
  fantasai: Unless someone has a different opinion we'd like to drop
            these two properties and then take the spec to CR once
            people have gotten a chance to check.
  fremy: Reasonable.
  dbaron: Should we add a note where they were saying they were
  fantasai: I can do that.
  astearns: Objections to taking stretch and fit-content to level 4
            and dropping a note noting where they went
  <dbaron> ... and pointing to the next level

  RESOLVED: Take 'stretch' and 'fit-content' to level 4 and dropping a
            note noting where they went and pointing to next level.

  fantasai: [missed] The one with the argument relies on min-content
            and max-content to it doesn't depend ong stretch
  <dbaron> I think [missed] was fantasai proposing that the
           fit-content() function stays in this level, but the
           fit-content keyword moves to the next level
  astearns: Did anyone implement fit-content?
  fantasai: I'm not sure, but I think the spec needs more work. My
            plan for L4 fwiw is to have stretch, fit-content, contain
            keyword (because we wanted to work on it with stretch),
            and add an aspect ratio feature.
  fantasai: That's the plan for L4 and I think TabAtkins and I can
            draft that pretty easily.

  astearns: I was just wondering if we were trying to move sizing 3 to
            CR if fit-content would need to move for impl status. But
            that can happen when we get to next publishing stage.

Restrict 'stretch' and 'fit-content' to width/height and max-*
  github: https://github.com/w3c/csswg-drafts/issues/1913

  fantasai: TabAtkins and I couldn't figure out a good use case for
            using them as a min width or height. We were suggesting to
            drop from min.
  fantasai: I can't think of a single reason you want to do it so it's
            not worth effort on testing and impl.
  astearns: This is L3 and L4 because you want to restrict fit-content
  fantasai: Yes, I think so.
  dbaron: I find it weird because it's about exposing low level
          concepts. Even if I can't come up with a use case off the
          top of my head it doesn't seem implausible. It's useful to
          have primitive concepts exposed when those concepts exist.
  fantasai: Fair.
  fantasai: I don't have a strong opinion.

  astearns: I'm wondering if there is a case where you're using custom
            properties that are set to one of these things and it
            would make sense to use that custom property value for a
            set of regular min and max prop. I'm not coming up with an
            actual case though.
  astearns: dbaron would you rather have them put back in? Or are you
            okay with then off for now until someone comes up with a
  dbaron: I'd rather put back in, but I don't feel that strongly.
  fantasai: Anyone else have an opinion?
  fremy: I can't find a use case either, but I don't have a strong
         opinion. I wouldn't want either remove or added. Either is
         fine. I can understand both points.

  astearns: What about if we leave this for a week and bring it up at
            TPAC with more people and more thought for possible use
            cases? Or just some stronger arguments for consistency.
  astearns: All I'm hearing is a lot of I'm not feeling strongly about
  astearns: Is this okay to leave for now fantasai?
  fantasai: No problem.

  astearns: Anything else to bring up on the call?
  astearns: For those coming to TPAC travel safe. We'll see you next
  <tantek> thanks!
Received on Thursday, 2 November 2017 00:45:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 2 November 2017 00:45:23 UTC