W3C home > Mailing lists > Public > www-style@w3.org > January 2014

[CSSWG] Minutes Seattle F2F Mon 2014-01-27 AM I: Variables, Masking

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 30 Jan 2014 00:43:31 -0800
Message-ID: <52EA10B3.7010205@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Variables
---------

   - RESOLVED: Publish Variables as CR once Tab has completed edits on
               remaining issue and prepared at Disposition of Comments.

Masking
-------

  - Discussed addition of reference-box arguments to shape arguments
    for clipping.

  - RESOLVED: Defer the 'bounding-box' value from clip-path and
              mask-origin to next level.

  - RESOLVED: clipping/masking properties respond to box-decoration-break
              same as background images

  - RESOLVED: Keep mask-box.  No opinion on whether or not to do a slice
              image function yet; use cases are needed (that wouldn't be
              solved by multiple border images).

  - Discussed coordinate systems of <mask> when applied to HTML+CSS.

  - Plan to republish Masking as WD to work through issues filed since
    LC publication.

====== Full minutes below ======

Agenda: http://wiki.csswg.org/planning/seattle-2014

Agenda
------

   This is minuted but uninteresting technically. See IRC log.

CSS Variables CR
----------------
Scribe: fantasai

   TabAtkins: Got no comments during 6 months LC period
   TabAtkins: so propose going to CR
   ChrisL: After changing all the names.

   plh: Implementation status?
   TabAtkins: Mozilla is working on implementation by heycam
   TabAtkins: We had an implementation, abandoned 'cuz engineer left,
              but have someone planning to pick up
   dbaron: Mozilla implementation is done as far as we know. heycam is
           working on other things. We're just waiting for the spec to
           go to CR.
   ...
   plh: tests?
   dbaron: I believe we even contributed a bunch
   dbaron: do have tests
   plh: please drop a link to them
   plh: 10 months at least for CR phase
   <astearns> http://test.csswg.org/shepherd/search/spec/css-variables-1/
   <astearns> 168 tests in shepherd
   dbaron: we have 179 files of tests, contributed
   plh: so, they need review?
   plh: Ask guy implementing at google to review them?
   <dbaron> tests in contributors/mozilla/submitted/mozilla-central-reftests/variables
            and contributors/mozilla/submitted/css-variables
   glazou: Do you think they represent a complete test suite?
   dbaron: probably not, but don't know
   TabAtkins: seems a little sparse, but not too far off. Would estimate
              a few hundred tests.

   glazou: Have question for next level of variables
   glazou: Got a question wrt using variables inside MQ
   TabAtkins: have a proposal for MQ variables
   fantasai: It would have to be a completely separate mechanism.

   fantasai: Do we have an owner for Variables test suite?
   glazou proposes Tab
   fantasai: I don't think that's going to work, cuz not actually going to
             happen. Anyone else?

   glazou: Any objection to moving Variables to CR?
   smfr: One issue left in the spec wrt animation
   TabAtkins: Oh, we decided on that. Haven't edited it in
   discussion of remaining edits
   RESOLVED: Publish Variables as CR once Tab has completed edits on
             remaining issue.
   ChrisL: Is there a DoC?
   TabAtkins: no issues, so that's easy
   ChrisL: need an explanation of why no comments, i.e. not because nobody
           read it
   fantasai: Because it's a processing spec. Tend to have way fewer issues
             than layout ones.
   ACTION ChrisL to work on CR publication
   <trackbot> Created ACTION-603
   ACTION Tab to ping Google engineer working on Variables, ask to formally
              review Mozilla's tests
   <trackbot> Created ACTION-604

Masking
-------

   krit: One issue was reference box
   krit: I added reference boxes for clip-path, same syntax as in Shapes
   krit: can choose which box you want to use as reference box for clipping
   krit: This was an LC request
   krit: We have no resolution on this. Are there any objections/concerns?

   krit: bounding-box
   krit: Something that fantasai pointed out...
   krit: idea of bounding box is that a box can have children that overflow
   krit: using bounding box, can size a shape according to this box here
   krit: so ellipse of 100% will take entire overflow area
   krit: But if you fragment across, say, columns
   krit: bounding box is box that surrounds all of client rects
   krit: which is not matching how we want to handle fragmentation otherwise

Scribe: TabAtkins
   ChrisL: Rather than leaving it undefined, we can say the current def
           isn't very helpful.
   ChrisL: So it's defined, but not useful in that particular case.
   ChrisL: You get a result, it's not undefined.
   krit: I don't want to put that into the spec.
   fantasai: I don't want to add something with that behavior because it's
             not how the other boxes work.
   fantasai: It's not consistent.
   fantasai: The goal of the reference box changing is which box you're
             changing, not how you wanna handle fragmentation.
   fantasai: If we want to have a bounding box ability for that, it should
             be an independent switch.

   krit: [something about the way the fragmentation and boxes are defined]
   szilles: If you didn't have fragmentation, what would you want?
   krit: Without fragments, you'd have a ref box for the whole overflowing
         area, and an ellipse would then fill the whole thing.
   szilles: There's already specs for what to do for background-* stuff.
            Why not have it work the same way?
   fantasai: It does, but the definition of bounding-box isn't compatible.
   szilles: I'd do slice, and then put things back together per fragment.
   fantasai: We could define that, we just can't call it bounding box.
             That term already has a meaning in some OM functions.
   fantasai: I'd call it overflow-box, since the concept is capturing the
             overflow.
   <dbaron> I'm not crazy about the term "overflow box"
   krit: So you'd just say you take the overflowing area?
   astearns: Just as with other boxes, if the box gets fragmented, you
             apply it to the fragments the same way backgrounds do.
   astearns: Same definition as the other shape boxes, but for overflow.

   dbaron: I'm not too happy with the term overflow-box.
   dbaron: One, it sounds like it should be a rectangle.
   dbaron: Also, it doesn't quite feel like overflow.
   astearns: It is a rectangle, except in fragmented stuff, same as the
             other boxes.
   florian: Isn't it a list of boxes?
   fantasai: Yeah, but for symmetry we should do *-box for the value name.
   krit: But all the keywords have the same problem; it would be weird to
         have them be *-box and have this one be something "fixed".

   dbaron: Okay, so why is it overflow?
   astearns: If you have an element with content that overflows, what do
             you call the box that contains everything from that element?
   dbaron: Well, there's two kinds of overflow.
   dbaron: Overflow you scroll to, and overflow you don't.  And maybe a
           third.
   fantasai: It's defined as the rectangle that would contain the border
             boxes of the element and all its descendants (with descendants
             possibly transformed).
   dbaron: And doing 3d flattening if you're in the middle of a preserve-3d
           tree?
   shepazu: Are the different things written down somewhere?
   TabAtkins: They're things we've discussed before, but haven't written
              down yet.
   shepazu: Can we write them down?
   TabAtkins: Yeah, they should go in Overflow. dbaron's the editor.
   krit: So is name the only problem?
   fantasai: No, definition is also the problem.

   dbaron: So what is the use-case for clipping to the overflowing things?
   dbaron: And what does that imply for an overflow region that is a union
           of rectangles but not a rectangle itself.
   dbaron: I'm having trouble seeing why you'd want to use overflow as a
           clip path.
   shepazu: If you're trying to highlight a particular thing, you might
            want to just have that shown.
   ChrisL: [another example]
   dbaron: This is for masking, not clip?
   fantasai: Both.
   SimonSapin: The region we're talking about is just about sizing the
               clip path, not about clipping itself?
   dbaron: You're going to end up making very specific assumptions about
            what your overflow is.

   szilles: So the bounding box is the smallest box around all the content.
   Rossen: What fantasai and I have been using for "bounding box" is the
           pre-fragmented box, sliced appropriate.
   [...]
   <dbaron> I don't even know what we're deferring to the next specification...
   * Scribe is also lost.

   TabAtkins: Okay, so we're deferring the "bounding box" value and anything
              like it?
   shepazu: Wait, SVG already defines it, right?
   krit: No, SVG does something completely different, and doesn't have
         fragmentation.
   RESOLVED: Defer the 'bounding-box' value from clip-path and mask-origin
             to next level.

   krit: Okay, new topic. Fragmentation for clip-path and masking.
   krit: We need to define in general how clip-path works with fragmentations.
   krit: I propose we do the same thing as background/etc., following
         box-decoration-break.
   krit: I'd like to extend Fragmentation to include this.
   fantasai: Sure. We can just define that the behavior is the same as for
             background images.
   krit: clip-path/clip/mask same as background wrt box-decoration-break
   krit: mask-box same behavior as border-image wrt box-decoration-break
   fantasai: So b-d-b controls masking/clipping as well as backgrounds.
   smfr: Are there any cases where you'd want to use different b-d-b
         behaviors between the properties?
   krit: I think not.
   RESOLVED: clipping/masking properties respond to box-decoration-break
             as proposed above.

   krit: Last issue is a proposal for a 9-slice image function.
   krit: Simon and Dean suggested that instead of mask-box, we should
         define a 9-slice image function.
   krit: Then use the normal mask property to allow masking borders of the
         element.
   krit: We didn't really resolve if the CSSWG even wants to define such
         a function.
   krit: There's also a question of if we want to remove mask-box anyway,
         even though it's implemented in WK/Blink.

   fantasai: My concern is that it's pretty complex, and one part (the
             outset) isn't useful for generic images.
   krit: Right. All of the property values for mask-box would have to go in.
   krit: fantasai pointed out that we don't have the box outset.
   krit: So that can't be done with 9-slice.
   smfr: At least without adding a mask-box-outset property.
   krit: So, do we want to work on a 9-slice image?
   krit: And maybe the extension to a 5x5 one?
   fantasai: What's the use-case for it?
   fantasai: I can't imagine using it for anything beyond border-image.
   fantasai: Maybe multiple border-images, but it won't be a list bullet.
   fantasai: That's it, as far as I can imagine.

   krit: So we have a request for border-image with 5x5, but no request
         for an image function that does that.
   fantasai: Not opposed to extending border-image to 5x5, there were
             requests to do that in the L3 cycle as well
   fantasai: So since I can't imagine using a 9-slice for anything besides
             matching against the box...
   fantasai: And it would be a really long function.
   fantasai: I'm somewhat opposed to doing this unless there are some solid
             use cases outside decorating the border-box.

   krit: So any other opinions? I'd like to resolve that we at least keep
         mask-box.
   RESOLVED: Keep mask-box.  No opinion on whether or not to do a slice
             image function yet.

   * smfr found 2 stack overflows asking for sliced images
   <fantasai> for doing what, exactly?
   <TabAtkins> Hook us up with some links, smfr.
   <smfr> http://stackoverflow.com/questions/5284743/image-slices-placed-using-css-divs
   <smfr> not sure if these are 9-way slicing

   krit: If you ref a <mask> element, it has maskUnits=''.
   krit: Something like the reference box, but for SVG.
   krit: Can be object bounding box (OBB) or userSpaceOnUse (USOU).
   krit: obb is pretty clear you want the element's reference box. We choose
         content-box for HTML and bounding box for SVG.
   krit: usou, for SVG, it takes the viewport of the reference box.
   krit: But "viewport" has a different meaning in CSS.
   krit: You can't scroll (in theory) for SVG, it's the width/height of
         the whole document.
   krit: But in CSS it's the width/height of your window.
   [lots of confusion over viewbox vs. viewport]
   TabAtkins: SVG's viewport is the size of the nearest <svg>.
   TabAtkins: viewbox is a way to establish a coordinate system over the
              viewport.
   TabAtkins: Neither have any connection to CSS's definition of "viewport".

   krit: If an SVG element takes a <mask> as a mask, it finds the nearest
         viewport, and does coordinates from that.
   fantasai: Similar to our line about abspos containing block?
   krit: Yeah, similar.
   krit: So we have this concept in SVG. What do we do for HTML?
   TabAtkins: roc had this proposal, where has exact same rectangle as
              object-bounding-box, but fills that with the outsides
              coordinate space
   TabAtkins: in our case, it would mean you can do normal px units, and
              will work out fine
   TabAtkins: difference is how big is a user unit
   * scribe confused
   * fantasai thinks Tab needs to fill this bit in himself

   TabAtkins: So, OBB establishes a box from the ref box, and scales the
              "user-space unit" so that that box is exactly 1 unit wide
              and 1 unit tall.
   TabAtkins: USOU establishes the same box, but sizes the "user-space unit"
              to be equal to the CSS px.
   krit: So I support roc's definition (or Tab's interpretation of it)
         for HTML element.
   krit: So do we want to propose this to the SVGWG?  It seems a lot of
         people don't understand it.
   [fantasai reviewing the example again]
   fantasai: I suggest we make all these edits, publish a WD to review them,
             *then* publish as LC when we're sure we're done.
   fantasai: So we don't cycle through LC.
   krit: If we assume that this WD gets published, how long do we wait until
         LC?
   fantasai: I say 3 weeks?
   szilles: Depending on the level of comments.
Received on Thursday, 30 January 2014 13:41:45 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 30 January 2014 13:42:02 UTC