W3C home > Mailing lists > Public > www-style@w3.org > June 2015

[CSSWG] Minutes Telecon 2015-06-17

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 18 Jun 2015 07:48:13 -0400
Message-ID: <CADhPm3uC4djOME_7i60YmHW5f0eCddU91eJhk96+wzdoYanDNA@mail.gmail.com>
To: www-style@w3.org
transform-origin UA style
-------------------------

  - RESOLVED: Adopt second suggestion from Cameron
(https://lists.w3.org/Archives/Public/www-style/2015Jun/0109.html)
              about the UA style sheet plus a note saying initial
              transform-origin for SVG elements won't lead to an
              expected result.

Percent resolution for abspos vs in-flow grid items
----------------------------------------------------

  - All the needed parties weren't available to reach a formal
      resolution, but the group leaned toward deciding that grid
      items are treated the same way always for percent resolution
      regardless of how they got to be laid out.

Grid Issues
-----------

  - RESOLVED: normal computes to 0 on multi-col on grid containers
  - RESOLVED: grid-gap property is the shorthand for column-gap and
              row-gap. grid-gap resets both.
  - fantasai will create a note for grid and flexbox about authoring
      tools supporting the must requirement to re-order the DOM in a
      logical way. Once that is complete the group will resolve on
      adding it.
  - A decision on percentage padding/margin for abspos boxes with
      grid container containing block will wait until dbaron returns
      in July.

CSS 3 UI
--------

  - RESOLVED: Update the REC for css-style-attr
  - The chairs will talk to plh to see if there is any flexibility
      in the publication process before the group spends time
      deciding if they want to change how they handle publication.
  - box-sizing will still be removed from level 3. If there's a
      strong use case for it, it can be added to level 4.
  - A decision on if the UA may treat unsupported values as auto will
      wait until tantek has a chance to weigh in on the issue.

Elements and Nested Scrollers
-----------------------------

  - Discussion will continue on the mailing list now that awareness
      is raised.

===== Full Minutes Below ======

Present:
  Rossen Atanassov
  Adenilson Cavalcanti
  Bo Campbell
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Peter Linss
  Edward O'Connor
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Alan Stearns

Regrets:
  Tab Atkins
  David Baron
  Sanja Bonic
  Chris Lilley
  Mike Miller
  Anton Prowse
  Takayuki Tsukitani
  Lea Verou
  Ian Vollick
  Steve Zilles

  scribe: dael

  glazou: Let's get started.
  glazou: Anything to add to the agenda?

transform-origin UA style
=========================

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0109.html
  glazou: I'll handle this one since krit isn't here. There is a
          tentative explanation of the issue for default transform-
          origin for SVG elements.
  glazou: There is a problem between svg and non-svg which is 0,0
          for svg and 50%,50% for others.
  glazou: There is a decoration that would do the switch, or a
          proposal from Cameron that would change the default style
          sheet.
  glazou: krit is handling it and he has a slight preference for the
          option from Cameron.
  glazou: What do people think about this?

  * fantasai thinks Cameron's suggestion makes sense
  Rossen: I was at the svg F2F last week. The one issue that we
          discussed during that topic was if we don't have the
          'auto' value, what happens when you set to 'initial'.
  Rossen: The UA style sheet will get up and running the first time
          and when you reset the transform-origin to initial, we are
          screwed.
  glazou: That's a good point.
  Rossen: My preference was to go with 'auto' even though I don't
          like automagic defaults, but it will cover that use case
          which I believe is important.
  <Florian> The stylesheet approach might have been fine if there
            was no compat concern, but there is, so auto.
  glazou: But we have the value anyway so it must work in all cases.
  glazou: I was more in favor of the second proposal, but that's a
          very good point.

  fantasai: The initial keyword computes to 0,0?
  glazou: It computed to 50%,50% on svg elements.
  fantasai: Does anyone use 'initial' on transform-origins?
  Rossen: I'm assuming they do.
  fantasai: It's fairly obscure. If you know it takes a position
            you'll put a position into it.
  Rossen: Working for the last 12 months on interop, 'initial' is
          used a lot.
  glazou: And if it's available to all CSS properties, we need to
          make it available. It's a question of being consistent.

  smfr: CSS resets, do they set value to initial?
  Rossen: They're supposed to.
  fantasai: The concern is web compat. Cameron says FF and Webkit
            already impl it. They're evidently not hitting a problem.
  Rossen: My point was for consistency. That they're not running
          into issue today, let's say in a year SVG gets more
          traction, the initial value is well defined and people are
          using it. If they do it for transform-origin they will get
          unexpected results.
  fantasai: They will get an unexpected default if they use it on
            anything that the UA sets a different default and we do
            that on a lot of things. We do that where we think
            initial is one thing but somewhere we set it to
            something else because that's the important default.
            There's no need for this to be more complicated.
  hober: I agree.
  glazou: I have a problem with that point of view. We have two
          requirements. First is, it's a constant of CSS spec. We
          need to solve the 50%,50% instead of 0,0. The second is to
          make sure initial works correctly.
  glazou: The question is, does the first proposal or second
          proposal solve both requirements. It seems the second is
          not. That's my personal opinion. It seems the first one
          could fix it at the cost of some change in browser impl.
  Florian: If we had no compat issue to worry about, both solutions
           could be reasonably used. We are using UA style sheet for
           a bunch of things so there are a bunch of things where
           you get a different value from initial. It means it's
           okay to do. But since it was brought up that doing it
           with the UA style sheet is done, doing else wise would be
           compat issue.

  <fantasai> I would like to also smash the idea that the initial
             value of every CSS property needs to be 'auto' if we
             would otherwise need a UA style rule to get the right
             behavior. We don't do that anywhere else.
  <fantasai> If we can represent the UA stylesheet without 'auto',
             we don't add 'auto'.
  <Florian> +1 to fantasai

  glazou: Since we don't have krit, I told him I'd issue a call for
          consensus.
  Rossen: Just because we don't have krit doesn't mean there aren't
          other SVG members.
  Rossen: If we can get close to a resolution I would prefer that.
  Rossen: I wanted to bring up, to contradict myself in proposing
          auto, it will bring the auto for animation and position
          kind of iffy because we'll have to allow transform-origin
          to be animate-able.
  Rossen: We can argue both ways quite a bit. I would be okay with
          the second proposal, but we have to be clear that we are
          going against what initial is supposed to do. Or at least
          if people start using initial they might get unexpected
          results.
  glazou: You're suggesting the second proposal with a note?
  Rossen: I'm not opposed, yes.
  glazou: Second is the UA style sheet with a note about the danger
          of using initial on svg elements.
  <fantasai> We just made applied this exact principle to cursors:
             minimizing the automagic in favor of using the UA style
             sheet. I don't understand why we are arguing in the
             opposite direction here.
  Florian: I would prefer that. Also because what fantasai put on
           IRC.
  glazou: fantasai you agree?
  glazou: The UA style sheet plus a note saying initial
          transform-origin for SVG elements won't lead to an
          expected result.
  fantasai: Yes, a note or example would be helpful. It's a good
            idea.
  glazou: Objections?

  RESOLVED: Adopt second suggestion from Cameron about the UA style
            sheet plus a note saying initial transform-origin for
            SVG elements won't lead to an expected result.

  <glazou> ACTION glazou: email krit about resolution item 1
  <trackbot> Created ACTION-694

percent resolution for abspos vs in-flow grid items
===================================================

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0164.html
  glazou: That's from fantasai.
  fantasai: I don't have a clear thought, but I'll present.
  fantasai: We discussed percent resolution in the block dimension
            for flexbox and in-grid items. What Mats pointed out is
            if you have and abspos grid item which we can do, those
            margins because it's abspos will have vertical resolve
            against horizontal.
  fantasai: So if you position an item in a grid area, if the
            margins are resolved against horizontal or vertical will
            depend on if it's abspos. That's pretty inconsistent, so
            do we want that situation or do we change abspos or
            grid.
  Rossen: In our implementation of grid, grid items are treated the
          same way always for percent resolution regardless of how
          they got to be laid out.
  Rossen: If an abspos element makes its way from the first level
          children of grid or somewhere deeper inside of the element
          chain it shouldn't matter. It's still part of the grid and
          will be laid out for all grid rules and this shouldn't be
          an exception.
  Rossen: If we're allowing you to, for ex position and abspos item
          in a grid row/column, there's not reason for it not to
          resolve % the same way as other grid items. Same for flex.
  fantasai: Okay.

  fantasai: We're missing dbaron and TabAtkins so I don't think we
            should resolve, but if anyone has something to add to
            think about it, let's do that.

  Florian: I'm confused about the statement of same for flex. You
           don't abspos something into flex, do you?
  fantasai: No.
  Florian: You have something that would be flex but you abspos it
           away from flex?
  Rossen: I missed that.
  Florian: I was saying that in the flexbox case, if you have a flex
           item you abspos to someplace else it's ancestry is in the
           flex, but it's not a part of the flex box.
  Rossen: What I said is that the use case from Florian is correct,
          but it's the opposite of what we're talking about. He said
          we have a first child of a flex box that's abspos, but the
          flexbox isn't abspos. In that case the abspos flexbox item
          will be laid out and processed whereever it gets processed.
  Rossen: So what we were discussing is the opposite where a deeply
          nested element is abspos but also gets its position
          container to be grid or flex and that grid of flex is
          doing layout for the abspos item. SO the rules for that
          grid or flexbos should apply.
  Florian: That makes sense to me, yes.
  Rossen: I just wanted to point out that there should be no
          difference between flex and grid.

  Florian: I think what IE currently does makes sense, but we should
           defer for other people.
  glazou: If there's nothing more to say, let's move on.

Grid Issues
===========

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0166.html

row/column gap
--------------

  glazou: That was from fantasai with two items. First is row/column
          gap issues, second is a11y.
  fantasai: There's three parts of row/column gap. First is should
            normal value of row-gap compute to 0.

  fantasai: There is supposed to be interpreted as a UA value in
            multicol, I think it's easier to authors to compute to 0
            on grid containers. The list seems to agree, but I think
            we should resolve that normal computes to 0 on grid
            containers.
  Rossen: I'm having a hard time getting to the e-mail.
  fantasai: gregwhitworth agrees.
  fantasai: So it should be okay.
  fantasai: gregwhitworth replied to the list that it makes sense so
            I'm assuming it makes sense for Microsoft in general.
  Rossen: gregwhitworth has opinions, but I have some too.

  glazou: Objections?

  RESOLVED: normal computes to 0 on multi-col on grid containers

  fantasai: This is for row-gap and column-gap. We want to have a
            short hand. Options are grid-gap and track-gap, but I'm
            open to other suggestions.
  <astearns> grid-gap sounds ok to me
  Rossen: grid-gap sounds good.
  hober: It's also consistent. track-gap would be confusing about
         not applying to multi-col.
  fantasai: It does apply in multi-col because it's a short hand
            that sets row and column gap.
  hober: If it applies in multi-col I'd say track-gap sounds better
         because it doesn't rely on another mode(?)
  <Florian> +1 to hober
  fantasai: Track is a grid layout term, but not for rows and
            columns. Not sure that it makes it better.
  Rossen: Yep, I agree with fantasai that track isn't applicable to
          multi-col.

  <Florian> gap
  Florian: Do we have a plan to add another property that's a better
           use for the word gap alone?
  fantasai: I don't know.

  fantasai: We might want to look at the next issue to help decide.
            Should the shorthand reset the gap property?
  Florian: Based on this it seems the text should be probably not a
           good idea for gap. We can just call it grid-gap for the
           general property.
  fantasai: I think having the grid shorthand reset the gap property
            is a useful thing. The interaction with multi-col isn't
            a problem because you can't have an interaction. It's
            only column-gap that applies the multi-col. It's
            unlikely people would try and combine multi-col and grid
            because they do very different things.
  hober: So you argue people will only want to use the shorthand
         when doing grid layout so we can name it after grid. That
         seems reasonable.

  Rossen: Did we consider something like gutter?
  Rossen: It doesn't say gap in the name, but it describes the gap
          in all those layout types.
  fantasai: We can't use gutter without a prefix since that's
            confusing with the page gutter, which is the part of the
            page used for binding.  If we have a row-gap and column-
            gap, the shorthand should be gap not gutter.
  Rossen: I'm fine with it.  We can change it later.
  <Florian> gutter -> row-gutter column-gutter
  <SimonSapin> +1 fantasai

  RESOLVED: grid-gap property is the shorthand for colum-gap and
            row-gap. grid-gap resets both.

a11y, tools, and reordering
---------------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0180.html
  fantasai: Basically, we have a requirement that authors shouldn't
            use grid or flexbox reordering to reorder the source
            differently than the visual order when it's not
            beneficial for a11y reasons. When you're reordering you
            do it in the source. We want to add a conformance
            requirement on authoring tools where if they don't
            change the source, that's the opt-in for the author.
  fantasai: It would be non-conformant to have an authoring tool
            that lets you reorder items in grid just by changing
            grid properties unless the author using the tool says I
            don't want you to reorder the source.

  glazou: What do people think?
  bo: Can you describe what an author opt-in means? I'm not sure I
      understand.
  fantasai: The default behavior of any authoring tool that allows
            re-ordering using grid or flexbox, it does the re-
            ordering by re-ordering the source, unless the author
            specifically says I want to keep the source order the
            same. The default behavior without the author doing
            something to choose visual re-ordering only, would be to
            change the source order.

  Rossen: I guess...this is a requirement that we will take. Having
          ordering and the ability to re-order items in those
          layouts is both useful and very appropriate to be done on
          the CSS layout. For example, you want to re-order images
          backwards to show the oldest first. I don't see why you
          would re-order your entire file. I see the a11y, but I
          find it difficult to believe it would be done anywhere
          except the CSS layer if you can do it there.
  Florian: I'm not convinced this would make a huge difference on
           what people do, but I agree with the requirement.
  hober: I am worried that the requirement makes assumptions about
         the UI of authoring tools that might not match a
         sufficiently new authoring tool UI. I don't want this rule
         to restrict authoring tool makers from innovating new ways
         to present these features, but on a meta level I don't make
         an authoring tool so I'd like to hear from people that make
         authoring tools. Do they find it reasonable. glazou is the
         only person we have that makes an authoring tool.
  glazou: I have no opinion yet because I haven't dove into flexbox
          or grid for my authoring tool.
  Rossen: The tool makers on our side, I don't believe these guys
          look into this kind of requirement closely.
  Florian: Yeah, I think it does not matter what we write it might
           not be applied, but they indicate intention.

  hober: I think that suggests it should be a note as to the best
         practice instead of conformance.
  Florian: We have that.
  fantasai: I don't think we do.
  Florian: On authors, not tools.
  fantasai: We have a conformance requirement on authors to order
            their DOMs in a logical way.
  glazou: In the W3C sheet there is an a11y guidelines post and it's
          the best post out there.
  Florian: Given that we have an author requirement, we can have a
           note to the authoring tools saying their UI should take
           this into account.
  glazou: I'd like us to warn the people editing the doc to know
          about it.
  Florian: In addition to, yes.
  glazou: A note in the whole spec while the document is about
          authoring tools entirely.
  Florian: Having the note in both places, yes.
  fantasai: I think that makes sense. I'm happy to draft text for
            that.

  <SimonSapin> "must" in a note?
  glazou: SimonSapin has a good question.
  Florian: It's a note explaining to authoring tools that authors
           have a must. It's an explanation of a must.
  SimonSapin: Ok, fair enough.

  glazou: Let's defer until fantasai makes the text. Do you accept
          an action to write it?
  fantasai: Adding a note to grid and flexbox and add a note that
            they can add conformance criteria if they wish.
  bo: This feels like a stop-gap about the bigger a11y issue for
      flexbox. This brings awareness to it, it does help.

  ACTION fantasai to write a note about authoring tools supporting
         the must requirement to re-order the DOM in a logical way
  <trackbot> Created ACTION-695

percentage padding/margin for abspos boxes with grid container
    containing block
---------------------------------------------------------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015May/0154.html
  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0168.html
  gregwhitworth: We had the same issue with interop about fixed
                 position. However we get CSS 2.2 update we need to
                 be able to say fixed position if Gecko changes, it
                 seemed like we're leaning in that direction.
  gregwhitworth: I don't know if this needs much discussion unless
                 Gecko disagrees.
  glazou: We don't have dbaron. So that defers until early July.
  gregwhitworth: I don't think I need to be here. However we get it
                 updated, we just need to know if he disagrees.
  Rossen: We have implementation intent from Blink.
  gregwhiteworth: No, blink and webkit have it.

CSS 3 UI Issues
===============

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0165.html

Updated REC for css-style-attr
------------------------------

  glazou: Let's do the two last ones about publication.
  Florian: There was a minor issue, it doesn't change anything, a
           term was just defined twice and it was causing errors.
  glazou: No object?

  RESOLVED: Update the REC for css-style-attr

  glazou: Do we have Bert?
  fantasai: I can work with plh to publish.

Publication Requirements
------------------------

  Florian: We don't have TabAtkins for the other one. There was an
           issue he raised where he realized that our publication
           practice wasn't a w3c requirement, but a CSS WG rule and
           he wanted to change publication to let authors deal with
           it.
  fantasai: I know I've published directly to web-req, but they
            wanted me to talk to the staff contacts. Given staff
            contacts aren't here...
  glazou: These are things chairs need to discuss with plh and
          web-req. If you want us to discuss we can.
  Florian: I think it's an action on the chairs to find out if it's
           possible to see if it's worth discussing.
  glazou: Let me ping plh on if it's possible and I'll get back.

Elements and Nested Scrollers
=============================

  glazou: One question, smfr are you on?
  smfr: yes.
  glazou: Did you want to talk about item 9?

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0147.html

  smfr: We're making progress on the ML, but I wanted to ask
        Microsoft for feedback.
  MaRakow: I saw the mail, but haven't gotten to digest.
  smfr: There was another only about containing block that would be
        good to nail down.

CSS 3 UI
========

box-sizing
----------

  Florian: I'd like to mention something about CSS 3 UI. Our "LC"
           period ends today. We have a handful of small issues open.
           There's maybe one or two we can tackle on the call. I
           don't think we can go to CR.
  Florian: During the F2F we thought we might drop the box-sizing
           and Mozilla was going to figure out if it was okay, but
           they removed it from their code base.
  fantasai: There was a resolution on the Wednesday minutes to drop.
  Florian: Okay. So we do drop it. I had a discussion with authors
           that it was nice, but not with any major use case. In
           some cases it's convenient, but it can be done without.
           If vendors agree we should remove, we stick by the
           previous resolution.
  fantasai: If there's strong demand it shows up in level 4.
  Florian: Okay.

Cursor treating unsupported values as auto
-----------------------------------

  Florian: The other thing is the CSS3 UI spec talking about the
           cursor property it has supposed values as auto.
  glazou: URL?
  <Florian> http://www.w3.org/mid/DB2A75EC-6C11-44A7-A043-4A2418ADC3C9@rivoal.net

  <Florian> The UA may treat unsupported values as auto.
  <Florian>   E.g. on platforms that do not have a concept
  <Florian>   of a context-menu cursor, the UA may render
  <Florian>   default or whatever is appropriate.
  Florian: [reads text]
  Florian: I don't think this is good, if you don't support, don't
           support and people can use a test page. "do whatever is
           appropriate" is vague.

  glazou: Is tantek on the call? I'd like to hear the original
          reason for it.
  glazou: I tend to agree, but I'd like to hear from him.
  Florian: That's reasonable.
  glazou: Okay, ping tantek to give us context.
  * fantasai and please compile a DoC

  ACTION Florian ping tantek for reason the UA may treat unsupported
         values as auto.
  <trackbot> Created ACTION-696

  glazou: I suggest we stop here. Thank you everyone. Bye.
Received on Thursday, 18 June 2015 11:48:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC