<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 :)
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
RESOLUTION: Publish the FPWD
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
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"
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/ Succeeded: s/RESOVLED/RESOLVED/ 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]