Masking Level 2
---------------
- RESOLVED: krit can make a wiki page for masking level 2 ideas, but
not an editor's draft yet.
Filter Effects
--------------
- RESOLVED: Filters apply to everything (except CSS image filter), and
remove issue 3 from filters at this level without
addressing the issue.
Prefixing Policy
----------------
- RESOLVED: SimonSapin will edit, with input from fantasai.
- The group spent some time discussing what conclusions the previous
conversations about prefixing had come to and what the status
of snapshot was.
- Plinss took an action to update shepherd so that it produces
something closer to a live index.
=====FULL MINUTES BELOW======
Masking Level 2
---------------
ScribeNick: Liam
krit: We have CSS masking level 1 in last call.
krit: I want to ask officially to create an editor's draft for level 2
masking.
krit: We deferred having different layers for masking, and some other
things.
dbaron: Does the ED need a cautionary statement?
krit: Yes.
krit: It's just to collect ideas.
fantasai: How about a wiki page instead?
krit: OK
krit: We already have spec text but I can make a wiki page if that's
preferred.
Chris: Is there implementation impetus?
krit: Multiple layers are shipping in webkit
(prefixed)
dbaron: Given it's shipping in webkit I'd argue for an ED at least.
fantasai: But we want to change how it works.
dbaron: Are we able to change how it works?
plinss: It's prefixed.
krit: In webkit the un-prefixed versions don't have multiple layers.
fantasai: The issue with multiple mask layers was that there weren't
different options for compositing; it was only intersection.
Since we aren't sure we actually want the thing that was
removed, probably shouldn't have a formal spec drafted up
for it; just put the issues and ideas in the wiki for now.
RESOLVED: krit can make a wiki page for masking level 2 ideas, but not
an editor's draft yet.
Filter Effects
--------------
[discussion of when to discuss filter effects => probably fx time on
Tuesday]
<krit> http://dev.w3.org/fxtf/filters/#issue-92cd9a9b
krit: We have background, border, content; How to filter just some of
these things?
chrisl: ::border, ::padding ?
krit: We should find a common way to specify as well as describe this
effect; I'd like to remove this issue from the spec.
krit: There are proposals for how to make multiple layers for just one
element.
dbaron: You might want things more powerful than just selection.
dbaron: E.g. I was thinking of a model like SVG filter inputs model,
dbaron: Where you have filter inputs for background, order and
content.
dbaron: The idea of SVG filter inputs with stroke & fill etc. seems
like it could extent to border and background.
krit: That's a backdrop, I'd say, separate term.
krit: I don't think we can find a solution for level 1, so I'd like to
defer it to level 2 or to combine specifications.
krit: Proposal: filters apply to everything (except CSS image filter),
and remove issue 3 from filters at this level without addressing
the issue.
[discussion of use cases for applying filters to different parts]
chrisl: The only thing missing is a way to say fo example that I only
want to apply this filter to the border-image.
fantasai: People want to do things to individual background layers,
the background as a whole, the border by itself, the
background and border as a unit, the content and not the
background, etc.
fantasai: Could we just come up with keywords for each of these
things?
krit: This is something you don't want to address just for filters,
but also with backdrop, and define a general way to specify it,
not just add more keywords to every property.
krit: There is a wiki page in the fx task force about this problem.
fantasai: I'm concerned we might be filtering ourselves into a corner
for the future.
plinss: Maybe we want to change the name of the filter property so
that we don't get stuck, e.g. filter-all.
[discussion of background-opacity]
RESOLVED: Filters apply to everything (except CSS image filter), and
remove issue 3 from filters at this level without addressing
the issue.
<dauwhe_> we're more resigned than resolved
<liam> :)
Plinss: Can we leave the issue in place?
krit: I don't think we can find a solution to issue 3 in this spec at
this level.
Plinss: OK. Anything else on filters?
(no)
Plinss: The next on agenda is WD of transforms
krit: Can we do all fx stuff on Tuesday?
(ok)
Prefixing Policy
----------------
fantasai: Didn't we solve that already and it did not get written up?
SimonSapin: I added it to the agenda.
SimonSapin: My understanding is the working group policy is still
officially to recommend prefixes
Many: no
fantasai: No, it hasn't been since the meeting in Paris in 2012.
SimonSapin: The most recent I could find is the 2010 snapshot
sylvain: Yes, you're right, nothing published since then.
fantasai: It's on my todo list
fantasai: The principle is that, you don't release prefixed problems
until CR.
Chris: The process is being changed, CCPR
Liam: I think so, but I'm not 100% sure
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0894.html
fantasai: Apple/webkit and IE still sticking to prefixes.
SimonSapin: If we had wg consensus last year, we should have that
published somewhere easier to find.
SimonSapin: At least on the wiki, if not in the snapshot.
<dbaron> https://twitter.com/csswg
<fantasai> http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/
plinss: We don't want you to ship something unprefixed before the WG
is ready.
chrisl: Should we still spend effort in snapshot?
fantasai: It's a lot less useful than it was.
dbaron: Especially since it's not rec-trac.
<SimonSapin> http://www.w3.org/blog/CSS/
fantasai: A large part of snapshots was to work around problems we
were having in the W3C process, representing features that
were in browsers & stable.
fantasai: The problem now is we have tons of untested features so
don't know what's snapshot-ready.
chrisl: Either we document we're no longer doing snapshots or we fix
the existing one.
chrisl: Snapshot is currently dated 2010 and it's nearly 2014
fantasai: The index of properties, glossary, still useful,
fantasai: So I want to see it updated.
plinss: But we don't need to call it a snapshot or track [all] the
specs.
fantasai: The goal was, this was the stuff "you can rely on as an
author" to be stable enough, but not rec because there are
no tests or interoperability tests.
plinss: I'm most of the way to an infrastructure.
plinss: Shepherd is parsing most of the specs now and keeping track of
definitions, properties, @-rules, values, the data is there,
plinss: So it's trivial to produce a list of what's in CR.
dbaron: It sounds like snapshot has prose in it that doesn't reflect
our current thinking.
chrisl: CSS snapshot should be republished with explanations updated
for prefix policy, and process, and removing the indexes to
point to an external index once we have one.
plinss: I can do that fairly soon.
<fantasai> http://www.w3.org/TR/CSS/
fantasai: Can you make an index of selectors automatically?
plinss: Not currently. The tool doesn't yet deal with them, but they
could be added if we add markup to the specs.
<krit> first time that I ever looked at this document :P
ACTION: peter to work on shepherd to make it produce indexes
(including selectors) for a "snapshot" or live index
<trackbot> Created ACTION-590 - Work on shepherd to make it produce
indexes (including selectors) for a "snapshot" or live
index [on Peter Linss - due 2013-11-17].
bert: I want a static document so people can refer to it,
bert: Dated, e.g. once every two years.
???: You could refer to a dated version.
bert: People will refer to different versions.
bert: We need longer things of stability.
* dauwhe_ February 29 is update the spec day!
krit: So let's have the snapshot separate from the index.
fantasai: So we need an editor of the 2013 snapshot.
plinss: It could take weeks to get the tool ready
fantasai: The prose can be updated with index as-is until later
* dbaron hopes we don't approach C++0xb
* fantasai volunteers SimonSapin :)
* sgalinea_ that'll teach him to bring up prefixes
RESOLVED: SimonSapin will edit, with input from fantasai
[break]