- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Mar 2019 20:17:29 +0100
- 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.
=========================================
Reviewing PRs
-------------
- The queue of PRs that need review has gotten long so group members
were asked to review PRs and reduce the queue.
TPAC 2019
---------
- The CSSWG has requested to meet on Monday and Tuesday of TPAC. An
email will be sent to determine if a Houdini meeting should also
be scheduled.
Scroll Snap
-----------
- RESOLVED: Accept the edits for
https://github.com/w3c/csswg-drafts/issues/3740
(Clarify that scroll-padding and scroll-snap-type on
root propagate to viewport)
CSS Pseudo 4
------------
- RESOLVED: text-shadow:none in UA style sheets are override-able by
authors for selection (Issue #3605: Specify better
handling of text shadows for ::selection)
CSS Overflow
------------
- RESOLVED: Accept adding -webkit-discard value to continue
properties to represent line-clamp that only applies to
webkit flex boxes and make it shorthand expansion for
-webkit-line-clamp (Issue #2847: Convert
-webkit-line-clamp alias requirement into a spec issue)
- RESOLVED: Accept the edits in
https://github.com/w3c/csswg-drafts/issues/2905
(Allowing (or not) alternate ellipsis behavior for
block-overflow)
CSS Inline
----------
- There was no agreement about changing the used value for
line-height:normal to return the keyword 'normal' instead of a
value (Issue #3749:A question for the procedure to compute the
used value of "line-height").
- Chromium returns the keyword but Webkit and Firefox return a
value. The value returned may not be correct because
line-height:normal calculates per fragment of the element and
any value returned would not be able to capture the multiple
possible values of 'normal'.
- Given that Webkit and Firefox return the value the concern is that
there is content on the web depending on this value. People
planned to look more into the possible implications of the
proposed change.
- Discussion will continue on the github issue and this will be
added to next week's agenda to try and reach a conclusion.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Mar/0004.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Dave Cramer
Elika Etemad
Javier Fernandez
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Nigel Megitt
Anton Prowse
Florian Rivoal
Jen Simmons
Lea Verou
Greg Whitworth
Regrets:
Dirk Schulze
Scribe: dael
Rossen: Good morning and good evening. Happy first day of spring
* AmeliaBR or first day of autumn…
Rossen: Wanted to start with a call for additional agenda items you
want to add or changes?
Reviewing PRs
=============
Rossen: Before we get going I wanted to draw your attention to PRs
open against our draft repo
Rossen: There are a number of people doing a great job at making
changes and updating specs and drafts, but we also need
review so we can get merged
Rossen: Please help out and drain the queue
TPAC 2019
=========
Rossen: Next extra topic.
Rossen: I have gone ahead and signed us up for Mon and Tues of TPAC
which is in Japan Sept 16-21. We meet Sept 16 & 17 which is
Monday and Tuesday
Rossen: Question to that topic, should we have a Houdini meeting?
Rossen: I can book half a day or a day room on Thursday, but I need
a signal on if needed
<AmeliaBR> FYI, the SVG group has asked for meeting on the Thursday
Rossen: Think about it and I'll start an email thread on private list
Scroll Snap
===========
Clarify that scroll-padding and scroll-snap-type on root propagate to
viewport
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3740
Rossen: fantasai are you on?
fantasai: Yeah. I think it was assumed by all of us scroll snap
property applied to viewport but we don't say so in the
spec. I copied overflow draft and scrollbar draft to say
propagates from root but not body element
<fantasai> https://github.com/w3c/csswg-drafts/commit/b5afa1086cf344046ea87013f0c48b3800eaacd7
fantasai: Edits ^
florian: The way overflow propagates from body is weird. Not doing
weird is good, but isn't a consistent good so can set both
on body and the property together
fantasai: Could set both on root instead. Don't propagate scrollbar
width or color
AmeliaBR: I haven't looked at edits, is it clear wording? Author
expectation is if overflow on the body does scrollbars I'd
expect that's where I put scroll snap. Maybe educate
authors how that's weird and problematic but it's an extra
level of lack of intuition
Rossen: Agree. If body propagates background color and overflow prop
back to viewport and canvas it would make sense to have
scroll property. But as fantasai pointed out we want to stop
all that legacy quirk behavior expansion of properties.
Rossen: Couple ways forward- continue adding them because this is
what authors expect. Or not do it and teach people by making
explicit test cases and educational material and that they
will face that it doesn't work, ideally find and article and
see body stuff is a quirk there to keep legacy web working
but don't do that
Rossen: Kinda more leaning not add to body css
Rossen: I do agree it makes sense to be explicitly pointed out apply
to viewport
AmeliaBR: Skimming edits it looks quite sensible. There is a note
about not propagating from body but I don't know if we
need to make that more author focused
florian: I guess that's enough. fantasai mentioned this is also the
case for scrollbar width. If we keep new stuff consistent
and none work on body we have a fighting chance of getting
people to set on root. I'm okay with edit as is if we make
that the policy we follow
Rossen: Other opinions?
Rossen: Sounds like we're okay with the edits where scrollsnap
properties propagate from root. Objections to accepting
edits?
RESOLVED: Accept the edits for https://github.com/w3c/csswg-drafts/issues/3740
CSS Pseudo 4
============
Specify better handling of text shadows for ::selection
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3605
Rossen: Discussed once and the discussion was cut short. Who wants
to resume that discussion and catch up the group?
fantasai: The question was really the text shadows spec on an
element and highlight element with background should text
shadows show through
Rossen: On element or on text?
fantasai: On text.
fantasai: Shadow is set on the element on DOM and you have
highlighted that element. Are you seeing the shadow or
not? The highlight has a background and generally paint
text over background but that means text might not visible
because have changed both text and background color and
there's no assurance shadow color is appropriate to
preserve contrast
fantasai: Highlight colors come from elsewhere then dom element. I
think it makes most sense to suppress text shadow unless
author explicitly says what it should be
florian: If an author explicitly considers shadows so they'll set it
to the right thing. Most of the time they won't think about
it and inherit and it probably will be wrong. I agree
AmeliaBR: Complication I brought up last time is that there's no
easy way to just say use whatever text shadow is on
surrounding because weirdness of how selection inherits.
Not just suppressing by default, but taking away option
for author to say keep text shadow as is
florian: Could do custom properties but that's a bit of a cudgel
AmeliaBR: In contrast if we leave it as is which is keep drawing
text shadow it's easy for author to override with
text-shadow:none
fantasai: But most won't
florian: Robust by default is important
fantasai: I think cases where author will want text shadows and
showing when highlighting will be less common then when
author sets text shadow and not highlight or setting
highlight colors and not thinking about it when setting
shadows
AmeliaBR: That's true. I think as far as whether text shadow looks
good or bad is 50/50
fantasai: Not good or bad, this is about readable. This is a11y
AmeliaBR: Reasonable to say default selection remove text shadows.
Not reasonable to override user set selection styles. But
if others disagree I've made my statement and won't object
nigel: Makes sense. If have default selection color for background
and foreground they apply and all the defaults make it
readable that's fine. If someone overrides text shadow for
selection they should look out. Other is if they override
text shadow for selections we try and push a color change,
but that's a pain to try and do to only modify the color if
it's overwritten
fantasai: I want to keep this not crazy complicated. We should try
and use cascade as much as possible
<nigel> +1 to not crazy complicated!
fantasai: Probably simplest is add a text-shadow:none to UA default
style sheet. If you want more complicated we can consider
AmeliaBR: Do have some complications since default UA sets
background and foreground but if author sets either,
neither value applies. Set text shadow in same group where
if author sets any we ignore whole set of UA rules
<bradk> +1 to just being in UA stylesheet. Allowing footguns is
better than being author-nanny.
fantasai: Could do that. Additional weirdness. Not concerned with
just UA but that author that sets selection is not the one
that puts text shadow on this specific heading. They just
want the header to look good on the page when it loads but
not in this case. Will be difficult if want text shadow to
show up in selection but not impossible. We should bias
toward readable page
AmeliaBR: Sure. As you say selections are about a11y not fancy
styling
AmeliaBR: So you are saying UA style sheet would have
text-shadow:none but if author sets it in their selection
styles that's fine?
fantasai: Yes
AmeliaBR: Okay
Rossen: Nearing consensus. Any other feedback on this or is everyone
getting around the same page. text-shadow:none in UA style
sheets are override-able by authors for selection
Rossen: Objections?
RESOLVED: text-shadow:none in UA style sheets are override-able by
authors for selection
CSS Overflow
============
Convert -webkit-line-clamp alias requirement into a spec issue
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2847
florian: Talked at F2F. Had follow up meeting afterwards.
florian: We went through what was needed for supporting
-webkit-line-clamp in contrast with spec. Concluded can't
be a straight alias because there are quirks we don't want
to propagate.
florian: Defined a shorthanding mechanism, added to the spec to the
satisfaction of all present.
<florian> https://github.com/w3c/csswg-drafts/commit/2cc319448f4732c127fa43213ce7cf7d96de04ac
florian: Commit ^
florian: Given non-prefixed line-clamp works for some properties the
prefixed version also would but setting weird values for
weird behavior. Other than necessary bits it's all same.
florian: I think people who cared were in the room and agreed, but
if anyone else wants to say something...
AmeliaBR: You could explain all the weirdness in terms of longhand
it's just that prefix sets different defaults compared to
regular version?
florian: Most are normal, but the one that takes discard takes a new
-webkit-discard value
fantasai: There's a lot of weirdness in -webkit-line-clamp and spec
makes most of the weird go away. There's one that would
not be web compat where line-clamp is all boxes and
-webkit-line-clamp applies to old style flex container and
propagates to flex items. That's a little weird. Other
differences between spec and webkit like where ellipsis
goes we don't think are issues
fantasai: This is because they're properties people are complaining
about and working around already
Rossen: Okay. Not because there will be no issues for rendering but
because people expect better behavior so expectation people
will adapt
fantasai: Expectation is it won't cause pages to break in major ways
florian: Small differences that are mostly improvements
Rossen: I would only worry if changing line height in significant
way. Some sites with tight layout like news sites they
produce containers that have weird overlap and looks odd
with as little as 1px line height difference
Rossen: If this is mostly an improvement we'll have to see how it
goes
florian: Mozilla has looked and to the extent they found sites using
it this won't be a problem. Won't know for sure until we
try.
Rossen: I think overall approach and alignment between legacy and
new sounds great
Rossen: Any additional thoughts or feedback before we resolve to
move forward with proposal in
https://github.com/w3c/csswg-drafts/commit/2cc319448f4732c127fa43213ce7cf7d96de04ac
?
Rossen: florian what is summary of resolution?
florian: Accept the edit that's in the spec.
fantasai: Accept adding -webkit-discard value to continue prop to
rep line-clamp that only applies to webkit flex boxes and
make it shorthand expansion for -webkit-line-clamp
RESOLVED: Accept adding -webkit-discard value to continue properties
to represent line-clamp that only applies to webkit flex
boxes and make it shorthand expansion for
-webkit-line-clamp
Allowing (or not) alternate ellipsis behavior for block-overflow
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2905
florian: Mats complained about previous state of spec and way we
insert alternate ellipsis. One problem was spec defined
that we insert ellipsis text as normal run of text on last
line. Unfortunate side effect of that is it could grow line
height it could introduce loops
florian: Left undefined how to break the loop. But because this is
hard we included a may that if you can't solve that you can
just do it at paint time and not effect layout
florian: Complaint is that main logic is undefined and alter log
available.
florian: Edited into spec is a solution for both. Main is simplified
and may removed. Still insert at layout but text inserted
has line-height 0 so it removes content due to
fragmentation so if you remove a tall inline it gets
smaller, but it can't shrink the line. Could change, but no
loops. Therefore don't need simpler alternative as a may
florian: Request is approve edits in place in the spec
florian: This too was discussed in after F2F meeting
Rossen: I'm assuming Mats is okay with edits?
florian: Mats wasn't looped in. Had previous resolution half a year
ago to go in this direction but specifics not written until
recently. Since heycam is running with this that's whose
feedback we focused on
Rossen: Makes sense
Rossen: Any additional feedback before resolve to accept the edits?
Rossen: Objections to accept the edits?
RESOLVED: Accept the edits in https://github.com/w3c/csswg-drafts/issues/2905
florian: Thank you
CSS Inline
==========
A question for the procedure to compute the used value of
"line-height"
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3749
dbaron: Isn't this talking about value for gCS which is another term?
florian: Resolved value, you're right
florian: This is raised by chromium because cssom spec says resolved
value is used value and they were trying to find a way to
return number of pixels but line-height:normal doesn't
resolve into a single height
florian: line-height has 2 sets of values. All values other than
normal resolve to a single height, normal resolves in
different value per text run. You ask for gCS for element,
not for text run so we can't return
dbaron: Chromium returns normal as a keyword?
florian: Yes
nigel: Reviewed this and was confused by spec with resolved value
because line-height just takes you to css2 line height and
doesn't way what resolved value is for line-height. Doesn't
seem spec says what it should be
florian: Kind of does depending on how you read it. For line-height
it's in the sublist where it says resolved value is used
value. It's unclear for line-height:normal that can be
returned
nigel: I think you're explaining how to read the sublists. That
probably needs reformatting. Thank you
florian: line-height:normal can only be preserved as normal if we
want something meaningful
nigel: You want to move line-height to computed value category?
florian: Not necessarily. There is another subgrouping of values for
line-height: length and percent are turned into absolute
values at computed but numbers are numbers and computed. At
used numbers become lengths. Do same thing but inherit
differently
florian: Normal, regardless of computed or used time can't become a
single number.
AmeliaBR: Are you asking us to say normal exists at used value time
or are you asking to create a special category to figure
out resolve value for line-height being normal if computed
value is normal?
florian: I think difference between those 2 is editorial because
used can't be observed unless we say gCS returns it. In
terms of what's observable it's same. I don't care how we
phrase, just don't turn normal into a number
nigel: Happy to have a unitless number for line-height converted to
a used value?
florian: Unitless stay as unitless at computed. At used value I
suppose it's categorized that way because web compat
requires it. That's usually why properties whose resolved
is mapped to used value instead of computed mapping. I'm
not trying to change values other than normal, want to
avoid normal being cast to a length when it can't be
florian: Who is CSSOM editor?
florian: Emilio
Rossen: Right
Rossen: You can make a PR and emilio can merge
florian: Happy with a resolution we keep normal and work with emilio
on phrasing
nigel: You talked about what is returned when it's normal. Do we
have data on UAs for unitless numbers?
florian: I have not looked. I assumed spec wasn't wrong, but can
look separately.
AmeliaBR: Working on a test case. Chrome does what florian is asking
for
<AmeliaBR> Test case: https://codepen.io/AmeliaBR/pen/bZmgqJ?editors=1011
myles: We're talking about return on gCS?
florian: Yes
myles: That's scary, line-height has been around forever
florian: Changing spec to match chrome
myles: FF and webkit return pixel value
florian: Can you define what value you return?
myles: This issue has a snippit of code that describes how we compute
florian: [looks at it]
florian: I'm not terrified about web compat given chrome does it
already
myles: On the other hand FF and webkit don't return keyword
florian: You think this is kind of code websites could have
specialized on to deal with browser difference?
Rossen: I think the assertion made was line-height has been there
forever and many sites depend on it. Predicting what will be
broken or not is difficult. I agree Chrome market share
probably dictates some behavior on desktop, but not sure on
mobile
florian: I wouldn't say chrome dictates behavior, but chrome doing
it this way is strong evidence that doing it this was
doesn't break the web
florian: And length value you would return doesn't match layout so
why return that?
fantasai: Also computed value is the normal keyword. We use used
value where there's a compat reason to do so
myles: I won't object but we wouldn't be able to make this change
without more research into how this would break
Rossen: Can always defer to next week if you want to get some time
and come back to use myles
florian: I guess...the question is what's alternative? Spec being
wrong is bad. Chrome returning a length that's unrelated to
actually used length seems weird
AmeliaBR: Is it really wrong? It's based on font of element. The
text spans inside might have different fonts but doesn't
the parent element have a line height even if it's not
used for anything?
<fantasai> AmeliaBR, the line height for normal is calculated per
fragment, not per element
florian: From the code snippit I don't know which font metrics we're
talking about
myles: Primary
florian: Which metric of that font?
myles: Ascent+descent+line gap
florian: I'm not good enough at fonts to phase this, but I believe
in the past we discussed there isn't a single ascent or
descent and the one we use aren't always the same
myles: For a particular font there are different values, but every
browser picks one and uses it throughout. At least for the
browsers I know
florian: You return line height of the strut?
myles: I don't know the term strut
florian: Strut is the css2.1 term for the thing that keeps the line
height from collapsing to 0
myles: Sounds right to me
fantasai: Line height used value is calculated per fragment of
element so it's not necessarily the line height from first
available font. Can also include fallback
myles: Correct, also includes things like child elements
fantasai: That's about height on line-box. There's difference
between line-box and fragment we're looking at. For an
element when calc line-height which is what's used when
calc height of linebox in most cases it's definite nmber,
but varies by fragment with normal
fantasai: The position of that length on the line is used in
combination with other elements on the line to get the
line box. We're trying to calc the line-height value that
factors into line box calc and that varies by fragment if
you have normal. You can't get that answer w/o doing layout
florian: I guess this boils down to that number from webkit isn't
entirely meaningless, but if we're saying this is the used
value it actually isn't
fantasai: Example: have line-height:normal and all text is using
second font in list that's what would set the line height,
but you'd return the first font. Given the intention of
gCS is reach the computed value and we don't have a web
compat reason to not it seems to me returning normal makes
a lot of sense.
Rossen: We're at the top of the hour. I don't want to force a
resolution. What's captured is compelling enough for WK and
FF team to noodle on this for a week and we'll put it in
next week's agenda.
<dbaron> I think there's value in allowing the discussion to proceed
a little further in the issue before bringing it to the
call; might be more likely to take less than 20 minutes.
florian: Sounds reasonable.
Received on Wednesday, 20 March 2019 19:18:23 UTC