- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Mar 2014 20:17:45 -0500
- To: www-style@w3.org
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.
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
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:18:13 UTC