Re: [CSSWG] Minutes Telecon 2014-03-05

On Wed, Mar 5, 2014 at 6:17 PM, Dael Jackson <> wrote:

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

s/TTML WG/Timed Text WG/g

also FYI, the TTWG is now responsible for WebVTT REC track work

> 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.
> Present:
>   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
> Regrets:
>   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
>         background.
>   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
>         background.
>   <krit>
>   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
>         properties
>   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
>         it.
>   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
>         compositing?
>   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
>           images?
>   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>
>   astearns: First is at [url above]
>   astearns: It is questioning if basic shapes should be defined in
>             CSS.
>   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
>             layouts.
>   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
>             change.
>   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
>             instead?
>   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
>             mask?
>   astearns: In any case, I'd still like to defer this. I'd like to
>             implement and iterate without waiting for the perfect
>             solution.
>   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
>             doesn't.
>   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
>             keyword.
>   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
>           opaque.
>   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
>               identifiers
>   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
>               excluded?
>   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
>             reference.
>   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
>             issue,
>   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
>         it?
>   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
>         difference.
>   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
>             later.
>   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?
>   [Silence]
>   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:48:10 UTC