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

[CSSWG] Minutes Tucson F2F 2013-02-06 Wed PM I: Fragmenting Transformed Elements, Intrinsic Sizing Principles

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 19 Feb 2013 21:26:56 -0800
Message-ID: <51245EA0.1000601@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Fragmentation of Rotated Boxes
------------------------------

   - Discussed various options for fragmenting transformed boxes.

   - RESOLVED: Transformation is applied independently to each fragment.
               Because nothing really gives you the expected results,
               and this is the simplest to define and implement.

   - Authors should beware of combining transforms and printing. It's
     unlikely to work well for anything more noticeable than subtle.

Intrinsic Sizing
----------------

   Discussed conflicting definitions of intrinsic sizing in CSS3 Box
   and CSS3 Sizing. There are two conflicting principles:
     (1) interop/deterministic layout
     (2) allowing as high fidelity layout as possible

   Bert and fantasai will incorporate appropriate text in CSS3 Sizing,
   defining the baseline and ideal layouts and discussing the principles
   outlined above.

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

Fragmentation of Rotated Boxes
------------------------------
Scribe: Tantek

   smfr: issue summary?
   <plinss> http://lists.w3.org/Archives/Public/www-style/2013Jan/0089.html
   <fantasai> http://www.w3.org/mid/AFDF40EF-A5C9-45B0-8F74-082A461939FF@adobe.com
   smfr goes to the whiteboard
   smfr draws boxes on the whiteboard
   smfr: you've got a block that's split across multicols or pages

   fantasai: we resolved that the fragmentation occurs before transforms
   szilles: the middle one is resolved out
   (scribenote: need image to reference)
   szilles: as a general principles, daniel, alan, and I were talking about
            this, daniel proposed general principles, any property that
            applies to something that is fragmented, applies to the fragments.
   szilles: … applies individually to the fragments, in other words I treat
            each fragment as if it were an independent element.
   (photos taken of redrawn whiteboard)
   http://lists.w3.org/Archives/Public/www-archive/2013Feb/0010.html

   glazou: points to whiteboard, explains rotation, origin
   szilles: if I have two fragments and I'm going to rotate them both
            around the same logical point, I have to translate that
            same point to the second region. or alternatively do I
            take the first fragment rotate relative to the point in
            its container, and take the second one and rotate it
            relative to it.
   szilles: where is the rotation point? (is the question) It ought
            to be relative to each fragment.
   szilles: because that's going to guarantee its going to be on the
            page, or might be
   dbaron: another principle
   dbaron: when authors are designing a page, and not thinking about
           printing, users are still going to want to print that page
           and want to come out pretty much as it looked on screen
   dbaron: and having the transform origin be different breaks that
   fantasai: we are already screwed on that point...
   <stearns> having the fragmentation breaks that

   glazou: explains options on the whiteboard
   dbaron, simon, daniel discuss / question diagram
   smfr, szilles joins discussion of whiteboard
   fantasai: both of the bottom two (all the ones on the whiteboard) are
             going to give you bad results
   smfr: I disagree
   glazou: I'm not sure
   fantasai: I'll show you
   dbaron: the bottom two
   szilles: consider a 180deg rotation
   fantasai: Closest thing to expected result for the user is a graphical
             slice rather than doing fragmentation.
   fantasai: you don't actually do fragmentation on the box, you first
             rotate it and then slice it up into pieces
   <glazou> http://lockerz.com/s/281826419

   glazou: can we do better? (in response to szilles)
   szilles: you can always say break-within:avoid
   szilles: we should do something easy to do that for small rotations
            will probably be ok
   szilles: and for big rotations, you're going to need to avoid the break
   glazou: rotate before and slicing afterwards is this (middle)
   rossen: I'm in favor of the top one! (exits room)

   daniel, fantasai, smfr continue discussing whiteboard
   plinss, we're talking about a box ...
   szilles: it's fragmented in any case
   plinss: how do you get the upper right hand result?
   fantasai: you lay it out as if in contiguous media, you do the
             transformation, and then you just slice it
   smfr: the bottom you've actually done fragmentations...
   szilles: the top you haven't
   szilles: I can think of no one who likes slicing images. no one.
   smfr: even if the content has a forced break?
   <stearns> slicing after transform is fine if you're avoiding the break.
             I want to know what happens when there is a break (intentional
             or not)
   szilles: if it has a forced break, then you're going to apply the
            transform to the two pieces independently
   szilles: e.g. I have text, div, with transform on it, break in the middle,
            that forces 2 paragraphs
   szilles: the transform is on the container

   plinss: another complication
   plinss: … what happens in the next paragraph
   dbaron: so you do the layout with fragmentation but you don't show any
           of it
   fantasai: but treat transformed element as an image
   dbaron: you lay out the transformed element as if it was not fragmented
           and then don't draw it
   dbaron: then you draw it like an image (?)
   glazou: and it doesn't change the position of the following elements

   fantasai: … if you break inside it you do graphical slicing on it
   fantasai: if you lay out while fragmenting you might make it taller
   fantasai: the document as a whole gets fragmented ...
   szilles: transformation is not supposed to ...

   smfr: high level issue, you do layout before transforms
   smfr: transforms are more of a graphical effect you do later
   smfr: you have to break first
   plinss: explains an order of operations
   fantasai: if a trivial transform shifts things around ...
   dbaron: smfr is right that this is not trivial and possibly not reasonable
           to implement
   szilles: the user is not going to like the results
   szilles: because the text is unreadable
   glazou: what's the other option
   szilles: any option is fine because the user can always do avoid page
            break to keep whatever he wants to stay
   szilles: but I think this one is particularly bad

   szilles: I prefer applying the transforms to the two fragments separately
   szilles: doesn't change layout, and most of the types of transforms are
            the kind you just show
   szilles: like a slight inclination
   szilles: it's going to be hard to distinguish the effects between keeping
            an origin and specifying separate origins

   glazou: another issue: repeat origin makes the first fragment visible
           in the first page, but out of the page in the second one
   szilles: if you do a 180deg rotation, both disappear
   glazou: you can have a case where one is visible, and the other is lost
           above the second page
   plinss: if the second piece gets cut off the second page then it gets
           drawn on the first page
   fantasai: that's what the spec currently says
   glazou: that's not workable
   plinss: Transform the fragments individually, and then slice the transformed
           results (potentially putting them on another page)

   glazou: you two different rotations of two different objects
   szilles: is there a use case for wanting to make this work across a
            fragmentation?
   glazou: I thought of an example, given by steve, regions polyfill,
           flow of text, and second one was rotated like that.
   glazou: and your whole document is like that. a flow of text, and a
           gutter that is rotated in 3D.
   smfr: in that case the container was transformed
   szilles: well the contents flow into the container and the container is
            rotated
   szilles: it's not the contents that's rotated, it's the container
   szilles: if you don't pick the right point to rotate around, yes you
            can screw up
   smfr: but in that case you can still do all the transforms before breaking
   szilles: but this example is worse
   smfr: with transforms you can always move things off screen

   glazou: we have a number of proposals here
   glazou: what is the best in terms of user expectations and implementability
   szilles: you won't succeed with user expectations
   glazou: I'm trying to minimize problems
   szilles: so this is the Bhutan principle
   glazou: ideal solution is not possible, so let's do the best we have
   simon: the container itself is fragmented ...
   simon: each fragment as its own transform origin
   szilles: that's what I was arguing for also
   glazou: we needed to list everything
   szilles: that does destroy the effect the user was trying to achieve
            (as david pointed out)
   glazou: we are back to the original proposal I made to steve and alan.
   glazou: does it make sense?
   smfr: transform the fragments independently
   smfr: I would like a solution where layout and breaking happens first,
         and transformation happens later in a graphical layer
   glazou: transform each fragment individually, with the origin relative
           to the fragment
   glazou: if you have 0,0 it is the top left corner of each fragment

   smfr: the transform spec says origin is relative to the border box -
         do we have a good definition of that for fragments?
   <SimonSapin> http://www.w3.org/TR/CSS21/box.html#box-dimensions
   fantasai: the border box of the fragment is well-defined
   smfr: what about the broken edge?
   fantasai: considered zero width, controls for it to be non-zero

   fantasai: this is the simplest thing to implement
   szilles: simplest thing for the user to understand and control
   glazou: so ok...
   szilles: since transforms don't affect layout, they're dangerous to use
   glazou: transform is applied to each fragment independently
   (meme discussions)
   <fantasai> "If you print your transforms, you're gonna have a bad time."
   glazou: we can forge a test case
   simon: we need  a test where content can overflow the page
   plinss: controls to turn on slicing
   simon: if you decide pages are supposed to be above each other, what
          happens when you overflow to the side
   RESOLVED: transformation is applied independently to each fragment.

   szilles: the coordinate system of the transform is defined relative
            to each fragment
   simon: yes, but you could imagine border boxes bounding box of all
          fragments...
   szilles: … it's own coordinate system
   smfr: transforms act as positioning ancestors
   smfr: you can put position absolute inside something transformed,
         the absolute offset is relative to the transformed ancestor
   smfr: what happens when it fragments
   szilles: this is the problem with pagination in the first place
   szilles: because it says that you reset to the page for its position
   smfr: for fixed?
   * fantasai wonders if we need a transform-break property in the future....
   smfr: if you have a position absolute that has descendants
   smfr: a what happens on second page
   bert: the ones that occur exactly at the point where the fragment breaks,
         do they occur on the first or second page
   szilles: similar to a problem with floats and page breaks

   szilles: isn't it the case that with a relatively positioned thing is
            relative to the fragment that it's in?
   smfr: if it has relative position -10px up
   smfr: does it show up on the previous page? or just disappear?
   szilles: disappear
   szilles: trying to consistently apply the rule that the fragments are
            relatively independent things, so you treat them separately,
            rather than trying to figure out what would you have done if
            they were not fragments
   ...

