[CSSWG] Minutes Tokyo F2F Fri 2017-04-21 Part IV: F2Fs, Motion Path [css-motion]

   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.

F2F scheduling

   - Provisional idea is to coincide with TYPO conference, after the

Motion Path

   - The group originally resolved that offset-position offsets the
       shape when the offset-path is a geometry/shape, but as
       discussion continued it was decided that more time was needed
       to think about the topic.
       - shans wrote a summary of possible solutions:
   - RESOLVED: <size> argument of ray() is required.
   - RESOLVED: Name the "cast to the side you're pointing at" value
   - RESOLVED: Close issue #69 (offset-rotation should only do
               path-relative rotation- https://github.com/w3c/fxtf-drafts/issues/69)
               no change.
   - RESOLVED: #51 (offset-* property names collide with logical
               properties- https://github.com/w3c/fxtf-drafts/issues/51)
               won't cause motion-path to rename; the offset-*
               logical props will change name.

Focus of custom textbox-like elements

   -  RESOLVED: Come up with a property name for this focus-ring
                property, ratify in the CSS-a11y TF, put it in css-ui-4


Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics

Scribe: fantasai

F2F scheduling

   astearns: TYPO usually has Tues-Sunday scheduling.
   astearns: I suggest our 4-day meeting starts Monday.
   fantasai: Suggest people get a break on Monday.
   vlad: First two days are more tech heavy than the rest of the
   vlad: Could start with that, and then co-exist with the conference-
   vlad: have parallel events.
   astearns: So we could have our meetings Thurs-Sun as well.
   astearns: But then we're meeting on a weekend.
   vlad: Monday Houdini, break for TYPO labs, follow with CSSmeetings.
   iank: Hosting us where?
   vlad: Host will be Monotype.
   vlad: Traditionally in Berlin.
   Florian: I would prefer no gap between Houdini and the rest,
            because as Houdini stabilizes, might be possible to do
            Houdini as a breakout session in parallel with CSS.
   Rossen: That's a valid argument, bigger one for those who travel
           and don't plan to attend TYPO but do want to attend
           Houdini and CSS you have extra stay in the middle.
   Rossen: If you're sponsored, not too terrible, but out of pocket
           not so great.
   [dino agrees]
   Florian: Who has problems with weekends?
   [dino waves]
   vlad: Conference part is typographic, some interest to this group,
         but not so much overlap.
   vlad: labs part is technology, more of interest to this group.
   vlad: labs is Tues-Wed.
   Rossen: So we can either set up CSS meetings before that so we
           don't overlap
   Rossen: but we don't want to do like Friday through next week
           through Monday, probably.
   Rossen: But then people who want to do labs can stay, others can
           go home.
   Rossen: Pushing after all of TYPO, if you want to go to labs, what
           are you doing.
   Rossen: So I think we either schedule right before or right after
   Rossen: Either way would go through weekend.

   Rossen: Anyone have problem with weekend? glazou tended to have
           hard problem with it.
   plinss: It was mainly if we did TPAC plus a weekend, then it gets
           really long.
   astearns: My preference is after the labs, so we're there
             simultaneously in case there's something interesting at
             the conference.
   astearns: We could even have a joint session with the conference.
   vlad: Could have panel session, ppl interested in CSS technology.
   vlad: May be someone interested to present in the conference
   fantasai: Or we could have a developer meetup after-hours.
   astearns: Provisional idea is to coincide with conference, after
             the labs.
   astearns: Any concerns, speak up.

   [CSSWG has preference for earlier in April than later because of
       summer meeting and no winter meeting]
   [discussion of summer location]

Motion Path
   Scribe: TabAtkins

   shane: 4 issues I'd particularly like to discuss today; we can do
          the rest of the 16 if we have time.
   shane: The four I'd like to discuss are relevant to our impl plans.

