W3C home > Mailing lists > Public > www-style@w3.org > April 2016

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

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 27 Apr 2016 19:09:56 -0400
Message-ID: <CADhPm3vg1rQD0m1_=J1y1GA3-F2JdZWEKvu=tJqnErA-kuhF5g@mail.gmail.com>
To: www-style@w3.org
  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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Apr/0421.html

  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?

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Apr/0169.html
  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> https://drafts.csswg.org/css-text/#characters
  <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

  <Rossen> https://drafts.csswg.org/css-round-display/#extending-viewport-rule
  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 @viewport algorithm the initial viewport is
           the one you get if you have no @viewport rule, including
           in the style sheet.
  Rossen: Initial is defined well.
  Florian: Actual is after you resolve all @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'

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Apr/0357.html
  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
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Apr/0431.html
  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.
Received on Wednesday, 27 April 2016 23:10:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC