[CSSWG] Minutes Seoul F2F 2014-05-21 Part I: CSS Masking, Geometry Interfaces, Test Results Script, Selectors 4

CSS Masking
-----------

  - RESOLVED: LC for CSS Masking

Geometry Interfaces
-------------------

  - RESOLVED: Publish FPWD of Geometry Interfaces

Test Results Script
-------------------

  - It was agreed that once plinss gets a chance to update a few
       pieces of Shepherd, it can be moved to W3C servers.

Selectors 4
-----------

  - Reviewed status. The group will review the text changes
    before a request is placed for a new WD.

==== FULL MINUTES BELOW ======

Present:
  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Adenilson Cavalcanti
  Dave Cramer
  Bruno de Oliveira Abinader
  Elika Etemad
  Daniel Glazman
  Dongwoo Joshua Im
  Koji Ishii
  Dael Jackson
  Philippe Le Hegaret
  Chris Lilley
  Peter Linss
  Shinyu Murakami
  Edward O'Connor
  Simon Pieters
  Liam Quin (phone only)
  Andrey Rybka
  Simon Sapin (phone only)
  Dirk Schulze (phone only)
  Alan Stearns
  Shane Stephens
  Jet Villegas
  Steve Zilles (phone only)
  5 observers

Regrets:
  Anton Prowse
  Lea Verou

Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael

CSS Masking
-----------

  glazou: Let's start
  glazou: We have krit calling in and the topic first is CSS masking
   <krit> http://dev.w3.org/fxtf/css-masking-1/#masking

  krit: CSS Masking has had some changes since the last WD. One was
        that we now have layered masking support.
  <krit> http://dev.w3.org/fxtf/css-masking-1/#the-mask-composite
  krit: To make this possible it was an issue how to combine
        different mask layers and I introduced a mask composite
        property.
  krit: It uses composite operators to make it easier to use
        instead of using a whole composite mode.
  krit: The mask-source-type, which needed to be renamed to
        mask-type.
  krit: Therefore it all needs to be renamed since webkit and Blink
        are shipping.
  krit: I've called it mask-operation.
  krit: mask-type is mask-operation and mask-box-type is
        mask-box-operation.
  krit: We've had no change requests in 2 weeks, so is it possible
        to publish a new LC?
  krit: It might be last LC.

  glazou: Thoughts?
  fantasai: There was one issue that was raised with layers about
            grouping the operations and combining the images. The
            reason we deferred layers was that we didn't know how
            to express such combinations.
  fantasai: Is grouping something we will want to do at some point,
            and if so, is this allowing us to add it later?
  krit: Grouping isn't important at the moment but it is interesting.
        We can think about that at the backgrounds and borders area,
        but for now I think we're fine with not having grouping.
  krit: We can introduce it in backgrounds and borders.
  TabAtkins: I'm fine with that. Whatever solution is in backgrounds
             and borders will be fine.
  fantasai: If we do an expression language that will be different
            from mapping compositing operators across layer lists.
  TabAtkins: And in the future we can have both.

  krit: Any other requests or can we go to LC?
  glazou: Comments?
  glazou: TabAtkins is fine, I'm fine, as is clilley and Rossen_

  RESOLVED: LC for CSS Masking

  clilley: Can you get the document ready today so I can request
           publication on Thursday?
  krit: Next week?
  clilley: This week
  krit: Sure.
  krit: Do you think you can get it published on Thursday?
  clilley: Yeah. As long as it's ready we can publish on Thursday.
  krit: Yeah.

  fantasai: What was the mask-type change?
  fantasai: Is it in the ED yet?
  krit: For some reason it wasn't input into the ED. I looked online
        and all that's missing is the change from mask-source-type.
  krit: And the mask-mode,
  krit: And mask-box-layout.
  krit: I'm not sure if I put it on the wrong branch, but it needs
        to be changed first.
  fantasai: Is there a clearer name than mask-mode?
  TabAtkins: That's what we used in SVG and I can't come up with
             anything better.
  fantasai: Okay.
  fantasai: Where is it in SVG?
  TabAtkins: Mask element.
  clilley: So you can't rename it
  fantasai: I'm happy if it matches something.
  fantasai: It's otherwise very vague but...
  krit: So you're fine with mask-mode?
  fantasai: If it matches SVG, yes.

  krit: There isn't in mask-mode, it was introduced in SVG.
  TabAtkins: There's an attribute. There's a same named thing so
             there's consistency.
  krit: We use mode quite often. That's true.
  krit: Any better suggestions or is it fine?
  fantasai: Where in mode? I was looking at masking module.
  <krit> http://dev.w3.org/fxtf/filters/
  krit: It is in the spec linked above. There's a lot of use of mode.
  krit: Composite operator.
  fantasai: If it means the same thing, great. But it doesn't.
  fantasai: It's used for blending, not mask interpretation.
  krit: True.
  fantasai: And Masking will need blend modes at some point?
  krit: No.
  clilley: He's arguing we use mode for that sort of thing.

  fantasai: Are we going to add blending modes to masking?
  krit: For background it's called background-blend-mode so it's
        explicit.
  astearns: If we do we can call them blendmodes.
  TabAtkins: Which is clear at that point.
  fantasai: The blend mode is clear.
  fantasai: Okay. I'm not happy unless it matches something else,
            but I don't have a better idea.
  fantasai: If it conceptually matched that would be awesome,
            matching a different concept is less awesome.
  * fantasai doesn't like "mode" or "type" in property names because
             they're semantic no-ops
  <fantasai> The only thing they express is "I take an enumerated
             type"

  clilley: Do we have a better name or can we move on?
  fantasai: We can move on.
  krit: The next one?
  glazou: That's all for masking? Okay.

