- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Feb 2018 19:55:42 -0500
- 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 Multicol
------------
- RESOLVED: column-gap: normal computed value returns normal
- There were three options available for Issue #2309 (Column rules
should only be drawn to the height of the column contents)
1) make a user control so people can explicitly control height
of column rules to be that of the content height or the
multicol height
2) Stay with current spec which suggests height of column rules
is the same as the multicol element height
3) Height of the column rule is based on height of the content
of the multi-height
Fonts 4
-------
- RESOLVED: No change for issue #2304 (font-variant-emoji: Consider
broadening to all "color fonts" use-cases, not just
emoji PPCP)
CSS Backgrounds
---------------
- RESOLVED: Switch the order to match current implementations on
issue #2305 (Change canonical serialization for
box-shadow)
CSS Values
----------
- RESOLVED: Accept the proposal in #2337 (calc() should round when
it's used as an <integer>)
CSS Typed OM
------------
- TabAtkins plans on making edits for Houdini issue #716 (Trim
CSSResourceValue and subclasses to opaque objects for this
level, punt rest to level 2) this week so requested anyone
interested add their thoughts to the github.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Tony Graham
Dael Jackson
Brad Kemper
Vladimir Levantovsky
Peter Linss
Anton Prowse
Liam Quin
Manuel Rego
François Remy
Melanie Richards
Alan Stearns
Eric Willigers
Regrets:
Elika Etemad
Florian Rivoal
Lea Verou
Sergio Villar Senin
Greg Whitworth
Scribe: dael
Reminders and Agenda
====================
Rossen: It is a few minutes past.
Rossen: As usual, any extra agenda items?
Rossen: I had a couple of quick items.
Rossen: First is a reminder that if you haven't booked your Berlin
travel it's time to do it now.
Rossen: Other topic which is related to the F2F/TYPO is the CSSWG
talk/presentation/whatever.
Rossen: Correct me, but my understanding is we have about an hour.
There was a request on the private list for ideas/topics.
Rossen: Please take a look. Make suggestions. Volunteer.
Rossen: I proposed a quick structure but I'm just throwing ideas out
there.
Rossen: I'm expecting people to suggest other things.
Rossen: Please look.
Rossen: The other thing is we have fallen back on our spec rec push.
Rossen: We want to resume the focus on the spec getting close to pr
and rec.
Rossen: I started/resumed the private list thread. I won't take time
on the call to review but please take a look and update if
you have any actions or tasks.
Rossen: Let's try to move things forward.
Rossen: We need myles for fonts so we'll postpone until he joins.
Border width rounding clarification
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2114
Rossen: Is dbaron or fantasai able to summarize?
dbaron: I could attempt to, but I'm not sure why it's agenda+. It's
a long issue and I"m not sure what fantasai wanted group
opinion on.
Rossen: I'm fine postponing until fantasai joines the call. We can
ask her.
CSS Multicol
============
Gutter properties computed value
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2294
Rossen: Summary is we have column-gap:normal value return as 0px for
anything that's not a multi-column and 'normal' if it is a
multicol
Rossen: Issue raised by Igalia that getComputedStyle where all
browsers but edge return normal. Proposal was to make
computed value to be normal everywhere.
Rossen: The consensus on the issue seems to be normal computes as
normal.
Rossen: So I'm looking for feedback or other idea.
Rossen: Should we just adopt proposed resolution or not change?
Rossen: Does anyone care about this who is on the call?
tantek: Only thing I'd add is just +1 to Mats.
Rossen: What he's saying is common sense of not making style depend
on layout and not make properties depend on other properties
which is one of our guiding rules and I fully agree. Just
curious on this issue.
rachelandrew: I agree with fantasai that people who care will
specify anyway so if impl are happy to go with normal
that makes sense.
Rossen: I don't think we'll have a problem changing to normal. I
think we're the only implementation that returns 0. I'm
assuming given all other implementors return normal there
shouldn't be a compat risk for us, or at least minimal.
tantek: Looking quick I didn't see a simple dom test to check
current impl. I'd be curious to try it in other browsers to
see if there is anything consensus-wise.
Rossen: Right.
tantek: Can I request that before we resolve? To add a test to get
information?
Rossen: Absolutely. We don't have to resolve today. fantasai and
florian are out. They and Sergio are active. I'm just
looking for progress.
Rossen: Sounds like we want examples and test cases to eval other
impl.
tantek: At least to inform the decision better. Sounds like rough
consensus but it's based on theoretical purity.
tantek: I'd like more concrete data.
rego: There's WPT tests for this. That's why I realized Edge isn't
returning normal and that's when I checked the specs.
tantek: Can you add a link to it?
<rego> http://w3c-test.org/css/css-align/gaps/column-gap-parsing-001.html
rego: ^
tantek: Thanks.
<tantek> rego which of the tests?
<tantek> (of the 17)
<rego> the first one "Default column-gap is 'normal'"
<rego> in Edge it fails
<rego> I meant, it returns 0px
Rossen: I see the same behavior as rego stated in the issue. In
windows I see Edge report 0 and FF and Chrome return
'normal'.
tantek: There's 17 tests.
rego: First one is the one that fails.
Rossen: fwiw looking at IE I think we regressed this in edge
unintentionally.
Rossen: For the sake of argument this could be just a bug.
tantek: I see normal in FF & Chrome
<rego> and Safari
Rossen: Yeah. That's what I said. Normal everywhere, FF, Chrome, IE
11. Edge is only one that does 0.
tantek: Safari also.
tantek: Okay. That makes it pretty clear.
Rossen: Going back to the issue, is this something we want to punt
or do we feel there is enough understanding to resolve?
tantek: I think there's enough understanding.
tantek: If fantasai or anyone else has new information we can follow
our normal procedure.
Rossen: fantasai supports normal to normal in the issue.
Rossen: Objections to resolving that column-gap: normal computed
value returns normal?
RESOLVED: column-gap: normal computed value returns normal
Column rules should only be drawn to the height of the column contents
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2309
Rossen: This came from dbaron a couple weeks ago and added by
rachelandrew.
<Rossen> test case:
https://w3c-test.org/css/css-multicol/multicol-breaking-001.html
dbaron: There was a thing in the spec, I had been doing testing and
it didn't match FF and Chrome and didn't make sense to me.
Edge does impl what the spec says. Question is what happens
to column rules when content of columns doesn't fill the
space it could fill.
dbaron: Either because you have a multi-col with a spec width and
height unspec # col. Depending on column-fill balance|auto
you might have content in the first and second or the top of
the first. Question is where do you draw the rules.
dbaron: Spec says a full height rule between any pair with content
in them. Completely empty is no rule. THat's not what FF and
Chrome do. Last comment in GH issue I linked to a test.
dbaron: I think it...don't look in FF, look in Chrome and Edge.
Rossen: I'm assuming you're going to be fixing in FF, that's why
you're looking?
dbaron: Wait a moment...I think I've gotten things confused.
dbaron: FF has a bunch of other bugs here that are messing this up
in weird ways.
dbaron: What this test shows is a multicol inside another.
dbaron: Spec calls for the purple column to go all the way tot the
bottom in the second column. FF & Chrome only take it to the
bottom of the content.
Rossen: What is wrong with this? I believe what the spec suggests in
terms of behavior as well as what IE/Edge/Presto impl for
column rules makes a lot of sense.
Rossen: Are you suggesting only make app column rules only draw to
content type?
dbaron: That's what I'm suggesting. I made that suggestion before
testing edge so I made it before realizing current browsers
did the thing the spec said.
dauwhe: I prefer Chrome to the spec
dauwhe: Purely as a visual thing, having the rule extend past empty
space strikes me as unexpected.
plinss: I think it should be an author rule. Having rules only to
content seems common, but you might want rules to go all the
way when you're doing something sophisticated. If you're
going to content you should make sure all rules are to the
same length.
dbaron: Might makes sense for balancing, but not column fill auto.
dauwhe: I agree with plinss about author control though.
<AmeliaBR> Does anyone have the current spec text? Is it really
supposed to apply to columns inside columns?
Rossen: To answer AmeliaBR, columns inside of columns brings nothing
interesting. dbaron did it for illustrative purposes to show
when the multicol itself is the content of another column
what the behavior is.
<dbaron> AmeliaBR, the spec text is quoted in the first comment of
the issue
* AmeliaBR thanks dbaron
Rossen: In this case I would have expected that...if we have content
height as the limit to column gaps, what Chrome does is the
behavior which would be compliant. And if column rules are
used to show where columns are and their height, because as
dbaron illustrates when you have a background you'll see the
heights, that looks just as silly as the other way where you
don't have the BG but you have the rule.
Rossen: I sympathize to plinss's suggestion of an author control.
Having the background & the column rules not be the same
height is pretty silly. That's my personal opinion.
Rossen: It seems strange that the two are not going hand in hand.
AmeliaBR: I brought it up because it seems browsers are consistent
with outer level being full height. It's only when you add
the inner level and how it break across multiple it's weird
Rossen: The multicol inside the top level extends all the way down.
That's why the rules are they way they are. It is visually
deceiving.
Rossen: In this case if you had max-height on the inner and height
on the outer so it stretches beyond I would expect column
rules to be the same height
<dbaron> I'd note that if you remove the .outer { column-fill:
auto } in the testcase than the thick blue rules get shorter
liam: There's a danger here that...in trying to decide based on
weird test cases. If I had spec a height explicitly I'd expect
the rule to go all the way down. Either you want a control as
plinss said or it should honor the height if you gave one.
Maybe you need to look at actual use cases.
Rossen: Now you're suggesting tie in column height and rule
properties which goes against our groups.
liam: No no, I'm asking what is user's expectation. If you have an
area with the height and column rules chances are you want the
rules all the way down. I'm supporting a property.
Rossen: I can't speak for the billions of users of the web. From a
pure layout PoV what I said is if you have column boxes with
backgrounds that extend the rules should extend the same
way. That's consistent with other properties.
<dbaron> I think this was also a case where this was implemented in
browsers *before* the current spec text existed.
Rossen: Let's see if we can narrow down this issue and get to
something actionable.
Rossen: Current proposal a 1) make a user control so people can
explicitly control height of column rules to be that of the
content height or the multicol height
Rossen: 2) Stay with current spec which suggests height of column
rules is the same as the multicol element height
Rossen: 3) Height of the column rule is based on height of the
content of the multi-height
Rossen: We can try to make a resolution or we can stop discussing
here and continue on GH. Get user feedback from designers,
come back and see what stands out.
Rossen: Preference dbaron?
dbaron: I'm fine discussing more.
Rossen: Okay.
CSS Fonts 4
===========
font-variant-emoji: Consider broadening to all "color fonts"
use-cases, not just emoji PPCP
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2304
myles: This topic was discussed a few weeks ago but a commenter
brought up new points. Because previous issue was resolved we
moved to a new issue. So just the new parts.
myles: This is a property that renders characters as if they have
variation selectors. This property sets the default so if you
don't have a selector CSS can say emoji or text style.
myles: Question was if this property should effect color fonts.
myles: Color font formats have been increasingly common. The request
was...the CSS should be able to turn those on and off.
myles: That's the background. Anything anyone wants to say before I
give an opinion?
myles: Should we allow the selector to affect regular color fonts?
myles: I haven't heard an author say they used color fonts
accidentally. Person raising this hasn't brought a case where
this is needed, just that it's easy to implement.
myles: I haven't heard an author need. Also there isn't full interop
on variation selectors and if we added more semantics it
would limit our ability to standardize. This issue is not
motivated and would hinder standardization.
<tantek> uh, turning off color (or picking different contrasts) is a
pretty accepted a11y use-case
<liam> +1 to tantek but not clear that's at the font level but at
the UA level overall
AmeliaBR: On the question of is there a use case. When it comes to
color web fonts I don't think anyone is using and wanting
to turn them of fin general. When it comes to native
emojis there is an issue where we have inconsistency as to
how to handle interaction of fill and stroke with a native
color font like and emoji.
AmeliaBR: As color fonts become more common it might be useful to
use a font consistently but turn off the color for certain
elements. But I don't have as much of a use case as I do
for the emoji.
myles: That's a good point. It is important that we should spec
interaction between fill/stroke and the color fonts.
myles: This proposal could go 2 ways. Way #1 is this would affect
font selection and you'd just turn off the color parts.
Option #2 is when you select font you skip the color. This
was about option 2 but it sounds like you're interested in 1.
myles: Main concern with turning off tables in the font file is 1)
that we don't have a precedent. 2) is if they want the color
to work it's possible using 2 of the font formats.
myles: Lastly color is part of the design of these fonts. If you
took the color out it would hamper the design and the font
would be useless. I list fonts in the issue where you can't
remove the color. It would be unfortunate for users to...it
would lead to confused users.
AmeliaBR: Many of these color fonts are shipping with fallback plain
outlines. But some aren't. If the font has a built in
monochrome fallback it seems logical to allow web page
authors a way to access it. If there is no fallback
logical is to fallback to a different font. It's hard to
integrate both into the font selection algorithm.
myles: Yeah and this is a case where the browser should be in the
business of looking at the outline and say if it should be
able to be used.
myles: And the fallback is required, there has to be a table. But
the contents may be empty or garbage.
<Rossen> +1 to what myles said
Rossen: I agree with myles. I want to see if there are any other
options or idea.
<fremy> @myles: just throwing a random idea here, how about we
render the glyph, convert to grayscale, and use this an
opacity mask on a background of the color of the "color"
property?
Rossen: From IRC I want to voice tantek's point about this being a
a11y lever. I agree with liam this shouldn't be the thing of
font selection. We normally handle high contrast etc. on a
much higher level for style or a lower level for color
inversion.
<tantek> Rossen: TBH it's both system level and app/site level. e.g.
both mobile OS's and mobile sites have "night mode"
features that alter such things
Rossen: Back to myles what do you want to do? Close no change?
myles: Right.
Rossen: Any objections or alternative proposals?
AmeliaBR: If we close no change we keep this property that will only
effect on the specific unicode characters designated as
having plain text or emoji presentation?
myles: Right
AmeliaBR: And it would effect font selection to render those
characters?
myles: It might. That's why I phrases the property as I did. In Mac
and iOS it does. I believe on every platform it might effect
font selection.
Rossen: Does that answer you AmeliaBR?
AmeliaBR: Pretty much. I still agree it would be nice to have a
toggle to turn off color font on generic text but I
realize right now use cases aren't clear.
myles: If a web author wants to turn off color font they should
remove it from the font family list.
AmeliaBR: I think we need to wait in see how things like font
variations and ways to work with existing font files. Like
people making color and monochrome and swapping between
the two. It's still hypothetical.
myles: That tech doesn't exist for any font format right now.
Rossen: Okay, objections to resolve no change?
Rossen: If there are more compelling use cases or additional
information we'll of course reconsider.
RESOLVED: No change for issue #2304
CSS Backgrounds
===============
Change canonical serialization for box-shadow
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2305
TabAtkins: Going by standard rule that default serialization should
match grammar that implies color after link but impl does
color before links. We should change grammar to match
impl.
Rossen: Looks like edits were pushed out. So only thing we need to
do is get consensus.
Rossen: Any other opinions as to why we shouldn't do this?
<dbaron> This is part of why I am not a fan of that general rule
being imposed without doing compatibility testing first...
although I think we may have rolled back the rule a bit?
<bradk> +1
<AmeliaBR> +1 to matching reality & also other properties
Rossen: Objections to switch the order to match current impl?
RESOLVED: switch the order to match current implementations
CSS Flex
========
Min-content sizing currently too smart to be web compatible?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2353
TabAtkins: I need to review this with fantasai
fremy: Then I can introduce it before next week
fremy: We tried to update Edge to follow spec for flex-basis. A lot
of websites if you spec width or height even if there isn't
content it's respected for min-content sizing.
fremy: We probably don't want to change this alone or first. Let's
discuss next week.
CSS Values
==========
calc() should round when it's used as an <integer>
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2337
TabAtkins: Basic issue, when you put an invalid number in the calc
due to range restrictions we clamp instead of call it
invalid. But we try and track int or number to reject at
parse time. If you do division it becomes a number. This
is inconvenient for typed OM. We'd like any numbers to
work out.
TabAtkins: I think the distinction for int and number I wrote in is
for convenience not a need. I propose if a prop only
takes an int and calc in non-int we round to an int. We
do this for animations already.
TabAtkins: To match how animations of int are specified at 0.5 we
round up.
Rossen: Any other opinions
Rossen: Or suggestions
<tantek> that sounds like a reasonable proposal and way of re-using
another approach of how we deal with this situation
AmeliaBR: I believe someone said edge does this?
TabAtkins: fremy said they do but they floor so he had a weak
preference for that. I think match animations is better.
AmeliaBR: Yes, doing actual rounding sounds more logical.
Rossen: Wouldn't disagree. For matching with flooring or animations
I'd also prefer animations.
Rossen: So I would be fine with TabAtkins proposal.
Rossen: Any other ideas or suggestions? If not we can resolve to
accept current.
Rossen: Objections?
RESOLVED: Accept the proposal in #2337
Schedule Wrangling
==================
Rossen: Snapshot 2018
Rossen: dbaron Should we postpone?
dbaron: I'm happy to postpone. May be better for F2F
Rossen: Next is "Percentage sizing section is kind of vague"
TabAtkins: Not 2 minutes
TabAtkins: I would like people to ask for the 3rd Houdini issue as
I'll edit that in?
CSS Typed OM
============
Trim CSSResourceValue and subclasses to opaque objects for this level,
punt rest to level 2
----------------------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/716
TabAtkins: Quick summary
TabAtkins: Hard to write a type hierarchy for JS that matches how
URLs and images work in CSS. Per our previous Tokyo
resolution in some properties we can't tell if it's an
image or a mask reference until we fetched the resource.
We can't even tell how to reflect it as a JS
TabAtkins: Proposal is the URL always readifies as a CSS URL
property. Image value is separate and used for other
image things. Anything that needs to accept an image will
accept both and if the URL is pointing to something else
it's invalid. There's some plans for a level 2 in the
issue. That's the basic issue.
<plinss> +1
TabAtkins: Simplify image handling for 2 classes and URLs are
independent of any type.
Rossen: Thanks. People who are interested please engage on that
issue.
Rossen: Reminder please look at spec rec steps and the proposed typo
topics.
Rossen: Thanks very much and we'll chat next week.
Rossen: Bye!
Received on Thursday, 1 March 2018 00:56:40 UTC