[CSSWG] Minutes Telecon 2018-01-31 [css-flexbox] [css-grid-1] [css-grid-2] [css-writing-modes] [css-sizing] [css-cascade] [css21] [selectors4]

  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 Grid & Flexbox

  - RESOLVED: Both flexbox and grid items top and bottom margin and
              padding percent resolves against the available inline

CSS Grid 2

  - RESOLVED: Add the feature proposed in issue #1116 to Grid L2.
  - RESOLVED: Publish FPWD for Grid L2

Writing Modes

  - RESOLVED: Accept proposal in issue #2239 (Also consider max-height
              as a limit on the height of the orthogonal flow)

CSS Sizing

  - RESOLVED: Computed value of min width and min height is auto even
              if it's internally resolved to 0 for layout purposes.

CSS Cascade

  - RESOLVED: From CSS 2, 2.1 and, 2.2 section 3.2 remove the
              paragraph beginning "UA must allow the user to specify a
              file..." https://www.w3.org/TR/CSS2/conform.html#conformance
  - RESOLVED: No change to section 6.4


  - leaverou compiled a list of options for issue #2143:
      and discussion will continue on github.
  - RESOLVED: Publish a new WD for Selectors adding the open items as


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jan/0102.html

  Rachel Andrew
  Rossen Atanassov
  Brian Birtles
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Javier Fernandez
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Liam Quin
  Chris Lilley
  Thierry Michel
  Michael Miller
  Anton Prowse
  Manuel Rego
  Melanie Richards
  Florian Rivoal
  Lea Verou
  Eric Willigers

  David Baron
  Vladimir Levantosky
  Peter Linss
  Dirk Schulze
  Jen Simmons

Scribe: dael

  Rossen: I think we have enough people.
  Rossen: Let's get started.
  Rossen: As usual I'd like to call for any additional items or
          changes to make to the agenda.

CSS Grid & Flexbox

Choose a single option for resolving padding and margin percent
    values of grid/flex items
  github: https://github.com/w3c/csswg-drafts/issues/2085

  Rossen: This is back from last week. Spec one option to resolve
          padding and margins for grid and flex items.
  Rossen: We discussed last week. I pinged dholbert and Mats on the
          thread. dholbert responded from Gecko and acknowledged they
          will change their behavior and they linked to a bug
  Rossen: That means we can resolve unless there's additional feedback
          or objections.
  Rossen: Current proposal: both flexbox and grid items top and bottom
          margin and padding % resolves against the available inline
  Rossen: Any thoughts? Comments? Objections?

  RESOLVED: Both flexbox and grid items top and bottom margin and
            padding percent resolves against the available inline

CSS Grid

