- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 05 Apr 2013 15:19:43 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Test the Web Forward Seattle April 12-13 (Fri-Sat):
http://testthewebforward.org/events/seattle-2013.html
- Test the Web Forward Tokyo planned for June 7-8 (Fri-Sat)
- RESOLVED: Publish css-overflow as FPWD
- RESOLVED: Exclusions model used for shape-inside.
- RESOLVED: Use the cascade for page size user prefs
- Discussed problems with using cascade for margin-box content.
- RESOLVED: Table cells, flex items, and grid items all
form pseudo-stacking contexts. Update Flexbox,
errata CSS2.1 accordingly.
- Discussed 'image-rendering', distinguishing between "auto"
and "smooth", perf considerations for animations.
====== Full minutes below ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Jim Dovey
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Dael Jackson
John Jansen
Brad Kemper
Peter Linss
Edward O'Connor
Anton Prowse
Matt Rakow (Microsoft)
Simon Sapin
Dirk Schulze
Alan Stearns
Nick Van den Bleeken
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2013/04/04-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Apr/0031.html
Scribe: SteveZ
Test the Web Forward
--------------------
<rhauck> Can I add one thing to the agenda - it's very quick- just some
announcements about upcoming TestTWF events
Rebecca: Test the Web Forward is planning an event following the CSS
meeting in Japan. We are all invited
Rebecca: 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
-------------
<smfr> http://dev.w3.org/csswg/css-overflow/
dbaron: We agreed to wait till this week
Fantasai: I pretty much agree with Florian Comments
<Bert> (I think Florian's comment is good, too.)
<Bert> (Not sure about any of the new stuff in the module, :-)
but no problem with trying it out.)
krit: If an element has overflowing content creating new boxes, how do
these boxes interact with siblings of the original element.
dbaron: Something split into three boxes with prior and later sibling
then have prior sibling, 3 boxes, and laster sibling
Glazou: So if you say display inline-block things will work correctly?
dbaron: Yes
dbaron: I am fine with adding Florian's issue
PLiness: Any objections?
Brad: Can you eventually move the Paged overflow from GCPM here?
dbaron: yes, that's the plan
RESOLVED: Publish the FPWD
Exclusions
----------
<smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0659.html
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 defined 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 BFC on the inside can only be one.
dbaron: If the inside is scrolled, what happens.
Rossen: the layout is done and that result is scrolled, not relayed out
plinss: it makes sense for the implementation, but perhaps not for the
user.
Tab: I am with 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 by laying out the top to fit
the top half, and the bottom to fit the bottom half, then
scroll straight in between. But that wouldn't work for for an
arbitrary shape.
dbaron: The reason that floats do not affect things inside a BFC is
because of scrolling
plinss: What else is going to change?
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
Alan: Doing Shape Inside as an exclusion gives more flexibility; can use
the wrapping properties to control how the lines are affected
dbaron: In the Float way, the entire BFC is moved rather 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
Bert: 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 cell?
Rossen: 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
Rossen: It is the requirement that the table cell, a BFC, must avoid
the float and that becomes awkward.
Anton: I think Exclusions has to be the way to go,
plinss: any objections to Exclusions model
RESOLVED: Exclusions model will be used in Shape Inside
* antonp thinks that otherwise you push the float model into /anything/
@page and User Prefs
--------------------
Topic: page size and user defined size in print dialog
<smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0684.html
SimonS: User want to choose based on what is in the printer. What do we
do when user and author have conflicting choices?
fantasai: User preferred page sizes can be expressed through @page rule
in user style sheet, using !important as necessary for override.
fantasai: CSS3 Paged Media says what to do if the specified size doesn't
match what is available in the printer
Glazou: this is more than page size; it is also about headers and footers
and that is more complex
Glazou: this is an old issue.
Glazou: this problem arises when printing PDF docs, say legal ones, on
which you do not want to print headers and footers
fantasai: Agree there's an issue on headers/footers; that's separate
from size.
SimonS: These are two different issues: there is a proposal to allow user
to choose whether or not to print system headers
SimonS: There is a proposal on mailing list to not print UA headers/footers
if author has specified headers/footers
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
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.
It does not work for headers and footers because there are 16
boxes to control, and while within a level they need to cascade
independently, across origins they need to be overridden as one
set.
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.
Fantasai: Use of cascade for user prefs should already be in CSS2.1
<fantasai> http://www.w3.org/TR/CSS21/cascade.html#cascade
RESOLVED: Use the cascade for page size
Flexbox
-------
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0707.html
Tab: Issue on flex items painting atomically was decided in July;
decided not to make them pseudo-stacking contexts, for consistency
with table cells.
Tab: But thinking about it more. we should make flex items, grid items,
and table cells all paint atomically.
<SimonSapin> Do we have a level 3 module that defines stacking contexts?
<fantasai> css-position-3, 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 via negative
margins.
Tab: 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
Tab: Table-cells become a pseudo-stacking context, not a full stacking
context.
Tab: 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 layout models will use pseudo-stacking contexts
Anton: We can do this for flexbox and grid, even without making the
change to table-cells
Fantasai: the main reason for copying table-cells in July was "consistency"
and no one had a reason for breaking that. We now have such
an argument.
Tab: Grid really wants to be atomic because Grid does a lot of overlapping
Tab: 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: minutes ^
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
plinss: whether this change affects tables is up to the vendors and the
degree of compatibility impact
Tab: Google thinks this is probably OK to change and dbaron seems to
believe so also
RESOLVED: make table-cell, flex item and grid item form pseudo-stacking
contexts
Images
------
<smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0750.html
Tab: image rendering property from SVG with added properties
Tab: left in the "auto" keyword which does smoothing
Tab: SimonF has asked for explicitly "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?
Tab: if an animation running with "smooth" what should you do to
maintain quality?
Tab: 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
Tab: 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"
Out of time.
Meeting closed.
<RRSAgent> http://www.w3.org/2013/04/03-css-minutes.html
Received on Friday, 5 April 2013 22:20:53 UTC