03 Apr 2013


rhauck, plinss, krit, djackson, sgalineau, glazou, fantasai, antonp, SimonSapin, Stearns, SteveZ, dbaron, jdovey, hober, smfr, BradK, Rossen, [Microsoft], JohnJansen, Bert, arronei, MaRakow, nvdbleek, Tab_Atkins, Tantek


<TabAtkins_> nvdbleek: It's in your email, on the private list.

<TabAtkins_> krit: References are based on the biblio file, so they haven't changed.

<TabAtkins_> ojan: Devs can avoid lines entirely if they like, by just using grid-row and grid-column.

<krit> TabAtkins_: ok, but should the well known spec CSS3 Transforms change it's title?

<krit> TabAtkins_: CSS Exclusions mentions level 3 as well

<TabAtkins_> krit: We certainly *could*. Ask Bert to change the biblio file, he's the only one with access I think.

<krit> TabAtkins_: well, I am not only asking because of Bert s ref file

<krit> TabAtkins_: Do the TR references change as well in the future?

<krit> TabAtkins_: currently it is still css3-transforms, css3-animations and so on

<krit> TabAtkins_: I am asking because of curiosity and preparation

<plh> regrets (again) for the CSS call. I'll be on the call next week for sure.

<TabAtkins_> I'm going to be probably 15 minutes late - I have to meet with someone in London, and our timing is constrained right now.

<TabAtkins_> krit: Yes, we plan to change the TR names as we publish new drafts (or maybe a mass move, we dunno).

<antonp> Zakim is fast today

<rhauck> plinss: can I add one thing to the agenda - it's very quick- just some announcements about upcoming TestTWF events

<plinss> sure

<SimonSapin> Zakim: mute me

<SimonSapin> Zakim: mute SimonSapin

<SimonSapin> better?

<SimonSapin> not sure why, it’s the same phone as usual. And the phone’s own muting is on

<plinss> must be noise on the line

I will do it

<Ms2ger> ScribeNick: SteveZ

rrsagaint, scribenick SteveZ

Add announcement of Test the Web Forward

<glazou> overlap with SVG ftf ?

Rebecca: TwF is planning an event following the CSS meeting in Japan. We are all invited

<glazou> ah right

There is also a TwF event in Seattle at Microsoft next week

<SimonSapin> F2F is Wednesday 5 ~ Friday 7, overlap with TTWF?

<rhauck> TTWF will start around happy hour time :)

CSS3 Overflow

DBaron: We agreed to wait till this week

<Bert> (I think Florian's comment is good, too.)

Fantasai: I pretty much agree with Florian Comments

<smfr> http://dev.w3.org/csswg/css-overflow/

krit: If an element has overflowing content creating new boxes, how do these boxes interact with siblings of the original element.

<krit> yes

<Bert> (Not sure about any of the new stuff in the module, :-) but no problem with trying it out.)

DBaron: Something split into three boxes with prior and later sibling then have prior sibliing, 3 boxes, and laster sibling

Glazou: So if you say display inline-block things will work correctly?

DBaron: Yes
... I am fine with adding Florian's issue

PLiness: Any objections?

Brad: Can you eventually move the Page overflow here?

DBaron: yes


Topic Exclusions

<smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0659.html

<tantek> and Zakim keeps hanging up on me

Alan: does a shape inside work like floats do or like an exclusion does in affecting lines of children

SteveZ: If defined as float, it will not affect lines of BFCs

Alan: If deifned as exclusion, it will affect lines of BFCs

Rossen: Shape inside should not behave differently than shape outside

Alan: if Shape Outside has two behaviors depending on what the shape is defined upon.

Rossen: the Inside can only be one.

DBaron: If the inisde is scrolled, what happens.

Rossen the layout is done and that result is scrolled, not relayed out

<dbaron> s/the inside/the BFC on the inside/

PLinss: it makes sense for the implementation, but perhaps not for the user.

Tab: I am wiht Rossen, reflowing during scrolling could cause things to jump around

