- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Nov 2015 20:38:22 -0500
- 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