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

[CSSWG] Minutes Telecon 2017-10-18 [flexbox] [cssom-view] [css-ui-3] [css-grid] [filter-effects]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Oct 2017 20:25:10 -0400
Message-ID: <CADhPm3vMQiozbfRBHrZP01BjYAmmVrek1CgD0ayMioSxChB8Dg@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.
=========================================


Spec Rec Next Steps
-------------------

  - There is a request to add needed tests to the flexbox test suite.

CSSOM View
----------

  - There is a need to find out from implementors if they want to
      standardize on Element.focus() and, if yes, on what.
      - The two behavior options are detailed here:
https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688
          with both options having multiple implementations.
      - There was general support to standardize, but not enough
          implementors were available to decide on which path.
  - Discussion then turned to if ScrollIntoView is necessary given the
      existence of scroll snap.
      - If it is needed, there's also a need to define how it would
          interact with the scroll snap properties.
  - Discussion will continue on GH and may need to be split into sub
      issues to decide what the default should be, what options should
      be available to override the default, and how do the overrides
      interact with scroll snap.

CSS UI 3
--------

  - RESOLVED: Change the definition of cursor auto to look like text
              over selectable text in CSS UI 3.
  - RESOLVED: Add exception for editable text into L3 UI.

CSS Grid
--------

  - There are two open items around percentage size that still need to
      resolved:
      - Should the block and inline axis be resolved symmetrically or
          asymmetrically?
https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551
      - What to do with percentage gaps?
https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096
  - Both items have examples in the github issue, so everyone was
      asked to review and add their thoughts to the issue to help
      reach a resolution.

Filter Effects
--------------

  - RESOLVED: Accept hue-rotate() as an exception to unitless values.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0034.html

Present:
  Rachel Andrew (IRC only)
  Rossen Atanassov
  Tab Atkins
  Bert Bos
  Tantek Çelik
  Benjamin De Cock
  Robert Flack
  Tony Graham
  Jihye Hong
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Michael Miller
  Simon Pieters
  Manuel Rego
  Florian Rivoal
  Alan Stearns
  Sergio Villar Senin
  Greg Whitworth
  Eric Willigers

Regrets:
  Dave Cramer
  Chris Lilley
  Lea Verou

Scribe: dael


Spec Rec Next Steps
-------------------

  Rossen: There were a few specs in the publish pipeline which is
          awesome. I wanted to check on if there has been any movement
          on testing or if anyone needs help. Especially for things
          like Writing Modes, Backgrounds & Borders, Flexbox.
  Rossen: Has there been work? Do you need help?

  florian: I have no made progress on writing modes. I don't need
           help, just time.
  Rossen: For writing modes, what is the timeline for rec? Is it only
          those tests?
  florian: They're the only ones on my radar. You'd need to check with
           authors.
  fantasai: Mainly the orthogonal flows, but they need implementors to
            update. It was supposed to be CR published, I think. I'm
            wondering if that happened.
  Rossen: No.
  fantasai: Writing modes 3 was supposed to be CR published and 4 as a
            FPWD. I'm not sure where that's blocked. It hasn't
            happened.
  Rossen: I'll follow up with Chris.
  Rossen: I'll see what the hold up is.

  Rossen: Backgrounds & Borders is in the publish pipeline.
  Rossen: Anything else to update?

  gregwhitworth: Regarding flex I sent that review is completed, but I
                 haven't gotten to work on the tests at the base. I'm
                 not sure I have time before TPAC. If anyone wants to
                 help please send PRs on flex. I plan to write tests
                 for the changes fantasai has been making, but I don't
                 know about the rest. I would welcome the help.
  Rossen: If you can help, that would be awesome.
  Rossen: Please give a hand to gregwhitworth.
  <gregwhitworth> Particularly before TPAC for those tests.
  <gsnedders> wrt flexbox, also note there's a bunch of PRs awaiting
              review at
https://github.com/w3c/web-platform-tests/pulls?utf8=✓&q=is%3Aopen%20is%3Apr%20label%3Acss-flexbox-1%20-label%3A%22do%20not%20merge%20yet%22