Basic support for "equal gutter" with justify-content on grid items
  github: https://github.com/w3c/csswg-drafts/issues/1116

  Rossen: This is, if I recall, the newly added functionality to Grid
  fantasai: There is a justify-content property that takes values to
            be put in between. You can center tracks, space them to
            the left or right, kinda like flex items. When people have
            a grid they want to auto-distribute, but have equal
            spacing in both axes. Right now there's no way to get that.
  fantasai: This proposal has a possible value where it means go look
            at the other direction and use it over here multiplied by
            a number.

  Rossen: Do we have javifernandez? Or anyone from Igalia?
  <lajava> yes
  Rossen: I see they've made comments on the issue.
  <lajava> rego and me are attending from igalia
  Rossen: I read through them. Seems there could be ambiguity as to
          how this could be helpful.
  fantasai: What proposal does is what was requested. I'm happy to
            entertain other syntactic options, but we should solve the
            problem. What happens in each case should be worked
            through. Stretch shouldn't be allowed in combo.

  Rossen: And from your proposed solutions you had 2 options. 1 to
          introduce a new syntax and the other was define what happens
          if axis is auto size and space is justified instead of
          copied. Which of the two proposals do you want to discuss?
  fantasai: I'm happy to entertain either. I think the proposal
            without syntax don't allow different proportions and would
            also change existing behavior so probably not the way we
            can go as TabAtkins noted last March.
  florian: The unitless number one seemed to make sense to me. I think
           TabAtkins has reservations about unitless numbers because
           they don't meshed will with typedOM.
  fantasai: In this case it's a multiplier and I don't know what unit
            we'd want to introduce.
  florian: It's a percentage of some kind that just doesn't say so.
  fantasai: We could use percent also.
  florian: Percent isn't used there?
  fantasai: Just alignment keywords. We could add percent to them in
            the future for the percentage of the amount from start to
            end. For that reason if we go in that direction it might
            be a good idea to not use percent.
  Rossen: I would stay away from percentage as well.
  fantasai: This effectively represents an aspect ratio of sorts.
  florian: Fair enough.
  florian: I don't mind. I just thought Tab felt introducing unitless
           things makes other things worse.

  fantasai: If someone doesn't like this proposal and wants to work on
            an alternate that's fine, but I don't have another
  <florian> it seems sensible to me.
  Rossen: I think this is a reasonable starting point. By the time
          we're done we might change, but as a starting point the
          proposed solution addresses this feature request.
  Rossen: I'd like to hear if there are other thoughts or proposals.
          If there are additional syntax issues we can deal separately.
  Rossen: I'm not hearing pushback on the proposed way to solve and
  Rossen: Are there any or any objections?
  <rachelandrew> +1 to adding the feature
  Rossen: There's a fair interest in this feature. Others last week
          gave thumbs up. I think it's reasonable to accept as level 2.
  Rossen: Are there any objections or additional comments?

  RESOLVED: Add the feature proposed in issue #1116 to Grid L2

  <rego> lajava, is having problems with the mic
  <fantasai> rego, maybe type in comment into IRC and we'll relay?
  <lajava> yes, sorry, nothing urgent that can't be discussed offline
  <rego> we don't have a better proposal, but we've some doubts
         regarding how it'll work for grid containers with "height:
         auto", if after alignment it'll overflow or if it'll change
         the height of the container
  <rego> but as we don't have a better proposal, I believe current one
         is fine as stating point
  <lajava> my concerns are specially related to the fact that Content
           Distribution increase the size of the container, instead of
           using the available space (even causing overflow)
  <fantasai> lajava, rego: These are good points, let's work through
             them in WD.
  <fantasai> lajava, rego: If we can't solve before subgrid needs to
             ship, we can drop to the next level :)
  <rego> :-)
  <lajava> fantasai: sounds good


  fantasai: Do we want to do FPWD?
  Rossen: Exactly. We can proceed to now resolve on FPWD for grid.
          Which will be potentially contain all the L1 delta including
          subgrid and this new grid gutter feature
  Rossen: I believe that's everything in L2, right?
  <Chris> so is the document ready to go for fpwd or does it need
          edits first?
  <Chris> I prefer that we are ready to go before resolving to request
          the transition
  fantasai: Yeah, this is all I intend for L2. We should focus on
            subgrid and this feature was straightforward.
  Rossen: Yeah. On our end we reviewed and we're fine with FPWD.
  Rossen: If there are no obj we'll resolve.
  <tantek> ship it

  Chris: The doc is ready to go as is now? Features we want are in?
  fantasai: Yes, just need to be regenerated.
  Rossen: There's no features we don't want. I had reservations last
          week, but we reviewed and we're good.
  Chris: +1

  RESOLVED: Publish FPWD for Grid L2

  Rossen: Congrats and thank you.

CSS Writing Modes

Should max-height also limit orthogonal flows?
  github: https://github.com/w3c/csswg-drafts/issues/2239

  fantasai: We use the...if you have orthogonal flow we need to come
            up with a height constraint on vertical text so there's a
            line length.
  fantasai: By default we use a combo of containing block if it's
            defined or nearest scrollport or initial containing block.
  fantasai: Scrollport we only use if its fixed height.
  fantasai: For containing block we forgot to look at max height.
  fantasai: Proposal is to modify spec to look at max height when
            there's and auto and a max.
  fantasai: There is one impl already.
  florian: We have 1 1/2 impl. Blink and Webkit do it.

  Rossen: From impl PoV it sounds reasonable.
  Rossen: We might already support this. It's been a while since I
          played with orthogonal flows. But it makes perfect sense.
  Rossen: Other thoughts, ideas, obj on having max-height be a
  florian: I'm in favor we should look in all cases, not some.
  fantasai: Agree.
  <rego> +1

  Rossen: Would be good when we spec language to word it such that the
          used content box height will be defined rather then auto.
          I'm saying this because we don't want to have to come back
          and say min-height also needs to be looked at in case it's
          bigger. Would be better to define it as defined not auto.
  fantasai: Yeah. We need to make sure we word for all cases. We can't
            use used height because if it's auto it depends on this
            orthogonal flows.
  Rossen: Agree.
  Rossen: Something like content box height would be defined. There's
          a combo of max and min height to make a limit.
  fantasai: Sounds good.
  Rossen: I just don't want to ignore min height in this or have it
          sound like only max applies.
  fantasai: Good point.
  florian: Rossen to make sure I follow you say if min height is large
           it could come into account but smaller doesn't matter.
  Rossen: If there's something that will define a limit, such as max
          or min height. Min height only pushes the limit if it
          exists. Provided a limit exists and you have to look at min
          height it's used. I don't want us to forget about min height
          which is pushing the limit.
  Rossen: I didn't know how to clearly define it so I said used height
          but that's weak.
  florian: Your point should be equally valid for containing block as
           scope. But yeah, I agree.
  <fantasai> sgtm, I'll make the edits and Florian will review ;)
  Rossen: I think we have enough in the discussion that will go into
          the minutes. Anything else to add?
  florian: Good to resolve.

  RESOLVED: Accept proposal in issue #2239