No model for interaction of `offset-position` and shapes
   Github Topic: https://github.com/w3c/fxtf-drafts/issues/78

   shane: Interaction between <shape> for path, and offset-position
   shane: One suggestions is when using a <shape>, offset-position is
   shane: Other is to apply to offset-position as the initial offset.
   fantasai: Don't have a strong opinion, but if you can do something
             useful with it, that's nice.
   Florian: Any difficulty with that?
   fantasai: Various shapes have a start position as a possible
             param. So what does it mean if you have that?

   RESOLVED: offset-position offsets the shape when the offset-path
             is a geometry/shape.
   [resolution rescinded after further discussion, below]

   fantasai: So offset-position isn't an offset, it's a position. How
             do you turn it into an offset?
   fantasai: [elaboration on this]
   fantasai: Positioning syntax is a position wrt four sides of a
             box; it's not privileging the top left corner. Don't
             want to turn it into a description of an offset from the
             top left corner.
   fantasai: circle(... at <pos>) describes the center of the
             circle. offset-position is also a position. Adding
             them together is non-obvious.
   astearns: What if we let offset-position *replace* the shape's
             position, when defined?
   shane: Eh, that doesn't seem desirable.
   TabAtkins: So core if points and points don't add together.
   Florian: Unless you can turn them into a vector.

   Scribe: fantasai

   fantasai: What if you don't specify a position in the circle?
   TabAtkins: Falls back to center.
   fantasai: Why not use the offset-position?
   TabAtkins: ...
   shane: [revisits Alan's suggestion again]

   [mumbly discussion of whether the box keywords are useful here]
   fantasai: There's no use case afaict, adding them for completeness
             is excess implementation and testing work.
   TabAtkins: But consistency!
   [back to original topic]

   shane: Suggestion to have offset-position overrides position in
          the shape.
   Rossen: Why use a separate position property?
   fantasai: Because it's there.
   TabAtkins: What makes it special here, vs any other place that
              uses the shape functions?
   TabAtkins: If we want to make path() easier to use, should do that
   TabAtkins: It would be great to have coords in path via css box
              coordinates generally.
   shane: Feels wrong, not sure how to explain why I think this...
   TabAtkins: If I use offset-position to set the start coord, why
              not use it to set other coords?
   shane: I think in general for the use cases here, the path doesn't
          need to be shaped wrt the box, but often you want the start
          position to be wrt box.
   shane: Usually you want the path to be absolutely sized.
   TabAtkins: Sure, they're all useful.
   TabAtkins: box coords are a superset of abs coords.
   <ericwilligers> In Blink's shipped implementation, if people use
                   position absolute and set left/top, then path('m 0
                   0 ... ') starts from left/top.
   TabAtkins: I think it's just weird that in this one instance of
              the path function, doing something special is weird.
   TabAtkins: Create a CSS-friendly version of path syntax, that
              takes <position> with units and such.

   shane: Paths are hard to read and write.
   shane: You usually take it out of an authoring tool.
   shane: Paste it in... but then want to move the path around.
   TabAtkins: You alter the first to digits of the path...
   shane: But if you're building a site where you're taking data from
          somewhere else, don't want a manual fixup.
   fantasai: I think shane's got a good point.
   TabAtkins: But if you want to use path elsewhere in CSS, then this
              is a problem
   shane: What you're suggesting doesn't fix it for path(), but it's
          also useful and we should do both.
   * fantasai agrees with Shane
   TabAtkins: Could say that path() takes an "at <position>" after
              the path, just like other shapes do
   TabAtkins: Should go back to offset position only offsetting ray.
   shane: Then position should go into the ray function.
   TabAtkins: Just what I was about to say.

   fantasai: That's not the only thing offset-position does.
   fantasai: So offset-position is not only for setting the position
             of the ray(), it's for positioning a box using <position>
             syntax in the manner of background-position
             (which you can't do with abspos).
   TabAtkins: The purpose of offset-position is to give you a
              translate function that acts like a background
              position, so that 0% and 100% map to aligning to
              opposite edges of the container
   TabAtkins: That appears to be only necessary use of it here;
              shapes can just take an explicit position
   TabAtkins: So maybe have a different feature for this

   RESOLVED: Undo previous resolution, we're still thinking about this

   <TabAtkins> (In other words, we could just move *all* the
               positioning functionality into the offset-path
               functions - path("..." at <pos>), ray(... at <pos>).
               Then there's nothing left for offset-position to do
               *in this module*, so we can address the functionality
               it still has elsewhere.

   <ericwilligers> So is the view that offset-position is to only be
                   relevant for ray() and none, and not for path()
                   and basic-shape?
   <astearns> ericwilligers: we're not happy with that
   <ericwilligers> See Figure 11 in https://drafts.fxtf.org/motion-1/#offset-anchor-property
                   where offset-position and offset-anchor are useful
                   with offset-path none.
   <fantasai> ericwilligers, I think the proposal was to move
              <position> inside the ray() function and delete
              offset-position or add the none-based positioning
              feature to something else?
   <ericwilligers> Can we make the <size> non-optional?
   <astearns> topic: ericwilligers we'd still need to decide the
   <ericwilligers> No default would be needed for function
                   ray(<angle> && <size> && contain?)

Should omitted <size> just extend to the containing block edge?
   Scribe: TabAtkins
   Github Topic: https://github.com/w3c/fxtf-drafts/issues/73

   jihye: offset-based positioning properties describe the path the
          element is on, various ways.
   jihye: ray() defines a line segment starting from the position,
          going in the defined direction.
   jihye: It has 3 params - angle, size, contain.
   jihye: Size is where the path ends.
   jihye: When talking about size, have to know the path length
   jihye: To resolve %s.
   jihye: So most important factor is <angle> in ray(); I want
          consistency with %s here, so if all you do is animate the
          angle, the % resolves to the same length the whole time.
   fantasai: So question is what the behavior is when you *omit* the
             size keyword.
   fantasai: Earlier you just draw the ray until you hit an edge,
             it's that long.
   fantasai: Current spec it defaults to closest-side.
   fantasai: So my suggestion is adding an option (or defaulting it)
             to get back the "cast the ray to the edge of the box"
   [explicitly unminuted discussion about whether it makes sense to
       be the default]

   fantasai: It's not clear, if the "measurement angle" is different
             from the angle you're actually using, why 100% stops at
             the point indicated by closest-side.
   shane: I think that's not usually the case - mostly it'll be used
          to position things around a circle around the box.
   ChrisL: I agree with shane - I think it's usually the case that
           you're using this feature for polar-positioning multiple
   fantasai: That's *a* use-case yes, maybe the most common one.
   ChrisL: Yeah, and why not make the most common use-case be the
           easiest thing to do?
   Florian: [gives example of putting the start-point in the corner
            instead, where closest-side will send all %s to 0.]
   shane: I think the default of a polar-positioning feature should
          be a circle.

   astearns: What about making size always required?
   fantasai: [doesn't like requiring it]
   TabAtkins: [heh, fantasai wants a default, but prefers a different
              default than anyone else]
   shane: Straw poll?
   fantasai: I'm against making it required, but won't oppose it. I
             will oppose defaulting it to closest-side, especially
             beause of the behavior Florian mentioned where percentages
             resolve to zero if you choose a corner origin (which
             seems like a reasonably common use case)

   RESOLVED: <size> argument of ray() is required.
   [discussion of naming the keyword]
   RESOLVED: Name the "cast to the side you're pointing at" value

offset-rotation should only do path-relative rotation
   Github Topic: https://github.com/w3c/fxtf-drafts/issues/69

   shane: First, issue was opened because you thought offset-rotation
          duplicated 'rotate'. I don't think that's true, and we
          should reject it.
   shane: Second, this is happening well after we shipped; we'd
          prefer to not make non-essential adjustments.
   <ericwilligers> https://drafts.csswg.org/css-transforms-2/#ctm

   shane: Final output transform comes from several sources.
   shane: offset, translate, rotate, scale, transform
   shane: The order these happen in is quite integral to the result.
          Re-ordering is not generally possible.
   shane: So a rotation that happens in offset is different from one
          in TSR, which is different from one in transform.
   shane: In particular, a rotate in "offset-*" rotates the frame of
          reference that the TSR properties work in.
   fantasai: Do we *want* to do that?
   shane: Yeah, definitely cases where you want to; you might be
          doing something independent in TRS.
   fantasai: [describes some example she wants help with]
   [something about additive properties not being possible yet]
   [I believe the point is that the example in question is gonna need
       more control, probably in scripting, than we can reasonably
       provide in simple CSS anyway]
   <fantasai> The use case is that you have the little motion path
              plane along its path, and then you want it to have an
              :active { /* shift it down/right by 2px to react to
              click */ }
   <fantasai> This should not require scripting.

   RESOLVED: Close issue #69 no change.

offset-* property names collide with logical properties
   Github topic: https://github.com/w3c/fxtf-drafts/issues/51

   shane: Offset property names collide with logical props.
   shane: We have offset-path/rotation/etc. Logical props has
   shane: Question is what the 'offset' shorthand do.
   TabAtkins: I'm okay with no shorthand for positioning offsets.
   fantasai: It's a PITA to have to set tbrl to zero.
   fantasai: So we should have a shorthand for them
   TabAtkins: If we can agree that the logical props don't need a
              shorthand, we can just let the logical props to stay as
              they are, and give 'offset' to the motion-path spec.
   fantasai: And that shorthand should match the prefixes (although
             it doesn't have to but that would be silly)
   TabAtkins: If that's the case, then one of the impls has to change.
   dbaron: I'm okay with changing logical prop name.

   RESOLVED: #51 won't cause motion-path to rename; the offset-*
             logical props will change name.

   [naming brainstorming:

   leaverou: What were the motion-path ones renamed in the first
             place? They're not really about offsets.
   Florian: They're not about motion either - you only get that when
            you animation offset-distance.

Focus of custom textbox-like elements

   shane: If you have a button-thing or a text-thing, native focus
          behavior differs.
   shane: If you focus the text thing, it shows a ring whenever it's
          focused, regardless.
   shane: But button things don't show a ring unless you focused them
          via a non-pointer interaction.
   shane: This behavior is hardcoded into our browsers with a list.
   shane: So we have the :focus pseudo-class, which you can set an
          outline with.
   shane: With a rule like ":focus { outline: ...; }", all your
          button-things act like text-things.
   shane: Alice has proposed :focus-ring, designed to help with
          outlines, which matches only when the focus ring would show
          on the element.
   <dbaron> We've also had :-moz-focusring for a while; see

   shane: This is all background - we already accepted :focus-ring.
   shane: Now at the moment we have weird UA stylesheet focus stuff.
          Deep magic, we'd like to switch them to :focus-ring.
   shane: So now we have a secondary problem.
   shane: Sometimes people make buttony-like or texty-like things.
   shane: It would be nice to be able to opt these elements into the
          appropriate behavior.

   shane: We have two proposals. We probably want to do both.
   shane: First is a property on an element that sets it to texty or
          buttony behavior.
   Florian: Why default to button?
   TabAtkins: If you put tabindex on a <div>, clicking that div
              doesn't focus-ring.
   <aboxhall> focus ring usually applies to everything unless that
              changed recently
   <aboxhall> http://jsbin.com/bujerufeca/edit?html,css,js,output
   <aboxhall> clicking the div shows a focus ring
   <aboxhall> yes, texty is the default behaviour
   [looks like shane had it backwards]
   shane: Okay, so texty is the default behavior.
   <aboxhall> oh right, it shouldn't match :focus-ring

   <dbaron> I suppose this is important because right now people work
            around the undesired focus outlines with things like
            :focus { outline: none } ?
   <aboxhall> dbaron: yup

   dino: Why not just defer to the ARIA role?
   <shane> aboxhall: why not trigger different behaviors via aria
   dbaron: And general design with ARIA is that it doesn't influence
           outside the a11y space
   <aboxhall> +1 ARIA shouldn't affect anything other than the a11y
   <aboxhall> unless the author decides it should
   [general agreement with this policy]

   <aboxhall> Wait, earlier were we saying texty *should be* the
              default behavior?
   <shane> no we were saying it is the default behavior
   <TabAtkins> yeah, aboxhall, because it's the default on all
               elements today, so it needs to be the initial value of
               the new property
   <aboxhall> omg no
   <aboxhall> then we end up back where we started
   <aboxhall> buttony should be the default behaviour
   <aboxhall> if you want to always see an outline, use :focus
   <TabAktins> How does the "default behavior" send us back to where
               we started?
   <aboxhall> so you'll need to specify "not texty" on everything
              which isn't texty (which is most things)?

   shane: So second thing we want is the ability to refer to the
          browser's default focus styling.
   Florian: outline-style: auto does this
   dino: Our focus impl in Safari is slightly wrong - it should be
         slightly animated glowy outline.
   Florian: With outline-style:auto, it can even change the shape of
            the outline.
   Florian: Can, but not required to follow the outline-color.

   shane: So, Alice, can you explain your preference.
   aboxhall: If we default to texty, we end up where we are today -
   aboxhall: Most things aren't texty, right?
   TabAtkins: Yeah, but also most things aren't buttony?
   aboxhall: I think if it's focusable they're more likely to be
   aboxhall: Today people take the focus ring off things because they
             don't want it to act texty.
   aboxhall: So the buttony behavior, which people actually want,
             should presumably help prevent people from removing
             focus outlines from things.
   * fremy doubts that statement; devs remove focus rings because the
           designer told them he/she don't like it
   [convo back and forth a bit over exactly how this would be applied]
   * fantasai doesn't think focusability belongs in CSS
   * shane thinks that ship has already sunk

   TabAtkins: So if this affects :focus-ring, and we re-base our
              impls to use :focus-ring in the UA stylesheet, this'll
              be a behavior change for all tabindex elements. Is that
   aboxhall: I think it's a positive behavior change, yes.
   [a bit of banter over why devs remove focus rings]
   TabAtkins: So proposal is that the default of shmocus-mode is
              buttony, which has the knock-on effect that arbitrary
              tabindex'd elements will change behavior (no longer
              focus-ringing on click)
   aboxhall: Yes. And remember that this won't affect anything that's
             currently outline:none, or using :focus. Just default
             elements, and things targeted by :focus-ring.
   astearns: So does anyone have an objection to doing this?
   <fremy> astearns: I am not convinced at all this is a good thing
   <fremy> @astearns: but ok, no strong opinion
   <astearns> thanks, fremy

   RESOLVED: Come up with a property name for this focus-ring
             property, ratify the CSS-a11y TF, put it in css-ui-4

   aboxhall: One added thing - the way :focus-ring is specced, it
             leaves it open to the browser what heuristic to use to
             apply :focus-ring.
   aboxhall: Obviously this property can be part of that.
   aboxhall: But one feedback from a11y folk is that some people
             always want to see the focus ring, others find the focus
             ring always confusing. So there could be a user setting,
             similar to the Chrome Mobile setting that lets you force
             it to always allow resizing.
   TabAtkins: Yeah, that's generally allowed. And if the user
              stylesheet exists, it can override authors with a
              !important rule.

   Florian: I just checked out outline-style. By spec you have what
            you want, in Safari you have what you want. In Chrome you
            get a *different* fancy outline; in Firefox you get a
            plain outline; in IE you get nothing.
   [discussion of how to test outline-style: auto in a reftest]

   <br dur=15min>

Received on Saturday, 27 May 2017 01:02:18 UTC