CSSOM View
==========

Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions
----------------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/pull/1805

  <jihye> related PR in WHATWG: https://github.com/whatwg/html/pull/2787
  zcorpan: This is about disabling scrolling from the focus method in
           html. Or customizing how the scrolling should behave.
  zcorpan: For scroll into view there is a dictionary to customize.
           but for focus there is no way to turn off or customize
           scrolling.
  zcorpan: There is a proposal to do these things. The open issue is
           what the API shape should be and the semantics and how to
           get interop on default behavior.
  <zcorpan> https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688
  zcorpan: On one comment there is a table describing default
           behaviors in browsers.
  zcorpan: In chrome, opera, safari the behavior is different between
           if it's partially in view or entirely out. In FF and Edge
           there's no scroll if it's partially in view. You get
           nearest alignment if it's entirely out of view.
  zcorpan: That's where we're at. We should figure out a way forward
           and a way to address these use cases.

  florian: One thing mentioned in discussion is there is a number of
           event options we might want to support. You don't strictly
           need them but it's not convenient. Probably should take
           some shortcuts, but how many isn't clear.

  fantasai: I had a question on this point in terms of the options for
            start vs end alignment of the thing you're scrolling into
            view. These conflict with the scrollsnap properties. My
            question is are these options necessary Do we need
            something in JS to override them? Do we use those prop
            instead?
  fantasai: Has anyone thought about that?
  florian: My intuition was the JS do the eq/ of maual and when you
           release scrollsnap kicks in. I haven't thought in depth.
  zcorpan: I haven't given enough thoughts about integration, but they
           should pay well together and cssom view should be aware of
           scrollsnap.

  fantasai: What's the impl status of the options?
  zcorpan: I don't know the current interaction.
  fantasai: No, are the options implemented and deployed or just in
            spec?
  zcorpan: ScrollIntoView is impl at least in firefox and chromium.
           I'm not sure if they're interop. It would work for basic
           things. I think 'nearest' keyword isn't supported

  fantasai: I think it would be worth thinking about if we need these
            options or rely on css properties. If you have
            ScrollIntoView why would you set a value different then
            scroll snap. If there isn't the property many not need to
            exist. If they do we need to think from that perspective.
  dbaron: There's definitely use cases for this when not using
          scrollsnap.
  fantasai: But we have wording where if something has a snapping area
            defined and you target that you can use the scroll s nap
            into to choose the scroll offset. Snap area has a meaning
            without snapping.
  florian: That tells you have for offset from to top edge if your at
           the top. It doesn't say how offset if you're at the middle.
  fantasai: Scroll snap align would tell you.
  florian: But only if you're snapping.
  fantasai: By default that value is none. You're not choosing an
            alignment, just marking an area.
  fantasai: But if you have an alignment it means you have a preferred
            alignment when that element is being considered.
  fantasai: As far as the JS is concerned it's less powerful and has
            to duplicate it with every call and keep track of that.
            The declarative method has that associated with the
            element the element tells you the information.
  fantasai: The only reason I can think of is if there is a scroll
            alignment and you want to do something different and you
            may or may not snap to the preferred behavior anyways. I'm
            not convinced that's something anybody wants.
  fantasai: I think that needs thought as to if we need those options.
            The information it's giving you for scroll options are
            less powerful then th scroll snap options.
  dbaron: I think many of the JS interactions the behavior you want is
          specific to the interaction. If you're tabbing through
          controls and focusing on next you want different the reverse
          tab and focus previous.
  fantasai: Right, but that's generally going to fall out of UA. If
            next and previous rearrange based on layout it won't help
            you. UA should choose if you shift to top or bottom and
            pick the right side. Doing that manually through JS
            doesn't seem right.
  zcorpan: I think the point is that the one who decides the
           behavior...like if you write an app it's the JS dev that
           makes the call to pull into view, not the UA.
  fantasai: Scroll into view the UA chooses a position to have the
            thing in view. It's an optional argument so if you leave
            out start or end it'll do dbaron's behavior but more
            intelligently. The JS dev doesn't have to figure out lots
            of things.
  florian: But in some cases it doesn't. In some cases it just centers
           the thing.

  jihye: First of all when I suggested to add some options to control
         scrolling when focus is called I wanted to prevent scroll or
         make smooth scrolling. I think if that can be handled by
         scroll snap?
  fantasai: No, but the start vs end is provided by scroll snap. I
            think you were trying to add this to a new API and they
            were copied over. I don't think anyone has thought through
            does anyone need this option if we have scroll snap. I
            think we need to add the auto non smooth, but my concern
            is adding start and end and in having it in the API. I
            don't know why it needs to be in JS if there's css
            properties to control it.
  florian: Another axis of reflection is how much do we want to expose
           on in view, partially out of view, out of view...how much
           do we expose? Do we want a numerical threshold, leave it to
           browser? There's various use cases we can think of and
           various levels we can expose.

  Rossen: Going back to zcorpan...in the beginning of your description
          you had a more specific question of focus and if it should
          align the same as scroll.
  Rossen: The rest of the conversation seems necessary around if we're
          going to expose these APIs and dive into how this interacts
          with scroll snap. I'm trying to wind down the discussion.
          zcorpan is there anything else you want from this?
  <zcorpan> https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688
  zcorpan: Regardless of API shape and scroll snap interaction there
           is the default behavior of the focus method and how it does
           scrolling. Do we want to align the behavior between
           browsers and, if so, what should that be?
  Rossen: Seems like webkit based browsers have one type of behavior
          and edge and FF are aligned to not scrolling if it's
          partially in view
  Rossen: So impl, would this be something that you're interested in
          aligning to and, if so, which should we align to?
  <tantek> IMHO interop on that would be good, I would think webapp
           devs would like it
  Rossen: As an impl I'm personally for interop where possible, but
          I'm not sure which is better b/c I haven't spent much time
          on it and seeing how it intersects across windows platform.
          But I want to hear what others thinks.
  <tantek> +1 Rossen

  florian: Additional question: has anyone checked if behavior is done
           when calling focus method when there is padding?
  zcorpan: If you check in the link
  <zcorpan> https://jihyerish.github.io/all-about-focus/
  tantek: Another question is if the scrolling is similar to fragment
          link scrolling since that's done on to an element.
  zcorpan: That is governed by html spec and calls scroll into view
           algo.
  zcorpan: I'm not sure if that's what you're asking.
  tantek: I'd be surprised if that works differently as an app dev.
  Rossen: I want to wind this down.
  <florian> answering my own question from earlier: tab focusing and
            script focusing appear to have the same behaviors
  <florian> Also, based on the example pasted above, the FF/Edge
            behavior seems much more intuitive to me. Could be
            different in different examples, and could be subjective,
            but for this one and for me, it's very clear.

  Rossen: What you were looking for was alignment between focus and
          scrolling. It seems your question to impl was answered as
          either they don't care or they're happy with what they have.
          Either case, the topic is still open. As fantasai pointed
          out there are a lot of things to think about in terms of
          snapping and how these should interact.
  Rossen: I suggest we take those new questions back to GH. If not we
          can work through during F2F. It seems your specific question
          about focus isn't quite answered.
  zcorpan: I think an option for going forward is if we can quickly
           agree on API shape or behavior then trim down properties to
           be able to disable scrolling in focus and then JS dev will
           have to use intersection observer and ScrollIntoView.
  fantasai: I have no problem with aligning params between focus and
            ScrollIntoView. I don't have an opinion on the default,
            but having the same options is reasonable. My main
            objection is I think part of the API shouldn't exist, but
            that's applicable to both.
  Rossen: Agreed.

  Rossen: Again, I was hoping you could get a better answer, but it
          doesn't sound like there is one. Let's go back to GH and I
          invite impl to think what the default should be and if we
          can align. Focusing is important. People with a11y needs
          require that quite a bit. I'm going to continue advocating
          for alignment here.
  fantasai: It seems to me there's 3 issues. 1) what's the default? 2)
            should there be options to change the default 3) those
            options, should they have params that would override
            scroll snap or not. If we override scroll snap how does
            that work.
  florian: And another where do we care about things that are
           partially or totally outside the screen.
  Rossen: We'll have those recorded in the minutes and if needed we
          can split into sub issues.

