- 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 http://thewebahead.net http://jensimmons.com 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 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 Thursday, 28 April 2016 03:45:30 UTC