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

[CSSWG] Minutes Paris F2F 2015-08-27 Part IV: will-change, Scroll Snap, Input Modality [will-change] [css-snappoints]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 14 Sep 2015 13:59:15 -0400
Message-ID: <CADhPm3tHwb3zAhxGTLpOzVJejfz1Q-ZAn9DYgNVHqqH3266HPw@mail.gmail.com>
To: www-style@w3.org
will-change
-----------

  - The will-change property will still be applied even if it
      doesn't change. Though it may cause the page to slow down,
      that is because authors didn't design their pages well, not a
      problem with the property.
  - will-change with animations will still create a stacking context.

Scroll Snap
-----------

  - Mozilla expressed a concern about the changes discussed
      yesterday: they were worried that they would make the changes
      but no other browser would.
  - A timeline was established to make the changes discussed so that
      browsers hopefully should have time to make the changes
      necessary to converge on implementation of the better behavior.

Input Modality
--------------

  - bkardell brought his proposal for a pseudo-class that allows
      control over the focus ring depending on the input method.
  - There was wide agreement that it was a useful and needed
      property.
  - RESOLVED: bkardell as editor of new ED for input modality (name
              pending)

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

  scribe: dael

will-change
-----------

  smfr: I recently put it in webkit and had some issues. The first
        one is uncontroversial. It implies that will-change creates
        a stacking context.
  smfr: Second concerns me more: if you say will-change: transform
        and apply it to something it doesn't work because it
        currently implies you get a stacking context. I'm worried
        that we'll have memory overhead and I'd prefer to avoid if
        the property doesn't apply.
  TabAtkins: I would like to keep it with current behavior because
             the definition of if something like transform applies
             can be complex over the tree. If you're the child of a
             flexbox you'll get blockifed eventually. We try to
             limit the information needed to evaluate a property.
  smfr: The stacking context issue is normative. I'd like to hear
        from other implementors if it's a problem.

  ojan: Is this not a problem today with * { position: .. }?
  smfr: They don't for performance but they will for transform?
  ojan: Won't the page fall over if they do that?
  TabAtkins: Half fall over.
  smfr: So you'll have z-index tree building every time.
  dbaron: I think it's a way for authors to shoot themselves in the
          foot.

  hober: If we're trying to replace it to 0 we shouldn't replace
         with worse performance. Transform to 0 would only happen
         for things that transform applies to.
  dbaron: Do we see authors using it with *? The translate-z hacks?
  smfr: Occasionally, yes.
  ojan: My personal opinion is we observe people doing bad things
        all the time. We think we just need to make it cheaper.
        That's our plan, we haven't gotten there. Is creating a
        stacking context expensive for you? It is for us but we're
        trying to make it less so.
  Rossen: It could be for us.
  dbaron: My intuition is it doesn't seem that expensive but I
          haven't measured.
  ojan: The degree in webkit doesn't seem fundamental. I don't feel
        too strongly for performance.
  ojan: I don't think it's fundamentally efficient. We have to fix
        it anyways because there's so much context being relaxed
        about creating stacking. We were going to fix it anyways.

  tantek: If I understand in terms of being a hook for UA to
          optimize, was there a reason why a no value was omitted?
  gregwhitworth: That's the default.
  tantek: It's auto. If you can know it will not change you can do
          optimization. We have this table-layout fixed in CSS 2.1
          you know it will not change.
  TabAtkins: One reason is the optimizations you use will layout
             horribly if the author lies. If the author says it will
             transform it produces correct results even if it
             doesn't.
  TabAtkins: If I say will-change: none and you've optimized, you're
             not incorrectly rendering. If you say will-change:
             transform and you don't it's fine.
  zcorpan: I think tantek is changing the semantic where if you say
           'no' the UA will actively ignore changes.
  smfr: That makes will-change more powerful. This is meant as a
        hint to optimize.
  TabAtkins: The only effects it has that are observable except for
             performance is for those things that you say would be
             visible. I would have had it have no observable effects
             if possible.

  plinss: What you're suggesting is doable, but should it be a part
          of will-change? You could have a property that says freeze.
  zcorpan: It seems to me if something doesn't change it's not going
           to be a performance bottleneck. It's not worth optimizing.
           There's no reason to introduce will-change: no.
  TabAtkins: Everything else is as fast as we can make it.
  zcorpan: It seems like another source of bugs.
  tantek: You couldn't cache whole sub trees?
  TabAtkins: If we were it would be a whole new property.
  TabAtkins: The complexity of trying to determine if this would
             apply I think makes this inadvisable. Putting
             * { will-change } is bad because everything says don't
             do that. If they do that, screw them.

  shane: Will-change is designed as a hint.
  dino: Except it has normative behavior.
  shane: If you say will-change you're saying whatever values I put
         in will change.
  dino: Browsers without will-change will get better performance.
  TabAtkins: On the pages where the authors have screwed themselves
             yes. Well-designed pages no.
  TabAtkins: This is complicated and reduces the ability of Servo's
             efforts to do parallelization.

  smfr: I'm willing to live with this if the other vendors think
        it's okay.
  MaRakow: No strong opinion.
  ojan: I could go either way.

  smfr: Third question is should will-change with animations create
        stacking context.
  smfr: You can also say will-change: display or position and those
        aren't animate-able.
  TabAtkins: They are animate-able. They flip at 50%
  smfr: It doesn't benefit from optimization.
  TabAtkins: It prevents you from opacity 100 to opacity 99.9999
             flickering. You'd have a layout change. I think it's
             still preferable to apply stacking context.

  smfr: Other opinions?
  smfr: Again, I'm good as long as other browsers think it's okay.
  ojan: Seems fine to me.
  hober: Opinions from Mozilla?
  dbaron: Not particularly.

  TabAtkins: If you're doing hacky position: sticky and you have
             things that care about stacking it would be nice if you
             get a nice position change.

