[CSSWG] Minutes Telecon 2015-09-30 [css-round-display] [css-animations] [css-transforms] [css-selectors] [css-ruby]

Joint Meeting with WebApps @ TPAC
---------------------------------

  - Tuesday afternoon is the best option for a joint meeting.

Sydney Dates
------------

  - The Sydney dates are January 30th and 31st for Houdini, February
      1st to 3rd for CSS, February 4th to 6th for SVG.

'polar-anchor' Property
-----------------------

  - Jihye reviewed her proposal for 'polar-anchor', available here:
      https://lists.w3.org/Archives/Public/www-style/2015Sep/0234.html
  - Generally there was agreement that this was useful and the right
      direction for this property.
  - There was concern that the property could still cause overflow
      even though this property was designed to prevent it.
  - 'auto' seemed like it could be what prevents the overflow, but
      was under-specified in this proposal and needed to be fleshed
      out more.
  - RESOLVED: Add 'polar-anchor' with issues for better specifying
              'auto' and percentages.

Reverting 'animation-timing-function' Change
--------------------------------------------

  - dbaron has made the edits to Animations to revert the change.

Computed Values of 'translate', 'rotate' and 'scale'
----------------------------------------------------

  - TabAtkins will make the proposed changes to the spec.

ruby-merge
----------

  - The group will let fantasai and Richard Ishida come to a solution.

:focus-ring
-----------

  - The proposal was to add :focus-ring to allow authors to only
      style the focus ring when the browser would normally trigger a
      focus ring as a way to narrow-down the more generic :focus
      pseudo-class
  - There were concerns that this would have negative accessibility
      implications, but it was argued those implications exist
      within :focus and should be addressed there- this makes the
      problem no worse than what already exists.
  - The name seemed problematic to some people so it may need
      bikeshedding later.
  - RESOLVED: Add :focus-ring to Selectors 4 or 5

Stacking Context at animation-start
-----------------------------------

  - In the following example, the stacking context would happen at
      the 49% keyframe:
          @keyframes move {
              from, 49% { transform: none;}
              50% { transform: translateX(10px); }
              to { transform: translateX(100px); }
          }
          <div style="animation: move 10s"></div>

===== FULL MINUTES =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2015Sep/0300.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Greg Davis
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Dael Jackson
  Brian Kardell
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Simon Pieters
  Anton Prowse (IRC Only)
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Lea Verou
  Ian Vollick
  Greg Whitworth

  scribe: dael


  plinss: Let's get started. Anything to add to the agenda?
  <Florian> http://www.w3.org/mid/C717D9A5-8A02-4598-935F-EB83E10D5FF0@rivoal.net
  plinss: I'll take that as a no.
  <Florian> The mail I pasted above is extra agenda items I'd like
            to get to, but WebEx isn't working, as you can't seem to
            hear me. Rebooting.

Joint Meeting with WebApps @ TPAC
---------------------------------

  plinss: This is a joint meeting to discuss ShadowDOM styling.
  plinss: They're proposing Monday or Tuesday. Any constraints for
          time? jdaggett prefers Tuesday afternoon.
  Rossen: Is that a joint meeting discussion?
  plinss: Yes, for ShadowDOM. Any preference or constraints between
          Monday and Tuesday afternoon?
  Rossen: Either works for me.
  plinss: Current proposal is Tuesday afternoon from jdaggett. Let's
          go with that.

Sydney Dates
------------

  plinss: I have on my calendar Jan. 30, 31 Houdini. Feb. 1-3 for
          CSS, Feb. 4-6 for SVG. Does that agree with everyone else
          and any reason to change it?
  Rossen: Is that what's on all the wikis?
  plinss: It's what's on the feed. Let me check the wiki.
  dbaron: I think it agrees with everything except maybe SVG because
          they shifted a few days.
  plinss: It agrees with CSS.
  Rossen: Then it should be fine. If that's what the wiki says I'm
          good.
  plinss: Let's consider those dates in stone.