CSS Sizing

Computing min-width/min-height: auto to zero
  github: https://github.com/w3c/csswg-drafts/issues/2230

  fantasai: I noticed we don't have consistency on if the min height
            or min width go to auto or 0 on flex items. Spec isn't
            clear. We should do something to make spec clear.
  fantasai: I think it's in our best interest to compute to auto as
            many places as possible. Given blink is always auto we
            should go ahead and do that.
  fantasai: This would change flexbox and grid spec to clarify that.
            min-width and min-height computes to auto

  Rossen: I thought we had a resolution. I believe in edge we're
          always doing auto so you can round to computed value and be
          able to round trip.
  fantasai: The cases where it goes to 0 it would round trip. Flex
            items the only dimension were auto isn't 0 is the main
            axis. In the cross axis it doesn't have any effect.  It's
            effectively 0 not computed to 0.
  Rossen: In other cases you'll have wrong behavior if you round trip
          to 0.
  fantasai: Those cases are already auto.
  Rossen: Okay.
  Rossen: Anyone from FF that wants to chime in? Seems Gecko is the
          only one that may need to do work.
  Rossen: Objections?

  Rossen: I don't hear objections, but there isn't large
          representation from Gecko. If they have additional comments
          the issue is there.
  tantek: Is the main argument round tripping?
  fantasai: Main argument is to have a simpler rule for auto. If we
            were going back in time we'd have auto always go to auto
            and never 0 so in layout modes with another meaning it's
            consistent. For flex there's a complex set of conditions
            for when auto behaves as 0. only with overflow visible and
            main axis. Seems simpler to compute to auto.
  Rossen: We've added a whole bunch of magic into auto for flex. We
          don't want to expose parts of the magic sometimes. We just
          want it to be always auto.
  <birtles> I believe dholbert is checking now
  <dholbert> not listening, but just noticing the discussion in IRC.
             Are we just talking about getComputedStyle basically? (
             not about actual layout behavior?)
  <fantasai>x dholbert: yeah
  <dholbert> fantasai: OK, I don't have strong opinions then
  <rego> dholbert, yep only about getComputedStyle()
  Rossen: tantek Anything else you want?
  tantek: I'm trying to understand, but no reason to object. I see
          dholbert is checking.

  <dholbert> fantasai: ...except I'd prefer to avoid introducing "this
             property's *computation* [as visible through inheritance
             etc] depends on that property's computed value on the
             same element" special cases
  fantasai: Argument to compute to 0 is the author gets that result
            immediately when we can reliably get 0. Case to compute to
            auto is we can make it a simple rule. You could prob.
            argue in either direction.
  Rossen: I'm not hearing pushback.
  Rossen: Sounds like we have 3 impl shipping the proposed behavior.
  Rossen: I'm going to call for objections. Any objections?

  RESOLVED: compute min-width/min-height: auto to zero
  [Note: this was minuted wrong. Please see lower in minutes for the correction]

CSS Cascade

