- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Sep 2017 08:08:45 -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.
=========================================
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:
https://github.com/w3c/csswg-drafts/issues/1770 ).
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: https://lists.w3.org/Archives/Public/www-style/2017Sep/0007.html
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> https://github.com/w3c/csswg-drafts/issues/1777
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> https://github.com/w3c/csswg-drafts/issues/309
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> https://wiki.csswg.org/planning/berlin-2018
Rossen: If so, please add to planning wiki.
Review of the optional test failures in the css-ui-3 test suite
---------------------------------------------------------------
Scribe: dael
Github: https://github.com/w3c/csswg-drafts/issues/1770
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> https://github.com/w3c/web-platform-tests/pull/6934
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: https://pastebin.com/vu1CCTMv
Should viewport units still depend on scrollbar width for
overflow:scroll?
---------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1766
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: https://github.com/w3c/csswg-drafts/issues/1349
many: thought we resolved that
<fantasai> https://lists.w3.org/Archives/Public/www-style/2017Aug/0042.html
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: https://github.com/w3c/csswg-drafts/issues/1765
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> https://github.com/w3c/csswg-drafts/issues/1777
<Rossen> https://github.com/w3c/csswg-drafts/issues/309
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.
Received on Thursday, 7 September 2017 12:09:43 UTC