- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Jul 2016 20:17:12 -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.
=========================================
Predefined spaces
------------------
- RESOLVED: Add AbobeRGB and ProPhotoRGB as predefined spaces.
Allow either the table of numbers or an ICC v.4
profile with relative colorimetric intent
- RESOLVED: Add a single CMYK profile, with relative colorimetric
intent, mainly to use as a fallback
Support for CSS namespaces
--------------------------
- TabAtkins explained the work being done on web components which
will solve for many of the problems authors are facing around
namespaces.
- The group agreed that this approach did seem like it would
help and more experimentation in this direction would lead
to more progress.
- The group also actioned TabAtkins to create a wiki to gather the
history of work and experimentation and allow authors to
comment and contribute to further progress.
Testcase for text-align: right + list-style: outside
----------------------------------------------------
- RESOLVED: Outside bullets are outside the box.
Grid
----
- RESOLVED: Accept the change (implied min takes on the constraint
defined on the track).
- Everyone has a week to review the proposal for block-axis
baseline: https://github.com/w3c/csswg-drafts/issues/197
- Next week the group will resolve on block-axis and then vote to
publish Grid.
Values & Units
--------------
- RESOLVED: Start a level 4 draft of Values & Units, move calc()
serialization to it, and then publish the remainder of
Values & Units 3 as CR.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jul/0049.html
Present:
Rachel Andrew
Tab Atkins
Bert Bos
Tantek Çelik (IRC Only)
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Brad Kemper
Ian Kilpatrick
Chris Lilley
Myles Maxfield
Michael Miller
Edward O'Connor
Anton Prowse
Liam Quin
François Remy
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Rossen Atanassov
David Baron
Daniel Glazman
Jen Simmons
Scribe: dael
astearns: Let's get started. Does anyone have anything to add to
the agenda?
<TabAtkins> We can drop the comma-redux topic - I've begun
gathering compat data, but haven't analyzed it yet.
I'll be ready next week.
<ChrisL> yeah, agreed on the comma topic
fantasai: If we have a few minutes, Values & Units. We're still
hung up on the calc() serialization but I'd like to
publish a new CR so I propose make that undefined.
astearns: Okay. We'll do that instead of the comma discussion.
astearns: Anything else?
Predefined spaces [css-color]
=============================
<ChrisL> https://github.com/w3c/csswg-drafts/issues/292
ChrisL: At the San Francisco meeting a couple of people suggested
we should have a larger set of predefined spaces. The
thought there I think was we should add a bunch more.
Recently dino said start with a small set. Apple only
needs one, P3. Maybe AdobeRGB and ProPhoto.
ChrisL: I said they should be added. We can do an ICC profile or
do the table we have. Table is simpler but less control.
ChrisL: It's also helpful to have a predefined CMYK space as a
fallback.
ChrisL: I could go either way on that. I can see it being helpful
or slowing up. I'd like opinions. Especially from digital
publishing or print-PDF publishers
ChrisL: I'd like to know what other people thought.
<myles> ChrisL: is there a specific proposal here, or are we just
discussing which color spaces should be present
Florian: You said should we define the color spaces with ICC
profile or table. Do we have to say in the spec?
ChrisL: Yes. An ICC profile needs a rendering intent. Relative
color image is testable and perceptive isn't testable.
Also, if we provide ICC profile do we require support of
ICC? If so which version? There's a bunch to put forward.
P3 and r2020 were done with tables and people have that. I
was thinking that would help get implementation going
faster.
SteveZ: Is there a difference that's noticeable between the two
methods since they're fixed somewhere? I understand
control eventually, but if we're restricting to a fixed
set is there difference?
ChrisL: If you use version 4 of ICC you apply chromatic adaptation
transform to the primaries and then do a tag for the
chromatic adaptation. So the numbers would be different,
but visually similar. For relative color intent it will be
the same for in gamut.
ChrisL: If I have access an implementation that does ICC I could
test but I don't know one.
Florian: What happens for out of gamut colors?
ChrisL: You have to define it. At the stage you can go to linear
RGB you get linear. I think we should say you clip to a
neutral gray point. It shouldn't do per component clipping.
Florian: Can't we say should use ICC may do table and they're
close. One is better and if you're willing to do it go
ahead.
ChrisL: We could. More complex to test but I wouldn't mind. Does
it mean implementors have to ship both or they can choose?
Florian: I mean choose. If I understand they give similar results,
but they're better with the profile. If they're not will
to do profile they get similar results but a bit better.
Florian: Do we need the profile in the spec?
ChrisL: Yes. We will need it in the spec.
ChrisL: Additionally for AdobeRGB we need Adobe's permission for
the trademark. We could name it something similar, but I'd
rather get explicit permission
smfr: For webkit we'd prefer an ICC profile solution. We want to
offload the code. We don't want separate code in the browser
that's different than the color mapping for images.
ChrisL: Would you apply same logic to rec2020 and P3 tables?
smfr: I think we'd want color profile.
ChrisL: I can work on adding those profiles. It would be great to
have input from Adobe if we can use the name.
SteveZ: I'll ask.
Florian: For the CMYK fallback discussion. I think that it would
be nice if you're doing content that's meant for printing
or on screen viewing. You can add a RGB fallback, but
then you have to manually calculate and that's a pain. So
if you can fallback to a known profile it gets you close.
ChrisL: I suggest I spec that out and if it's not implemented we
can always drop it.
Florian: Sure.
Florian: I don't think we want a whole bunch of cmyk profiles.
This would be mostly a fallback.
astearns: It sounds like we have a way forward. Do you want to
handle it in github or do you want a resolution?
* fantasai is in favor of more explicit resolutions, not less
Florian: If we agree resolutions are good.
<fantasai> If we have consensus, let's record it.
ChrisL: Okay, yes.
<ChrisL> Proposed resolution: add AbobeRGB and ProPhotoRGB as
predefined spaces. Allow either the table of numbers or
an ICC v.4 profile with relative colorimetric intent
<ChrisL> Proposed resolution: Add a single CMYK profile, with
relative colorimetric intent, mainly to use as a fallback
astearns: Any objections to the first part of the resolution?
RESOLVED: Add AbobeRGB and ProPhotoRGB as predefined spaces. Allow
either the table of numbers or an ICC v.4 profile with
relative colorimetric intent
astearns: Objections to the CMYK portion?
RESOLVED: Add a single CMYK profile, with relative colorimetric
intent, mainly to use as a fallback
astearns: Anything else on color spaces?
ChrisL: That's it beside the commas.
astearns: And TabAtkins is still collecting data there.
Support for CSS namespaces [css-scoping]
========================================
<astearns> https://github.com/w3c/csswg-drafts/issues/270
ChrisL: This is the 'what to do with shadowDOM' thing. How do you
style, do selectors work, etc. I think closing and saying
we won't fix it is doing the community a disservice. I'm
hearing a lot of pain where people want to be able to do
modularize-able solutions. I see huge long naming
conventions.
ChrisL: It's not 'do we have namespaces', it's what are we working
toward to have local variable type styling for
theme-ability. Just saying we won't do anything for a few
years isn't appropriate.
TabAtkins: Today the answer is web components. There are some
holes and we'd like it something like easier to do
declaratively, but we'd like it to mature to see where
we need to go. That's our focus. Everything that people
suggest won't do what they want. You want the solution
to work in both directions that's something web
components allow. Their solutions don't think both
directions. And browsers aren't doing scoped styles so
people won't implement the new things.
ChrisL: What does web components allow? Can you theme and style?
I'm not familiar enough.
<bkardell> TabAtkins: it could be declarative today, right? all
you need is a web component that just does that.
TabAtkins: If you put things in a shadow tree they're style-able
in the tree. The styles inside can't go out and the
styles outside can't go in. So it's a full
self-contained piece of HTML that won't be messed up by
styling on the rest of the page.
leaverou: How are they themed?
leaverou: I've refrained from using components because they're not
skin-able.
TabAtkins: We have some solution now. If you use variables you can
pass in styling one piece at a time. Not the most
convenient. We have the @apply rule that was generally
accepted that lets you shift entire style blocks across
the boundary.
TabAtkins: From inside the tree you can detect what's going on
from the outside like if a class is on an ancestor so
you can adjust accordingly. So you can ship with
multiple themes that do something depending on a class
outside.
<iank> Polymer has a writeup here of the mixin/custom-prop
solution:
https://www.polymer-project.org/1.0/docs/devguide/styling#custom-css-properties
bkardell: I wanted to add that one of the good things about this
is that we did experiment with several things. Chrome
and Polymer had experiments to allow you to explicitly
cross boundaries. We had a number of discussions based
on what people thought they wanted, but when we gave it
it wasn't really what they wanted.
bkardell: Going forward we should expose basic things, allow
experimentation, and progress. This is new ground. The
only way we can know this is the right thing is to be
allowed to use it.
TabAtkins: He's referring to the deep selector. It led to unending
problems of people changing things they didn't mean to.
So we dialed back to explicit sharing. It's all the
flexibility without a footgun.
leaverou: This sounds good but I'm skeptical that a component
exposes its variable so to change it you have to change
your CSS. Assuming there's no native slider, you want to
use a slider and then another slider you'll have to look
up the documentation. Native components do accept some
styling. It would be nice if author components did the
same thing.
TabAtkins: That's good feedback. We should keep that in mind as we
move toward more declarative.
<bkardell> but if we expose the right bits, then maybe people like
leaverou can experiment with ways to do that in wicg :)
leaverou: I'm not sure this is just shadowDOM. I think it may also
be nesting. That's another thing authors ask me about.
leaverou: Authors ask me a lot about nesting and scoping in every
conference for the last few months. I don't know what to
tell them.
leaverou: So nesting is another big thing. This is what the naming
conventions are trying to address.
astearns: So there's several issues. Scoping, nesting, a more
declarative approach to components. I'm not sure a
single github thread will be that helpful. It might be
good to have a single place with the history of this
conversation. So look we have this deep selector and it
didn't work like we wanted.
astearns: I'm thinking a wiki page with all the history where we
can take this github and point it there to say we've
worked on these things, we're trying these things. So
we're not shutting down conversation but it's not a
single thread.
astearns: I want a place where we can engage the community on
these issues and some place with the history of what we
tried and what we're looking to do.
<bkardell> this really does sound to me like a great thing to
bring up in wicg before csswg itself burns time on
it... that is inclusive of devs and hopefully then we
can bring back the good ideas.
ChrisL: Sounds great. So who should write it and who has the
material to begin it?
TabAtkins: I can start writing that. I have the history in my head.
fantasai: A blog post would be nice, but the commenting on our
blog is too broken.
astearns: And bkardell mentioned on IRC that this may be good for
the incubation group.
<bkardell> also repos and wikis and all available on wicg
ChrisL: In terms of what I wanted from putting this on the agenda,
I've achieved it.
ACTION TabAtkins to start collecting namespaces history and future
plans on a wiki so we can show the community and allow
input.
<trackbot> Created ACTION-783
<rachelandrew> I'd be very happy to look over or edit copy for
this sort of outreach to authors, I'm used to
writing for that audience.
Testcase for text-align: right + list-style: outside
====================================================
<astearns> https://lists.w3.org/Archives/Public/public-css-testsuite/2016Jul/0002.html
<astearns> http://jsbin.com/ciganovici/edit?html,css,output
fantasai: We have an incompatibility among implementations. We
need to pick a behavior.
fantasai: The intention was to leave this undefined in CSS2.1 but
the text isn't that unclear.
fantasai: The text says the bullet is outside the box which only
can be interpreted one way. But dbaron said we meant to
leave it undefined due to incompatibility issues in 2.1
discussions. So we just need to pick one.
fantasai: And edit accordingly
fantasai: I don't know what people would expect. I think having
right or center aligned bullets is super weird and rare.
gsnedders: This came up because Google hit this with a web compat
bug.
gsnedders: It was on something like a Chrome webdev page that was
broken in Firefox.
astearns: And in the report was there a preference?
gsnedders: I don't think so. Just a desire for interop.
gregwhitworth: Webkit matches chrome?
gsnedders: Yeah.
gregwhitworth: So the shortest course of action for me is to ask
FF to match everyone else.
<fantasai> What does Edge do?
astearns: Sounds good to me.
gsnedders: Firefox places the bullets to the center and right so
it hides under the black box in the test case.
gregwhitworth: If you change the color you can actually see it
which makes me think they're aligning the whole
thing.
gsnedders: It's weirder than that.
astearns: I suggest that we do what everyone else does and have
Firefox change.
fantasai: Sounds like we file a bug on Firefox for this one?
gsnedders: There's a 15 year old bug on this.
fantasai: As far as I can tell the spec is clear
gsnedders: We just re-added the test.
fantasai: So it sounds like outside bullets are outside the box.
RESOLVED: Outside bullets are outside the box.
<gsnedders> fantasai:
https://bugzilla.mozilla.org/show_bug.cgi?id=25291 is the FF bug,
FWIW.
<gsnedders> 16 year old bug, rather than 15. my bad. :)
Grid
====
Implied Minimum Size of Grid Items
----------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/283
fantasai: We have an implied minimum size on flex and grid items.
Usually it's the content size but sometimes it's
smaller. If you spec 100 px we'll do that instead of
imply a min.
fantasai: One thing pointed out was with track sizing we have
sizing on the track not the item. So it seems that the
implied min should account for that.
fantasai: I changed the spec to if you put a grid item inside a
100px track and in the grid item there's a 200px image
it doesn't stretch the item. The implied min is still on
flexible tracks.
astearns: Does anyone have an opinion on if that's the right way?
astearns: Given the lack of opinions, I"m include to go with
fantasai 's decision.
fantasai: Okay.
<rachelandrew> that makes sense to me
<fantasai> good :)
<astearns> thanks, rachelandrew
RESOLVED: Accept the change (implied min takes on the constraint
defined on the track).
Block-axis baselines
--------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/197
fantasai: Mats pointed out each box has a baseline in order to
baseline align it to other boxes. We define block-axis
baselines and those should also be honored for baseline
alignment. One of the things going on in Flexbox is
we're only doing it if the axis matches the main axis.
We're not synthesizing an axis for orthogonal flows.
fantasai: So if you have a mix of flex items and 2 are horizontal
and 2 vertical you can align the horizontal to each
other. For the vertical you can synthesize but that's
weird so Flexbox says you just start-align that stuff.
We wanted to preserve that behavior. So to get that to
work correctly we introduced natural and synthesized
baseline. If you baseline align you do it with natural.
fantasai: Synthesized are for putting content on a line of text.
fantasai: So we made a bunch of edits to the specs to bring this
in line. I think it makes sense, but I'm not 100% sure
it's correct. We'll have to do some cleanup in alignment
for tables legacy behavior. This is the direction we're
going in and if people want to think about this we'd
appreciate some feedback.
<fremy> fantasai: I am ok to review the changes if you send a mail
to the list with them so I don't have to look for them ;-)
<fantasai> fremy:
https://github.com/w3c/csswg-drafts/commit/3877c16e82d541e7640c9cb328c028e40f5d6ffc
astearns: One questions from your explanation. You said things are
start align with no natural baseline. If it's last
baseline it should be end align.
fantasai: Yes. That's specified.
astearns: That makes sense to me. Other opinions?
astearns: fremy volunteered to review. Should we give him a week
to review?
fremy: Yep.
fantasai: Makes sense.
Publication
-----------
fantasai: So once this issue is closed we'd like to go to CR
<fantasai> https://drafts.csswg.org/css-grid/issues-wd-20160519
astearns: So I propose we allow a week for review on baseline and
next week we resolve on that and do CR next week.
Objections to that timeline?
[silence]
astearns: Let's go with that.
Values & Units
==============
<fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2015
fantasai: Every issue tracked there^ is closed except there have
been concerns on the text for calc() serialization. We
have a lot of changes and we should push to CR. I'd like
to defer calc() serialization to level 4 and we can sort
it out there on a longer time scale. Also allowing us to
republish this draft.
fantasai: We've been holding off on forking level 3 to 4 because
we want to do the fork when we publish the CR to
minimize changes. So I'm hoping we can do that and put
the calc() serialization and add the units that were
resolved on for level 4.
astearns: I'm not sure happy in leaving it undefined, but I'm
happy with moving this along and adding the things
resolved on. As long as calc() serialization and all the
discussion stands in the level 4 draft I'm okay with
taking it out of level 3.
astearns: other opinions?
<bkardell> seems good
<bkardell> +1
astearns: In publishing a new CR of Values & Units 3 are you also
committing to making level 4?
fantasai: Yep. I want to prepare the draft, fork off of level 3,
and then publish.
astearns: So start a level 4 draft, move calc() serialization to
it, and then publish the remainder of Values & Units 3
as CR
astearns: Objections?
RESOLVED: Start a level 4 draft of Values & Units, move calc()
serialization to it, and then publish the remainder of
Values & Units 3 as CR.
<ChrisL> is that an updated cr?
<fantasai> yes
<ChrisL> is there a list of changes compared to the previous cr
astearns: Any other topics?
fantasai: I vaguely recall agenda+ something. Let me see what.
astearns: ChrisL had a question.
ChrisL: Questions on Values & Units.
ChrisL: On the level 3 CR; is it updated CR and is there a change
log? I'm thinking of the transition request.
fantasai: It's an updated CR. THere's a list of changes and DoC
and I'm going to review those. I'll collect them and
send them to you.
ChrisL: Sounds good.
<bkardell> was issue 266 discussed earlier?
<bkardell> it was on the agenda I think?
<bkardell> gotcha
astearns: bkardell, we decided to defer the comma discussion until
next week.
<bkardell> thanks astearns
astearns: fantasai did you find something?
fantasai: I found an inconsistency on baseline alignment. If you
need more alignment than you can do with baselines.
Flexbox says flex-start align, alignment says
start-align. I think we need self start. When you have
varying amounts of content they'll look almost start
aligned but the baseline won't be perfect. The
flex-start won't get you that. I think that's an error
in flexbox and it needs to depend on the writing mode.
fantasai: I think that's an error and I'd like to fix, but it's to
flexbox so it needs a resolution.
astearns: Sounds like the next step is to come up with a proposal
we can review.
<fantasai> https://github.com/w3c/csswg-drafts/issues/332
astearns: Ah, okay.
[silence while people look]
astearns: Why don't we add this to next week's agenda with the
other baseline topic to allow time to review.
fantasai: Sounds good.
astearns: Alright, so we'll end a bit early. Thanks everybody.
Received on Thursday, 21 July 2016 00:18:12 UTC