'polar-anchor' Property
-----------------------

  Jihye: I'm from LG Electronics, the editor of Round Display. I
         wanted to talk about 'polar-anchor', a new property related
         to round display.
  Jihye: While discussing it at the F2F in Paris there was a concern
         about overflowing within a containing block. Using only
         polar-angle and -distance to position we have to adjust to
         avoid elements coming out of the containing block.
  Jihye: To solve this 'polar-anchor' was suggested. It sets the
         anchor of the element and specifies a position that is a
         representative point of the element aligned with the
         containing block.
  Jihye: I referred to background position property for this. It
         takes value type <position> which is defined in the
         background position property. Any point in the content can
         be an anchor point.
  Jihye: When you can see the polyfill I mentioned in the mailing
         list there are 12 elements in circular layout.
  Jihye: Please see my message on the mailing list, reference #4. I
         implemented 'polar-anchor' as a polyfill so you can see and
         example.
  <astearns> http://anawhj.github.io/jRound/demo/polar/anchor.html
  Jihye: There are 12 elements in a circular layout.
  Jihye: First, 4th, 7th, and 10th are set to top, right, bottom,
         left.
  Jihye: The anchor of 2nd and 3rd are right-top
  Jihye: Those of 5th and 6th are right-bottom.
  Jihye: 8th and 9th are left-bottom, 11th and 12th are left-top.
         They are set according to the value of polar-angle.
         Therefore the exact distance value between the center
         points and the edge of the containing block become polar-
         distance value so you don't need to adjust it to avoid
         overflowing.

  Jihye: So I want to ask you is this 'polar-anchor' useful enough
         to be a new property?
  Florian: Yes, I think it's good. You're e-mail included the 'auto'
           value and I'm guessing it would mean you wouldn't need to
           say top-right on 2 and 3, etc. and it would guess based
           on the angle. I think that would be useful and difficult
           to specify. Even without that it's useful so I'm in favor.
  Jihye: Thank you.
  Jihye: And the name of this property is appropriate?
  Florian: I think so.

  <dbaron> I don't understand how polar-anchor interacts with
           polar-angle and polar-distance
  Florian: There's a comment on IRC from dbaron saying he doesn't
           understand. If I do, the polar-anchor says which point in
           the element that you're placing using polar coordinates
           is measured from the center of the containing block. If
           you do top-left you're positioning the top-left of the
           element from the center of the containing block. The
           default is center center.
  <dbaron> ah, ok.
  Jihye: Yes, default is center center
  Jihye: What was your question?
  Florian: It was dbaron asking how it worked on IRC so I explained.

  <astearns> if I understand correctly, if the 7 box is much wider,
             it's bottom left and right corners would still overflow
             the circle.
  <Florian> astearns: I believe so, yes. But presumably not with the
            auto value (which is not polyfilled here).

  Jihye: When the anchor point is set within a content box of the
         element then the represented point of the element, which
         point is mapped in the containing block is decided.
  Jihye: Anchor point is center center then the center point of the
         content area of the element is mapped to the point of the
         containing block.
  Jihye: When you put the element whose anchor is center center to
         the edge of the containing block some part of the element
         overflows.
  Jihye: Can you understand it?
  Florian: I think that's what astearns was saying on IRC.

  <fantasai> The 'auto' value basically says "position like bg
             position works"

  ChrisL: The numbers are irregularly spaced because there isn't a
          consistent position and I think the reason for that is
          that the demo is trying to make sure it doesn't go over
          the edges. [cutting out]
  ChrisL: In general this proposal doesn't guarantee you won't go out
          ...it depends on the shape that uses the alignment point.
  <ChrisL> It seems that this would need a clipping behaviour.
  Florian: So if I understand this, yes if you're using the explicit
           position keywords depending on the shape of the element
           and the container you will have a chance of overflow. The
           auto should make this magically not overflow. What I'm
           less sure about is how auto works when the distance is
           not 100%.
  Jihye: In the polyfill I didn't consider auto.

  plinss: What I'm hearing is people agree it's useful, but there
          are questions about how auto works and it doesn't seem to
          completely guarantee no overflow so there may be work
          there. It's a good start.
  Jihye: Thank you.

  Jihye: I'm curious, is value type <position> acceptable for
         'polar-anchor'?
  Florian: I guess so. What I think we should do is resolve to add
           this, see how you write it, try to resolve the issues
           around auto, and depending on how well it works maybe we
           don't need <position>.
  Jihye: Okay.

  Florian: What do others think?
  <TabAtkins> Without a well-behaving (and well-specified) auto
              value, I'm not convinced <position> is worthwhile.
  <TabAtkins> The trig you need to do to figure out where it should
              go can just as easily be used to adjust polar-distance
              with a fixed (center) anchor.
  dbaron: I feel like <position> is awkward when you're at an angle
          that's not a multiple of 45deg. If you look at the clock
          example the numbers are a bit uneven.
  Jihye: Between 1 & 2 and 2 & 3?
  dbaron: Yeah.
  Jihye: I will think about that, thank you.
  <ChrisL> dbaron, I explained why they are uneven earlier. look at
           the css
  <ChrisL> #item3 {
  <ChrisL>            position: polar;
  <ChrisL>         polar-angle: 60deg;
  <ChrisL>         polar-distance: 100%;
  <ChrisL>            polar-anchor: right top;
  <ChrisL> }
  <ChrisL> #item4 {
  <ChrisL>            position: polar;
  <ChrisL>         polar-angle: 90deg;
  <ChrisL>         polar-distance: 100%;
  <ChrisL>            polar-anchor: right center;
  <ChrisL> }
  <ChrisL> different alignment points

  dbaron: I wonder...I think having square boxes around the numbers
          seems a bit awkward as well so I don't know if that's
          messing with my view of the example.
  dbaron: The way background position works is if you say 75% 75% it
          aligns a point that is 75% 75% in the image to the point
          that's 75% 75% in the box. I wonder if something more like
          that would be useful here.
  Florian: Or...I think now it's positioning the anchor so when
           you...I think when you do an angle and a distance it
           should still work from the center but use the anchor to
           avoid overflow. That doesn't make sense. What we're
           trying to do is adjust how far the element is moved out,
           not adjust the line of how far it's move. Anchor seems to
           be doing both.
  Florian: But I still think it's difficult to talk without details.
           I'm in favor of writing it and working on issues from
           there.
  plinss: Agreed.

  Florian: Should we resolve?
  TabAtkins: I'd rather see a well specified auto value or some
             fixes to percentages before we resolve. Without that I
             don't think it's useful.
  plinss: Let's see it added to the ED so we can work on those.
  fantasai: You can add it with those two issues.
  plinss: Yeah.

  RESOLVED: Add 'polar-anchor' with issues for better specifying
            'auto' and percentages

