- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 21:28:23 -0500
- 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.
=========================================
Scroll Snap
-----------
- RESOLVED: Accept fantasai's proposal (scroll-snap-padding is
renamed to scroll-padding and scroll-padding reduces
the area of the viewport that the UA considers
“visible” when performing semantic scrolling
operations.)
- RESOLVED: No renaming of scroll-snap-type: mandatory |
proximity, because no better proposals.
- RESOLVED: No renaming of scroll-snap-stop: normal, because no
better proposals.
- RESOLVED: Accept the text in spec for snap scope.
- RESOLVED: CSS Scroll Snap to go to CR
Timing Functions
----------------
- RESOLVED: Split out timing functions into own module, Level 1 to
include functions that have been implemented for
awhile, Level 2 to include newer functions/proposals
- RESOLVED: birtles shane dino MaRakow to edit
Viewport API
------------
- This work will continue in WICG and Florian will join so he can
participate more.
CSS UI
------
- RESOLVED: If you click or click and drag in user-select:none
area, doesn't affect any existing selection
- RESOLVED: Keep outline-color: invert unless Edge decides to
drop, in which case we drop.
===== FULL MINUTES BELOW =======
Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda
Scribe: ChrisL
Scroll Snap
===========
scroll-snap-padding vs scroll-padding
-------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/395
fantasai: Scroll snap padding changed to more general
scroll-padding.
fantasai: Define which part of viewport is in view.
fantasai: Not to affect visibility but if it is in comfortable
position for viewing.
fantasai: Affects scrolling into view, through script or
interaction, page up/down, affects scroll from caret
movement,
fantasai: similar things. No effect on layout or scroll origin
except as affects snapping.
fantasai: Declarative replacement for js scroll hacking.
<fantasai> to accommodate UI elements floating over the scrollable
area.
fantasai: And request for caret operations.
fantasai: Same effect for scroll snapping, but more interactions
covered too and better UX.
Florian: If we have this, it makes a couple of old proposals
obsolete, and no need for the proposed properties.
Florian: Simpler way to address that.
MaRakow: There are objections around semantics of scroll snap for
snapping purposes, usage patterns on scroll padding.
MaRakow: Can't use one without affecting the other, see github
issue.
MaRakow: Do implementors have thoughts?
dino: Apple has no opinion.
jet: hmmm
jet: I will comment on github.
fantasai: This is last blocking issue.
Florian: Since Sydney at least.
fantasai: MaRakow argues that keeping things separate, odd because
most use cases the value is the same one on scroll
padding so one property for both uses makes sense.
fantasai: can separate by making a shorthand later if needed.
fantasai: Main use case for scroll-snap-padding is to block out
things too close to the edge or covered by UI
fantasai: Need to block out for all these scroll ops.
fantasai: If you do want a difference then set scroll-padding based
viewport
fantasai: and then use scroll-snap-margin on snapping element to
give a different spacing.
fantasai: So all use cases addressed and common case is easy.
fantasai: So accept this proposal please and make it easy to do
good scrolling.
TabAtkins: Agreed.
TabAtkins: It's useful to solve things right now. Same for
scrolling and snapping, make it generic of overflow
control.
jet: Is this from implementation?
jet: We have an implementation
TabAtkins: No it is super old and crufty.
fantasai: Filed because of working through spec and seemed the
author use cases not solved.
fantasai: All are simply solved by widening this property
fantasai: to more cases.
MaRakow: I'm confirming no other strong opinions.
Rossen: No strong ones but TabAtkins leans towards fantasai
strongly now, as is dino.
Rossen: So it is all you Matt.
MaRakow: Scroll snapping is specific alignment in the viewport
while the functionality is a range in view so
MaRakow: not guaranteed to be the same as the box that what
MaRakow: accessible in view box.
TabAtkins: All approximately right and when a bit different,
scroll-snap-margin handles just fine.
MaRakow: Could other implementors read the issue and chime in?
MaRakow: Does syntax get overloaded?
MaRakow: Others seem to think not.
<andrey-rybka> +1 for Elika's proposal
fantasai: If you really want to do it with padding then we can
split scroll padding into two longhands down the road.
Doubt we will.
fantasai: I'm not seeing the mismatch you think exists.
fantasai: Theoretical purity that should not override author ease
of use.
<jensimmons> +1 to that — one property that does many things. Not
multiple properties that are similar.
MaRakow: I'm not objecting strongly, want other opinions
MaRakow: on the githb issue.
<andrey-rybka> just a data point but what Elika proposed actually
solves many use cases for Bloomberg
Rossen: So as this is the last issue holding us from CR and to
move forward, call for consensus on current issue as
stated by fantasai. So no sustained objection?
Rossen: You want implementors to give a full read before making up
their mind?
astearns: More support of fantasai's proposal.
dino: Let's decide and adjust in CR if implementors find issues.
Rossen: ok with that?
astearns: This is the last open issue.
MaRakow: No there are still some.
fantasai: Two renaming but no proposal so rejected. One editorial,
conciseness. One resolved already.
fantasai: So just this one issue.
Rossen: So apart from editorial ones, no outstanding design
issues. MaRakow, agreed?
MaRakow: Offscreen mapping is one.
fantasai: Sitting with proposed text since june, at least.
fantasai: accepted previously the text was not good.
fantasai: Don't know what you are objecting to.
Rossen: Almost out of time.
Rossen: Call for consensus.
Rossen: Any objections:
(none heard)
RESOLVED: accept fantasai's proposal
Naming
------
fantasai: Rename anything? No actual proposal.
fantasai: So leave as it.
Rossen: Can we live with mandatory and proximity.
(no objections)
RESOLVED: No renaming of scroll-snap-type: mandatory | proximity,
because no better proposals.
fantasai: scroll-snap-stop normal and always, rename normal.
(no objections to keeping those names)
RESOLVED: No renaming of scroll-snap-stop: normal, because no
better proposals.
Snap Scope
----------
<fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-scope
fantasai: Wording in section on scroll snap, if the top edge of
a box is aligned over here way outside the viewport,
shouldn't snap to it. Should not care that it happens
to align, because we can't see it at all.
(we film the interpretative dance)
(literally)
fantasai: Honestly don't know what the disagreement is so can't
fix it.
Rossen: matt?
MaRakow: Point of snapping is to point to snap to the things out
of view currently and is this corridor scrolling the
feature only starts scrolling through the animation of
the scroll.
MaRakow: I understand the intention.
MaRakow: Outside x direction of the viewport is not contributing,
not strictly true.
* ChrisL thinks this is poorly captured sorry does not follow what
matt is saying actually.
Rossen: Proposed text?
Florian: I think this is the same issue as what I raised earlier
about the wording problem regarding the corridor, for
which I got convinced that it was fine.
fantasai: Different topic.
MaRakow: Might proposed something last time but not sure. path
scroll would take .... considered for snapping.
Rossen: Okay, fair if the spec does not say what exactly is
considered outside, needs to be better defined.
fantasai: Depends on which snap positions you consider to land.
this however is not that.
fantasai: What this prose is saying is that this position (with
the top of the box aligned, way off-screen) is not a
snapped position.
fantasai: like the illustration in the spec, offset in the wrong
axis so not snapped.
fantasai: When looking for snap positions can consider it, that's
up to UA, but can't snap to it unless also brought into
view
fantasai: So this is not about taking corridor into consideration.
Simple answers question: is it snapped? no it is not.
MaRakow: Have to choose one and need to know which are valid.
Scoped through custom scroll, intersection on x axis
fantasai: See the section on choosing snap positions
fantasai: this XY cannot be chosen, it is not snapped.
fantasai: Even if author manually aligns them there, ua is not
snapped there.
Rossen: this is in a different section.
<fantasai> https://drafts.csswg.org/css-scroll-snap/#choosing
fantasai: Section 6.2. this one is saying it is not in a snapped
state.
<fantasai> Section in question -
https://drafts.csswg.org/css-scroll-snap/#snap-scope
Rossen: Just ended up there by chance anyway, still not considered
snapped.
Rossen: Make sense?
MaRakow: I think so.
Rossen: So this addresses your issue.
MaRakow: Think so yes.
Rossen: Minor editorial clarifications in CR, lets resolve to do
so.
Rossen: Any objections to moving to CR?
fantasai: lets go to CR
<andrey-rybka> +1 for CR
(no objections)
RESOLVED: css scroll snap to go to CR
RESOLVED: to accept the text just discussed
Timing Functions
================
scribe: fantasai
birtles: Can we please start another spec?
birtles: Wanted to define timing functions for both transitions
and animations and web animations in one place.
birtles: Currently in Transitions, it's kindo f awkward.
birtles: Talked about having a frame timing function.
birtles: Apple has spring timing function.
birtles: Also talked about things like script-defined timing
functions,
birtles: Multi-segment timing functions,
birtles: all these things need to have a home.
birtles: So proposal is we make another spec for timing functions
birtles: and take it out of CSS Transitions and put all that stuff
there.
[general agreement]
fantasai: I think it's a great idea
fantasai: I would like to see that if it's pulled out of
Transitions Level 1.
fantasai: We have two levels of this spec
fantasai: one with the interop stuff that should go to CR like 2
years ago
fantasai: And one with with all the new stuff.
dino: Do we need an incubator? Can we just go.
Rossen: This is existing work, just splitting work that's in one
spec into another spec
Rossen: Continuing existing work.
Rossen: Don't see any reason to incubate, nothing new there.
Rossen: Would ask Tab, would you agree with this statement or not.
TabAtkins: Wasn't listening, so yeah sure.
shane: I want to answer for Tab, answer is it depends.
shane: Apple's spring timing function fundamentally breaks timing
function model.
shane: Would rather not see it in a timing function spec.
shane: Think we could accommodate it with the same syntax Apple
proposes declaratively in the scrolling animations spec, if
we generalize that.
sam: Which aspect of it fundamentally breaks the timing model?
shane: Previously, timing functions couldn't alter the duration of
the animation.
TabAtkins: More specifically, none of the timing functions had an
opinion on what the duration is.
TabAtkins: Have to do the math on spring, then set duration
accordingly.
TabAtkins: Otherwise looks stupid.
dino: Only looks stupid if you pick a stupid duration value.
shane: I thought the way it works was to change duration.
[confusion]
Rossen: Seems like agreement on continuing working on this.
Rossen: Let's go back to request for splitting work so we can
continue working on it.
Rossen: Then we can decide on what stays and how it stays.
Rossen: Do you agree with this, Shane?
shane: If the timing functions you want to consider require...
birtles: We can decide on where spring() lives later.
shane: I'm fine with that.
Rossen: Any objections?
RESOLVED: Split out timing functions into own module, Level 1 to
include functions that have been implemented for awhile,
Level 2 to include newer functions/proposals
RESOLVED: birtles shane dino MaRakow to edit
Viewport API
============
rbyers: ...
rbyers: Got some compete pictures and stuff, but short summary.
rbyers: Trying to incubate a new API that will finely explain
pinch zoom.
rbyers: Not trying to make all browsers behave the same.
rbyers: Not trying to fully define space.
rbyers: But incremental step to expose a simple API that lets you
reason separately about the space that the page is laid
out into and the space that the viewer sees.
rbyers: So, basically relative geometry and position of the layout
and visual viewports.
rbyers: Worked with websites, bunch of bugs.
rbyers: Sites are broken because make assumptions about this.
<rbyers> https://docs.google.com/presentation/d/1VxLlMTgrq11Q-ltPXyg5_7YuDAo00sbdElsRe752sQg/edit#slide=id.g861a184b2_2_237
rbyers: Think simple API can be used to address these cases.
rbyers: Demo/presentation
rbyers: Get a sense of the behavior.
rbyers: Talking a lot with MaRakow, he's given a lot of feedback
on the API.
rbyers: Here's the repo:
<rbyers> https://github.com/WICG/ViewportAPI
rbyers: Trying to get bare bones simple bit, incubate and iterate.
rbyers: Experimental implementation of this in Chrome now if you
turn on experimental features.
Florian: Looked over, seems good to me. Happy to keep in WICG.
Florian: I think the terms visual viewport and layout viewport
should go into device-adaptation because more than just
you is depending on these terms.
Florian: Please file issues against me on specific things you need.
rbyers: Most CSS specs need to be updated to say which viewport
for every place they say viewport.
rbyers: And no two browsers agree on which one for these things.
astearns: Florian, will you join the WICG group?
Florian: Yeah.
CSS UI
======
user-select: none and selectionchange event
-------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/319
Florian: Have a thing selected, and then click something with
user-select:none
Florian: Should it unselect? Should it?? or ???.
Florian: I was tasked to ask the editing task force.
Florian: Multiple people said doing things inside user-select:none
shouldn't affect selection.
Florian: Think we should resolve on that.
hober: I think it should match platform convention.
Florian: What is native behavior of clicking "user-select: none"
hober: Behavior of clicking on an non-selectable area of the UI.
Florian: Safari already doesn't match what Mac OS does.
johannes: ... when you cannot select them, you should not lose
your exiting selection.
esprehn: user-select:none causes us to unselect things, and we
want to change that behavior.
Florian: I think that's a separate issue. No interop, chrome and
edge said they'd match Firefox, and editing TF agreed.
* fantasai is confused what the behavior was
Florian: If you click or click and drag in select:none doesn't
affect existing selection.
Rossen: Any objections?
<andrey-rybka> +1 to resolve
RESOLVED: If you click or click and drag in user-select:none area,
doesn't affect any existing selection
dino: There should be an escape clause for platform convention.
dino: There are definitely parts of UI that are non-selectable in
the platform.
Florian: The fact that different browsers behave differently was
confusing JS users, so request was to harmonize browsers.
Florian: Safari would have to change, but after change would match
its own platform better. So what's the problem?
Remove outline-color: invert
----------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/423
Florian: outline-color has two color values. One is 'invert',
which is initial value. If can't 'invert', defined to
fall back to initial color.
Florian: There are two implementations, one relevant (Edge), two
irrelevant (IE, Opera). No process block.
Florian: Browsers are allowed to not implement inversion if
impractical.
Florian: Don't see any value in removing the value. But people
have asked to remove the value.
Florian: Use case that justifies this value is real, and we have a
relevant current implementation. Would rather not drop it.
Florian: Fact that Edge/IE have this feature and want to continue
having it, I think we should keep it.
Florian: If they want to drop it, then we should of course drop it.
fantasai: So proposed resolution: keep invert unless Edge decides
to drop, in which case we drop
RESOLVED: Keep outline-color: invert unless Edge decides to drop,
in which case we drop.
Rossen: Going back to the agenda, we have 10 minutes left
* fantasai would like to get first-baseline last-baseline sorted,
is blocking css-align atm
CSS Text Decoration
-------------------
fantasai: With regards to text-underline thickness/position, has
to be separate property from the existing -position
property, because that one is language-dependent and
intended to inherit through independently from other
properties.
fantasai: Probably want an -offset property for position control.
<bobbytung> -offset +1
[Meeting adjourned]
Received on Wednesday, 16 November 2016 02:29:26 UTC