- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 31 Jul 2014 11:40:52 -0400
- To: www-style@w3.org
Animations Issues
-----------------
- The main remaining issue from the previous telecon regarding
Animations revolved around computing values in keyframes.
- dbaron and sylvaing took turns explaining the issues and
complexities when there are multiple properties with a
different number of values.
- The group came to two conclusions for handling missing values;
interpolate what the value should be from the given values or
use a value from the non-animated state.
- No definitive conclusion was reached, but the leaning was toward
interpolation.
- Discussion will continue on the mailing list with an e-mail
summary from sylvaing.
Specifying options for scrollIntoView()
---------------------------------------
- Discussion will continue on the mailing list.
Flexbox and Overflow
--------------------
- Discussion will continue on the mailing list.
Ruby
----
- RESOLVED: Floats are passed up through Ruby to the containing
block
- RESOLVED: Publish a new WD for Ruby
Renaming gray()
---------------
- leaverou presented her findings from a poll seeking to rename
gray() to a less confusing name.
- The poll gave clear results in favor of rgb() and rgba(),
however the working group had a concern that this would be
confusing for new authors.
- RESOLVED: accept rgb() with single values and rgba() with 2
values and keep exploring other potential values
- Discussion continued after the call on IRC to try and find a
non-confusing and author friendly solution.
===== Full Minutes Below ======
Present:
Glenn Adams
Rossen Atanassov
David Baron
Adenilson Cavalcanti
Alex Critchfield
Elika Etemad
Simon Fraser
Sylvain Galineau
Dael Jackson
Brian Kardell (IRC only)
Brad Kemper
Peter Linss
Mike Miller
Edward O'Connor
Anton Prowse
Matt Rakow
Simon Sapin
Alan Stearns
Lea Verou
Steve Zilles
Regrets:
Tab Atkins
Bert Bos
Dave Cramer
Bruno de Oliveira Abinader
Chris Lilley
Florian Rivoal
Scribe: dael
plinss: Let's get started.
plinss: Anything to add to the agenda?
[silence]
plinss: That's a no, I guess.
* fantasai had sent a few agenda+ earlier
Animations Issues
-----------------
sylvaing: This was an old issue about the shorthands and
sub-properties that aren't available. As dbaron pointed
out there's a bunch of sub-issues that need resolution.
At least 2, maybe a 3rd
sylvaing: The first is that in general the computed value can
depend on other computed values. So if you have a font
size and set an resolution of 2em, the font size affects
that. Do we do that in keyframes?
sylvaing: Second issue is that in other implementations we ignore
non-implemented properties. So do we apply in a
keyframe? If you have border-start: none and set a
keyframe, does that reset to 0?
sylvaing: Third issue is from a resolution a while ago. How do we
animate non-animatable properties? There my
understanding was that it would be animations and
transitions, but dbaron says it's only animations.
sylvaing: dbaron am I missing anything?
dbaron: There's complications to the second issue, but we can get
there at some point.
* dbaron now wonders if he meant first issue
sylvaing: So first we have a keyframe anywhere in the animation.
Example: we have font size of 42px and an indent of 2em,
do we resolve the keyframe as a regular rule applied to
the element?
sylvaing: I think yes. It would be surprising if the rule works
one way inside a keyframe and differently outside.
dbaron: One complication here.
dbaron: The way animations work is that you animate each property
separately. So if you have a three part property and you
have 0% property that specifies all properties, but a 50%
that's only 2 properties, you animate the first as if it's
only at 50% and the second from 0% to 100%. One model to
address this is the keyframe is a style rule.
sylvaing: I believe this is what authors think happens.
dbaron: Maybe. It produces weird results in that case. If you're
animating font size in em and you're doing something else
in em units in the keyframe, you'd do the em units at 0
against 1em and 3 against 3em.
sylvaing: I don't think it's necessarily weird. If you're
animating the width of something and the container is
changing width, they'll interact.
sylvaing: I agree that if you think of animations as each property
in its own keyframe, then I think the current behavior
makes sense, but I'm not convinced that's how authors
think about it. The keyframes are like a selector. It's
a rule with a bunch of prop that apply together. So it's
surprising if font size is 16px and if you use 2em, it's
different if you move within a keyframe.
dbaron: Maybe. I'm curious what others think.
sylvaing: Me too. If folks like leaverou or other users are on the
call that would be great.
smfr_: Anything about how the children of things are being
animated?
dbaron: Animations do affect the computed value,
smfr_: So it would make sense for em size to be affected by font
size.
dbaron: That's not the question. It's em size inside the keyframe
itself.
smfr_: I think that if inherit works, I think em size would. I'm
not sure I understand the implications of your example.
smfr_: It seems when you're doing em size in a 50 keyframe, it
seems you would pick half way between 0 and 100.
dbaron: We need an order to resolve prop dependent cycles in order
to resolve animations properties in correct order.
smfr: Isn't that true of style positions anyway?
dbaron: Maybe. We'd need to explicitly have code to know that in
this case. We don't now.
* fantasai is super confused
* leaverou is too
* bkardell_ is also confused
<leaverou> Some code showing the issue we're trying to decide
about would be useful, since so many here are lost.
dbaron: I think the model...keyframes are a bit weird because you
only use the stuff out of them that was specified in them.
Properties not specified in the keyframe aren't overridden
by the animation so they're different from the rest of the
cascade.
smfr: So if I animate the font size and have stuff outside in em
it's not affected?
dbaron: That's affected. Keyframes are different from rest of
cascade because it matters what's specified or not that
doesn't normally matter. It affects if the animation
chooses to override during that period of time
dbaron: Especially if you have multiple animations running.
<bkardell_> dbaron: I agree that is weird.
plinss: It looks like there's a lot of people lost. Is there an
example we can put in IRC?
sylvaing: We can do the one in the thread.
dbaron: A simple example is which.
<sgalineau> #a { animation: a; font-size: 16px; }
<sgalineau> @keyframes a { 0% { font-size: 32px; text-indent:
2em } }
<sgalineau> Does the font-size: 32px inside the keyframe change
the value of
<sgalineau> text-indent (and make it 64px rather than 32px)?
<sgalineau> original thread
http://lists.w3.org/Archives/Public/www-style/2014Jul/0297.html
<leaverou> If font-size in the animation supersedes the one in the
rule, I'd expect it would also apply to ems. Otherwise
it would be super confusing.
<sgalineau> leaverou: right.
<sgalineau> leaverou: I think authors expect keyframe rules to
apply like other rules. In practice, it's as if each
property gets its own @keyframes rule
<bkardell_> sgalineau: FWIW, that is what I would expect as an
author :)
<leaverou> I think if the link between font-size and ems is
broken, this is going to be very confusing
Rossen: So if we have font which is animating at 1/3, let's say
30% from 2em to 1em
Rossen: And to the 100% is to 3em. It goes 2 to 1 to 3.
<Rossen_> 2 > 1 > 3
Rossen: And than we have animatable which is in em which goes
the opposite and snaps on the 1/3 which is in the middle
of the 2 to 1 animation of the font.
Rossen: So the q is, what would be the resolution at the 30% of
the property that's animating in em if the font is being
animated from 2 to 1 in the same time?
Rossen: dbaron, is that the right representation of your point?
dbaron: I didn't follow.
fantasai: Can you type it in CSS code?
plinss: Are you typing, Rossen_ ?
Rossen: Yes.
dbaron: I'm typing a different example as well.
<leaverou> So I'd expect em to animate as the font-size is
animating, as well as animating from 2 -> 3
<dbaron> @keyframes a { 0% { font-size: 32px; width: 10em }
50% { width: 15em } 100% { font-size: 64px; width: 20em}
} #elem { animation: a linear 5s; font-size: 16px }
sylvaing: So in dbaron's example I would expect width to be 120.
At 50% the font would be between 32 and 64, 15x48, I
guess?
sylvaing: At 100% 20x64
dbaron: What about if the animation had two things running, the
lower affecting font, upper affecting width?
fantasai: I think yes. I think it's at each point in time, take
the combo of all rules and interpolate as needed.
dbaron: That gets really complicated.
<leaverou> dbaron: To understand or to implement?
sylvaing: What's more complicated for authors? Combine them or
think as each being split into logical keyframe rules?
It gets complicated in both directions. It's complex
enough, but thinking of each property you're animating
getting a logical keyframe is a bit...
<dbaron> @keyframes a1 { 0% { font-size: 32px } 100% { font-size:
64px } } @keyframes b { 0% { width: 10em } 50% { width:
15em } 100% { width: 20em} } #elem { animation: a linear
5s, b linear 8s; font-size: 16px }
sylvaing: So we're 25 minutes in. If it needs more email
discussion, that's fine. Like TabAtkins, I'm in favor of
creating keyframe rules like @ rules to min surprises
fantasai: leaverou asked in IRC if it's complicated to understand
or implement?
* leaverou thanks fantasai :)
dbaron: I'm pretty sure it's complicated to implement. It might be
impossible, but I'm not sure. I think it's also hard to
understand.
fantasai: I think anything else is hard to understand, but I can't
speak to implementation.
<bkardell_> +1, I can't actually see another way that is more
intuitive
smfr: I think this is a fix for something that isn't encountered
much. leaverou's case with the border shorthand is a more
common thing to talk about.
plinss: Let's see if we can wrap this up. Back to dbaron's first
example: You're animating font size in first and last, but
not middle, but doing width in all. So over the whole
animation you're changing the font size, so I don't see
why the em size isn't changing.
<leaverou> +1 to plinss
dbaron: I think current behavior is you apply each rule and you
extract values.
plinss: So at 50% you're applying the full the set width, but the
other keyframes are still involved?
<Rossen_> @keyframes a {0%{font-size: 20px; width: 10em} 33%{
width: 20em } 66%{font-size: 20px;} 100%{font-size:
30px; width: 30em}}
sylvaing: So then the animation, we're not animating computed
values?
dbaron: We're doing it, but where and when do computed values come
from?
fantasai: I understand better. We have a missing font size in the
middle keyframe. One option is to compute from the other
keyframes. The other option is to take it from the style
rule without the animation because in this keyframe we
weren't given a value.
<leaverou> IMHO the 2nd option is sure to cause a lot of WTFs
dbaron: I don't think it's that simple. You have to decide if the
base includes other animations or not. And if you try and
include things from other animations in the base value,
you need to consider when and that can make animations
jump in odd ways.
fantasai: I think the two things that make sense is you
interpolate whatever is missing and do your computations
from there. Or in a given animation you want to have a
value for every property mentioned and anything missing
comes from the un-animated state.
fantasai: Things that don't take the value from the current state
seems confusing.
sylvaing: So you're saying animations don't influence each other?
fantasai: Well, we should take all the rules, apply the cascade
and do the animations like that.
sylvaing: So if A is doing font size and B is doing width in em,
you're saying that B is based on the width before
animation, but if width is together with font size, the
width is effected during the animation?
* dbaron didn't follow what fantasai said
fantasai: I think that's straightforward to understand. I think
the first is better, but if it's not often used, it's
fine. I don't know how to have the animations rules
interact in a different way from taking all the values
and interpolating. I understand A and B, but you're
saying there's other more complex options?
fantasai: A is take all the rules that apply from all animations
at a given time and interpolate. B is if you have an
animation that's missing values from keyframes, grab
them from the non-animated state.
dbaron: I think there are other options like if you do one at a
time from lowest to highest.
* leaverou does not understand how anybody would support B. It's
completely unexpected and confusing.
sylvaing: Okay. We can go back to the ML.
fantasai: It's nice to have a summary of the options.
<bradk> If Width is not affected by font-size during the
animation, does it jump at the end of the animation?
Rossen: One more question. dbaron, in your example what would it
request the animation frame to return? If I try and get
the use values?
dbaron: That just gets your callback at a certain time.
Rossen: So would you expect it any different?
Rossen: The way you would resolve the callback vs the two
animation lines? In your second example.
dbaron: Okay.
Rossen: In it if you request animation as, say 4sec in B, which is
about 50%,
Rossen: What would you expect the use value for width to be?
dbaron: That's what we're trying to decide. Basic options are if
it's based on...
Rossen: What would your implementation do today?
dbaron: 15em x 16px.
dbaron: And I think that might be inter-operable
<dbaron> I think
Rossen: I wouldn't expect a decision that would counteract too
much something that's inter-operable. I think there's
content that depends on that.
<leaverou> with that logic, non-animatable properties being
dropped from keyframes is also interoperable, but we
resolved against it
plinss: I hear you, but if this is under-specified, we may want to
fix it now.
Rossen: Sounds fair, but let's not ignore that.
plinss: If everyone has interop, maybe we have to live with it.
plinss: Can someone write up a straightforward example for the ML?
sylvaing: I can start a new thread with the options we've
discussed and dbaron can expand.
plinss: Did we get to the border issue?
dbaron: I think the border issue is the same, but involves
non-animatable properties.
dbaron: So this is the border issue simplified.
Specifying options for scrollIntoView()
---------------------------------------
plinss: Who wants to talk on this one. Do we have TabAtkins?
fantasai: No.
dbaron: I might be able to talk on it, but TabAtkins recently
responded. Let me see.
dbaron: So. There's something in the CSSOM spec that doesn't make
sense and we want to implement that thing so we need to
have it make sense. I think. Am I changing topic here?
dbaron: Maybe. This is a slightly different thread. This isn't the
one I asked for. I'm commenting on the "and related" part,
but I don't know we'll get far without TabAtkins and
zcorpan.
plinss: Want to come back to it?
dbaron: I guess, but there's a chance we'll have something
implemented before then.
plinss: So is there a concrete proposal?
dbaron: There was, but TabAtkins said he doesn't like it, but not
on the public list.
plinss: We'll aim for progress on the mailing list.
Flexbox and Overflow
--------------------
plinss: Can we do this without TabAtkins?
fantasai: I'm here, but I don't know if I can do it. Basically the
issue is that we normally have the overflow, you can't
scroll to the start direction, just the end if it
overflows. If we're aligning we go to the end side.
fantasai: So with flex box should that be flex direction relative
instead of writing mode?
dbaron: And if you use a *-reverse keyword they're the same thing.
Rossen: And with writing mode vs flex direction, fantasai hit the
point. I agree with TabAtkins that if we're using flex
direction as the origin of start and end for flow, what
Chrome does today makes sense. If we don't, IE and Firefox
makes sense. For implementation from our point of view
it's easy one way or the other, but we have to decide on
preference.
fantasai: I think...I'm leaning toward writing mode relative and
maybe take into account content alignment and scroll in
alignment direction. Reverse should be ordering and page
should layout as before, but I haven't thought much on
it yet.
Rossen: That wouldn't help in the overflow case.
Rossen: So take this to the ML?
fantasai: I think so.
Ruby
----
fantasai: I sent a mail earlier about 3 issues in Ruby.
fantasai: First one is inlinizing.
<fantasai> There are three issues I would like the CSSWG to review
and approve:
<fantasai> 1. Inlinizing rules
http://lists.w3.org/Archives/Public/www-style/2014Jul/0028.html
<fantasai> 2. Floats inside ruby
http://lists.w3.org/Archives/Public/www-style/2014Jul/0392.html
<fantasai> 3. Bidi of ruby
http://lists.w3.org/Archives/Public/www-style/2014Jul/0191.html
<fantasai> Issue is inlinizing rules
<fantasai> Probably someone can just read that email.
fantasai: So this is an inline item and you break between lines so
it would be easy for a ruby space to contain a block
element but it's bad because you can't break across
lines properly. If you have a block level thing inside a
line element, you have split behavior. But Ruby
structures are complicated.
fantasai: So to deal with this, which seems to have no use case, I
added a line saying if you have block level, you change
its computed display type to inline level.
fantasai: I wanted to check with the WG if that makes sense or if
you want to do something different.
plinss: For Ruby that makes sense to me. Any other opinions?
[silence]
plinss: I guess not.
fantasai: Related, if you have in your annotation a forced line
break character, the white space automatically gets
collapsed because I didn't know what to do to linebreak
the annotation, but not the whitespace. I can revisit
that if there's a more useful behavior
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0392.html
fantasai: The next issue was floats inside Ruby. One option is
they go passed up to the containing block. Or we ignore
floats.
fantasai: TabAtkins prefers the first. The goal is to make them as
much like inlines as practical.
<dbaron> I think it makes sense to pass them up to the containing
block.
SteveZ: Floats has an alignment issue. It says it can't be before
the first thing. Would that make a difference in this
case?
fantasai: I'm not sure. It would be aligned to the line box. It
shouldn't be higher than top of line box, right?
dbaron: Yes.
SteveZ: Cool.
RESOLVED: Floats are passed up through Ruby to the containing
block.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0191.html
<fantasai> http://dev.w3.org/csswg/css-ruby/#bidi
fantasai: Next is bidi. There are two constraints from Ruby. They
need to be contiguous. Ruby annotations must stay with
their bases.
fantasai: Simplest is to force bidi isolation which means they
can't be split up. The rule for ordering is use the
direction property of their container.
fantasai: Is there any comments? Want to think more? Does that
seem fine?
plinss: Anyone?
SteveZ: If I wanted to split, I can break Ruby into chunks?
fantasai: Yeah.
dbaron: Does bidi use the direction of the property? Is there
direction associated?
fantasai: Yes. If you are doing odd things in Ruby with bidi and
you're not tagging with correct direction attribute
things won't look good.
dbaron: But only if you're doing mixes inside Ruby.
fantasai: Basically, if the Ruby element doesn't match the
element, it'll go bad.
SteveZ: So if you're annotating Latin with Arabic, I should be
careful?
fantasai: Yeah. I think that's reasonable. I think you'd need to
tag that even if it wasn't Ruby.
plinss: Okay.
plinss: Anything else on Ruby?
fantasai: I re-wrote whitespace handling. No one was interested on
the list. If people want time, that's fine, but I think
we need a new WD.
Rossen: Yes, we do want to review.
plinss: Before a new WD?
Rossen: No. You can do a new WD.
plinss: This is just a standard publication of a new WD?
fantasai: Yep. No where near a LC.
plinss: So any objections to a WD?
RESOLVED: New WD for Ruby
fantasai: Can a staff contact help me with that tomorrow, or are
they all off?
fantasai: Okay. I'll send it to Sheppard.
plinss: You might CC Bert.
fantasai: Okay. Thanks.
Renaming gray()
---------------
leaverou: The thing is in CSS level 4 there's gray() that goes
from 0 to 100%, which is black to white. I suggested it
should rename to white or black since it's strange that
gray(100%) is white.
<leaverou> http://lea.verou.me/2014/07/an-easy-notation-for-grayscale-colors/
<leaverou> https://docs.google.com/forms/d/1pp3RY-A4MAs7b-gmqFx6bKn52_G_WLoPFkV0vueiWP4/viewanalytics
leaverou: I also posted a poll (above) with 246 responses and
surprisingly mostly people wanted rgb() with 1 argument
or rgba() with 2 arguments
leaverou: It seems that was the consensus, which I find strange
since the others are more understandable, but this is
what authors liked.
<leaverou> https://docs.google.com/spreadsheets/d/1XJU1jOLb-6ifvkUqK1Y_bsHx9r09aWApce18SkWryFc/edit#gid=166170944
leaverou: If you want details, they're in the spreadsheet above.
leaverou: There's a lot of "other" responses because originally
there was rgb() with 1 or 2 arguments, but I changed it
so those votes became other. If you count the other
votes, it's even larger.
* fantasai notes the spreadsheet is locked
plinss: It does follow our pattern of repeating missing arguments.
MaRakow: I also like the rgb/rgba(). It looks more familiar.
SteveZ: The question is would they expect it for the other color
functions? That's more difficult.
SteveZ: If I do different colors than rgb, would they still want
one element in the gray direction?
leaverou: I'm not sure. Like hsl() with one argument? I saw one
comment, but only that.
fantasai: I think that makes sense. The rgb to get gray you write
50% three times and you're just short handing. For HSL
gray isn't 50% three times. I think it makes sense for
RGB, but not HSL.
SteveZ: That's where I was coming from. I can see people asking
for it.
<sgalineau> On the other hand, shorter # values and shorter rgb()
values will do different things? not sure if that
matters.
* MaRakow #7 == #777 == #777777 ?
* MaRakow #78 == #7778 == #77777788?
* Rossen_ #78 == #7788 == #777888 :)
leaverou: Many suggested what MaRakow suggested which is repeated
single digit text values.
SteveZ: It certainly makes sense, I was worried we're creating a
precedent.
leaverou: In HSL arguments aren't repeated so it's not the same
pattern. HSL 50, 50, 50 means nothing.
SteveZ: I understand.
* fantasai can't remember why we rejected 2-digit hex
<TabAtkins> No way to add alpha
<fantasai> TabAtkins: 4-digit hex ?
<TabAtkins> Right, no way to do gray hex with alpha.
<TabAtkins> 4 digit hex is adjust rgba
<fantasai> TabAtkins, ????
plinss: So I'm not hearing objections to adopting rgb()/rgba()
BradKemper: I think that's useful for existing authors, but for
new people it's not intuitive.
BradKemper: I'm wondering if we could have black with one argument
that's an alias. Are we restricted to picking one?
leaverou: I agree. I think rgb() is the least readable.
BradKemper: I think they're seeing it as an abbreviation of what
they've been doing for gray. It's not the most readable
leaverou: Any reason we can't have both?
plinss: Black wouldn't make sense be because it's the opposite,
but white works.
leaverou: Black got the second most votes.
* fantasai thinks we need ranked choice here, if we didn't have
gray, would those ppl vote white or black?
BradKemper: I think with black it's the opposite of RGB. If you're
doing 255 you'd expect the opposite.
plinss: I wouldn't want opposite directions.
plinss: So I think we expect single values for rgb() and 2 values
for rgba().
BradKemper: Maybe for black and white we accept only single values?
leaverou: If we do black, would that be a special value for print?
plinss: I think colors would need to be in the same space unless
we're specifically doing something for print.
RESOLVED: accept rgb() with single values and rgba() with 2 values
and keep exploring other potential values
plinss: Thanks everyone.
After call conversation on gray()
---------------------------------
<MaRakow> Actually thinking more, probably #78 == #787878 would
make more sense, rather than #77777788
<MaRakow> maybe
<fantasai> yes
<fantasai> The double digit should be a unit imo
<leaverou> MaRakow: the reasoning against these was that #xyz
expands by digit, not by repetition
<leaverou> so inconsistency
<fantasai> it's 3 values, it kinda has to.
<fantasai> repeating wouldn't make any logical sense
<fantasai> hm
<MaRakow> yeah, i'm just thinking out loud. haven't really looked
at this before
* fantasai neither, really...
<hober> I think we should just keep it as gray()
<glenn> +1
<antonp> grayshade
<hober> see e.g. Core Graphics' CGColorCreateGenericGray()
<antonp> or something similar
<hober> CGColorRef CGColorCreateGenericGray (CGFloat gray, CGFloat
alpha);
<fantasai> gray(100%) is black?
<leaverou> it's white
<fantasai> oh
<fantasai> ~_~
<antonp> haha that's gonna confuse me a ton
<leaverou> gray(0%) is black
<fantasai> I know! Do a poll
<leaverou> lol
<fantasai> On your first instinct, gray(100%) is a) black b) white
<fantasai> If you get 90% answers on one answer, go with gray()
<fantasai> otherwise, I think it can be considered a failure
<fantasai> and you have to reject it and find a different name
<SimonSapin> fantasai: "On your first instinct, gray(100%) is
a) black b) white", that could include c) "medium"
gray
<hober> yeah, obviously gray(100%) is the grayest gray :)
<liam> gray in colour is a shade rather than a tint usually, so 0%
would be white
<fantasai> SimonSapin: an interesting point, but I think that
makes it awkward to have the range 0%-200%
<SimonSapin> fantasai: of course. Which is why gray() doesn’t work
IMO
<liam> gray(200%) should be blue with pink stripes. Keep the
b*stards guessing. Better is black(50%)
<leaverou> I would love black() even more if it also corresponded
to device-cmyk(0,0,0,x) in print. Currently, I think
printers convert RGB grays to use all the inks, which
is super wasteful.
<liam> depends on the printer driver / RIP
<liam> some can do UCR too, and some not.
<leaverou> cheap home printers?
<SimonSapin> I don’t think it’s CSS’s job (in a feature not
related to printing) to work around cheap printers
being stupid
<SimonSapin> would it make sense to have both white() and black(),
even though they’re technically redundant?
<leaverou> IIRC device-cmyk() is converted to rgb with the naïve
conversion anyway, which I believe would convert
grayscale colors to proper RGB grays. So we could
define black() as a shortcut to device-cmyk(0,0,0,x).
But then there’s no opacity :(
<SimonSapin> should we have device-cmyka() too?
<leaverou> SimonSapin: Let’s turn all the CSS colors into
functions!!!1!1 :P
<fantasai> device-cmyk(0,0,0,50%) is not 50% opaque?
<leaverou> fantasai: Not unless we implement some form of
overprint
<leaverou> (which btw, is sorely needed)
* fantasai doesn't really understand how device-cmyk() is supposed
to work
<leaverou> it's just a different color space. 50%K is not semi-
transparent, just like rgb(50%,0,0) isn't
<liam> k is black, not opacity
<fantasai> I know, but if you're spilling black at 50% of its
dispersal, is it opaque?
<fantasai> Like, 50% black on orange paper is somewhat orange, is
it not
<fantasai> if you printed orange ink under it, that would be the
same, no?
* fantasai is taking device-cmyk too literally
<leaverou> fantasai: If you overlay a 50% K div over an orange
div, it wouldn't be affected unless you overprint
<leaverou> and there's no standard way of overprinting right now
AFAIK
<leaverou> in practice, what would happen
<leaverou> is that the print formatter would create a "hole" in
the orange div
<leaverou> and print the gray on top of it
<leaverou> you can see that a lot in magazines and stuff
<leaverou> when the designer forgot to overprint
<leaverou> and the letters aren't completely aligned
<leaverou> (because perfect alignment is rare)
<leaverou> and you can see the white "hole" underneath them
<leaverou> fantasai: ^^
* fantasai nods
<leaverou> fantasai: Does it make sense?
<fantasai> yes
<fantasai> I'm aware :)
<liam> 50% black on orange paper will show up as a pattern of tiny
dots usually, like newsprint
<liam> (or on any other colour paper)
<SimonSapin> does alpha blending make sense in cmyk space?
<leaverou> SimonSapin: Why not? InDesign/Illustrator support it
<leaverou> I believe print formatters implement their own
proprietary overprint properties, or nothing at all
(not sure about AH, but I believe Prince has a property
for it)
<liam> printing inks used for commercial offset litho (the basis
for CMYK) are opaque at around 80% depending on dot gain (
how absorbent the paper is) but lower values are simulated
by dots, and the lower colours show though the dots. Black
is printed underneath.
<liam> well, you also need trapping support (avoiding sharp
corners), and support for avoiding too much ink at any
pixel
<liam> four-colour separation software may do some of that, and/or
"preflight" software.
Received on Thursday, 31 July 2014 15:41:20 UTC