[CSSWG] Minutes TPAC F2F 2013-11-10 Sun III: Masking Level 2, Filter Effects, Prefixing Policy

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]

Received on Wednesday, 20 November 2013 02:08:40 UTC