CSS UI 3
========

Auto cursor should behaves as default cursor except for text?
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1598

  florian: We've already narrowed problem considerably. It's only
           about distinguishing things we can't in UA stylesheet.
           There's two things reopened. We say one cursor over text,
           one over everything else. We should change that to be one
           over selectable text. That was in originally, seemed an
           unintentional omissions.
  fremy: I can give some background as to why this is useful. If you
         have text inside a button you don't want the cursor to become
         a text cursor, but you don't want that. To me it seems
         straight forward and most browsers are doing this. I think
         that should be in the spec.
  florian: I sort of have this in L4. In L4 I put an exception to not
           look like text cursor. I forgot the other things that might
           make the text not selectable. [missed]
  Rossen: What is the request?
  florian: For a resolution to change the definition of the auto
           cursor to change on selectable text, not all text. I'll
           make edits.
  <tantek> and I already +1 that here:
https://github.com/w3c/csswg-drafts/issues/1598#issuecomment-335863545
  <tantek> last week

  Rossen: That would mean change of behavior...fremy your example.
          What would the change mean to you?
  fremy: We are already doing this in edge. I think all browsers also.
  fremy: This is aligning spec with browsers.
  dbaron: Were you going to get to the editable thing?
  florian: I wanted that sep.

  florian: Proposed resolution: Change the definition of cursor auto
           to look like text over selectable text.
  Rossen: Objections?

  RESOLVED: Change the definition of cursor auto to look like text
            over selectable text in CSS UI 3.

  florian: Second part is another thing where we may want to align to
           browsers, but it contradicts previous intention. In the
           general case browsers change to text cursor over editable,
           even if it's not next. This is doable in UA stylesheet, but
           we're interop in not doing that. There's reluctance to
           change, especially on Chrome side. Do we want to change or
           grant an exception for this because we are interop?
  Rossen: Opinions? Esp from Chrome?
  Rossen: Do we have anyone from Chrome?
  Rossen: I guess there's no one from Chrome.
  florian: Chrome seemed if other browsers commit to change and we
           push hard they'll do it. They probably don't want to be
           alone in this. I'd like to hear from Mozilla.
  dbaron: I'm fine with having editable thing in spec. It's not 100%
          clear to me that read/write pseudo does the right thing here.
  dbaron: I just haven't thought through it. I'm okay with the
          editable exception.
  <tantek> +1 similar thoughts to dbaron
  fremy: I'm in favor too. It's interop in all browsers. We can
         change, but I don't think we need to. I don't think author
         would expect it and changing something interop could cause
         problems. My opinion is we should make the change to make
         things easier for impl.
  Rossen: I hear a lot in favor or don't mind.
  Rossen: Objections to adding an exception into L3 UI?

  RESOLVED: Add exception for editable text into L3 UI

  <tantek> ready for CSS3-UI PR?
  florian: That probably takes us to a passing test suite and we can
           begin to move toward rec
  <tantek> SGTM

