W3C

- DRAFT -

SV_MEETING_TITLE

27 Jan 2014

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
fantasai, TabAtkins

Contents


<dbaron> I'm in the hotel in Seattle.

<Ms2ger> A meeting?

<glenn> dial-in status?

<glazou> sylvain is out of the room for a few minutes, I will ask him ASAP, glenn

<glenn> tnx; i'm on call, but sylvain has not activated it yet

<glazou> ok

<smfr> glenn: we haven't started yet

<smfr> glenn: there is a polycom tho

<glenn> ok; i'm on hold, waiting on the conf to start on the dial-in posted in the planning page; is there a scheduled start time? i thought it was 9am

<dauwhe> Sylvain is dialing now...

<glazou> http://wiki.csswg.org/planning/seattle-2014

Agenda

<fantasai> Scribenick: fantasai

fantasai: I'll be flying out 1pm on Wed, so anything you want me here for, don't schedule for then

various other ppl leaving early on Wed, but not that early

glazou: Some items LC/CR
... masking, shapes, syntax, variables...
... Maybe start with that
... Dedicate this morning to this document?

krit: Some masking stuff has to be wed, but maybe 45min for today

astearns: shapes, 15-20min

fantasai: flexbox, maybe 20-30 min now, then discuss min-size issue later... that might take awhile, and benefit from discussion over lunch

TabAtkins: No comments for Variables, so really quick

glazou: Elements as regions tomorrow afternoon

fantasai: merging animatable / computed value lines for this afternoon?

fantasai, tab: estimate 30min

<dbaron> I don't understand the proposal, btw.

fantasai: grid probably also half an hour, but can put anywhere

glazou: update on TTA this afternoon?

fantasai: That sounds like a good idea

florian: I propos MQ for tomorrow
... Would encourage people to review edits beforehand
... estimate 1-1.5 hr

glazou: :has()

fantasai: tomorrow?

glazou: 45min probably

fantasai: who put baseline grid on it?

astearns: Have some examples to show, doesn't necessarily need f2f time

glazou: 15min?

astearns: sure

glazou: css3-color?

fantasai: need to check on status of tests, implementations, etc.

glazou: 15-20min then?
... reverse lists is an interesting topic
... estimate 30min, for tuesday morning
... Tuesday afternoon. Fragmentation?

fantasai: sure

glazou: hour?

florian: sure

glazou: display spec?

TabAtkins: 45min for that

glazou: -webkit-color-adjust ?

florian: Not much time, I hope

glazou: End of Tuesday morning for that, if we have time
... page selectors?

dave: 15 min maybe

glazou: wed morning maybe
... will-change

fantasai proposes Wed

glazou: 45min

TabAtkins: also grouping of perf things

glazou: Simplify object size of replaced elements
... wed morning, short
... scroll snap points

?: half hour?

glazou: ok, wed morning

dbaron: will-change and scroll snap points really important, I think. Fine with Wed, as long as we get to them

fantasai: ruby should be on 15m, only one issue on agenda

SteveZ: can we put shadow dom with regions?

TabAtkins: not really realaed

SteveZ_: kinda related
... would like shadow DOM update before regions

TabAtkins: should be 15min update

glazou: OK, will slip in Tuesday afternoon, probably after Fragmentation
... issue tracking?

dbaron: Might want that before TTA
... because one of obstacles to getting them done

glazou: ok, insert before TTA

plinss: @import to Cascade?

fantasai: 10min, put anywhere

CSS Variables CR

TabAtkins: Got no comments during 6 months LC period
... so propose going to CR

ChrisL: After changing all the names

plh: Implementation status?

TabAtkins: Mozilla is working on impl by heycam
... We had an impl, abandoned 'cuz engineer left, but have someone planning to pick up

dbaron: Mozilla impl 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
... do have tests

plh: please drop a link to them
... 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?
... 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
... 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
... 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

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

RESOLUTION: Publish Variables as CR once Tab has completed edits on remaining issue.

ChrisL: Is there a DoC?

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 - Work on cr publication [on Chris Lilley - due 2014-02-03].

ACTION Tab to ping Google engineer working on Variables, ask to formally review Mozilla's tests

<trackbot> Created ACTION-604 - Ping google engineer working on variables, ask to formally review mozilla's tests [on Tab Atkins Jr. - due 2014-02-03].

<SimonSapin> Where No WG Has Gone Before

Masking

krit: One issue was reference box
... I added reference boxes for clip-path, same syntax as in Shapes
... can choose which box you want to use as reference box for clipping
... This was an LC request
... We have no resolution on this. Are there any objections/concerns?
... bounding-box
... Something that fantasai pointed out...
... idea of bounding box is that a box can have children that overflow
... using bounding box, can size a shape according to this box here
... so ellipse of 100% will take entire overflow area
... If you fragment across, say, columns
... bounding box is box that surrounds all of client rects
... which is not matching how we want to handle fragmentation otherwise

