- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Oct 2014 16:41:53 -0400
- To: www-style@w3.org
Motion Path
-----------
- Krit presented his proposed solution for motion path which
contains three long-hand properties; 'motion-path', 'motion-
position' and 'motion-rotation' and their shorthand, 'motion'.
- The group received the proposal positively, but had several
potential issues that will need to be addressed. They
included:
- Calculating angle based on position
- Property name confusion
- Having to define motion-path multiple times
- Interaction between transforms and motion
- RESOLVED: Make this an official editors draft with krit, shane,
and TabAtkins as editors
- The entire group was given an action to read, review, send
comments about what you would like changed or noted or marked
as an issue for FPWD
See editor's draft at http://dev.w3.org/fxtf/motion-1/
Issues in Media Queries 4
-------------------------
- RESOLVED: No change: aspect ratios remain integers
- RESOLVED: Deprecate device-* media features. Keep behavior, but
authors "must not use"
- RESOLVED: 'resolution' MQ uses the vertical resolution when
pixels are not square.
- There was significant debate on the best way to handle high-
contrast and color-inverted styling with several different
approaches raised and discussed to maximize usability, but
also encourage a11y-friendly code.
- RESOLVED: Add color-inverted media feature with values 'none'
and 'inverted'
- RESOLVED: We will add one or more high-contrast related media
features.
- RESOLVED: we won't distinguish between "UA doesn't support
scripting" and "scripting is supported but turned off"
- RESOLVED: close issue 12 wrt View Mode spec as no change
===== FULL MINUTES BELOW ======
Scribe: fantasai
Motion path
-----------
<krit> http://dirkschulze.github.io/specs/motion-1/
krit: Would like to present a solution for motion path.
krit: I'm not asking for resolution or anything; I just want to
present it.
krit: This proposal is about specifying a path along which object
moves or transforms.
krit: SVG wants all kinds of animation things. This was also
requested to have on HTML elements.
krit: For this proposal I created 3 different longhand properties
[krit shows an example of airplane along an S-curved path.]
[plane turns to stay facing forward along path]
krit: You could use the motion-path property, which takes
<basic-shape> | path() | <url> pointing to SVG
krit: Motion-position defines the position along the path
krit: motion-position: <length> | <percentage>
krit: Rotation can animate along the path
krit: motion-rotation: [auto | reverse] && <angle>
krit: ...
krit: Shane proposed to have a motion() function, which is a CSS
transform function.
krit: It can be used together with other transform functions (like
rotate, translate, etc)
krit: Syntax would be same as motion shorthand property.
krit: All I want to do for now is present this proposal and ask
you to look at it for the next F2F.
astearns: Motion-position, takes any length, e.g. ems?
krit: yes
fantasai: What if it's too long?
krit: There are definitely issues to discuss, it needs more
proposals.
gregwhitworth: Position is only the beginning and end right?
gregwhitworth: You might want to snap to various places.
TabAtkins: Or use another transform to shift the plane around.
gregwhitworth: You might want to pivot around a corner.
krit: You can apply motion-rotation and transform together.
TabAtkins: motion() does some magic combination of translate and
rotate.
glazou: I tried to make planets with moons on this.
glazou: It's missing one thing to do that... calculating angle
based on position
<shans> If you use the motion function as part of a transform
specification then you can do that
Bert: A bit confusing that this property doesn't actually create
motion, need to animate it.
Clilley: Good to call it motion-path because a) that's what SVG
calls it and b) it's a path along which the thing is
intended to move.
Bert: Yes, but if you don't combine with animation, then it's just
equivalent to translate
Bert: It's a nice way to define a translation,
Bert: But nothing moves.
Bert: Maybe if SVG calls it that, then I'm okay. But I found it
confusing because the motion comes from somewhere else
fantasai: Well, you can propose new names if you have a good
suggestion.
glazou: This is 2D only?
krit: At the moment, yes. Could expand to 3D.
shans: Dino brought up a point on the mailing list that you need
to specify the motion-path multiple times.
shans: Can we get around that somehow?
TabAtkins: Could have a null path value and it assumes the same
path.
shans: Would we run into trouble later if we ever want null path
to mean an empty path?
fantasai: Just put a zero-length path.
Clilley: That's not quite the same.
Clilley: Zero-length path does give you an orientation and does
have a coordinate system, even if it's just a point. So
it affects rotation
Clilley: But you definitely want to avoid repeating the path spec.
TabAtkins: You need to have some kind of default value for motion
to fill in for transform animations.
shans: Could maybe have motion() and motion-position()?
krit: Could say that if you don't specify a path in motion(), take
it from the motion-path property.
<TabAtkins> motion(auto 20% 10deg)
krit: But we can discuss later if there's interest.
fantasai: So, seems like everyone likes this proposal and wants us
to work on it. Any objections to making an ED?
[general agreement]
TabAtkins: This can also make the Web Animations spec smaller
glazou: When you define a motion-path, and you query computed
value of transforms. Does it reflect the motion?
TabAtkins: Yes.
TabAtkins: It's just translate+rotate.
TabAtkins: That gets reflected in matrix the same way.
shans: But not exactly the same, because you can't animate from
that to a translation
TabAtkins: The Web Animations spec already has a specialized
construct for this precise use-case.
krit: So if anyone has concerns about the proposal, please post.
glazou: What happens if you have both transform and motion?
krit: Proposal currently says that motion is pre-multiplied by the
transform.
krit: So you apply the motion path, then you apply the transform.
krit: Like writing, writing the transform functions over the other
transform functions
dbaron: Is pre-multiplication going to give you transform of the
thing or transform of the path?
dbaron: One of the multiplications will rotate the thing and then
move it along the path,
dbaron: Other will rotate the path and then move along that.
[unminuted confusion]
TabAtkins: ... ... So it will rotate the thing rather than the
path.
dbaron: If I did {motion: foo; translate: 50px; }, does it move it
50px and then do the motion stuff, or do the motion and
then translate it in whatever direction the element is now
pointing?
TabAtkins: The second one. If you want the first, use
transform:translate(...) motion(...); explicitly.
shans: Transform property happens after the path.
shans: Wherever the element ends up on the path, it gets
transformed there.
RESOLVED: Make this an official editors draft
fantasai: Action on the WG to read, review, send comments about
what you would like changed or noted or marked as an
issue for FPWD
krit: Editors will be krit, shane, Tab
Media Queries 4
---------------
<florian> http://dev.w3.org/csswg/mediaqueries4/
florian: Values and Units don't define ratios, so MQ does.
florian: It's used for aspect ratios and defined as
integer/integer
florian: There are reports of people writing non-integers in the
wild such as: 1.5/1
TabAtkins: I've seen arbitrary ones with weird numbers.
<Clilley> 1.77777777777777778 : 1 ( == 16:9)
florian: I feel it's not worth defining this.
florian: Do we want to allow non-integers?
Clilley: It's only a problem with squares;
Clilley: If you do something almost square, you can do the usual
epsilon thing to compare floating point numbers.
florian: Do we want to define floating point equality, or is it
not worth the bother?
florian: If nobody cares let's do the easy one.
RESOLVED: No change: aspect ratios remain integers
florian: (min/max)-device-(width/height) is the size of the
screen, not browsers. It's not useful. Deprecate it?
Clilley: (explains how sites use it wrong)
florian: It's also used to detect iphones.
zcorpan: Can we change the semantics to be equivalent to (min/max)-
(width/height)?
dbaron: It's also fun on mobile, browsers use different ideas of
viewport.
<dbaron> viewport stuff: http://vimeo.com/channels/cssday/100523275
Clilley: That's sounds reasonable. If the spec documents that
these approaches are fragile, explaining why.
florian: So far, sites use the very few media features available.
If you're 320px wide, you probably have touch.
RESOLVED: Deprecate device-* media features. Keep behavior, but
authors "must not use"
Bert: so are we continuing to support it?
Clilley: Yes, supporting it forever but not recommended to use it,
that's what deprecated means
<Clilley> yes, that is what deprecation means
Glenn: "should not use"?
TabAtkins: We can use "must" for author conformance, it's fine.
* glazou2 it's recommended that web authors don't use...
plinss: It's really should not.
TabAtkins: Resolution MQ has interesting handling of non-square
pixels.
TabAtkins: The exact value never matches non-square. Min/Max do,
but they behave differently.
TabAtkins: We have to decide what the <= syntax does
TabAtkins: We define min/max by saying they're equivalent to <= or
>=, but that doesn't tell us how to handle this:
<TabAtkins> (resolution < 4/3) {...} (resolution >= 4/3) { ... }
<TabAtkins> resolution < 2x and resolution >= 2x
florian: It does, but [example] doesn't cover the whole range.
TabAtkins: I'd prefer to have <= >= work sanely, to be consistent.
TabAtkins: Then we might as well say that exact resolution works
with non-square.
plinss: What behavior, use the smaller? larger?
TabAtkins: Pick one.
TabAtkins: Do we have non-rectangular pixels in practice?
Glenn: All the time [televisions for instance].
dbaron: Do browsers do this per spec?
TabAtkins: That's a good question.
dbaron: Gecko does not. We have a single number.
Rossen: We used to support non-square, and deprecated it. No one
complained that we know of.
florian: Most likely, the browser engine doesn't know.
TabAtkins: So, proposal: work on some undefined number in the
range.
dbaron: On windows/linux, Gecko uses the vertical resolution.
Rossen: We do the same.
zcorpan: In CSSOM View, device px ratio uses the smaller.
dbaron: On Mac, we call the system API which gives a single number.
TabAtkins: Would people be okay with just using the vertical
resolution?
SimonSapin: Do we know what the Mac system API does?
hober: *shrugs* Returns a number.
florian: That's better than different behavior in min- and max-.
hober: I wanna check compatibility-wise,
dbaron: I no idea if other browsers are consistent.
florian: "Should use vertical if you have both, whatever if you
can't" ?
TabAtkins: If somebody can't do it, they'll tell us.
dbaron: I'm checking if the resolution from the OS actually
influences the MQ at all
florian: We care about CSS px, not device pixels
dbaron: ... it's not actually relevant
florian: This only happens if you're putting a different number of
device pixels per CSS pixel vertically vs. horizontally
TabAtkins: Proposed: use the vertical resolution
RESOLVED: 'resolution' MQ uses the vertical resolution when pixels
are not square.
florian: Next issue, we might want a separate MQ for the kind of
resolution printing cares about.
florian: Nobody really asked for it.
florian: Issue 5: overflow-block, overflow-inline. On screen, you
get scrollbars. In print, next page. You might want
different behavior in each direction
florian: Issue 6 is naming for these properties
florian: Issue 2 is, spec says "when things overflow the
viewport", but viewport is not the right term. What is
the right term?
plinss: If you change writing mode, you change what is inline or
block, but not your paper.
florian: It still helps for mostly-vertical documents.
plinss: I'm not sure it's rational to use logical terms rather
than physical.
TabAtkins: Yes, that's the issue, we're not sure.
plinss: At MQ time, do we ever know which is which?
TabAtkins: That's a question: should we have MQ for "main writing
mode"?
TabAtkins: User preference is for display layout.
florian: If no UA can switch mode initially, yes.
plinss: If I switch printer to landscape...
florian: You change the ratio, but keep directions.
dbaron: Is there a way for author to know what the default
direction is?
TabAtkins: There might be a way to expose it in MQs.
TabAtkins: ereaders exist in the Japanese market that let you swap
between vertical and horizontal text.
florian: We want to stop people querying for print when they want
to query for pages.
florian: Right now the two properties that take different values:
-inline only takes none or scroll. -block also has page.
Can't do that with physical... or maybe we can.
plinss: Odd pages on the right, even pages on the left, in 2-page
spreads.
plinss: [...] it's complicated.
TabAtkins: Too complicated to be distilled into the common case
for something like this?
florian: If you overflow in the block direction, go to the next
page.
plinss: In a spread, if something overflows in the inline
directions, theoretically it should overflow into the next
page.
plinss: It's commonly done with images overflowing over a two-page
spread.
TabAtkins: [...] special-case spreads.
TabAtkins: We can probably leave it out for now, it needs input.
But it works within this paradigm.
plinss: Every other page can overflow in every other direction.
dauwhe: You can't really define spreads in CSS right now.
plinss: Yes, but we should.
TabAtkins: There's still a main overflow direction, and the other
where you shouldn't overflow.
TabAtkins: It's not used, it's always left and down.
Bert: This is before the page has any content, talking about
device here.
florian: But you expect things in a given direction.
Bert: I have to mentally translate from block/inline.
TabAtkins: You already have to do that anyway.
plinss: We also have physical properties.
TabAtkins: These are legacy.
plinss: But this is about physical characteristics of the device,
I'm not sure of the value of making these logical.
florian: The interaction between physical device and what you lay
out on it.
florian: It's tricky. I guess we don't have a resolution?
TabAtkins: Not yet.
florian: Okay, issue 2.
florian: The thing being overflowed is not the viewport, so what
is it?
hober: Initial containing block?
TabAtkins: Yeah, probably.
Clilley: Current containing block? I want the current page, not
the first page.
TabAtkins: ICB changes per page.
SimonSapin: Does it really? css3-page says not
plinss: That's a bug.
SimonSapin: We discussed it, but haven't updated the spec.
TabAtkins: Not sure how that works, then.
TabAtkins: Action on me and Simon to check what css-page says, and
what it should.
SimonSapin: It's complicated because viewport units.
<fantasai> No, the ICB does not change per page.
<fantasai> If you abspos a thing, it always goes to the first page.
florian: Issue 7. Light-level MQ, to tweak contrast. But E-ink
would not.
florian: There is a Microsoft MQ for high contrast. It's a a11y
feature when users forces it.
florian: It's not identical to our MQ, but very related.
florian: In addition, there is an inverted mode.
florian: I'm suggesting to add one value to the existing media
feature, and add one with three values.
florian: The extra value to light-level is activated when browser
forces you into high contrast. It ignores your CSS or
tweaks it. You react to it.
hober: What's it called?
florian: Microsoft has a prefixed media feature. When it puts you
in high contrast mode, it let's you know.
plinss: You can't override, but you can adapt.
<hober> There's also one in Indie UI
<hober> http://www.w3.org/TR/indie-ui-context/#user-contrast
hober: [link above] is more general than the MSFT proposal.
hober: You could translate -ms-high-constrast to -1 .. 0 .. +1
hober: The negative number represents lower than average contrast
TabAtkins: I really don't like this design.
<hober> Indie UI also has a color inversion bit:
<hober> http://www.w3.org/TR/indie-ui-context/#colors-inverted
florian: Finishing this proposal: new media feature inversion has
3 values: none, requested and enforced.
florian: None is as usual. Requested: nothing has happened, but
you should invert yourself. Enforced: you have been
inverted but might want to double invert some images.
TabAtkins: Shouldn't work quite that way [...]
TabAtkins: It might be useful to add high-contrast to light-level,
and add the MSFT proposal that tells you what you're in.
TabAtkins: If the high contrast MF is set but light-level: high-
contrast is false, you are requested but not forced.
florian: You develop on a device that can force you but not just
request. You invert images. On another device that asks
you, you just invert images.
TabAtkins: Inverting is stupid. It's just a cheap way to do white
on black text.
florian: The MSFT value says you *have been* inverted... the
document is not clear. But another property lets you
disable it, suggesting it's done to you.
florian: That's my proposal: 2 axises
hober: On the Contrast case, OS X has a continuous contrast
adjuster.
TabAtkins: Light level uses keywords to split into significant
buckets. You're not gonna do a whole range of
variation, but I don't know what values mean.
hober: You typically pick a threshold.
TabAtkins: What threshold? Keywords pick for you.
TabAtkins: Inverting is weird, you'd want to respond specifically.
TabAtkins: On android, it literally inverts pixels. It often gives
you white and black, but not always, and makes you
images look stupid
TabAtkins: Windows adjusts your CSS to match the desired scheme.
fantasai: Why can't browsers do intelligent things?
TabAtkins: The android a11y level is low level.
fantasai: Browsers can still un-invert images by itself.
hober, florian: It's unclear what should be inverted, not, or
removed. (e.g. shadows).
florian: It could be in user stylesheet: please invert my things.
fantasai: Rather, please use white text on a black background?
hober: The user preference is about a color scheme, but system-
level it's not.
* sgalineau recalls the -ms queries were about customizing the
design when high-level contrast is on e.g. preserve or
remove backgrounds, shadows etc. back then printing
disabled backgrounds by default but not high-contrast.
florian: Proposal: Add a value to light-level: you have been put
in high contrast. And add a new media feature: you have
been inverted, you may want to adapt
fantasai: Having light-level should stay about light level. You
can have another thing for high contrast/inversions/etc
plinss: Call it accessibility.
florian: We might or might not want to merge with printer wants to
save ink.
TabAtkins: That's requested too.
hober: As far as having high contrast keyword vs values, the
author will pick a threshold. I'm worried about apps with a
web view where the rest of the app reacts continuously, but
web view can't.
TabAtkins: Sensors are terribly calibrated. If you want fine-
grained control, do it in JS, there's an API.
fantasai: You could have keywords *and* numeric value?
florian: One media feature with all the things done to you?
hober: They're independent.
fantasai: Although inverted *and* saving ink doesn't really work.
fantasai: Typically you remove background, and increase contrast
of text.
fantasai: There's a MQ for that.
hober: Greyscale?
<fantasai> hober, return 0 for http://www.w3.org/TR/css3-mediaqueries/#color
plinss: iOS a11y settings has three settings for contrast [...]
everybody does it differently.
<Bert> -> http://www.w3.org/TR/indie-ui-context/#colors-inverted
indie-ui colors-inverted
TabAtkins: Possibly don't adjust light-level, but pull the indie
UI color inversion thing and the MSFT one?
hober: Both keywords and numeric?
florian: Drop the active value and pull in the rest of MSFT
proposal.
TabAtkins: I think active was because none didn't used to be falsy.
florian: We've used 0 and 1 for booleans
TabAtkins: That was dumb
florian: The prefixed version can keep 'active'.
florian: Should we include printer saving ink?
fantasai: Yes, it's very similar.
<florian> Proposal 1: pull in high-contrast from
http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx
without the active value
<florian> Proposal 2: add "inverted" with values "none" and
"inverted".
<florian> Proposal 3: as ink-saving, with none and economy
TabAtkins: The color-adjust property takes 'economy' and 'exact'.
Take that as a media feature.
TabAtkins: We also want a 'none' value for no adjustment.
plinss: Property vs. media query?
TabAtkins: You want to say don't do this (property) or adapt when
it's done (MQ)
fantasai: Economy is default. Author can override to exact, and
users can override again to force economy.
TabAtkins: Color adjusting is not just a print thing.
fantasai: It doesn't matter on e-ink, right? Maybe on something
white is more expansive.
TabAtkins: We want to get rid of the print media type.
fantasai: "Don't use too much black" is different from "you don't
get backgrounds"
TabAtkins: Yes, you can want not to override adjustment, but still
react to it.
fantasai: This media feature doesn't tell me that I'm printing.
dbaron: There's a trade off; you're asking the authors to make
fine-grained decisions that they probably don't care about.
Making stylesheets for situations they're never gonna test
<fantasai> dbaron++
dbaron: You have to split it up at levels authors will care about.
fantasai: If we have the color-adjust property, authors who care
will set it to exact and do the right thing.
plinss: Color adjust will prevent the browser to remove
backgrounds as well?
TabAtkins: Yes.
florian: Proposal 3 above is rejected?
TabAtkins: Correct.
TabAtkins: Proposals 1 and 2 look like they have consensus.
hober: I'd like to phrase 1 differently
hober: Keywords vs numerical value vs both.
TabAtkins: That's independent.
hober: I disagree.
<fantasai> color-adjusted: none | light-high-contrast | dark-high-
contrast | inverted
<fantasai> color-preference: none | light-on-dark | dark-on-light
<fantasai> color-adjusted: none | [ light-high-contrast | dark-high
-contrast ] || inverted
<hober> colors-inverted: none | inverted
<hober> @media (colors-inverted)
florian: Do we also include inversion in that media feature?
florian: Do we want an inverted high contrast dumb variant?
fantasai: High contrast gets rid of the grays.
TabAtkins: Then maybe we want inversion separate.
TabAtkins: You can still test for inversion alone in a multi-value
media feature.
fantasai: In MSFT high-contrast, is everything forced to white and
black?
gregwhitworth: No, it's light and dark.
gregwhitworth: You can have colored high-contrast.
TabAtkins: We still want inversion an additional separate MQ, for
the boolean context to be useful
fantasai: In that case, split it out even more.
<fantasai> high-contrast: white-on-black | black-on-white | none
florian: The original reason to bundle this with light level is
that light level can be faked for a11y.
florian: We intentionally bundle a11y things with non-a11y, so
they get used.
hober: There's a tradeoff between one n-dimensional MQ, and a
bunch of booleans
fantasai: Responding to light and responding to "I want white and
black / black on white" is similar
<astearns> add "inverted" with values "none" and "inverted"
<astearns> pull in high-contrast from
http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx,
without the active value, adding the boosted value?
<sgalineau> color-inverted: inverted looks like a double negative
hober: (responding to sgalineau) doesn't matter, in practice you
use it as a boolean.
RESOLVED: Add color-inverted media feature with values 'none' and
'inverted'
<fantasai> It should probably be color-inverted: none | all |
luminance | hue
<fantasai> or something
<fantasai> color-inverted: none | luminance || hue
florian: Next: pull in media contrast media feature from MSFT,
remove 'active', and add 'boosted' which is pixel level
rather than CSS level
* liam hopes there is also a low-contrast mode supported in there
somewhere.
fantasai: Do we need low contrast?
florian: Does it exist in any OS?
plinss: It's possible to lower.
<liam> Yes, gnome supports it, across platforms.
<fantasai> color-contrast: normal | high | low
<liam> Both high and low contrast "themes" are supplied, for
accessibility reasons
<hober> http://www.w3.org/TR/indie-ui-context/#media-feature-user-contrast
<fantasai> color-contrast: <number>
hober: Indie UI is -1 to 1, I assume they have good reasons. I
also think it belongs in CSS
hober: Three things: system inversion, system contrast, and user
preferences
fantasai: Forced inversion might be combined with a forced [...]
RESOLVED: We will add one or more high-contrast related media
features.
florian: Issue 8: We have a media feature do detect if scripting
is disabled,
florian: Should we differentiate between scripting not supported,
or disabled by the user?
(several): no.
RESOLVED: we won't distinguish between "UA doesn't support
scripting" and "scripting is supported but turned off"
florian: We're trying to break apart media types into media
feature, it would be good to do so with input (mouse,
touch, ...)
florian: We need more things.
<plinss> http://www.w3.org/TR/view-mode/
florian: Issue 12: There's a spec called View Mode, in REC. It has
media features to detect full screen, borderless window,
etc. It was written for widgets, ignored for a while, but
could be relevant to browser-based OSes
Clilley: Is it ignored because nobody likes widgets?
plinss: We looked at it, it was controversial...
florian: It seems relevant. Do we let it die and develop something
new? Or pull it into MQs?
plh: Marcos also has things.
<plh> http://w3c.github.io/manifest/#display-member
zcorpan: There's a pseudo-class for Fullscreen.
florian: View Mode semantics are a bit richer.
<zcorpan> http://fullscreen.spec.whatwg.org/#:fullscreen-pseudo-class
<plh> http://w3c.github.io/manifest/#display-modes
RESOLVED: close issue 12 wrt View Mode spec as no change
plinss: we're done for the day
Received on Monday, 13 October 2014 20:42:22 UTC