<tantek> with fixed positioning, things change layout while you scroll

<BradK> Maybe shape inside should be non-scrollable

<Bert> <div style="shape-inside:circle(...)">Some text... <div style="overflow: scroll; height: 5em">Inner text..</div> more outer text...</div>

PLinss: When scrolling happens without re-layout, then things may overlap and become unreadable

fantasai: For a circle you can make it work iwth re-layout, but not for arbitrary shape

DBaron: Reason that Float does not affect things inside a BFC is becasue of scrolling

<SimonSapin> (glazou, still getting noise from me? I don’t hear it.)

PLinss: What else is going to change?

<glazou> SimonSapin, nope all ok

Alan: Nothing really, just need to add a note to say that the wrapping context of the elements inside get the exclusion area added to them
... Doing Shape Inside as an exclusion gives more flexibitily; can use the wrapping properties to control how the lines are affected

DBaron: in the Float way, the entire BFC is moved reather than the lines within it.

Alan: When you layout something inside only the lines are affected and BFCs are moved to avoid the collision

PLinss: If something is centered, and using the float model a BFC is moved, that would affect the centering point

Rossen: This does not happen with the Exclusion model
... Rossen: details of 2x2 grid in a circle shows Exclusions likely more straightforward

PLinss: I agree

<Bert> <table style="shape-inside: circle(...)><tr><td>A1<td>A2<tr><td>B1<td>B2</table>

Bert: not clear on table example
... what else can you do but shorten the lines of the content of each of the cells

Rossen: Table with a single cell with overflow scroll and table has a shape inside of a rectangle with size of 50% of the table itself. Then how big is the table celll?
... with the Float model, cannot have a float that pushes the table cell one way or another, but with the Exclusion model we have a solution
... It is the requirement that the table cell, a BFC, must avoid the float and that becomes awkward.

Anton: I think Exlusions has to be the way to go,

PLinss: any objections to Exlusions model

RESOLUTION: Exclusions model will be used in Shape Inside

<smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0684.html

<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0684.html

<Bert> page size and user defined size in print dialog

page size and user defined size in print dialog

SimonS: User want to choose based on what is in the printer. What do we do when user and author have conflicting choices?

Fantasai: Text in Page using !important rules to handle this

Glazou: this is more than page size; it is also about headers and footers and that ismore complex

<fantasai> fantasai: User prefs can be expressed through @page rule in user style sheet

Glazou: this is an old issue.

<fantasai> fantasai: CSS3 Paged Media says what to do if the specified size doesn't match what is available in the printer

Glazou: this problem arises when printing PDF docs, say legal ones, on which you do not want to print headers and footers

<fantasai> fantasai: Agree there's an issue on headers/footers

SimonS: These are two different issues: there is a proposal to allow user to choose whether or not to print system headers

Glazou: In Firefox, all the settings for the print dialog are in the UI, not from CSS.

DBaron: OS print dialogs are different on different systems

<fantasai> SimonS: There is a proposal on mailing list to not print UA headers/footers if author has specified headers/footers

Glazou: what are you asking for? a resolution to say the document settings should always override user settings?

Fantasai: the Cascade is the way that we control this in general, this does not work to headers and footers because there are 16 boxes to control

SimonS: this should be handled by a user style sheet?

Fantasai: yes

SimonS: That would work

Glazou: This depends on the OS print mechanism

Fantasai: Scaling to fit is already spec'd; it depends on being able to find the local paper size
... this should already be in CSS2.1

<fantasai> http://www.w3.org/TR/CSS21/cascade.html#cascade

RESOLUTION: use the cascade for page size

<fantasai> <add in fantasai's cascading margin boxes idea>


<glazou> url?

<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0707.html

<glazou> sgalineau, at least that's a palindrome :-)

Tab: Flex itmes painting atomicly decided in July. But thinking about it more. we should make flex items, and grid items paint atomicly

<fantasai> and table cells

<SimonSapin> Do we have a level 3 module that defines stacking contexts?