User stylesheets, UA stylesheets - still something we expect to be
  github: https://github.com/w3c/csswg-drafts/issues/2237

  Chris: I guess there are 2 parts to this. First is I was trying to
         remove fonts 3 test failures. 2 tests said you have to set UA
         stylesheet to specific syntax which implies you have to be
         able to edit and put syntax in UA stylesheet.
  Chris: Since fantasai said you can wrap a div instead of putting it
         in the stylesheet so that's solved.
  Chris: But this is testing functionality I can't find anywhere.
         There's nothing that says the UA stylesheet has to be
         something physical nor something editable by the user.
  Chris: They're relying on non-required features.
  Chris: User stylesheets there's a requirements to support. Edge
         doesn't do it. Chrome took it out. We've had this model since
         CSS 1. Do we still believe in it or do we want to allow the
         browsers to inject and we shouldn't test for it. Especially
         UA stylesheet.
  fantasai: I don't know anywhere in the spec the UA stylesheet
            editable. User stylesheet is a file you can choose.
  Chris: Right.

  fantasai: There's also that we have spec sections conflicting.
  florian: How?
  <fantasai> https://www.w3.org/TR/CSS2/cascade.html#cascade
  fantasai: One impl one thing, the other different. Cascade talks
            user and user agent.
  fantasai: User may be able to spec style info for a particular doc.
            It's all mays.
  <fantasai> https://www.w3.org/TR/CSS2/conform.html#conformance
  fantasai: Chris pointed out there's a section on the conformance
            with musts saying UA must allow the user to select a
  <fantasai> “UAs must allow users to specify a file that contains the
             user style sheet.”
  florian: That doesn't seem very elegant. Spec saying how a UA must
           behavior is reasonable. But saying it must provide some UI
           level feature, file access is a UI level requirement.
  fantasai: That's in 3.2.
  Chris: An additional complication were UA a11y guidelines require it
         to be modifiable. That's various legal standards. Modifying
         or changing this has substantial repercussions. Assuming it
         works also has repercussions.

  Rossen: As an impl who is shipping this- UA stylesheet since the
          first time I impl this in IE8 there was no conformance
          requirement that the user stylesheet has to be on disk nor
          using it as such and paying the performance costs.
  <fantasai> *please* can we not confound UA and user in this
  Rossen: This as a UA impl leads to the conclusion this better be a
          static compiled ready to go stylesheet. This is the reason
          we don't have an actual file on the system. But we do have
          one that's loaded and compiled.
  <smfr> webkit also compiles the UA style sheet at build time
  <fantasai> The UA stylesheet and user stylesheet are really
             different concepts.
  Rossen: So there is the concept of user agent defined stylesheet.
          But we don't plan on shipping it as actual CSS.
  Rossen: Other reason is if you have different user agents referring
          to same engine you should have, at least our design
          principle, is they all have basically same stylesheet.
  Rossen: User stylesheets we deprecated before edge. We had support
          in ie9 and 10. I think we deprecated in 11. There was no use.
  Rossen: Since then things changed. In particular extensions allow
          the addition of stylesheets only that can be used to modify
          and tailor UX in more ways then a single stylesheet. In
          terms of extensibility one of our principles was to
          encourage this to be exposed through extensions rather then
          dropping a style sheet.

  florian: Pretty much agreeing with you. I think the right division
           is the css specs should define how user stylesheets work,
           but stay out of the must impl. If other specs want to
           require this of browsers, but css should define how it
  <fantasai> +1 to Florian
  <Rossen> +1 to florian
  Rossen: Agree.
  <Chris> https://www.w3.org/WAI/UA/TS/html401/cp0414/0414-USER-STYLE.html
  <Chris> Checkpoint 4.14 Choose style sheets (Priority 1 )
  <Chris> Provision 2 : Allow the user to choose from and apply at
          least one user style sheet.
  <Chris> also https://www.w3.org/TR/UAAG20/#gl-style-sheets-config

  dauwhe: I want to reiterate the importance of the end use affecting
          presentation of content. This becomes a huge issue on
          digital books. There's an aria personalization task force so
          might be good to coordination. I don't want to see this die.
  fantasai: Yeah.
  fantasai: I think propose edits would be leave the cascade 6.4
            section in place. It describes that a use could do a css
            syntax or through an interface. I think we should remove
            from conformance the paragraph that was the user must have
            ability to spec a file representing user stylesheet.
  <fantasai> https://www.w3.org/TR/CSS2/conform.html#conformance
  fantasai: I would remove that second paragraph after bullet list ^
  <fantasai> no changes proposed to
  florian: I don't think removing the must decreases the chance of
          impl. It's important to define how to do it and let market
          pressure push to impl.

  Rossen: Chris back to you.
  Chris: I wanted clarity. I didn't have an aim in mind. I like what
         florian said we shouldn't spec UI behavior.
  fantasai: Proposal for edits. Sound good?
  Chris: I like what you suggested.
  fantasai: Proposed resolution: From section 3.2 remove the paragraph
            beginning "UA must allow users to spec a file". No changes
            to section 6.4
  <fantasai> https://www.w3.org/TR/CSS2/conform.html#conformance 3.2
  <fantasai> https://www.w3.org/TR/CSS2/cascade.html#cascade 6.4 (no

  Rossen: One at a time. From CSS 2 section 3.2 remove the paragraph
          beginning "UA must allow the user to specify a file..."
  Rossen: Objections?
  <Chris> https://www.w3.org/TR/CSS22/conform.html#conformance
  Chris: Question. That link ^ goes to css2 which points to 2.1 and
         2.2 I want to make sure we're updating those.
  fantasai: Yes, we can update both of those. Might as well edit all.
  <Chris> +1

  RESOLVED: From CSS 2, 2.1 and, 2.2 section 3.2 remove the paragraph
            beginning "UA must allow the user to specify a file..."

  Rossen: Second was additional resolution of no change for css
          cascade section 6.4.
  fantasai: CSS 2.
  Rossen: Sorry. I'm looking at links and got confused.

  florian: Question.
  florian: If this would induce process churn I'm happy no change. If
           it would it would be nice to mention it may be done with an
           extension as well as a file.
  fantasai: It's already there.
  florian: Given the example of extensions is nice, but only if it
           doesn't make process change.
  Chris: It's easy to put that in 2.2
  fantasai: I feel like the text is close enough.
  florian: Sure.
  Rossen: Back to proposed no change resolution. Objections?
  <liam> ok with no change

  RESOLVED: No change to section 6.4

