/irc-logs / w3c / #css / 2008-10-21 / end

Options:

# Session Start: Tue Oct 21 00:00:00 2008
# Session Ident: #css
# [00:24] * Quits: anne (annevk@81.253.7.27) (Ping timeout)
# [01:51] * Joins: Arron (arronei@131.107.0.106)
# [01:52] * Quits: arronei (arronei@131.107.0.106) (Ping timeout)
# [02:08] * Quits: Arron (arronei@131.107.0.106) (Ping timeout)
# [02:08] * Joins: arronei (arronei@131.107.0.104)
# [02:21] * Joins: Arron (arronei@131.107.0.104)
# [02:22] * Quits: arronei (arronei@131.107.0.104) (Ping timeout)
# [02:36] * Joins: arronei (arronei@131.107.0.104)
# [02:37] * Quits: Arron (arronei@131.107.0.104) (Ping timeout)
# [02:45] * Joins: Arron (arronei@131.107.0.101)
# [02:45] * Quits: arronei (arronei@131.107.0.104) (Ping timeout)
# [02:48] * Joins: arronei (arronei@131.107.0.101)
# [02:48] * Quits: Arron (arronei@131.107.0.101) (Ping timeout)
# [02:57] * Joins: Arron (arronei@131.107.0.101)
# [02:58] * Quits: arronei (arronei@131.107.0.101) (Ping timeout)
# [03:05] * Joins: arronei (arronei@131.107.0.103)
# [03:05] * Quits: Arron (arronei@131.107.0.101) (Ping timeout)
# [03:08] * Quits: arronei (arronei@131.107.0.103) (Ping timeout)
# [03:09] * Joins: arronei (arronei@131.107.0.75)
# [03:22] * Quits: arronei (arronei@131.107.0.75) (Ping timeout)
# [03:23] * Joins: arronei (arronei@131.107.0.72)
# [03:48] * Quits: arronei (arronei@131.107.0.72) (Ping timeout)
# [03:48] * Joins: arronei (arronei@131.107.0.102)
# [05:21] * Joins: Arron (arronei@131.107.0.106)
# [05:21] * Quits: arronei (arronei@131.107.0.102) (Ping timeout)
# [05:30] * Quits: Arron (arronei@131.107.0.106) (Ping timeout)
# [05:30] * Joins: arronei (arronei@131.107.0.104)
# [05:37] * Joins: Arron (arronei@131.107.0.104)
# [05:38] * Quits: arronei (arronei@131.107.0.104) (Ping timeout)
# [05:55] * Quits: Arron (arronei@131.107.0.104) (Ping timeout)
# [05:56] * Joins: arronei (arronei@131.107.0.71)
# [06:07] * Joins: Arron (arronei@131.107.0.71)
# [06:08] * Quits: arronei (arronei@131.107.0.71) (Ping timeout)
# [07:43] * Joins: dbaron (dbaron@86.216.151.101)
# [07:51] * Joins: anne (annevk@81.253.60.178)
# [07:57] * Joins: plinss_ (plinss@81.253.61.215)
# [08:02] * Quits: plinss_ (plinss@81.253.61.215) (Quit: plinss_)
# [08:07] * Quits: dbaron (dbaron@86.216.151.101) (Ping timeout)
# [08:14] * Joins: arron_ (Arron@24.17.124.83)
# [08:34] * Joins: plinss_ (plinss@81.253.4.254)
# [09:03] * Joins: CWilso (cwilso@81.253.10.142)
# [09:05] * Quits: plinss_ (plinss@81.253.4.254) (Quit: plinss_)
# [09:07] * Parts: melinda (melinda.gr@67.142.45.126)
# [09:08] * Joins: melinda (melinda.gr@67.142.45.126)
# [09:09] * Joins: jdaggett (jdaggett@81.253.11.206)
# [09:12] * Joins: MoZ (chatzilla@81.253.11.59)
# [09:13] * Joins: alexmog (alexmog@81.253.58.152)
# [09:13] * Joins: glazou (daniel@81.253.12.146)
# [09:14] * Joins: shepazu (schepers@128.30.52.30)
# [09:14] * Joins: plinss_ (plinss@81.253.12.255)
# [09:17] * Joins: sylvaing (sylvaing@81.253.12.243)
# [09:21] * Quits: plinss_ (plinss@81.253.12.255) (Connection reset by peer)
# [09:21] * Quits: jdaggett (jdaggett@81.253.11.206) (Connection reset by peer)
# [09:22] * Joins: plinss_ (plinss@81.253.12.255)
# [09:22] * Joins: jdaggett (jdaggett@81.253.11.206)
# [09:30] * Joins: dbaron (dbaron@81.253.12.121)
# [09:34] * Quits: dbaron (dbaron@81.253.12.121) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [09:34] <sylvaing> ScribeNick:sylvaing
# [09:35] * Joins: dbaron (dbaron@81.253.12.121)
# [09:35] <sylvaing> ScribeNick: sylvaing
# [09:35] * dbaron RRSAgent, pointer?
# [09:35] * RRSAgent See http://www.w3.org/2008/10/21-css-irc#T07-28-48
# [09:35] <glazou> http://wiki.csswg.org/spec/css2.1#issue-60
# [09:35] <glazou> Topic is z-index in lev2
# [09:35] <glazou> http://dev.moonhenge.net/css21/spec/z-index/
# [09:36] <sylvaing> (second URL describes z-index issues)
# [09:36] <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
# [09:37] <sylvaing> Hixie: bottom line, one "'s" should be removed....
# [09:37] <sylvaing> Hixie: emailed author to suggest he sends testcase(s) to highlight actual issues
# [09:38] * glazou laughs and wants an armagnac
# [09:39] * sylvaing seconds morning armagnac motion
# [09:39] * CWilso looks up "armagnac"
# [09:40] <sylvaing> dbaron: a float can be relatively positioned so 2.10 may be relevant
# [09:41] * glazou CWilso think local and old mojito
# [09:43] <dbaron> We could add "non-positioned" in (3) (4) and (5) in the 7-point list in 9.9.1
# [09:44] <dbaron> and of course change "float's parent's stacking context" to "float's parent stacking context"
# [09:44] <Hixie> right
# [09:44] <dbaron> in 9.5
# [09:45] * CWilso wonders if it's just him, or if the network is extremely slow this morning.
# [09:45] <Hixie> it's slow
# [09:45] <Hixie> >500ms ping to the router in the hotel
# [09:45] <glazou> CWilso: it is
# [09:45] <sylvaing> plinss: i wonder if there is value in making the editorial changes in a future revision
# [09:47] <sylvaing> glazou: hixie, do you think we should take the changes ?
# [09:47] <sylvaing> hixie: changes are always normatively risky
# [09:48] <sylvaing> plinss: not sure there is css3 module where this change could be made
# [09:48] <sylvaing> plinss: not rejecting comments, but should reject them for CSS21 edits
# [09:51] <sylvaing> RESOLVED: two Appendix editorial changes accepted; no CSS21 updates; Hixie to email proposal author
# [09:52] <sylvaing> glazou: next topic : text layout/direction module
# [09:52] <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2008OctDec/0020.html
# [09:52] <sylvaing> bert: we need to place this module on the roadmap
# [09:52] <arron_> Hixie, Please remind the proposal author to create test cases.
# [09:53] <sylvaing> fantasai wonders if it needs to be split up
# [09:53] <sylvaing> alexmog points out dependency between box model and direction
# [09:53] <Hixie> arron_: did that in my first e-mail
# [09:57] <sylvaing> fantasai, alexmog, bert: line grid will move out of text layout to a separate module
# [09:57] <sylvaing> bert: does name of module remain text layout ?
# [09:58] <sylvaing> fantasai: yes, that makes sense
# [09:58] <sylvaing> alexmog: deadline to make this happen ?
# [09:59] <sylvaing> fantasai, bert, alexmog : first public working draft by end of year
# [10:02] <sylvaing> RESOLVED: FPWD of text layout module end of year, alexmog/salonir/fantasai editors; line grid module moves to new editor's draft
# [10:02] <sylvaing> glazou: priority of text layout ?
# [10:04] <sylvaing> RESOLVED: goal is CR during charter period
# [10:06] * Quits: plinss_ (plinss@81.253.12.255) (Connection reset by peer)
# [10:06] * Joins: plinss_ (plinss@81.253.12.255)
# [10:06] * Quits: CWilso (cwilso@81.253.10.142) (Ping timeout)
# [10:06] <sylvaing> glazou: topic is closed
# [10:07] * Quits: jdaggett (jdaggett@81.253.11.206) (Connection reset by peer)
# [10:07] * Joins: jdaggett_ (jdaggett@81.253.11.206)
# [10:07] <sylvaing> glazou: we are left with paged media issues we need to address in the afternoon so melinda can attend
# [10:08] <sylvaing> glazou: next topic is attribute selection
# [10:08] <sylvaing> glazou: this is about selecting the empty string with an attribute selector
# [10:09] <sylvaing> glazou: previous f2f said that the following matches nothing : P[foo$=""]
# [10:09] * Joins: George (opera@213.236.208.22)
# [10:09] <sylvaing> glazou: but P:not(foo$="") matches everything
# [10:10] <sylvaing> glazou: potential for browser hack
# [10:10] <sylvaing> glazou: this is true for all attribute selectors; regular = is fine
# [10:10] * Joins: nickshanks (nickshanks@88.217.192.121)
# [10:11] <sylvaing> glazou: this should be invalid
# [10:11] <sylvaing> dbaron: I'm not sure this is a good reason to make this invalid
# [10:12] <sylvaing> (good reason being second selector was not sensical)
# [10:14] * Joins: CWilso (cwilso@81.253.10.142)
# [10:14] <sylvaing> glazou: this is because the empty string is always a substring of any non-empty string
# [10:19] <sylvaing> dbaron, fantasai, glazou discuss previous decisions on the matter and mozilla changes
# [10:20] <sylvaing> glazou proposes that $="", *="" and ^="" never match
# [10:21] <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.
# [10:21] <fantasai> dbaron, what would be the one tiny spec clarification for interop?
# [10:21] <dbaron> fantasai, it would have been saying *="" always matched when the attribute was present
# [10:22] <fantasai> what about the others?
# [10:22] <dbaron> fantasai, I think it was already clear for the others.
# [10:22] <fantasai> $=?
# [10:22] <fantasai> ~=?
# [10:22] <dbaron> ~= is entirely separate; I think it was clear for $= and ^=
# [10:22] <sylvaing> sylvaing, plinss, glazou: empty string could only match an attribute value set to the empty string
# [10:23] * Quits: CWilso (cwilso@81.253.10.142) (Ping timeout)
# [10:23] <sylvaing> fantasai: today, we have interop between slightly older versions of firefox, opera and safari
# [10:24] <fantasai> although iirc safari did something weird on one of the cases
# [10:24] <glazou> http://www.disruptive-innovations.com/zoo/css3tests/selectorTest.html#target
# [10:25] <sylvaing> glazou: no decision since no consensus
# [10:25] <sylvaing> plinss: what do we need to do to come to a decision ?
# [10:26] <sylvaing> glazou: we need to test current implementations
# [10:26] <sylvaing> alexmog, plinss: we are not far from a decision since no one is opposed to either decision
# [10:27] <sylvaing> plinss: we have consensus that no one has a clue
# [10:27] <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
# [10:28] <fantasai> http://tinyurl.com/5qluy2
# [10:31] <sylvaing> dbaron: the test does not capture the change made in firefox 3 so not conclusive
# [10:33] <sylvaing> fantasai: logic of the change was that there was interop on ~= so we made everything else work based on tilde's semantics
# [10:33] <sylvaing> dbaron: but it looks like we do not interop on tilde...
# [10:33] <dbaron> s/do not/did not/
# [10:33] <dbaron> (because Safari behaved differently for ~=)
# [10:36] <fantasai> http://pastebin.mozilla.org/558307
# [10:36] * Quits: jdaggett_ (jdaggett@81.253.11.206) (Connection reset by peer)
# [10:36] * Joins: jdaggett (jdaggett@81.253.11.206)
# [10:37] <sylvaing> no decision on this topic
# [10:49] <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
# [10:52] * Quits: plinss_ (plinss@81.253.12.255) (Connection reset by peer)
# [10:53] * Joins: plinss_ (plinss@81.253.12.255)
# [10:54] * Quits: sylvaing (sylvaing@81.253.12.243) (Ping timeout)
# [11:16] * Joins: plinss__ (plinss@81.253.12.255)
# [11:16] * Quits: plinss_ (plinss@81.253.12.255) (Connection reset by peer)
# [11:16] * Quits: jdaggett (jdaggett@81.253.11.206) (Connection reset by peer)
# [11:16] * Joins: jdaggett (jdaggett@81.253.11.206)
# [11:17] * Joins: jdaggett_ (jdaggett@81.253.11.206)
# [11:17] * Quits: jdaggett (jdaggett@81.253.11.206) (Connection reset by peer)
# [11:23] * Joins: sylvaing (sylvaing@81.253.32.32)
# [11:26] * Quits: MoZ (chatzilla@81.253.11.59) (Ping timeout)
# [11:27] <anne> CSS haz a <br>?
# [11:27] <sylvaing> ScribeNick: sylvaing
# [11:27] <anne> ah, had :)
# [11:27] <sylvaing> fantasai presents CSS variables/constants proposal
# [11:27] <fantasai> http://fantasai.inkedblade.net/style/specs/constants/
# [11:27] <fantasai> s/proposal/counter-proposal/
# [11:28] <sylvaing> the counter-proposal defines parse-time constants
# [11:30] <sylvaing> for example, one can separate the layout from the colors across site pages e.g. a site like launchpad.net
# [11:31] <sylvaing> fantasai reviews implementation constraints
# [11:32] <sylvaing> fantasai: three type of constants: value constants, styleset constants and selector constants
# [11:32] <sylvaing> defined with @define block
# [11:32] * Quits: shepazu (schepers@128.30.52.30) (Quit: Core Breach)
# [11:32] <sylvaing> fantasai reviews examples
# [11:32] * Joins: shepazu (schepers@128.30.52.30)
# [11:34] <sylvaing> fantasai: selector constant must be a valid selector but cannot comma-separated grouping syntax since the constant may be part of a selector
# [11:35] <sylvaing> fantasai discusses scoping; declarations in-scope from point of declaration until overriden; not changed, just overriden
# [11:36] <sylvaing> fantasai: constants do not cross @import boundaries without a special @import keyword
# [11:38] <sylvaing> discussion of scoping and asynchronous stylesheet parsing
# [11:39] <sylvaing> @import keywords are pull, push and sync
# [11:39] <sylvaing> glazou: why not allow two keywords so "@import push pull" equivalent to "@import sync" ?
# [11:41] <sylvaing> alexmog: do other languages have this ability to control scope ?
# [11:41] <sylvaing> jdaggett_: don't compound docs have this ?
# [11:42] <sylvaing> fantasai: I picked a constant expansion character, no personal preference
# [11:43] <sylvaing> glazou: if an expanded selector constant is invalid what happens ?
# [11:43] * Joins: MoZ (chatzilla@81.253.35.22)
# [11:43] <sylvaing> fantasai: if the constant hasn't been declared, it doesn't get expanded; in this case, the selector is invalid
# [11:44] <sylvaing> jdagett: why we need selector constants ?
# [11:44] <sylvaing> glazou, plinss: users ask for it
# [11:44] <sylvaing> jdaggett: use-case ?
# [11:45] <sylvaing> glazou, plinss, fantasai: complex selectors e.g. styling content nested inside a cell
# [11:47] <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
# [11:47] <sylvaing> glazou: you especially want to preserve the rule when the constant turns out to be invalid
# [11:48] <sylvaing> alexmog, fantasai, plinss: you have this problem with invalid CSS anyway
# [11:48] <fantasai> plinss: and comments, etc.
# [11:49] <sylvaing> glazou: in an editor manipulating stylesheets, you need to preserve the @define blocks
# [11:51] <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 ?
# [11:54] <sylvaing> glazou: not sure pull/push/sync are useful
# [11:55] <sylvaing> dbaron, plinss: for constants, it would make sense for the first constant definition to 'win'
# [11:56] <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
# [11:57] <glazou> howcome : don't use the $ sign because the dollar is so weak these days
# [11:57] <dbaron> (discusion of $ or € :-)
# [11:58] <sylvaing> fantasai: processing model is parse time, after tokenization
# [12:00] <sylvaing> alexmog questions the priority of selector constants
# [12:01] <sylvaing> glazou: values is the #1 use-case but selector is also a common request
# [12:02] <sylvaing> glazou: making them global means you'd have to parse everything (even two passes ?)
# [12:04] <sylvaing> fantasai reviews name-value table handling depending on @import statement
# [12:08] <dbaron> It seems like this isn't significantly simpler.
# [12:08] <sylvaing> fantasai reviews an example in the document
# [12:10] <sylvaing> alexmog: first one wins would make global confusing as a local definition could be ignored due to one you cannot see
# [12:10] <sylvaing> s/global/global scope
# [12:10] * Bert is reminded of Gnu make.... how many kinds of assignments can you come up with?
# [12:15] <sylvaing> hakkon: I don't want to have things changing after parse time
# [12:15] <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
# [12:16] <sylvaing> hakkon: you'd have to reimplement a parser
# [12:19] * Bert wonders if IDEs for C also rely on the C DOM to edit C files. (Sorry, that's mean.)
# [12:21] <fantasai> background: #FFDDDD;
# [12:21] <fantasai> background: rgba(100%, 0, 0, 0.5);
# [12:21] <fantasai> background: url(image1.png), url(image2.png);
# [12:21] <fantasai> your editor will only see the middle declaration, the other two will get lost
# [12:22] <fantasai> the problem with information getting lost in the CSSOM already exists
# [12:22] <fantasai> howcome: I think it would be a reasonable extention to the CSSOM to allow access to the strings
# [12:22] <fantasai> howcome: I've got very strong feedback from my developers that they want this at parse time only
# [12:23] <sylvaing> plinss: shouldn't a style attribute be able to refer to a constant ?
# [12:24] <fantasai> glazou: I understand perfectly the users side of this
# [12:25] <fantasai> glazou: but it still seems very hard for implementors
# [12:25] <sylvaing> fantasai: there are also use-cases that are not covered
# [12:26] <fantasai> by the variables proposal
# [12:27] * Quits: MoZ (chatzilla@81.253.35.22) (Ping timeout)
# [12:31] <sylvaing> fantasai: spec is currently too technical to be presented; it needs examples and use-cases for a web author audience
# [12:32] <sylvaing> dbaron: both proposals - variables and constants - seem like a lot of work
# [12:32] <sylvaing> plinss: which one do you prefer ? opera favors a parse-time solution. would you agree ?
# [12:33] <sylvaing> glazou: parse-time solutions are browser-only; harmful to editing tools
# [12:33] <sylvaing> plinss: would distinction between parse-time vs. runtime affect your decision ?
# [12:33] <sylvaing> dbaron: I don't think so
# [12:33] <sylvaing> alexmog: agree it's not parse vs. runtime but completeness of the solution.
# [12:34] <sylvaing> alexmog: parse-time only is different from everything else we have; especially one without an object model.
# [12:35] <sylvaing> glazou: this is a pragmatic position : do not restrict the feature for the user, it's an implementor issue
# [12:36] <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
# [12:37] <sylvaing> howcome: this is simple. we shouldn't have an object model
# [12:37] <sylvaing> dbaron: i worry about solutions of this kind since we'll have to come back and change it later
# [12:39] * glazou STRONGLY disagrees with howcome here
# [12:39] <sylvaing> dbaron worries about loading consideration (sync cost)
# [12:40] * glazou thinks howcome again thinks browser-only, a W3C disease that has been plaguing W3C for more than ten years
# [12:41] <sylvaing> plinss: other feedback is that if they're defined inside an @media block they shouldn't propagate outside
# [12:41] <sylvaing> fantasai: but i might to have different declarations per media but the same value
# [12:41] * Quits: jdaggett_ (jdaggett@81.253.11.206) (Quit: jdaggett_)
# [12:42] * Quits: dbaron (dbaron@81.253.12.121) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [12:42] * Quits: sylvaing (sylvaing@81.253.32.32) (Quit: sylvaing)
# [12:43] <plinss__> http://www.webmonkey.com/blog/What_s_On_Your_CSS_Wishlist_
# [12:43] <plinss__> <br type="lunch">
# [12:44] * Quits: glazou (daniel@81.253.12.146) (Ping timeout)
# [12:45] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
# [13:24] * Quits: anne (annevk@81.253.60.178) (Ping timeout)
# [13:43] * Quits: alexmog (alexmog@81.253.58.152) (Ping timeout)
# [13:48] * Joins: anne (annevk@81.253.60.178)
# [13:50] * Quits: anne (annevk@81.253.60.178) (Connection reset by peer)
# [13:50] * Joins: anne (annevk@81.253.60.178)
# [13:51] * Quits: anne (annevk@81.253.60.178) (Client exited)
# [13:51] * Joins: anne (annevk@81.253.60.178)
# [13:53] * Joins: glazou (daniel@81.253.50.197)
# [14:08] * Joins: shepazu (schepers@128.30.52.30)
# [14:13] * Joins: alexmog (alexmog@81.253.58.152)
# [14:13] * Joins: jdaggett (jdaggett@81.253.54.155)
# [14:18] * Quits: arron_ (Arron@24.17.124.83) (Quit: arron_)
# [14:21] <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)
# [14:22] <fantasai> Bert: or requiring that the non-fallback color be specified in the shorthand and forbidding background-size from appearing immediately after the color
# [14:24] * anne is now known as CharlesMcCathieNe
# [14:25] * CharlesMcCathieNe is now known as anne
# [14:25] <Bert> So in either case, the non-fallback color becomes required.
# [14:26] <fantasai> hm, yeah
# [14:26] * fantasai doesn't have any other brilliant ideas, maybe someone else does
# [14:28] <Bert> It's not necessarily a problem. You may have to use 'transparent' a bit more often.
# [14:30] * Joins: dbaron (dbaron@81.253.57.122)
# [14:32] * Joins: MoZ (chatzilla@81.253.57.141)
# [14:44] <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.
# [14:45] <Bert> PPlinns is OK with that, he says.
# [14:45] <Bert> s.PPlins/Plins/
# [14:45] <fantasai> my only concern is readability/understandability of the style sheet
# [14:45] <plinss__> s/Plins/plinss/
# [14:45] <fantasai> other than that there is no strong reason for the /
# [14:46] * dbaron wonders if fantasai is in JLTF
# [14:46] * fantasai yes
# [14:47] <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
# [14:48] <plinss__> I actually think it would be more understandable to have the fallback color as a separate property
# [14:48] <fantasai> no, you really really want it to be reset together with background-color
# [14:49] <fantasai> imagine I set background-color: transparent; background-fallback: red;
# [14:49] <fantasai> then later in the cascade I have background-color: white;
# [14:49] <fantasai> That background-color: white must reset the fallback as well
# [14:49] <fantasai> otherwise I get background-color: white; background-fallback: red;
# [14:49] <fantasai> which is totally not what anyone is expecting
# [14:49] <plinss__> ok
# [14:52] <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?
# [14:52] <plinss__> if the later rule really wanted a white background, you'd have to set the background-image to none as well...
# [14:52] <fantasai> hmmm perhaps
# [14:53] <plinss__> which would also preclude the use of the fallback color
# [14:53] * Quits: MoZ (chatzilla@81.253.57.141) (Ping timeout)
# [14:53] <Bert> There is currently only a fallback color for the last image.
# [14:59] <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.
# [15:01] * Joins: sylvaing (sylvaing@81.253.54.179)
# [15:01] <Bert> Two slashes (//) instead of one?
# [15:04] <fantasai> oww
# [15:04] <fantasai> maybe for the background-size, if you must
# [15:04] <dbaron> some implementations treat // as comments, I think
# [15:04] <fantasai> lol
# [15:16] * Quits: sylvaing (sylvaing@81.253.54.179) (Ping timeout)
# [15:16] * Joins: glazou__ (daniel@81.253.50.197)
# [15:16] * Quits: glazou (daniel@81.253.50.197) (Connection reset by peer)
# [15:16] * glazou__ is now known as glazou
# [15:16] * Quits: plinss__ (plinss@81.253.12.255) (Ping timeout)
# [15:19] * Joins: plinss_ (plinss@81.253.12.255)
# [15:19] * fantasai wonders if CSSWG has started up again yet, nobody seems to be taking minutes
# [15:20] <glazou> fantasai: not having critical mass here ...
# [15:23] * Joins: sylvaing (sylvaing@81.253.0.195)
# [15:26] * Joins: CWilso (cwilso@81.253.2.26)
# [15:27] * Joins: Bert_ (bbos@mcclure.w3.org)
# [15:28] * Quits: Bert_ (bbos@mcclure.w3.org) (Quit: leaving)
# [15:29] * Joins: Bert_ (bbos@mcclure.w3.org)
# [15:29] <dbaron> ScribeNick: dbaron
# [15:29] * Quits: Bert_ (bbos@mcclure.w3.org) (Quit: leaving)
# [15:29] <dbaron> Topic: Paged Media
# [15:30] * dbaron points melinda to the topic, in case she's interested
# [15:30] <dbaron> Elika: 'em' on font-size on root element
# [15:32] <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
# [15:32] <dbaron> Elika: Should margin boxes and page borders and backgrounds be printed on blank pages?
# [15:32] <dbaron> Elika: We propose we just print them, but adding :blank that would let you specify visibility:hidden
# [15:33] <dbaron> Elika: Technical documents tend to print them, novels tend not to.
# [15:33] <dbaron> (adding in level 4)
# [15:33] * Joins: Bert_ (bbos@mcclure.w3.org)
# [15:33] * Quits: Bert_ (bbos@mcclure.w3.org) (Quit: leaving)
# [15:33] <dbaron> Haakon: Should I put in in gcpm?
# [15:34] <dbaron> Elika: I also have it on the wiki for the level 4 draft.
# [15:34] <dbaron> Haakon: We could make gcpm the level 4 draft.
# [15:34] <dbaron> Elika: part of it
# [15:34] <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.
# [15:34] <fantasai> RESOLVED: headers, footers, borders, etc print on blank pages, add :blank selector later
# [15:34] * Quits: Bert (bbos@mcclure.w3.org) (Ping timeout)
# [15:35] <fantasai> http://www.savagecreek.net/CSS/Page/css3_paged_media_lc2_issues_list.htm
# [15:35] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Oct/0233.html
# [15:35] <dbaron> (previous was issue 8)
# [15:35] * CWilso hmm. WebApps done, guess I'll wander back up to CSS.
# [15:35] <dbaron> Elika: Issue 3: We don't define what happens when the width of the page changes mid-document.
# [15:36] <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.
# [15:36] <dbaron> Elika: ... if they split across pages
# [15:37] <dbaron> Alex and Elika discuss some possibilities
# [15:37] * Joins: ed (ed@81.253.53.125)
# [15:38] * glazou wonders who is ed
# [15:38] * ed is teh ed :)
# [15:38] <glazou> lol
# [15:38] <dbaron> Alex: How important is it to reflow things into irregular-shaped pages, as opposed to ensuring that a container keeps constant width?
# [15:39] <dbaron> Elika: If you have that rule, the root element stays the same width throughout the document.
# [15:39] <dbaron> Alex: I like this rule applied to body but not to a paragraph.
# [15:40] <dbaron> Alex: Things with BFC should have an exception.
# [15:40] <dbaron> Alex: But even without BFC, things can have position:relative, be a containing block for absolutely positioned elements, etc.
# [15:42] * Quits: ed (ed@81.253.53.125) (Quit: ed)
# [15:42] <dbaron> Alex: I'm going to claim no use case for continuous flow of text across irregular pages.
# [15:42] <dbaron> Peter: Or almost none.
# [15:42] * Joins: Bert (bbos@mcclure.w3.org)
# [15:43] <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
# [15:44] <dbaron> Haakon and Elika discuss a bug in Opera.
# [15:44] * Joins: Bert_ (bbos@mcclure.w3.org)
# [15:45] * Quits: Bert_ (bbos@mcclure.w3.org) (Quit: leaving)
# [15:45] <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.
# [15:45] <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.
# [15:45] * Joins: mollydotcom (mollyholzs@70.176.234.187)
# [15:46] <dbaron> Elika: OK, non-BFC, in normal flow, and requirement is a SHOULD.
# [15:47] <dbaron> Alex: multiple bodies would make this easier...
# [15:48] <dbaron> Haakon: Can an element start on one type of page and go to another?
# [15:48] <dbaron> Elika: Certainly.
# [15:49] * Joins: ed (ed@81.253.4.205)
# [15:49] <dbaron> (David, Haakon, and Alex discuss DOM, etc.)
# [15:51] <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
# [15:51] <dbaron> Elika: Next thing is counters scoping.
# [15:51] <dbaron> Elika: Melinda and Haakon both want scoping of counter to be shared between document and page context.
# [15:51] <dbaron> Elika: So if I have a counter in the document I can print it in the margin box
# [15:52] <dbaron> Elika: That's already defined to work, but the reverse doesn't work currently.
# [15:52] <dbaron> Haakon: Just have one namespace.
# [15:53] <fantasai> dbaron: There's three things you can do with counters. You can use them, increment them, and reset them
# [15:53] <fantasai> dbaron: Using and incrementing you just need to define the order
# [15:53] <fantasai> dbaron: reset is a problem
# [15:56] <fantasai> fantasai: what would reset on an @page mean? reset at the start of the document? what about on a named page?
# [15:56] <fantasai> fantasai: reset on the first named page? every named page?
# [15:57] <fantasai> howcome: every named page
# [15:57] <fantasai> fantasai: how is that useful?
# [15:57] <fantasai> peter: footnotes
# [15:58] <fantasai> dbaron talks very fast and very detailed about counters
# [15:59] <fantasai> fantasai, howcome: what if counter-reset on @page doesn't create a scope?
# [16:00] <fantasai> dbaron: This ties into a counter-set property that sets the value without introducing a new scope
# [16:00] <fantasai> dbaron: I think CSS counters are too limited to do the headers that we want
# [16:00] <fantasai> dbaron: or the headers in html5
# [16:02] <fantasai> BREAK
# [16:05] <mollydotcom> do I get a break too?
# [16:08] * mollydotcom wants an espresso and some pamplemousse juice!
# [16:11] * Joins: MoZ (chatzilla@81.253.7.146)
# [16:17] <glazou> mollydotcom: and pear pie
# [16:17] <mollydotcom> oooh, pear pie?
# [16:17] <glazou> apricot pie too
# [16:17] <mollydotcom> lovely
# [16:17] <glazou> yep
# [16:18] <glazou> there's enough pear pie for 25 persons and we're 236 :)
# [16:18] <glazou> lovely eh ?
# [16:18] <mollydotcom> someone needed a counter (badumpump)
# [16:19] <CWilso> KSSSH!
# [16:19] <CWilso> @glazou I hereby give you permission to eat my 25/236th of the pear pie
# [16:19] * Quits: sylvaing (sylvaing@81.253.0.195) (Ping timeout)
# [16:20] * Quits: MoZ (chatzilla@81.253.7.146) (Ping timeout)
# [16:21] * mollydotcom thinks CWilso is a very generous fellow but suspects glazou found some pie ;)
# [16:23] * CWilso what can I say, i'm a giver.
# [16:24] * Joins: Lachy (Lachlan@81.253.10.193)
# [16:24] <fantasai> dbaron: I think that if we a) said that a counter-reset on the page context didn't make a new scope and
# [16:25] <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
# [16:25] <fantasai> dbaron: ...
# [16:27] <fantasai> fantasai: the example in http://dev.w3.org/csswg/css3-page/#page-based-counters should just work
# [16:27] * Joins: sylvaing (sylvaing@81.253.10.74)
# [16:29] <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.
# [16:29] * Quits: ed (ed@81.253.4.205) (Connection reset by peer)
# [16:29] * glazou and peter think all other WG meetings are probably over :-)
# [16:29] * Joins: ed (ed@81.253.4.205)
# [16:29] * CWilso whyever would you think that?
# [16:29] <jdaggett> jltf continues!!
# [16:30] <fantasai> fantasai: Would @page { counter-increment: foo; } create a counter scope at the root?
# [16:31] <fantasai> dbaron: I'd have to check old emails to see if that works
# [16:32] <fantasai> http://www.w3.org/TR/CSS21/generate.html#scope
# [16:33] <fantasai> dbaron: The problem with that was with nested counters
# [16:33] <fantasai> dbaron: I remember what the problem was
# [16:33] <fantasai> dbaron: Say you're using ul, li with the appropriate resets and increments
# [16:33] <fantasai> dbaron: and your ::marker pseudo uses a counters() expression that does dotted numbering
# [16:34] <fantasai> dbaron: this is all happy as far s incremental rendering goes
# [16:34] <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
# [16:39] <fantasai> fantasai: so what if we define any counter-resets and increments in the page context not to create a scope
# [16:39] <fantasai> fantasai: in the document
# [16:39] <fantasai> fantasai: but all counter-reset and increment declarations create a scope on the root element
# [16:41] <fantasai> Bert asks about page counter increments
# [16:41] <fantasai> @page { counter-increment: page; }
# [16:41] <fantasai> _@page {counter-increment: foo; }
# [16:41] <fantasai> @page { counter-increment: page 0; }
# [16:42] <fantasai> agreement that it doesn't make sense to put any of this in the margin boxes
# [16:43] <fantasai> @page foo { counter-increment: bar; }
# [16:43] <fantasai> @page { @top-left { content: counter(bar); } }
# [16:44] <fantasai> fantasai: so does bar get created at the root, even if it is never used? or does the increment get ignored?
# [16:46] <fantasai> my proposal is to only create scopes on the root element for any counters referenced on the first page of the document
# [16:47] <fantasai> so if I want to increment bar in @page foo, then I need to declare it
# [16:47] <fantasai> otherwise, we have to gather all declarations for @page and create scopes for any counter-* counters that have been delcared
# [16:47] <fantasai> even if that declaration never gets used
# [16:48] <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
# [16:48] * trackbot noticed an ACTION. Trying to create it.
# [16:48] * RRSAgent records action 1
# [16:48] <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].
# [16:48] <dbaron> Elika: Should the 'page' property be inherited?
# [16:48] <dbaron> Hakon: No.
# [16:48] <dbaron> Elika: HP has a bunch of implementations that already inherit it.
# [16:49] <dbaron> Elika: It was difficult to get these other implementations to not inherit page-break-inside; we don't want to push it further.
# [16:49] <dbaron> Haakon: I think we fixed things for non-inherited 'page' so that all the use cases work the same way.
# [16:50] <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.
# [16:50] <dbaron> Hakon: [shows css3-gcpm dev.w3.org draft]
# [16:50] <dbaron> Hakon: I think this solution addresses all the use cases.
# [16:50] <dbaron> Elika: What about existing content?
# [16:51] <dbaron> Hakon: We're making it into a list of properties, which is why we need it to be not inherited.
# [16:51] <dbaron> Hakon: I think when it's not a list of values, it doesn't matter.
# [16:51] <dbaron> Elika: Do we want it to be a list?
# [16:51] <dbaron> Hakon: We worked hard to reach this consensus; print implementors are in.
# [16:52] <dbaron> Elika: The behavior of 'auto' inside an element that has a named page is different.
# [16:54] <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.
# [16:55] <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.
# [16:56] <dbaron> Elika: Another proposal that would preserve inheritance of 'page' would be:
# [16:57] * Parts: anne (annevk@81.253.60.178)
# [16:57] <dbaron> Elika: In level 4 or gcpm, page becomes a shorthand for page-name (inherited), page-foo (non-inherited)
# [16:57] <dbaron> Elika: where page-foo takes value 'auto', 'trigger-first', 'continue-onto-next-page', etc.
# [16:58] * Joins: anne (annevk@81.253.60.178)
# [16:58] <dbaron> Hakon: I'd rather start from the proposal we've discussed for a long time than a brand new proposal.
# [16:59] <dbaron> Elika: There's a backwards-compat issue, and an interacting with other standards orgs issue.
# [16:59] <dbaron> Hakon: Do you have a code example to show the backwards-compat issue?
# [17:00] <dbaron> Elika: The content that works differently is <div style="page:foo"><div style="page:auto"></div></div> which is probably not very common.
# [17:00] <dbaron> Elika: The issue HP has is about asking implementations to change.
# [17:00] <dbaron> Hakon: Why don't we take this offline?
# [17:01] <dbaron> Hakon: They'd have to change when they go to the list value.
# [17:03] <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.
# [17:04] <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?
# [17:04] <dbaron> Hakon: Good question.
# [17:04] <dbaron> Bert: I think you strike from the page list even for empty pages.
# [17:05] <dbaron> Elika: I think you don't.
# [17:07] <dbaron> Peter: Pages that matter are often ones going straight from device to printer, not on the Web.
# [17:07] <dbaron> Hakon: Change in gcpm rather than css3-page?
# [17:07] <dbaron> Elika: We should go with what we ultimately want to do now.
# [17:07] * Joins: hendry (hendry@89.16.172.32)
# [17:08] <dbaron> Peter: Hard to do a straw poll given the implementors here, and those not here.
# [17:09] <dbaron> Hakon: I don't feel like forcing printer manufacturers to change their hardware.
# [17:09] <dbaron> Elika: If we're going to do this, we should definitely put in warnings, etc.
# [17:09] <dbaron> Hakon, Elika, Peter: Both should be normatively compliant.
# [17:09] <dbaron> Peter: I think I'm ok with that given that the 2 uses may never see each other.
# [17:09] <dbaron> Haakon: Good, we have consensus.
# [17:09] <dbaron> Peter: Well, provisional, depending on Melinda's reaction.
# [17:10] <dbaron> Topic: overflow:scroll in paged media
# [17:10] <dbaron> Alex: (draws)
# [17:11] <dbaron> Alex: For overflow:scroll, should we render scrollbar on paper or drop it?
# [17:12] <dbaron> Alex: With overflow:auto, and something doesn't fit on page, we don't know if element will fit or not.
# [17:12] <dbaron> Alex: By the second page, we know whether the screen presentation would have a scrollbar.
# [17:12] <dbaron> David: last page
# [17:12] <dbaron> Alex: In theory, we could go back and re-render previous page.
# [17:12] <dbaron> Alex: Current behavior differs across implementations
# [17:13] <dbaron> Alex: Printing in Firefox never renders a scrollbar for overflow:auto
# [17:13] * Parts: George (opera@213.236.208.22)
# [17:13] <dbaron> Alex: Printing in Opera always renders scrollbar for first page, not sure what it does for last page.
# [17:13] <dbaron> Alex: Printing in Safari does something else.
# [17:14] <dbaron> Jonas: You don't know what size to make the scrollbar thumb.
# [17:15] <dbaron> Alex: There are two things I really don't want:
# [17:15] * Quits: ed (ed@81.253.4.205) (Connection reset by peer)
# [17:15] <dbaron> Alex: (1) I don't want to have to go back to the previous page and recalculate it.
# [17:15] * Joins: ed (ed@81.253.4.205)
# [17:15] <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)
# [17:15] <dbaron> Alex: I favor Firefox behavior; there isn't much use for the scrollbar on paper.
# [17:16] <dbaron> David: Do we print scrollbars for overflow:scroll?
# [17:16] <dbaron> Alex: Yes, but never for 'aut'.
# [17:16] <dbaron> s/aut/auto/
# [17:16] * Quits: ed (ed@81.253.4.205) (Connection reset by peer)
# [17:17] * Joins: ed (ed@81.253.4.205)
# [17:17] <dbaron> Alex: I think Safari doesn't paginate the element.
# [17:18] * Joins: plinss__ (plinss@81.253.12.255)
# [17:18] * Quits: plinss_ (plinss@81.253.12.255) (Connection reset by peer)
# [17:18] <dbaron> David: Seems like printing scrollbars on paper is a bad idea...
# [17:18] <dbaron> (Hakon and Alex test something in Opera)
# [17:19] * mollydotcom is now known as mollydotcom_afk
# [17:19] <dbaron> Alex: My proposal is that when printing an element with overflow:auto, it is ok to never print scrollbars.
# [17:19] <dbaron> Hixie: That's already ok.
# [17:20] <dbaron> Alex: It's also ok to print scrollbars if UAs so desire.
# [17:20] <dbaron> Hixie: The spec also says you can use whatever scrolling mechanism you like.
# [17:20] * Quits: ed (ed@81.253.4.205) (Connection reset by peer)
# [17:21] * Joins: ed (ed@81.253.4.205)
# [17:23] <dbaron> Topic: Do elements with overflow:auto and overflow:scroll split when printed?
# [17:24] <dbaron> Alex: Seems ok to not print.
# [17:24] <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.
# [17:24] <dbaron> Elika: Seems like UA should be allowed to act as though it had height:auto
# [17:25] <dbaron> Peter: How would the UA know what content that's reasonable to do on and what it's not.
# [17:26] * Quits: ed (ed@81.253.4.205) (Connection reset by peer)
# [17:26] <dbaron> Peter: There is a class of users who want printing to yield a screen grab.
# [17:27] <dbaron> Jonas Sicking: It makes sense to show there is clipped content that would show on screen...
# [17:27] * Joins: ed (ed@81.253.4.205)
# [17:27] * Quits: mollydotcom_afk (mollyholzs@70.176.234.187) (Quit: Quitting!)
# [17:27] <dbaron> Peter: Printing a scrollbar does that.
# [17:27] <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.
# [17:27] <dbaron> Peter: That can be UA dependent.
# [17:28] <dbaron> Alex: There's always the option of a print style sheet.
# [17:28] <dbaron> Peter: Would be nice if overflow:auto could degrade into height:auto in print, but overflow:scroll doesn't.
# [17:28] <dbaron> Peter: but not sure if that really makes sense.
# [17:29] <dbaron> Alex: Use cases for overflow:auto always involve height not 'auto'.
# [17:29] * Quits: Lachy (Lachlan@81.253.10.193) (Quit: This computer has gone to sleep)
# [17:30] <dbaron> Alex: But rel pos could create scrollbars without height:auto.
# [17:31] <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.
# [17:31] * Quits: ed (ed@81.253.4.205) (Connection reset by peer)
# [17:32] * Joins: ed (ed@81.253.4.205)
# [17:33] <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.
# [17:34] <dbaron> RESOLVED: It is not required to make content that's not visible on screen visible when printing.
# [17:35] <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?
# [17:35] * glazou REMINDER 6:45pm in room Riviera C for Advisory Committee representatives, Chairs, AB, TAG, Offices staff and Team
# [17:35] <dbaron> Elika draws.
# [17:37] <dbaron> David: Also, do you draw the side borders along where you're skipping?
# [17:37] <dbaron> Alex: And does it count as part of the height of the body for something abs pos relative to body?
# [17:39] <dbaron> Bert, Peter, David agree that border and height stop 1em above the bottom of the page (element does not continue into gap)
# [17:39] <dbaron> Jonas: What about one of them being a float: two picees of text being uneven?
# [17:39] <dbaron> s/picees/pieces/
# [17:41] <dbaron> Elika: What about flowing text into the gap
# [17:41] <dbaron> Peter: If you don't let text flow under it, text should flow under the borders
# [17:42] <dbaron> Elika: You could choose not to consume height but still draw.
# [17:42] <dbaron> David: Drawing when you're not consuming height is a problem for background images
# [17:43] * Parts: anne (annevk@81.253.60.178)
# [17:44] <dbaron> David: Drawing backgrounds of some elements but not others also seems like a problem, especially with float case.
# [17:44] <dbaron> Jonas: I think you should keep drawing borders and background to the bottom.
# [17:44] <dbaron> Jonas: And repeat the part of the background from the break point.
# [17:45] <dbaron> David: That's inconsistent with inlines, where we stop borders and background before the end of the line.
# [17:46] * Joins: smedero (smedero@81.253.27.16)
# [17:46] <dbaron> Jonas: inlines look weird
# [17:46] <dbaron> David: they look weird with borders, fine with backgrounds
# [17:47] <dbaron> Peter: split border isn't weird-- it tells you that it continues on
# [17:48] <dbaron> Peter: I think it's weirder to have background/border continue on in empty area.
# [17:48] <dbaron> Elika: So it sounds like we can at least resolve that computed height isn't consumed.
# [17:48] * Quits: smedero (smedero@81.253.27.16) (Quit: smedero)
# [17:48] <dbaron> RESOLVED: Computed height is not consumed by the height between the break and the bottom of the page.
# [17:49] * Quits: jdaggett (jdaggett@81.253.54.155) (Quit: jdaggett)
# [17:53] <dbaron> Alex draws case where there's a float inside a fixed height container, and the float has an earlier split
# [17:54] <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.
# [17:55] <dbaron> (Note that we didn't resolve whether there's background or border drawn in the gap.)
# [17:57] <dbaron> Elika draws another case, which doesn't convince anyone else that it's another bad case.
# [17:57] <dbaron> Implementations should try to avoid creating overflow when there wouldn't be overflow when unpaginated (or something like that).
# [17:58] <dbaron> RESOLVED: Implementations should try to avoid creating overflow when there wouldn't be overflow when unpaginated (or something like that).
# [18:01] <fantasai> ACTION: fantasai write double-cascade proposal for ::selection
# [18:01] * trackbot noticed an ACTION. Trying to create it.
# [18:01] * RRSAgent records action 2
# [18:01] <trackbot> Created ACTION-115 - Write double-cascade proposal for ::selection [on Elika Etemad - due 2008-10-28].
# [18:05] <dbaron> DONE
# [18:06] * Quits: glazou (daniel@81.253.50.197) (Quit: glazou)
# [18:06] * Quits: sylvaing (sylvaing@81.253.10.74) (Ping timeout)
# [18:08] * Quits: plinss__ (plinss@81.253.12.255) (Quit: plinss__)
# [18:11] * Quits: CWilso (cwilso@81.253.2.26) (Ping timeout)
# [18:15] * Quits: dbaron (dbaron@81.253.57.122) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:22] * Joins: plinss_ (plinss@81.253.37.186)
# [18:50] * Quits: ed (ed@81.253.4.205) (Quit: ed)
# [19:06] * Quits: plinss_ (plinss@81.253.37.186) (Quit: plinss_)
# [19:17] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
# [19:28] * Joins: dbaron (dbaron@81.253.62.72)
# [20:13] * Quits: alexmog (alexmog@81.253.58.152) (Ping timeout)
# [20:22] * Quits: dbaron (dbaron@81.253.62.72) (Ping timeout)
# [20:41] * Quits: melinda (melinda.gr@67.142.45.126) (Connection reset by peer)
# [20:53] * Joins: melinda (melinda.gr@67.142.45.126)
# [21:53] * Quits: Arron (arronei@131.107.0.71) (Ping timeout)
# [21:59] * Joins: arronei (arronei@131.107.0.74)
# [22:16] * Quits: anthony (chatzilla@203.12.172.254) (Connection reset by peer)
# [22:17] * Joins: anthony (chatzilla@203.12.172.254)
# [22:18] * Quits: melinda (melinda.gr@67.142.45.126) (Quit: melinda)
# [22:18] * Quits: anthony (chatzilla@203.12.172.254) (Connection reset by peer)
# [22:21] * Joins: anthony (chatzilla@203.12.172.254)
# [22:44] * Joins: plinss_ (plinss@81.253.10.253)
# [23:34] * Quits: plinss_ (plinss@81.253.10.253) (Quit: plinss_)
# Session Close: Wed Oct 22 00:00:01 2008

The end :)