- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Feb 2013 20:10:44 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Paged Media Level 4
-------------------
- RESOLVED: glazou to start css4-page based on ideas outlined in minutes
and http://www.w3.org/mid/50F29E84.1050804@disruptive-innovations.com
Flexbox
-------
- RESOLVED: Zero-length boxes stay at end of earlier line unless line is
already overflowing, in which case they wrap
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-1
- RESOLVED: flex line's cross size is floored at zero
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-2
- Opened issue on percentage margins on flex items
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-16
- Flex items' cross size to be definite when stretched to fit definite size.
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-3
- RESOLVED: Defer additional spacing controls to Level 2
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-4
- RESOLVED: Proposed handling of stretched items with intrinsic aspect
ratio is accepted.
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-8
- RESOLVED: http://lists.w3.org/Archives/Public/www-style/2012Dec/0041.html
is WG response for
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-9
- RESOLVED: Flex items can have negative outer size; no clamping to zero
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-10
- RESOLVED: ::first-line/::first-letter don't apply to flex containers.
Could revisit later if this is in high demand.
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-13
- RESOLVED: overflow applies to flex containers
http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-15
====== Full minutes below ======
Paged Media Level 4
-------------------
Scribe: fantasai
<glazou> http://www.w3.org/mid/50F29E84.1050804@disruptive-innovations.com
glazou: One of my activities right now is my EPUB editor
glazou: We have a few issues between IDPF and ourselves, W3C
glazou: They are taking things from us that are unstable drafts
glazou: They rely exclusively on XML serialization of HTML5
glazou: One thing ppl do with electronic books is convert Word documents
glazou: Word allows very powerful headers, footers, footnotes, bookmarks,
etc.
glazou: GCPM has very weak headers/footers, and all data you can put
there comes from generated content
glazou: These are not elements. They're just text.
glazou: Not enough to import document coming from word processor
glazou: We are far behind
glazou: What we do, allow, is not enough to allow ebooks
glazou: And not enough to allow importing Word documents into Web formats,
Ebook formats
glazou: The way Håkon designed headers/footers in css3-page
glazou: He divides the page margin into 16 boxes
glazou: We have new specs on the radar for csswg, grid, flexbox, regions, etc
glazou: That allow precise layouts
glazou: we don't need so many boxes now
glazou: The idea is to take the parts of GCPM/css3-page that make sense
glazou: And for the rest, deprecate almost what's in Paged Media
glazou: And move towards much more powerful page definitions
glazou: Get flows of content, like what's in the Regions spec, to allow
powerful complex headers/footers, which we don't have right now
glazou: If I take first word document from my hard disk, e.g. invoice
glazou: It has header with quote number invoice number, customer number, etc.
glazou: All of that is lost when you import to HTML+CSS
glazou: ebook industry is big enough that we should address this problem
glazou: The current GCPM and css3-page are only implemented by batch
processors
glazou: There's not a single browser implementing bits from these specs
glazou: Very basic properties, page size, maybe
glazou: I'd like to hear reasons why they were not implemented
glazou: Not a priority? Only for batch processors? Not implementable?
Bad perf?
glazou: My idea is to start Paged Media Level 4
glazou: If you're absolutely not interested, though, it's not worth the time.
glazou: Would reuse bits of L3
tantek: Even if no one is interested, if you have ideas on a simpler
proposal, it's worth writing up
tantek: Seeing your ideas may spur other ideas
<stearns> would this be only for printed output, or would it also include
paginated views?
glazou: It's not just simplification, but also a harmonization with
other proposals in the CSSWG
glazou: In HTML5 we have <header> and <footer> elements. We are not
able to deal with them on a per-page basis
dbaron: Wrt priorities, I think the current draft has not been as high
priority as other things
dbaron: I think there are many features that look like a lot of work but
don't get you much contributes to that.
dbaron: But that's not the only reason.
glazou: Not asking for commitment to implement or even review, but can
I start a draft?
[people seem supportive of this idea]
tantek: One big change that has occurred since GCPM was first developed
and framed is, we shifted from a desktop/print-centric web to
a mobile web
tantek: GCPM feels heavyweight large screen
tantek: That's not the focus to day. The focus is mobile.
tantek: The only advice I give is any simplification should first,
foremost, solve mobile use cases that paged media has rather
than books, print, all these edge cases
glazou: Books are an edge case?
szilles: 5% that everybody uses is still pretty important
szilles: displaying info is key role of Web
<stearns> mobile (particularly tablets) should raise the priority of
paginated views, imo
szilles: At least one issue with small screens is being able to have
reasonable pagination
tantek: Do reasonable pagination, but also need to solve the scrolling
problem.
glazou: Wrt mobile, one major application is ebook reading
tantek: Yes, mobile ebook reading, but rather than massive complex
texts everyone brings as examples
molly: Isn't it included
molly: Our primary role is to have interop across these devices
molly: I disagree, having many years in publishing industry
molly: Was talking about GCPM to Tim O'Reilly, he said "We are desperate.
EPUB does not fulfill the needs we have. We need solution that
incorporates the open standards."
Rossen: I wanted to mention, the GCPM spec, the way it is currently standing
Rossen: We've been looking at it quite a bit
Rossen: it's not something which is easy to develop on top of
Rossen: Are we building a platform that other ppl will build on top of?
Rossen: Or are we building the platform which is the reader?
Rossen: GCPM defines a nice reader app
Rossen: If you're building a platform, then implementing GCPM itself
does not allow enough programmability for ppl to build on top of
glazou: You are thinking in terms of implementation. I'm thinking in
terms of readers and books [?]
glazou: Ebook publishers need to do a lot more with footers and headers
glazou: Not a question of platform, question of usage.
* stearns agrees rabidly with Rossen
Rossen: My point is, e.g. debate of "what is a page". Author should
define what is a page.
Rossen: Whatever we do should also be printable
Rossen: All efforts currently putting forward in Fragmentation, regions,
etc, are all moving in that direction of exposing enough
primitives on platform so ppl building apps on top can have
sufficient resources to do that.
glazou: Again, what I have in mind is more harmonization with other specs
on WG's radar, than something entirely new
glazou: We have plenty of things, and we don't use them for page definition.
We could. It will be much better tailored and much more maintainable
and manipulable for Web authors
glazou: More controversial... footnotes
glazou: Way they're done in GCPM is way complicated. Should do them with
flows.
glazou: Same thing with bookmarks
glazou: A footnote would be an element with some flow
glazou: Has to be tailored, but should be doable.
glazou: Mention the ebook case because I'm working on it, but it's not
the only one
glazou: When you want to display data, you want to paginate, to scroll
between pages.
glazou: We don't address that.
glazou: We are too weak in terms of CSS rendering
glazou: So goal is to try to do that
glazou: My assumption is not that you will agree immediately, but submit
ideas to WG and start discussion on that
glazou: Would give very good signal to IDPF if we do that.
RESOLVED: glazou to start css4-page based on ideas outlined above
SimonSapin: I agree with most of what you said, except for the part
of deprecating css3-page
SimonSapin: … because it’s been implemented and used for many years,
even though not on the web
* dbaron wants to ask Rossen what he meant by defining what a page is
<Rossen> dbaron, my point is that I don't want to define "what a page is",
I want to give authors the ability to define it themselves
<dbaron> Rossen, are you talking about allowing authors to do paginated
overflow like in Håkon's overflow:paged proposal, or something
else?
<Rossen> dbaron, this is a good start but not sufficient if you want to
allow variable page sizes
<dbaron> Rossen, that sounds like regions or overflow:fragments
<Rossen> dbaron, yes, these proposals are really good start in this
direction
Flexbox
-------
<fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012
First issue is handling of zero-length boxes at end of line
<TabAtkins> http://dev.w3.org/csswg/css3-flexbox/#algo-line-break
fantasai: Question is what happens if first item is really wide,
then add zero-length item
fantasai: Should it stay on first line or go to next line?
[discussion of flex line breaking]
fantasai: We put items until you overflow
TabAtkins: Then back up by one
<fanasai> (unless it's the first item, then don't back up, just break)
TabAtkins: It's possible that you have a negative-length item that
will make an overflowing item fit, but we don't look ahead.
szilles: Overflows lefthand side of flexbox?
szilles: What are user expectations?
TabAtkins: Don't use negative margins that big?
<dbaron> sounds like it's worth being clear about what happens with
negative margins, and not looking further forward
fantasai: Not a big user expectation issue. Edge cases, we want to
make sure implementers are happy with it
TabAtkins: Suppose flexbox is 300px wide. First 2 items 200px wide,
third is -100px
TabAtkins: Theoretically, can fit all three in box
TabAtkins: But since you overflow after adding the second, you break
after the first item.
TabAtkins: If ordering was different, had third before second,
then all three would fit on first line
dbaron: I'd support defining the negative margins case clearly; it's
not defined clearly for inline layout.
fantasai: In the same example, if we had a first item of 400px,
and second item is 0px or -100px
fantasai: In both cases, the second item would wrap, even though it
doesn't increase the length of the flex line
fantasai: This last example is what this issue is about.
fantasai: Any further comments? People happy with this interpretation
of line-breaking?
szilles: Record what Tab said, that use of negative box sizes is
discouraged, but it's defined, and in a way that doesn't
require excessive lookahead
RESOLVED: Zero-length boxes stay at end of earlier line unless line is
already overflowing, in which case they wrap
Issue 2: Handling of negative-size flex lines
fantasai: If all items in a flex line have negative cross-size, does
the flex line have negative or zero height?
TabAtkins: Decided to clamp the flex line's cross-size at zero
TabAtkins: Could let them be negative, but don't see any reason to do so.
Rossen: wrt regular block flow, where you can do that...
TabAtkins: If you have a wrapper div in block flow, and fill with
negative size things, div is still at least zero height
Rossen: [...]
TabAtkins: You can't have negative-height lines, because only way to
get negative sizes is negative margins
TabAtkins: In main dimension, can have items overlap each other
TabAtkins: and have them be negative
TabAtkins: In cross direction, can overlap, but not have negative
cross-size for lines
szilles: Note that some of these issues are relevant to inline layout
fantasai: This one doesn't apply, because of root inline's line-height.
RESOLVED: flex lines are floored at zero
Issue 3: stretch and percentage cross-sizes
fantasai: Wanted to fill flex items, e.g. each item having content
with height :100%;
TabAtkins explains Rudolph's case
TabAtkins: No way to fill it without invoking more flexbox
TabAtkins: Believe our proposal is do nothing, it's currently
workaroundable
fantasai: But no way to do, e.g. 50% fill
fantasai: Btw, what are percentage margins relative to on a flex item?
TabAtkins: Think it's same as block
fantasai: So relative to containing block's width for both horizontal
and vertical margins?
Bert: Should it be relative to writing mode or flex direction?
TabAtkins: If you think of flex as better block, then should be consistent.
Rossen: If your cross size changes, you have margins in percent, that
resolves from the main size, by increasing your cross size,
main size will increase.
fantasai: Guess this a separate issue, should probably double-check
that things work sensibly.
ACTION fantasai: investigate handling of percentage margins on flex items
<trackbot> Created ACTION-532
[discussion between Rossen and Tab wrt margins]
Tab, Rossen, and fantasai to investigate during the break
fantasai: So back to the issue, a related concept is that if you have
'stretch' item, it does not propagate definiteness from the
flex container to the flex item, so you can't resolve
percentages against it.
fantasai: In Rudolph's case, it's trying to reference an auto size,
so percentages definitely wouldn't work.
fantasai: But suppose flex container is definite size, 'stretch'
doesn't allow to resolve against that height right now
Rossen: Should do so, because stretch is equivalent to height 100%
Rossen: We did the same thing for Grid as well
ACTION TabAtkins: Make stretch definite when flexbox is single-line
Issue 4: Constant spacing around items
http://lists.w3.org/Archives/Public/www-style/2012Oct/0249.html
TabAtkins: Basically requesting more spacing controls
TabAtkins: Have had similar requests from Yehuda Katz
TabAtkins: Wanting to put fixed spacing among items
TabAtkins: This one wants specific spacing between flex lines, preferably
same as spacing between flex items on same line
TabAtkins: Think to defer to Level 2. Want more spacing controls,
but do a proper treatment of it later.
RESOLVED: Defer additional spacing controls to Level 2
Issue 5: http://lists.w3.org/Archives/Public/www-style/2012Oct/0220.html
fantasai: If you have percentage that can't be resolved, CSS2.1 says
it's treated as auto. Currently spec says it computes to auto,
but we decided it's actually the used value that's auto
fantasai: We need that to be clear for this issue to be clear in Flexbox
TabAtkins: Stretch checks against computed value of 'auto'
fantasai: So question is, when does 2.1 erratum get published?
http://lists.w3.org/Archives/Public/www-style/2012Oct/0437.html
http://lists.w3.org/Archives/Public/www-style/2012Oct/0466.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392
Bert: Did we want to keep the computed value as a percentage so you can
back-resolve the parent's width?
fantasai: No idea. Just know that the current text is wrong.
fantasai: Bert, do you need anything from the WG on this issue?
ACTION Bert: Update errata, CSS2.1 spec for bug 15392
<trackbot> Created ACTION-533
Issue 6 was editorial
Issue 7 was straightforward, fixing conflicting wording in spec
Issue 8 we discussed in December, was waiting on Rossen to confirm
http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
http://lists.w3.org/Archives/Public/www-style/2012Dec/0040.html
Rossen: We ignore aspect ratio once main size is determined
Rossen: Have overlapping content?
TabAtkins: No, no overlapping. Just ignore aspect ratio
Rossen draws example
<div flex><img/><img flex:1/></div>
div is 300px, images 100px each, square
div is 200px tall
TabAtkins: If it's single line, they both stretch to 200px, and main
size increases to 200px accordingly
TabAtkins: Then second one is flex: 1, so it negative-flexes to fit,
becoming 100px wide. Stays 200px tall.
RESOLVED: Proposed handling of stretched items with intrinsic aspect
ratio is accepted.
Issue 9
RESOLVED: http://lists.w3.org/Archives/Public/www-style/2012Dec/0041.html
Issue 10: Do flex items with negative margins increase available space?
fantasai: Flex items can have negative sizes, we don't clamp the outer
size to zero
RESOLVED: Flex items can have negative outer size; no clamping to zero
Issue 12: Orthogonal Flex Layouts Sub-optimally Defined
fantasai: We haven't figured out how to solve this yet, so still open
Issue 13: Should ::first-line/::first-letter apply to a flex container?
fantasai: Mailing list seemed to think, why bother at this point,
nobody seems to be demanding it and it's additional complexity
TabAtkins: It wouldn't be too tricky, since you'd be propagating into
the first flex item.
RESOLVED: ::first-line/::first-letter don't apply to flex containers.
Could revisit later if this is in high demand.
Issue 14 was closed as invalid
Issue 15: Should 'overflow' apply to flex containers?
TabAtkins: We answered yes
dbaron: It's a lot of work
TabAtkins: Two of us already do it
dbaron: Is the idea that you run the entire flex layout algorithm as if
the container is that size
TabAtkins: And if you overflow, you add scrollbars and do it again
dbaron: If you have horizontal overflow, you make a scrollbar that can
go out to there, but then you do the layout as though the width
is still the original width minus the scrollbar.
dbaron: Is that clear?
fantasai: I think that's implied in the way overflow is defined
RESOLVED: overflow applies to flex containers
<br type="tea">
Received on Friday, 15 February 2013 04:11:20 UTC