CSS Grid
========

Percentages and intrinsic size
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/509

  Rossen: fantasai summary?
  fantasai: There is...the never ending topic keeps branching into
            variations. The current variation has 2 issues. First is
            that the resolution we took on percentage sizing, we made
            edits that are symmetrical for block and inline axis.
            Igalia guys said we implemented asymmetric. So that's an
            issue of do we want to change for symmetric.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551
  fantasai: Summary comment ^
  fantasai: Basically, I think we resolved this is correct behavior,
            but if someone thinks different we should discuss.
  <rego> related to first issue, this comment is also important:
         https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334437618

  <fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096
  fantasai: Second is what do we do with % gaps. All options ^
  fantasai: C and E are terrible. F is impl by chrome. B and D are the
            ones they're combining. Gecko does A.
  fantasai: I don't have a strong opinion, but we should think
            carefully. We have a mix of impl and we need impl, spec,
            and authors to agree on best option.

  rego: Regarding first issue, I think the change to make symmetric
        for columns and rows is contrary to rest of impl. We've been
        checking options and if we do it we have to do extra passes.
        We'd like to check if other impl will do that or if we should
        revert status.
  fantasai: Another pass for track sizing algorithm, or just through
            the items?
  rego: We believe it needs another pass of the algorithm. We were
        finding some strange issues to resolve that.
  Rossen: Are you talking about the % resolution of gaps?
  rego: Tracks
  Rossen: Okay.
  Rossen: And there's no interop?
  rego: There is interop, but it's contrary to what the resolution
        says.
  fantasai: It's an intrinsically sized grid with a % size grid track.
            Does that % resolve. It does with columns, not with rows.
            Spec says resolve in both axises.
  <rego> the spec text is:
  <rego> > then the must be treated as auto, for the purpose of
         calculating the intrinsic sizes of the grid container and
         then resolve against that resulting grid container size for
         the purpose of laying out the grid and its items.

  TabAtkins: Current is similar to how block works.
  Rossen: But block has nothing to do with grid. We shouldn't define
          one layout system with a completely different. The original
          desire to keep things symmetric in grid was based on how a
          good system should work. it's up to us to decline from that
          model, that's fine if this is what everyone agrees we should
          do. But let's not justify current with what we intended.
  TabAtkins: Sure. We're just saying block behavior wasn't an
             accident. It was reasonable to avoid extra layout in
             common cases. Might not be right for grid, but there was
             good reason behind our choice to copy it over.

  Rossen: Trying for progress. Current proposal is to back out on our
          original resolution from Seattle and go with the asymmetric
          one.
  TabAtkins: Intention isn't to get a resolution this week, it's to
             bring it up for talk later.
  Rossen: If you're not asking for a resolution, let's keep working on
          it. We should resolve on this during F2F at the latest.
  fantasai: Agree.
  <rego> this was the change from the resolution:
         https://github.com/w3c/csswg-drafts/commit/15cf0c6d56efdbb44383134ebe19dff672b01546
  Rossen: We should put a time limit on this. We'll have to get
          consensus.
  <tantek> It does feel like an issue that would benefit from seeing /
           discussing diagrams in person at the f2f
  <tantek> Have we made progress on this at previous f2fs?
  fantasai: It would be useful for people to think and comment on the
            GH. Understanding the ramifications of this is most useful
            if people think through use cases and behavior and we're
            not going to get that around the table.
  Rossen: Agree.

  Rossen: Did you want to discuss gap % resolution or should we let
          that go?
  TabAtkins: I don't think we'd get that in 4 minutes.

