- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 21:28:09 -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 Linked Animations
------------------------
- birtles introduced the two existing proposals and some issues
that they have uncovered in trying to create these proposals.
- RESOLVED: Accept this scroll linked animation work, to be done
under the WICG
Writing Modes Level 3 Test Status
---------------------------------
- Koji reported that of the 995 tests there are 13 that are
blocking the move to PR.
- The tests on text orientation upright property have no
implementations passing and fantasai was actioned to look into
these tests more as she believes we need to pass these tests
before progressing.
- Koji will begin preparing a new DoC listing reasons why at-risk
features are removed and any responding to any feedback
received since the last publication.
Scroll Anchoring
----------------
- ojan introduced the work being done in WICG to allow for scroll
anchoring which addresses the common use case of content being
added (such as an add) which pushes down existing content and
effects scrolling.
Media Feature: “reduce motion” user setting
-------------------------------------------
- jcraig requested the addition of a "reduce motion" user setting
for accessibility.
- There was interest in adding this feature, but disagreement as
to if work should happen on just this item or on a complete
grouping of accessibility-related user settings such as
monochrome and reduced transparency.
- The group ran out of time on this topic before concluding on
exactly how to proceed.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda
Scroll Linked Animations
========================
Scribe: dino
birtles: Dean sent a proposal years ago, but it wasn't complete.
Google and Mozilla have come up with separate new
proposals
birtles: I'll give a 1 minute demo, and list a few issues.
<dino> Mozilla's proposal - https://birtles.github.io/scroll-animations/
<dino> Google's proposal - https://github.com/drufball/generalized-animations
[birtles shows a custom build of Firefox with some scroll-linked
demos]
myles: Is there any script in this demo?
birtles: Yes, it's a mix of both. Declarative for easy stuff,
script takes over after a while.
[birtles shows a demo with a mix of scroll-based and time-based
animations. switching between the two.]
birtles: We've found three issues:
birtles: 1. Transitions
birtles: In many cases you want to represent behavior with
transitions not animations. e.g. if you want something to
appear, you need two animations for in and out.
Transitions is just a state change. In other cases an
animation is fine, since it is a run-once situation.
birtles: It was a surprise to us that transitions were the most
natural way to author many of these effects. This makes
the animation-trigger feature less useful.
birtles: We have drafted something called @trigger that can be
used to change style based on scroll position.
birtles: So issue 1 is do we need an @ rule or something.
<birtles> http://www.nytimes.com/projects/2013/tomato-can-blues/?hp
<birtles> http://cuberto.com/
birtles: 2. Layout cycles
birtles: Once you have the idea of triggers that can affect
layout, you can possibly have a cycle.
birtles: We have some vague wording in the proposal about freezing
the scroll offset for the frame.
birtles: This avoids a cycle within a frame, but you can still
have flip-flop animations.
dino: Transitions already has this issue.
birtles: 3. Describing the scroll points for triggering animations
birtles: Maybe we can use the scroll snap points syntax, but I
don't know how to do it.
Rossen: You mean scroll-snap events?
birtles: No, about linking a scroll point to an element.
[birtles describes how he wants something to happen based on the
position of an element]
fantasai: Scroll snapping lets you specify where a scroll for an
element will be, but does not let you reference that
from another rule.
fantasai: Have a new property that is "when the scroll snaps at my
scroll point, then something happens"
Rossen: Thanks for this introduction, we've been waiting for this
for a long time.
shane: We need to work out what we are going to do.
shane: I suggest a small group of people in an incubator.
Rossen: Unlike fonts, this seems like a good example of something
that could go to WICG and come back when it is more mature.
Rossen: Please, if you want to participate on this topic, do so!
astearns: It doesn't need to be a small group. It should include
the type of people who are solving this problems with
scripts.
astearns: Make it as wide as possible.
RESOLVED: Accept this scroll linked animation work, to be done
under the WICG
Writing Modes Level 3 Test Status
=================================
koji: The test status is linked from the agenda
<Rossen> http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html
<ChrisL> There are 995 tests in the test suite, 118 of that have
only 1 or less implementations.
koji: There are 995 tests in the suite. 118 tests do not have 2
passing implementations.
koji: I've categorized them.
koji: Most of the 118 are related to this group. Only about 28 are
not.
koji: The suite depends on 5 other specs. I excluded them from the
28. Then if I remove the MAY or SHOULD tests.... (form
controls, etc)
koji: This leaves 13 tests that are blocking our exit.
koji: Of those 13, four categories...
koji: 1. synthesized baseline
<fantasai> of atomic inlines in vertical-lr
koji: 2. text orientation upright property
koji: affects the used value of direction
koji: there are 0 passing implementations
koji: 3. absolute positions
koji: There are ~250 tests in this group, and 3 of them don't have
2 implementations
koji: 4. Glyph composition
koji: edge case - text combine has a newline character, there is
only one passing implementation
koji: These all seem minor to me, and we've made a lot of
progress, I propose that we allow these failures and move to
PR.
ChrisL: We could make the case that 13 failures is ok.
fantasai: For number 2, were you testing the used or computed
value?
fantasai: So upright text is in the wrong order?
astearns: Could fantasai take a look at those 13 failures?
ACTION fantasai to take a look at the 13 failing Writing Mode tests
<trackbot> Created ACTION-794
astearns: Have you filed browser bugs on these failures?
koji: Some of them, but since authors have not complained, I don't
think they are real world issues.
Rossen: You should still file the bugs.
jet: We do have Gecko bugs for all these! I see that browsers only
have at most 80% complete coverage. Is that enough?
astearns: The criteria is that each test has 2 passing
implementations, not that there is interoperability
between all tests.
ACTION koji to file these writing mode test failures on the browsers
<trackbot> Created ACTION-795
<dbaron> FWIW, when I started looking through the Gecko failures,
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1244601
(which accounted for quite a few) but then didn't get
further on filing additional bugs
Florian: I've informally looked at changing writing mode on table
cells and got weird results. Have we tested this enough?
koji: Yes.
<fantasai> I think category 4 failing test is a weird edge case,
don't need to worry so much.
<fantasai> I don't think that's the case for #2. Those should be
fixed.
Rossen: ChrisL, can we go to PR in this state?
ChrisL: We are dropping all the at-risk features?
astearns: Yes.
ChrisL: We need to write up a clear rationale for us progressing.
e.g. we've filed bugs, they are not show stoppers, etc.
Florian: Especially for the features that are at-risk, we've
already got a +1 spec ready.
ChrisL: That doesn't matter.
koji: Do you have an example of such a document?
ChrisL: An email to the group is enough.
astearns: Informed by fantasai's review.
fantasai: The category 2 failures need to be fixed.
fantasai: That's right to left upright.
koji: This is uncommon.
fantasai: More common in hebrew than arabic.
Rossen: Any objections to the at-risk features?
fantasai: I think there are blocking tests. I don't think #2 are
an edge case.
astearns: Does it help to wait for the tests to pass?
astearns: Why not move to a new draft now?
fantasai: I would prefer to wait. Implementations might be doing
the work now.
astearns: Look at the test failures, see if we can address
category #2, cut down the draft to features that have
passing tests.
astearns: What else is necessary?
ChrisL: For any comments we received since we last transitioned,
we need to show that we handled them. i.e. we need a new
DoC
ChrisL: It's fine to have the DoC say that it will be address in
the new version.
[clarification on what the transition process is]
fantasai: From the list of 13 tests, if we have implementors who
will fix a few bugs, we should be able to transition.
ACTION koji to prepare DoC for writing modes transition
<trackbot> Created ACTION-796
Scroll Anchoring
================
scribe: ChrisL
<ojan> https://github.com/WICG/interventions/blob/master/scroll-anchoring/explainer.md
ojan: Doing this in WICG at interventions github
ojan: Mitigate common experience of an ad loading and pushing
content down. Adjusts scroll position
ojan: during layout, store scroll position, adjust it back if it
changed.
ojan: Anchor deepest element at top of page. Restore to position
after layout
ojan: as if user scroll, but browser scrolled.
ojan: Lots of webcompat issues, ugly heuristics
ojan: like poorly done sticky headers that jump.
ojan: Walk ancestor chain and any ancestor that modifies layout we
don't do scrolling.
ojan: They animate padding on body which works poorly, gives
scroll loops.
ojan: We want to add a css property to control this.
ojan: On by default, opt-out to current behavior, or opt in for no
heuristics.
ojan: Move to wicg in next 2 weeks.
ojan: Ignore fixed position elements.
ojan: Should we do that for abspos as well.
frremy: Can you get intervention when only specific things happen?
fantasai: Are you aware it is affected by align-content property?
<fantasai> https://drafts.csswg.org/css-align/#overflow-scroll-position
Rossen: MaRakow is not on call yet.
Media Feature: “reduce motion” user setting
===========================================
jcraig: Exposing user prefs through css media features.
jcraig: Macros has this;
jcraig: flying animations that fly out,
jcraig: spinning starfield. chrome example. zooming (demonstrates
pages)
jcraig: Make people ill, painful, vomit etc.
jcraig: This is called "reduce motion". Want to expose to web.
jcraig: prefers-reduced-motion.
jcraig: We asked 3 years ago.
jcraig: What do people feel about exposing these. Fingerprinting
obviously, outweighed by accessibility benefits.
jcraig: Other ones are harder to do - contrast settings vary by
platform.
jcraig: Reduce transparency settings.
jcraig: (demonstrates a carousel)
jcraig: Allows page authors to decide how to handle it.
Rossen: Thanks.
gregwhitworth: What about platforms with no motion control. Return
true always?
jcraig: They will be asking support for it.
jcraig: May be a way to do with extensions or custom MQ short term.
jcraig: Prefer to avoid prefixing.
dino: Trivial to implement, huge benefits.
bkardell: Discussion earlier was user preferences, that we need to
invent new ways to set independent of OS.
bkardell: Talking in cognitive accessibility taskforce.
jcraig: dpub ig does not want to allow this (?)
jcraig: We have had shipping settings for years while their
taxonomy is thousands of possibilities.
bkardell: Do they overlap
jcraig: Maybe.
Florian: Useful to many, easy, should do.
Florian: Seems to be in a broader category of similar things.
Florian: Color contrast somewhere in between.
Florian: Not clear how to expose to web platform.
Florian: I'd like to notice patterns before we settle on it.
jcraig: Did a high contrast text setting for example. Microsoft
can flip foreground/background. Android have text contrast
enhancement.
jcraig: Others related to contrast, reduce transparency to boost
contrast.
Florian: Whole area of inserted, boosted contrast etc. clear to do
something but not what.
Florian: Expressing a user pref, kind of tempted to put in the
same group. But maybe just do that one.
esprehn: Like to see spec clarified first. monochrome, safari
connects to accessibility setting, we connect to display
driver
esprehn: no-one on a mac has one.
esprehn: Purpose of the mq was not clear.
esprehn: Need to be clearer why it is.
<fantasai> esprehn, I think that wasn't originally its purpose,
but it has been effectively repurposed :)
TabAtkins: Happy to put notes in, in general it is the output
device.
esprehn: Too vague.
fantasai: It was originally for monochrome monitors, got
re-purposed.
* fantasai doesn't think the original editors thought about a
monochrome mode on a color monitor.
jcraig: Toggled red square green circle for colorblind.
Considering collapsing that feature.
esprehn: If it is tied to the accessibility setting say so and
then we know.
fantasai: I'm agreeing with Florian. In context of related stuff.
Want to see all the requests you have had, in a draft,
figure out patterns.
Florian: It is tied to accessibility so privacy.
Rossen: That was already mentioned.
Florian: Suggested earlier that when a page has that from js, user
gets a permission notification.
jcraig: Screen reader directly exposes a disability. This is some
benefit but used by many more people.
<Rossen> [FYI: we're closing on this topic]
jcraig: Next steps?
dino: Listing all queries is ok but OS already has categories. No
need to discuss them again.
Florian: Different ones have different lists.
dino: Reduce motion is unfuzz, easy to do. Go ahead with that.
hober: Let's not let perfect be enemy of good.
dino: Some are fuzzy, changed between releases.
Florian: One on me to update draft.
astearns: I'd rather start with this one.
astearns: asap
fantasai: It's easier when we have all of them to look at.. this
is brainstorming.
astearns: Brainstorming should not go in draft.
astearns: We have a process. Put in the things we are definite,
add a note about vague stuff.
fantasai: We don't limit ourselves in early drafts.
Florian: At least this one and reduced transparency.
hober: Editorial effort, if editors want to do that then great.
Rossen: We're out of time.
Received on Wednesday, 16 November 2016 02:29:12 UTC