[CSSWG] Minutes Telecon 2014-03-05

Multiple Mask Layers and mask-composite

  - The group responded positively to krit's proposal for multiple
         mask layers, but expressed a desire to see it move with
         borders. Krit  and Rossen will continue the discussion on
         the mailing list.

CSS Shapes to CR

  - RESOLVED: Reject the first comment from the e-mail at
  - RESOLVED: Defer luminance to level 2
  - Astearns hopes to make the needed changes to ask for Shapes to
         go to CR again next week.

Relaxing <custom-ident> restrictions

  - RESOLVED: custom-ident is restricted only in cases where
         actually ambiguous parsing-wise. Specs referencing it
         should be clear about what is excluded.

CSS2 ED to Mercurial Status

  - SimonSapin will publish the public version of CSS2.
  - Fantasai will make sure it appears on the current work pages.

TTML WG Request

  - Fantasai and Rossen expressed that they think fragmentation will
         be able to transition to CR by the end of the year, leaving
         the TTML group in the clear.

Masking Keywords Fill and Stroke

  - RESOLVED: Change keywords to be fill-box and stroke-box.
  - Krit will take the WG's desire to the SVG WG.


  Glen Adams
  Rossen Atanassov
  David Baron
  Bert Bos
  Dave Cramer
  Bruno de Oliveira Abinader
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Peter Linss
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Greg Whitworth

  Tab Atkins
  Chris Lilley
  Leif Arne Storset

  ScribeNick: dael

  plinss: Let's get started
  plinss: Any additions?

Multiple Mask Layers and mask-composite

  krit: In the past we had multi layers for mask as we do for
  krit: We couldn't agree how to composite/combine them.
  krit: I sent a proposal to add a new property: mask-composite.
  krit: This allows us to define different compositing operators.
  krit: Each effects current level and the one below, similar to
  <krit> http://dirkschulze.github.io/specs/css-masking-1/#the-mask-composite

  krit: I created a draft, but haven't published because I would
        like to hear some feedback from the working group.
  krit: Webkit and blink already implement prefixed and there's some
        examples out there.
  krit: My keywords are the same as HTML and composite operator
  krit: I think it's a good way to combine different layers.

  smfr: You said old Webkit had this function?
  smfr: I don't remember that.
  krit: Mask-composite was implemented as I speced this.
  krit: I just added two more properties that are in webkit to be
        more similar to HTML. It now has the same 13, or it will
        have soon. I missed one.
  krit: Does anyone have concerns adding this to masking level 1?

  smfr: To specific concerns. I'm worried we're doing this before
        borders. I think we could get in trouble with applying
        things to the composite operator
  smfr: This is adding composite operator to masking and we have one
        to backgrounds.
  krit: We don't have it right now. There's a difference between
        compositing and blend. We just have blend for background.
  smfr: I'm just surprised this is getting higher priority then
        other things.
  krit: I'd like to have this in other places, but this isn't the
        topic for right now.

  rossen: Why are we putting this in level 1?
  krit: Without this we can't define different masking layers.
  krit: It makes sense to support this spec implementation-wise.
  krit: We see it in webkit already. It makes a lot of sense to have

  rossen: So it's basically a nice feature, but we don't have data
          to make a stronger statement then that?
  krit: You mean it's nice to have multiple layers or just
  rossen: I'm just trying to find out why we're adding it back in. I
          don't have another agenda.
  krit: I think it makes sense to align with background. I got
        comments to my personal e-mail to support multi-layers.
  krit: It just makes sense since background supports it and there's
        lots of similarity.

  rossen: Is it worth pursuing alignment between them?
  krit: I think that's helpful to the author to have it similar.
  rossen: Is there reason to support the similarity between
          background and masking?
  krit: It's nice.
  rossen: I'd rather have one concept for two features, not similar
          concepts for two.
  krit: The thing to do would be to support compositing on
        background and I'd like to have that conversation, but I
        think that's separate from masking.
  rossen: If we can get to a solution with one concept for both
          features, I think it's worth having the discussion.
  rossen: Otherwise, we're just making a masking-only decision and
          ignoring the compatibility.
  krit: I'm fine to have that discussion, but I think maybe on the
        mailing list first.
  krit: Or should we do it on the call?
  rossen: Yeah, mailing list first would be great.
  krit: That's fine.
  rossen: Thanks.

  <BradK> I think for level one, lower layers should just mask upper
          layers, without any special keywords.
  * fantasai bradk, mention that on the call?
  <BradK> fantasai: Sorry, I'm in and out. I just wanted to stick
          the comment in there, and it can be discussed on the
          mailing list.

  plinss: One question. Purpose of multi-image is to composite to
          one layer for one element.
  krit: Yes. You combine all mask layers to one and then apply.
  rossen: It's a type of flattening, right? A similar concept
          applies to 3D masking too?

  krit: I'll bring this back to the mailing list and we'll add
        background and borders as part of the discussion.
  plinss: To clarify, primary use case is complex mask using simpler
  krit: Yes.
  plinss: OK. We'll take this to the mailing list.
  plinss: Anything else?
  krit: No.