Filter Effects
==============

hue-rotate() is being used with unitless zero angle
---------------------------------------------------
  github: https://github.com/w3c/fxtf-drafts/issues/228

  TabAtkins: When we realized several impl support unitless angles we
             marked out the few to worry about and then said not to do
             it in the future. Our dev figured out what is used and
             the only one we didn't consider already is hue-rotate.
  TabAtkins: Proposal is we add hue-rotate to the list of functions
             that explicitly allow a unitless angle.
  TabAtkins: I don't believe we need anything else.
  Rossen: Options against?
  Rossen: We're fine with that. I see dbaron said on GH he's okay. I
         +1 his request to add a web platform test with that issue.
  Rossen: Objections to accepting hue-rotate as an exception to
          unitless values?

  RESOLVED: Accept hue-rotate() as an exception to unitless values

  ACTION TabAtkins to add a test case
  <trackbot> Created ACTION-865

HTML
====

Change default <sup> and <sub> styling?
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1888

  TabAtkins: Dominic read an article about <sub> and <sup> and was
             wondering if he could change html stylesheet to support
             them instead of the basic way we do. I think it's okay,
             but we need yes/no from other people.
  florian: There are comments. The problem is when you start nesting.
  TabAtkins: Okay. Reasonable.
  Rossen: Let's put it back to the issue. There's discussion. We'll
          bring it back next week.

  Rossen: That's the top of the hour.
  Rossen: Thank you everyone, we'll talk next week.
Received on Thursday, 19 October 2017 00:26:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 19 October 2017 00:26:10 UTC