Intrinsic Sizing
----------------

   <SimonSapin> http://dev.w3.org/csswg/css3-box/#intrinsic
   <SimonSapin> http://dev.w3.org/csswg/css3-sizing/
   glazou: let's move back to second simon's issue about sizing
   SimonSapin: we have two conflicting definitions of max-content and
               min-content
   SimonSapin: what’s the plan?

   fantasai: I think the definition in box should be a guiding principle
             for us
   fantasai: but we should be defining specific to each layout module
             exactly how to fulfill this in ways that accommodate practical
             considerations
   bert: I wonder if that's possible
   bert: you want to take into account properties like hyphenation, widows
         and orphans
   bert: can become quite handy
   s/handy/ difficult
   bert: due to lack of resources, may have to fallback to something simpler
   bert: when you have the possibility
   ...
   dbaron: I think box is defining the goal in too much detail.
           overemphasizing the concept of overflow.
   dbaron: when we implemented hyphenation we chose to NOT affect the
           min intrinsic width
   dbaron: we might then choose to hyphenate some things or not
   bert: but if someone turns hyphenation on, don't they want it to change?
   dbaron: not necessarily
   bert: very narrow column with long words in it
   bert: e.g. two columns rather than one
   dbaron: doing the computation for hyphenation is quite expensive
   dbaron: you're going to have to do multiple runs of text measurements
           over the same string, because of kerning, ligatures etc. due
           to where you might hyphenate
   dbaron: we need to get used to the idea that we're defining these things
           in the definitions of properties, and not just trying to do this
           overarching thing doesn't quite work right.
   tantek: agreed with dbaron, prefer specifying in properties instead of
           overarching areas

   bert: we want people to compete on doing things the best possible way
   bert: that's a general principle we want to apply to table and grid layout
   bert: try to make it as compact as possible, but limit to reasonable time
         or hardware
   bert: or if you animate it
   bert: if you have some time to layout a grid, then please try to find
         line breaks that make things as compact as possible
   bert: I don't want unsightly gaps
   bert: I want a way to make tables that actually look good
   bert: at same time, I don't want to force the optimal, but I want to make
         it possible to do the optimal
   bert: CSS should be able to do that
   bert: e.g. with electronic books and such
   bert: so if we say in the intrinsic sizing, here are some hints on
         approximating things, if you're in a hurry, that's fine. but
         if we say you must do it in this approximate way, I don't
         think that's good enough.

   bert: measuring overflow is the best criterion for measuring optimal
         layout or not. maybe there are other things you can measure.
   dbaron: there are all sorts of things like elements with width 110%
           that are always going to overflow
   dbaron: the way we want to do things is build up intrinsic widths from
           leaves to their ancestors
   dbaron: so an element with width 110% may or may not influence the
           intrinsic width of its ancestor, and that is what should affect
           its ancestor's intrinsic width, not the overflow of every
           possible descendant.
   bert: the way you use it is to minimize overflow, not look for 0
   dbaron: it will always overflow out of its parent, but not necessarily
           its great grandparent
   dbaron: but having to worry about that is too complicated and breaks
           the notion of a functional subtrees
   bert: not summing the parts - not how it works
   dbaron: it is how it works - interop across 4 implementations so we
           should document that
   bert: it won't work well for grids and columns
   dbaron: there are rules we can write for grids and columns to make it
           work well

   szilles: I'm losing track
   szilles: 1. dbaron wants a computationally efficient way to get a good
               enough answer
   szilles: 2. and Bert wants an option that's better than "good enough"

   szilles: OTOH I thought I heard this morning that I could define different
            rules for table cells than other circumstances.
   szilles: I think the provision as written allows you to change the rules
            for table cells
   szilles: I'm not arguing you want to, in principle you could special
           case table cells
   dbaron: of course we have to special case table cells and intrinsic
           width of a table, and the way you deal with percentages is...
           interesting
   dbaron: I don't think we want to just say that's derived from a general
           principle, I think we have to write up what the rules are
   bert: at some point I want a third table layout algorithm where you
         actually get what you want in a table

   bert: I think we need something for things like regions
   bert: it makes a difference how much you put in one region vs. the
         second region
   bert: because of the affect it has on other regions, same size, or
         fit on the page, or hyphenation possibility in one case and
         not another.
   bert: those are local things that have a very global or much higher
         level than a single element effect

   szilles: I think it's reasonably clear.
   szilles: the piece I don't understand is
   szilles: I agree with what david just said
   szilles: document what's interop
   szilles: that doesn't handle bert's piece where I want to allow people
            to do better if they can and not be in violation of the spec
   szilles: bert's definition was intended to say what he thought what
            better meant
   szilles: david points out that doesn't help the reader of the spec
            because it leaves too many unanswered variables to get a
            useful initial implementation.
   szilles: I'm looking at ways to specify the sizing thing in a way that
            you can say that implementations may do better than this and
            still be conformant
   szilles: OTOH people complain when two implementations don't break
            lines in exactly the same place
   szilles: every time we don't specify exactly what the answer is someone
            is unhappy
   glenn: specify an open source tool open source font will make the same
          line breaks
   szilles: I can think of lots of reasons to not go there - separate issue
            - not related to sizing

   szilles: david, do you have a problem with doing better?
   dbaron: there's a large amount of content out there that depends on
           particular behavior
   szilles: I would prefer that the leaving open be in the sizing module
            but I don't know how to say it
   dbaron: it sounds like the path we're going towards is, Bert want CSS
           as a whole to allow implementations to do better
   dbaron: I would like a specification for how CSS is used on the web
           that specifies what you have to do to be compatible with
           what's on the web
   dbaron: if those have to be two different specifications that would be
           unfortunate

   simon: bert is right that the sizing spec would close the possibility
          of doing better at some point
   simon: but maybe the spec can include that
   simon: similar to a recent proposal of balancing text in line breaks
   simon: what you do normally, and balancing which is more expensive
   bert: difficult in how you specify
   bert: some way to say please do this optimal
   bert: or 50% of
   bert: depends on algorithm and parameters
   simon: maybe resolve by documenting how web works today
   simon: and have a way to do an optimal switch
   bert: already differences today
   bert: some impls do better line breaks than others, some do better
         page breaks

   glenn: if you want an opt-in approach, it should be to opt-in to choosing
          the browser standard
   fantasai: no that has to be the default for browsers
   glenn: no it doesn't have to be
   fantasai: if it's going to break the web, you can't make it the default
   glenn: there is no breaking the web when it comes to sizing
   fantasai: there are somethings that no matter how weird crazy they are,
             you have to implement them
   simon: for me as an implementer it is important that this is documented
   szilles: I like simon's suggestion that we define a particular algorithm,
            and we can add a property later for the author to specify that
            he wants a different criteria to be used for sizing
   szilles: it would be left up to defining whatever criteria would change
            for the new property/value
   szilles: but it would at least give us a baseline for today

   bert: but problem is with the old content
   bert: old content doesn't done have hyphenation
   bert: hyphenation should be turned on by default
   john: problem is with content suddenly changing. If you suddenly upgrade
         the browser and the page layout changes it's a problem.
   john: issue for microsoft products
   smfr: issue for us too
   smfr: but we tell people cannot depend on pixel-same rendering from
         release to release
   simon: bert, use your user style sheet to turn on hyphenation
   simon: we don't have to change the definition of in CSS initial values
   szilles: for hyphenation you really need to say letter counts and
   szilles: there are ...
   szilles: I prefer the opt-in approach
   plinss: you could also do user vs. ua style sheet
   fantasai: I think bert and I need to sit down and shift texts into one
             place
   fantasai: here is what you can potentially do better, and here is the
             baseline of what browsers should do
   fantasai: and yes there will be a gap where behaviors could be better
   fantasai: the algorithm will be normative, that will be the baseline
   simon: how can you do better then?
   fantasai: because you say so in the spec, that you can do better
   fantasai: e.g. for multicol the spec already notes possible need to do
              many many passes to do better measurement. we already say
              the rules there will only give you an approximation.
   fantasai: if you can do better, you may do better
   fantasai: I think action should be for me and bert to incorporate the
             text from box into sizing and ...

   tantek: I think there are 2 principles worth documenting
           (1) ... interop/deterministic layout ...
           (2) we want CSS to allow as high fidelity layout as possible.
   tantek: I'd like to action parties to write these up (e.g., on wiki)
           so we can reference them
   <SimonSapin> +1 for having the rationales somewhere, as Tantek says
   ACTION: Bert, write-up CSS design principle of defining CSS features
           to allow implementations to potentially do as high fidelity
           layout / presentation as possible.
   <trackbot> Created ACTION-540
   ACTION: fantasai write-up CSS design principle of defining baseline
           CSS features with deterministic algorithm(s) that reflect
           interoperable implementation behaviors and compatibility
           with web content
   <trackbot> Created ACTION-541
   ACTION: Bert work with Elika remove material on sizing in Box module
           and incorporate equivalent material into Sizing module.
   <trackbot> Created ACTION-542
   ...

plins: overflow
dbaron: postpone to teleconferences
john: I have a minor issue
<br type="stretch">
Received on Wednesday, 20 February 2013 05:27:27 GMT

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