Geometry Interfaces
-------------------

  <krit> http://dev.w3.org/fxtf/geometry/
  krit: We worked on the geometry interface which is the dom-point,
        dom-matrix, etc. that we had in different publications
        before.
  krit: They had been in CSSOM view and this is a combination of the
        interface that we actually use in OM and SVG

  <krit> http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity
  krit: There have been some slight changes to DomMatrix.
  krit: There had been long discussions on the mailing list and I
        added ident to the DOM matrix interface that checks if the
        matrix is an identity transformer.
  <glazou> krit: your document lacks a normative reference to WebIDL
           please

  krit: There are some issue.
  <krit> http://dev.w3.org/fxtf/geometry/#issue-5712ca41
  krit: One is for the DOMMatrix constructor. One issue I'd like to
        resolve is issue 2 (link above)
  krit: This is where DOM Matrix takes a string that can be a
        translator.
  krit: The translation you can use in CSS can be passed into the
        string because you can pass the start and generate the DOM
        Matrix
  krit: SVG uses the transform attr and it has less restrictions. It
        doesn't require units
  krit: In SVG we have the transform attr and it has less
        restrictions. It doesn't require units and it has white
        spaces between function name and the braces.
  krit: I would suggest that we allow transform attr syntax here.
  krit: It allows CSS syntax and SVG syntax.
  krit: The SVG syntax will be around for a long time and use of SVG
        syntax would allow CSS syntax to work. The SVG group wanted
        approval from CSS.

  TabAtkins: I'm fine with unit-less, but I don't like the "let's
             have it be an ident plus parenthesis."
  TabAtkins: It's a strange artifact and doesn't need to be
             maintained.
  krit: I haven't seen it but it's in theory allowed.
  TabAtkins: I don't think we need to spread that aspect further,
             but unit-less if fine.
  krit: We would need a third syntax. It creates a string from
        transform and passes to Matrix.
  TabAtkins: And if you're not weird it'll work.
  krit: I don't think that it's a good idea to have a third syntax
  * fantasai agrees in not having a 3rd syntax
  TabAtkins: It's only a third because it accepts the unitless SVG
             thing when CSS in general doesn't do that. That's the
             only separation and I don't think that's a significant
             difference.
  krit: User agents have to implement three different ways for very
        little gain.
  krit: It gets you closer to CSS without whitespaces.
  krit: I'm not sure if that gain is good enough.

  TabAtkins: Whenever you do the unit-less is that interpreted as px?
  krit: Yes.
  TabAtkins: So it's accepting the weird or required to use pixel,
             I'm fine with sticking to CSS, but don't see a reason.
             If we have to do one or another, I want CSS.
  clilley: Unit-less doesn't mean pixels always.
  TabAtkins: But it has to be understandable.
  clilley: If I do 0.3 by 0.3 it can be huge.
  krit: If clilley is talking about user units, it's always 1 px.
  clilley: No, it's not.
  krit: It is.
  krit: It means 1px isn't always 1 pixel when it's transformed.
  krit: It depends on what you mean.
  clilley: So 1px can be 3000 device pixels. Most people if they say
           the want a 1px font they don't expect it to be huge.
           Forcing people to write px isn't useful. For a lot of
           content people that aren't used to scalable things, they
           set it to fixed and use px, but that's not the only way.

  krit: I agree on the behavior. Do we want CSS, SVG, or a mix?
  clilley: Does mix mean the superset?
  krit: SVG is the superset.
  TabAtkins: CSS syntax that accepts numbers that are interpreted as
             px units.
  krit: How would you do with having CSS syntax without units?
  TabAtkins: Have them set numbers that are interpreted as
             pixel units.
  krit: Um.
  krit: I hope we can get rid of whitespace in SVG. I didn't see the
        behavior in use so maybe it's fine, but in this case I'd
        change SVG transform syntax.
  krit: I'm fine with keeping this issue open until SVG transform is
        resolved.

  krit: I'd like to publish a FPWD with these issues and we can
        compare.
  TabAtkins: Absolutely publish, yeah.
  glazou: Other opinions?

  RESOLVED: Publish FPWD of Geometry Interfaces

  clilley: plh, can we publish a FPWD?
  plh: Yes.

  plinss: One question. In Shenzhen we got a bunch of feedback from
          Alex Russell that isn't in here. Is that rejected, not
          considered?
  krit: What about Alex Russell?
  krit: I tried to ping him and he didn't respond.
  clilley: What was the substance of your ping?
  krit: I summarized the promises we have in CSS WG with the
        interface and he was suggesting growth instead of a new
        interface. I asked him to comment on the mailing list and
        summarize his opinion and opinions from others. He didn't
        respond or comment on the mailing list.
  plinss: I'll follow up with him.
  krit: I talked with Mozilla and he feels we should have the
        new interface.
  plinss: Okay.
  glazou: So are we done with this topic?
  krit: Yeah.

