W3C home > Mailing lists > Public > www-style@w3.org > November 2015

Minutes Sapporo F2F 2015-10-26 Part III: Wide Gamut/Deep Color, Scroll Snap [css-color] [css-snappoints]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Nov 2015 20:38:22 -0500
Message-ID: <CADhPm3tYZtx9FqgyPw3Xzsh4JzH2C0KmhvKcHDKzEwezT23Jaw@mail.gmail.com>
To: www-style@w3.org
Wide Gamut / Deep Color
-----------------------

  - RESOLVED: Drop color-correction property from CSS Color.
  - RESOLVED: Keep sentence about untagged images being sRGB.
  - ChrisL will work on a proposal for a color profile feature for
      CSS.
  - Suggested to make a cut of the stable features for L4, and
    shift the rest of the spec to L5. This would make it clearer
    what's ready for implementation.

Scroll Snap
-----------

  - RESOLVED: drop 'scroll-snap-points-x/y: repeat() '
  - RESOLVED: Drop the feature of multiple snap points per element.
  - RESOLVED: Don't do anything special for multicolumn or grid.
  - RESOLVED: scroll-snapping applies to all elements.
  - RESOLVED: Always apply snap after all JS-based scrolling
              operations.
  - The text for when layout changes need resnapping will need
      someone with implementation experience to review it once it's
      written.
  - RESOLVED: Defer adding additional DOM APIs for scroll snapping.
  - RESOLVED: No automatic snap point at start and end of scrollable
              area. (issue 44 no change)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: fantasai

Wide Gamut / Deep Color
=======================

Colors Outside sRGB
-------------------

  dino: There's a few things to discuss.
  dino: Firstly, most importantly, the ability to specify colors
        that are outside sRGB.
  dino: I think Tab and smfr had a discussion about whether or not
        RGB values are clipped.
  ChrisL: They're clipped to the gamut.
  TabAtkins: We don't syntactically clip them. The actual value is
             clipped.
  ChrisL: This is so that you can specify outside the range using
          negative numbers.
  ChrisL: Downside is that the mapping outside the sRGB gamut isn't
          specified.

  dino: So what do we do about that?
  ChrisL: We've decided to add the LAB numbers.
  ChrisL: A second way to do it is to add support for other RGB
          models, e.g. Adobe RGB.
  ChrisL: All of these require adding syntax to specify the value,
  ChrisL: And also to extend the rendering space in which you do
          calculations.
  ChrisL: LAB means you'll never get clipping,
  ChrisL: interpolation of gradients etc. will be done in that space.
  ChrisL: You will never clip prematurely.
  ChrisL: That's the current plan.

  SimonSapin: Would that require a separate property?
  ChrisL: Yes, it would require a separate property for
          interpolation space.

  leaverou: Wouldn't that mean that any kind of interpolation,
            gradients or transitions, would all be the same?
  leaverou: You might want different choices for different uses.
  ChrisL: That's a good point.
  ChrisL: Right now there's no choice.
  ChrisL: SVG had one for [??] and another for filters.
  ChrisL: What's your gamut?
  dino: Less than Adobe RGB.
  dino: Ultimately we want to get to specifying colors in LAB.
  dino: Maybe it's simpler to experiment with not clipping?
  dino: See what breaks.
  dino: Then we can allow something like Adobe RGB to specify as
        gamut.

  TabAtkins: I discussed a lot with ?? who does graphics.
  TabAtkins: Our major issue is, if you're outside the sRGB gamut,
             you need more storage space.
  TabAtkins: That inflates all the colors.
  ChrisL: You need 10-12 bits per color, but then for storage you
          would want 16...

  dino: Other problem we came across..
  dino: Topic 2 is imageset, where you might want to provide
        different artwork on wide gamut vs normal gamut.
  TabAtkins: We already have a media query for handling that.
  TabAtkins: It tells you number of bits.
  ChrisL: That's not sufficient.
  ChrisL: That tells you the resolution within the gamut, not how
          wide the gamut is.
  TabAtkins: We can invent another media query.
  Florian: I'm not sure how easy it would be to make an MQ.
  Florian: Easy for "is it bigger than sRGB", but how much bigger?
  ChrisL: Do we want "how much bigger"?
  TabAtkins: Don't think we need anything fancy for imageset or
             picture element etc.
  TabAtkins: Just need the MQ.

  TabAtkins: The biggest issue is how to support that,
  TabAtkins: Without blowing out texture budgets.
  Florian: With unlimited resources, you would always would like to
           always use LAB.
  Florian: Might want to selectively apply to things that really
           matter, e.g. for gradients but not transitions.
  Florian: Been playing around with using half-floats as well.
  (16-bit floats)
  dino: That's implementation specific.
  ChrisL: But then your CSSOM is inconsistent.
  TabAtkins: They just come out as numbers.

  dino: It can work on MQ on-list.
  dino: I don't think there's any problem with imageset, just
        address with MQ.

  dino: Still missing bit where we specify the gamut.
  ChrisL: At one point we had an ICC profile @rule.
  TabAtkins: @color-profile.
  ChrisL: Not sure that's the best way forward, but it's one way.
  ChrisL: Images have their own tags, but if it's just a CSS color,
          then need a way to say.
  ...
  ChrisL: That has the advantage of triplet of values.
  ChrisL: The other way you'd have to specify color profile in
          addition to triplet.
  TabAtkins: Current spec has a color-correction property.
  ChrisL: That's not quite..
  TabAtkins: It can be extended, too. In any case that's what we
             have in the current draft.
  ChrisL: We can keep the section title and remove all the text.