Reverting 'animation-timing-function' Change
--------------------------------------------

  dbaron: I don't know if there's anything to discuss. Everyone on
          the list agreed. I reverted the one change though there's
          a bunch more editing I haven't gotten to.
  plinss: Okay.

Computed Values of 'translate', 'rotate' and 'scale'
----------------------------------------------------

  TabAtkins: I agree with what dbaron said and I'll make the edits.
  plinss: Other opinions?

ruby-merge
----------

  plinss: Richard Ishida sent some e-mails on this. Can anyone speak
          to it?
  Florian: If anyone it would be fantasai.
  fantasai: I sent a message to the list yesterday, I don't know if
            there's been time for Richard to reply. It was suggested
            there should be a value that triggers Jukugo ruby as per
            JLREQ and that the rest of it should be dropped. I don't
            have a response from Richard.
  plinss: Anyone else have comments or are we okay with letting
          fantasai and Richard sort this out?
  TabAtkins: Yep.

:focus-ring
-----------

  TabAtkins: If you remember at the last F2F we had a discussion
             with bkardell about input modality. We've been working
             through the issues with bkardell and Alice Boxhall to
             find the simplest way to solve the use cases.
  TabAtkins: We're still working things through, but one thing seems
             obvious. Whenever the author wants to style the focus
             ring because it doesn't match the website's style: They
             can use :focus styling, but they can't style it only
             when the browser would have applied focus rings.
  <bkardell> ala
https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-focusring
  TabAtkins: The idea is to add a pseudo-class that applies only
             when the browser would apply a focus ring and we say
             the UA is styled with that pseudo-class.
  TabAtkins: We thought that was generally useful. Mozilla already
             has something that is basically this.
  bkardell: I shared it in the IRC.

  Florian: I agree this is a nicer way to address it, but we should
           wait for the use case hunt to end.
  TabAtkins: This seems useful no matter what the other conclusions
             are. What other functionalities we might need is what
             we're waiting on. This is independently useful
             regardless of how we decide on the other pieces of
             input modality.
  Florian: Depending on what we find if we see the :focus-ring can
           solve almost all the use cases we might want to change it
           to solve all of them.
  TabAtkins: That should only happen if we take two years. If we
             find we need to tweak it it would be in the next few
             months.
  <tantek> I'd like to hear from bkardell
  <tantek> rather than speculation

  * bradk thinks the name is weird. Should be something like
          :browser-chosen-focus
  * bradk "ring" is meaningless to indicate that it is a focus that
          doesn't apply to everything.

  Rossen: One concern I have is focus ring could be viewed as system
          specific between different OSs. Different implementations
          may want different ways to handle a11y scenarios which the
          page author may or may not be handling. With giving
          authors the ability to style focus ring they may fight
          with a11y primitives.
  TabAtkins: They have that ability already. The :focus pseudo-class
             lets them do that. This narrows the meaning of focus so
             that it doesn't happen when a browser doesn't normally
             trigger a focus ring.

  bkardell: I see a lot on IRC about name bikeshedding. I agree we
            can bikeshed. I think conceptually Alice and I agree
            that the crux of the problem as it manifests today is
            authors have no way to be privy to the knowledge the
            browser has. The :focus pseudo-class is unfortunate in
            that your use of it messes with the a11y.
  bkardell: :focus-ring is intended to just bubble up whatever the
            browser decides will get the focus ring and allow you to
            style it better without effecting a11y.
  bkardell: As to if we need more properties, this is a useful
            exercise to drill down and see. If we need to go further
            it lines up with our existing proposal. I don't think
            this precludes others.

  Rossen: I have my reservations. If we could go back I'd prefer
          this to be a global media feature that's set once not per
          pseudo-class...
  TabAtkins: I'm not sure what you're proposing there.
  TabAtkins: Is what you're proposing relevant to the fact that
             people can override focus rings today by messing with
             the outline property.
  Florian: Authors today cannot know if they're overriding or
           creating one where it shouldn't be.
  TabAtkins: Rossen's reservation was about overriding. We're not
             introducing new functionality.
  Rossen: Okay. Consider it a rant about past decisions.
  bkardell: If you'd like to talk more privately I'd love to hear
            what you have to say.
  Rossen: Sure.

  <bradk> :focus:not(:focus-ring) ?

  TabAtkins: So given that :focus-ring is a subset of :focus, any
             objections?
  plinss: If this pseudo-class is triggered then :focus is triggered?
  TabAtkins: Yes.

  <tantek> are we talking about just standardizing
           https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-focusring ?

  Florian: I've considered if a :focus-ring-within thing would be
           useful and I think probably not. That extension doesn't
           need to be repeated.
  TabAtkins: Yes. I think you want to be able to put a focus ring
             style in your document and you don't want that to apply
             to everything that has a focus ring.

  tantek: Are we standardizing what moz-focusring does?
  TabAtkins: It's basically moz-focusring.
  tantek: Okay. That sounds good to me.

  bkardell: Only caveat is we would like a way for custom elements
            to define their behavior. Are they more like a button or
            text input field.
  TabAtkins: And that's where conversations are ongoing, but that
             will interact with this pseudo-class.
  tantek: I think we should capture that as an open issue rather
          than try and solve it.
  <bkardell> +1
  tantek: We can specify this without solving that.
  bkardell: I wouldn't be bowled over if the group was opposed to
            that. I don't see a high bar to that.
  tantek: Let's capture the custom element part as an issue.
  TabAtkins: It should be a part of the custom elements. Now that
             we've agreed on level 1 that should arrive shortly.
  tantek: Okay. I'm fine with capturing this where ever.

  TabAtkins: This would go into selectors 4 or 5. 4 isn't
             unreasonable because it has one implementation and
             requires no new functionality so it's a pretty minor
             feature.
  tantek: Is Chrome committing to shipping this soon?
  TabAtkins: I can't speak directly to that, but I don't think we'd
             have opposition.

  plinss: Objections?
  smfr: Is the intent that the author would only change the outline
        style?
  TabAtkins: It's a selector. You can change what you want.
  tantek: Yeah, we often have selectors that can limit.
  TabAtkins: We have pseudo-elements that have limits, but that's
             due to the nature of the elements.
  plinss: There's no restrictions on :focus.
  bkardell: Someone in the community group raised that they thought
            it should be a pseudo-element.
  TabAtkins: We're not creating anything new on the tree.
  bkardell: I wanted to check for agreement
  Florian: I agree.
  plinss: I do too. There may be a reason for an pseudo-element
          later, but that may be just for a11y reasons.

  <bradk> Would :focus-ring override:focus? Or would they both
          apply?
  <bkardell> a ua default sheet could !important display

  smfr: I'm concerned that if this is used incorrectly you could get
        a state where it flickers in and out. You could set display:
        none and it would shift. I'd rather limit it to something
        that only applied to the focus ring.
  TabAtkins: I think there's reason to tint the background element
             for example. So I think there's reason to not just
             focus the ring. If you change the outline it overrides
             whatever the browser is doing for the focus ring.
  tantek: smfr if you have specific examples that you think are
          problems, post them with the moz prefix and we can treat
          Firefox as the canary in the coal mine.
  Florian: If there's a problem it's bigger than :focus-ring. All
           the drag and drop might have a problem. All UI pseudo-
           classes have that problem. We should solve this larger
           problem.
  TabAtkins: This is just a subset :focus to only do items that the
             browser would normally create a focus ring on.
  tantek: This is a subset of :focus
  TabAtkins: Any arguments on this that would also apply to :focus
             we should approach, but it's not something against this.
             It's valid, but isn't related to this request.
  tantek: Yes, anything that demos bad behavior we can demo with
          :focus.
  smfr: That sounds reasonable.

  smfr: I don't like the name. It's also not obvious to me what the
        UA would know when to stop stying it's normal focus ring.
  TabAtkins: It appears the default is that if you set outline we
             turn off the native style. We can capture that as the
             default or make something more explicit, such as a
             subset of outline that captures if it's being used as a
             focus ring. That's a generic focus ring issue.
  Florian: I agree that however we address that should go around
           outline property, not around the selector.
  smfr: I'm fine with that.

  RESOLVED: Add :focus-ring to Selectors 4 or 5

  * TabAtkins is thinking of "outline-focus: yes | no" (with better
              names), set to "yes" by the UA stylesheet and
              defaulted to "no" by the 'outline' shorthand.
  <Florian> TabAtkins: Maybe. Do you want to make a Pull Request
            against CSS-UI, then we discuss, and I merge if we agree?

