W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes TPAC Sun 2012-10-28 PM I: Collisions, Exclusions, Line Layout

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 22:33:31 -0800
Message-ID: <50A33B3B.4080406@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
CSS Collision
-------------

   - Florian requested feedback

Exclusions
----------

   - RESOLVED: bug 15085 closed, keep the wrap-through property
               http://www.w3.org/Bugs/Public/show_bug.cgi?id=15085

   - RESOLVED: bug 15087 closed, interaction of floats and exclusions
               is explained in the spec section 3.6
               http://www.w3.org/Bugs/Public/show_bug.cgi?id=15087

   - Discussed bug 15089, making e.g. circle fit content
               http://www.w3.org/Bugs/Public/show_bug.cgi?id=15089

   - RESOLVED: bug 15083 closed as processing model is now described
               http://www.w3.org/Bugs/Public/show_bug.cgi?id=15083
     Still some concerns remaining wrt allowing an implementation to
     calculate correct results.

Line Layout Module
------------------

   - Steve reviewed progress on line layout module

====== Full minutes below ======

CSS Collision
-------------

   florian: There's a link to the spec at the bottom of the wiki.
   <stearns> http://lists.w3.org/Archives/Public/www-archive/2012Oct/att-0120/Overview.html
   florian: At the last f2f, we discussed a possible CSS property that
            would help deal with colliding thigns.
   florian: I've had limited time, but I've started a spec.
   florian: Basic idea is that you have a property 'collision' that can
            take "overlap" or "avoid".  If two elements have "avoid",
            and they collide the one later in document order moves out
            of the way.  The spec defines what "collide" means, and how
            they move.
   florian: So please review and give me feedback or ideas for things
            not yet defined.
   florian: This is not yet ready for FPWD.  I'm not sure if it's ready
            for ED on dev.
   * fantasai defers to dbaron on this
   TabAtkins: I'm fine with ED. You can add the "not-yet-ready" notice
              that I've put on a few specs this morning.
   TabAtkins: My opinion is that I simply can't find anything that's not
              on dev.w3.org.
   szilles: Agree with Tab. I've got some specs there as well that are
            similarly not-yet-ready.
   * TabAtkins BIG RED NOTICE: http://dev.w3.org/csswg/css3-hierarchies/
   dbaron: I'm not too excited about this draft, but with a big warning,
           I'm okay.
   florian: So with a big warning, we're okay with publishing an ED?
   Rossen: I think I'm interested in co-editing as well.
   szilles: Is this intended to cover floats?
   florian: yes, but perhaps by reference.

<br type="lunch"/>

