W3C home > Mailing lists > Public > www-style@w3.org > February 2018

[CSSWG] Minutes Telecon 2018-02-14 [selectors-4] [css2] [css-values-3] [css-typed-om] [mediaqueries] [css-contain] [cssom] [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 14 Feb 2018 19:19:55 -0500
Message-ID: <CADhPm3utfW_4fkMM0hKTYKi3g=i-P3XU-+C5=TBH01b+=P84YA@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.


  - RESOLVED: Remove drop pseudo class. (Issue #2257)

CSS Values & Units 3 and CSS 2

  - RESOLVED: Revert the change [to Values & Units about how to handle
              an empty URL] and open an issue noting that we had this
              change and we're not sure about it at this point. (Issue
  - astearns will complete the tests he was preparing so that
      republication of Values & Units 3 can happen next week.


  - RESOLVED: Add serialization principles to CSSOM (Issue #1564)
      - TabAtkins will make these edits as the spec doesn't currently
          have a full editor.


  - astearns will make new github label to distinguish edits where the
      community is invited to make the edits as well as edits that are
      good for a newcomer.

CSS Typed OM

  - RESOLVED: Keep last week's resolution for Houdini issue #610, say
              ignore instead of throw, and for matrix use the previous
              behavior with an issue noting we'd like to enforce in
              the same way but we don't know how.

Media Queries

  - RESOLVED: Have calc serialize in MQ same as properties, have that
              called out in the spec, and then test to see if we can
              follow that. (Issue #1968)

CSS Contain

  - RESOLVED: Have the break properties not affected by style
              containment. (Issue #1872)
  - Florian will create a PR to move flow-from and flow-into into
      Regions spec.

CSS Sizing

  - RESOLVED: Accept the change in
             (auto computes to auto always, but the resolved and used
             value of auto is 0 on non-flex or grid items)
  - RESOLVED: Have min and max content keywords behave for textarea's
              height the same as for blocks in the height property.
              (Issue #2141)
  - RESOLVED: Have min and max content keywords for width property of
              inputs and textarea to size based on contained content.
              (Issue #2141)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Feb/0010.html

  Tab Atkins
  David Baron
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Michael Miller
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Dirk Schulze
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou

  Dave Cramer
  Benjamin De Cock
  Daniel Glazman
  Brad Kemper
  Vlad Levantovsky
  Manuel Rego Casasnovas
  Jen Simmons

Scribe: dael

  astearns: Let's get started.
  astearns: Does anyone have anything extra to add to the agenda?
  astearns: Is TabAtkins on yet?
  astearns: We'll skip item #1 and #2.


drag and drop
  github: https://github.com/w3c/csswg-drafts/issues/2257

  astearns: Suggestion was drop the drop pseudo class since they have
            nothing to hook into.
  florian: What happened to what they hooked into?
  gsnedders: There was no implementation interest in it.
  astearns: There was a drop zone global attribute that wasn't gaining
            traction so they removed it.
  astearns: Objections to removing drop pseudo class for now?

  RESOLVED: Remove drop pseudo class.

CSS Values & CSS 2

empty url() behaviour needs errata to match Level 3
  github: https://github.com/w3c/csswg-drafts/issues/2211

  fantasai: Basically gsnedders found css2 and values3 disagree what
            to do with an empty URL.
  fantasai: Looks like we decided for L3 to make it invalid instead of
            refer to location of stylesheet. I couldn't find the
            minutes of that resolution so if anyone remembers that
            discussion it would be useful. We should make specs agree
            and impl to agree with specs.
  astearns: Do we have data on current impl?
  fantasai: gsnedders do you know? I tested using computed values
            where I got URL of the page, it was invalid.
  gsnedders: I think Chrome & FF resolve to page itself. I'm not sure.

  astearns: Proposal is change L3 to match impl and revert the invalid
            resource bit?
  fantasai: Would need to look what that looks like in the changeset.
            I have no real opinion on which way to go.
  astearns: I spent time trying to find the resolution that lead to
            this and I failed as well.
  astearns: What should we do fantasai? Resolve to revert or do more
            research and see what's impl, have tests, and then decide
            on how to change L3?
  fantasai: I think we have a fairly good idea. Test we ran so far
            it's not treated as invalid. It's supposed to be parsed as
            incorrect. Since this is a spec in CR and we have 2.1 and
            previous version say valid points at page we should
            revert. If someone thinks revisit we can re-open it.
            That's my opinion because we want to update V&U.
  fantasai: If we're not sure what to do don't make the change, file
            an issue, leave it open for later.
  astearns: Given that we're still trying to figure out why we made
            the change it makes sense to open an issue.
  fantasai: Then let's revert the change tot he draft and publish.
  astearns: What about revert change to draft, leave change and note
            as a comment in the draft so there's something in the
  fantasai: I can mark it as an issue in the draft, this is CR spec.
            That text I can leave it commented in and that text is
            linked from the issue.
  astearns: Sounds fair.

  astearns: Proposal is revert the change and open an issue noting
            that we had this change and we're not sure about it at
            this point.
  astearns: Objections?

  RESOLVED: Revert the change and open an issue noting that we had
            this change and we're not sure about it at this point.


  fantasai: That's the last issue and there's a DoC. I'd like to
            resolve to republish CR.
  astearns: I started writing tests for second to last issue and I
            haven't updated tests to match the negative calc
            resolution. I'd like to update the tests in the next week
            and then we can resolve to publish.
  astearns: Sound good?
  fantasai: That's fine.


Spec no longer defines the general "shortest serialization" principle
  github: https://github.com/w3c/csswg-drafts/issues/1564

  fantasai: Main issue is we need someone to make edits. There's no
            active editor. This keeps coming up as some editor is
            confused as to why Firefox serializes different and it's
            because this isn't in the spec.
  fantasai: Can we assign somebody to do the edits?
  astearns: There's the edits to re-introduce the shortest
            serialization and the other principles dbaron mentioned.
  fantasai: Yes, they should all be in the spec but no one is owning

  astearns: I would love to have an editor for CSSOM. I've been trying
            to recruit one. Anyone on the call willing to volunteer?
  TabAtkins: I can do particular issues, but not the new general
  astearns: Can we tasks you to add the principles in the issue? Just
            this edit.
  TabAtkins: Absolutely.

  tantek: Not volunteering. Do we have a label for something like PR
          desired where there isn't someone assigned but we'd welcome
          someone to do a PR for this item?
  astearns: We don't but it would be good. A first issue tag for easy
            things would also be good for someone new.
  <Chris> "Good first issue"
  florian: We have edits needed, but it doesn't distinguish.
  tantek: This is a callout to a volunteer stepping forward instead of
          saying this is the a to do list.
  tantek: This is a good example where it's non-normative text where
          it's a easy first edit.
  fantasai: This isn't non-normative
  tantek: Reading dbaron's text it sounded like it's non-normative.
  TabAtkins: This is in the guideline of things where we really want
             to say it normative but there's too many variations. This
             needs an experienced editor.
  florian: The principle of tantek's ask is sound.
  fantasai: Spec is normative and will say there are exceptions. For
            properties should should be able to apply these and get
            correct serialization.
  tantek: I think enough text is in there that a new person could do a
          decent PR. This is the kind of edit I'd welcome someone
          taking a shot at. Anyway. Didn't mean to sidetrack.
  astearns: It would be good to have a tag saying outside submissions
            welcome and a tag that says this is unassigned and we
            don't have an editor.
  TabAtkins: Agree to both.
  <dbaron> I think this is the sort of edit where I'm likely to have
           substantive disagreements with draft text by Tab, and Tab
           would be likely to have substantive disagreements with
           draft text by me.

  astearns: objections to putting these principles into cssom?

  RESOLVED: Add serialization principles to CSSOM.

  ACTION TabAtkins to make the edits in
  <trackbot> Created ACTION-867

  ACTION astearns to come up with new tags for new edits
  <trackbot> Created ACTION-868

CSS Typed OM

Does the is2D design allow for inconsistent interpretation of
  github: https://github.com/w3c/css-houdini-drafts/issues/610

  TabAtkins: This needs a revisit because I remembered the reason I
             made a choice.
  TabAtkins: Short recap, dbaron suggested that is2D causes behavior
             changes so if it's set to true we throw on changes that
             would touch 3D parts of an object. Problem is matrix
             component. It doesn't reinvent 2 or 3d objects on its
             own. I didn't want a low power of the DOMMatrix.
  TabAtkins: So the matrix object just contains a DOMMatrix. Problem
             is DOMMatrix doesn't have this logic. is2D flag is read
             only and just reflects if it's 2d or 3d. There's no way
             for the is 2d flag on the transform to effect how the
             DOMMatrix responds to operations. There's nothing in the
             spec for it now and it would be a tear away problem.
             Things are linked in lifecycles which is awkward for
  TabAtkins: There's no way to do this thing on the matrix component
             as designed. We can't even split into 2 or 3d because the
             2d will still want a matrix.
  TabAtkins: That's why I went that is2D is a declaration from the
             author and we ignore the 3d-ish parts rather then the
             more controlling way. So I think we need to revert unless
             someone has a more clever way
  krit: For DOM we made the flag read only on purpose because
        different transversions where something looks 2d but is 3d.
  TabAtkins: Right. Same policy is elsewhere. A translate with 0 on
             the z axis is still 3d. It's a product of your intent not
             the contents. I agree the DOMMatrix isn't a bad design,
             it's trying to do a different thing then transform are
             trying to do.

  dbaron: I'm not especially happy. It think it's worth leaving an
          issue to see if somebody can come up with something better.
  TabAtkins: Yeah. If we're going to go with that I would prefer to
             change my recommendation from last week to ignore instead
             of throw since that'll be consistent with us coming up
             with a good way to do it that works.
  TabAtkins: If we stick with the solution from before where is2D just
             changes serialization, if we can solve the matrix
             component then sets to 3D will do something and I'd
             prefer we do something in case it's stuck for an extended
             period of time.
  TabAtkins: So ignore sets rather then throw.
  astearns: Work for you dbaron?
  dbaron: I'm okay with that.

  astearns: As far as I understand suggestion is we keep previous
            resolution but change so we don't throw on sets.
  TabAtkins: Ultimate issue is I have no way to enforce the previous
             resolution on matrix. So keep last week, say ignore
             instead of throw, and for matrix use the previous with an
             issue noting we'd like to enforce in the same way but we
             don't know how.
  astearns: Objections to this path?

  RESOLVED: Keep last week's resolution, say ignore instead of throw,
            and for matrix use the previous behavior with an issue
            noting we'd like to enforce in the same way but we don't
            know how.

Media Queries

How do media queries with calc() where it can be resolved early
  github: https://github.com/w3c/csswg-drafts/issues/1968

  florian: A few weeks back we decided that calc is supposed to
           simplify down as soon as it can, but not simplify away.
  florian: Raised against MQ. Implementations were new, but 2 new impl
           we not doing that. Chrome was about to agree to not do that
           which means remove the calc when serializing. In same
           discussion it was raised if combining length units early
           was what we wanted.
  florian: I don't have a stand, but since impl sort of disagree on
           the resolution we need to revisit. I think TabAtkins
           thought what we resolved was good.
  TabAtkins: I'm not strong either side. Whatever works.

  florian: Do we have anyone who wanted to impl the other thing?
  astearns: Not enough strong opinions on the call.
  astearns: Reading dbaron's comment it sounds like you'd be against
            dropping calc?
  dbaron: I'm catching up on the issue
  dbaron: I was pointing out one issue with dropping calc it sometimes
          makes a thing valid that wouldn't be valid without the calc.
          We don't check range restrictions in calc.
  florian: In FF and webkit that's what they do. If you have aspect
           ratio of -1/-1 with a calc it serialized through as all
           which is what you'd expect.
  dbaron: Maybe...I don't know how well calc validity rules are
          specified. Changing validity rule would need to be specified

  florian: In same discussion MQ in em serializes to em but em+px
           serializes to px in a calc and why.
  florian: Do we need to revisit how calc serializes in MQ? Happy with
           existing rules? Revisit based on impl?

  florian: Asking differently: When we resolved on rules for calc in
           general context were people in favor of what we resolved
           remembering MQ or did we forget and need to investigate?
  astearns: I do not recall MQ being part of that conversation.
  fremy: I don't see a point of making them different. We don't
         support calc but if we did it would be same as properties. If
         no one is arguing different we should stick with what we have.
  florian: Yep. It was pointed out all impl don't do that but it could
           be a bug. There isn't a problem of web compat because this
           is new. But if we resolve one thing in spec and everyone
           impl something else it's not helping.
  florian: In other words, I'm happy to close won't fix and I'm happy
           to take tests from fremy and then file bugs one people.
  fremy: Why not ^-^

  astearns: Proposal is close, have clamping in MQ calc be exactly the
            same as for property values. We'll then have tests to see
            what's been impl and see if it matches reality?
  florian: Informal tests say they don't, but formal lets us file bugs.
  astearns: I like not having something special for MQ. But I think
            it's useful to have something explicitly discuss this in
            MQ spec so we can hang a test off it.
  florian: Sure...
  florian: I'll phrase it to explicitly refer to the canonical text.
           Sounds good.

  astearns: Proposal is have calc serialize in MQ same as properties,
            have that called out in the spec, and then test to see if
            we can follow that.
  astearns: Obj?

  RESOLVED: Have calc serialize in MQ same as properties, have that
            called out in the spec, and then test to see if we can
            follow that.

CSS Contain

Clarify style containment effect 1
  github: https://github.com/w3c/csswg-drafts/issues/1872

  florian: There's a thing called style containment with 2 groups of
           effect. #2 isn't under discussion, that's fine. What's
           under discussion is how style containment should/shouldn't
           affect break-before and break-after.
  florian: A number of people said affecting made no sense. TabAtkins
           wasn't sure. TabAtkins are you now sure?
  TabAtkins: I think we can remove it.
  astearns: Proposal is to have the break properties not affected by
            style containment?
  florian: Or drop the part that claims they are.
  astearns: Objections?

  RESOLVED: Have the break properties not affected by style

  florian: Part 2 talks about flow-from and flow-into. I think that
           should be moved to regions spec given relative maturity.
  astearns: I think that's fine. Can you open an issue on regions to
            add that?
  florian: I can open a PR that changes both specs?
  astearns: Even better.

CSS Sizing

Decide how to handle `min-width/min-height: auto` for non-grid/flex
  github: https://github.com/w3c/csswg-drafts/issues/2248

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2248#issuecomment-362114572
  fantasai: The issue is about what do we do with computed values on
            non-grid and non-flex items. Behave as 0. dholbert
            proposed auto keyword computes to itself on all display
            types, but the resolved value should be 0.
  fantasai: This has a couple of advantages. One is that it makes the
            computed value easier to compute, the keyword isn't based
            on display type information. Second advantage is there was
            some behavior we were trying to resolve for another issue
            which required us to distinguish between auto and 0 min
            sizes on elements that are no flex and grid so being able
            to refer to that is good.
  fantasai: Disadvantage if you're animating from initial value of
            assumed 0 on the min-height and min-width, that breaks.
  fantasai: Not sure how many people are animating that and, if they
            are, assuming initial value of 0.
  fantasai: I think we should take proposal, but want to hear from
            group. Toward the end of the issue there's discussion
            about a separate item that needs to file separately.

  astearns: Other opinions?
  astearns: Proposal is have the computed value be auto but the used
            value be 0?
  fantasai: Used value is 0. Resolved value would be 0.
            Change...currently computed value is 0, computed value
            remains as the keyword auto. If you use getComputedStyle
            we'll return 0 for backwards compat.
  fantasai: Kinda like we do for width where auto computes to self but
            getComputedStyle returns 0.
  astearns: Objections to this change?

  RESOLVED: Accept the change in

Please add vertical auto-resize textarea field
  github: https://github.com/w3c/csswg-drafts/issues/2141

  fantasai: Had a number of requests for form control textarea able to
            take size from height on contents. Currently auto means
            take from rows and cols.
  fantasai: Proposal is new min and max content behave on textareas
            more like blocks.
  fantasai: 2 questions 1) should we do this for textarea for block
            dimension. 2) do we want to consider this in the inline
  fantasai: Take them one at a time.
  fantasai: We previously discussed this on iframe, but that's
            separate due to more security concerns.

  fantasai: Should min and max content on the height of a textarea
            tell the textarea to take height from the amount of
            contents it has.
  dbaron: This is a new feature where as you type in the textarea the
          size changes?
  fantasai: Yes.
  astearns: Can change.
  tantek: I've seen that effect via JS.
  TabAtkins: Easy to do in JS.
  tantek: Shouldn't need JS though.
  fremy: As I mentioned in issue I'm fairly confident this is a good
         feature. I've had people use JS and get it wrong. Still
         concerned about min-content being bigger then auto. Maybe
         only say max or have something special for min.

  dbaron: For textareas they have a different min and max content
          because the way they wrap. Generally they allow any
          character for wrap though that might vary.
  florian: I don't think any character is the case.
  dbaron: At least in emergency cases. Something long and unbreakable
          it'll wrap rather then force scroll.
  florian: If so that's probably consequence of styles. I don't think
           there's anything that calls for different text wrapping in
           these. I don't recall seeing any that didn't look like
           bugs. But you can achieve the effect by applying CSS and
           that may be in the UA stylesheet.
  <dbaron> Gecko's wrapping styles for textarea { white-space:
           pre-wrap; word-wrap: break-word; }

  astearns: With regard to fremy concern about min-content being
            bigger then auto, is that the case for blocks?
  fantasai: I'm confused about this concern. I don't see why it's
            different. It's definitely true on grid items where auto
            can be smaller then min-content. Auto says use this other
            formula which is some cases but not all based on content.
  fantasai: I don't understand the concern about auto having to have a
            relationship with min and max content. I'd prefer if they
            behave just like they do for blocks. Only think that needs
            to be different is auto itself.
  astearns: Sound reasonable fremy ?
  fremy: I'm still not sure...it's possible that auto is smaller than
         min-content. I'm surprised. In my mental modal auto is always
  fantasai: But that's not true.
  fremy: Possible. If that's not true then fine.
  fantasai: [gives example when it's not]

  astearns: The current discussion is using min and max content
            keywords and have them behave for textarea's height the
            same as for blocks in the height property.
  astearns: More concerns or discussion?
  astearns: Objections?
  <TabAtkins> yay!
  <TabAtkins> (I had Francois' concern as well, but Elika convinced

  RESOLVED: Have min and max content keywords behave for textarea's
            height the same as for blocks in the height property.

  astearns: Inline direction
  fantasai: Since we're working on this for form controls we have
            option to make it apply in inline direction. Not sure it's
            useful for textareas. On inputs I could see people might
            want to use it to size an input. Question is do we make
            these keywords work on those.
  TabAtkins: In inline axis we care more about min and max interacting
             with auto. That's how floats work. If we were to let
             min-content refer to actual content it would change
             behavior. If you had a long word wider then textarea it
             would change size.
  fantasai: Auto means use the size spec in the html attribute or
            default to the size.
  <rachelandrew> +1 for the inline direction, makes sense that we can
                 do the same in both axes.
  fantasai: The min-content contribution has nothing to do with
            min-content size of element. Nothing to pinch unless you
            spec min or max content keyword nothing would change.
  TabAtkins: You're right. Nevermind.
  astearns: rachelandrew put +1 on IRC

  astearns: Proposal is to have min and max content apply to both
            inputs and textareas? With the previous for the height is
            it only textarea or also inputs?
  fantasai: Let's start with just textareas? Inputs are one liners.
  astearns: But for inline this would be both?
  fantasai: That seems reasonable. I'm also okay to only do it for
            input if people are uncomfortable with textarea.
  astearns: Concerns about inputs and textareas?
  astearns: Proposal: have min and max content keywords for width
            property of inputs and textarea to size based on contained
  astearns: Objections?

  RESOLVED: Have min and max content keywords for width property of
            inputs and textarea to size based on contained content.

  astearns: Is anyone chomping at the bit to impl and give feasibility
  astearns: We'll have to see how long this lasts in this level of the

  astearns: Thanks everyone for calling in. We'll continue sizing
            issues next week.
  astearns: Thanks all!
Received on Thursday, 15 February 2018 00:21:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 February 2018 00:21:20 UTC