Test Results Script
-------------------

  clilley: I was working with our web and communications team where
           they wanted us to take out the paragraph markers. We got
           to leave them, but I complained about taking out this
           script that gave a nice summary of the test suite.
  clilley: Without it the pages aren't as useful and the reaction
           was surprising positive. I went a few rounds of what we
           would need to keep this and one sticking point was
           accessibility and I proved this doesn't interfere
           with that.
  clilley: The next issue was "does this make the doc non-archival?"
           I said no.
  clilley: And "Can you just inline the results?" No because we want
           it to be in real time.
  clilley: The one real remaining sticking point is that the script
           isn't hosted at w3c.org
  clilley: I said I'd talk about this. Since then someone popped up
           with a bunch of hand waving where it would let the data
           live where it does and the script can be on w3c.org

  plinss: It's fine by me, it makes it harder if I update the
          script, but that's okay.
  clilley: Will you update in a way that breaks the API?
  plinss: I wrote it a long time ago and the API has only had one
          update since.
  plinss: I intended to get back into it in the next few weeks and
          if you let me do that first then you can have a fairly
          stable script.
  clilley: Thank you. I think it's very good.

  plinss: It doesn't link to the stylesheet. Do you want that piece
          too and have it live on the w3c server?
  plinss: That's doable.
  plh: Did you think about how you do a new app you need to do the
       script? Is that painful and do we want to try a new location?
  clilley: All the thing for a publication need to be underneath. I
           think it's worth pushing on a well known location where
           it's installed and point there. It also solves the
           version problem.
  clilley: That's worth pushing for.

  plh: You can still share it across specs.
  plh: As long as you won't ever break it, that would be nice.
  clilley: If it's inserting a style sheet link through the script,
           that needs to come in before the final official sheet.

  clilley: So for next step we need to re-factor and stabilize?
  plinss: Yeah, let me have another pass to stabilize.

  plh: Then we need to deal with bikeshed?
  plinss: Yes, bikeshed is making those links.
  plinss: So we'll want to use our own version of the script on
          the drafts?
  clilley: It seems more efficient if the script is together. If
           not, let's shift.
  TabAtkins: It's the browser making the requests.
  clilley: Then we'll use the same version for all.
  clilley: Any origin problems if some is on dev and some is on www?
  TabAtkins: Shouldn't be.
  clilley: Okay. The ball is in plinss court.

  plinss: I recall an issue with TR where it doesn't exist?
  clilley: I believe they're serving HPS.
  plh: We don't use it for TR commands.
  plinss: If people are doing the FTP for it, it would be shipping
          wrong.
  plh: I don't believe people are.
  plinss: But we can do it on dev.
  plh: It's possible people could access it but since the link is
       related the script will be through HTTPS as well
  plinss: I was thinking of issues a while ago.
  plh: Testing will be needed.
  plinss: Okay. We're fine.

  plh: I tried to access through HTTPS and got redirected.
  plinss: And dev isn't doing HTTPS.
  plinss: I think bikeshed uses scheme-relative urls for that. I
          think we're okay.
  plinss: Okay.

Selectors 4
-----------

  <dbaron> http://dev.w3.org/csswg/selectors4/

  fantasai: There's been a lot of text changes so I need to review
            it and then we'll want another WD with that
  fantasai: I think what we need from the WG is opinions on what's
            going in this level vs. the next. Right now the draft
            has a cut of what we think goes in this level.
  glazou: So nothing to do really?
  fantasai: I don't think so.

  glazou: If you have anything to discuss on level 4 now is the time.
  glazou: We need time to review the added text.
  TabAtkins: And I have more to rewrite.
  glazou: If we close this now it means we've used the morning's
          agenda. CSS3 text is on this afternoon for SteveZ and Bert.
  glazou: We don't have Bert on the call.

Received on Friday, 13 June 2014 14:17:02 UTC