<fantasai> (We made them not atomic, because table cells aren't atomic.)

<fantasai> SimonSapin: positioning

<fantasai> I think

Tab: the only way to tell whether they paint like table-cells or atomically is to move a float outside the box and then back in.
... in this case the float is between the content and the background in a table-cell and over or under both in the atomic version
... Table-cells become a pseudo-stacking context, not a full stacking context

Desire is to make this change, retroactively, in CSS2.1

Note CSS2.1 already has changes that require a PER to update the spec

<tantek> I agree with making this an errata to 2.1

Tab: It might be OK to say that, even if table-cells do not change, all future ones will be pseudo-stacking contexts

Anton: We can do this of flexbox and grid, even without making the change to table-cells

Fantasai; the reason for copying table-cells in July was "consistencly" and no one had a reason for breaking that. We now have such an argument

Tab: Grid really wants ot be atomic because Grid does a lot of overlapping
... any objection to making Flexbox pseudo-staking contexts?

PLinss, Anton: not sure

<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0265.html

Fantasai: noted that Anton argued for pseudo-stacking context in July

PLinss: how about separating the foregrounds and backgrounds and paint each separately

Tab: no, for grid items if you put an item on top of another you want the background of the top item to obscure the lower one.

PLinss: might want to add a switch to interleave the backgrounds

<glazou> SimonSapin, worse than before :(

<SimonSapin> sorry :/

PLinss: whether this change affects tables is up to the vendors and the degree of compatibiity impact

Tab: Google thinks this is probably OK to change and DBaron seems to believe so also

RESOLUTION: make table-cell, flex item and grid item atomic

<antonp> atomic == /pseudo/-stacking context

atomic means "pseudo-stacking context"


<smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0750.html

Tab: image rendering property from SVG with added properties
... left in the "auto" keyword which does smoothing
... SimonF has asked for explicity "smooth" keyword and have "auto" mean do what UI want to do to get fast rendering

DBaron: Scaling up and down often has different behavior and this needs to be consider in the spec and in testing

Optimize quality maps to "smooth" and optimize speed maps to "auto'

Tab: How low can you go an be considered optimizing quality? do you need to go bi-cubic
... if an animation running with "smooth" what should you do to maintain quality?
... saying, "it does not degrade" is too fuzzy for me.

SimonF: the UA will not degrade image quality

Tab: but, it may degrade other aspects (eg frame rates) of the animation
... I am happy to add this

Bert: Is this too simple. Not discussing frame rate seem to be too restrictive

Tab: you should specify "auto" which tries to keep up the frame rate (and degrade image quality)

<Bert> (No objections, just not sure I understand why you want smooth ever.)

SimonF: Do not want to add frame rate in explicity because there are other factors that need to be considered as well

SteveZ: so it amounts to if you want frame rate to have priority say, "auto" and if you want image quality to have priority say, "smooth"

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-04-03 17:07:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/block/inline-block/
Succeeded: s/Dirk: ?/krit: If an element has overflowing content creating new boxes, how do these boxes interact with siblings of the original element./
FAILED: s/the inside/the BFC on the inside/
Succeeded: s/FantasaiL/fantasai:/
Succeeded: s/a BFC/things inside a BFC/
Succeeded: s/singel/single/
Found ScribeNick: SteveZ
Inferring Scribes: SteveZ
Default Present: rhauck, plinss, krit, djackson, sgalineau, glazou, fantasai, antonp, SimonSapin, Stearns, SteveZ, dbaron, jdovey, hober, smfr, BradK, Rossen, [Microsoft], JohnJansen, Bert, arronei, MaRakow, nvdbleek, Tab_Atkins, Tantek
Present: rhauck plinss krit djackson sgalineau glazou fantasai antonp SimonSapin Stearns SteveZ dbaron jdovey hober smfr BradK Rossen [Microsoft] JohnJansen Bert arronei MaRakow nvdbleek Tab_Atkins Tantek

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/2013/04/03-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]