Stacking Context at animation-start
-----------------------------------

  <smfr> https://lists.w3.org/Archives/Public/www-style/2015Sep/0279.html
  smfr: Before Paris I investigated a webkit bug. In Paris I spoke
        to TabAtkins and dbaron about the scenario where you have a
        set of keyframes and not all of them create a stacking
        context. So this e-mail has an example where 50% onwards in
        stacking. So when do they start the stacking context?
  smfr: Originally I thought it was when the animation started, but
        it looks like it starts at 49%. That's contrary to the
        opinion I got from TabAtkins and dbaron.

  TabAtkins: I didn't mean to indicate contrary to that. I assume
             animations is applied in the simple way where you only
             get stacking when you run into something that requires
             it. Anything else would have required extra work. I
             think that's correct. We should let animations change
             properties. The will-change is appropriate for say you
             will change the transform and you can create stacking
             earlier.
  <MaRakow> +1 to Tab
  <vollick> If authors wanted to avoid jank due to stacking contexts
            coming and going, they should use will-change as well,
            then?
  Rossen: I agree. I'd like it to be that values are applied as the
          timeline of the animation goes. Any kind of chaining
          doesn't need to be analyzed ahead of time which could be
          costly. I'm not sure where you're going, but my guess is
          with more stacking you get better layering which would
          lead to better performance. As a general rule from our
          implementation it would be hacky and cumbersome to analyze
          ahead of time.

  smfr: I bring this up because in webkit we'd prefer to hand off
        the animation to an underlying graphics animation. I'd
        prefer to not re-evaluate while it's running.
  Rossen: I totally sympathize, but I'd rather have a static
          decision where ether you let it be as is or you create
          stacking at the start of any animation that causes
          stacking. Trying to find out ahead means you have to
          compute a bunch of styles.
  TabAtkins: I think it's worse in the general web animations APIs
             where you can have more complexity. I don't want to
             limit it to small batches of keyframes when you can
             create a large number. We have a property to indicate
             that you will create stacking.
  Rossen: The animation graph intersecting with the inheritance
          isn't something you can find ahead of time.

  smfr: I think will-change inside keyframes won't have an effect.
  TabAtkins: It should still be respected via the resolution we made
             a while ago about having non-animatable ones flip.
  smfr: Okay. I'd like to hear from dbaron?
  dbaron: I think I agree with TabAtkins and Rossen.
  smfr: Okay.
  smfr: I guess we don't need new text in animations since this is
        the behavior that falls out from doing nothing.
  TabAtkins: Yeah.
  smfr: Okay.

  <bradk> @tabatkins -internal-outline:1px dotted black;gets set to
          none by shorthand in shorthand.

  plinss: I agree with all that, but one complaint we come up with,
          I hate that we have all these behaviors that are side
          effects and we can't get at directly, like if it's
          stacking context. I think we should have stacking context
          always.
  fantasai: If you set z-index to 0 it's stacking
  TabAtkins: Not quite. You also have to set position: relative
  <vollick> plinss: +1
  <MaRakow> https://drafts.fxtf.org/compositing-1/#isolation
  Rossen: We do have a property that's stacking context. It's a
          compound property, but implementing or exposing is
          straight forward. I'm not sure about useful. As to
          containing blocks I second that.
  plinss: It annoys me that there are so many things that say
          position:relative just to get the side effects.
  <dbaron> We actually changed opacity >= 0.99 to use the cheap
           drawing path
  TabAtkins: The isolation property from filter has the effect of
             making it stacking so it can define your filter groups.
             So that's one thing.
  TabAtkins: For containing blocks, for block layout the display
             spec defines the flow root type. For positioning we
             don't have a way to trigger arbitrary position
             containing blocking, which we should at some point.
  Rossen: We'll have to figure out how that intersects with
          positioning, but yes. I think we're taking a ranting
          detour from smfr issue.

  plinss: And we're over time. To close on smfr's issue, I think
          everyone agrees you create stacking context when you
          create stacking context, not beforehand.
  TabAtkins: Yep.

  Florian: I added some agenda+, can we do those next week? I also
           wanted an update on the prefixing policy for next time.
  plinss: Will do.

Received on Thursday, 1 October 2015 10:46:32 UTC