- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 30 Jan 2014 00:43:31 -0800
- 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