- From: Glenn Adams <glenn@skynav.com>
- Date: Wed, 5 Mar 2014 18:47:20 -0700
- To: Dael Jackson <daelcss@gmail.com>
- Cc: W3C Style <www-style@w3.org>
- Message-ID: <CACQ=j+cKKdYsNsGZ+sikUT6eeyL=UH3LBhc5uHsrAbVJ90ubHQ@mail.gmail.com>
On Wed, Mar 5, 2014 at 6:17 PM, Dael Jackson <daelcss@gmail.com> 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 > http://lists.w3.org/Archives/Public/www-style/2014Mar/0103.html > - 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. > > ======FULL MINUTES BELOW===== > > Present: > Glen Adams > s/Glen/Glenn/ > 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> > 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 > 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> > 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 > 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 > > http://lists.w3.org/Archives/Public/www-style/2014Mar/0103.html > > 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