- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:59:59 -0400
- To: "www-style@w3.org" <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.
=========================================
SVG & Color breakout
++++++++++++++++++++
CSS-SVG Box Correspondences
---------------------------
- RESOLVED: fill-box, stroke-box, content-box, padding-box, border-box all
map as defined in fill-stroke module. view-box maps to border-box
in CSS.
- RESOLVED: Initial value of transform is view-box
CSS Color 4
-----------
- RESOLVED: dino will experiment with using extended sRGB as the working
color space and come back with results.
- RESOLVED: Interpolate between colors by converting them to the
working color space for now.
- RESOLVED: color() always serializes as color().
- RESOLVED: Add an API for converting between the browser's known
color spaces; dino will bring a proposal to the group.
- RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/817
as invalid, as you can already do this.
- RESOLVED: Get data/info first from graphics impls on having
image-rendering:high-quality mandate a linear
color-space for scaling, then revisit.
- RESOLVED: leaverou is also an Images 3 editor
CSS Inline
----------
- RESOLVED: Koji as co-editor of Inline Layout.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Note: The group split part of the morning of the 20 April on two
tracks: Floats and Color/SVG.
Scribe: flackr
CSS-SVG Box Correspondences
===========================
<dbaron> It seems we have three github issues on this:
https://github.com/w3c/fxtf-drafts/issues/66
https://github.com/w3c/csswg-drafts/issues/999
https://github.com/w3c/csswg-drafts/issues/857
fantasai: Issue is to have a standardized mapping between dash box
keywords, bunch of properties take these kinds of
keywords.
Rossen: Yesterday we partially covered issue, and agreed on
mapping. content-box and padding-box map to fill-box.
border-box maps to stroke-box.
fantasai: We need something to go back in other direction.
Rossen: For view-box?
TabAtkins: It's a box, but we don't have anything that let's you
refer to it.
TabAtkins: We can map view-box to one of the element based boxes.
fantasai: In fill and stroke module CSS ends up having all of
these boxes, <points to content, padding, border,
stroke>.
fantasai: Are there places in other specs where we take these
boxes?
TabAtkins: No, we only have these in fill and stroke because they
talk about text, with geometry different than normal
boxes.
fantasai: fill-origin property, which takes these keywords can be
set on any element. It's not applied to text, applied to
an element and takes that object's geometry for setting
the fill origin for images.
fantasai: If we don't have transform-box or other box properties
use the same definition, then if you set coordinates in
transforms and set the same in fill or stroke, you would
get different results.
fantasai: We didn't run into a use case while working on
transforms that we needed these text based bounding box
concepts, but we should use this same concept in all of
our boxes, where ever fill or stroke appears
fantasai: for example for setting a mask image with the same
origin when set to fill-box as a fill with origin set to
fill-box.
TabAtkins: Possible-
TabAtkins: problem is that mask, transform, and shapes.
fantasai: Shape doesn't have fill and stroke.
<dbaron> reading https://github.com/w3c/csswg-drafts/issues/999#issuecomment-277024658
dbaron: The notion that some of the properties are doing different
things does make some sense because they can't reasonably
map into the same property.
fantasai: Didn't discover we needed fill-box and stroke-box in CSS
until we did fill-stroke module.
<dbaron> https://drafts.fxtf.org/fill-stroke/
fantasai: view-box is on transform-box property?
TabAtkins: Just on transform-box.
ChrisL: The view-box declared on the closest svg element.
Rossen: Kind of like initial box of the svg.
TabAtkins: I don't agree in general we should match fill-box and
stroke-box to same meaning
TabAtkins: because these properties are dealing with text and
these properties are talking about properly filling and
stroking that text
TabAtkins: whereas for svg they are in a different context, it
depends on the property you are interpreting for.
fantasai: If you have element with some text, and the fill box is
bigger, then when you draw an image and add a mask,
these need to use the same coordinate system
fantasai: but if you're saying fill-box is not available for mask
origin can't make these line up.
TabAtkins: It's still a matter of which concept you're talking
about, the box's geometry or the geometry of the text.
fantasai: It should create the same coordinate system that it does
if you set fill-origin on that element.
Rossen: In CSS boxes internally, this is going to be an overflow
box.
fantasai: It's text only.
fantasai: It's the outline of the glyphs, so not quite the inline
text box.
fantasai: I think we need consistent coordinate systems,
fill-origin and mask-origin should have the same
behavior for the same keywords.
fantasai: If those have same behavior for same keywords,
transform-box should too.
TabAtkins: Yeah, but other properties such as mask-origin, when
using svg keyword on css stuff will have a changed
meaning.
fantasai: Hopefully people aren't doing that.
ChrisL: How much of a breaking change is this?
TabAtkins: Might be minor, might be major, depends on content.
fantasai: Initial value might need to be some kind of auto keyword
that depends on whether it's svg or css
fantasai: or a UA stylesheet thing.
ChrisL: I'd rather avoid making breaking changes unless we have to.
TabAtkins: Initial value of border-box for svg is view-box.
TabAtkins: transforms and svgs default to the top-left corner.
TabAtkins: I guess I'm okay with this.
TabAtkins: With fill-box used in css meaning what's defined in
fill and stroke.
Rossen: We don't care about view-box?
fantasai: This is another issue I think.
TabAtkins: Think we added auto keyword.
[confusion about what the resolutions actually were]
fantasai: If I specify transform-box: border-box on svg element
what do I get?
<dbaron> (answer to the previous question was border-box ->
stroke-box on SVG)
fantasai: If I specify transform-box: view-box on a CSS box what
do I get?
TabAtkins: Maps down to border-box, it's the closest you can get.
fantasai: What's the initial value?
TabAtkins: Something different, forget what specifically
fantasai: Make initial value view-box to get behavior we want it
to have.
ChrisL: That seems fine.
<fantasai> Resolutions from yesterday, presumably were
<fantasai> * border-box in SVG is treated as stroke-box
<fantasai> * view-box is in CSS is treated as border-box
<fantasai> * initial value is view-box
<fantasai> From today: fill-box and stroke-box for CSS are as
defined in fill-stroke
<fantasai> for completeness, content-box and padding-box in SVG
are treated as fill-box
Rossen: view-box and stroke-box resolve to the same as boxes
defined in svg fill-stroke
RESOLVED: Initial value of transform is view-box
RESOLVED: view-box and stroke-box resolve as defined in fill-stroke module
CSS Color 4
===========
Working Color Space
-------------------
Github Topic: https://github.com/w3c/csswg-drafts/issues/300
dino: Idea is that document will have working color space, some
kind of css syntax to say what it is, default is srgb.
dino: There was some discussion as to what does the value if you
specify background-color: rgb(255, 0, 0) what space are they
in?
ChrisL: This is in sRGB.
dino: This didn't matter because everything was in sRGB. we think
older style colors should be in working color space.
ChrisL: Downside is if you view source and copy some of their
style and document the colors become different.
ChrisL: Also, one reason to change working color space is because
you've got some bit of content you want in a different
color space, like a video.
ChrisL: You don't want your existing colors to change because you
have a new element needing a wider gamut.
dino: Adding the new element doesn't necessarily change colors.
ChrisL: If you then want to have a gradient you need to change
working color space.
dino: I propose we change default working color space away from
srgb but to be extended sRGB.
ChrisL: In SRGB you've got 0-255 and we used to say you could
theoretically go below 0 or above 255 but it was undefined
what the transfer code was.
ChrisL: There was defined a transfer space called scRGB which was
a linear mapping which was tried in HTML context for a
while but it didn't work well.
ChrisL: You need a wider gamut. Going for an older model which
isn't compatible with color management systems isn't going
to work well.
dino: Concern that ChrisL is bringing up is that you would end up
with a band as you clamped at the edge of your color space.
ChrisL: What is complete gamut range?
dino: Goes on forever.
dino: It covers at least P3
dino: and should cover rec2020.
dino: Should we distinguish between linear, SRGB, etc
dino: We don't have any way to handle blending in linear space yet.
dino: Designers don't understand what it is, are very used to
non-linear blending.
ChrisL: Once we're finished with this easy stuff we need to get
linear for when we get onto HDR.
dino: Definitely do not want to block out linear, we could
definitely add it now.
ChrisL: I'd like to see more details about your proposal.
dino: I was hoping to implement it, do everything in extended SRGB
and see what happens. And whenever doing an interpolation
convert to the working color space and see how well this
works.
dino: We could make the default working color space extended SRGB,
which should be lossless, not out of gamut.
dino: I can do some experimentation and see if that's okay.
RESOLVED: Interesting idea, dino will experiment and come back
with results.
Interpolation between different color spaces
--------------------------------------------
Github Topic: https://github.com/w3c/csswg-drafts/issues/883
dino: Following on from issue 300, if experimentation pans out
than I agree with ChrisL, do interpolation in document color
space which means you may get discontinuities at the ends.
ChrisL: You said earlier you wouldn't get discontinuities at the
end.
dino: I said if experimentation works out, then hopefully the
working color space does something that does not result in
discontinuities.
Rossen: We can independently resolve on interpolating.
<dino> linear-gradient(rgb(255, 0, 0), color(display-p3 1))
dino: This ^ will get a solid color, not a gradient in the working
color space SRGB.
leaverou: If the working space is SRGB, then the display color is
clipped?
dino: It's clipped within a gradient, but not in the background
color.
dino: I'm trying to come up with a color space that's the same as
what people are used to but allows interpolation outside of
it.
ChrisL: This is why the working colorspace exists. It's not
possible to pick the 'larger' because they can intersect.
for example p3 and adobergb
ChrisL: This is why we have working colorspace which can be set to
Rec2020, or XYZ, or Lab
ChrisL: and will never clip.
ChrisL: This is why I want to have lab as an option because apart
from not clipping it also gives better results.
dino: I don't know how expensive it is to use Lab
ChrisL: When you have two things with different color profiles
they'll get converted to XYZ or Lab
<ChrisL> because those are the two profile connection spaces for
ICC profiles
leaverou: Why can't we interpolate in the union of the two working
spaces or lab? The author intent is clear: I want to
interpolate between sRGB red and P3 red. Those are not
the same colours.
<leaverou> http://dabblet.com/gist/1b1344c158bf599bfc1ad47cc1265e7a
dino: I will provide feedback based on our implementation. We can
always use Lab and this issue will go away - get no banding
dino: At which point you asked why do we need a working color
space for the document?
leaverou: We still need to define what the rgb(), hsl() etc colors
in the document resolve to.
dbaron: When you're combining different stylesheets from multiple
sources you don't want one stylesheet to change the
meaning of things in another stylesheet
??: variables?
dbaron: You know you're doing it.
TabAtkins: We previously had issues where we didn't want to let
other unrelated stylesheets mess with your colors.
dino: If an imported stylesheet sets the document working color
space we should come up with some rules for how its
processed.
TabAtkins: Let's give colors all defined meanings.
ChrisL: Let's continue to, as has been defined since css1, they've
always had defined meanings but the fidelity has ramped up.
leaverou: If all colors have defined meanings, why do we need a
working color space?
dino: We only need a working color space for interpolation.
dbaron: Even if color A is defined and color B is defined, it
depends on the working color space what is half-way
between them.
leaverou: Convert to Lab.
TabAtkins: Converting to Lab is *an* answer, not necessarily the
answer.
ChrisL: That's an option, it's not compatible with what we have at
the moment.
leaverou: To be better.
dbaron: But it would be a change.
Rossen: Do we have a counter proposal? If not let's go with dino's
proposal.
Rossen: You'd interpolate between colors in the document working
space.
RESOLVED: Interpolate between colors by converting them to the
working color space for now.
Serializing color() values
--------------------------
Scribe: TabAtkins
Github Topic: https://github.com/w3c/csswg-drafts/issues/480
dino: If you did "color(srgb 1 0 0)", should it serialize as that,
or as "rgb(255 0 0)"?
dino: Two problems.
dino: We lose a lot of precision sending it out to rgb() - only 8
bits of precision, vs doubles.
dino: That's impacted us in real impls - the touch bar in new
macs, when in editing mode you can pick a color, and those
colors are in a wider color space, then if we convert to
srgb you lose precision; if we send that information back
up, it's not what the author said.
ChrisL: In general I've moved Color 4 to 0-1, because it's
inherently bit-depth neutral, and we're seeing devices
with 10 or 12 bits per channel now.
dino: So should a color(srgb) be output as rgb()?
ChrisL: If anything, output it as %, that's higher precision.
TabAtkins: Or just keep it color().
dino: That's what I do now. It's higher precisions.
TabAtkins: Does anyone suggest simplifying to rgb()?
dino: No, it's just not strictly defined.
dino: And now that we have the new rgb() syntax, should we
serialize to that? That would probably break things.
TabAtkins: Yeah, I think we need to output in the old rgb().
dbaron: Back to color(), we could output to % and keep it
higher-depth.
dino: Yeah, but it would probably break content.
dino: No content expects percentages in the serialized form right
now.
dino: So maybe we can suggest that rgb() is always 8-bit?
ChrisL: Absolutely not - rec2020 is only defined over 10 and 12
bit. It would be a syntax violation.
dbaron: I think he was suggesting that the rgb() syntax,
specifically, is 8-bit.
ChrisL: Okay, that's fine. That then means that rgb() *must* be
stuck in sRGB - it can't become rec2020.
dino: No, I really just meant that when we serialize rgb(), we
round it to 8-bit.
ChrisL: So if a user inputs with rgb(%), then serializes, what do
you get?
TabAtkins: integers between 0 and 255
dino: So I think we can resolve that color() serializes as color().
RESOLVED: color() always serializes as color().
TabAtkins: Make sure to specify whether trailing 0 args are
omitted or not in serialization.
dino: I think I always output all the args. I leave off alpha if
it's 1.
API for converting between color spaces
---------------------------------------
GitHub Topic: https://github.com/w3c/csswg-drafts/issues/1248
dino: So say you're writing an imaging tool and you want to have
some code that converts between color spaces.
TabAtkins: We should. I don't like it when there's complicated
math the browser can do, but there's no API for it.
TabAtkins: I've had to write this code in JS by looking up papers.
RESOLVED: Add an API for converting between the browser's known
color spaces; dino will bring a proposal to the group.
Industry standard color names
-----------------------------
Github Topic: https://github.com/w3c/csswg-drafts/issues/817
TabAtkins: This already exists, no? color() accepts strings
already, to refer to palette colors in an ICC profile.
ChrisL: Yeah, crissov just needs to provide an appropriate ICC
profile.
ChrisL: And then you can do Pantone on your own as a user, rather
than invoke licensing issues with browsers.
RESOLVED: close as invalid, as you can already do this.
Gamma errors in image downscaling
---------------------------------
leaverou: There's some further discussion linked from this issue.
leaverou: Depending on the scaling algo, particularly if there are
stripes or thin patterns, the resulting downscaled image
can be significantly color-warped.
ChrisL: This is artifacts because they're doing arithmetic in a
non-linear color space. 1+1 doesn't equal 2, it equals 1.6.
leaverou: So I was asking if we should change behavior, or have a
switch for this, or what.
TabAtkins: Even in realistic images, you'll get noticeable
darkening if you downscale.
leaverou: So one proposal: image-rendering:high-quality mandates a
linear color-space for scaling.
leaverou: Or we have a new value for image-rendering that does
linear-blending.
TabAtkins: The cost of this is time, of course. But Chrome already
does a quick-and-dirty scale, then pops in a good scale
a second later or so.
dbaron: Does anyone know the actual slowdown ratio of doing linear
blending?
ChrisL: Don't have numbers, but it's simple - you just use a
lookup table to map them; a single lookup per pixel per
channel to send it to linear, then you downscale, then
those lookups again to send it back to gamma.
dbaron: In general we've had a disconnect between this WG and the
graphics people, and I feel that making this decision
without them will further that disconnect.
dbaron: So I think we should ping actual people doing the image
scaling, to at least get the rough data on how much slower
- big difference of 2% vs 400% slowdown.
TabAtkins: Heck, if it's small enough we could mandate it for
"smooth" too.
Rossen: So would you like to postpone this until we get some
numbers from graphics people?
dbaron: I think that would be useful.
RESOLVED: Get data/info first from graphics impls, then revisit.
Lea as Images 3 editor
----------------------
leaverou: Since I've done work on Images 3, can I be editor on
that too? (I'm already editor of Images 4.)
RESOLVED: leaverou is also an Images 3 editor
CSS Inline Editors
==================
fantasai: While we're at it, can we add Koji for css-inline?
fantasai: I'm pretty sure dauwhe won't mind.
RESOLVED: Koji as co-editor of Inline Layout.
Floats Summary
==============
fantasai: We discussed floats, and decided that the logical
keywords should be inline-start and inline-end.
fantasai: You'll often want to float in only one axis, and so to
disambiguate, you need inline/block-start/end, and so
left/right maps to inline-start/end.
<br type=lunch>
Received on Saturday, 27 May 2017 01:00:35 UTC