- 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