W3C home > Mailing lists > Public > www-style@w3.org > October 2014

[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-08 Part III: Motion Path, Issues in Media Queries 4

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Oct 2014 16:41:53 -0400
Message-ID: <CADhPm3uELExMN4=gJesaOZbohKkpxEV-VU73QrzFjbBR7whrZA@mail.gmail.com>
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
        - 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
  - 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


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

  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

  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

  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
  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
  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
  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
  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
  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)-
  dbaron: It's also fun on mobile, browsers use different ideas of
  <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
  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
  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
  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
  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
  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
  plinss: In a spread, if something overflows in the inline
          directions, theoretically it should overflow into the next
  plinss: It's commonly done with images overflowing over a two-page
  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
  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
  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
            without the active value
  <florian> Proposal 2: add "inverted" with values "none" and
  <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
  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
             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

  <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
  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
  fantasai: Forced inversion might be combined with a forced [...]

  RESOLVED: We will add one or more high-contrast related media

  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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:47 UTC