- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Nov 2010 15:43:39 -0800
- To: "www-style@w3.org" <www-style@w3.org>
CSS3 Multi-Column Layout
------------------------
- RESOLVED: If a columnspanning element doesn't fit within the multicol
element without overflowing, then it doesn't span anymore
- RESOLVED: column-span applies to "in-flow block-level elements"
- RESOLVED: column-spanning elements are BFC roots always
- RESOLVED: Initial value of column-span is 'none' (to distinguish BFC
behavior of 1-spanning and not-spanning).
- RESOLVED: Columns overflowing due to forced breaks and not constrained
height overflow to the right, rather than wrapping to a new
column row below. Note this causes dataloss when printing.
Flexbox
-------
- RESOLVED: Change prefix from box- to flex-
- RESOLVED: Combine box-orient and box-direction into flex-direction
- RESOLVED: Split box-flex into flex-grow and flex-shrink
- RESOLVED: 'auto' margins flex as 1
- RESOLVED: Drop box-flex-group
- RESOLVED: Mark multiline at-risk.
- RESOLVED: Rename box-ordinal-group to either flex-order or flex-index
(mark exact name as issue)
- RESOLVED: Mark entire transverse alignment as an issue until further notice.
GCPM
----
- Discussed problem of specially styling pages that are the first or last
page of a named page set, or that belong to the spread containing that
first or last page.
- Discussed problem of tweaking page size to handle widows or orphans.
- Discussed hyphenate-last-line-avoid property proposal.
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
John Daggett
Elika J. Etemad
Sylvain Galineau
Daniel Glazman
Soonbo Han
Koji Ishii
John Jansen
Hĺkon Wium Lie
Peter Linss
Markus Mielke
Alex Mogilevsky
Ilkka Oksanen
David Singer
Anne van Kesteren
Steve Zilles
Agenda: http://wiki.csswg.org/planning/tpac-2010
<RRSAgent> logging to http://www.w3.org/2010/11/01-CSS-irc
<RRSAgent> http://www.w3.org/2010/11/01-CSS-minutes.html
Scribe: fantasai
CSS3 Multi-Column Layout
------------------------
howcome: I would like to confirm agreement on a few things
howcome: Implementations seem to be coming along nicely
howcome: Hopefully all of the functionality in the spec
howcome: We need some clarifications in the spec
howcome: It's all about spanning elements
howcome: Remember we have a multicol element here, and we lay out
in colums
howcome draws on the board
howcome: The issue is overflow
howcome: There are two reasons for overflow: you could have a
constrained height
howcome: or you could have forced column breaks, more breaks than
you have columns
howcome: The issue is what to do if you have an element with
column-span: all in one of the overflow columns
howcome: Alex proposed to do nothing, i.e. pretend column-span was
not set
howcome: If it's in the overflow columns due to forced breaks,
though, I think it makes sense to have it break the column
row and render as column-span: all, with content following
it filling in columns in a row below it
?: What if you have both a constrained height and forced breaks?
Alex: If it's due to forced breaks, you can try to put it in the main
section. And if it doesn't fit and cause overflow, then you put
it in an overflow column and ignore the spanning behavior
Alex: One special case: when you try to place a colspan and it itself
doesn't fit, and creates overflow. That creates a circular
dependency
Alex: I think we resolved that if it doesn't fit as a span, you ignore
the span
howcome: So the distinction is, if it fits inside the multicol element
as a span, then it does so, else the spanning behavior is
ignored
dbaron: You could also ignore in all cases when there's a constrained
height
stevez: I think it should be if it fits or not
howcome: I think we should honor it in as many cases as possible, so
I think we should hinge this on whether there's room or not
stevez: This might interact with the EPUB case, where they paginate
in addition to doing multicol
Alex: If the forced-break case is height-constrained, where does the
overflow columns go?
Alex: Do the columns overflowing from the second row have full height,
or shortened height, i.e. height after the rowspan?
dbaron: So you're saying whether colspan works at all...
howcome: is dependent on whether there is room inside the multicol element
Alex: This could create a very ugly case if you have only one line of
space left at the bottom of the multicol. you would create
one-line-high overflow columns off to the right
Alex: As the available space after the colspan approaches zero, the
number of columns for content after it approaches infinity
fantasai: From an implementation perspective, I would prefer this method.
fantasai: The main reason we simplified column-span to 1 or all instead
of arbitrary numbers was to avoid a column row with columns of
multiple heights
fantasai: if overflow columns were full-height columns, then we lose
that simplification
SteveZ: Epub wants to have pagination, especially in the multicolumn case,
because they want to avoid overflow behavior when there are
mulitiple columns
fantasai: (Also, if forced-column-breaks can create overflow columns,
then your full-height columns would overpaint any such
overflowing columns before the column span)
[note to minutes: insert pictures]
dbaron draws some content on the board
I have a some text, then a forced break, then more content.
Then a spanning element.
tab, fantasai: Then you balance the content, which may introduce breaks
in the column before the forced break or after it or both
RESOLVED: If a columnspanning element doesn't fit within the multicol
element without overflowing, then it doesn't span anymore
New questions:
1. do columnspanning elements create a new block formatting context
2. does columnspanning turn inline elements into blocks?
3. If the answer to either of the above is yes, does that behavior apply
when the columnspanning is ignored due to overflowing (as resolved above)?
2... or does it not apply to inline elements
fantasai: I think column-span should only apply to block-level elements
Bert reads the applies-to line from the spec
RESOLVED: column-span applies to "in-flow block-level elements"
dbaron: Note in the prose that it has no effect on elements outside a
multicol element
<dbaron> Well, really I said that maybe the in-flow aspect is the same
as the doesn't-work-outside-multicol aspect, and then we got
to that conclusion.
fantasai: If a column-spanning element is a BFC root, then margins don't
collapse through its boundaries.
fantasai: I don't think that margin behavior should change based on whether
a colspan is honored or not.
<sylvaing> CSS3 Multicolumn http://www.w3.org/TR/css3-multicol/
fantasai: So if it's a spanning element, it should automatically become a
BFC and no longer collapse margins through its boundary,
whether or not it's triggered the overflow nonspanning case
fantasai: I think we might need to distinguish whether an element is
spanning one column or not spanning, because of this.
dbaron: I really don't want whether something is a block formatting context
root depend on layout
dbaron: I really want to know what floats are relative to before layout
tabatkin1: So they should become BFCs regardless of whether they actually
span something or not
dbaron: We shouldn't have tricky behavior for an error case
Steve: So column-span: all; would mean span the current column in the
overflow case
Steve: i.e. the all in that case means the one column
RESOLVED: column-spanning elements are BFC roots always
RESOLVED: Initial value of column-span is 'none'
<szilles> Arron, the reason for column-span="none" is to be able to say
that an element without an explicit column-span value does not
create a Block Formattring Context
Bert: Last issue is, do margins between spanning elements collapse?
Bert: e.g. if I have H2 followed by H3, can their margins collapse
fantasai: What about between the spanning element and the content of
the columns above and below it?
Roughly, answers seem to be Yes, and No, but discussing...
Back to fantasai's issue
fantasai: If you get more columns than you have space for due to forced
column breaks, then I think instead of overflowing to the right,
I think the columns that don't fit should create a new column
row rather than overflowing off to the side.
fantasai: This way we avoid an overflow case.
Alex: I'm concerned people would use this for some weird design cases
that don't work well
Steve Zilles echoes the concern
<Bert> (If the columns "wrap," i.e., the n+1st column starts underneath
the 1st, then this becomes a way to make a grid in some cases.
Effect is almost the same between 'display: inline-block' and
'break-after: always'...)
dbaron: I'm concerned that we're getting too far from what we're implementing
howcome: We have implementations of multicol, we have to resolve these issues
dbaron: We're not getting much author feedback on columns
tabatkin1: They're not useful in continuous media
more discussion of this case
steve zilles thinks this solution causes bad layout
fantasai thinks avoiding overflow is important
steve: People will insert forced breaks randomly in order to get the
layout they want
fantasai draws a multicol element overflowing, showing how block-column
overflow would result in a bad overflow situation in the
constrained height case: since the height is constrained, placing
overflowing columns below the first row overwrites any content
after the multicol element
fantasai draws another one where the multicol has an auto height and
stretches to fill the content; in this case, if columns are
wrapped below the first row, no such overflow occurs
tabatkin1: Assuming overflow:visible, yeah, it looks ugly. But you only
get the good overflow if you have explicit column breaks based
on where you think is "good".
fantasai: Right, so far. Ideally we'll have in the future a "column-length"
that can cause new column rows without forced breaks
<arron> referring to the first drawing by fantasai, are the columns
overflowing to the right or below?
<tabatkin1> arron, they're overflowing down, overlapping content in later
elements.
<dbaron> but the drawing is to say that's why they don't overflow down
fantasai: If we think that column length is needed to get a sane rendering,
maybe we should go ahead and just add column-length now.
fantasai: I'm not happy with creating overflow cases when they are not
necessary
szilles: I could live with multiple breaks overflowing to the right today.
fantasai: If we do that today, then you would have to use column-length in
order to get explicit-break columns to wrap
tabatkin1: column-length is not the right trigger for wrapping overflowing
explicit break columns
tabatkin1: if they're explicit breaks, they're explicit breaks
tabatkin1: If you set column-length: 40em; and your explicit breaks are at
20em, what's your column row height?
steve: Ok, I see what you're saying
Steve: Ok, I'm willing to withdraw my objection provided you add a note
about this column-length property
steve: My concern is that people will start putting in explicit breaks
just to get the behavior that column-length would have given
Steve: But if you at least put in the spec that this is not intended for
this purpose, and how we want to proceed
Peter: Authors don't read the spec. They'll do whatever it takes to make
content work the way they want it right now.
Peter: Let's just put this property in right now.
dbaron: I'm not sure this is useful
tabatkin1: This would make multicol usable for me
Peter: Fundamentally, multicol doesn't make much sense on continuous media
Peter: But let's not force people into making unusable layouts.
dbaron: I'm not sure we're addressing use cases with multicol
dbaron: And I don't think we would implement all this.
fantasai: column-length is a piece of cake if you do either spanning or
pagination
dbaron: But we don't implement column-spanning. And we can't balance columns
with forced column breaks in our current design.
Kai: We have a lot of demand for this, actually.
Kai: We haven't switched from table layouts to CSS due to lack of multicol
howcome: So how would you decide the gap between the column rows?
fantasai: use column-gap
fantasai: can give it two values, just like border-spacing, if needed
Alex: I want separate properties
fantasai: Do you need them to cascade independently?
Alex: I just like having separate properties
fantasai: If we need separate properties, we can split them out later
and make column-gap a shorthand.
Steve: In XSLFO, we replicated the multicol box
various concerns raised to porting this idea to CSS
<Bert> (Chained regions, e.g., César's extensions to template layout,
would solve most use cases as well. That, too, is an example of
pagination inside a continuous display...)
Steve: I'm going back to my position of putting a note that this doesn't
solve the following problems.
howcome: We go back to the issue of where the overflowing forced-break
column goes: off to the right, or wrap under?
howcome: I'm in favor of wrapping under, quite stronger.
Alex: You need gap and rules, though.
fantasai thinks we should just use the column-gap and deal with customized
gaps and rules later
steve: But I don't think column-gap is good enough.
<Kai> q+ to say that currently control over layout is key
fantasai: I'm not saying it's good enough, I'm saying it's adequate as a
default even in the future when we have all these controls
fantasai: The only other reasonable default is a zero gap. I don't see how
that's better
...
tabatkin1 doesn't want to half-ass this
...
Kai: Web page layout is very precise right now.
Kai: Automatically wrapping columns loses precision
Kai: It's easier to control if it always overflows to the right
<Kai> it would be good to have this as default and have the ability to
have it wrap
howcome takes a straw poll on behavior
A - overflow to the right
B - wrap under
Bert: A
Kai: A
Steve: A
Peter: B
Markus: A
Tab: A
beth: A
?: A
??: B
Chris: A
Daniel: A
John: A
Sylvain: A
Koji: A
Arron: A assuming right is actually end
fantasai: B
arron, :)
Alex: A
dbaron: A
jdaggett: A
howcome: B
no comment from the observers in the room
Peter: I think it's unfortunate that we're choosing a behavior for multicol
that doesn't work well for print
RESOLVED: overflow to the right
Flexbox
-------
<tabatkins> http://www.xanthir.com/blog/b48Z0
tabatkins: I put up a list of all the new changes that Alex and I have
agreed on for the flexbox draft
fantasai suggests putting that on the mailing list
tabatkins: Most are pretty small; syntax-level changes
tabatkins: Major one is that we're changing the prefix from box- to flex-
tabatkins: Because box is overloaded in CSS
tabatkins: The next is determining the direction
tabatkins: We used to have two properties for that
tabatkins: Don't believe they need to cascade independently, so merged
them into one that has all combinations
dbaron: That probably makes sense
tabatkins: At the last F2F sorta decided that things should flex differently
when they're growing from when they're shrinking
tabatkins: e.g. having the biggest flex, which normally becomes the biggest,
become the smallest when shrinking
tabatkins: Split into flex-grow and flex-shrink
tabatkins: Also margins participate in flexing
tabatkins: 'auto' flexes as 1
tabatkins: Very common use case was splitting things to align half items
on left, half on right
tabatkins: previously had to add a dummy element
tabatkins: now can do that with margins
tabatkins: Keeping box-ordinal-group, renamed to something shorter
tabatkins: Multiple lines, not super-sure about
tabatkins: Seems like a large enough topic that it should be addressed
more thoroughly
Alex: There are no current implementations right now of multiple lines
tabatkins: so thinking we might push that for the next level
Alex: What was the motivation for multiple lines?
dbaron: You'd have to ask hyatt. Not sure he'd know either
Alex: We had some use cases that seemed interesting, but not sure any
of them are really important.
Alex: One example of multi-line box is a dialog box with a lot of tabs
Alex: But that's not a good design to begin with
Alex: The biggest problem with multicol is how to handle the last line
Alex: Sometimes there's only one item on the last line
Alex: I'm not sure I've seen any good design for this
Alex: So multiline is only useful in combination with max width or
something like that
fantasai had a use case of a catalog, with tiles representing each item;
fantasai: But pushing multiline flexbox to a next level makes sense to me
tabatkins: The major change is alignment in the transverse direction
tabatkins: Previously handled with box-align, which would align the box
to the top, bottom, or centered
tabatkins: or could stretch the box
tabatkins: I expressed some unhappiness about that design
tabatkins: I spent some time looking at it and realized you can do every
case except baseline with margins
* Bert (Talking about tab cards: I'd still like some way to turn a UL,
or a sequence of SECTIONs, into a stack of cards with tabs...
But that's unrelated to flexbox.)
tabatkins: Current proposal is to have one keyword that makes the box shrink
tabatkins: Can align that box with margins
tabatkins: [...]
dbaron: The thing that seems weird to me is if the child is itself a flexbox
with the alignment in the other direction
dbaron: It's unclear whether to throw out box-align or throw out box-pack
dbaron: normally the child is in the orthogonal direction
dbaron: The control was for the alignment in the axis direction
* fantasai is not understanding
dbaron: With your new proposal, if the child is a flexbox with an orthogonal
direction
dbaron: which do you use?
dbaron: because you have two different things telling you how to align stuff
tabatkins: depends what the child wants to be
fantasai: I'm getting confused here
Alex: I think it's a good point. What we're trying to do here is require
that the child layout has certain capabilities
Alex: So far there is only one precedent of requirement for nested layout,
ability to declare its own baseline
Alex: We're adding requirement of declaring vertical alignment
Tab draws a big box with two small boxes inside
one on the left one on the right
right child has three boxes stacked vertically and is a flexbox
left child has squiggles aligned to the top
align: before assigned to big box
pack: end assigned to right child
Tab: Hm, I see what you're talking about. Yes, this needs to be explicitly
resolved somehow
dbaron: I think you'd want the thing on the child to beat the one on the
parent
fantasai: Maybe make it not apply to flexboxes
Alex: What if the left one is a table?
dbaron: I think you want these differentiations to apply to non-flexbox
children
Alex: Could define this alignment to only apply to block containers
dbaron: baseline has its own problems with vertical-axis flexboxes.
That's it's own problem
Alex: We're making a complicated problem just to solve baseline alignment.
Not sure it's worth it.
Tab: baseline alignment is very common for e.g. tab strips
Tab: Say I have <ul> with <li>, render as a horizontal flexbox tab strip
Tab: Would want different alignments, bottom aligned, baseline aligned,
centered...
Alex: .. nested elements?
Tab: How would you do that with nested elements?
fantasai: You might want to align to the top baseline or to the bottom
baseline
Alex: Let's step back and talk about logistics of the spec
Alex: Let's suppose hypothetically that next implementation comes out
with this new syntax
Alex: Are the existing implementations going to add another new prefixed
implementation for this new spec and then on the next round it will
become standard which will be in three years from now? Is that the
route that we are looking at?
Alex: The alternative would be to make small changes to the spec which
makes Mozilla and WebKit implementations nearly compatible with
the spec
Alex: Which means next release of webkit/mozilla/ie would bring us close
to CR
Tab: There are some changes that are important and we definitely want,
e.g. flex-grow flex-shrink split
Alex: Question is do we consider existing implementations important in
validating the spec, in which case we are trying to make less
changes as long as they are equivalent
Alex: Or are we taking the position that we are changing everything freely
Alex asks dbaron
dbaron: I think in the end we're going to have to rewrite a lot of it
either way. Hard to say when that's going to happen.
dbaron: But I think we should try and get this right.
Alex: I'm not as concerned with complexity of implementations. I just
want this to stabilize faster. Want to know if that matters.
dbaron: What are these changes relative to?
Tab: Last official WD
Tab: Dropped idea of flex units, since couldn't figure out baseline
alignment with that.
discussion of stability, etc.
Markus suggests this is parallel to multicol, fantasai says it's not
nearly as advanced--hasn't gone through design review, which we
are doing now
more discussion of stability and implementation release schedules and
interop on old syntax etc
Alex is concerned about interop on old standard instead of on new standard
Tab: We can try to make changes to box-align more minor.
Tab: I tried to leave it unchanged and mix in vertical-align to align contents
Tab; But wasn't getting sane answers when I tried to map out how that works
...
dbaron: I like the idea of using vertical-align. Want to know what the
issues were.
Alex: If we resolve on everything except baseline, and can get those
edits into the spec, that would be a great outcome of this meeting.
RESOLVED: Change prefix from box- to flex-
Next issue: combining box-orient and box-direction into flex-direction
Alex: I'm not too thrilled with changing that. think old is more intuitive
dbaron thinks the opposite: prefers Tab's proposal
RESOLVED: Combine box-orient and box-direction into flex-direction
RESOLVED: Split box-flex into flex-grow and flex-shrink
dbaron: I think what the spec said and what implementations did is different
fantasai: So maybe look into what current implementations do to determine
default behavior of flex-shrink
Should auto margins flex as one?
fantasai: I'm strongly in favor
RESOLVED: 'auto' margins flex as 1
Tab: Drop box-flex-group? Not sure on this one
dbaron: I think splitting out flex-shrink would solve many of the use
cases here
dbaron: Note we don't implement flex-group
Alex: We haven't heard any significant use cases, and it's expensive
to implement
RESOLVED: Drop box-flex-group
Drop multiple-line support?
Alex: Mark at-risk?
dbaron: We should drop before CR if we're not sure that the spec is ready
dbaron: At-risk is something that is ready to be implemented, but we're
not sure that it will be implemented
<dbaron> I'm ok with either way.
Tab: The existing behavior is well-specified, just too simplistic to be
useful
RESOLVED: Mark multiline at-risk.
RESOLVED: Rename box-ordinal-group to either flex-order or flex-index
(mark as issue)
Tab: Multiple lines .. current syntax is to take values of single or
multiple
Tab: Suggest to change to box-wrap: wrap | nowrap
fantasai: Makes sense to me.
Alignment in transverse direction
Alex: Would it help to solve this problem if you could independently
specify background on the flexbox item from the actual child?
Tab: It's weird, but would solve my use case
fantasai cringes
dbaron: Would prefer to solve it some other way than a pseudo-element
RESOLVED: Mark entire transverse alignment as an issue until further notice.
GCPM
----
<howcome> http://dev.w3.org/csswg/css3-gcpm/#page-selection-nth
howcome: Two issues I have
howcome: One thing we cut out earlier this year was named page lists
howcome: But the requirement is still there
howcome: There's a use case for being able to style pages differently.
howcome: Named page lists approach was heavyweight; not suggesting to
re-add that
howcome: Suggesting :nth page selector
howcome: Here's an example *pulls up nearest book*
<arron> I would prefer this to be :nth-page not just :nth
howcome: You don't want headings on the spread of a chapter heading
fantasai: How about :first, :middle, :last?
howcome: Need to access 2nd page
fantasai: what for?
howcome: both pages on the spread of the chapter heading need to be
selected to e.g. drop headers
discussion of how to indicate the start and end of a named series
<dbaron> I think if you want @page chapter:nth(2), you need a new
value for the 'page' property that makes a new chapter
"restart" the sequence of chapter pages.
Tab: You could have a :spread() that takes a page name, and is true
if either side of the spread has a page with that name
fantasai: But all the pages in that book are "chapter" pages. You
have to somehow distinguish the start and end of a
particular chapter page series
howcome explains some use case involving widows and changing page sizes
glazou: complex selectors are very hard to present in a UI
glazou: I'm not saying the feature is not needed, just presenting a
warning
dbaron: You want the nth page of that name.
dbaron: But that's actually different from the nth page
dbaron: They should be separate selectors
<dbaron> Some of these examples are :nth-of-name(), some are :nth-page()
<dbaron> or maybe :nth-of-name() should be :nth-of-sequence()
<dbaron> ?: maybe we don't need nth... just first-in-sequence?
fantasai: Seems to me you just need to address the first page, first
spread, last page, and last spread of a named series
howcome: The case I need to address an arbitrary page is to address
widows and orphans
howcome: The publisher doesn't want to have a single line alone on a page
howcome: so he tweaks the size of the page before it to accommodate
an extra line
Bert: TeX alters the line-height for this case
howcome: It's a spread. You want to keep the baselines even
Peter: you have this exact same problem in columns
Tab: Maybe we need more powerful orphan-widow properties
Peter: I don't like that we're targetting the page by number
Peter: You don't want to target the page with a problem.
Peter: If I edit the document: change the content, or the styling, the
problem is no longer on the page I targetted.
glazou: It's a hack
Discussion returns to the 'page' property
glazou: What happens if the element that triggers a page group has a
page break property. Then it's impossible to know which page
is the second page he wants.
howcome: If it's inserted before, you don't count it.
howcome: The idea is that every chapter starts on the left of a spread.
howcome: And you want to remove the headings on the second page of the
chapter.
glazou: No, you want to remove it on the other page of the spread that
the chapter start is in.
tabatkins: If the chapters start on the right, then you want to alter
the last page of the previous chapter, instead.
* Bert thinks the sequence of named pages wasn't so bad...
fantasai: [explains dbaron's comment about why chapter:first doesn't
work for this use case, with analogy to p:first-child]
fantasai: [explains proposal for :first-page(pagename), and
:first-spread(pagename)]
<fantasai> :first(pagename) selects the page on which an element with
page: pagename; starts
<fantasai> :first-spread(pagename) selects that page and potentially
the next page if they are part of the same spread
<fantasai> similarly for :last-page(pagename) and :last-spread(pagename)
<fantasai> and you can combine with :left, :right, or :blank for
styling as needed
howcome: That doesn't solve the widows problem.
plinss: It doesn't fully solve the existing problem, either. If the
chapter starts on a right page, and the left page has content,
you don't necessarily want to style the left page.
howcome: Yeah, you don't want to select backwards. Just select the
second page, if the chapter starts on a left page.
tabatkins: Okay, if that's the case then I don't have a problem with
selecting the second page explicitly.
glazou: I think that this offers too much power - it will be abused.
<Kai> Wondering about workflows. As discussed now a piece of text to
be printed will have to be styled after all textual changes have
been made. Any changes to the text before that might change the
layout and leave the author to re-style the whole text.
Peter: Whether you have left and right pages or just right pages is a
print-time decision
fantasai: not in CSS. All pages are classified as left or right
howcome: Right, suppose you're printing to PDF
Peter: If I print this document in non-duplex mode, I don't want left
and right pages
Alex: could you have a media query for whether you have facing pages?
unminuted discussion
howcome: I want to suppress the headings on the pages in both page on
the spread to be suppressed
peter: You want controls for spreads, not for numbered pages
Bert: We can talk to XSLFO people. They've done this before
Bert: It might be more involved than just headers and footers.
<howcome> http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-last-line-avoid-property
* dbaron wonders if this is the one-more--hyphen---property
Alex: Do we need a control for this property?
Alex: Couldn't we just always avoid it?
* dbaron thinks Antarctica should be Ant-arc-ti-ca
<Bert> (Another way to reduce the ugliness in the example: This is
just a / simple ex- / ample to show / Antarctica.)
<tabatkins> Bert, that requires more adaptive hyphenation, which is
almost certainly too expensive for the web. Fine for
print, though.
fantasai: Do we need a control for this, or can we just have the UAs
be smart about it?
jdaggett: Do we need different values?
howcome: There are different policies among publishers. This is a
control that's been asked for.
howcome: We can drop the 'always' value; it's not as important.
glazou: What happens if the last word is wider than the column?
howcome: It's an avoid, not a requirement
<fantasai> I think auto should be asking the UA to be smart and do
something reasonable, not allowing anything....
Alex: spread should be on by default. Or maybe more than spread
Peter: Publishers do manual tweaking to avoid awkward breaks. Reset
breaking for one particular word on one particular page
Peter: We're not going to do that in CSS
Peter describes some of the difficult aspects of pagination
Peter: But if you tweak things at that level, you only satisfy layout
for that particular output instance
Peter: It doesn't apply if you change any of the output environment
parameters
Peter: By flipping this switch, it'll help some of the time and hurt
some of the time.
<Kai> isn't it exactly the ability to output on different output
environments that makes this feature necessary?
Peter: I read e-documents on this thing (iphone) all the time. And I
change the font size all the time.
Peter: The author isn't thinking of that
Peter: I don't want us to target the weird thing that happens on my
computer. I want to target the general problem.
Meeting closed.
<smfr> TabAtkins: i think a big unresolved transform issue is how they
apply to inlines
<TabAtkins> smfr: Yes, indeed. Should we talk about that during the FXTF
meeting on Thursday, or what?
<smfr> TabAtkins: i think the css-wg is more likely to have useful input
<TabAtkins> Ok. I'll push it on the agenda tomorrow.
<smfr> if it's later afternoon i could join
<TabAtkins> The question is between transform-each-box or
transform-bounding-box, right?
<TabAtkins> kk
<smfr> options are:
<smfr> 1. disallow transforms on inlines
<smfr> 2. transform the bounding box
<smfr> 3. transform line boxes somehow
<TabAtkins> kk
<smfr> 4. transform each bit like gecko does
<smfr> 5. maybe others
<TabAtkins> Oh, right, (4) is different because of, frex, bidi mixes within
a line?
<smfr> right
<smfr> i'm tempted to suggest `
<smfr> er, 1
<TabAtkins> Yeah, that might be the best.
<smfr> authors can use inline-box if they have to
<arron> I think 1 would be best too
<TabAtkins> We resolved on "just don't allow it on inline" for column spans
in multicol, so it seems like we're comfortable with that.
<smfr> sweet
<TabAtkins> smfr: Any thought on radial gradient canonical forms, while I
have you here?
<smfr> no, i haven't studied the radial gradients spec yet
<smfr> saw your emails tho
<TabAtkins> Did you read my email from yesterday?
<smfr> i saw it, then saw the second one so didn't read the first one
entirely ;)
<smfr> TabAtkins: i don't quite grok the start point + angle form
<TabAtkins> Okay, so here's how it works.
<smfr> you say the end point is the start rotated around the middle, but
that's not true if there's an angle
<TabAtkins> Right. What you do is, first, draw the reference line from
the start point to the rotated end point.
<TabAtkins> Then, rotate the reference line *around the center of the box*
by the angle.
<smfr> ok, so 2 things affect the final slant
<smfr> the points, and the angle
<TabAtkins> Then the gradient start is the "point on the reference line
where a line drawn perpeendicular intersects X corner", etc.
<TabAtkins> Yes, they work together, and have good behavior for their
defaults.
<smfr> hmm, that sounds more complicated
<smfr> and it doesn't address the use of the explicit start/end points
which places the gradient over some sub-rect
<TabAtkins> Only because the combination of both a ref-line and an angle
is strictly unnecessary. It's only specced that way so that
the two cases are specific instances of a general case, and
can be transitioneed together.
<TabAtkins> smfr: I don't know if that's actually a use-case. I've
never had to do that.
<TabAtkins> And I made myself a gradient-image generator in PHP, so I
used gradients pretty freely in designs.
<TabAtkins> 95% of use-cases, I think, can be addressed solely with
either an angle, or a box-cardinal direction.
<TabAtkins> I'd be fine with just speccing both of those as separate
functions, but if I can make a single function do them both
without a lot of hassle, then I'd prefer to.
<TabAtkins> I'd like to align whatever solution I do for linear gradients
with a similar solution for radials, though. Radials are a
much harder problem.
<TabAtkins> Anyway, let me post that email to the list.
<smfr> k
<TabAtkins> k, sent. now, off to dinner for a few hours.
<TabAtkins> bradk_: Check out the email too. I think the model I propose
for linear gradients has roughly equivalent power to yours,
but more continuous behavior and less abstraction.
<TabAtkins> bradk_: I still don't like the mode where you pretend that
the angle is relative to a unit box and then transform it.
But this one, where a bare angle is relative to a horizontal
line and thus gives us the algebra-inspired behavior, still
seems cool.
<bradk_> Tab, I see it the other way around, where the keyword just turns
off the bit that prevents the angle from stretching as the box
stretches.
Received on Tuesday, 16 November 2010 23:44:15 UTC