CSS Shapes to CR

  astearns: When I made the request to discuss this on the call
            there was one LC comment, but in the last hour we had a
            bunch of comments from howcome.
  astearns: We can take some time on call to discuss and decide how
            to address if that's okay?
  Group: Yes.

  <astearns> http://lists.w3.org/Archives/Public/www-style/2014Mar/0103.html
  astearns: First is at [url above]
  astearns: It is questioning if basic shapes should be defined in
  astearns: He said shapes in HTML should be defined there. I
            disagree. We define the basic shape function as a way to
            define how the shape displays and how it interacts with
  astearns: I don't know if I should say this comment is out of
            scope or rejected, but I don't think we should make a
  fantasai: I agree.
  plinss: I do too.
  rossen: I would vote to reject.
  plinss: The shape is the presentation. I say reject.
  astearns: Can we get a resolution?

  RESOLVED: Reject the first comment from the e-mail at

  astearns: Second comment is about empty div.
  astearns: My suggestion was to use before and after pseudo, but
           the after doesn't have the right positioning.
  astearns: I think we can change the example without empty divs
            without having to exit LC.
  fantasai: I agree.
  rossen: Or you can put the shape inside the div and call it a day.

  astearns: What I was thinking was; the example illustration shows
            a triangle which isn't in markup or CSS.
  astearns: It's contrived already and I'm going to to find a simple
            left/right mirror with triangular characteristics to
            make it a better example.
  astearns: That was just informational. I don't need a resolution
            on that.

  astearns: Last one is about using luminance of an image to define
            a shape.
  astearns: It's a fine thing to add, but I've been arguing we
            should defer it to level 2.
  astearns: Does anyone think it has to be defined now?

  smfr: That sounds similar to luminance for masking and I'm
        wondering if there should be a more generic way to say this
        is good for masking and shapes?
  astearns: At the moment masking has a luminance switch, right?
  krit: Yes.
  fantasai: It's a separate property. Perhaps it's a separate image
  astearns: I was thinking a keyword to use luminances from the
            image instead of alpha-mask.

  fantasai: Maybe in the shape-image-threshold?
  astearns: That's true. Or perhaps the image function itself could
            have an alpha or luminance switch.
  astearns: But then when you use it, it will display a luminance

  astearns: In any case, I'd still like to defer this. I'd like to
            implement and iterate without waiting for the perfect
  astearns: I think we can add this later.

  plinss: I like the idea of different image functions.
  plinss: That way you can do something like set the shape based on
          level of red.
  fantasai: Then you wouldn't use an image function.
  astearns: Unless you decide what pixels you're pulling out.
  fantasai: An image function has to return an image, that you can
            use in background-image.
  ???: Then that's defined in images and this is deferred?

  astearns: One thing that's useful is you can take an image and
            display the different levels differently which would
            allow more interesting applications.
  plinss: We're building a primitive so we can use it anywhere. So
          it doesn't belong per se here.
  plinss: That said there might be use in being able to switch
          between alpha and luminance, but I think we can get there
          when we get there.
  plinss: Other thoughts?
  <BradK> +1 for it being an image function to define what
          channel/luminance is used for alpha.

  plinss: So the proposal is defer that for a future level?
  fantasai: I think it's interesting that masking has it and shapes
  fantasai: We probably want to use the same approach for both.
  krit: The first question is do we want it in level 1, or defer it
        to 2?
  krit: That's the first thing we should answer.
  fantasai: It doesn't matter to me. I wonder about it being in
            level 1 for masking, but not shapes.
  fantasai: Not that we should necessarily add it to shapes.
  astearns: I think we should make sure that what we add in the
            future to shapes should be similar to masking now
  astearns: If we decide to have a separate switch from the image, I
            think it's easy to add that to shapes as a keyword.
  astearns: Masking has a separate property. Using the same keywords
            is enough to keep them similar.
  astearns: So masking has a property and shapes uses the same

  plinss: And would the default be alpha, luminance, or auto?
  plinss: Masking default is auto.
  krit: It's just a new keyword. For masking we needed to use auto
        for backward compatibility.
  krit: It's different for shapes.
  krit: I think it's an example that mask has alpha and luminance,
        not auto.
  plinss: In my head, auto would be useful would be if there isn't
          an alpha, but I don't know if that makes sense from usage.
  plinss: Currently if you use an image without alpha, it's just
  krit: These are examples we would need to figure out.
  astearns: To your question if there isn't an alpha, there's
            essentially no effect.
  plinss: If we have a luminance threshold, we'll need one for alpha.
          You may want the white or black to be ignored.
  astearns: That may be better served later. It may be too
            complicated for a simple keyword.

  <smfr> lumunance(invert(url(foo.png))
  <smfr> ^luminance()
  * Bert thinks it may finally be time to replace JPEG with
         JPEG2000, because the latter has an alpha channel...
  <BradK> image(url(whatever.tif) alpha-from(luminance))

  plinss: So the question is do we add this now or later?
  plinss: I don't think I hear anyone saying now except fantasai for
          consistency with masking.
  smfr: I think it's fine to defer, but I'd like it to be more
        consistent in the future.
  fantasai: I don't feel very strongly, it was just a concern.
  astearns: Okay.

  plinss: What I'm hearing is; defer to level 2, but when we do it
          keep it consistent.
  astearns: I have a note in level 2 about luminance, and I'll add a
            note saying we want to be consistent with masking and
            that we want to be able to select various because I like
            that idea.

  RESOLVED: Defer luminance to level 2

  plinss: Anything else?
  astearns: That's it except punctuation issues.
  astearns: So I need to find and fix that example and run it past
            howcome to make sure the exemple works for him.
  astearns: I'll hopefully ask for CR transition next week.
  plinss: Ok.

Relaxing <custom-ident> restrictions

  SimonSapin: In the spec we have a custom-ident that's defined with
  SimonSapin: There's a restriction that these items cannot have the
              same name as keywords in the same property.
  SimonSapin: In some cases that would cause parsing ambiguity.
  SimonSapin: There are other cases where that wouldn't happen, but
              they're still restricted.
  SimonSapin: I'd like to propose that we only restrict keywords on
              the same level.

  fantasai: Can we just say that we don't allow ambiguous keywords?
  SimonSapin: It depends on how you define ambiguous.
  fantasai: Parsing-wise ambiguous.
  SimonSapin: We can say that, but I don't know how to tell people
              to figure that out.
  fantasai: We can make a list for implementors so they don't have
            to figure it out.
  SimonSapin: So when there's custom-ident we list exactly what's
  fantasai: Yes. It's fairly straightforward, but you have to think
            about it.
  fantasai: It would be convenient to list them.

  fantasai: Will we run into this again when the custom thing only
            comes after this keyword, but you can use anything there
            and no one will parse it wrong.
  fantasai: It's not just parenthesis that cause issues.

  SimonSapin: I'm in favor of removing any restrictions we can.
  fantasai: Let's make it ambiguous vs. not ambiguous and suggest
            that specs make an explicit list.
  fantasai: Some kinds of formulation of what would be excluded.
  fantasai: So an example would be that they have something really
            complex and just say all the keywords in the property
            are excluded instead of listing one by one.
  SimonSapin: That works for me.
  plinss: Any other thoughts?

  RESOLVED: custom-ident is restricted only in cases where actually
            ambiguous parsing-wise. Specs referencing it should be
            clear about what is excluded.

  dbaron: One concern is there are cases where you have a list and
          it's only ambiguous on the first item, but we want items
          to be tab consistent.
  dbaron: I wouldn't like us to change restrictions so that you have
          have inherit as the second value, but not the first, in a
          comma-separated list.

  plinss: I agree with dbaron, we don't want that behavior.
  fantasai: I think a way to handle that is the position...I guess
            if you have a type and it's repeated or movable the
            repetition doesn't effect what's excluded.
  plinss: dbaron are you happy with that phrasing?
  dbaron: I guess so.
  plinss: I think we can move on for now.

CSS2 ED to Mercurial Status

  plinss: I was hoping plh would be here, but do we have replies
          from everyone?
  plinss: Can we merge now, or do we need to wait?
  SimonSapin: The conversion is ready, we need approval
  plinss: Every message plh sent, I saw a reply from.
  plinss: Except fantasai and I assume you're not objecting.
  fantasai: No.
  plinss: So we should go ahead and merge it.
  SimonSapin: So I should do it now?
  plinss: Yes.

TTML WG Request

  plinss: One thing I forgot to ask
  plinss: The TTML WG wants to check the status on break
  ???: What did they want to check?
  plinss: They have a use case on TTML and they want to publish.
  plinss: The goal is to not block them.
  fantasai: We should have fragments in CR by the end of the year.
            Rossen_ do you want to chat after the call?
  Rossen_: Yes.
  fantasai: We'll figure it out.

  Rossen_: I think we have half a dozen or so issues on the ML with
           additional some editorial requests.
  Rossen_: I don't think we have any technical issues left. I agree
           we should be good for CR by the end of the year.
  Rossen_: Maybe we can get to LC before the next F2F?
  fantasai: That would be great.
  Rossen_: I think they should be okay.
  plinss: I'll send that feedback then.
  plinss: Anything else?

  simonsapin: We have a public CSS2 ED, can we link to it on the
              current work?
  fantasai: Yes, I can do that.

Masking Keywords Fill and Stroke

  fantasai: On the masking spec there were keywords added during the
            last F2F, fill and stroke, to choose what box to
  fantasai: These two are inconstant because they don't end in box.
  fantasai: It's not the fill boundary or anything you're selecting,
            it's actually a bounding box you're selecting.
  fantasai: I think they should end in box for constancy and because
            that's what the represent.

  SimonSapin: I just sent on www-style; We discussed this at the F2F
              and people wanted to add new keywords instead of
              adding box.
  fantasai: I understand the concern, but it's becoming a usability
  fantasai: Because everything else in the set uses box, it's not
            helpful to anybody that these don't.
  fantasai: I'd be okay if we wanted to change -box to -something
            else everywhere if we want to do that. We'll take the
            hit on aliasing background-clip. That's better.
  fantasai: Doing these new keywords we didn't want to use box
            because we don't like the term box, that's not great in
            terms of spec wording.
  fantasai: In this case this is a keyword the authors have to use
            and our arcane arguments about what is/isn't a box
            doesn't matter to authors and they have to deal with
            this all the time.
  plinss: That makes sense to me. It makes more sense to see them as
          object-box and stroke-box.
  fantasai: We're not even using fill and stroke as concepts.
  fantasai: We're boxifying this weird shape and that's not clear
            from the keyword.

  krit: Whatever we come up with I want the discuss with SVG WG
        because they wanted just fill and stroke.
  plinss: We need to have them part of this discussion, but I think
          fantasai's proposal makes a lot of sense.

  plinss: As a follow-up, why is it no-clip instead of none?
  fantasai: The shorthand becomes ambiguous with image.

  plinss: Ah. krit can you take this to SVG?
  krit: Can we resolve that CSS wants to have it and action me to do
  plinss: Okay, any objections?

  RESOLVED: Change keywords to be fill-box and stroke-box.

  ACTION krit Take this resolution to SVG
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-620 - Take this resolution to svg [on
             Dirk Schulze - due 2014-03-12].

  plinss: Anything else?
  fantasai: I was wondering why CSS keywords compute to fill-box.
  fantasai: It seems like borderbox should compute to fill-box.
  krit: The main reason is the SVG group didn't want to use all the
        box names because stroke isn't the same as border.
  krit: At the F2F we came up with the idea that we have different
        keywords for HTML and SVG in case the user comes up with a
  krit: If that's not clear from the spec we need to rephrase.
  fantasai: It's clear. I'm just curious why we didn't want to come
            up with something more intelligent.
  krit: It was denied. Mostly from SVG WG members, but some CSS too.
  fantasai: I'd like to understand the reasoning, but we can do that
  plinss: You can take that offline?
  fantasai: Yes.

  plinss: I think that's it for this week.  I won't be on the call
          next week since I'll be attending SXSW.
  glazou: How many people at the WG will be at SXSW?
  glazou: No one but plinss? Wonderful.
  plinss: Sounds like we can have the call next week.
  plinss: Thanks everyone.

Received on Thursday, 6 March 2014 01:18:13 UTC