- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 13:40:41 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*
CSS3 Fonts
----------
RESOLVED: @font-face will be same-origin by default with the use of CORS
to relax for HTTP
Flexbox
-------
RESOLVED: flex-order as <integer>
RESOLVED: Publish css3-flexbox as WD
RESOLVED: abspos elements leave behind placeholders and all that implies
RESOLVED: Flexbox ordering property named 'flex-order', not 'flex-index'
RESOLVED: Not addressing stack axis in Flexbox
RESOLVED: logical keywords are flex-relative, not writing-mode-relative,
when used in flexbox
RESOLVED: Effective min-width on flexes is a limitation after the initial
flex resolution, not while figuring out preferred width of element.
RESOLVED: minimum width is just min-width; min-content is not an implied
minimum
RESOLVED: For 'flex-align: stretch', honor 'max-width', then start-align
Unresolved discussion of 'visibility: collapse'.
Multi-column Layout
-------------------
RESOLVED: break-before:column won't force a blank column when the element
is the first in the column.
RESOLVED: Pages work the same as columns - an element at the top of the
page with break-before won't force a blank page.
RESOLVED: page-break-before doesn't create a break if you're at the top
of the page, where at the top of the page means no content has
been placed. Borders do not count as content. Zero-height elements
count as content.
RESOLVED: percentage in block dimension is computed relative to multi-col
element, not column box height
Discussed whether margins should collapse between column-spanning elements.
GCPM
----
Reviewed new features for leaders.
Reviewed Opera's proposal for paged overflow controls. Some concern about
defining navigation controls for paged views.
RESOLVED: Publish CSS3 GCPM as soon as all edits are made
====== Full minutes below ======
http://www.w3.org/2011/10/31-css-irc#T19-14-36-1
http://krijnhoetmer.nl/irc-logs/css/20111031#l-1320
http://krijnhoetmer.nl/irc-logs/css/20111101
Scribe: fantasai
WebApps/CSSWG Joint Meeting Resolution
--------------------------------------
http://www.w3.org/2011/10/31-webapps-minutes.html#item02
jdaggett: We resolved to make the font loading @font-face same-origin
by default
jdaggett: Two actions on me
ACTION jdaggett: Reword how same-origin is described to talk only about HTTP
<trackbot> Created ACTION-391
sylvaing: Wouldn't this be an issue for implementations?
<sylvaing> my question was whether implementations used CORS or From-Origin;
it seems we made a decision on using CORS
fantasai: So if I linked a font on a different server via ftp, that works
around the same-origin restriction?
ACTION jdaggett: Talk with Anne about how to reference the same-origin
things "correctly"
<trackbot> Created ACTION-392
Vladimir: ...
jdaggett: This resolution will eliminate the need for an at-risk rule.
sylvaing: Will there ever be a connection between this and From-Origin
Florian: It's CORS
jdaggett: Once the action items are complete, there will be another point
at which we can rehash if need be
<hober> I didn't think we made a decision to use CORS specifically, only
to have a same-origin restriction by default in @font-face
jdaggett: So do we have a resolution?
RESOLVED: @font-face will be same-origin by default with the use of CORS
to relax for HTTP
<Bert> to relax restrictions in CORS, the syntax is "Access-Control-Allow-Origin: *"
in the HTTP response headers, I believe. Is there anything else needed?
Flexbox
-------
TabAtkins: I have a couple outstanding issues I need to edit, but we
don't need to worry about -- just resolve corner cases with
obvious answers
TabAtkins: Other issue: ATM in the spec flex-order takes a <number>,
whereas z-index takes an <integer>
TabAtkins: So we can either make flex-order <integer> or z-index <number>
to make consistent
TabAtkins: Prefer <number> because it makes it easier to insert things in
between later
ChrisL: what's the impact on z-index of changing it?
TabAtkins: z-index currently takes <integer>, so this would be expanding it.
smfr: I'm a little uncomfortable with changing z-index
smfr: I see a lot of devs setting z-index to maxint -1
TabAtkins: Would the crazy things ppl do be affected by this change?
TabAtkins: I don't think so
Arron: We don't know.
Molly: I'm afraid.
Molly: Many designers don't understand CSS, they use properties that we
define and understand, but they create hacks to work around
implementations or to address a feature they don't know how else to do
Molly: What is going to happen if something changes there?
smfr: Whether it breaks depends on the implementation. Opera had a 16-bit
implementation at one point
TabAtkins: floats are above our minimums
smfr: You can't represent maxint accurately as a float
TabAtkins: We were talking about required minimum ranges for <integer>
TabAtkins: will almost certainly be below maxint
Florian: Possible ppl are writing floats into their z-index, and their
pages currently work only because it gets thrown out
TabAtkins: If we believe that's actually a problem, that there is
significant usage in the wild of invalid z-index values, then
we have a problem
Markus: what do we lose by not having <number>?
TabAtkins: It's mildly more convenient to use <number>.
Steve: Is the benefit of analyzing this worth the benefit?
fantasai: you can use the BASIC approach and space your numbers by 100
TabAtkins: Make flex-order be <integer> and later evaluate whether to
change flex-order and z-index to <number>
* sylvaing wonders how existing code that parses z-index value will handle
a switch to <number>
RESOLVED: flex-order as <integer>
fantasai: On another note, why do we have flex-order and z-index?
TabAtkins: I don't care very much, slightly prefer flex-order
<Bert> ('nav-index' is also called "index," not "order.")
Bert mentions tabindex in CSS
'nav-index'
discussion
<tantek> hearing 'nav-index', /me puts down the TPAC planning wiki page and
hurries back to CSS WG
<sylvaing> z-bikeshedding
Steve: I think 'index' is slightly better because you have to think about
what it means, and if you read it you have to look it up
Steve: I think order implies something it isn't
Molly: Many people already understand z-index anyway, and in their
vocabulary, so it's consistent anyway
holding off until alex is around
* sylvaing thinks we're arguing for consistency with something everyone is confused about
TabAtkins: Last thing is to request WD publication. Last draft is from 2009
dbaron: One reason I hesitate to rename flex-order to flex-index is because
boxflexgroupthing might be flex-index
TabAtkins: Oh, you mean like flex-group
dbaron: I guess flex-group is fine
RESOLVED: Publish css3-flexbox as WD pending flex-index/flex-order issue
resolution
alex: flex-order changes processing order, not just visual order so I
think it should be flex-order
alex: did you go over min-width?
alex: 8, 10, 12
alex: abspos children
<TabAtkins> http://wiki.csswg.org/spec/css3-flexbox#issue-10
alex: We had an issue about issue of abspos elements creating an empty,
which is discoverable when justifying
alex: There is no reasonable way to place that hypothetical static position
alex: Place where it would have been is inline content, and that gets
wrapped in an anonymous ocntainer, and that box is empty.
alex: But justifying with flex-pack shows this placeholder
alex: Positioning a flex-item without a placeholder is tricky
fantasai: Why not define the static position as coinciding with the flexbox,
rather than as a hypothetical child??
alex: The only thing we don't like is the behavior with flex-pack: justify,
and I don't mind it being bad for this case since it makes everything
else work better
TabAtkins: So we're embracing the placeholder concept.
Ojan: I don't like that
Ojan: Weren't you proposing to point its static position as being in the
middle of the flex-pack space
dbaron: that's a lot of code to special-case an edge case
RESOLVED: abspos elements leave behind placeholders and all that implies
http://wiki.csswg.org/spec/css3-flexbox#issue-8
Straw poll: flex-index vs flex-order
jj: order
alex: order
howcome: absain
koji: absain
markus: order
tantek: abstain
steve: index
alan: order
florian: abstain
bert: no opinion
?: index
brad: abstain
smfr: order
dean: abstain
soonbo_han: index
shane: order
hober: order
luke: abstain
<Bert> so we decided to call it flex-abstain?
kim, molly, rossen: order
dbaron: order
jdaggett: abstain
sylvaing: order
arronei: order
tab: order
fantasai: index
glazou: I don't care
ChrisL: order
RESOLVED: flex-order
http://wiki.csswg.org/spec/css3-flexbox#issue-12
TabAtkins: This is to consider z-order axis
TabAtkins: as a flex order
TabAtkins: I believe we shouldn't do anything about this right now
TabAtkins: If we want to address stacked layout, which I think we should,
we should consider it as another display or part of grid or
something else. Don't have all the primitives we really want
TabAtkins: One thing you might want to do, frex, if you have items of
different size, you might want to size to the size of the
current item, or size to the size of the largest item so you
don't resize as you swap them
TabAtkins: That's a control that you don't have otherwise
dbaron: What's the use case for size based on the one on top?
dbaron: Gecko implements this, and we've never gotten a request for size
based on the one on top
Rossen: size top sounds like a way of deferring layout of the other things,
is that your use case?
TabAtkins: Partially
TabAtkins: Have a use case for sizing according to top
TabAtkins: I've seen tab layouts where your headings or whatever are on the
side, and the contents of your page are the stack
TabAtkins: You want them all to fill the widths. But if you have a tall
item and some short items, you don't want the short items to
have a long scroll bar
dbaron: Fair enough, but that doesn't seem like flexbox.
Markus: If we add this we'll have another way to do stacking in addition
to z-index and grid
TabAtkins: There's still further things that distinguish this from plain
flexbox that make it not a good idea to combine
TabAtkins: Flexbox's alignment primitives are flex-align and flex-pack,
which are perpendicular/parallel to the flex axis
TabAtkins: If you have stack, then you have two orthogonal axes, and it's
not clear which is align and which is pack
TabAtkins: If we were going to tack it onto one of our layout models,
grid might be better. not sure if it's the best idea, but
seems better than this
Alex ...
Alex: If you take a grid and give it several items, it will give you a stack.
<Bert> (Template Layout once had 'display: card | card-container | card-tab'.
Came from a request from Device Independent WG.)
TabAtkins: One final thing that makes me hesitant, I'm not sure if we
want to address in CSS, but if you have tab layout then you
probably want to show the tabs themselves.
TabAtkins: Auto-generated, linked up manually, some old proposals, but
don't know how
TabAtkins: in JavaScript it's easy, but may want to address it in CSS
Alex: HTML5 control using script and grid and add to HTML5 as necessary
TabAtkins: One problem with script is, the tabs should be accessible.
TabAtkins: Most developers will not and do not in practice hit all of
the accessibility goals we want there.
Alex: it needs to be an HTML5 control
fantasai: Couldn't you use fragment IDs?
TabAtkins: If we address this automatically somehow via CSS, I doubt
we want to tie this into z-index.
<Bert> (http://www.w3.org/Style/Examples/007/target is example using
fragment IDs (and :target, thanks to Daniel))
TabAtkins: problem with using z-index is that you want to just deal
with the flex items, not everything else on the page
RESOLVED: Not addressing stack axis in Flexbox
http://wiki.csswg.org/spec/css3-flexbox#issue-14
alex: Do 'before'/ 'after' apply to direction based on writing mode or
based on flex order?
TabAtkins: Currently flex-align: start aligns to the beginning of the
flex order
alex: flex-align: after goes after the first line (towards the second)
RESOLVED: logical keywords are flex-relative, not writing-mode-relative,
when used in flexbox
http://wiki.csswg.org/spec/css3-flexbox#issue-17
TabAtkins: Let's say it says width: flex(1)
TabAtkins: And you give it a min-width of 50px.
TabAtkins: Should this start the flex calculations from 50px?
TabAtkins: Or should it start from zero and then check/correct if necessary?
TabAtkins: This is important if I want to give each item flex of 1, but
set a minimum for readability
TabAtkins: If you make it so that everything starts from the minimum width,
this breaks
TabAtkins: Everyone will start at their min-width, then they'll flex, and
then they'll be different size
TabAtkins: However, that method is easier
TabAtkins: However I think it is a bad enough behavior that it should be
changed
TabAtkins: I'm specifying exactly when min/max are taken into account
TabAtkins: Think we should make sure min/max are handled after flexing.
fantasai: I think I agree
dbaron: ...
TabAtkins: The passes are limited and cheap. It's multi-pass layout, but
not full layout. Will converge super-fast.
Alex: Don't think it's possible to avoid multiple returns, but very hard
to come up with situation that requires more than one return.
dbaron: Assuming we know how to resolve intrinsic sizes in block dimension
dbaron: but that's another problem entirely
<dbaron> but one I think we should try to solve in this spec
Alex: Let's say you have flex of 1000px, and your max-content is 2000px
and min-content is 500px
Alex: min-width is specified to 100 or 0, doesn't matter
Alex: which of min-width will go to the min, is it going to be min-content
or min-width?
alex: I think what's supposed to happen, if width is 'auto' then we should
look at min-content width
alex: If width is specified, then we should not look at min-content width.
fantasai: I think it makes sense? I think it's consistent with what Tab
proposed.
TabAtkins: We're working on an implementation, and you're working on an
implementation, so we should be able to figure out what's sane
alex: Question is in what cases do we consult min-content, if ever
alex: Default value of min-width is 0
alex: so it's always specified
fantasai: do we need an 'auto' value for min-width?
alex: ...
alex: Could say minimum is max(min-width, min-content)
alex: Problem with that is you can never have a box that is smaller than
min-content
TabAtkins: Could we say by default things can shrink to zero, and if you
want min-content as a minimum, you say min-width: min-content
Ojan: Seems non-flexbox specific
alex: Different because flexibility depends on the width
Ojan: To be consistent with
OjaN: if you put min-width: 100px and width: 300px then you'll get 300px
dbaron: Those don't conflict. If you swap them you get 300px
Rossen: The problem is that if you want to achieve parity with behavior
of table cells floaters abspos or anything else that does
shrink-to-fit,
Rossen: min-content is always respected in these types of layout
Rossen: flex in this case doesn't respect the minimum content
Rossen: If you have some characters, and default value of min-content
is 0, flex will currently shrink all the way down to zero
Rossen: might or might not be what you want
fantasai: How about changing the initial value of 'min-width' to 'auto'?
Rossen: When would you not want min-content?
alex: I have a huge long unbreakable line, don't want to follow that
steve: Wouldn't you want the same thing in a table?
TabAtkins: It's easy to do what we want for flexbox. Still means tables
are confusing, but everybody else works the same way.
TabAtkins: If you want min-width of 0, set it to zero. If you want
min-width of min-content, say so.
RESOLVED: Effective min-width on flexes is a limitation after the initial
flex resolution, not while figuring out preferred width of element.
dbaron: The way things need to work for blocks and tables is that min-width
doesn't affect the pref width of the element, but affects the pref
width of the parent
RESOLVED: minimum width is just min-width; min-content is not an implied
minimum
TabAtkins: There was a question when flex-align: stretch combines with
'max-width' smaller than the size of the flexbox so that it
can't stretch fully
TabAtkins: Proposal is to respect the sizing constraint and then start-align
RESOLVED: proposal accepted
Ojan: Do we want to address visibility: collapse
fantasai: the problem with using display:none to dynamically show/hide
elements...
fantasai: ...is that you really only want to take thing out-of-flow in
one dimension (the main axis).
<Bert> (Example of 'visibility: collapse' in tables:
http://www.w3.org/Style/Examples/007/folding)
fantasai: You can't do that with display:none, but visibility:collapse
is *supposed* to solve this in tables. It does a bad job,
but we can't do it right.
(example was of a panel with collapsing panels)
dbaron: I think it doesn't work well in tables because it hasn't been
solved right yet.
dbaron: Because if you have more space for the other things, they can
be smaller in the other dimension, so they'll still change size.
fantasai: Tables also have the problem that row/col spans get clipped
oddly by collapse.
ojan: My concern with this is that this is sort of a more generic thing.
Why doesn't this work on lists (hiding, but still incrementing
counters).
fantasai: I'd like it to work there.
ojan: Right, but there's backwards compat issues. So let's ignore
collapse, and solve it properly with a new property or value.
dbaron: What's the problem with lists that's not solved by display: none?
TabAtkins: Preserving counters.
fantasai: Also contribution of the width to the parent's intrinsic size
TabAtkins: Also, running animations.
Steve: what happens if I set height to zero
fantasai: you also have to turn off padding, border, margins, box-shadow,
etc. etc.
Ojan: So it's dead in the water to make visibility: collapse; work on
block elements, I presume?
dbaron: I don't know, maybe not
Molly: visibility: collapse isn't taught
...
fantasai: Goal is to make it not show up, just like display: none;
except without some of its problems
Bert asserts that you'd want to leave extra space so that the content
after the list stays the same place
fantasai doesn't understand what we're arguing over anymore
dbaron: sounds like this is unresolved
Multi-Col
---------
Scribe: TabAtkins
howcome: multicol is in CR. impls are coming along.
howcome: But there's one area I've discovered where we don't have interop
howcome: the break-before/after/inside properties
<howcome> http://www.w3.org/TR/css3-multicol/#break-before-break-after-break-inside
howcome: Basic question I need an answer for.
howcome: Applies to both column and page breaks.
howcome: Say you have an element, the first in a page or column.
And you set break-before on it.
howcome: Should you apply it (forcing a new break), or just leave it,
since it's already the first element.
howcome: I think we should do the latter.
howcome: For both pages and columns.
fantasai: For pages, you sometimes want blank pages, but you don't want
*arbitrary* extra blank pages. Usually you want to start all
chapters on the left page, or something.
glazou: Sometimes you do specifically always want, say, 1 blank page
before chapters.
fantasai: You can do that by using ::before or similar and give it a
sufficient height (but no content) to push the rest of the
content down.
howcome: 2 out of 3, roughly, do it the way I want.
<ChrisL> <div class="notes" style="page-break-before:always;background-image:tpilb.png"/>
howcome: The others force a new break.
glazou: So the proposal is to *not* create a blank column when the first
element in a multicol has break-before:always.
RESOLVED: break-before:column won't force a blank column when the element
is the first in the column.
fantasai: For pages, there are use-cases where you want to feed the blank
pages, there are larger use-cases where you *absolutely don't*
want that.
fantasai: So we should use that as the default, and possibly address the
"force blank pages" later.
RESOLVED: Pages work the same as columns - an element at the top of the
page with break-before won't force a blank page.
howcome: Now, <div><div></div></div><style>div { break-after: all; }</style>
howcome: Two breaks? Or do they collapse?
fantasai: I think they do collapse. The spec seems to imply that as well.
TabAtkins: And it's consistent with the decision we just made.
alexmog: I don't think any browser currently has that behavior.
fantasai: I intend to fix that in Mozilla.
alexmog: I think all browsers collapse -after breaks, but not -before breaks.
alexmog: Things like the <html> element shouldn't count as "content"
before the element, forcing a break. Same with display:none
elements.
fantasai: For <div>...</div><div/></div>...</div>, we shouldn't collapse -
breaks shouldn't collapse through the empty element.
szilles: I'm surprised at this. I would think it would be simpler to
always honor the breaks, not collapse.
alexmog: Say you have an <h1>, the first thing in the document, and you
set break-before on it.
alexmog: But it's *not* actually the first element. <html> and <body>
precede it.
szilles: Isn't that consistent with our previous case? If the <h1> is
at the top of the page...
TabAtkins: This is a different case
TabAtkins: In this multicol case, the <div> is literally the first thing
on the page
TabAtkins: In the other case, the <h1> is not the first thing on the page,
it's wrapped by a <body> and an <html>
szilles: Define that as being at the top of the page
Alex: Orphan control shouldn't .. if you have a region with only room for
one line, and we have an element with orphan that has 3 lines
alex: we're currently going to move that to the next region because we're
not at the top of the page
* unsure that was minuted correctly
alex: You have a long enough paragraph, multiple lines
alex: starts in a region which can fit just one line
alex: which is ok for titles
alex: You want that one line to still be in that region, even though with
orphan control will want to keep it with the rest of the parent
alex: The reason these cases are related, is if break-before and
break-after are interpreted as I think in the spec
alex: they're not "make sure there's a break here", it's "make sure this
is the first thing on the page"
alex: For both widow/orphan and breaks, you're still looking at whether
you're the first thing on the page
alex: opening tags don't count as making you not at the top of the page
szilles: That would just fall out of the definition, which is make sure
this is the first thing on the page
howcome: ...
howcome: <chapter><section></section.</chapter>
howcome: You want each chapter to start on a new page, and each section
to start on a new page. You want to set break-before sections
and chapters
fantasai: 2.1 says that when determining breaks, you look at the break
properties of all the elements that meet at the given margin.
fantasai: It's pretty vague, unfortunately.
alexmog: page breaks don't prevent margin collapsing, though...
<alexmog> http://www.w3.org/TR/CSS21/page.html#forced
TabAtkins: Specifically, the definition of "top of a page" is underdefined.
Does a margin or border on a parent make you no longer at the
top of a page? (The correct answer is no.)
dbaron: It needs to be defined in a whole bunch of cases. Frex Mozilla
has mTopOfPage, which deals solely with the possibility of
nothing fitting -- it lets us know if we have made any progress
in putting things on the page, so that we don't keep breaking
and placing no content
dbaron: For that placing a border does count
alexmog: Having <body> as your parent, even with ??? is honored.
alexmog: If you look at break-after, which is supposed to be consistent
with break-before, all browsers collapse break-after.
szilles: Isn't that the same rule/difficulty in determining if something
is at the end of the page?
alexmog: Yes.
alexmog: [some section] has a very simply rule that just says a forced
break occurs when any elements contributing to the current margin
have a forced break.
alexmog: So you go and do normal margin collapsing, then look at the result.
...
alexmog reads from CSS2.1 spec
fantasai: It wouldn't have been written to imply more than two elements if
collapsing wasn't meant to happen.
howcome: So we can just clarify 2.1 if it' snot fully clear.
szilles: Doesn't the margin definition break if you put a border on <chapter>?
TabAtkins: Yes, and that's bad.
dbaron: What happens if one says 'left' and the other says 'right'?
howcome: I say you choose whichever one grants you the most pagebreaks.
fantasai: When collapsing breaks there's nothing "between" your breaks.
I think you should choose the last one, because it's the one
closest to the next content.
howcome: I'd like to have a resolution because we're in CR, and we need
testcases written.
howcome: I can live with the last one winning if there are conflicts.
fantasai: The spec is pretty clear that a series of page breaks should
never generate more than one page break in series.
howcome: Okay, so collapsing works. Do borders stop break collapsing?
alexmog: They block margin collapsing, so.
howcome: Can't we just lean on margin collapsing's rule?
fantasai: I don't think there's *ever* a use-case for having a border
on an otherwise blank page with this.
alexmog: the 2.1 definition is based on margin-collapsing.
Florian: We should prioritize authors over implementations, and authors
don't want a blank page with just a border.
alexmog: And if we can avoid changing the very complicated margin-collapsing,
that's good.
Scribe: fantasai
szilles advocates for just coming up with a good definition for top-of-page
szilles: Definition is if you haven't put any content on the page, then
you're at the top. And borders aren't content.
TabAtkins: This is still wayyy simpler than margin collapsing. There's no
negatives, no zero-height elements that collapse through, none
of that.
howcome: I think there's some kind of consensus here.
proposal: page-break-before doesn't create a break if you're at the top
of the page, where at the top of the page means no content has
been placed. Borders do not count as content. Zero-height elements
count as content.
dbaron: So placing an empty block counts, but placing start of a block does
not count.
dbaron: Alternative def is placed either a non-phantom line box or a
non-replaced block with non-zero height, or anything other than
something that goes in a line box, or something that doesn't go in
a line box and isn't a non-replaced block
TabAtkins: Can we just say line boxes is all we care about?
dbaron: tables? replaced blocks?
TabAtkins: Why are we allowing ... collapsed through?
dbaron: Because alex wanted it
Alex: I really like CSS2.1 definition because it covers lots of cases in
just 2 lines
howcome: So we have one proposal which is 2.1, based on margin collapsing
<dbaron> I'm fine with the 2.1 definition
howcome: And then another, perhaps simpler, definition
howcome writes out the definitions
dbaron: One thing that seems weird is that you have start of a block,
that's ok, and end of a block, that's ok, but start *and* end of
block, that's not ok
...
TabAtkins: The break-afters generate a break
TabAtkins: The break-befores don't generate a break: they're already on
a new page
fantasai: The thing that's weird is collapsing anything through the
content area of an element. We do that for margin collapsing,
and its weird. We should not do that here.
alex: I have a problem with not counting the border as content
alex: My margin will be after that border, and while I'm asking to be
the first thing on the page, I'm not really
TabAtkins: I think the potential downside of where that might be confusing
is less bad than having an entirely blank page with nothing but
a border on it.
fantasai: Note you're actually not required to print pages that have only
backgrounds and borders on them
howcome: It seems you feel quite strongly about this, Alex.
howcome: Let's take a quick straw poll.
A: alex
B: steve/fantasai/tab
jj: A
alex: A
koji: abstain
Markus: abstain
Tantek: abstain
Steve: B
Alan: abstain
abstain
Florian: B
Bert: abstain
....
lots of abstain
howcome: we can collapse all the abstain :)
Rossen: A
dbaron: A
sylvaing: abstain
arronei: A
Tab: B
fantasai: B
smfr: B
molly: B
<hober> b
fantasai: explains the two options
molly: The empty <div> is there. If we're dynamically generating things,
it should have an effect
now howcome is explaining why we're collapsing at all
Alex: If you look at continuous media, where instead of page-break you
have a large margin
alex: e.g. 3em margin
alex: whatever comes after margin is held together by the results of
margin-collapse
fantasai: If you're collapsing through this empty element, where is this
break happening?
fantasai: If you have a bunch of break-afters, and you collapse them,
and you break the page, the margins that were there get truncated.
fantasai: But after a forced page break, you keep margins at the top.
fantasai: If you have an empty div, and you have set break-before and after
on it, and the preceding and following div also have breaks,
which page is the middle <div> contributing to?
dbaron: And more importantly, which page is the empty div on?
alexmog: Where does it say that margins are truncated after the break?
howcome: We resolved on that.
dbaron: [explains the 2.1 spec for it]
dbaron: And this assumes that breaks exist *between* block-level margins,
rather than being stuck somewhere *inside* of collapsed margins.
<dbaron> quoting 13.3.3 point 1 and the note following
new straw poll!
jj: A
alex: A
steve:B
Florian: B
Bert: A
Brad: B
hober: B
smfr: B
Kim: B
Molly: B
Rossen: B
dbaron: B
arronei: A
TabAtkins: B
fantasai: B
glazou: B
ChrisL: B
Totals: 4 A, 13 B
RESOLVED: page-break-before doesn't create a break if you're at the top
of the page, where at the top of the page means no content has
been placed. Borders do not count as content. Zero-height elements
count as content.
ACTION fantasai: put proposal B for page-break collapsing into specs
<trackbot> Created ACTION-393
dbaron: We should errata 2.1
alex: can we get it written up first?
sylvaing: Column boxes define a containing block, right?
sylvaing: What if my columns are balanced and I have a percentage height?
dbaron: If it's auto height, it's auto-height
dbaron: The column boxes all occupy the full height of the multicol box
dbaron: They should have the same implicit height
sylvaing: Don't they adjust when you balance
<Bert> ACTION bert: create issue against CSS 2.1 corresponding to ACTION-393.
<trackbot> Created ACTION-394
RESOLVED: percentage in block dimension is computed relative to multi-col
element
GCPM
----
howcome: This is what I showed last night.
howcome: A few other changes we need to go through.
howcome: WD is a year old.
howcome: One thing that left GCPM since then is hyphenation
howcome: We should do an updated WD
howcome: A couple other things
glazou: Markus has shown me horizontal navigation in a document that is a
little bit in conflict with your proposal
howcome: I don't think it's in conflict, they're going in the same way
Markus and howcome seem to be ok with the situation
howcome: I'm not tied to the syntax, but I think it should be declarative
as you say
markus: Declarative is good, but you also need JS access
howcome: First issue is with leaders
howcome: Bert brought up this point
howcome: The issue being that he wanted to have control over alignment
of leaders
howcome: If I understood correctly, Bert, you wanted to create a leader that's an arrow
howcome draws: ABC ------------> 1
<Bert> -> http://www.w3.org/Style/Examples/007/leaders examples of leaders
(hacked, of course, but showing the way I want them)
howcome: In order for this arrow, which is in the generated content,
howcome: to make this visually make sense, Bert wants the point of the
arrow to connect with the line
howcome: So that you don't get that effect *draws an arrow where the head
is broken from the body*
ChrisL: That assumes the horizontal lines match up with the arrows
Bert: In the Symbol fonts they do
howcome: the idea is to add a second argument to the leader function,
howcome: I think these are the values you need: 'start', 'end', 'center',
'space', 'pattern'
howcome: pattern is to make the dots align across lines
glazou: 'space' will mean whitespace in web author's mind, please use
something else like 'stretch' (just an example)
fantasai: Stretching implies stretching the glyph. 'background-repeat'
already uses 'space' for stretching the gaps
howcome: You want these leaders to align. I think this is the most
common use case.
szilles: Don't understand where the space is added.
dbaron: You put as many characters as will fit. In normal case you
right-align them
dbaron: In space case, you insert spaces between the leaders
szilles: Need to be clear about whether its between all the characters
or between each string
Bert: Not the way it works in TeX, but it's another option
Bert: The leader unit is a fixed size, doesn't change size
Bert: Can put space before/after, both, etc. but not inside it
Tantek: Aren't leaders like border-images?
Tantek: why not use images
szilles: Because the common case is to use glyphs
<ChrisL> typographers also see decorations as glyphs
fantasai: might want both characters and images
fantasai talks about matching the dots to the dots in the font, in size,
postion, and shape; this is why they are glyphs, not images
szilles: We've talked about a need for characters, there might also be
a need for images
molly: I think space, which goes characters out to available space, and
justification which fits inside the containing block
????
molly: What I interpret that as meaning space out the chraacters to take
up the width
howcome: That's right
howcome: The quesiton is between all characters or only where the
repetition is
szilles: Why not have two values
fantasai: space and justify
fantasai: space like border-image and background-repeat
?: letter-space and pattern-space
molly: justify makes sense
molly: This addresses both issues
howcome: Does anyone need center?
Bert: Sometimes you want as much space before the leader as well as after
dbaron: Centered absolutely or centered individually?
Florian: We're resolving to split the space into two, and not remove any
other value
some confusion around everything
* tantek provides a dot-leader example from >10 years ago: http://tantek.com/CSS/Examples/dotleaders.html
<tantek> (try resizing)
<tantek> #tablesabuse
howcome puts in string-space and letter-space
bikeshedding 'pattern' leads to 'align'
fantasai: I'd also drop the comma and use ||
fantasai: just like in properties
Bert: One more about leaders, but maybe not so easy to solve.
Bert: How to make double-ended arrows
fantasai: Just put three strings: "start" "middle" "end"
TabAtkins: image-resolution is in css3-images, so should remove from here
howcome: ok, done
szilles: One other catch with alignment
szilles: In Indic languages, the leader aligns with the hanging basline
szilles: In Japanese it would be centered
fantasai: That should be handled in the fonts
szilles: The leader needs to be aligned to the relevant baseline.
szilles: That may fall out
szilles: Just want it noted
howcome: Nothing changed in ... various sections ....
howcome: Paged Presentations
howcome: This is basically what I demoed yesterday, where we use the
overflow property to set the axis onto which we put out these pages
howcome: They could be analyzed and split into two, and we could have
multiple properties for them
howcome: We did that at some point in our implementation, but it creates
many possibilities
howcome: that we aren't really going to use
howcome: So instead we have four values that cover the needs we have found
howcome: there might be others
howcome: not tied to syntax, but we like the functionality
howcome: the -controls bit adds the UI
howcome: native UI for paging
szilles: I'm concerned that it's not as standardized as scrollbars are
howcome: It's like HTML5 controls for video
glazou: that's in the markup
alex: ... overflow paginator, could be x and y
howcome: Could split these into 2 properties. Paged thing could be on
2 oveflow, and the others on a different property
howcome clarifies that x in paged-x is about how the pages connect,
not which direction of overflow is affected
glazou: I'm very concerned about the controls bit
Florian: Does the first bit forbid the UA to have controls?
howcome: Alex asked, does touch work both places?
howcome: This just adds visual controls
dbaron: In the simplest case it could even be a scrollbar, though probably
not the best idea, but it could be
<ChrisL> so the distinction is that the controls take up space
howcome: We have overflow: scroll, so we are referring to controls already
fantasai: In scroll vs auto, we're distinguishing whether the controls are
visible when there's no need to scroll, not whether the UA should
put controls at all when there is overflow to scroll to
dbaron: More similar to hidden
molly: Point out that if the controls are UA-dependent, could be a problem --
authors will want to style it
Bert: When we introduced marquee, we added overflow-style and had it as a
value of overflow-style
Bert: This seems more like additional values for overflow-style
Tantek: overflow-style: marquee-paged
Markus: In the first case (paged-x) you still want some indication of
where you are
Markus: The default shouldn't be nothing.
<tantek> where's Tapas when you need him
dbaron: There are 2 options, in some sense there's no default. You can
choose with or without controls
howcome: This is where we've built a UI through the DOM. These controls
have been made by the page (shows demo) whereas these are made
by the UA
szilles: I'm still confused about what "this" is that you say should be
in CSS
Adobe: In Acrobat the controls appear on hover
howcome: you can choose whether UA gives controls or whether author
provides controls
fantasai: What if the author assumes you have a swipe interface for
paging, and doesn't provide controls, but I don't have that
interface? Then I'm stuck.
glazou: When you use the overflow property, you just say that the overflow
should be visible in some way. You don't make any provision about
the means.
<dbaron> I disagree with Daniel.
<dbaron> I don't think saying there are "controls" is too constraining.
Markus: Here I'm showing you a similar solution using regions and exlucions
Markus: You have a template mechanism that handles overflow.
Markus: At the bottom there is a little indicator of where you are and
how many pages you have
Markus: If I use the mouse, I get a scrollbar
glazou: Here you are stopping the scrolling between two pages
(markus is demoing)
markus puts some experimental -ms- snap properties
markus: Now it snaps between pages
markus: But you still get a progress indicator, so you know where you are
markus: Beauty of this approach, based on regions, it's a simple JS
templating model.
markus: You can inject animations, etc. etc.
markus: Not saying howcome's idea is a bad idea, but this brings more
powerful
* tantek notes that Opera claims to support overflow-x and overflow-y:
http://dev.opera.com/articles/view/opera-9-5-the-next-generation-of-web-s/
Tantek: Can we go back to howcome's demo
Tantek: You mentioned that simple values etc.
Tantek: I'm wondering how does that interact with overflow-x and overflow-y
Tantek: I know Opera supports those.
Tantek: If you've figured that out, I'd love to understand that interaction
howcome: These properties only belong on overflow shorthand
Tantek: That's why I think they should go on overflow-style
howcome ...
fantasai: I agree it should go in overflow-style
dbaron: This changes the layout model
dbaron: It's not just changing how we get to the overflow
fantasai: I have a question for Markus: what happens when you print?
Markus projects:
body {
overflow-x: auto;
overflow-y: hidden;
-ms-scroll-snap-type: mandatory;
-ms-scroll-snap-points-x: snapInterval(...)
}
Markus: In general the basics of how this app runs, it's just a simple
page that brings in other html pages as templates
markus: We also have a default overflow template
markus: Just a little bit of JS to make this stuff work
glazou: little bit?
markus shows template pages
markus: Place my items, grid
Markus: What I showed you at the end is playing with this snap thing
Markus: You can snap after one page, multiple pages, define ranges etc.
Markus: We presented at the build conference, sdk out there, want to
bring th WG as a propsoal
glazou: So this only works with JS?
fantasai: I don't mind having JS interact with CSS, but I don't want us
to build layout models here that require JavaScript in order
to work.
<tantek> LOL - Håkon's pagination proposal is already in the media:
www.macworld.com/article/163317/2011/10/opera_cto_kill_the_browser_scroll_bar.html
<tantek> (and http://dvice.com/archives/2011/10/creator-of-css.php )
Markus: With scripting you can do interesting animations
Markus: When we started thinking about pagination, we started with
something ismilar to howcome's model, but thought it would
be better to have .... to create a better magazine-type experience.
hober: ...
howcome: I encourage you to add pagination to regions
alex: Pagination should not be part of regions
howcome: Regions should know how to work with pages
szilles: I agree with fantasai's statement that layout models shouldn't
require JavaScript, but also good to define events and things
to add more
glazou: Agreed, but the basic thing howcome demoed shouldn't require JavaScript
* tantek agrees with szilles
sylvaing: Right, it should be optional
<tantek> pagination events would be useful
howcome shows his api
szilles: I might want to ask questions about pages, like what links are
on this page
howcome: I think that's reasonable
howcome: I object to you calling this a low-end feature, markus.
howcome: I can recreate the Economist's layout almost pixel perfect with this
BradK: Howcome's solution, the UA can provide the UI for how the pages
get turned
bradk: So you can even hav an ibook like experience, where it's curling
and everything. Could be a high-end kind of experience
florian: high-end from control of the user, not the author (?)
bradk: I consider UA controls an advantage. Don't have to relearn how to
turn pages on every website
Alan: I think whatever we build for pagination should work with multicol,
work with regions, should work without either
Alan: Could see this for slides
Markus: As soon as you want more flexibility on what things look like,
you need regions
bradk: Scrollbars are the same every page you're at, unless the author
does something special
bradk: I think that's good, so you don't have to figure out how to turn pages.
Szilles: If we're going to do what Brad just said, we should agree on
what the components are
szilles: My Kindle can do more than go back and forth between pages
szilles: A bunch of things ppl expect when paging things
szilles: Come up with some expectation of what the controls should be
szilles: controls is too open ended
[szilles says stuff about bookmarks etc]
molly: I agree.
molly: Need consistency, and say explicit about how it needs to be done
hober: HTML5 doesn't say much about what the video controls should be
howcome: Depending on what the device is, might have different controls
Florian: Say what capabilities it has
molly: I want to step back a moment, I understood that if you use these
features and allow the UA specific controls, that you will be
able to style those controls
Florian: If you want to style it, you build it yourself.
molly: ok
hober: UA could provide some hook into its controls, but that's up to the UA
molly: As long as ppl can create their own controls
Bert: As long as I as the user can override what the author does
Bert: I want consistency across pages. I choose my browser.
fantasai: If the author says, don't put controls, and builds his own out
of JS, and the user is lke "I can't deal with these weird
controls, I want my own controls", how do you deal with that?
Florian: Turning on the UA controls is easy. Killing the author controls
is not so much.
szilles: Also need to make sure there are screenreader APIs for this.
discussion of accessibility apis and what they're capable of
<mmielke> Links to the Regions based demo (runs on win8 developer preview):
http://code.msdn.microsoft.com/windowsapps/Dynamic-Region-Templates-94bc9c95
molly: When you're looking at this content anyway, the content is
linearized in your core document
szilles: With regions you can mix streams
alex: I think this should be a display property
alex: If it's overflow property, it applies to everything. But paging a
flexbox doesn't make sense.
alex: All other kinds of layout that support overflow don't need to support
paged overflow
plinss: Don't see why you can't paginate flexbox
howcome: I'd really like to publish another WD of GCPM.
howcome: We haven't gone through everything, so we can have big disclaimers
about syntax and everything
howcome: But I'd like to get out another WD. First for updates to other
things. But second there seems to be consensus that we want to
work on this.
glazou: Don't have consensus, have interest
glazou: So provided you document all the issues and comments.
glazou: It's only a WD and we have interest in the feature
szilles: I'm def interested in the feature, but not sure where it belongs
fantasai: It can start here, and then we'll see where it goes. Just like
everything else.
TabAtkins: Move counter styles to css3-lists? most is already in css3-lists.
Willing to take on the next thing
dbaron: I think there's a bunch of things in this spec, and not a whole
lot of interest in other things in the spec
dbaron: So we're going with the model that everything we actually want will go
out of it?
fantasai: we're doing that already
howcome: Like John said, I don't think this module will ever go to REC
glazou: Any objection to publishing?
RESOLVED: Publish CSS3 GCPM as soon as all edits are made
glazou: Reminder, lot of joint meetings tomorrow, not necessarily in this room
glazou: Also FXTF on Thursday
glazou: Start here tomorrow.
glazou: We will discuss CSSOM with Anne at 9am
fantasai: jdagget, kojiishii and I will be having a joint meeting with
the UTC on Thursday
Received on Monday, 28 November 2011 21:59:21 UTC