- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 14 Sep 2015 13:59:15 -0400
- 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