Untagged Colors as sRGB
-----------------------

  dbaron: Has the compatibility problem there been solved?
  dbaron: Is there a browser that is shipping support for CSS and
          untagged image colors as sRGB.
  dino: Yes, Safari does.
  TabAtkins: CSS says you can use any color space as long as same
             one for untagged CSS and untagged images.
  dbaron: No, you're wrong, it says sRGB.
  TabAtkins: Everything talks about it as sRGB,
  TabAtkins: but allows you to do other things.
  ChrisL: [... something about old stuff being outdated and Apple no
          longer shipping 1.8 gamut something-or-other ... ]
  ChrisL: So we can drop the color-correction property, or repurpose
          it to do something useful.

  fantasai: Any objections?
  Florian: No but a question.
  Florian: Wasn't it for matching Flash?
  ChrisL: Flash added color correction.
  ChrisL: This is all really weird historical stuff that isn't
          needed anymore.
  Florian: Just wanted to check the reasons no longer exist.

  RESOLVED: Drop color-correction property from CSS Color

  dino: We tell the flash plugin to use sRGB so that it will match
        the colors that the page will have, because we're the only
        browser rendering in sRGB.

  Florian: I'm happy about dropping this, but I think that property,
           even though not implemented,
  Florian: Was the only thing that allowed the rest of the browsers
           to not work in sRGB.
  ChrisL: No.
  ChrisL: What it actually means is you work in sRGB, and the level
          of fidelity with which you are required to conform to sRGB
          is astoundingly low.
  ChrisL: How do you composite outside gamut stuff with other stuff?
  ChrisL: If you say it's all sRGB, it's all defined, and you can do
          the conversions.
  ChrisL: Nice, simple, consistent model.
  ChrisL: Better to express it that way.
  TabAtkins: Everywhere except color correction, the spec does say
            it's all sRGB.
  SimonSapin: Crappy monitors will still exist when everyone
              supports LAB.
  TabAtkins: Removing that section will lose that untagged images
             are in sRGB.
  TabAtkins: Need to keep that untagged images are in sRGB.
  <ChrisL> so we need to preserve that sentence

  RESOLVED: Keep sentence about untagged images being sRGB.