Exclusions Open Issues
----------------------

   Scribe: ChrisL
   <stearns> http://dev.w3.org/csswg/css3-exclusions/
   Rossen: we have several issues, first is 15085
   <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15085
   <stearns> http://dev.w3.org/csswg/css3-exclusions/#wrap-through-property
   Rossen: do we need it? we think yes
   Rossen: helpful for implementations using exclusions, easy and natural
           way to prevent them affecting content
   Rossen: magazine-like effects, see examples on wiki
   Rossen: want to close the issue
   <stearns> http://wiki.csswg.org/ideas/css3-exclusions-print-use-cases
   stearns: near the end there is an example with overlays of exclusions,
            some affect content and not others for layered effects.
            needs wrap-through
   Rossen: also exclusions overlapping other exclusions. Collision
           avoid/allow is different, this allows collision but does not
           affect the content
   Rossen: can maybe move this into the new property
   florian: how does this differ
   Rossen: allows collision but content is not affected. Different, and
           needed. Want to resolve issue as 'yes we need the property'
   (no objections)
   RESOLVED: bug 15085 closed, keep the wrap-through property

   <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16437
   <stearns> http://dev.w3.org/csswg/css3-exclusions/#wrap-flow-property
   Rossen: this was already resolved but relates to top and bottom definition
   TabAtkins: its clearly not right
   TabAtkins at very least add before and after
   Rossen: ok

   <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15087
   <stearns> http://dev.w3.org/csswg/css3-exclusions/#floats-and-exclusions
   Rossen: Interaction of floats and exclusions
   Rossen: section on exclusions and floats, 3.6 covers this
   Rossen: discussed at previous f2f and mailing list, no feedback. Can
           leave open, while people review the proposed solution
   stearns: Or we could close it, and re-open if more specific issues arise
   Rossen: changed a year ago
   glazou: close it
   RESOLVED: bug 15087 closed, it is explained in the spec section 3.6

   <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15089
   stearns: shrink-to-fit circle with shape, not content outside a shape
   Rossen: came up in Santa Clara, Bert or Howcome raised it, exploring
           shrink to fit inside a circle
   stearns: it was fantasai
   Rossen: have come up with *a* solution, not one that gives us exact
           content fitting in arbitrary shapes
   Rossen: still do shrink to fit, apply min max sizing to original content
           box per 2.1
   Rossen: then we apply the shape and resolve shape percentages against
           that box
   Rossen: not perfect, circle will give overflow
   Rossen: better than no shrink to fit at all
   Rossen: more elaborate solution which approximates tightly fitting
           content in arbitrary shapes is difficult to compute
   Rossen: especially when the shapes are different inside and outside.
           Its NP-complete.
   Rossen: so do shrink to fit on box, [....]
   Rossen: author is asking for auto layout, and result is not optimal
   ChrisL: would like to see an example where it gives a reasonable result
   szilles: would prefer to see underflow rather than overflow, can grow
            the box for the second iteration
   florian: so repeat and increase
   szilles: increase enough
   dbaron: sometimes increasing width increases height too eg images
   stearns: could evaluate percentage you get when applying the shape,
            as a first approximation
   Rossen: opposite is when there is a shape that extends out of the
           content box, will get underflow by default. Do you squeeze it?
   szilles: no
   Rossen: can look into adding one extra resize
   Rossen: any additional reservations

   Bert: some module has the 'change the fontsize' property
   aaron: text-size-adjust
   Bert: was discussed in context of justifying last line of a paragraph,
         it's the same problem
   Rossen: in those cases people will not rely on shrink to fit
   Rossen: if both are dependent on resizing we need to cut the dependency.
           its ok with only one extra layout
   Bert: how does author express this?
   arronei: text-size-adjust
   Rossen: its not just text, it can be images
   stearns: needs additional steps for content fitting
   szilles: also for tables and line grid
   szilles: keeping the lines aligned inside tables
   szilles: so don't change the line heights
   stearns: assume we will get to content fitting in a later spec
   Bert: maybe it was removed
   Rossen: ok so keep it open and add the solution we just agreed on,
           resolve it later
   arronei: original issue is resolved
   stearns: want the algo resolved and in the spec
   ChrisL: so keeping it open while spec text is proposed?
   Rossen: yes

   florian: could compare relative percentage coverage of box and shape
            to get estimate for second iteration
   Rossen: yes but putting triangles inside squares, its harder

   <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15083
   Concerns over Error accumulation vs. performance
   Rossen: processing model was not in th spec when this was raised.
           Spec was updated Dec 2011
   Rossen: believe issue is currently resolved. Exclusions positioned
           out of flow require the extra layout pass
   Rossen: in terms of performance, that is the best we can do
   Rossen: there are cases where the position does not depend on the
           content so only one pass, as described in the spec
   Rossen: issue open a long time, spec updated to address it a long
           time ago, want to close it
   * fantasai defers to dbaron on this one too :)
   RESOLVED: bug 15083 closed as processing model is now described
   Rossen: if there are more specific issues, then raise them
   Bert: two passes is the minimum?
   Rossen: no it's the maximum
   stearns: we need specific cases cited where two passes does not work
   stearns: if those cases are important enough to address
   florian: could add a 'take as long as you want' option, off by default
   Bert: not clear what the second pass is
   Rossen: it's specified in the spec
   * fantasai notes that column-balancing is multi-pass until it stabilizes
   Rossen: That is a different part of the spec. These are separate problems.
   Rossen: error accumulation is the issue here, as exclusions accumulate
           it becomes significant
   Rossen: so we favoured a more performant approach with a single pass
           that computes all the positions, then position all the exclusions,
           and then you are done
   Rossen: if exclusions have predefined positions you don't need the first
           pass which is the case here
   florian: shrink to fit first and position later does not give extra
            iterations unless content of exclusion is generated using
            regions
   florian: then the position and size of the exclusion change the content
            of the exclusion
   Rossen: this is nothing new
   florian: multicol has same issue
   Rossen: done with issues, just brainstorming stuff

   Bert: worried we close the door on future improvements
   * fantasai agrees with Bert
   Rossen: no, we closed the door on 'there is no processing model defined'.
           It favours a performant model
   Rossen: we can add other models later, but we tried and did not come up
           with one
   stearns: Bert wants to ensure improvements are not disallowed. We can
            add text to the spec to clarify that.
   florian: how do you rest between a refinement and a random non-conforming
            change
   Bert: needs a lot of effort for shapes
   szilles: already have a bunch of properties to control that
   Bert: its not line by line
   SteveZ: can't define as 'always seek optimum', its a default algorithm
   florian: if we say 'must do at least as good as this' we need a measure
            of goodness
   stearns: place where content is laid out and shape should match. so it
            is reducing drift
   SteveZ: optimal is no underflow and no overflow
   TabAtkins: let's wait until a better algorithm is proposed and tested
   Bert: no single objective. Different products can have different objectives
   Bert: can use Tex algorithm, different weighting factors. people choose
         the best product for their needs
   Bert: like differing opinions on line breaking. same for balancing
         multicolumns
   florian: if there is a single possible way to define best, its ok. But
            if now, we can't say 'at least as good as' because it can't
            be tested or measured
   SteveZ: let's see what we get with the current algorithms, we need experience

