W3C home > Mailing lists > Public > www-style@w3.org > May 2017

[CSSWG] Minutes Tokyo F2F Fri 2017-04-21 Part III: CSS-SVG Box Correspondences, CSS Color [css-color][css-transforms]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 26 May 2017 20:59:59 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <a8424cbb-362e-909f-ac7d-116717d8cda7@inkedblade.net>
=========================================
   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

This archive was generated by hypermail 2.3.1 : Saturday, 27 May 2017 01:00:36 UTC