Specifying the Color Profile
----------------------------

  dino: So I think we're back to the last remaining bit, so someone
        should come up with a proposal for specifying interpretation
        of RGB values.
  dino: With regards to the profile, downloadable or named or
        whatever.
  ChrisL: I'm happy to add that.
  ChrisL: SVG did that by using a functional notation where the
          first three parameters were the color, and the last
          parameter told you which ICC profile was in use for that
          definition.
  ChrisL: Token was specified via @rule with URL.
  Florian: Were there predefined names?
  ChrisL: There weren't, but there could be.
  ChrisL: We can do it differently, but that's what SVG did.
  ChrisL: Plugins implemented it, no browsers though.
  ChrisL: I think it was relatively sane.
  Florian: Trial and no evidence of problems?
  ChrisL: No evidence of problems. It worked. Could possibly do
          other things.

  dino: These colors have impact on other parts of the platform, e.g.
        <canvas> and WebGL.
  dino: So.
  ChrisL: I agree that should somehow be defined.
  dino: If we invent new syntax for RGB, you set that as your fill
        style, might need to define what happens.
  TabAtkins: Need to define some way for canvas to use higher image
             store.
  dino: My proposal for WebGL is that... at the moment you get rgba
        framebuffer, could require others.
  dino: 2D Canvas has an API that explicitly returns bytes.
  TabAtkins: If you switch context-creation argument, API would have
             to change.
  dino: Or flattens if you call it.
  Florian: We can have two different APIs, one that always returns
           8bit sRGB after conversion.
  Florian: And tack on an addition API that returns all information.
  ChrisL: Flattening is not simple, there's multiple ways to flatten.
  ChrisL: So a 2nd API is better.
  dino: If haven't specified higher store.. do you magically clip
        canvas? do you ???

  ACTION ChrisL Propose color profile feature for CSS
  <trackbot> Created ACTION-728
  ACTION TabAtkins Drop color-correction property
  <trackbot> Created ACTION-729

  ChrisL: I started moving around sections in the spec, btw,
  ChrisL: To make it clearer when we're talking about sRGB or not.

  Florian: Does introducing all this stuff solve CMYK?
  ChrisL: Not really.
  ChrisL: If the syntax for an arbitrary ICC space...
  ChrisL: If the first parameter is always the token, then you could
          change it from taking 3 numbers to N numbers, and accept 3
          or 6 numbers as needed.
  Florian: Then the problem will only be device-cmyk()?
  ChrisL: That's why we needed sRGB fallback.
  ChrisL: This isn't a case of not understood, I'm fine with weird
          CMYK.
  ChrisL: The problem is computing interpolation for transitions etc.
  TabAtkins: device-cmyk() has a fallback argument. If unspecified,
             it gives a really bad fallback, but at least a fallback.
  Florian: The alternative proposal was syntax error at composition
           time...
  Florian: Does this syntax give color space first, then arbitrary?
  ChrisL: 1st parameter seems more reasonable.

  Florian: Would this support pantone colors?
  ChrisL: Yes, could have named profiles.
  ChrisL: It would be a palette.
  ChrisL: Could have named color profiles that you deal with yourself
  ChrisL: Also deals with #1 issue of "How do I name my own colors?"
  leaverou: You could also use CSS Variables.

Colors 4 Cut
------------

  ChrisL: We can kick around details after proposal is drafted.
  fantasai: We've had a draft of of CSS4 color for a long time now.
  TabAtkins: Yeah, it's time to start trimming and punting.
  fantasai: What here has 2 implementations?
  TabAtkins: None of it at the moment.
  TabAtkins: I think Servo has 8-digit hex, and I have a patch for
             blink.
  fantasai: Do we have a single implementation of other stuff?
  TabAtkins: color-adjust has at least 1 implementation.
  TabAtkins: That's it.
  fantasai: If we don't have prioritization based on implementation,
            we should survey authors to find out what's the best
            features we should add to help them.

  [discussion about color() function being suboptimal wrt syntax]
  fantasai: Trivial stuff could be pushed to implementations first,
            other stuff leave for us to work on more

  fantasai: Maybe TabAtkins and ChrisL could go through the spec and
            ask, for each feature, "Are there any open or expected
            issues/changes?" If no for both, put in L4, else in L5.
            Then implementers know what's stable and ready to
            implement, and what's still being worked on.
  fantasai: Because it seems like a bunch of stuff here is super
            stable, and others are still being worked out. Not clear
            which is which.

Color Adjustment
----------------

  dino: Designer of page might decide the result is not what they
        wanted.
  dino: The math isn't changing, it's still worth considering that
        you'd have to write another rule in your section that says,
        okay, it's a different type of adjustment I want when I'm on
        this display.
  dino: I'm actually really surprised these adjustments are popular.
  dino: I think majority of designers want this very specific color.
  TabAtkins: If you look at SASS, it's everywhere.
  TabAtkins: People give lots of talks on it.
  TabAtkins: People pick two colors, want to generate colors.
  ChrisL: Recalculates colors based on the few they picked, lots
          fewer hard-coded colors that don't mean anything

  ChrisL: Already resolved to do LAB ones
  Florian: Don't what to rathole on this too long, but for color
           adjustment function, it seems to me that this is
           independent of color space you're operating in.
  Florian: At the syntax level, want nicely lightened, or nicely
           darkened color, but then fine with storing in sRGB.
  Florian: Which is why I would like Chris's stuff to happen first.

  dbaron: Can we not have a concept that's color-adjust and another
          one that's color adjustment? It's confusing.

Scribe: Bert

Scroll Snap
===========

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue

Drop scroll-snap-points-x/y: repeat() in favor of element-snapping (Issue 10)
-----------------------------------------------------------------------------

  https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-10
  fantasai: Issue 10
  fantasai: There was a comment that element-based snapping should
            be sufficient.
  fantasai: We have implementations of the repeat syntax already, in
            some form.
  fantasai: If we want to drop it, we need to check if element-based
            actually does it all.

  Florian: Is the question whether there is content based on this?
  fantasai: No, but in that case implementers would keep their
            prefix syntax.
  dino: I'd be in favor of removing, normally, but this seems simple
        to implement so let's leave it.
  Rossen: We (Microsoft) do see usage.
  TabAtkins: We are weakly for dropping it, but won't cry.
  Florian: If there is a good way with element, then better to
           remove this less good way before people use it.
  leaverou: As an author, I think elements are simpler. I wouldn't
            use this syntax.

  mattrakow: If your snap position is interval-based: every 5th
             element, e.g., then repeat is simpler.
  Florian: But that seems fragile. Syntax shows result of a
           computation in your head, not the reason for that
           calculation.
  TabAtkins: Thinking you could container elements...never mind.
  mattrakow: You can make a script to calculate 90% of the elements,
             easier.
  Florian: If the images are oddly sized, then it can't use the
           repeat anyway.
  TabAtkins: And if you use flexbox, there may be some white space
             between them.
  SteveZ: It seems you want snap after N-1 images.
  SteveZ: Where N depends on viewport.
  TabAtkins: Actually, can use a container.
  fantasai: Can use selectors [...]
  TabAtkins: container and nth-child()
  TabAtkins: Assuming you know the number and the size.
  Florian: So, if you have that info, then you can also do it with
           elements.
  fantasai: So leaning towards dropping it.
  dino: We may complain later, but OK now.

  RESOLVED: drop 'scroll-snap-points-x/y: repeat() '

  Florian: So the whole section in the draft disappears?
  Florian: But there is an issue in that section.
  fantasai: We'll get to that.

Multiple Snap Points Per Element (Issue 11)
-------------------------------------------

  https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-11
  fantasai: Issue 11
  fantasai: Multiple snap points per element.
  fantasai: Roc answered you could add more elements.
  fantasai: Tab and I thought you might want other things beside
            snapping happening to those points, in which case
            you need elements to represent them anyway.
  fantasai: So it's simpler to have just one point per element.
  mattrakow: It seems like a useful functionality to me.

  fantasai: I'd like more feedback first, and possibly add it in
            next level.
  fantasai: I need compelling use case that cannot be solved
            adequately.
  TabAtkins: Example of canvas: shouldn't have one bigger than
             screen anyway.
  TabAtkins: Example of SVG: SVG has elements, so you can set snap
             point on them already.
  Florian: An image with people: want to snap to each person's face.
           But better to overlay elements corresponding to the faces.

  mattrakow: Did Mozilla or Apple implement snap points?
  dbaron: We have some tests for parsing.
  fantasai: Roc didn't see an issue with dropping multiple points.

  fantasai: Shall we resolve to drop the feature?
  SteveZ: Adding elements means need to change the content.
  TabAtkins: Unlikely that you wouldn't want elements there anyway,
             for other reasons.
  astearns: I'm thinking about element-based regions... :-)
  SteveZ: I agree that hover would be common, indeed.

  RESOLVED: Drop the feature of multiple snap points per element.

Snapping Columns / Grid Tracks (Issue 12/13)
--------------------------------------------

  https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-12
  https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-13
  fantasai: Issue 12
  TabAtkins: Similar to grid. You have elements, or pseudo-elements.
  [ multicolumn case could be solved with ::column, which we think
    we want anyway; grid case there's usually elements you can snap
    to already ]

  RESOLVED: Don't do anything special for multicolumn or grid.

  dino: How far away are we from ::column pseudo?
  Tab(?): If necessary, we could define it and just say it only
          accepts scroll-snap properties.

Should Apply to More Than Just Block-Level Boxes (Issue 16)
-----------------------------------------------------------

  https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-16
  fantasai: issue 16
  fantasai: Inlines can be snap targets.
  bert: What do you snap to?
  fantasai: The bounding box.

  RESOLVED: scroll-snapping applies to all elements

