/irc-logs / w3c / #css / 2008-08-20 / end

Options:

# Session Start: Wed Aug 20 00:00:00 2008
# Session Ident: #css
# [02:40] * Joins: molly (mollyholzs@70.171.237.207)
# [02:41] * Quits: molly (mollyholzs@70.171.237.207) (Quit: Quitting!)
# [02:45] * Quits: sylvaing (sylvaing@131.107.0.102) (Ping timeout)
# [03:16] * Joins: melinda (melinda.gr@67.142.45.126)
# [07:48] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070206])
# [10:02] * Joins: alexmog (alexmog@131.107.0.77)
# [10:04] <Bert> Good morning CSS!
# [10:05] * Joins: SteveZ (d5c7928a@128.30.52.43)
# [10:16] * Joins: anne (annevk@213.199.146.138)
# [10:16] * Joins: dbaron (dbaron@213.199.146.138)
# [10:22] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
# [10:22] <RRSAgent> logging to http://www.w3.org/2008/08/20-css-irc
# [10:22] <dbaron> RRSAgent, make logs public
# [10:22] <RRSAgent> I have made the request, dbaron
# [10:22] * Joins: plh (plh@128.30.52.28)
# [10:23] <Bert> Scribe: Bert
# [10:23] <Bert> ScribeNick: Bert
# [10:23] <Bert> Topic: Text layout
# [10:25] <fantasai> Chair: #css
# [10:25] <Bert> People are setting up the projector. Alex will project a demo.
# [10:26] <Bert> Picture on the screen shows many combinations of text directions.
# [10:26] <Bert> Including different positions of scrollbars
# [10:27] <Bert> Fantasai: I think the scrollbar positions are wrong. Should always be in the same place, for usability.
# [10:28] <fantasai> howcome and glazou arrive
# [10:29] <fantasai> Attendees: howcome, dbaron, glazou, salonir, phillippe, jdaggett, stevez, alexmog, bert, fantasai, anne
# [10:33] <plh> s/phil+ip+e/philippe/
# [10:34] <fantasai> peterl walks by the window, will be here soon we hope
# [10:36] <fantasai> +peterl
# [10:36] <fantasai> +rishida
# [10:42] * Joins: plinss_ (plinss_uk@213.199.146.138)
# [10:43] <Bert> Interlude: quick round the table, now that everybody is here.
# [10:50] <Bert> Text layout topic postponed.
# [10:50] <Bert> Topic: CSS 2.1 issues
# [10:52] <Bert> Topic: CSS 2.1 issue 14
# [10:52] <Bert> http://csswg.inkedblade.net/spec/css2.1#issue-14
# [10:53] <Bert> David: Proposal needs replacing. The condition it includes is always true.
# [10:54] <Bert> David: Issue is when element's top & bottom collapses in presence of min-height.
# [10:54] <Bert> David: If min-height happens to be exactly the intrinsic height, spec currently says margins don't collapse.
# [10:55] <Bert> Fantasai: My proposal: don't say less than or equal, but say "effecting height."
# [10:55] <fantasai> s/effect/affect/
# [10:56] <Bert> Fantasai: Bert had some reference to another part of the spec. which might help as well.
# [10:56] <fantasai> Fantasai: alternate proposal, change "less than" to "not affecting" and "greater than" to "not affecting"
# [10:56] <Bert> Steve: David, are you concerned about the word "affect"?
# [10:57] <Bert> David: Yes.
# [10:57] <Bert> Steve: True that height is *always* affected by min-height in a sense...
# [10:57] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jul/0586.html
# [10:58] <Bert> Fantasai: This is Bert's message.
# [10:58] <fantasai> ACTION: dbaron write new proposed text for Issue 14
# [10:58] * trackbot noticed an ACTION. Trying to create it.
# [10:58] * RRSAgent records action 1
# [10:58] <trackbot> Created ACTION-91 - Write new proposed text for Issue 14 [on David Baron - due 2008-08-27].
# [10:59] <Bert> Peter: Issue also affects max-height.
# [10:59] <Bert> David: Yes, the action applies to that as well.
# [10:59] <Bert> Peter: Are we sure everybody agrees with the behavior, apart form the wording?
# [10:59] <Bert> David: I can make text before the end of this ftf.
# [11:00] <Bert> Daniel: Let's try to come back to this tomorrow then.
# [11:00] <fantasai> RESOLVED: to change spec so that case where auto height is equal to min/max height margin collapsing is not disabled. Exact wording to be determined later
# [11:00] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-42
# [11:01] <Bert> Topic: CSS 2.1 issue 42
# [11:01] <Bert> Fantasai: About static position, should also include assumed 'clear: none'
# [11:01] <Bert> Fantasai: I have no opinion.
# [11:02] <Bert> David: I don't like to think about that...
# [11:02] <fantasai> The suggested addition matches what most UAs do, with the exception
# [11:02] <fantasai> of IE7, but IE8 beta 1 seems to match other UAs now. See [1] for
# [11:02] <fantasai> test details.
# [11:02] <fantasai> er that's not the testcase url
# [11:02] <fantasai> https://bugzilla.mozilla.org/attachment.cgi?id=308701
# [11:03] <Bert> Fantasai: I have a test case that shows that clear is not honored when finding static position.
# [11:05] <Bert> Fantasai: The second blue has the same 'clear' as the first, but is positioned. You can see the second blue is not pushed down as the first one is.
# [11:05] <Bert> Alex: The easier it is to compute the static position the better.
# [11:06] <Bert> Alex: Ignoring clear thus seems right thing to do.
# [11:06] <Bert> Fantasai: No opinion on whther it is better, but at least we have more interop that way.
# [11:06] <Bert> Steve/Daniel: Still confused about what it means...
# [11:07] <Bert> David explains the basic case, 'position: absolute; top: auto'
# [11:07] * Joins: r12a (ishida@128.30.52.30)
# [11:08] <Bert> Steve: It does seem to make sense to use the initial valiue of clear...
# [11:08] <Bert> Fantasai: It makes it easier to express that to say "as if clear had been none."
# [11:09] <Bert> Alex: A number of things happen, becomes block, taken out of flow... so concept of where it *would* have been becomes dificult.
# [11:10] <fantasai> I was saying that if you consider that there may have been text/margins after the cleared-positioned element, then it gets complicated to figure out the static position
# [11:10] <Bert> Alex: Who wants to guess at where it would have been if it had floated!?
# [11:11] <Bert> Alex: For 'display: block', logic is fairly simple: the static pos. is on the next line. For clear there is more work to do.
# [11:11] <Bert> David: It's not that much more complicated, just yet another thing to look at.
# [11:11] <Bert> Peter: And 'clear' can make things move *up* can't it?
# [11:11] <Bert> Fantasai: We ficed the spec that that doens't happen anymore.
# [11:12] <Bert> s/ficed/fixed/
# [11:12] <Bert> David: The spec also says that the UA is free to approximate the position...
# [11:13] * Joins: glazou (daniel@213.199.146.138)
# [11:13] <glazou> yoooooo
# [11:14] * Joins: jdaggett (jdaggett@213.199.146.138)
# [11:14] <jdaggett> ah port 80...
# [11:16] * Quits: plinss_ (plinss_uk@213.199.146.138) (Quit: plinss_)
# [11:16] <Bert> Proposal strawpoll: 3 yes, rest abstains
# [11:16] * Joins: plinss_ (plinss_uk@213.199.146.138)
# [11:18] <Bert> Anne: We're probably OK with changing to the proposal...
# [11:19] <Bert> People are looking at Opera's behavior. Opera seems to apply clear, but also seems to have some problem, maybe with margins.
# [11:19] <Bert> Firefox ignores the clear.
# [11:20] <glazou> Opera has no interoperability issue, it only has a bug :-)
# [11:20] <Bert> IE7 behavior appears difficult to interpret.
# [11:21] <fantasai> Webkit is compatible with Firefox
# [11:21] <fantasai> glazou: apparently the proposal makes sense to all browser vendors
# [11:22] <Bert> Daniel: Seems we have implementations and promises of change, so we can accept the proposal. Is that correct?
# [11:22] <Bert> Alex: IE8 *does* ignore clear, what you see is an artifact of something else.
# [11:23] <fantasai> RESOLVED: accept proposal for Issue 42
# [11:23] <Bert> Topic: CSS 2.1 issue 53
# [11:23] <Bert> http://csswg.inkedblade.net/spec/css2.1#issue-53
# [11:24] <Bert> How does justification work in pre?
# [11:25] <Bert> Topic: CSS 2.1 issue 60
# [11:26] <Bert> The issue is described in a 25-page document...
# [11:26] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-48
# [11:26] <Bert> Topic: CSS 2.1 issue 49
# [11:27] <Bert> Topic: CSS 2.1 issue 48 & 49
# [11:27] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-49
# [11:27] <Bert> s/Topic: CSS 2.1 issue 49//
# [11:28] <fantasai> dbaron: goal is to use the next available bolder/lighter font
# [11:28] <fantasai> dbaron: definition of computed value used to be incompatible with this
# [11:28] <fantasai> dbaron: we fixed this, but didn't remove the old text completley
# [11:29] <Bert> David describes issue. Computing 'bolder' involves stepping to next available weight. But computed value may be a non-existent weight. Not all text in spec was corrected to reflect that.
# [11:29] <Bert> David: You don't know the available weights and there may also be multiple fonts involved in an element.
# [11:29] <fantasai> jdaggett: Windows has problems with weights. In Windows you have only two weights. On Mac this is more of an issue
# [11:30] <fantasai> glazou does not like the way computed values for font-weight is a tuple when the property takes a single value.
# [11:30] <fantasai> glazou: If the computed value is not a valid value, it is very complex
# [11:30] <fantasai> jdaggett: we have a similar issue with font-stretch, where we have wider and narrower
# [11:30] <Bert> Daniel: I don't like that value is one keyword, but computed value can be *two* keywords. You cannot write down the computed value.
# [11:31] <fantasai> dbaron: whatever we decide for font-weight should also apply to font-stretch
# [11:31] <fantasai> dbaron: the other issue is that the way multiple occurrences of bolder/lighter compound with each other isn't really defined in the spec
# [11:31] <Bert> David: Spec is unclear about sequences of multiple bolder and ligher.
# [11:31] <fantasai> dbaron: you could view the computed value of font-weight as a base weight followed by an ordered sequence of bolders and lighters
# [11:32] <fantasai> dbaron: or you can see it as the sum of bolders and lighters, e.g. bolderx3 or lighterx2
# [11:32] <fantasai> dbaron: this gives different results
# [11:32] <Bert> John: Have to carry around complex datastructures for cases that never happen.
# [11:33] <Bert> John: Want to make it simpler. Bolder just bumps the weight by two steps.
# [11:33] <fantasai> John: We should do something simpler.
# [11:33] <fantasai> John: 400 to 500 usually won't trigger a bolder font
# [11:34] <fantasai> John: bumbing it up to 600 will get you a bolder font, because 500 falls back to normal
# [11:36] <Bert> Discussion about stepping by 100 or 200 and what the effect is if font has *all* weights (synthesized, e.g.).
# [11:36] <fantasai> dbaron: there's three options for what the computed value should be
# [11:36] <Bert> David draws on white board.
# [11:36] * glazou wonders how many users use more than 'normal' and 'bold'
# [11:36] <fantasai> dbaron: Option A, which was vaguely implied in CSS2, is it's some value 100-900
# [11:36] <Bert> David: option A: computed value is a single number 100-900
# [11:37] <fantasai> dbaron: Option B, it's some value 100-900 and then an integer representing the number of bolders/lighters applied
# [11:37] <fantasai> dbaron: option C, it's value 100-900 and then a sequence
# [11:37] <fantasai> dbaron: Difference between B and C ...
# [11:37] <Bert> David: option B: number 100-900 plus the sum of the bolders (+100) and lighters (-100)
# [11:38] <Bert> David: Option C: weight 100-900 and *sequence* of steps bolder and lighter.
# [11:38] <Bert> David: Options B and C are not the same, depending on the fonts.
# [11:38] <fantasai> [jing] B
# [11:39] <Bert> David: Option C is more complex.
# [11:39] <Bert> Steve: Now I understand why this is an edge case... :-)
# [11:40] <glazou> C is better, right, but it's also totally crazy and means nobody will ever use the computed value of font-weight
# [11:40] <Bert> John: The computed style is not itself a useful value in options B/C.
# [11:41] <Bert> Steve: There are many fonts where weights differ in only one step (100).
# [11:41] * fantasai votes for B
# [11:41] <fantasai> :)
# [11:42] <fantasai> glazou: a lot of websites use 'bolder' rather than 'bold'
# [11:42] <Bert> Daniel: Many people who use 'bolder' expect to go from 'normal' to 'bold'.
# [11:42] <fantasai> dbaron: For GetComputedStyle, there are manyt hings you could do. You could look up the fonts and return a numeric value.
# [11:43] <fantasai> dbaron: I'm more concerned about what inherits.
# [11:44] <Bert> Steve: If you mix fonts, option C seems overly complex for little gain in practice. It's the theoretically right way, but is it worth it?
# [11:44] <Bert> David: I think there are problems with C as well.
# [11:45] <fantasai> Peter: Say you have a set font. Later you go bolder. Inside that you go lighter. Shouldn't you be back where you started?
# [11:45] <Bert> Peter: After 'bolder' and 'lighter', don't you expect to be back where you were?
# [11:46] <Bert> Steve: 'bolder' is more reliable, because fonts don't always have bolder weight at 700.
# [11:47] <Bert> Daniel/David: I expect many people use 'bolder' and 'bold' as synonyms.
# [11:47] <glazou> glazou: most web authors don't even know 100-900 values exist...
# [11:48] <Bert> Peter: Saying normal and then bolder, the author expects to see something bolder if it exists, so just bumping by 100 doesn't work.
# [11:49] <Bert> Peter: Trick I used was encoding B all in a single integer, something like 101 stands for weight 100 + 1 times bolder.
# [11:50] <Bert> David: The spec has been modified many times and not always consitently.
# [11:50] * plh hides under the table with he hears DOM Level 2 style spec
# [11:50] * glazou suggests a first break in 15 minutes or after this issue, the earliest
# [11:50] <fantasai> dbaron notes that GetComputedStyle doesn't return the "computed style" in the CSS2.1 sense, but rather the "computed style" of the CSS2 spec, which is more like the "used style" of CSS2.1
# [11:51] <Bert> David: The text I want to remove is that, if there is no darker font, the computed value is bumped by 100.
# [11:52] <fantasai> ... because it is leftover from before we fixed the computed value to use a tuple
# [11:52] <Bert> Peter: If the OS *can* make an arbitrary weight, then that is what the UA should use.
# [11:54] <Bert> David: There were two parts to this issue: removing the text just quoted about unavailable weight, and chosing between options B and C.
# [11:55] <fantasai> John: if you have bolder, bolder, lighter and only two weights available, with B you get bold, with C you get normal
# [11:55] <Bert> John: One typical question is what we expect after normal + blder + bolder + lighter: If font has one bold only, are we back at normal?
# [11:55] <anne> http://hixie.ch/tests/adhoc/css/fonts/weight/
# [11:55] <Bert> s/blder/bolder/
# [11:56] <jdaggett> http://www.hixie.ch/tests/adhoc/css/fonts/weight/002.xml
# [11:56] <anne> http://hixie.ch/tests/adhoc/css/fonts/weight/002.html
# [11:56] <anne> (works prolly better in IE)
# [11:57] * Quits: SteveZ (d5c7928a@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [11:57] <dbaron> http://dbaron.org/css/test/2008/font-lighter
# [11:57] <Bert> David gives a simpler test.
# [11:59] <Bert> Moz is bold, Opera is normal, Safari is normal.
# [12:00] <fantasai> Peter: What does the author expect in this case?
# [12:01] <Bert> Peter rephrases the difference between C and B. Does 2 bolder + 1 lighter end up at normal or at bold (if font has only one bold)?
# [12:03] <Bert> John: There are few systems in practice with fonts with multiple weights. Basically only some Macs.
# [12:04] <Bert> Hakon: We need to cater for higher quality fonts, there will be more of them.
# [12:05] <Bert> Steve: Many fonts have weights that are not normal and bold, has to support those.
# [12:05] <Bert> Fantasai: We can't really answer the question what an author expects after bolder+bolder+lighter?
# [12:05] <Bert> s/\?//
# [12:05] <fantasai> because we have no web designers here today
# [12:06] <fantasai> SteveZ: the other important question is should bolder+lighter give you back the normal font?
# [12:06] <fantasai> SteveZ: the sequence won't always do that, if e.g. there is no bolder font but there is a lighter font
# [12:07] <dbaron> Should we take a B vs. C straw poll?
# [12:07] <glazou> yes
# [12:07] <Bert> Steve: Think e.g., about the case that there is no bolder, but there is a lighter one. In option C, normal + bolder + lighter will give you that ligher one, not the normal one. So option C is not correct for this case.
# [12:08] <Bert> Philippe: Maybe this is not worth fixing in the time scale for CSS 2.1.
# [12:10] <Bert> Discussion about whether it is important (and if so, when) that computed value is a "string" in CSS syntax.
# [12:10] <Bert> It's an issue for the DOM, is it also for CSS 2.1?
# [12:11] <Bert> Daniel: Should we do a strawpoll?
# [12:12] <fantasai> Anne: abstain
# [12:12] <fantasai> fantasai: B
# [12:12] <fantasai> Bert: 60% B 40% C
# [12:12] * Joins: SteveZ (d5c7928a@128.30.52.43)
# [12:12] <Bert> John: The behavior and the syntax of the computed value are separate questions.
# [12:12] <fantasai> Rcihard: abstain
# [12:13] <fantasai> Alex: C
# [12:13] <fantasai> Peter: B
# [12:13] <fantasai> Steve: B
# [12:13] <fantasai> John: B
# [12:13] <fantasai> Phillippe: Abstain
# [12:13] <fantasai> Saloni: Abstain
# [12:13] <fantasai> Daniel: 60% B 40% C
# [12:13] <fantasai> David: B
# [12:13] <fantasai> Howcome: B
# [12:15] <fantasai> glazou: Add a note saying that GetComputedStyle is unpredictable for anything aside from normal and bold
# [12:15] <Bert> John: IE already has an extesnion to getcomputedstyle for the font weight.
# [12:16] <Bert> Daniel: Seems we have preference for B, but do we have consensus?
# [12:16] <fantasai> Peter: My concern is what happens when we start getting rich fonts with multiple weights.
# [12:16] <Bert> Peter: I want to be sure that result is intuitive for fonts with more than two weights.
# [12:17] <Bert> Peter: Imagine a font with seven weights and he does lots of 'bolder' and maybe one lighter, but then the page gets displayed on a system with just one bold.
# [12:18] <Bert> Peter: We need to describe what we want 'bolder' to really *mean*. Different people have a different interpretation.
# [12:19] <Bert> Daniel: Take a break and come back a bit later?
# [12:19] <Bert> Fantasai: Could ask Molly and Jason, but maybe can also just resolve it now.
# [12:19] <fantasai> RESOLVED: Accepted proposal for Issue 48
# [12:19] <fantasai> (49 still open)
# [12:20] <Bert> [Break 15 mins]
# [12:33] * Joins: shepazu (schepers@128.30.52.30)
# [12:38] <Bert> Daniel: Extra agenda for Friday: charter
# [12:38] <glazou> hi doug
# [12:39] <Bert> Daniel: ... about process, milestones, etc., and explaining things to Philippe.
# [12:40] <Bert> Back to issue 49.
# [12:40] <Bert> Alex: Not sure the implementations will want to change.
# [12:40] <Bert> Peter: How about in a future version?
# [12:41] <Bert> Alex: Maybe designers should avoid 'bolder' and 'lighter' and we should say so in the spec.
# [12:41] <Bert> Alex: Because it may have effect on soem systems and not on others.
# [12:43] <Bert> Richard: You were trying to find out how people use it. Should maybe ask that of some actual users.
# [12:43] * Quits: glazou (daniel@213.199.146.138) (Quit: switching to daniel.glazman account)
# [12:44] <Bert> John: We're defining edge case behavior. Should not say "don't use this" because in a world with two weights, it works as expected.
# [12:45] <Bert> Fantasai: Even if we don't say anything in level 2, we should be precise in level 3.
# [12:45] <Bert> Philippe: But there is something in level 2 already.
# [12:45] * Joins: glazou (daniel@213.199.146.138)
# [12:46] <Bert> John: How about font-stretch: wider?
# [12:46] <fantasai> http://www.w3.org/blog/CSS/2007/08/29/backlog_resolutions
# [12:46] <fantasai> "RESOLVED: The Markus Principle: ..." :)
# [12:46] <Bert> Peter: Only reason to not define in CSS 2.1 mightbe that we have differing implementations.
# [12:47] <Bert> Peter: But still want to decide what we'll have in level 3, even if we leave level 2 undefined.
# [12:47] <Bert> Alex: Feedback from designers is necessary here.
# [12:47] <Bert> Fantasai: Can Peter take an action to ask Molly and others?
# [12:48] <Bert> Discussion about leaving it undefined in level 2 and under what conditions.
# [12:49] * Joins: myakura (myakura@118.8.102.216)
# [12:49] <Bert> Fantasai: OK with leaving CSS 2.1, as long as we decide what to do for level 3.
# [12:49] <Bert> Daniel: Or just say that we will resolve for level 3, without saying what way.
# [12:50] <fantasai> SteveZe: "A sequence of bolders and lighters may have different results in different UAs."
# [12:50] <Bert> Steve: We can put a note that sequences of bolder and lighter may have different results on different sstems.
# [12:50] <fantasai> Fantasai: add that this will be defined in CSS3
# [12:51] <Bert> Daniel: "Seq. of bolder and lighter may have unpredictable result in level 2, but will be defined in level 3."
# [12:51] <fantasai> Peter: Add dependence on UA, OS, and font availability
# [12:51] <fantasai> Peter: So authors know how widely they need to test
# [12:51] <fantasai> ACTION: fantasai Draft a note
# [12:51] * trackbot noticed an ACTION. Trying to create it.
# [12:51] * RRSAgent records action 2
# [12:51] <trackbot> Created ACTION-92 - Draft a note [on Elika Etemad - due 2008-08-27].
# [12:51] <anne> [off] plh, so the difference between the HTML and XML version of 001 is that 001.html has font-size:2em and 001.xml has font-size:1em :)
# [12:51] <plh> [off] ah, that explains indeed :)
# [12:52] <fantasai> RESOLVED: Leave undefined in CSS2.1, add note as described above
# [12:52] <fantasai> for ISSUE 49
# [12:52] <fantasai> ACTION: Peter Consult Jason, Molly, other web designers, about what is expected behavior for bolder + lighter, bolder+bolder+lighter
# [12:52] * trackbot noticed an ACTION. Trying to create it.
# [12:52] * RRSAgent records action 3
# [12:52] <trackbot> Created ACTION-93 - Consult Jason, Molly, other web designers, about what is expected behavior for bolder + lighter, bolder+bolder+lighter [on Peter Linss - due 2008-08-27].
# [12:53] <Bert> Philippe: Can you add an issue on CSS3 Fonts about this, so that it doens't get lost?
# [12:53] <Bert> Fantasai: Doing it right now...
# [12:54] <Bert> Philippe: And can you add the test cases to that issue?
# [12:55] <fantasai> ISSUE-61 recorded against CSS3 Fonts
# [12:55] <Bert> Topic: CSS 2.1 issue 52
# [12:55] <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Aug/0154.html
# [12:56] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-52
# [12:57] <Bert> Issue is about practice of putting page-break on BR, which is not allowed by spec (unless BR is made a 'block')
# [12:58] <Bert> David: Seems page-break is a bit like clear, for which we allow UAs to apply it to inlines.
# [12:58] <Bert> Alex: Think it should apply only to BR, not to all inlines.
# [12:58] <Bert> Bert: What is the difference between BR and SPAN?
# [13:00] <Bert> Alex: Not a lot of interoperability on BR, e.g., applying :before to it.
# [13:00] <fantasai> br { content: '\A'; white-space: pre; }
# [13:00] <fantasai> but need to make 'clear' apply specially
# [13:00] <Bert> Anne: That (Fantasai's rule) is what Opera does,
# [13:00] <fantasai> Anne: That's how Opera implements
# [13:01] <Bert> Alex: What is the size and position of BR in Opera in DOM?
# [13:01] <Bert> Fantasai: Same as with a line feed...
# [13:02] <Bert> Daniel: A 'page-break-before' on BR puts a blank line at the top of the page.
# [13:03] <Bert> Steve: Whether page break applies shoudl depend on how the elt is styled, in particular whether it is block-level.
# [13:04] <Bert> Daniel: One use case is a BODY consisting of nothing but text and BR. Want to break page at some BR.
# [13:05] <fantasai> ... or <pre> and
# [13:05] <Bert> Daniel: Users of word processors often work like that: turn some line break into a page break.
# [13:05] <anne> (Opera's behavior with respect to the interaction of 'content', 'clear', and is slightly weird.)
# [13:06] <Bert> Steve: 'last-line-align' applies to last line before the BR.
# [13:06] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [13:06] <anne> (The moment you use 'content' on it no longer has special 'clear' behavior, even if it is "\A".)
# [13:06] * plh fantasai, be aware that issue 66 has a markup error for its status in the wiki
# [13:06] <Bert> Steve: So it looks also like a natural break point. It *looks* like a paragraph.
# [13:07] * plh thank you :)
# [13:07] <Bert> Daniel: BR could be used for page breaks as well. HTML doesn't have a page break element, but could imagine
# [13:07] <fantasai> fantasai: The same applies to '\A' in a white-space: pre element
# [13:08] <Bert> Saloni: What if we apply page breaks to all elements, not only block-level?
# [13:08] <Bert> Fantasai: We would make an exception for HTML: page break applies to block-level, except in HTML it also applies to...
# [13:09] <Bert> Steve: Everywhere where last-line-align applies should also accept page break properties.
# [13:10] <anne> fantasai, (since people are talking) you could just define some special construct and then HTML5 says that is such a construct
# [13:10] <Bert> David: Lines in PRE also have last-line-align' applied.
# [13:10] <anne> fantasai, then magic langauges work too
# [13:10] <Bert> David: Which of many "last" lines has the page break applied to?
# [13:11] <Bert> Fantasai: Imagine a pre, *all* lines would have page break properties applied.
# [13:12] <Bert> Steve: The alternative is that 'last-line-align' doens't apply.
# [13:12] <Bert> Fantasai: The 'last-line-align' applies because there is a forced line break.
# [13:13] <Bert> Steve: I wouldn't call that an inline element.
# [13:14] <Bert> David: Maybe the term [inline] is not fully intuitive, but it *is* precisely defined.
# [13:15] <Bert> Daniel: What about some XML format (because there are many now), where I want to turn some element into a page break? Think MS Word.
# [13:16] <Bert> Alex: Many cases: line breaks, page breaks, paragraph breaks, and any of there with or without last line behavior.
# [13:16] <anne> s/langauges/languages/
# [13:16] <Bert> Alex: Seems we need 'display: break'
# [13:17] <Bert> Peter: Steve's argument is a negative argument. He says *if* we do this then we have to do that. Not that we have to do "that."
# [13:18] <Bert> Anne: Just adding 'display: block' when needed to make an element into a page break element is not a big deal.
# [13:19] <Bert> Daniel: Consider editing perspective. It's easy to insert an empty element.
# [13:19] <fantasai> br { white-space: pre; content: '\A'; }
# [13:19] <Bert> Fantasai: Just insert an empty element with both page break and display:block
# [13:19] <fantasai> br[type="page"] { display: block; content: none; page-break-before: always; }
# [13:20] <Bert> Daniel: But we can't reproduce HTML's BR in XML.
# [13:20] <Bert> Hakon: Yes you can, the sample style sheet shows how.
# [13:21] <Bert> Fantasai: Anne and I are saying that you can get the functionality you want in XML.
# [13:21] <fantasai> Fantasai: just without the quirkcs
# [13:22] <Bert> Anne: Or we introduce an abtract magic element and then any language can decalre that some element act as that magic element.
# [13:23] <Bert> Several people explain the problem of sequences of BR. The second and subsequent ones cannot be 'block' because they shouldn't collapse.
# [13:24] <Bert> Hakon: Can solve that with selectors, BR + BR.
# [13:24] <anne> http://www.joelonsoftware.com/articles/fog0000000018.html
# [13:25] <Bert> Fantasai: The quirky behavior of BR is that 'clear' applies.
# [13:25] <Bert> Peter: Now imagine I want to set 'content' on my BR, I lose the line breaking behavior.
# [13:25] <Bert> Several: Just add the \A as well.
# [13:26] <Bert> Peter: I want an extra property, or a 'display' value, for BR.
# [13:27] <Bert> Hakon: But that doesn't work in current browsers.
# [13:28] <Bert> Steve comes back to what "inline" means, doesn't think a \A can be called "inline."
# [13:29] <Bert> Fantasai: So you don't want to call the span in "<pre>foo [linebreak] bar</pre>" inline? In CSS it is defined as inline.
# [13:29] <Bert> Daniel: The width of the line box before the break is different.
# [13:29] <fantasai> s/[linebreak]/test[linebreak]test/
# [13:30] <Bert> Hakon: Really? And does that matter at all?
# [13:30] <Bert> Daniel: You can ask for the bounding rect of Fantasai's SPAN in the DOM. But it may not be relevant for this discussion.
# [13:31] <Bert> Saloni: Do we all agree that page break applies to BR, independent of how we explain it?
# [13:32] <Bert> Bert: No, don't make exceptions for HTML.
# [13:32] <Bert> Alex: We (IE) have a special 'display' tupe (more or less) for BR.
# [13:32] <Bert> Hakon: What then happens in IE if I set :before{content:"\A"} on the BR?
# [13:34] <Bert> Hakon: Is that display type hardcoded? Or can you override it with a style rule?
# [13:34] <Bert> Steve: Can you change BR to list-item?
# [13:34] <Bert> Hakon: Should work in Opera, yes.
# [13:34] <Bert> Peter: How can a user override the rules?
# [13:35] <Bert> Peter: I like there to be a simple rule to make the BR behave one way or another. Make it not break a line, e.g.,