Scroll Snap
-----------

  dbaron: Yesterday we were talking about changing snap points to
          address feedback from a few years ago. It sounded like a
          bunch of others were okay with changing. The concern we
          had is we're willing to change to match the new thing, but
          if no one else does the new thing we'll have to change
          back.
  dbaron: The question is, even if you ship with prefixes, the
          authors will write the prefixes.
  dbaron: So basically we sort of said yesterday people were okay
          with changing the spec and that should be contingent on
          the people being willing to ship the new thing and get rid
          of the old thing.
  TabAtkins: Agreed.
  TabAtkins: I need to discuss further with Matt. The only thing on
             the table for changing was scroll-snap-coordinate.
  TabAtkins: I agree. Even if we decide we should change to -align
             if the currently shipping browsers don't drop and
             change we'll have to change the spec.

  dbaron: I'd be interested in hearing from Apple and Microsoft.
  MaRakow: Ours is old so it's not compliant right now. We have just
           snap-points-x and -y.
  ojan: There's another difference that no one has shipped which is
        snapping with layer changes.
  MaRakow: We don't. Our is from 4 years ago.
  TabAtkins: Theirs is setting up distances on a container.
  ojan: If the height of an item changes...
  TabAtkins: You're fine. Their implementation doesn't care, it's
             too old.
  ojan: My understanding is Apple and Mozilla do not re-snap if the
        height of an item changes.
  smfr: I forget what we decided to do. I don't think it's relevant
        to this discussion.
  ojan: It's the what's happening in the spec. What people have
        shipped doesn't match spec.
  dino: Spec doesn't say what to do.
  ojan: It does.
  dino: Isn't that a bug?

  Florian: If nothing matches nothing okay, but the more things that
           match the harder it is to change.
  Florian: That the Microsoft implementation is significantly
           different makes this easier.
  smfr: And the interoperability is on scroll-snap-points which is
        proposed to drop.
  fantasai: We can keep it. I'd rather keep it than not change the
            model. We don't see the use case, but it's not blocking
            us from going forward.

  plinss: Sounds like everyone is okay with dropping the bits you
          want.
  fantasai: Everyone wants to keep the bits we wanted to drop, but
            is okay changing the things we want to change.
  TabAtkins: That would leave me 80% happy.
  fantasai: I don't have an objection to -x and -y. If that's where
            we start it's not harmful in any way. You implemented
            with the repeat?
  MaRakow: We have list and repeat. The repeat syntax I think there
           might be a small syntax difference but it's functionally
           the same.
  fantasai: Okay. That's helpful to know.
  MaRakow: We're prefixed also.

  fantasai: So we need a new model. We're not constrained because
            the only interoperability this is repeat.
  MaRakow: I'm not sure how interoperable Mozilla and Apple are.
  ojan: Some analysis that one of our folks did is there is quite a
        bit of difference. The specific thing I can think of is if
        descendants feed into your snap points.
  ojan: I think that was the big one so maybe that's not true
        anymore.
  ojan: I think the layout thing is the only thing.
  rbyers: I don't think there's any snap on program scroll.
  smfr: We decided not to.
  fantasai: If you want it you could add an API.

  MaRakow: We had an open issue, but that was removed when we
           decided we wanted to clamp down to the stuff agreed on.
           We're still interested in a snap to next or snap to page
           20. As it's currently written any type of scroll, the
           snap points talk about the stasis state. Once you've
           reached steady it's mandatory you be attached to a snap
           point.
  MaRakow: If you're programmatically scrolling to 99 you go to 100.
  rbyers: What's a steady state?
  TabAtkins: You've stopped moving.
  MaRakow: There are going to be issues for users that don't support
           animations. I think everyone has a definition of having
           reached a destination.
  smfr: Is there text in the spec that says that?
  MaRakow: Yeah, there's text.
  <MaRakow> In the definition of mandatory-type snap points: "it
            must come to rest on a snap point at the termination of
            a scroll, if possible"
  <MaRakow> http://www.w3.org/TR/css-snappoints-1/#scroll-snap-type

  plinss: So are we done on scroll-snap?
  fantasai: I think so.
  dbaron: I think we heard from one implementor, but not from Apple.
  dino: We don't comment on future releases.
  dbaron: I'm inclined to say given that response we should leave as
          is.
  dino: You're not asking if we would implement the new and improved
        spec you're asking if we'd stop implementing what we have.
  dbaron: We've implemented what the spec has now. If the spec
          improves we'd implement the new thing if we have
          reasonable confidence that we don't have to go back to the
          old thing because people are writing for Apple.
  dino: What you really want to know is would we drop our support
        for the old spec. I don't know...
  smfr: We'd be willing to implement new stuff if the existing stuff
        is still mostly compatible.

  Florian: I would be equally concerned if the Apple implementation
           and Microsoft's had been similar. Given that what we want
           to change is not interoperable I feel less bad about not
           having an answer.
  ojan: I think dbaron's point stands. If Apple is unwilling to
        remove others must implement.
  fantasai: Not necessarily true. They haven't shipped yet so if we
            could get the stuff out quickly...
  dino: We sent it out 3 months ago.
  fantasai: Testing builds are separate.
  astearns: But they're a good indicator for very close future
            things.
  fantasai: But websites won't build thing that only work in a
            testing browser.
  dbaron: It's not just web that will be on it.
  fantasai: If we get something in the next year and people are
            working toward interop Apple will move to that.
  dbaron: I may want to come back.
  dino: If theres a new spec we'll want to support that with others.
        If we want to remove something we'll have to make that
        decision when the time comes.
  Rossen: That's fair.

  rbyers: Do you have concerns about shipping prefix and unprefix
          that aren't the same.
  dino: It's annoying but...
  plinss: It's prefixed.
  dino: Yes.

  MaRakow: This will be easier to have a conversation once I've
           talked more with TabAtkins and fantasai. We all want to
           be cautious about not changing things we don't need to.
  dino: The best way to address this is get the spec out.
  fantasai: We have a rough draft. Our goal should be something
            that's stable enough that it's clearly better in three
            weeks. Work on something until TPAC. If we can maintain
            that timeline we can make a decision on what's going on
            and people should be able to build and ship in a
            reasonable timeframe.

