W3C home > Mailing lists > Public > www-style@w3.org > April 2013

[CSSWG] Minutes Telecon 2013-04-05

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 05 Apr 2013 15:19:43 -0700
Message-ID: <515F4DFF.9090807@inkedblade.net>
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

This archive was generated by hypermail 2.3.1 : Friday, 5 April 2013 22:20:55 UTC