- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Jul 2019 06:21:20 -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 Color 4
-----------
- There was some confusion on what properties are included in the
resolution for issue #3804 (Resolved: add the original list of
colors from TabAtkins and fantasai as well as Field, FieldText
and ActiveText). melanierichards will draft a PR for chris to
review and add to the spec.
- RESOLVED: Take what we're calling image-p3 in our spec and rename
it to display-p3 (Issue #4056)
CSS Lists
---------
- RESOLVED: Leave undefined for now and add a note explaining why
[it's undefined] (Issue #4004: Should option/optgroup be
able to set counters?)
CSS Content
-----------
- RESOLVED: Add an 'auto' value (Issue #4074: Initial value of
quotes should be auto)
- The group was interested in discussing a more exact definition of
the new 'auto' value to try and get an interoperable value that
roundtrips.
Geometry
--------
- RESOLVED: Add back in the overflow for DOMMatrix readonly to the
DOMMatric constructor (FXTF Issue #346)
Writing Modes
-------------
- Issue #4026 (Need to define the list of calculations that require
a definite inline space) needs to be reviewed before the spec
can continue its path toward REC.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0000.html
Present:
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Elika Etemad
Dael Jackson
Dean Jackson
Chris Lilley
Cameron McCormack
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Regrets:
Rachel Andrew
Tab Atkins
Christian Biesinger
Manuel Rego Casasnovas
Christopher Schmitt
Dirk Schulze
Greg Whitworth
Scribe: dael
CSS Color 4
===========
Resolution Clarification for Issue #3804
----------------------------------------
astearns: Let's get started
<Rossen> I have one small topic - it is about this resolution here
(https://github.com/w3c/csswg-drafts/issues/3804) Did we
resolve to undeprecate ALL previously deprecated system
colors or only the set required for High Contrast + the new
ones required by Apple (smfr)
astearns: Rossen mentioned an extra topic in IRC about high contrast
and dark mode colors
astearns: Does anyone know the answer to his IRC question?
* fantasai can't see the question, has too much lag
<Rossen> Yes, I just wanted a clarification to our resolution
<Rossen> This resolution here
(https://github.com/w3c/csswg-drafts/issues/3804)
Did we resolve to undeprecate ALL previously deprecated
system colors or only the set required for High Contrast +
the new ones required by Apple (smfr)
astearns: Since no one has an answer on the phone I'll ask him to
add a comment
<astearns> Rossen: can you add a comment to that thread asking the
question?
fantasai: What was the question?
fantasai: Ah.
fantasai: Only resolve to undeprecate the ones listed in the issue,
not all
<Rossen> OK, thank you Elika. We will undeprecate the ones for High
Contrast + the ones from smfr
<fantasai> Rossen, not exactly -- we're going with the ones listed
in the resolution
astearns: Anyone else have extra items for the agenda?
fantasai: If chris is here I have publication questions
astearns: I don't see him in webex or IRC
<fantasai> https://github.com/w3c/transitions/issues/142
CSS Text
========
Clarify whether soft breaks exist at boundaries of an inline element
with `word-break:break-all`
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3897
astearns: From last week. Sounded like we wanted to make progress on
GH, but not sure if that happened.
astearns: Is there anything we can do on the call or does it need
time+comments?
[silence]
astearns: We'll come back to this
CSS Multicol
============
column-fill should behave more similarly in paginated and continuous
contexts
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-506507437
astearns: I think there was progress. Something we can resolve on
here?
dbaron: I wrote down my interpretation. What we need is Blink and WK
impl feedback
astearns: Any WK feedback on this issue?
astearns: You suggested revert but that requires Blink and WK to
agree
tantek: Looks like smfr joined IRC at least.
astearns: Are you on call smfr ?
<smfr> no but myles and dino should be
myles: I'm on, but nothing to say
myles: No comment
astearns: I'll remove agenda+ tag until we get feedback
<smfr> I would have to digest this before commenting
fantasai: Does that mean only waiting on WK?
astearns: Both would be good.
fantasai: Probably want to ask Morton.
astearns: Fair
astearns: I'll add a comment mentioning a few people to see if I can
shake anything out in GH discussion
Publishing questions
====================
astearns: I see chris is on IRC. Are you on call as well?
fantasai: Can you [chris] get display published? Other question was
about edits to css color L4 related to forced colors mode
fantasai: There was confusion about that so might be good to get
that edited in
chris: Thing with display is there were duplicate IDs
fantasai: I believe they're fixed
chris: Cool
fantasai: If not, ping me I will fix
chris: astearns did we add renaming image back to display?
astearns: On the agenda
astearns: Other question about color L4 edits?
chris: There's an open issues, is there a PR?
fantasai: I can do edits if you want
melanierichards: I can help submit a PR for this
chris: That would help, sure. Thanks.
dino: There's no GH for this?
<fantasai> https://github.com/w3c/csswg-drafts/issues/3804
fantasai: This is the one Rossen brought up.
astearns: Issue #3804
astearns: I haven't reviewed, is there a resolution
fantasai: Yes.
astearns: Only colors in issue itself
fantasai: In the resolution, yeah
astearns: We'll wait on a PR
CSS Lists
=========
Should option/optgroup be able to set counters?
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4004#issuecomment-506906199
astearns: We left it at fantasai and TabAtkins suggesting we punt on
replaced elements for now
<TabAtkins> Yes
fantasai: Dug into issue a little. Seems like figuring out what's
going on for form controls is a mess. To get spec to
reflect reality we figured fine for spec to leave it
undefined.
fantasai: Want to check with WG if really want to dig into the issue
heycam: I think need to do at some point, but okay undefining it for
now. At some point need to consider alternate presentations
of certain elements like select and what it means to allow
UAs to have CSS based and nonCSS based presentations.
heycam: Make sure counters and anything else makes sense in presence
of presenting these in different ways
astearns: Given we have 1.5 impl that reset counters and option/
optgroup are the most list-like would it make sense to
define those and leave reset?
fantasai: Could. Want to move to a world with more styling rather
than less. Makes sense elements with some visual
representation can handle counters. No reason they can't
manipulate counters. I don't feel strongly this is
important to solve right now. Happy to leave undefined and
let implementations merge toward more things being
countable
AmeliaBR: Specific behavior for option/optgroup the inconsistencies
with counters are related to other styling
inconsistencies. Getting a proper model for explaining how
option/optgroup and selects in general work for display
trees would be useful. Special rules for counters without
whole model might make more complicated
heycam: Counters are special because can effect things without.
Separate from general stylability in that way. Seems we
could solve counter issue independent in terms of should be
observable outside the select so counters increment
heycam: Am I right that if counters increment inside you can see it
outside?
fantasai: Yeah
astearns: In some browsers it has effect, in others it does not
heycam: Agree with fantasai might not be super important. Does seem
like a discussion we can have about if it's acceptable to
make UAs that don't have CSS based and therefore boxes
should do something else to inc. counters
fantasai: I think cases where this shows up is test cases. I can
image using counters within select box but not referencing
them outside. Given not sure how this impacts impl
architecture. I'm leaning to undefined and let them
converge. I don't think we should spend effort getting
impl to align. If there's a use case later we can add it.
That's why I advocate leave undefined. What impl doing is
probably fine for now
astearns: What if we resolve to undefine at this level and add a
note we're doing this because no interop and don't have a
use case guiding to the right direction
fantasai: More no use case to spend engineering effort to align.
Right direction for authors is honors counters. That's
what they would expect and it's reasonable. Don't think it
matters in this strange case
astearns: Just having a note why we're leaving undefined.
fantasai: I can have a note that there's no interop and we don't
think it's important to get interop so we're leaving it
undefined
astearns: Any further arguments to not leave undefined?
tantek: Can we live with this being a compat issue where we have to
become compat with whatever Chrome does?
astearns: Are you aware of any Gecko bugs currently?
tantek: I don't. I believe that us leaving undefined in the long
term means it'll end up being a compat issue with Chrome. If
we can live with what Chrome does eventually spec may have
to specify that behavior.
AmeliaBR: Given it's lack of feature in dominant browser I don't
know if that argument is that strong. I don't think people
will rely on counters not working in optgroups. There
might be a zombie CSS issue if it ever works but that's
not major web compat argument.
tantek: Okay
astearns: Proposal is leave undefined for now and add a note
explaining why
astearns: Objections?
RESOLVED: Leave undefined for now and add a note explaining why
CSS Color
=========
Predefined colorspaces (renaming image-p3 to display-p3)
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4056#issuecomment-505993145
<chris> I looked into the edit history, there were a number of
changes from dci-p3 to where we are now. Rik was the main
contributor; there was discussion on the commits. See for
example
https://github.com/w3c/csswg-drafts/pull/557/commits/644c4c49b86d97bb59bf74e533bdfbe339f3d176
chris: Looked at this. When originally put in spec confusion between
dci-p3 and what Apple used. I originally called it dci-p3 and
that was wrong for many reasons
chris: Thought we had a resolution, but can't find it. Went through
edit history and it went through name changes. I'm happy
changing to to what everyone knows it as
dino: My memory is not great. At some point I posted the profile for
it given the idea it can be linked form the spec. I'm in favor
of display-p3. Also willing to add another named to dci-p3 but
I don't think there's a need
chris: I don't think there is. dci-p3 has strange greenish white and
designed for use in digital cinema. Not appropriate for web
dino: That's the main driver for Apple creating what we call
display-p3
tantek: You said because it's designed for dark environments it's
not appropriate for web
dino: Pitch black rooms
tantek: People do use the web in dark rooms
dino: This is just the convenience method. You can get the same
result using display-p3. It just happens to have been
calibrated for different env.
tantek: Is that calibration not useful when looking at web in the
dark?
dino: If you're writing to be used in something like a cinema sure
astearns: That's an argument to add dci-p3, but this is about what
do we call the thing that we know is not dci-p3 and we
want to support it
AmeliaBR: Adding separate profile can defer until demand. There is
demand to match the thing Apple does. If the definition is
match Apple then we should match the name unless there's
trademark reasons
dino: Nothing Apple specific about this other than we gave it a
name. That's why I posted the file. There's nothing secret or
protected about this
chris: Given that I would like to call for resolution
astearns: I could not find reason why we changed from display-p3 to
image-p3. There's some discussion about how web isn't only
for displayed, but not terribly compelling.
astearns: Proposal: Take what we're calling image-p3 in our spec and
rename it to display-p3
astearns: Objections?
RESOLVED: Take what we're calling image-p3 in our spec and rename it
to display-p3
dino: Anything we can do in CSS to stop people from using their
phone in a cinema? ^_^
astearns: Happy to follow the incubation process
CSS Content
===========
Initial value of quotes should be auto
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4074
heycam: Commenter is happy with deciding or not on call
AmeliaBR: Request is a new value auto to be clear. This is language
sensitive default
dbaron: I think that's the idea
dbaron: Idea is that WK and Blink use an initial value that is not
something they can serialize that triggers language
dependent marks. Would like to do in Gecko, but want to be
able to serialize and roundtrip
AmeliaBR: I think this is something authors would want to use. Might
not need to set explicitly if it's sensible default.
heycam: Can use initial to get this unserializable value
astearns: Is reason because no one wanted to impl auto in past?
Reason why we did not do this previously?
dbaron: I don't know. I do know it used to be the spec acted as
though you would write all language dependent values in CSS
in UA stylesheet. Some have non-speedy selectors and it's
better to impl in not-CSS and more direct data from CLDR
AmeliaBR: In spec have a 'depends on UA initial value'. Not great
because means no interop. Sounds like in some UA depends
on more than a single value. Having an auto value and the
UAs that have a simple initial value auto can resolve to
the initial value
florian: Auto and initial value for language reasons is reasonable.
Are you considering specifying what the behavior is or is
it meant to be impl dependent?
AmeliaBR: Good question. Should we define auto needs to be sensible
language based
dbaron: Could be more precise depending on interop situation. Worth
follow-up investigation. Worth coming up with more specific,
but no one has that written down right now
florian: If we define what it is eventually I support auto value
myles: Having the initial value be auto is a good idea. Should do it
astearns: Having rough consensus for auto value that is for now impl
dependent but it serializes well
<fantasai> https://html.spec.whatwg.org/multipage/rendering.html#quotes
fantasai: HTML spec, I believe this is out of CLDR. Has a definition
for quotes. Seems to be all we're asking for is an auto
value with this behavior built into it. So UA stylesheet
just says auto and have this behavior. So we have a
definition. Might want to update the definition but not
defining from scratch
AmeliaBR: Sounds good. Simplify UA stylesheet. Integrate into CSS.
fantasai: None of these selectors are HTML specific
AmeliaBR: But for default HTML @namespace.
fantasai: We can drop the @namespace
AmeliaBR: Either way making it defined in CSS rather than HTML means
defined for all CSS applications
myles: Should allow for other browsers to change CLDR rules.
Shouldn't say must adhere to exactly what CLDR says
florian: Do you have specific ways you want to differ from CLDR or
just fundamental principle?
myles: I'm sure we have tweaking. Lots of designers and language
experts that have many different opinions in our company.
Don't have specific example off the top of my head
astearns: Aside from question of defining exact behavior of auto,
does anyone object to adding an auto value?
RESOLVED: Add an 'auto' value
astearns: I'm open to figuring out if we can define this. Would be
good to have specific proposal, not just pointing to
another spec ans saying copy. If someone wants to define
auto more closely good to open a new issue with a
proposal. Sound okay for everybody?
heycam: Yeah
Geometry
========
DOMMatrix constructor is a performance and code portability footgun
-------------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/346
astearns: krit sent regrets. TabAtkins said makes sense.
chris: [missed] said he didn't need to be in discussion and happy
with what we agreed
astearns: Proposal was [reads]. I don't entirely understand it.
AmeliaBR: I don't entirely understand it either. Right now the
constructor allows either a string or an iterate-able
object. In certain environments if you pass another matrix
object as a parameter it gets serialized to a string and
reparsed and act like it works. In others it won't happens
and it throws. Concern this is bad
AmeliaBR: Not sure why sometimes serialized and not others
AmeliaBR: Request is support another constructor overload that you
can construct any matrix by copying values of another
matrix object
heycam: Don't understand why it is worker throws exception
dbaron: I suspect some serialization or parsing code not exposed to
workers.
<dbaron> yeah, the stringifier is Window-only
AmeliaBR: If behavior in a window is it serializes and parse back
again it doesn't sound efficient. Direct cloning is more
efficient
dbaron: Difference is because stringifier is DOM only.
dbaron: There's consensus in issue. Asking WG to declare that
astearns: I don't see anyone saying it's a bad idea to revert the
change
dbaron: And it's part of a change being reverted, not the entire
heycam: I also don't understand underlying motivation of removing
overloads in general
astearns: Proposal: Add back in the overflow for DOMMatrix readonly
to the DOMMatric constructor
astearns: Objections?
AmeliaBR: Question- do we have multiple implementor consensus?
astearns: I see Blink and Gecko in comments
AmeliaBR: Probably okay unless someone from WK objects
RESOLVED: Add back in the overflow for DOMMatrix readonly to the
DOMMatric constructor
Writing Modes
=============
astearns: 2 weeks ago talked about pushing Writing Modes forward.
astearns: florian you were going to file and issue on Gecko?
florian: I have not, but dbaron raised an issue about part of spec
in question. Someone who is not me, probably fantasai or
koji, should look. Filing an issue while considering
changing the spec is not best time.
<fantasai> I think the issue was asking for clarification
<fantasai> Not a change particularly
florian: I have not given up on pushing writing modes forward. For
people that understand writing modes, looking at dbaron's
issue is a good idea
<dbaron> https://github.com/w3c/csswg-drafts/issues/4026
florian: That's the one; dbaron just posted
florian: fantasai, koji, and others if you can look it would be good
astearns: Thanks. I will ask again next week for what progress we've
made. If the issue has baring on test results we can get
that sorted.
astearns: Anyone have anything else to do in last 7 minutes?
astearns: We're done. Thanks everybody and talk to you next week!
Received on Thursday, 4 July 2019 10:22:25 UTC