Snapshot 2105
-------------

  <fantasai> http://dev.w3.org/csswg/css-2015/
  <fantasai> https://drafts.csswg.org/css-2015/#experimental
  fantasai: That's the snapshot. There was the discussion on this
            section (second link). I did a bunch of rewording and
            you can see where the changes are. Please take a look
            over the break so if we agree or if you have concerns we
            can talk about that I can keep working on it until we're
            happy.
  tantek: Can we slot time into the agenda
  <tantek> this is important enough to get folks in the room to
           hopefully agree.

  [break=15min]

Input Modality
--------------

  plinss: Are we waiting for bkardell to call in?
  bkardell: I'm here.
  bkardell: So basically if you create an interactive element in
            HTML, since around 2007 browsers have been figuring out
            what to do with the focus rectangle so it's optimal
            regardless of the browser.
  bkardell: When you're clicking people have different expectations
            than the keyboard. When we did selectors focus we were
            only on :focus. When an author uses :focus they're not
            consulting the same source of truth as the native style
            and the result is the author disables focus rings
            altogether.
  bkardell: There's no way to deal with this without really specific
            rules.

  bkardell: Alice Boxhall and I got together and wrote a proposal
            that would expose the user's modality that would explain
            how you interact. We wrote the governance rules around
            what browsers do.
  <bkardell> https://github.com/alice/modality/tree/master/docs
  bkardell: We created a policy around how to do it and retain the
            a11y aspects. We created a property that was originally
            MQ based. After discussions with other folks there was
            an idea it was better off being a pseudo-class.
  bkardell: I'm pretty okay with the pseudo-class. I think the MQ
            made more sense for an author, but it's marginal.

  Florian: It seems to me either way to make this work you're
           relying on the same logic as pointer and hover MQ which
           is given a set of inputs connected to a device figure out
           which one is primarily being used. So even if there's a
           mouse and a keyboard, the user is primarily on the mouse
           so use that. That's the same consideration.
  Florian: Having looked briefly at your proposal, should we design
           these together or separate? They seem similar enough to
           think together.
  rbyers: There's a fundamental differences between a MQ and this
          where the MQ are saying at any given time what is the
          state of the system.
  Florian: You're implementing wrong. You don't need to flicker
           every time the user is close, but there's a notion of
           what is the primary thing.
  rbyers: In many cases there is no input.
  rbyers: In bkardell's case the user was just introduced with
          something. The MQ was before they interact.
  Florian: Just because the user touched the mouse, but you are
           primarily navigating between with tab, you're clearly on
           the keyboard. You need heuristics to deal with that. The
           MQ were designed for similar logic. It's the same logic.
  rbyers: It sounds to me like bkardell's thing is meant to have
          context. It sounds to me like how is this being handled.
          If I click with the mouse and touch the touch screen it
          could cause two different modalities.
  Florian: I'm not saying one replaces, I'm saying they're similar
           enough that we should have a common model.
  rbyers: MQ have to rely on some heuristic whereas I'm hoping
          bkardell can be very specific.

  bkardell: That's interesting because I had not considered that. In
            our discussions we did discuss the document had the
            modality which is more along the lines with the MQ
            things. It's an interesting point as to what if you did
            both at the same time. What would happen? browsers are
            single threaded.
  TabAtkins: This is a red herring.
  TabAtkins: One will happen before the other.
  TabAtkins: You can multi-touch, but it's one event at the same
             time.
  Rossen: And they can sometimes be in the same frame.
  TabAtkins: But one fires before the other.
  bkardell: Basically there can be only one.

  TabAtkins: The use cases for modality, the mixture is the best use
             case. You want focus rings as you tab through a form,
             but not the button after you click.
  Florian: Both have a primary thing, but this is more fine grained.
           You want to switch on and off at a higher-grained level.
  TabAtkins: The point is how you have focused something. That's
             what the modality is about. In addition to the
             semantics talk, MQ for something changing rapidly are
             the worst.
  TabAtkins: I was confused when I first read it as a MQ, but the
             intention is how you interact with a given input is how
             it works.
  esprehn: This is how the browser works. When you click an input
           you get a focus ring. If you tab to a button you get a
           focus ring.

  Florian: I don't know what is the latest version, but does it need
           to enumerate the things?
  TabAtkins: There are two modalities, keyboard and mouse.
  bkardell: Keyboard and not keyboard.
  Florian: If it's binary that's fine.
  TabAtkins: It's all about, like, if you're activating something by
             literally touching it vs. the computer moving you
             through the document- that effects if you want a focus
             ring.

  bkardell: There's been discussion on the spec and we've had
            feedback. Maybe call it sequential. Part of why it's a
            modality thing is we can build up abstract names that
            include more or less that way. Sequential is better than
            keyboard.
  Florian: It's still wrong because you can have spacial navigation.
  TabAtkins: We can name later. There are two modes. The computer
             sending and your physical actions.
  Florian: You're on a physical keyboard, but when you get close
           enough to a button it snaps there.
  TabAtkins: The presence of your pointer is enough to call that
             mouse.
  Florian: I probably agree, but this is gray zone.
  TabAtkins: Basic proposal is as some pseudo class on some elements.
  Florian: Focusable elements
  TabAtkins: Yeah. This is exposed with the two values. fantasai has
             a registered dislike of 'mode'. Does the WG feel this
             is useful in terms of explaining in the platform?

  tantek: I would like to know if authors care and would they do the
          work?
  TabAtkins: Authors right now just turn off the focus ring a lot.
  TabAtkins: The reason that even a11y guide that says don't do that
             isn't too successful, what they want which is no focus
             ring on button is why. I think as general a11y
             tutorials will get it.
  tantek: For that use case, anyone could provide a style rule that
          says if you're going to do focus-outline: none thing, do
          the button. Authors are good at copy/paste.
  Florian: There's nothing they can copy. If you do
           focus-outline: none it will remove the outline.
  TabAtkins: It's bad a11y. They can say use this with the thing
             that means cursor with focus and you're golden.
  <tantek> if this is just about how something acquired focus, then
           what about just :focused(modality)
  <tantek> e.g. :focused(keyboard)
  <tantek> "modality" is an unnecessarily abstract term
  <tantek> bkardell are you committed to the term "modality" or are
           you open to alternatives?
  <bkardell> tantek: very open
  <Florian> modality -> focus-source
  <Florian> not-keyboard -> pointer
  <tantek> Florian I think the choices are keyboard vs.
           direct-manipulation (pick a better name)
  <tantek> where direct-manipulation could further be broken down
           into touch vs pointer
  <tantek> note that touch != pointer
  <tantek> but they behave *somewhat* similarly, not the same
  <tantek> and both very different from keyboard
  <tantek> like no need to even use :focus
  <tantek> if you have :focused()
  <bkardell> http://discourse.wicg.io/t/exposing-a-users-input-modality/1067/33
             some good discussions on this here re: naming and all
             the WG should look at
  <Florian> tantek: good point.
  <tantek> or heck :focus(keyboard)
  <tantek> why do we need anything new besides a param for :focus?
  <tantek> (sorry if this is premature bikeshedding)
  <Florian> tantek, because we need it on active as well?
  <zcorpan> :keyboard
  <Florian> tantek, and maybe on hover as well?
  <TabAtkins> tantek, Matt just said the WinJS team wanted to do it
              with more than just :focus, yeah
  <tantek> ok
  <tantek> thanks TabAtkins, Florian
  <tantek> I still dislike the abstract jargon of modality
  <tantek> would prefer something like :from
  <tantek> e.g. :focus:from(keyboard) or :active:from(pointer)
  <tantek> I like more readable selectors
  <bkardell> jquery supports +1 ;)
  <tantek> +1 on what?
  <bkardell> tantek the name is discussable for sure
  <bkardell> tantek +1 on adding this

  bkardell: I think any time we do anything we are to an extent
            specifying if authors will use it or get it. I really
            believe we should do things based on data. We've proven
            the need because this has been experimented since 2007
            at least and there have been lots of feedback. Every
            user of the web has tested it as useful.
  bkardell: If we can write something intuitive enough...we have a
            polyfill of it. The model should be for us to write a
            spec and provide a polyfill that's cross browser and
            give it to early adopters to find if we missed the boat.
  TabAtkins: I think this will be used because you can write a
             simple rule and copy/paste and it does the thing you
             want. This feels like the kind of a11y improvement that
             will succeed.
  bkardell: I think we could prove it easily.

  MaRakow: On author interest, this is functionality that the WinJS
           team asked for. The intention there was to change the
           style drastically. They were using a think board...this
           wasn't just :focus, but :active and :hover. There is
           interest there. tantek pasted a suggestion in chat that
           was very similar.
  MaRakow: This is ideally how you would want to implement as an
           active state for touch. This matches what we've heard
           requests for in the past.
  rbyers: Chrome has exposed a source capability on events. Whatever
          we want to name this we want to expose on device
          capabilities. Today when something gets focused you can
          say was this focused by something that is touch event.
  bkardell: Is there...that gives you back a string as an answer?
  rbyers: There's an object that only has one thing right now, but
          we'll want to add to that.
  bkardell: I'll read up on that.
  <rbyers> UIEvent.sourceCapabilities: https://github.com/RByers/InputDevice

  TabAtkins: It sounds like at least minimal browser support for
             adding this. Anybody oppose?
  Bert: The distinguishing factor if you want to include the focus
        does it matter on what the user did or the next expected
        action?
  TabAtkins: I think it is how you acquire focus. I think the thing
             is how you acquire focus. The point that makes the
             focus ring extra important is it's not predictable
             going between elements to know which one is next. When
             you're clicking it's not a mystery, it's what you just
             clicked on.
  Bert: But clicking on something like a text area, I want the focus
        ring.
  tantek: You can do that today. Regardless of how this got there.
          Just using :focus as is.
  TabAtkins: Right now the choices between authors always turning
             off outlines or getting an outline where most of the
             time you need it you get a focus ring.
  bkardell: Your intuitive thing is if you're going to touch the
            focus ring it has to do with your branding or design. As
            soon as you touch it your intuition is just write one
            rule. You say :focus, you give it a new outline, and
            quickly you'll realize it doesn't look right and people
            will see rings where an avgerage user won't and that's
            because it's not the same source as the native styling.
  Bert: I can see you select elements visually, but I was hoping for
        something where I could say all elements.
  Florian: Focusable is something different that we don't have.
  TabAtkins: On a well designed page this is maybe only buttons.

  * fantasai wonders if we want MQs for keyboard
  * fantasai and if this would integrate with it
  <fantasai> @media (keyboard) { has a keyboard }
  <fantasai> @media (keyboard: primary) { mainly using keyboard }

  TabAtkins: So objections to the feature and, if not, should we
             agree to write up an ED?
  Florian: Yeah.
  TabAtkins: bkardell as editor?

  RESOLVED: bkardell as editor of new ED for input modality (name
            pending)

  <fantasai> bkardell:
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPseudoClassList.h#166
Received on Monday, 14 September 2015 18:00:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:33 UTC