CSS Sizing

Computing min-width/min-height: auto to zero
  github: https://github.com/w3c/csswg-drafts/issues/2230

  Rossen: Resolution was we compute auto in the case of auto.
  tantek: That wasn't what was scribed.
  Rossen: The resolution was supposed to be computed value of min
          width and min height is auto even if it's internally
          resolved to 0 for layout purposes.
  tantek: That makes sense to me.
  tantek: I'd like that as an updated resolution in the minutes.

  RESOLVED: computed value of min width and min height is auto even if
            it's internally resolved to 0 for layout purposes

  fantasai: I updated the issue
  <tantek> for grid & flex items only
  tantek: grid and flex only?
  fantasai: Yeah. If it's anything else file that separate.

  Rossen: We have 5 minutes. Preference on topic?


  fantasai: I'd like to propose we update WD of selectors? Item #6
            needs more discussion but it is marked as an issue.

Name the "functional pseudo-class like :matches() with 0 specificity"
  github: https://github.com/w3c/csswg-drafts/issues/2143
  <leaverou> https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470

  leaverou: We resolved a month ago to add a pseudo class :is . There
            was concern that that's the logical opposite of not.
            Proposal is we could rename :matches to :is, we could
            rename :matches, we could combine both properties. There
            were a bunch of proposals for different names. I made a
            table with proposals
  leaverou: Hoping we could do a straw poll and decide on name.
  leaverou: I think best is to mix them into one pseudo class of :is.
            :matches was implemented but it's not used and is only in
            Safari. The argument was that it’s "rude" to rename.
  <fantasai> I don't think we can close on this fairly in the next 4
  <fantasai> 3 minutes
  florian: Rude isn't the best word, but there is inertia there and
           it's a lot to change.
  smfr: I don't have a feel for how much :matches is used.
  <bradk> This could be a 30 minute discussion

  fantasai: We have 2 minutes. I'd like us to defer this since there
            has been a lot of interesting discussion. And we should
            have info on existence of :matches.
  leaverou: I won't be able to be in next week, so defer 2 weeks.
  fantasai: Sure.
  Rossen: This topic will take time. Let's point everyone to the issue
          so it's discussed.


  Rossen: fantasai you wanted an updated WD?
  fantasai: Yeah, to selectors. There's a handful of open issues that
            are significant and they're marked in the draft.  I'd like
            to update the W3.org.
  <fantasai> Issues marked in the draft:

  RESOLVED: Publish a new WD for Selectors adding the open items as

  Rossen: This topic should continue being discussed in the issue and
          once we're ready to resolve we'll bring it back. A couple of
          weeks from now sounds reasonable on timeframe.
  Rossen: That's the top of the hour. Any other publication
          resolutions? I don't see any.
  Rossen: Let's end here.

  Rossen: Next week is an APAC time zone friendly call. Keep that in
          mind. We'll be at 4pmPT.
  Rossen: Have a good rest of the day and we'll chat next week.

Received on Thursday, 1 February 2018 00:41:48 UTC