Brief   Full   Jump  


High contrast


[CSSWG] Minutes Telecon 2017-09-06 [css-align] [css-ui] [css-values] [css-fonts]

1 message.

[CSSWG] Minutes Telecon 2017-09-06 [css-align] [css-ui] [css-values] [css-fonts]
Dael Jackson   Thu, 7 Sep 2017 08:08:45 -0400

www-style > September 2017 > 0014.html

Received on Thursday, 7 September 2017 12:09:43 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to:

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Align --------- - RESOLVED: Publish updated WD of css-align Spring and summer (July-ish) f2f planning for 2018 -------------------------------------------------- - RESOLVED: 1st week of July 2018, likely in Sydney, actual location TBD Review of the optional test failures in the css-ui-3 test suite --------------------------------------------------------------- - RESOLVED: Leave spec as-is, no changes. Accept all current requirements as listed in issue (Github: ). Should viewport units still depend on scrollbar width for overflow:scroll? --------------------------------------------------------- - RESOLVED: Drop the requirement to subtract scrollbar size from vh/vw units for overflow scroll. @font-face unicode-range and first available font ------------------------------------------------- - RESOLVED: Change spec text to read first available font that would match the U+0020 (space) character. (This change will be applied to both Fonts 3 and 4) ===== FULL MINUTES BELOW ====== Agenda: Present: Rossen Atanassov Tab Atkins Dave Cramer Alex Critchfield Elika Etemad Simon Fraser Dael Jackson Dean Jackson Tomoya Kimura Myles Maxfield Theresa O'Connor Naina Raisinghani François Remy Florian Rivoal Alan Stearns Shane Stephens Eric Willigers Regrets: Rachel Andrew David Baron Benjamin De Cock Daniel Glazman Tony Graham Chris Lilley Anton Prowse Melanie Richards Lea Verou Greg Whitworth Scribe: fantasai Spec Rec Next Steps/Extra Items ------------------------------- Rossen: Anything to add to the agenda? fantasai: I had a few items. First was publish an updated WD of align. RESOLVED: Publish updated WD of css-align fantasai: Next topic was this grid issue (1777), don't want to resolve now, just bring it to everyone's attention to discuss next week. <fantasai> Rossen: Is the first the link? fantasai: Grid issue where Sergio reported that current behavior of 1fr implying min of auto is confusing. It's fairly significant and I want to discuss next week. scribe: dael fantasai: 3rd is V&U issue I think we should close no fix. It's a request for adding pi radians. <fantasai> fantasai: This one ^ Rossen: I'll try and add to end of agenda. We have a shorter one. Unless there's anything else from you, does anyone else have extra issues? Especially from APAC friendly call only people. [silence] Rossen: Okay, I'll take that as no. Spring and summer (July-ish) f2f planning for 2018 -------------------------------------------------- shans: Can we refer to month not season? Rossen: Okay. I believe this is July/Aug 2018. shane: We...I believe we took on responsibility to host and looked at a number of options. Sydney is looking most viable. Down side is it's winter, but it's about the same as summer in San Francisco. fantasai: You could try co-hosting with Mozilla if you want Canada. shane: Yeah, it was within Google we couldn't find Canada. If there's a strong feeling Canada is better we can keep looking. I'll always prefer local. Rossen: If the host prefers Sydney, will there be any members that couldn't make that? <Florian> If (location == France) { any date is fine } else { prefer beginning or end of summer, not middle } Rossen: I believe our last discussion was referring to this as late July. Maybe early. nainar: Options in the doodle are all of July. fantasai: Did we want to consider August? nainar: We can. shane: There's no reason not to. We have a room hold in July but I think we would be fine for August. astearns: We tend to lose Europeans in August. Rossen: August will be harder for me. Florian: From a based in Japan perspective early summer or late summer is easier. Early July or late Aug. Rossen: Okay. scribe: fantasai Rossen: August is in the middle between the April meeting and TPAC. shane: When is TPAC? Rossen: Late October. <dauwhe> TPAC: October 22-26 shane: Late August seems too close to TPAC vs Berlin. <fremy> Slight preference for early July myself. Rossen: [asks a question, missed the question] Rossen: Should we at least sort out dates? Maybe early July? <Florian> I don't think either of the location makes a difference as to the date. 1st half of July works for me. Rossen: Hosting options seem to be Sydney, and maybe Canada. Rossen: Any objections to 1st half of July? shane: I would nail down the week, because of holidays in Sydney. shane: 1st week of July would be better. Rossen: So 1st week of July is better for hosting in Sydney. Rossen: Does anyone have any hard objections? Otherwise we'll resolve on 1st week of July. RESOLVED: 1st week of July 2018, likely in Sydney, actual location TBD fremy: Since we're resolving Sydney and this is APAC call, many people in Europe aren't here to comment Rossen: We can rediscuss next week if needed * fantasai thinks SF or LA would be good options, direct flights from just about everywhere we have members. Rossen: Wrt April F2F in Berlin, we need to know how many people interested in the venue hotel <astearns> Rossen: If so, please add to planning wiki. Review of the optional test failures in the css-ui-3 test suite --------------------------------------------------------------- Scribe: dael Github: Florian: During the previous F2F I reported about the test suite status. Close to done and passing. Optional tests don't pass for a lot. tantek suggested we review. Florian: In the GH issue you have the list of what fails and why. First list is nothing passes, second is only 1 passing. Short summary I think we're okay. Most of these are may tests. Florian: I think that's fine. Florian: There's a bunch of failing may tests, but there are a few that aren't and we can talk about. Florian: First is outline 005 which says the outline should follow the border edge. It fails in all browsers. In Safari this happens when outline-style is auto. Florian: I think this is fine. This is a thing we knew about when we decided. I feel okay with that. myles: What are you proposing here? Florian: I'm suggesting this is all fine. Or we decide this optional fails are bad. I don't think we need a change, but tantek suggested review so I'm going through the list. Does that sound good? fremy: It does to me. Florian: First is currently all browsers in most cases don't round the outline when the border radius is round. Safari does it when it's auto. Are we happy with spec as-is? Rossen: Spec is should? Florian: Yes. Rossen: Okay. Anyone unhappy with this? If not we can move on. [silence] Florian: Right. Florian: Next 4 are outline 13-16. FF passes 13, everyone fails the rest. If you put a negative outline and if you put a large one and it meets in the middle. The spec has error handling to keep the outline from disappearing when it meets itself. Florian: Everybody that's failing fails differently. This is a should. I think this should stay, it's a rare error case. Most browsers do bad, FF less bad. So it sounds reasonable to me. Rossen: Unless anyone objects we can move on. Florian: Text overflow 18. Spec suggests when you have text overflow ellipsis, when the user selects the ellipsis the spec suggests the user selects the test behind the ellipsis. This is a should. Suggested behavior seems more friendly. Is this misguided? Rossen: This borders with editing and we shouldn't define editing, but I'm fine with a should. hober: Should is a stronger verb. Rossen: Are you suggesting may? hober: I think we should file bugs on the browsers. Florian: I think I have filed bugs on most of this. Rossen: Let's continue unless there's a strong reason to not have a should. Florian: Next ones are resize tests. Normally resize only applied to overflow something not visible. We have a may to allow applying to a long list of other things. Safari and chrome do iframes. No one does anything else. Bugs are filed. This is may. I'm fine as is. fantasai: Fine to me. Rossen: Looks good. Next is cursor? Florian: Yes. Cursor takes url pointing to an image. In newer specs we have url or a list of other options. You may support these in addition to image. No one supports. It's a may. Rossen: We're fine on the edge side. Rossen: Next is cursor text 002. Florian: If you have horizontal text the text should be vertical. If you have transform rotate the cursor can angle to the text rotate. It's a may. Rossen: Sounds reasonable. It's a more advanced feature. Florian: Could happen on svg with a path. It opens the door. Rossen: Okay. There 4 more optional tests with 1 pass? Can we go through those as a group? Florian: Since we have one pass, 3 should and 1 may I'm okay with a blanket this is fine. Rossen: I think everyone can go individually. I want to be mindful of time. Florian: Understand. Rossen: So 4 optional test, FF passes 3, Safari passes the 4th. Florian: And the last two are subcases we've discussed. Rossen: If no objections we can call all of those resolved so this issue is resolved and closed. fremy: 21 is weird. [reads] I don't know how you'd do it, but FF does. All the other ones I'm fine. Rossen: I didn't catch all, but it didn't sound like an objection. Does anyone object or want something different? RESOLVED: Leave spec as-is, no changes. Accept all current requirements as listed in issue. CSS UI status update -------------------- <Florian> Florian: CSS UI status update. Florian: One PR for one test with a should that passes in 1 browser. Once someone approves all except 2 tests pass in 2 implementations. I've filed bugs on those two. I'll paste in IRC. <Florian> Remaining CSS-UI Bugs on mandatory requirements with less than 2 implementations: Should viewport units still depend on scrollbar width for overflow:scroll? --------------------------------------------------------- Github: Rossen: Can anyone take this? TabAtkins: I'm here. TabAtkins: This may not be decided yet. Core of the issue is, vw and vh we specified that if you do overflow scroll on root scroller we take into account size of scrollbar so 100vw fills the visual viewport TabAtkins: FF has broken code for this, Servo isn't planning on doing it. We, Chrome, don't do it either. dbaron is asking if we can remove that so vw and vh are based on ignoring scrollbar. My original obj is that destroyed usefulness of these and we decided it would default to no scrollbar size. TabAtkins: After we thought more for layout you don't need...I don't think many if any vw cases need 100 to be exactly the right size. You can use flexbox or gird for similar or better. For other things with viewport limits such as scaling fonts, they're fine with a little off. TabAtkins: I could be convinced that vw are lower fidelity. fantasai: I'd ask around a bit more. I can imagine wanting something to fill the viewport when you click. Doing layout of sizing of tables if they're too big to wrap them in their own scrollbar. I can see cases. TabAtkins: I'd like to see examples that aren't solved in other ways. I should look at the table case again. smfr: The author of the webkit blog came asking about this He wanted his viewport to be full bleed and 100 vw was triggering full scrollbars. smfr: This is only an issue for always on scrollbars. TabAtkins: I suspect that's why it didn't make it into webkit and then chrome inherited that code. TabAtkins: You seem to be arguing we should keep spec as-is so it can respond to scrollbars? smfr: Not necessarily. Independently we should think of ways to solve this. fantasai: We should solve it with these units. If we don't how do we fix this? Another unit? Rossen: fwiw we don't support in edge or ie either. I'm in support of what TabAtkins said and his rationale. At the same time I sympathize with fantasai were if we're going to have units to enable this, this is the unit. Rossen: Sounds to me like none of the impl have it and the only one with it wants to drop and it's broken. If we allow scrollbar styling that would have more severe effects for how we resolve scrollbar width. What are we doing. Rossen: Options are vw always resolved to full viewport ignoring scrollbars. For most scenarios you know how big the viewport is and if you care about scrollbars you can do calc and subtract some pixels. myles: You can do better with dino's proposal from the last f2f. One of those variables can be the scrollbar width. Rossen: Even better. Love it. That's a great option once we have it. Rossen: Those are the options I see, what do we do? myles: Sounds like there's agreement to drop. <fantasai> :( Rossen: Agreed. Obj? <fremy> fine with dropping RESOLVED: Drop the requirement to subtract scrollbar size from vh/vw units for overflow scroll. myles: Can we do #5 first? font-feature-settings property should be reset by font shorthand ---------------------------------------------------------------- Github: many: thought we resolved that <fantasai> Rossen: It was agenda+ on Aug 2 and I guess it wasn't removed. <fantasai> "- RESOLVED: All font-* properties are reset by the font shorthand, except font-presentation and font-synthesis." @font-face unicode-range and first available font ------------------------------------------------- Github: myles: fremy do you want to take this? fremy: Basically one dev on our team impl unicode range for font face and realized if you want to follow spec you compute based on first available font that matches any character. So any font could be that and you need to download every font which defeats the purpose. All browsers only care about the space character. Proposal is to reflect that in spec so first available font is the one that would match the space character. fremy: Shouldn't be controversial. fantasai: I don't think intention is first font to match every character, it's any character. So if the font has that character in it. The impl seem to be using the space assuming that a font that includes any glyphs at all will at least has one for U+0020. myles: The spec says "any character" so proposal is to change to read "the space character" fremy: Correct. myles: Fine with us. TabAtkins: It implies first font that doesn't have a unicode range or has one so that doesn't mean anything how it's written. So, sure. If space is what people are relying on it's not a bad choice. Rossen: Do we have a proposal? fremy: Proposal is the first available font that would match the U+0020 (space) character Rossen: Webkit is fine it sounded like. Objection to this proposed change? myles: Not an objection, but this text is in both fonts 3 and 4 so this will go into both. fantasai: I'm not sure that is actually the issue. It seems to be a side effect. Rossen: What is the actual issue? fantasai: I think the interesting thing here is that... fantasai: The issue is talking about a font that has glyphs that don't match its unicode range so it has no glyphs that will be used, but it's used as first available font. Should that font not be used in the font list because it will never be used. fremy: Main reason is we don't want to change the font unit when we change the font. It does not depend on contents. fantasai: Question is regardless of the content you define a font that doesn't have any glyphs. The overlap is 0 glyphs. No space, no character. Should that be used for the definition and that's not clear. TabAtkins: Problem is you have to then download fonts speculatively. And that's an author error. If you say it covers a certain range we should believe you. fantasai: If that's the case and we're saying we'll base on unicode range, if we change this definition the unicode range has picked out the characters that don't use the space so you wouldn't use the test font. TabAtkins: But browsers do that. fantasai: Edge and chrome are different. TabAtkins: Blink and webkit are same. fremy: Edge doesn't support unicode range right now. When we tried to fix we ran into this. Rossen: I'm going to go back to proposed resolution and as if there are any alternative proposals and, if not, we can take that text to both fonts 3 and 4. Which means 3 resets CR. fantasai: Do we have anyone from Mozilla or results from them? Rossen: Sounds quiet. Rossen: I don't think we have anyone. fantasai: I'd suggest we get feedback. Rossen: We can resolve tentatively. Rossen: We have 3 implementations. We can take a resolution and go back if there's more evidence. fremy: On the test case FF behaves same as chrome and safari. Rossen: Objections to changing text to read "first available font that would match the U+0020 (space) character" fantasai: I'm getting different results on FF then on chrome fantasai: In FF all 3 red boxes are same height. Chrome has the middle shorter. Rossen: Linux? fantasai: Yes. fremy: On windows it's the same. If it's not Ariel then the test case doesn't work. fantasai: I think it would be good to find out what Mozilla is doing. <fantasai> I have Arial installed Rossen: Mozilla will have the ability to re-raise. In the presence of new information we can reconsider. RESOLVED: Change spec text to read first available font that would match the U+0020 (space) character. <Rossen> <Rossen> Rossen: We've over time. fantasai did have two issues ^. Please take a look so we can discuss next week. Rossen: Thank you everyone for joining. We'll talk next week.