00:02:05 <arronei> arronei has joined #CSS
00:15:22 <Arron> Arron has joined #CSS
00:30:11 <arronei> arronei has joined #CSS
00:39:17 <Arron> Arron has joined #CSS
00:41:43 <arronei> arronei has joined #CSS
00:51:24 <Arron> Arron has joined #CSS
00:59:13 <arronei> arronei has joined #CSS
01:02:53 <arronei> arronei has joined #CSS
01:17:00 <arronei> arronei has joined #CSS
01:42:23 <arronei> arronei has joined #CSS
03:14:56 <Arron> Arron has joined #CSS
03:24:20 <arronei> arronei has joined #CSS
03:30:54 <Arron> Arron has joined #CSS
03:49:42 <arronei> arronei has joined #CSS
04:00:58 <Arron> Arron has joined #CSS
05:36:59 <dbaron> dbaron has joined #css
05:45:13 <anne> anne has joined #css
05:51:09 <plinss_> plinss_ has joined #css
06:08:31 <arron_> arron_ has joined #css
06:28:05 <plinss_> plinss_ has joined #css
06:57:16 <CWilso> CWilso has joined #css
07:01:30 <melinda> melinda has left #CSS
07:01:41 <melinda> melinda has joined #CSS
07:02:47 <jdaggett> jdaggett has joined #css
07:06:30 <MoZ> MoZ has joined #css
07:06:54 <alexmog> alexmog has joined #css
07:07:15 <glazou> glazou has joined #css
07:08:03 <shepazu> shepazu has joined #css
07:08:06 <plinss_> plinss_ has joined #css
07:10:49 <sylvaing> sylvaing has joined #css
07:15:57 <plinss_> plinss_ has joined #css
07:16:13 <jdaggett> jdaggett has joined #css
07:23:45 <dbaron> dbaron has joined #css
07:28:36 <sylvaing> ScribeNick:sylvaing
07:28:39 <dbaron> dbaron has joined #css
07:28:48 <sylvaing> ScribeNick: sylvaing
07:29:03 <glazou> http://wiki.csswg.org/spec/css2.1#issue-60
07:29:10 <glazou> Topic is z-index in lev2
07:29:21 <glazou> http://dev.moonhenge.net/css21/spec/z-index/
07:29:47 <sylvaing> (second URL describes z-index issues)
07:30:37 <sylvaing> Hixie: document appears to be a large number of editorial changes; propose to reject on basis of too many changes; also one typo + one misunderstanding
07:30:48 <sylvaing> Hixie: bottom line, one "'s" should be removed....
07:31:29 <sylvaing> Hixie: emailed author to suggest he sends testcase(s) to highlight actual issues
07:33:38 <sylvaing> dbaron: a float can be relatively positioned so 2.10 may be relevant
07:36:47 <dbaron> We could add "non-positioned" in (3) (4) and (5) in the 7-point list in 9.9.1
07:37:43 <dbaron> and of course change "float's parent's stacking context" to "float's parent stacking context"
07:37:46 <Hixie> right
07:37:48 <dbaron> in 9.5
07:39:13 <Hixie> it's slow
07:39:18 <Hixie> >500ms ping to the router in the hotel
07:39:23 <glazou> CWilso: it is
07:39:26 <sylvaing> plinss: i wonder if there is value in making the editorial changes in a future revision
07:40:55 <sylvaing> glazou: hixie, do you think we should take the changes ?
07:41:14 <sylvaing> hixie: changes are always normatively risky
07:41:57 <sylvaing> plinss: not sure there is css3 module where this change could be made
07:42:38 <sylvaing> plinss: not rejecting comments, but should reject them for CSS21 edits
07:45:07 <sylvaing> RESOLVED: two Appendix editorial changes accepted; no CSS21 updates; Hixie to email proposal author
07:45:43 <sylvaing> glazou: next topic : text layout/direction module
07:45:47 <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2008OctDec/0020.html
07:46:03 <sylvaing> bert: we need to place this module on the roadmap
07:46:24 <arron_> Hixie, Please remind the proposal author to create test cases.
07:46:42 <sylvaing> fantasai wonders if it needs to be split up
07:47:13 <sylvaing> alexmog points out dependency between box model and direction
07:47:38 <Hixie> arron_: did that in my first e-mail
07:51:01 <sylvaing> fantasai, alexmog, bert: line grid will move out of text layout to a separate module
07:51:34 <sylvaing> bert: does name of module remain text layout ?
07:51:41 <sylvaing> fantasai: yes, that makes sense
07:51:50 <sylvaing> alexmog: deadline to make this happen ?
07:53:28 <sylvaing> fantasai, bert, alexmog : first public working draft by end of year
07:55:45 <sylvaing> RESOLVED: FPWD of text layout module end of year, alexmog/salonir/fantasai editors; line grid module moves to new editor's draft
07:56:01 <sylvaing> glazou: priority of text layout ?
07:57:54 <sylvaing> RESOLVED: goal is CR during charter period
07:59:48 <plinss_> plinss_ has joined #css
08:00:35 <sylvaing> glazou: topic is closed
08:00:42 <jdaggett_> jdaggett_ has joined #css
08:01:09 <sylvaing> glazou: we are left with paged media issues we need to address in the afternoon so melinda can attend
08:01:59 <sylvaing> glazou: next topic is attribute selection
08:02:23 <sylvaing> glazou: this is about selecting the empty string with an attribute selector
08:02:45 <sylvaing> glazou: previous f2f said that the following matches nothing : P[foo$=""]
08:03:05 <George> George has joined #css
08:03:29 <sylvaing> glazou: but P:not(foo$="") matches everything
08:03:50 <sylvaing> glazou: potential for browser hack
08:04:29 <sylvaing> glazou: this is true for all attribute selectors; regular = is fine
08:04:31 <nickshanks> nickshanks has joined #css
08:05:15 <sylvaing> glazou: this should be invalid
08:05:24 <sylvaing> dbaron: I'm not sure this is a good reason to make this invalid
08:06:06 <sylvaing> (good reason being second selector was not sensical)
08:08:09 <CWilso> CWilso has joined #css
08:08:13 <sylvaing> glazou: this is because the empty string is always a substring of any non-empty string
08:12:44 <sylvaing> dbaron, fantasai, glazou discuss previous decisions on the matter and mozilla changes
08:13:50 <sylvaing> glazou proposes that $="", *="" and ^="" never match
08:14:53 <dbaron> FWIW, I said that I thought the discussion was a waste of time -- we were one tiny mozilla change and one tiny spec clarification away from complete interop, and then we changed the spec to something drastically different, and now we're discussing changing it to something else drastically different.  I'd prefer whatever solution ends the discussion the fastest and closes it for sure.
08:15:21 <fantasai> dbaron, what would be the one tiny spec clarification for interop?
08:15:36 <dbaron> fantasai, it would have been saying *="" always matched when the attribute was present
08:15:50 <fantasai> what about the others?
08:15:58 <dbaron> fantasai, I think it was already clear for the others.
08:16:05 <fantasai> $=?
08:16:07 <fantasai> ~=?
08:16:21 <dbaron> ~= is entirely separate; I think it was clear for $= and ^=
08:16:35 <sylvaing> sylvaing, plinss, glazou: empty string could only match an attribute value set to the empty string
08:17:34 <sylvaing> fantasai: today, we have interop between slightly older versions of firefox, opera and safari
08:18:11 <fantasai> although iirc safari did something weird on one of the cases
08:18:17 <glazou> http://www.disruptive-innovations.com/zoo/css3tests/selectorTest.html#target
08:19:27 <sylvaing> glazou: no decision since no consensus
08:19:37 <sylvaing> plinss: what do we need to do to come to a decision ?
08:19:51 <sylvaing> glazou: we need to test current implementations
08:20:25 <sylvaing> alexmog, plinss: we are not far from a decision since no one is opposed to either decision
08:20:39 <sylvaing> plinss: we have consensus that no one has a clue
08:20:59 <fantasai> data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html lang%3D"en">%0D%0A <head>%0D%0A  <title>Test<%2Ftitle>%0D%0A  <style type%3D"text%2Fcss">%0D%0A    p[title~%3D""] { text-decoration%3A underline%3B }%0D%0A    p[title*%3D""] { color%3A orange%3B }%0D%0A    p%3Anot([title~%3D""]) { border%3A solid blue%3B }%0D%0A    p%3Anot([title*%3D""]) { background%3A yellow%3B }%0D%0A  <%2Fstyle>%0D%0A <%2Fhead>%0D%0A <bod
08:21:49 <fantasai> http://tinyurl.com/5qluy2
08:24:52 <sylvaing> dbaron: the test does not capture the change made in firefox 3 so not conclusive
08:26:40 <sylvaing> fantasai: logic of the change was that there was interop on ~= so we made everything else work based on tilde's semantics
08:27:02 <sylvaing> dbaron: but it looks like we do not interop on tilde...
08:27:19 <dbaron> s/do not/did not/
08:27:27 <dbaron> (because Safari behaved differently for ~=)
08:29:45 <fantasai> http://pastebin.mozilla.org/558307
08:29:49 <jdaggett> jdaggett has joined #css
08:31:36 <sylvaing> no decision on this topic
08:43:09 <fantasai> Alex, peter, and fantasai are looking at the test case results for FF3, FF trunk, Safari, and Opera and seeing no interop. But at least FF trunk's behavior is predictable
08:46:51 <plinss_> plinss_ has joined #css
09:10:06 <plinss__> plinss__ has joined #css
09:10:34 <jdaggett> jdaggett has joined #css
09:11:23 <jdaggett_> jdaggett_ has joined #css
09:16:44 <sylvaing> sylvaing has joined #css
09:20:53 <anne> CSS haz a <br>?
09:20:59 <sylvaing> ScribeNick: sylvaing
09:21:09 <anne> ah, had :)
09:21:15 <sylvaing> fantasai presents CSS variables/constants proposal
09:21:26 <fantasai> http://fantasai.inkedblade.net/style/specs/constants/
09:21:30 <fantasai> s/proposal/counter-proposal/
09:22:34 <sylvaing> the counter-proposal defines parse-time constants
09:24:17 <sylvaing> for example, one can separate the layout from the colors across site pages e.g. a site like launchpad.net
09:25:06 <sylvaing> fantasai reviews implementation constraints
09:25:42 <sylvaing> fantasai: three type of constants: value constants, styleset constants and selector constants
09:25:47 <sylvaing> defined with @define block
09:25:58 <sylvaing> fantasai reviews examples
09:26:01 <shepazu> shepazu has joined #css
09:28:02 <sylvaing> fantasai: selector constant must be a valid selector but cannot comma-separated grouping syntax since the constant may be part of a selector
09:28:51 <sylvaing> fantasai discusses scoping; declarations in-scope from point of declaration until overriden; not changed, just overriden
09:30:01 <sylvaing> fantasai: constants do not cross @import boundaries without a special @import keyword
09:31:54 <sylvaing> discussion of scoping and asynchronous stylesheet parsing
09:33:05 <sylvaing> @import keywords are pull, push and sync
09:33:29 <sylvaing> glazou: why not allow two keywords so "@import push pull" equivalent to "@import sync" ?
09:34:51 <sylvaing> alexmog: do other languages have this ability to control scope ?
09:35:05 <sylvaing> jdaggett_: don't compound docs have this ?
09:36:09 <sylvaing> fantasai: I picked a constant expansion character, no personal preference
09:37:05 <sylvaing> glazou: if an expanded selector constant is invalid what happens ?
09:37:07 <MoZ> MoZ has joined #css
09:37:25 <sylvaing> fantasai: if the constant hasn't been declared, it doesn't get expanded; in this case, the selector is invalid
09:38:17 <sylvaing> jdagett: why we need selector constants ?
09:38:27 <sylvaing> glazou, plinss: users ask for it
09:38:33 <sylvaing> jdaggett: use-case ?
09:39:11 <sylvaing> glazou, plinss, fantasai: complex selectors e.g. styling content nested inside a cell
09:40:57 <sylvaing> glazou: I understand why one may prefer immutable constants to variables but these need to be accessible through CSSOM so the stylesheet can be re-serialized as it was authored
09:41:28 <sylvaing> glazou: you especially want to preserve the rule when the constant turns out to be invalid
09:42:05 <sylvaing> alexmog, fantasai, plinss: you have this problem with invalid CSS anyway
09:42:29 <fantasai> plinss: and comments, etc.
09:42:44 <sylvaing> glazou: in an editor manipulating stylesheets, you need to preserve the @define blocks
09:44:47 <sylvaing> glazou: I must be able to edit the @define rule in an editor but how do I do that if it's gone at parse time ?
09:48:28 <sylvaing> glazou: not sure pull/push/sync are useful
09:49:05 <sylvaing> dbaron, plinss: for constants, it would make sense for the first constant definition to 'win'
09:49:46 <dbaron> or would at least solve the problem of (1) define constant C (2) rule using constant C (3) redefine constant C (4) use CSSOM to manipulate rule in (2) to use constant C differently
09:51:23 <glazou> howcome : don't use the $ sign because the dollar is so weak these days
09:51:33 <dbaron> (discusion of $ or € :-)
09:51:48 <sylvaing> fantasai: processing model is parse time, after tokenization
09:54:36 <sylvaing> alexmog questions the priority of selector constants
09:55:00 <sylvaing> glazou: values is the #1 use-case but selector is also a common request
09:55:51 <sylvaing> glazou: making them global means you'd have to parse everything (even two passes ?)
09:58:08 <sylvaing> fantasai reviews name-value table handling depending on @import statement
10:01:46 <dbaron> It seems like this isn't significantly simpler.
10:02:22 <sylvaing> fantasai reviews an example in the document
10:03:55 <sylvaing> alexmog: first one wins would make global confusing as a local definition could be ignored due to one you cannot see
10:04:19 <sylvaing> s/global/global scope
10:08:40 <sylvaing> hakkon: I don't want to have things changing after parse time
10:09:02 <sylvaing> glazou: making it parse time only makes it unusable in an editor since I do not even know there are constants in your stylesheets
10:10:27 <sylvaing> hakkon: you'd have to reimplement a parser
10:14:44 <fantasai> background: #FFDDDD;
10:14:52 <fantasai> background: rgba(100%, 0, 0, 0.5);
10:15:02 <fantasai> background: url(image1.png), url(image2.png);
10:15:11 <fantasai> your editor will only see the middle declaration, the other two will get lost
10:15:39 <fantasai> the problem with information getting lost in the CSSOM already exists
10:15:55 <fantasai> howcome: I think it would be a reasonable extention to the CSSOM to allow access to the strings
10:16:26 <fantasai> howcome: I've got very strong feedback from my developers that they want this at parse time only
10:17:37 <sylvaing> plinss: shouldn't a style attribute be able to refer to a constant ? 
10:18:32 <fantasai> glazou: I understand perfectly the users side of this
10:18:46 <fantasai> glazou: but it still seems very hard for implementors
10:19:29 <sylvaing> fantasai: there are also use-cases that are not covered
10:19:38 <fantasai> by the variables proposal
10:25:21 <sylvaing> fantasai: spec is currently too technical to be presented; it needs examples and use-cases for a web author audience
10:25:47 <sylvaing> dbaron: both proposals - variables and constants - seem like a lot of work
10:26:10 <sylvaing> plinss: which one do you prefer ? opera favors a parse-time solution. would you agree ?
10:26:40 <sylvaing> glazou: parse-time solutions are browser-only; harmful to editing tools
10:27:02 <sylvaing> plinss: would distinction between parse-time vs. runtime affect your decision ?
10:27:05 <sylvaing> dbaron: I don't think so
10:27:22 <sylvaing> alexmog: agree it's not parse vs. runtime but completeness of the solution.
10:28:02 <sylvaing> alexmog: parse-time only is different from everything else we have; especially one without an object model.
10:28:57 <sylvaing> glazou: this is a pragmatic position : do not restrict the feature for the user, it's an implementor issue
10:29:38 <sylvaing> dbaron: the relative priority of this also has to be taken into consideration; the cost is similar to cal() but I think calc is higher priority
10:31:01 <sylvaing> howcome: this is simple. we shouldn't have an object model
10:31:16 <sylvaing> dbaron: i worry about solutions of this kind since we'll have to come back and change it later
10:33:37 <sylvaing> dbaron worries about loading consideration (sync cost)
10:34:51 <sylvaing> plinss: other feedback is that if they're defined inside an @media block they shouldn't propagate outside
10:35:22 <sylvaing> fantasai: but i might to have different declarations per media but the same value
10:36:58 <plinss__> http://www.webmonkey.com/blog/What_s_On_Your_CSS_Wishlist_
10:37:10 <plinss__> <br type="lunch">
11:42:16 <anne> anne has joined #css
11:44:19 <anne> anne has joined #css
11:45:09 <anne> anne has joined #css
11:47:20 <glazou> glazou has joined #css
12:02:03 <shepazu> shepazu has joined #css
12:06:40 <alexmog> alexmog has joined #css
12:07:18 <jdaggett> jdaggett has joined #css
12:15:33 <fantasai> Bert: I can think of two options for the background shorthand: dropping the slash in background-color (since it's not strictly necessary, it's there only for clarification)
12:16:18 <fantasai> Bert: or requiring that the non-fallback color be specified in the shorthand and forbidding  background-size from appearing immediately after the color
12:19:23 <Bert> So in either case, the non-fallback color becomes required.
12:19:40 <fantasai> hm, yeah
12:22:16 <Bert> It's not necessarily a problem. You may have to use 'transparent' a bit more often.
12:23:46 <dbaron> dbaron has joined #css
12:25:58 <MoZ> MoZ has joined #css
12:38:33 <Bert> Dbaron's issue with 2-token look-ahead would only go away if the slash is removed, so fantasai's first option seems best.
12:38:57 <Bert> PPlinns is OK with that, he says.
12:39:13 <Bert> s.PPlins/Plins/
12:39:14 <fantasai> my only concern is readability/understandability of the style sheet
12:39:28 <plinss__> s/Plins/plinss/
12:39:32 <fantasai> other than that there is no strong reason for the /
12:40:40 <plinss__> Having two colors is no less understandable than having a slash IMO, when I first see the slash I have to wonder what it's for
12:41:43 <plinss__> I actually think it would be more understandable to have the fallback color as a separate property
12:42:36 <fantasai> no, you really really want it to be reset together with background-color
12:42:59 <fantasai> imagine I set background-color: transparent; background-fallback: red;
12:43:09 <fantasai> then later in the cascade I have background-color: white;
12:43:18 <fantasai> That background-color: white must reset the fallback as well
12:43:30 <fantasai> otherwise I get background-color: white; background-fallback: red;
12:43:36 <fantasai> which is totally not what anyone is expecting
12:43:36 <plinss__> ok
12:45:40 <plinss__> although whether or not the later specification of background-color may still not be seen can still depend on whether the background-image loads or not. Does it perhaps make sense to associate the fallback color with the image rather than the background-color?
12:46:37 <plinss__> if the later rule really wanted a white background, you'd have to set the background-image to none as well...
12:46:37 <fantasai> hmmm perhaps
12:46:47 <plinss__> which would also preclude the use of the fallback color
12:47:19 <Bert> There is currently only a fallback color for the last image.
12:53:10 <Bert> What syntax could distinguish a fallback color from a normal color? The slash requires look-ahead. It being the second color works, butthen the color is associated with another color, not with an image, as plinns said.
12:54:45 <sylvaing> sylvaing has joined #css
12:55:17 <Bert> Two slashes (//) instead of one?
12:57:39 <fantasai> oww
12:57:55 <fantasai> maybe for the background-size, if you must
12:58:13 <dbaron> some implementations treat // as comments, I think
12:58:20 <fantasai> lol
13:10:17 <glazou__> glazou__ has joined #css
13:13:03 <plinss_> plinss_ has joined #css
13:14:02 <glazou> fantasai: not having critical mass here ...
13:16:50 <sylvaing> sylvaing has joined #css
13:20:17 <CWilso> CWilso has joined #css
13:21:26 <Bert_> Bert_ has joined #css
13:22:56 <Bert_> Bert_ has joined #css
13:23:01 <dbaron> ScribeNick: dbaron
13:23:08 <dbaron> Topic: Paged Media
13:24:29 <dbaron> Elika: 'em' on font-size on root element
13:25:40 <dbaron> We find "When specified for the root of the document tree (e.g., "HTML" in HTML), 'em' and 'ex' refer to the property's initial value. " in 4.3.2
13:26:05 <dbaron> Elika: Should margin boxes and page borders and backgrounds be printed on blank pages?
13:26:35 <dbaron> Elika: We propose we just print them, but adding :blank that would let you specify visibility:hidden
13:26:43 <dbaron> Elika: Technical documents tend to print them, novels tend not to.
13:27:07 <dbaron> (adding in level 4)
13:27:15 <Bert_> Bert_ has joined #css
13:27:31 <dbaron> Haakon: Should I put in in gcpm?
13:27:39 <dbaron> Elika: I also have it on the wiki for the level 4 draft.
13:27:46 <dbaron> Haakon: We could make gcpm the level 4 draft.
13:27:49 <dbaron> Elika: part of it
13:28:18 <dbaron> RESOLVED: It's ok to have everything print even for blank pages, as long as we have control over it in a future level.
13:28:23 <fantasai> RESOLVED: headers, footers, borders, etc print on blank pages, add :blank selector later
13:29:06 <fantasai> http://www.savagecreek.net/CSS/Page/css3_paged_media_lc2_issues_list.htm
13:29:14 <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Oct/0233.html
13:29:16 <dbaron> (previous was issue 8)
13:29:37 <dbaron> Elika: Issue 3: We don't define what happens when the width of the page changes mid-document.
13:29:57 <dbaron> Elika: Proposal is that each page is laid out as though the ICB is the same size as the current page, but allow exceptions for tables and shrink-to-fit elements.
13:30:08 <dbaron> Elika: ... if they split across pages
13:31:15 <dbaron> Alex and Elika discuss some possibilities
13:31:21 <ed> ed has joined #css
13:32:03 <glazou> lol
13:32:33 <dbaron> Alex: How important is it to reflow things into irregular-shaped pages, as opposed to ensuring that a container keeps constant width?
13:32:46 <dbaron> Elika: If you have that rule, the root element stays the same width throughout the document.
13:33:37 <dbaron> Alex: I like this rule applied to body but not to a paragraph.
13:33:52 <dbaron> Alex: Things with BFC should have an exception.
13:34:16 <dbaron> Alex: But even without BFC, things can have position:relative, be a containing block for absolutely positioned elements, etc.
13:36:13 <dbaron> Alex: I'm going to claim no use case for continuous flow of text across irregular pages.
13:36:20 <dbaron> Peter: Or almost none.
13:36:30 <Bert> Bert has joined #css
13:37:28 <fantasai> dbaron: I think if you define this for block elements in the normal flow, then the wacky cases are going to be the cases that don't matter
13:38:21 <dbaron> Haakon and Elika discuss a bug in Opera.
13:38:30 <Bert_> Bert_ has joined #css
13:38:58 <dbaron> Hakon: Most often, the margins are going to change, but it's not going to change the width of the CB -- gutters on opposite sides, first page having bigger margin at top, etc.
13:39:33 <dbaron> Alex: I could live with a requirement of a non-BFC-element adapting to changing width, but having softer language until we have an implementation showing it works.
13:39:34 <mollydotcom> mollydotcom has joined #css
13:39:53 <dbaron> Elika: OK, non-BFC, in normal flow, and requirement is a SHOULD.
13:41:23 <dbaron> Alex: multiple bodies would make this easier...
13:41:42 <dbaron> Haakon: Can an element start on one type of page and go to another?
13:41:47 <dbaron> Elika: Certainly.
13:42:47 <ed> ed has joined #css
13:43:09 <dbaron> (David, Haakon, and Alex discuss DOM, etc.)
13:44:41 <fantasai> RESOLVED: Adopt proposal that page layout on current page assumes ICB matches current page size and contents lay out accordingly, restrict requirement to SHOULD and applying for non-BFC elements in normal flow, all others being undefined
13:45:08 <dbaron> Elika: Next thing is counters scoping.
13:45:22 <dbaron> Elika: Melinda and Haakon both want scoping of counter to be shared between document and page context.
13:45:35 <dbaron> Elika: So if I have a counter in the document I can print it in the margin box
13:45:52 <dbaron> Elika: That's already defined to work, but the reverse doesn't work currently.
13:46:11 <dbaron> Haakon: Just have one namespace.
13:46:54 <fantasai> dbaron: There's three things you can do with counters. You can use them, increment them, and reset them
13:47:06 <fantasai> dbaron: Using and incrementing you just need to define the order
13:47:13 <fantasai> dbaron: reset is a problem
13:50:26 <fantasai> fantasai: what would reset on an @page mean? reset at the start of the document? what about on a named page?
13:50:36 <fantasai> fantasai: reset on the first named page? every named page?
13:50:39 <fantasai> howcome: every named page
13:50:46 <fantasai> fantasai: how is that useful?
13:50:48 <fantasai> peter: footnotes
13:52:13 <fantasai> dbaron talks very fast and very detailed about counters
13:53:31 <fantasai> fantasai, howcome: what if counter-reset on @page doesn't create a scope?
13:53:52 <fantasai> dbaron: This ties into a counter-set property that sets the value without introducing a new scope
13:54:12 <fantasai> dbaron: I think CSS counters are too limited to do the headers that we want
13:54:17 <fantasai> dbaron: or the headers in html5
13:55:51 <fantasai> BREAK
13:59:32 <mollydotcom> do I get a break too?
14:05:23 <MoZ> MoZ has joined #css
14:11:22 <glazou> mollydotcom: and pear pie
14:11:31 <mollydotcom> oooh, pear pie?
14:11:32 <glazou> apricot pie too
14:11:33 <mollydotcom> lovely
14:11:34 <glazou> yep
14:11:51 <glazou> there's enough pear pie for 25 persons and we're 236 :)
14:11:56 <glazou> lovely eh ?
14:12:32 <mollydotcom> someone needed a counter (badumpump)
14:12:49 <CWilso> KSSSH!
14:13:17 <CWilso> @glazou I hereby give you permission to eat my 25/236th of the pear pie
14:18:15 <Lachy> Lachy has joined #css
14:18:27 <fantasai> dbaron: I think that if we a) said that a counter-reset on the page context didn't make a new scope and
14:19:08 <fantasai> dbaron: b) counter-resets and counter-increments affect all counters that are in scope at the deepest point in the normal flow at the page break
14:19:12 <fantasai> dbaron: ...
14:21:21 <fantasai> fantasai: the example in http://dev.w3.org/csswg/css3-page/#page-based-counters should just work
14:21:33 <sylvaing> sylvaing has joined #css
14:23:02 <fantasai> fantasai summarizes that the page context and document interact as if the page context were an element within the document at the start of the page, inside the deepest element in the normal flow that spans the page break.
14:23:22 <ed> ed has joined #css
14:23:33 <jdaggett> jltf continues!!
14:24:28 <fantasai> fantasai: Would @page { counter-increment: foo; } create a counter scope at the root?
14:25:31 <fantasai> dbaron: I'd have to check old emails to see if that works
14:26:17 <fantasai> http://www.w3.org/TR/CSS21/generate.html#scope
14:26:39 <fantasai> dbaron: The problem with that was with nested counters
14:26:58 <fantasai> dbaron: I remember what the problem was
14:27:14 <fantasai> dbaron: Say you're using ul, li with the appropriate resets and increments
14:27:27 <fantasai> dbaron: and your ::marker pseudo uses a counters() expression that does dotted numbering
14:27:40 <fantasai> dbaron: this is all happy as far s incremental rendering goes
14:28:31 <fantasai> dbaron: if after this list, somebody sticks in an <li> that is not in the <ul> that creates an implied scope on the root element, and you have to go back and renumber the list items with a zero in front
14:32:50 <fantasai> fantasai: so what if we define any counter-resets and increments in the page context not to create a scope
14:33:01 <fantasai> fantasai: in the document
14:33:18 <fantasai> fantasai: but all counter-reset and increment declarations create a scope on the root element
14:34:50 <fantasai> Bert asks about page counter increments
14:34:58 <fantasai> @page { counter-increment: page; }
14:35:28 <fantasai> _@page {counter-increment: foo; }
14:35:36 <fantasai> @page { counter-increment: page 0; }
14:36:03 <fantasai> agreement that it doesn't make sense to put any of this in the margin boxes
14:36:45 <fantasai> @page foo { counter-increment: bar; }
14:37:37 <fantasai> @page { @top-left { content: counter(bar); } }
14:38:06 <fantasai> fantasai: so does bar get created at the root, even if it is never used? or does the increment get ignored?
14:40:35 <fantasai> my proposal is to only create scopes on the root element for any counters referenced on the first page of the document
14:40:54 <fantasai> so if I want to increment bar in @page foo, then I need to declare it
14:41:16 <fantasai> otherwise, we have to gather all declarations for @page and create scopes for any counter-* counters that have been delcared
14:41:21 <fantasai> even if that declaration never gets used 
14:41:56 <dbaron> ACTION Elika: propose a solution for allowing counter-properties on @page that doesn't require going through all the pages at the beginning to figure out what to reset on the root
14:41:56 <trackbot> Created ACTION-114 - Propose a solution for allowing counter-properties on @page that doesn't require going through all the pages at the beginning to figure out what to reset on the root [on Elika Etemad - due 2008-10-28].
14:42:08 <dbaron> Elika: Should the 'page' property be inherited?
14:42:10 <dbaron> Hakon: No.
14:42:20 <dbaron> Elika: HP has a bunch of implementations that already inherit it.
14:42:47 <dbaron> Elika: It was difficult to get these other implementations to not inherit page-break-inside; we don't want to push it further.
14:43:05 <dbaron> Haakon: I think we fixed things for non-inherited 'page' so that all the use cases work the same way.
14:43:44 <dbaron> Elika: One approach is to come up with a solution that lets inherited work for all use cases, another is to let implementations be conformant to print profile even if they inherit.
14:43:56 <dbaron> Hakon: [shows css3-gcpm dev.w3.org draft]
14:44:04 <dbaron> Hakon: I think this solution addresses all the use cases.
14:44:09 <dbaron> Elika: What about existing content?
14:44:44 <dbaron> Hakon: We're making it into a list of properties, which is why we need it to be not inherited.
14:44:53 <dbaron> Hakon: I think when it's not a list of values, it doesn't matter.
14:45:14 <dbaron> Elika: Do we want it to be a list?
14:45:30 <dbaron> Hakon: We worked hard to reach this consensus; print implementors are in.
14:46:00 <dbaron> Elika: The behavior of 'auto' inside an element that has a named page is different.
14:47:44 <dbaron> Hakon: It may be that this can stay inherited when you only have one value, but we want to go to multi-value.  There has been significant discussion among vendors.
14:49:32 <dbaron> Elika: The problem is that most of the time you want the first page of a series to be special, the middle pages to be uniform, and maybe the last page to be special.
14:49:49 <dbaron> Elika: Another proposal that would preserve inheritance of 'page' would be:
14:50:59 <anne> anne has left #css
14:51:15 <dbaron> Elika: In level 4 or gcpm, page becomes a shorthand for page-name (inherited), page-foo (non-inherited)
14:51:35 <dbaron> Elika: where page-foo takes value 'auto', 'trigger-first', 'continue-onto-next-page', etc.
14:52:13 <anne> anne has joined #css
14:52:27 <dbaron> Hakon: I'd rather start from the proposal we've discussed for a long time than a brand new proposal.
14:52:56 <dbaron> Elika: There's a backwards-compat issue, and an interacting with other standards orgs issue.
14:53:07 <dbaron> Hakon: Do you have a code example to show the backwards-compat issue?
14:53:48 <dbaron> Elika: The content that works differently is <div style="page:foo"><div style="page:auto"></div></div> which is probably not very common.
14:53:57 <dbaron> Elika: The issue HP has is about asking implementations to change.
14:54:03 <dbaron> Hakon: Why don't we take this offline?
14:55:32 <dbaron> Hakon: They'd have to change when they go to the list value.
14:56:51 <dbaron> Elika, Hakon: We can add loopholes, making implementations conformant if they do inherited, and warning authors about the case where there's a difference.
14:57:40 <dbaron> Bert: With the page lists, is an empty page caused by page-break-before: right counted as one of the pages in the list?
14:57:47 <dbaron> Hakon: Good question.
14:58:00 <dbaron> Bert: I think you strike from the page list even for empty pages.
14:58:46 <dbaron> Elika: I think you don't.
15:00:58 <dbaron> Peter: Pages that matter are often ones going straight from device to printer, not on the Web.
15:01:12 <dbaron> Hakon: Change in gcpm rather than css3-page?
15:01:25 <dbaron> Elika: We should go with what we ultimately want to do now.
15:01:38 <hendry> hendry has joined #css
15:02:15 <dbaron> Peter: Hard to do a straw poll given the implementors here, and those not here.
15:02:38 <dbaron> Hakon: I don't feel like forcing printer manufacturers to change their hardware.
15:02:48 <dbaron> Elika: If we're going to do this, we should definitely put in warnings, etc.
15:02:57 <dbaron> Hakon, Elika, Peter: Both should be normatively compliant.
15:03:13 <dbaron> Peter: I think I'm ok with that given that the 2 uses may never see each other.
15:03:22 <dbaron> Haakon: Good, we have consensus.
15:03:32 <dbaron> Peter: Well, provisional, depending on Melinda's reaction.
15:04:25 <dbaron> Topic: overflow:scroll in paged media
15:04:28 <dbaron> Alex: (draws)
15:05:22 <dbaron> Alex: For overflow:scroll, should we render scrollbar on paper or drop it?
15:05:38 <dbaron> Alex: With overflow:auto, and something doesn't fit on page, we don't know if element will fit or not.
15:06:15 <dbaron> Alex: By the second page, we know whether the screen presentation would have a scrollbar.
15:06:20 <dbaron> David: last page
15:06:30 <dbaron> Alex: In theory, we could go back and re-render previous page.
15:06:38 <dbaron> Alex: Current behavior differs across implementations
15:07:05 <dbaron> Alex: Printing in Firefox never renders a scrollbar for overflow:auto
15:07:14 <George> George has left #css
15:07:19 <dbaron> Alex: Printing in Opera always renders scrollbar for first page, not sure what it does for last page.
15:07:31 <dbaron> Alex: Printing in Safari does something else.
15:07:56 <dbaron> Jonas: You don't know what size to make the scrollbar thumb.
15:08:39 <dbaron> Alex: There are two things I really don't want:
15:08:47 <dbaron> Alex: (1) I don't want to have to go back to the previous page and recalculate it.
15:08:49 <ed> ed has joined #css
15:09:10 <dbaron> Alex: (2) I don't want to have a scrollbar on one page and not have it on one page (thus producing different widths, which has its own set of problems)
15:09:38 <dbaron> Alex: I favor Firefox behavior; there isn't much use for the scrollbar on paper.
15:09:46 <dbaron> David: Do we print scrollbars for overflow:scroll?
15:09:52 <dbaron> Alex: Yes, but never for 'aut'.
15:09:55 <dbaron> s/aut/auto/
15:10:51 <ed> ed has joined #css
15:10:57 <dbaron> Alex: I think Safari doesn't paginate the element.
15:11:55 <plinss__> plinss__ has joined #css
15:11:58 <dbaron> David: Seems like printing scrollbars on paper is a bad idea...
15:12:33 <dbaron> (Hakon and Alex test something in Opera)
15:13:31 <dbaron> Alex: My proposal is that when printing an element with overflow:auto, it is ok to never print scrollbars.
15:13:37 <dbaron> Hixie: That's already ok.
15:13:47 <dbaron> Alex: It's also ok to print scrollbars if UAs so desire.
15:14:00 <dbaron> Hixie: The spec also says you can use whatever scrolling mechanism you like.
15:14:47 <ed> ed has joined #css
15:17:37 <dbaron> Topic: Do elements with overflow:auto and overflow:scroll split when printed?
15:17:53 <dbaron> Alex: Seems ok to not print.
15:18:14 <dbaron> Peter: Seems good if something that scrolls on screen to print spread out on paper; but then there's also the argument for print style sheets.
15:18:37 <dbaron> Elika: Seems like UA should be allowed to act as though it had height:auto
15:18:49 <dbaron> Peter: How would the UA know what content that's reasonable to do on and what it's not.
15:20:18 <dbaron> Peter: There is a class of users who want printing to yield a screen grab.
15:20:47 <dbaron> Jonas Sicking: It makes sense to show there is clipped content that would show on screen...
15:20:54 <ed> ed has joined #css
15:20:55 <dbaron> Peter: Printing a scrollbar does that.
15:21:17 <dbaron> Alex: Now that we have devices that scroll but don't show scrollbars, we should encourage UAs to produce indications of scroll that aren't scrollbars.
15:21:28 <dbaron> Peter: That can be UA dependent.
15:21:41 <dbaron> Alex: There's always the option of a print style sheet.
15:22:10 <dbaron> Peter: Would be nice if overflow:auto could degrade into height:auto in print, but overflow:scroll doesn't.
15:22:17 <dbaron> Peter: but not sure if that really makes sense.
15:22:54 <dbaron> Alex: Use cases for overflow:auto always involve height not 'auto'.
15:24:06 <dbaron> Alex: But rel pos could create scrollbars without height:auto.
15:25:37 <dbaron> Alex: I think we have a consensus that it is not required to make content that's not visible on screen visible when printing.
15:26:05 <ed> ed has joined #css
15:26:44 <dbaron> Peter: I want the corollary to be that something that has all of its content visible on screen shouldn't trigger an overflow condition when printing just because it's near the page boundary.
15:28:02 <dbaron> RESOLVED: It is not required to make content that's not visible on screen visible when printing.
15:28:42 <dbaron> Elika: If you have a fixed height element that contains a page break (either something didn't fit, or forced break) that's not quite at the bottom of the page, should that gap consume height of the element?
15:29:19 <dbaron> Elika draws.
15:31:01 <dbaron> David: Also, do you draw the side borders along where you're skipping?
15:31:23 <dbaron> Alex: And does it count as part of the height of the body for something abs pos relative to body?
15:33:13 <dbaron> Bert, Peter, David agree that border and height stop 1em above the bottom of the page (element does not continue into gap)
15:33:23 <dbaron> Jonas: What about one of them being a float:  two picees of text being uneven?
15:33:29 <dbaron> s/picees/pieces/
15:34:50 <dbaron> Elika: What about flowing text into the gap
15:35:37 <dbaron> Peter: If you don't let text flow under it, text should flow under the borders
15:35:55 <dbaron> Elika: You could choose not to consume height but still draw.
15:36:16 <dbaron> David: Drawing when you're not consuming height is a problem for background images
15:37:27 <anne> anne has left #css
15:37:42 <dbaron> David: Drawing backgrounds of some elements but not others also seems like a problem, especially with float case.
15:38:13 <dbaron> Jonas: I think you should keep drawing borders and background to the bottom.
15:38:33 <dbaron> Jonas: And repeat the part of the background from the break point.
15:39:00 <dbaron> David: That's inconsistent with inlines, where we stop borders and background before the end of the line.
15:39:41 <smedero> smedero has joined #CSS
15:40:02 <dbaron> Jonas: inlines look weird
15:40:09 <dbaron> David: they look weird with borders, fine with backgrounds
15:40:58 <dbaron> Peter: split border isn't weird-- it tells you that it continues on
15:42:05 <dbaron> Peter: I think it's weirder to have background/border continue on in empty area.
15:42:15 <dbaron> Elika: So it sounds like we can at least resolve that computed height isn't consumed.
15:42:31 <dbaron> RESOLVED: Computed height is not consumed by the height between the break and the bottom of the page.
15:47:04 <dbaron> Alex draws case where there's a float inside a fixed height container, and the float has an earlier split
15:47:43 <dbaron> David: I think having the float overflow in that case is not as bad as having the simpler case overflow because we do consume height.
15:49:05 <dbaron> (Note that we didn't resolve whether there's background or border drawn in the gap.)
15:50:41 <dbaron> Elika draws another case, which doesn't convince anyone else that it's another bad case.
15:51:30 <dbaron> Implementations should try to avoid creating overflow when there wouldn't be overflow when unpaginated (or something like that).
15:51:46 <dbaron> RESOLVED: Implementations should try to avoid creating overflow when there wouldn't be overflow when unpaginated (or something like that).
15:54:47 <fantasai> ACTION: fantasai write double-cascade proposal for ::selection
15:54:47 <trackbot> Created ACTION-115 - Write double-cascade proposal for ::selection [on Elika Etemad - due 2008-10-28].
15:58:39 <dbaron> DONE
16:15:39 <plinss_> plinss_ has joined #css
17:22:10 <dbaron> dbaron has joined #css
18:46:48 <melinda> melinda has joined #CSS
19:52:44 <arronei> arronei has joined #CSS
20:10:49 <anthony> anthony has joined #css
20:14:49 <anthony> anthony has joined #css
20:38:30 <plinss_> plinss_ has joined #css