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

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

From: Jen Simmons <jen@jensimmons.com>
Date: Wed, 27 Apr 2016 23:45:04 -0400
To: www-style@w3.org
Message-ID: <etPan.57218740.7de1dd21.a446@MacBook-Pro-20.local>
I was at the meeting today. How is it that we take attendance? 

Jen Simmons
Designer & Developer Advocate at Mozilla
Host and Executive Producer of The Web Ahead
twitter: jensimmons

On April 27, 2016 at 7:13:58 PM, Dael Jackson (daelcss@gmail.com) wrote:

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.  

===== FULL MINUTES BELOW ======  

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 Thursday, 28 April 2016 03:45:30 UTC

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