Line Module
===========

   <stearns> http://dev.w3.org/csswg/css3-linebox/
   SteveZ: http://dev.w3.org/csswg/css3-linebox/#inline1
   SteveZ: in bad need of a complete restructuring make it understandable
   <fantasai> +1 to that
   SteveZ: want to make it have a processing model, definitions, then details
   SteveZ: some parts are not related to the line - text height and
           line-box-contain. mainly concerned with size of the content area
           that text takes up
   SteveZ: em-box or max ascender/descender. for background
   dbaron: is this about line height
   dbaron: text does not have backgrounds. inline boxes do
   SteveZ: everyone is using ascender/descender so the black background
           actually covers the white text
   SteveZ: moz, ie safari and chrome all use ascender+descender
   dbaron: spec requires that
   SteveZ: not, it requires either that or em-box. So there is less need
           for the property as everyone uses the same in practice
   SteveZ: text-height is the easy one
   SteveZ: will say explicitly that ascender+descender is picked
   Bert: think you are saying the one people implemented is the one I don't
         like
   Bert: backgrounds will differ if multiple fonts used on one line
   (several) yes
   SteveZ: we don't need it for version 3, can put it back in if I am wrong.
           will copy the note from 2.1 but give the default that is used
           in practice
   bert: I agree
   bert: but would rather the default was 1em
   SteveZ: went in neutral but all the implementations picked one of the
           two allowable ways
   florian: a default that is different from what everyone implements is
            no use
   SteveZ: vendors are not clamouring for a new property. want to focus
           on what it implemented now and get it done

   SteveZ: so, line-box-contain
   http://dev.w3.org/csswg/css3-linebox/#LineStacking
   SteveZ: non-replaced and replaced elements work differently, these were
           suboptimal choices so this property lets you specify different
           things in the computation
   SteveZ: eg use font size rather than line-height
   dbaron: its the ascender+descender size
   SteveZ: did not see a resolution
   dbaron: hyatt did this in webkit with a prefix
   dbaron:  it was my proposal as an alternative to line stacking strategy
   dbaron:  browsers all need this internally to handle quirks mode rendering
   SteveZ: so looking for confirmation that this needs to remain in the
           level 3 standard
   dbaron: was never super keen on it as i dislike mode selector properties
   dbaron: but don't see an alternative here
   fantasai: could apply to inline level elements
   dbaron: Definitely applies to blocks. Question is whether it applies
           to both inlines and blocks
   dbaron: Have gone back and forth on this. Not a problem from implementation
           perspective, just from "what controls do we want to provide"
           perspective
   SteveZ: will look in line-stacking-strategy for reusable bits but it
           may be we are already committed

   SteveZ: we have the general problem, related to line grid
   bert: doesn't line grid solve all the problems?
   SteveZ: for ruby its assumed the line spacing is enough that the ruby
           will fit
   TabAtkins: (editorial comment)
   (various) dude this text is mostly from like 2001
   koji: found a webkit bug on this
   (scribe missed bug number)
   <hober> https://bugs.webkit.org/show_bug.cgi?id=56388
   <Koji> webkit bug for line-box-contain

<br/>
Received on Wednesday, 14 November 2012 06:36:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT