- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 19 Feb 2013 21:26:56 -0800
- 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 UTC