<TabAtkins> ScribeNick: TabAtkins

ChrisL: Rather than leaving it undefined, we can say the current def isn't very helpful.
... So it's defined, but not useful in that particular case.
... 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.
... It's not consistent.
... The goal of the reference box changing is which box you're changing, not how you wanna handle fragmentation.
... If we wanna 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: You do, 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.
... 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.
... Same definition as the other shape boxes, but for overflow.

dbaron: I'm not too happy with the term overflow-box.
... One, it sounds like it should be a rectangle.
... 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 ahve an element with content that overflow, what do you call the box that contains everything from that element?

dbaron: Well, there's two kinds of overflow.
... 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?
... And what does that imply for an overflow region that is a union of rectangles but not a rectangle itself.
... 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 elika 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...

;_;

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.

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

krit: Okay, new topic. Fragmentation for clip-path and masking.
... We need to define in general how clip-path works with fragmentations.
... I propose we do the same thing as background/etc.
... I'd like to extend Fragmentation to include this.

fantasai: Sure. We can just define that the behavior is the same as for *

krit: clip-path/clip/mask same as background wrt box-decoration-break
... 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.

RESOLUTION: clipping/masking properties respond to box-decoration-break as proposed above.

krit: Last issue is a proposal for a 9-slice image function.
... Simon and Dean suggested that instead of mask-box, we should define a 9-slice image function.
... Then use the normal mask property to allow masking borders of the element.
... We didn't really resolve if the CSSWG even wants to define such a function.
... 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.
... Elika pointed out that we don't have the box outset.
... 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?
... And maybe the extension to a 5x5 one?

fantasai: What's the use-case for it?
... I can't imagine using it for anything beyond border-image.
... Mayb multiple border-images, but it won't be a list bullet.
... 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: So since I can't imagine using a 9-slice for anything besides matching against the box...
... And it would be a really long function.
... I'm somewhat opposed to doing this unless there are some solid use cases outside decorating the border-box.

<fantasai> fantasai^: Not opposed to extending border-image to 5x5, there were requests to do that in the L3 cycle as well

krit: So any othe ropinions? I'd like to resolve that we at least keep mas-box.

RESOLUTION: Keep mask-box. No opinion on whether or not to do a slice image function yet.

<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=''.
... Something like the reference box, but for SVG.
... Can be object bounding box (OBB) or userSpaceOnUse (USOU).
... obb is pretty clear you want the element's reference box. We choose content-box for HTML and bounding box for SVG.
... usou, for SVG, it takes the viewport of the reference box.
... But "viewport" has a different meaning in CSS.
... You can't scroll (in theory) for SVG, it's the width/height of the whole document.
... But in CSS it's the width/height of your window.

<fantasai> lots of confusion over viewbox vs. viewport

TabAtkins: SVG's viewport is the size of the nearest <svg>.
... viewbox is a way to establish a coordinate system over the viewport.
... 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.

<fantasai> krit: So we have this concept in SVG. What do we do for HTML?

<fantasai> TabAtkins: roc had this proposal, where has exact same rectangle as object-bounding-box, but fills that with the outsides coordinate space

<fantasai> TabAtkins: in our case, it would mean you can du normal px units, and will work out fine

<fantasai> TabAtkins: difference is how big is a user unit

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.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/01/27 18:41:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/fantasai/florian/
Succeeded: s/done/done as far as we know/
Succeeded: s/SimonSapin/???/
Succeeded: s/???/smfr/
Succeeded: s/readit/read it/
Succeeded: s/boudning/bounding/
Succeeded: s/3d tree/preserve-3d tree/
Succeeded: s/krit: fan/fan/
Succeeded: s/doing this/doing this unless there are some solid use cases outside decorating the border-box/
Found ScribeNick: fantasai
Found ScribeNick: TabAtkins
Inferring Scribes: fantasai, TabAtkins
Scribes: fantasai, TabAtkins
ScribeNicks: fantasai, TabAtkins

WARNING: No "Present: ... " found!
Possibly Present: AdobeSeattle ChrisL Henke37 MaRakow Ms2ger Rossen_ Scribenick SimonSapin SteveZ SteveZ_ TabAtkins adenilson astearns cabanier_ css darktears dauwhe dave dbaron dbaron_ dwim eliezerb eliezerb_2nd emalasky fantasai florian glazou glenn israelh jcraig jdaggett jet joined kawabata2 koji krit leif liam lmcliste_ nvdbleek nvdbleek3 plh plinss sarasou sgalineau shepazu smfr szilles tantek trackbot yamamoto zcorpan zcorpan_ zmike
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2014/01/27-css-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]