Do Layout Changes Resnap? (Issue 22)
------------------------------------

  https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-22
  fantasai: issue 22
  fantasai: What happens on re-layout?
  fantasai: Roc said it was hard, but Matt said people expected it.
  fantasai: Roc could live with that.

  Florian: Scroll to the end of a growing box, like our IRC log on
           the projector.
  TabAtkins: That is a different feature, sticky boxes.

  mattrakow: Proximity snap point updates are a MAY currently,
  Florian: I agree that mandatory points need MUST, but if an image
           loads late, the end of the document may disappear just as
           you were reading it.
  stevez: In case [...] I'd like to stay were I am.
  Florian: Different situation.
  Florian: There are 2 cases -- if you are already snapped to a
           point, probably want to stay there. If not snapped, then
           whether you snap after reflow or not is a different
           question.

  mattrakow: Imagine a snap element is deleted, do you snap to a
             different element now?
  Florian: I haven't seen a case where [...]
  fantasai: It makes sense that when you are already snapped to a
            point, you stay there.
  dbaron: It may that when you resize, you end up too close to the
          edge.
  mattrakow: Possibly if the snap point still exists after the
             re-layout, you MUST resnap to it.

  Rossen: We are talking layout changing, not transform, right?
  TabAtkins: Transforms are taken into account, spec is clear.
  dino: And animations
  TabAtkins: Also.

  fantasai: Proposal: Changes in the geometry of the snap point wrt
            the scroller MUST resnap to the active snap point, even
            if it is proximity snap.
  <fantasai> Proposal:
  <fantasai> 1. If mandatory, must resnap after geometry changes
  <fantasai> 2. If proximity, may resnap after geometry changes
  <fantasai> 3. If actively snapped (in either case), must stay
             snapped to that snap position (so long as it continues
             to exist).

  dbaron: You need a condition that you *can* snap to it.
  dbaron: If screen size changes, e.g.
  fantasai: Another related issue for that.

  Florian: There is a difference between proposal and what I said:
           if the element moved too far to be able to snap, and then
           moves back, do you snap?
  TabAtkins: That is separate issue of snapping beyond scrollable
             area.
  dbaron: If you are required to snap to a snap point...let's talk
          about that later.
  dbaron: I want to come back to this issue once we talked about the
          other ones.

Is DOM script-scrolling snapped? (Issue 25)
-------------------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-25
  fantasai: Issue 25
  fantasai: Everybody agrees that JS-based scrolling should snap,
            just like other types of scrolling.
  dino: You scroll to what JS said, and *then* snap?
  TabAtkins: Yes, the spec is clear on that.
  mattrakow: The spec is less specific about animation curves.
  mattrakow: Not every UA will have animations.
  mattrakow: This is better left to UA.
  dino: If js scrolls to [...] operation has no effect.
  fantasai: It seems we agree that DOM APIs for scrolling all snap.
  fantasai: And the animation is UA-defined -- just have to end up
            at that snap point.

  RESOLVED: Always apply snap after all JS-based scrolling operations.

  fantasai: Note that it may not snap if you end far from a
            proximity point.
  TabAtkins: If JS scrolls to halfway between points, do we need to
             specify where it goes? (Also inertia, but that can be
             left fuzzy).
  mattrakow: The user can usually do another scroll if result is not
             what he wanted.
  Rossen: Let's not deal too much with error cases.

When do layout changes trigger resnapping? (Issue 24)
-----------------------------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-24
  fantasai: Issue 24.
  fantasai: When do layout changes trigger resnapping?
  fantasai: I'm not sure how to say this in the spec.
  TabAtkins: "When document is stable"
  dbaron: Consider smooth scroll...
  fantasai: So question is who can write that text for the spec?
  dbaron: It may need some implementation experience.
  TabAtkins: OK, so we need something rough and then experience can
             update it.

Might be nice to have API to get snap destinations (Issue 28)
-------------------------------------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-28
  fantasai: Issue 28.
  fantasai: I'd suggest to defer this to later.

  RESOLVED: Defer issue 28.

Should start/end of scroll area automatically be snap-points? (Issue 44)
------------------------------------------------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-44
  fantasai: Should start and end edge be automatic scroll positions?
  fantasai: There has been discussion.
  fantasai: You can have the effect by having elements there.
  fantasai: Sometimes maybe pseudo-element.
  fantasai: So our conclusion was to not to automatically add those
            points.
  mattrakow: I agree with not adding implicit points.
  TabAtkins: Our proposal allows to add both edges explicitly.
  Florian: I agree, but I'm wondering if there needs to be an
           explicit switch.
  Florian: Seems you can get it through elements.
  Florian: Can still add it later in compatible way?
  fantasai: That was Tab's and my conclusion. Can we resolve?

  RESOLVED: No automatic snap point at start and end of scrollable
            area. (issue 44 no change)
Received on Thursday, 19 November 2015 01:39:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:34 UTC