- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Sep 2018 21:26:48 -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.
=========================================
F2F Scheduling
--------------
- RESOLVED: Mid-Year F2F will be in Toronto hosted by Mozilla the
week of June 3
- RESOLVED: Will do June 4-7, Tuesday-Friday
- RESOLVED: CSS 4-6 (Tuesday-Thursday) and Houdini 7 (Friday)
- Early Year F2F is likely the week of 25 February in Honolulu, but
this isn't completely confirmed yet.
Text Decor 4
------------
- RESOLVED: text-decoration-skip-ink only takes 2 values, none and
auto with auto being default (Issue #2818)
- RESOLVED: Add normative text that states the auto value forces the
UA to add the appropriate level of skipping (Issue #2818)
Fill-Stroke
-----------
- RESOLVED: Only accept unitless values on SVG 1.1 supported
properties with the exception of baseline-shift (Issue
#3057)
CSS UI 4
--------
- RESOLVED: Don't fix and explain why in the issue (Issue #1815:
Anything that creates a stacking context should sort in
the positioned descendants z-ordering list)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0000.html
Present:
Rossen Atanassov
Tab Atkins (IRC Only)
David Baron
Amelia Bellamy-Royds
Garrett Berg
Benjamin De Cock
Elika Etemad
Dael Jackson
Dean Jackson
Myles Maxfield
Cameron McCormack
Xidorn Quan
Melanie Richards
Alan Stearns
Fuqiao Xue
Regrets:
Tantek Çelik
Simon Fraser
Tony Graham
Geoffrey Sneddon
Lea Verou
Scribe: dael
F2F Scheduling
==============
Rossen: Let's go ahead and get going
Rossen: Hello everyone. As usual, are there any extra agenda items?
fantasai: Did we settle on F2F dates next year? I think Rachel and
Jen would like it.
Rossen: Settled on dates but not place. I was going to ask TabAtkins
who is IRC only about the first meeting of next year. He
took an action to figure out if they can host
Rossen: TabAtkins please get back to us.
<AmeliaBR> Dates on the wiki are still very -ish:
https://wiki.csswg.org/planning#upcoming-meetings
Rossen: Rachel and Jen the dates are stable
astearns: I don't think you're right. I think TabAtkins is looking
at 2 weeks in Feb.
<TabAtkins> As mentioned earlier today, I'm in discussion with the
Moana Surfrider hotel right now. Plan is last week of
Feb; 90% likely. 10% chance of 3rd week instead.
astearns: Dates for middle meeting we're waiting on figuring out
when CSS Day will happen. That was finalized today
Rossen: I stand corrected. Only stable meeting is TPAC next year
Rossen: [reads TabAtkins]
Rossen: Sounds like last week of Feb in Honolulu...90% is high
likelihood. Let's communicate this with people as they start
scheduling.
florian: Don't buy tickets but keep room
dbaron: May/June- I had the room in Toronto reserved for 2 weeks,
May 27-31 or June 3-7
dbaron: CSS Day, we were worried it would conflict with the later
week but it doesn't. CSS Day is 13th and 14th
dbaron: June 13 and 14
Rossen: Provided we're likely late Feb then probably better for late
May/early June. I would prefer June 3-7 but that's me.
dbaron: One other reason to prefer later the earlier dates are a US
holiday.
dbaron: I don't think there are any Canadian holidays then
AmeliaBR: Canadian holiday is the 20th
Rossen: So settle on June 3 hosted by Mozilla?
Rossen: Objections on the week of June 3 so dbaron can release the
other and people can plan?
florian: No objection. Lots of North America travel for me, but no
objection
RESOLVED: Mid-Year F2F will be in Toronto hosted by Mozilla the week
of June 3-7
dbaron: Finalize which days are what? That's Monday-Friday
Rossen: Will need 1 day of Houdini and 3 CSS?
dbaron: That's what I'd assume.
Rossen: Start Monday? or Friday?
florian: Weren't we going to merge?
Rossen: I don't think easy to merge Houdini and CSS, but tracks in
CSS we can.
Rossen: In last 3 meetings even with merging we've finished the
agenda or couldn't finish.
florian: Okay.
Rossen: We'll have plenty to work on.
fantasai: Prefer later half.
Rossen: Tues-Fri?
fantasai: Yeah
Rossen: Anyone opposed to that?
RESOLVED: Will Do June 4-7, Tuesday-Friday
Rossen: Tuesday Houdini and Wed-Fri CSS
Rossen: Or opposite
Rossen: In the case Houdini is shorter that can be potentially
shorter rather then starting shorter.
Rossen: So if we have Houdini at the end people may have free time
if we're short
Rossen: CSS 4-6 and Houdini 7. How does that sound?
RESOLVED: CSS 4-6 and Houdini 7
Rossen: Back to February.
Rossen: It will be likely last week of February. I don't think we
can get firmer.
Rossen: I'm assuming it's week of 18th TabAtkins as last week?
florian: I think week of 25th
Rossen: Might be last full week. I don't know.
<dbaron> TabAtkins, which February week did you mean?
<TabAtkins> Yeah, planning on *last* week. 4 days in there (3 CSS, 1
houdini).
<TabAtkins> week of 25th
Rossen: Awesome. Feb 25th
<TabAtkins> not firm, don't resolve. ^_^
Rossen: Let's stop here until TabAtkins gets a firm yes.
Rossen: At least we scoped time frame.
<TabAtkins> yeah, will be soon
CSS Text Decor 4
================
Consider adding a third value (skip?) for text-decoration-skip-ink
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2818
Rossen: We wanted xidorn on the call for this.
Rossen: Who wants to summarize?
fantasai: This is text-decoration-skip. Issue is we had resolved on
'auto' and 'none' values, but there wasn't an 'on' value
fantasai: If 'auto' means platform that will in some cases not skip.
If author wants skipping being able to say on should be
separate. Otherwise auto means on and loses ability to be
auto.
fantasai: Proposal is add a new value that means please skip. I
propose skip-ink for a name.
fantasai: Reason is we might want shorthand in the future so skip
values can be combined without ambiguous.
<myles> is Xidorn here? The whole reason we're discussing this again
is to get his input
<xidorn> myles: I am
florian: sgtm. I remember related topics were discussed, tried to
look. May have missed something, but found that if we have
this it should not skip on strike-through. Agreed never
skip on strike-through
fantasai: Right
florian: Other than the shorthand conversation couldn't find
anything against this.
xidorn: myles asked for my opinion. I commented in the github and I
don't think I'm the one that raised this. Probably emilio. I
didn't have issue with 'auto' and 'none' but having
'skip-ink' is fine. As long as we don't use 'all' or
something
myles: If we wanted 3 values it would be because obey platform and
do skip-ink would be distinct.
myles: Last time we discussed Microsoft said wanted this on by
default. If yes all major platforms would have skip-ink same
as auto so if yes we don't need 3rd value
fantasai: If we have on and off as 2 values auto should be clear
what it does
myles: Happy to call it what you want
xidorn: Auto still makes sense. It can depend on how implementor
does. Implementations can decide what script to skip.
fantasai: If you skip on some and not others it's not on.
myles: That's true because typographical sense. Some scripts should
never skip.
Rossen: There are cases to optimize for not skipping. Like for
particular font size. There's diminishing return for
skipping on smaller font sizes.
Rossen: If I get xidorn that's a bit more we can take different
heuristics on when to skip but in general skipping in auto
should be skipping. Is that right xidorn?
xidorn: Yeah.
fantasai: If there's any magic under the scenes that's auto and
that's not equivalent to on. On is always and if author
wants they should get it
myles: Opposite view is typographically the on value is bad to use
and no one should use it
Rossen: And for back compat in cases...for platforms that don't have
feature impl then auto is great for default.
florian: We're trying to resolve now is that the auto can mean
different levels of skipping but not no skipping at all. Is
that what we're trying to say?
Rossen: Kind of. And for a platform that doesn't support skipping
florian: Sure, then you don't support the value so no skipping is a
fallback
fantasai: There are cases where skipping and not skipping the
heuristic of the browser might not be what the person
wants. If you have Arabic and position underline so it's
exactly with the dots then not skipping becomes and issue.
I don't think it makes sense to say the UA can decide but
the author can't
florian: The always-on auto is bad for a universal selector but if
you're smart if can be fine
AmeliaBR: Agree with fantasai there should be ability of authors to
override heuristics. Maybe one solution is to make it
clear the value is an override or force by the name. Make
it clear it's not what you should normally use.
florian: I think auto and skip-ink are reasonable
Rossen: Let's see if can resolve on...
florian: none, auto and skip-ink
<AmeliaBR> So it would be `text-decoration-skip-ink: skip-ink` ?
<florian> AmeliaBR: yes, for the sake of when we have a shorthand of
many different kinds of skipping
Rossen: Proposal: 3 value property which is
text-decoration-skip-ink: none|auto|skip-ink(or skip)
Rossen: Do we care about skip/skip-ink or can we ignore for now?
fantasai: I think resolve now
myles: Shouldn't be a value where browser doesn't have ability to
make your text not ugly
florian: Don't you think author might know better in some cases?
Rossen: Author doesn't know device and settings so it's hard to
predict this
Rossen: I sympathize with myles on this one
Rossen: Start with auto and none and if when this takes off and
there's a huge degree of requests for skip-ink we can add
it. Removing it is harder.
<florian> works for me. If we have two values, it should be none and
auto.
Rossen: So back to the two values none|auto with auto default
myles: Great idea. If goal is let users fix browser heuristics we'll
hear from users if heuristics are no good. Then it's a great
time to add the value
xidorn: I agree with myles. Once we have more feedback from users on
use cases we may revise even differently then three keywords.
Rossen: Objections to resolve text-decoration-skip-ink only takes 2
values, none and auto with auto being default
RESOLVED: text-decoration-skip-ink only takes 2 values, none and
auto with auto being default
florian: Do we try and craft spec wording to mean that auto is for
typographic smart, but not do nothing. Not supporting we
don't need to take into definition of property
<AmeliaBR> Current definition is `auto`: UA should skip over where
glyphs are drawn
Rossen: Levels of not supporting. You support it but for some
devices you want this offer for battery.
florian: If you use @supports text-decoration-skip-ink: auto can you
expect some level of skipping?
Rossen: I think answer should be yes.
Rossen: myles?
myles: Auto is meant to let browsers have freedom. Spec can describe
freedom
florian: Freedom, but not to not skip at all.
myles: That's fair.
fantasai: Needs to be clear. Currently initial value means you can
not skip. If we say that's not possible we should be
explicit about that
myles: My thought is if Microsoft thinks this is right we can put it
in spec
Rossen: Once we have support for the property having it on by
default is the path forward. We would support that
Rossen: Additional resolution to make those edits?
Rossen: Objections to adding normative text that states the auto
value forces the UA to add the appropriate level of skipping?
RESOLVED: Add normative text that states the auto value forces the
UA to add the appropriate level of skipping
Fill-Stroke
===========
stroke-width and stroke-dasharray accept numbers
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3057
AmeliaBR: This is broader then the stroke properties. Background-
SVG1 properties were defined in such a way that length
data type was extended to allow unitless numbers as length
AmeliaBR: Causes complications. SVG2 we changed so that things were
explicit that value for properties from SVG1 that accepted
unitless # as length is now explicit in syntax
AmeliaBR: Found a couple cases not properly updated including
stroke-width.
AmeliaBR: eric did a review
<AmeliaBR> https://docs.google.com/spreadsheets/d/1HRzb_-S28xq7GqYKhHbMP2YQlqWLvOWSS_twLXy-I40/edit?usp=sharing
AmeliaBR: Spreadsheet of which properties accept unitless numbers ^
AmeliaBR: In addition to stroke-width and stroke-dasharray which is
a spec error there is also baseline-shift and all the new
SVG geometry properties. Blink and webkit accept unitless
numbers on those
AmeliaBR: Because it's a general CSS syntax issue wanted to bring it
to the full WG
fantasai: This was a significant point of contention in the past
where CSS said we need length and SVG said we want
unitless. I think before there was a compromise and I
don't remember it. I think CSS properties taking a
unitless length and treating it as px shouldn't have
happened.
AmeliaBR: You think treat as only for legacy and don't do it in any
new properties
fantasai: Yes
AmeliaBR: That would affect geometry prop.
AmeliaBR: Compromise is special parsing rules in presentation
attribute forms where at parse unitless upgraded to length
with px. Because that we can do things where CSS needs a
unit
<TabAtkins> We've got a <quirky-length> production (defined in
Quirks spec) for handling "unitless px lengths".
heycam: We already have a bunch of examples were presentation
attribute accepts and CSS properties need a unit so CSS
properties never got a unitless number. I think it's
reasonable to not extend any other CSS properties to accept
plain numbers in the property and just leave it as the
properties needed for SVG, allowing those for numbers
heycam: Not allow for anything like geometry
myles: Aside from web compat this is a fine direction
Rossen: Add to the discussion what TabAtkins put in IRC.
<quirky-length> for Quirks mode does support unitless for
length. I'm in favor of not spreading this to other
properties or modes
Rossen: We prefer keep attributes the way they are and all CSS
properties to continue to support lengths as they do today
AmeliaBR: We do have SVG1 properties where there is webcompat need
to support. Plan for SVG was to limit to the ones from
SVG1. Somehow this slipped through blink and webkit
implementation for geometry properties
AmeliaBR: baseline-shift is the other complication. Significantly
redefined in CSS, though originally in SVG1. Not sure if
worth switching to more CSS compat syntax or keep it with
SVG1 syntax
fantasai: Web compat question. If there's no content dependency we
should eliminate. If there's content that depends on
unitless number things in CSS properties it needs to be
incorporated in.
<AmeliaBR> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/baseline-shift/
AmeliaBR: Little used property outside of certain SVG editors. It's
showing up once in Edge's scan with unitless
fantasai: Then we should eliminate this parsing quirk
heycam: And I guess that's what spec required. Referencing CSS text
already doesn't have unitless number
fantasai: Need to update stroke, can you tag the fill-stroke spec?
AmeliaBR: Yeah
AmeliaBR: Proposal: Unitless number as an alternative to length will
only be accepted in those SVG properties that were defined
as properties in SVG1.1 except for baseline-shift
fantasai: Accept for those with a webcompat constraint is what I
would say.
Rossen: Objections?
Rossen: Unitless number as an alternative to length will only be
accepted in those SVG properties that were defined as
properties in SVG1.1 except for baseline-shift and those
that have a web-compat constraint
fantasai: I think it's: Unitless numbers quirk is limited to SVG1.1
properties where there's a webcompat constraint requiring
it. Required for stroke-width and stroke-dasharray. Will
not support for baseline-shift
dbaron: Saying 'quirk' is dangerous because it sounds like it's in
quirks mode only
<AmeliaBR> Revised proposal: Unitless number as an alternative to
length will only be accepted in those SVG properties
where there is a webcompat need. Specifically:
stroke-width, stroke-dasharray, stroke-dashoffset will
accept it; baseline-shift won't.
heycam: Looking through the SVG1.1 property list and those that
don't have a CSS property only other is stroke-dashoffset
heycam: If people have data on if stroke-dashoffset is needed...but
given there's only 3 properties maybe we can be clear about
the set
AmeliaBR: There's lots of properties where we do accept it but we
updated syntax to say they accept number
Rossen: Agree with what you're saying heycam but we'll have to
discuss again. We'll either add or remove properties with
more data
AmeliaBR: This is one reason why don't want to make it about web
compat but rather that they were defined in SVG1.1
Rossen: Yes, but we don't want to broadly say all, we want to limit
the scope.
Rossen: We can do what heycam said where we only say 3 properties
accept or we can go with based on data we'll add and we know
for sure about these properties.
Rossen: Preference?
fantasai: I'd resolve on principle and then refine list. I think
we'll include a lot of SVG1.1 Having this number parsing
issue limits the future so that's why we want to limit
where this is done. Especially where we've taken SVG
properties and broadened them. It will be somewhat
arbitrary. Webcompat is tightest we can pull the string
dbaron: I don't want to resolve on a principle that requires an impl
to experiment with removing something that's interoperable
in order to demonstrate webcompat problems. I think if
everyone does this for a property we should spec it that way.
AmeliaBR: I was misleading by saying a lot of properties. I guess it
really is only the ones we've talked about. Lots of
attributes using CSS syntax made it seem a wider issue
Rossen: Proposal: Only accept unitless values on SVG 1.1 supported
properties with the exception of baseline-shift
RESOLVED: Only accept unitless values on SVG 1.1 supported
properties with the exception of baseline-shift
CSS UI 4
========
Anything that creates a stacking context should sort in the positioned
descendants z-ordering list
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1815
florian: There is a value that corresponds to the behavior everyone
has. We say if you start selection before element and end
after then selection must include the element in the
middle. Someone suggested we should exclude it. So content
before and after, but not contained element.
florian: As far as I can tell this is not what people impl. Only FF
supports multi-part selections. However the none value is a
middle ground. Browsers that support multi-part must have 2
part selection and others must make one big selection. but
they can exclude the middle part.
florian: That's for none and corresponds to what people impl.
Doesn't correspond for contain, but we could do it.
fantasai: What's most reasonable for use case?
florian: No use case mentioned. We are mostly interop
myles: No use case plus interop seems clear
florian: This is from Google. Anyone know why?
fantasai: You can say we're leaning to not because interop and we
have no use cases. If they come back with use cases we can
reconsider
Rossen: Proposal: resolve no fix and explain why in the issue
RESOLVED: Don't fix and explain why in the issue
Rossen: We'll move the remaining issue to next week. Thanks everyone
Received on Thursday, 6 September 2018 01:28:14 UTC