W3C home > Mailing lists > Public > www-style@w3.org > July 2014

[CSSWG] Minutes Telecon 2014-07-30

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 31 Jul 2014 11:40:52 -0400
Message-ID: <CADhPm3vg4xQfRBn2-NUuAuXxkEHcEOEBJfhvwowo-06TnC6zVQ@mail.gmail.com>
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
  - 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.


  - RESOLVED: Floats are passed up through Ruby to the containing
  - 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 ======

  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

  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?
  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
  dbaron: Animations do affect the computed value,
  smfr_: So it would make sense for em size to be affected by font
  dbaron: That's not the question. It's em size inside the keyframe
  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
  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

  <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
  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
  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

  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
  dbaron: We're doing it, but where and when do computed values come
  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
  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
  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.


  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
  <fantasai> 2. Floats inside ruby
  <fantasai> 3. Bidi of ruby
  <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?
  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
  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
  SteveZ: Floats has an alignment issue. It says it can't be before
          the first thing. Would that make a difference in this
  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

  <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
  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
  * 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
  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

  <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"
  <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

  <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
  <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
  <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
  <liam> four-colour separation software may do some of that, and/or
         "preflight" software.
Received on Thursday, 31 July 2014 15:41:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 31 July 2014 15:41:20 UTC