Shane Stephens | 3 May 03:39 2016

computedStyle of cloneNode

Hi list,

What should 

Gecko returns the same value as getComputedStyle(foo).opacity, while WebKit and Blink return empty strings. Edge returns "1" regardless of foo's opacity.

It seems to me that returning the computed style of the cloned node is wrong as the clone isn't in the document and therefore doesn't match the same rules as the original. However, I can't find any specification text that confirms this.


fantasai | 2 May 18:55 2016

propdef tables for shorthands

We've been leaving most fields in shorthand propdef tables
as "see individual properties", but, I think going forward
we should fill these in if all sub-properties have the same
value. This is more useful to people looking things up in
the spec, especially as we are encouraging people to use
shorthands over longhands in many cases.


Michael Großklaus | 30 Apr 15:53 2016

Proposal for animation-pause property


I have a proposal for a new property for css animations. I was discussing this briefly (almost a year ago though) with Lea Verou via twitter and she told me that I should post to this mailing list and make my case. So I hope that's ok and the usual way to go. :)

So, I quite often have the case that I'm implementing an animation where the animation itself e.g. takes two seconds, but I want a break of, let's say, 8 seconds before the animation starts again.

At the moment I have to implement it like this:

<at> keyframes animationName {
    0% { animationStart }
  20% { animationEnd }
  21% { animationStart }

element {
  animation: animationName 10s;

This has multiple disadvantages:
- I have to animate back to the initial state (see keyframe 21%) what causes code duplication (I'm not 100% sure about this point - correct me if I'm wrong!)
- If I want to change either the duration or the break, but keep everything else as it is (in absolute numbers), I have to adjust the keyframes since they're relative to the duration value

If there would be something like an animation-pause, I could do the following:

<at> keyframes animationName {
      0% { animationStart }
  100% { animationEnd }

element {
  animation: animationName 2s;
  animation-pause: 8s;

This would solve the above mentioned disadvantages in my opinion.

I hope I was able to make my point. Thank you in advance!

Best regards,
Michael Großklaus

Freiberuflicher Web-Entwickler

Scheideweg 6
20253 Hamburg

mail <at>

USt-Id.: DE279812974
Finanzamt Hamburg-Hansa

fantasai | 1 May 08:25 2016

[css-scroll-snap] snap alignment container (concept name)

There's an issue marked in the spec for a better name for this
   # snap alignment container
   #    A scroll container’s snap alignment container is the
   #    rectangle obtained by reducing its visual viewport
   #    by its scroll-snap-padding.
   # ISSUE: Better name for this concept?

I propose “scroll snap window”, “snap window“ for short!
(I.e. use “snap window” but allow other specs to cross-link in to
“scroll snap window” for better context.)

   * shorter and easy to pronounce
   * relates to the concept of having a hole inside which we're
     viewing stuff, which is what it is
   * doesn't use the overloaded word “viewport”

   * ???


Mats Palmgren | 30 Apr 20:40 2016

[css-align] typos in justify-self/align-self for abs.pos. ?
"Otherwise, when 'justify-content' is not 'normal', ..."

"Otherwise, when 'align-content' is not 'normal', ..."



Brad Kemper | 30 Apr 01:57 2016

Re: [css-round-display] Add 'auto' to 'polar-anchor' and make it as initial value

Brad Kemper
> On Apr 29, 2016, at 1:56 AM, Jihye Hong <jh.hong <at>> wrote:
>>> On Apr 28, 2016, at 3:33 PM, Brad Kemper < brad.kemper <at> > wrote: 
>>> On Apr 27, 2016, at 6:49 AM, fantasai <fantasai.lists <at>> wrote:
>>> On 04/21/2016 11:56 AM, Jihye Hong wrote:
>>>>>> On Apr 20, 2016, at 3:19 AM, Brad Kemper < brad.kemper <at> > wrote:
>>>>>> On Apr 19, 2016, at 12:46 AM, Jihye Hong <jh.hong <at>> wrote:
>>>> My suggestion was,
>>>> - If any positioning property isn't specified, 'polar-anchor: auto' is the
>>>> same result of 'polar-anchor: left top'.
>>>> - When 'polar-anchor: auto' is specified on an element with 'left', when it
>>>> works as 'polar-anchor: left'.
>>>> - When 'polar-anchor: auto' is specified on an element with 'top', when it
>>>> works as 'polar-anchor: top'.
>>>> - When 'polar-anchor: auto' is specified on an element with 'right', when it
>>>> works as 'polar-anchor: right'.
>>>> - When 'polar-anchor: auto' is specified on an element with 'bottom', when
>>>> it works as 'polar-anchor: bottom'.
>>>> And 'polar-anchor: auto' is specified with 'left' and 'top', when it works
>>>> as 'polar-anchor: left top'.
>> This doesn't work. What if 'top' and 'bottom' are both non-auto? Or 'left' and 'right' are both non-auto?
I don't think we need polar-anchor:auto.
> I didn't mention all of the cases. I omitted some of them.
> My idea was, if 'top' and 'bottom' are both non-auto then 'polar-anchor: auto' works as 'polar-anchor:
bottom top'.

I think you meant 'polar-anchor: top'?

> And when 'left' and 'right', 'polar-anchor: auto' may be as the same with 'polar-anchor: left'.

>>>> 'auto' works like this to get the same result as the normal positioning
>>>> method.
>>> I don't think this makes much sense. Any value should give the same result
>>> as normal positioning if 'polar-origin' is 'auto'. Only if it is not 'auto'
>>> should 'polar-anchor' or 'polar-distance' have any effect.
>> True. Though if 'polar-anchor' was renamed as 'nudge' or 'move' (since that is its actual visual
effect), one could more easily imagine it working regardless of other polar-* properties, whenever
'position' was not 'static'. 
>>>> It was resolved that using 'polar-distance' or 'polar-angle' makes a switch
>>>> of the coordinate system from Cartesian coordinates to polar coordinates at
>>>> CSSWG F2F in Sydney [1].
>>> No, only 'polar-origin' is the switch.
>> Yes, thanks. I was worried there for a sec.
> I realize that we don't have the same polar model here.
> In my polar model, 'polar-distance' or 'polar-angle' makes the switch between Cartesian coordinates
and polar coordinates.
> And when 'polar-distance' or 'polar-angle' is 'non-auto' then 'polar-origin: auto' works as
'polar-origin: center'.
> But when both 'polar-distance' and 'polar-angle' aren’t specified, then 'polar-origin: auto' works
as 'polar-origin: top left'.
> Am I misunderstanding about the resolution from CSSWG F2F in Sydney?

I think you are misunderstanding, yes. 

Your polar model is more complicated. 'polar-origin' is the more obvious candidate for making the switch.
It's value is what says where to position the element in the containing block, so it's non-auto value is
what causes the centering anyway. 

If 'polar-origin' is auto, then it wouldn't position the element in the containing block at all, so that's
what we want for its initial value. If it is '50% 50%', then it centers it (or if you prefer to think of it in
more complicated terms, it changes the coordinates of the containing block to polar for 'polar-*'
properties only, where the "0 0" origin is in the center, and also changes the representative  alignment
point of the element to be in the center of the element. The end result is the same, however). 

But 'polar-angle' and 'polar-distance' can be (and should be) completely independent of this centering
effect, just as they would be with 'position: relative'. 

Mats Palmgren | 30 Apr 01:32 2016

[css-grid] abs.pos. section still says 'order' applies
"However, it does participate in the reordering step (see 'order'),
which has an effect on painting order."

I believe the above sentence is obsolete and should be removed.


Daniel Holbert | 30 Apr 00:11 2016

[css-grid] Need to document that "justify-self:auto" means "start" on absos children, just like "align-self:auto"

Hi www-style,

The grid spec has a special case for "align-self:auto" on abspos
children in 11.2:
  # For the purpose of calculating this static position,
  # a value of 'align-self: auto' is treated identically
  # to 'start'.

QUESTION: don't we need the same special case for "justify-self:auto"?

It looks like that's the intention, based on this line from the
"Changes" section:
  # Don’t follow 'auto' values of 'align-self' or
  # 'justify-self' on absolutely-positioned children;
  # just default to 'start' alignment.

But I don't see any normative spec text that describes this behavior for
"justify-self". So: I think my first spec-quote above (from 11.2) needs
to be broadened to cover "justify-self" as well as "align-self".


Dael Jackson | 28 Apr 01:09 2016

[CSSWG] Minutes Telecon 2016-04-26 [cssom-view] [css-text] [css-round-display]

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

Range.getClientRects() when range contains part of a grapheme cluster

  - RESOLVED: When a range endpoint falls in the middle of a
              grapheme cluster, Range.getClientRects() should
              include the entire grapheme cluster.

Control Characters Roll Call on implementation

  - gregwhitworth asked for updates on browsers for their status on
      the control characters change resolved in Sydney in 2015.
      - Safari hasn't begun implementation
      - No one on the call could speak for the Chrome team.

Round Display

  - The conversation around viewport-fit for setting the viewport in
      the non-rectangular display will be postponed to the F2F where
      a whiteboard is available.
      - The terminology will also need to be decided on to make the
          concepts clearer.
  - The 'auto' value of viewport-fit as written in the spec wouldn't
      be useful. There was wide support for an 'auto' value that
      says do something between contain and cover that's smart if
      you want to or just do contain. This would allow UAs to
      innovate in this new space.
  - Changing the initial value of 'polar-anchor' to 'auto' brought
      up two different models of how 'polar-anchor' should be used.
      There wasn't enough time to decide between the two, so the
      conversation will continue either on the next telecon or the
      - Either model would be fine with the initial value being
          'center' so that is likely to stay the same no matter
          the result of the conversation.



  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Joone Hur
  Dael Jackson
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Michael Miller
  Florian Rivoal
  Hiroshi Sakakibara
  Alan Stearns
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  Dave Cramer
  Ian Kilpatrick
  Anton Prowse
  François Remy

Scribe: dael

Range.getClientRects() when range contains part of a grapheme cluster

  Rossen: Let's get started.
  Rossen: Hello everyone.
  Rossen: Any extra items?
  Rossen: koji are you on?

  koji: The issue is that when Range.getClientRects() is called and
        it contains part of a grapheme cluster the behavior was
  koji: On the mailing list Xidorn and Simon and I agreed it should
        extend to include grapheme clusters. I'm asking if that's
        okay with the WG.
  myles: I think it should include the whole cluster.

  * fantasai notes that this is more-or-less undefined wrt boxing
  <fantasai> "The rendering characteristics of a typographic
             character unit divided by an element boundary is
             undefined: it may be rendered as belonging to either
             side of the boundary, or as some approximation of
             belonging to both."

  Rossen: Is that okay with the WG?
  Rossen: Is there a reason why it shouldn't be okay?
  Rossen: It sounds reasonable.
  Rossen: Is there anything that makes this unreasonable?
  koji: Not for me.

  smfr: Have we seen this issue in the wild?
  Rossen: Is this something you've observed or are we making this
  koji: In blink there were behavior changes and that caused this.
        Before we made a fix we want to clarify the spec
  Rossen: Is there any content broken or effected because the
          changes? Or does this just need to be added to proceed
          with the implementation?
  koji: All uses we're aware of are including grapheme cluster.
  Rossen: I didn't understand. Have you seen websites or docs that
          depend on this today?
  koji: An application was dependent on the behavior. The app
        developers say including grapheme cluster is what they want.
  Rossen: Okay.

  Rossen: Going back to the WG, any opinions or concerns?
  <astearns> seems like editing would be adversely affected
  dbaron: I might have misunderstood what this was about
  * tantek is still trying to understand what this is about as well
  dbaron: Maybe not
  <dbaron> I guess as long as we're talking about things that are
           actually grapheme clusters, rather than also getting into
           ligatures, which I think may be more interesting

  Rossen: Do we include grapheme clusters in the bounding rect if
          there are grapheme clusters in the range. Myles expressed
          support, koji is in favor. I'm not opposed. I'm curious to
          see what others think.
  smfr: This is when a range endpoint is in the middle of a grapheme.
  Rossen: I thought when it encompassed.
  koji: It is the endpoint, yes.
  dbaron: I was mixing endpoint in a grapheme and a ligature. If
          it's endpoint in a grapheme it makes sense. If it's
          ligatures you may want to divide.
  myles: Yes, let's keep this only grapheme clusters.

  myles: One piece of clarification...
  myles: This proposal is not changing the indexes of the range so
         web content wouldn't know the boundaries measured. The
         implementor would do this internally, but the new ranges
         would not be visible to script.
  koji: Yes.
  koji: Both Xidorn and Duga (sp?) both said returning the region is
  Rossen: I missed that koji.
  koji: I asked the question if browsers should do the extended
        region and both individuals said negative.
  Rossen: To summarize...based on conversations with their Android
          devs that complained about the breakage from a Blink
          change, they expect that when a range falls in the middle
          of a grapheme, the get bounding rect wouldn't include any
          of the bounds, it excludes it. Is that right koji?
  koji: I'm not sure if I understand.
  <Bert> (So, if I understand correctly: in computing the size of
         the range that starts between O and acute-accent, the O is
         included in the measure.)
  koji: Let me repeat.
  koji: The expectation is that they want to return the rectangle
        bounding including grapheme clusters, but they don't need
        the range of the result.
  koji: Does that make sense?
  myles: You said do not need the range?
  koji: Yes.
  myles: Sounds like everyone agrees.

  Rossen: Are you guys okay? Does anyone object?
  Rossen: To summarize the resolution: getBoundingRect() excludes
          the range when it falls in the middle of a grapheme cluster.
  myles: I was under the impression it would include.
  Rossen: That's why I kept asking. I was getting confused. A couple
          of times you said they didn't expect it to be included and
          then you said it would be.
  koji: Include. I think I said extend, not exclude. So that means
  Rossen: Got it. So it is inclusive.
  Rossen: Objections to that proposal?

  RESOLVED: getBoundingRect() INcludes the range when it falls in
            the middle of a grapheme cluster.

Control Characters Roll Call on implementation

  gregwhitworth: Basically we all agreed at Sydney in 2015 we would
                 put it behind a flag in Nov 2015. Only Edge and FF
                 have done that.
  gregwhitworth: I'm either missing it in Chrome or it's not impl
                 and I'm not seeing it in Safari.
  myles: Safari has not started impl.
  gregwhitworth: Dino guaranteed it so talk to him :)

  Rossen: Anyone on the Chrome who can give an update?
  Rossen: I guess not.

  gregwhitworth: I'd like to stress we're trying to use this as a
                 test bed where we can work together in a unified
                 way. So if you can prod the devs to get this done
                 and ship uniformly in the next year or two that
                 would be great.
  Rossen: Okay. Other comments?

Range.getClientRects() when range contains part of a grapheme cluster

  Bert: Can someone check the resolution previously? Or maybe just
        point to the e-mail instead?
  <smfr> "when a range endpoint falls in the middle of a grapheme
         cluster, Range.getClientRects() should include the entire
         grapheme cluster”
  Rossen: The proposed was that it extends the start and end of the
          range to include the full grapheme cluster before it is
  Rossen: And current is [reads]
  smfr: I think we should do what I types into IRC
  <Bert> +1 to what smfr typed
  <myles> +1 to smfr
  Rossen: Okay.
  Rossen: So the range is what it is.
  myles: Yes.
  <koji> yes
  Rossen: That's correct, right smfr?
  smfr: range is unchanged.
  Rossen: Only thing extended is ClientRect.
  Florian: Yes.

  RESOLVED: ignore previous resolution
  RESOLVED: When a range endpoint falls in the middle of a grapheme
            cluster, Range.getClientRects() should include the
            entire grapheme cluster.

CSS Round Display

  Rossen: jihye are you on the call?
  jihye: I'm on the call

viewport-fit for setting the viewport in the non-rectangular display

  jihye: First topic is viewport-fit. In the previous meeting we
         added viewport-fit. It can set the size of the bounding box
         for the viewport. And we can see the actual port through
         the bounding box. In a rectangle we didn't need the concept
         of the bounding box because it was they physical screen. On
         rounded the shape isn't the same.
  jihye: So actual viewport is the bounding box which takes
         circumscribed rectangle of the...[missed]
  Florian: To rephrase, I think we have a terminology problem
           because screens and viewports have been rectangular. As
           soon as the screen isn't a rectangle we don't know if the
           viewport is a shape or a rectangle. Either way the
           viewport is one thing and there's another thing. One is
           rectangle one is shape.
  Florian: In my mental place, the viewport is rectangular.
           Something that doesn't have a name isn't rectangular.
  fantasai: Isn't that the screen?
  Florian: Probably.
  jihye: You think that the actual viewing area is the same as the
         actual viewport?

  Florian: We have as much of a terminology problem. We don't just
           have viewport, we have layout and visual viewports. The
           way I propose a stub for a spec, we have two values,
           cover and contain. You have a screen with a shape and you
           take the bounding box of the screen shape. If you do
           cover the initial layout matched the screen bounding box.
           If you do contain the initial layout viewport fits within
           the screen.
  jihye: We're confusing actual and visual viewport.
  Rossen: What does actual viewport mean?
  Florian: It's in opposition to the initial viewport. It's
           different states of the viewport. The way it's speced
           when you run  <at> viewport algorithm the initial viewport is
           the one you get if you have no  <at> viewport rule, including
           in the style sheet.
  Rossen: Initial is defined well.
  Florian: Actual is after you resolve all  <at> viewport rules.

  jihye: When we use screen object, screen.width is the actual or
  Florian: It's all undefined as far as I know. I think it's
           documented on a blog.
  jihye: You think the bounding box I mentioned is the same as
         visual viewport?
  Florian: I think the bounding box of the screen shape is the
           initial layout of the viewport when viewport-fit is cover.
  Florian: And when viewport-fit is contain the thing that defines
           initial and layout viewport is the thing inscribed in the
           screen shape.

  Florian: I think this needs to be F2F with drawings.
  jihye: Yeah.
  Florian: I don't think the mechanism is hard, but the terminology
           is poorly defined and there's a bunch of rectangles.
  Rossen: I think the explanation is clear, but I don't mind going
          over this at the F2F.
  Rossen: Back to jihye, would this satisfy you? Pushing it to F2F?
  jihye: I think we should define the viewport-fit better when we
         meet in F2F. I want to discuss other things on viewport-fit
         such as the value.
  * bradk thinks 'actual viewport' is a misleading term.

  jihye: We talk about the value of viewport-fit contain|cover|auto.
         I think auto should work when display is rectangular or
         rounded as contain. For the other shapes auto is cover.
  Florian: What I meant with my auto proposal is it's similar to
           contain but less strict. On a rectangle contain and cover
           at the same. In a rounded rectangle it should be the same
           as or it should be a little smaller because the UA thinks
           dropping the corners isn't that bad. It could have an
           additional mechanism where if you drag around you can
           move the viewport to show everything. It's a magic value
           that's kinda like contain but you can do a little
           scrolling or panning.
  Florian: If you have a smart way of showing more than contain you
           can and that's auto.
  Florian: You seem to think auto decides between contain and cover
           depending on screen shape.
  jihye: Yes.

  Florian: So, I don't understand why you don't group other shapes
           with round.
  jihye: Because we, so far, can't know the exact shape of the
         display except round and rectangle. So I thought that when
         we don't know accurate shape we have to do an estimated way.
         Same on the rectangular. I thought I divided that.
  Florian: So if you don't know the shape of the display you can't
           do contain so auto might as well be cover
  jihye: Yes.
  Florian: I don't think you can do contain either. If the UA
           doesn't know the shape of the screen it cannot impl this
  <bradk> Good point
  Florian: So I don't think making auto depend on that helps.
  Florian: If that's the concern we should drop auto, but I think
           the value I proposed might be marked as at-risk.

  jihye: So your thought is the auto isn't necessary for
  Florian: I think it's not. The basics is contain and cover. The
           auto I proposed is contain + magic UI. But if no one
           wants to implement. that magic, the basic semantics are
           in cover and contain.
  Rossen: Wasn't that the original...back to your fragmentation for
  Florian: I don't think I came up with that. I think I took that
           from something fantasai said, but I'm not sure the history.
  fantasai: We were discussing different ways to do a viewport that
            fits in a circle. Having a static viewport is the
            simplest way. But there are other ideas like have some
            extra margin in the scrollable area so you can pull the
            screen down. That way you can have a shape that's
            slightly bigger. But it wouldn't be cover or contain.
  fantasai: This is a new area so we don't know how the device
            manufacturers will come up with to present this to the
            user. Auto lets you come up with other solutions.

  Rossen: I sympathize with this if we define auto as a UA choice
          that's a value between contain and cover. It's currently
          stronger than that.
  Florian: That's not what I proposed.
  Rossen: I'm reading the spec as-is. [reads]
  Florian: Yeah, I don't think that auto is useful.
  Rossen: Agree. I sympathize with the other proposal to let UA
  Florian: I just want to add that I think we should leave it to the
           UA and for the UA's that don't know what to do do the
           same as contain.
  Rossen: Yeah.
  Florian: So if you don't know what to do do contain. If you have a
           better idea do that.

  Rossen: Given that we're going to discuss this at length and we've
          got other topics. jihye is there anything else for now or
          wait for the F2F?
  jihye: I think the definition of auto that I suggest would be
         changed is better. The definition of viewport-fit can be
         dealt with at the F2F.
  Rossen: And what is the change you're referring to for auto?
  Florian: What we just said, no?
  jihye: Yes.
  Rossen: Oh, got it.
  Rossen: So it sounds like you're okay with the definition we
          discussed and pushing the rest to the F2F.
  jihye: Okay, yes.

Make the initial value of 'polar-anchor' as 'auto'

  jihye: Polar-anchor chooses the representative point within the
         content of the element when positioned in the containing
         block. When I suggested polar-anchor originally it was only
         in polar-coordinates. But now it's in box position. The
         initial value is currently center. If it's positioned
         without polar-anchor where is the representative point?
  jihye: Even if it's not specifically set, the default values refer
         to the initial values. Therefore the representative point
         is the center, even if polar-anchor is not specified. It
         should be the same if it's cartesian or polar coordinates.
         But this is against box positioning rules. I think this can
         be solve when initial value of polar-anchor is auto.

  Florian: We've changed the model of how the properties interact a
           few times. If we're not doing polar-positioning, what
           does polar-anchor do?
  bradk: Nothing.
  Florian: So the initial value doesn't matter.
  bradk: It's kind of redundant to transform translate for what it
         does. For polar-anchor.
  bradk: All it does is move the element. You can say it's by
         finding how the center is, but it's just adding another
  Florian: I think I remember we didn't want to do transforms
           because it's a mix of layers and transforms are after
           layout and positioning. When we have polar-distance with
           the contain value that tries to take everything into
           account to not overflow, you don't want transforms at
           that point. So if we want to be able to do the same
           movement, but we want to do the right movement, so it has
           to be separate.
  bradk: I understand that. If it's a separate property you can call
         it translate and it can do something when not
  Florian: That's confusing with actual transforms.
  bradk: Nudge or move or something.
  bradk: polar-origin makes it confusing because it's not polar.
  Florian: We talked about how this interacts with other positioning
           and landed on something...what was the latest?

  fantasai: None of the properties apply unless polar-origin is not
            auto. We added auto which positions according to normal
            position scheme. If it's auto or not the polar-angle
            move from that position. You can move it at an angle at
            a distance. There's some ambiguity and issues, but it's
            in the Sydney minutes.
  fantasai: bradk's latest email does use the Sydney agreement.
            Initial value is polar-distance is 0 and angle can be 0
            or it doesn't matter. I don't think having polar-anchor
            value of auto makes any sense. I think it's fine as the
            center of the element and you can change that.
  fantasai: In the positioning scheme unless you set polar-origin to
            something non-auto the polar-anchor value would have
            some effect. If you don't specify polar-anchor and leave
            as center, the center is the position. If polar-origin
            is auto you don't care what the anchor is.
  bradk: I don't think you care anyway because when you're doing
         angle and distance it's the whole element that's moving.
  Florian: Yes. Where it matters is when polar-origin is not auto.
           Then you're aligning that point to the point in polar-
  bradk: That's adding more layers of obfuscation to what you're
         doing. You're moving the element once you've centered it
         somewhere. Polar-anchor moves things around.

  Florian: I know you hate the naming, but let's have that
           conversation separate from behavior.
  bradk: Basically it moves the element when polar-origin is not
         auto. Why not just let it move the element around?
  jihye: I thought polar-anchor can work independently from
  bradk: It's simpler and more powerful.
  fantasai: What would it do without polar-original. That abspos
            model isn't point to point alignment. You're creating
  <fantasai> I think if we have an 'auto' value for polar-anchor, it
             should copy the value of 'polar-origin'.
  <fantasai> I don't think the definition in the thread is useful

  Florian: So you're in flexbox and haven't touched any other polar,
           you just do polar-anchor topleft. bradk you're suggesting
           that moves 50% top and left?
  bradk: Yeah. That's why the naming is part of that. Why not move
         it with any positioning?
  Florian: So you would have it take percentage or absolute length.
  bradk: That's the effect when in polar-positioning
  fantasai: No.
  Florian: Not really.
  fantasai: Shifting something slightly in respect to current
            positioning is what relative positioning is for.
  bradk: You're combining with abspos so you can't have both.
  fantasai: So you use offset property in abspos. You can use calc.
            I don't see why we need to do this.
  bradk: Then we don't need the property.
  fantasai: It's only useful if using polar because then you can say
            in the containing block take the top-center edge and on
            the element you want the center.
  bradk: It's the same as always taking the center and polar anchor
         is an additional movement. You're always aligning the
         center to the position in the containing block as spec by
         polar-origin. polar-anchor adds an additional movement.
  fantasai: Sort of, yes. That's not how we think of it.
            Polar-origin doesn't have access to size of the child. I
            think...if you want to copy the way background
            positioning works it might be useful and the auto to
            polar-anchor can copy polar-origin and if you say center
            it's 50% from both. That way it works the same as
            background images.

  Rossen: Before we go further, we're at top of the hour. It sounds
          like this can go for some time.
  Florian: We have two topics in the topic. bradk and fantasai
           models are different. In fantasai model polar-anchor
           doesn't apply when polar-origin is auto so the initial
           value of center is fine. In bradk model polar-anchor:
           center is fine as the initial value. In both models
           center is fine.
  bradk: That might be right.
  Florian: So either model, the initial value of center is fine.
  <fantasai> Fwiw, I think adding 'auto' to polar-anchor is okay if
             it's meaning is to copy value of polar-origin

  bradk: Maybe we should defer to F2F where we can do diagrams.
  Rossen: Okay, jihye one more topic to the F2F. Is that okay? We
          can always do next week's call
  jihye: Do we have a next week call?
  Rossen: I thought so.
  jihye: Okay, let's move to next week.

  Rossen: Okay, we're a minute past the hour. Thank you everyone,
          I'll talk to you next week.

Yves Lafon | 27 Apr 10:53 2016

[css3-values] turn missing from attr() types.

Looking at
<type-or-unit> keywords
The dimension list contains ‘deg’ ‘grad’ ‘rad’ but ‘turn’ is missing.


Baroula que barouleras, au tiéu toujou t'entourneras.


Rossen Atanassov | 27 Apr 03:37 2016

[csswg] Agenda conf call 27-Apr-2016

Time/Phone/WebEx details available to WG Members in w3c-css-wg.
US Toll Number: +1-617-324-0000

For local times, see: 

0. Extra agenda items and other digressions

1. [cssom-view] Range.getClientRects() when the range contains part of a grapheme cluster 

2. [css-text] Control Characters Roll Call on implementation
    (getting any indication from lagging browsers)

3. [css-round-display] viewport-fit for setting the viewport in the non-rectangular display 

4. [css-round-display] Make the initial value of 'polar-anchor' as 'auto'

5. [css-color] wider/deeper colors/color-gamut:

6. [mediaqueries][css-page] MQs should respond to page size 

7. [css-lists] Bug in nested counter scopes