- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Apr 2016 19:09:56 -0400
- 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
F2F.
- 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.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Apr/0421.html
Present:
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
Regrets:
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
undefined.
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
prospectively?
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
desired.
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
include.
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
computed.
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
viewport?
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
viewport-fit.
<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
viewport-fit?
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
auto.
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
experiment.
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
movement.
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
polar-positioning.
<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-
anchor.
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
polar-coordinates.
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
offsets.
<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