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

Options:

  1. # Session Start: Wed Aug 20 00:00:00 2008
  2. # Session Ident: #css
  3. # [02:40] * Joins: molly (mollyholzs@70.171.237.207)
  4. # [02:41] * Quits: molly (mollyholzs@70.171.237.207) (Quit: Quitting!)
  5. # [02:45] * Quits: sylvaing (sylvaing@131.107.0.102) (Ping timeout)
  6. # [03:16] * Joins: melinda (melinda.gr@67.142.45.126)
  7. # [07:48] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070206])
  8. # [10:02] * Joins: alexmog (alexmog@131.107.0.77)
  9. # [10:04] <Bert> Good morning CSS!
  10. # [10:05] * Joins: SteveZ (d5c7928a@128.30.52.43)
  11. # [10:16] * Joins: anne (annevk@213.199.146.138)
  12. # [10:16] * Joins: dbaron (dbaron@213.199.146.138)
  13. # [10:22] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  14. # [10:22] <RRSAgent> logging to http://www.w3.org/2008/08/20-css-irc
  15. # [10:22] <dbaron> RRSAgent, make logs public
  16. # [10:22] <RRSAgent> I have made the request, dbaron
  17. # [10:22] * Joins: plh (plh@128.30.52.28)
  18. # [10:23] <Bert> Scribe: Bert
  19. # [10:23] <Bert> ScribeNick: Bert
  20. # [10:23] <Bert> Topic: Text layout
  21. # [10:25] <fantasai> Chair: #css
  22. # [10:25] <Bert> People are setting up the projector. Alex will project a demo.
  23. # [10:26] <Bert> Picture on the screen shows many combinations of text directions.
  24. # [10:26] <Bert> Including different positions of scrollbars
  25. # [10:27] <Bert> Fantasai: I think the scrollbar positions are wrong. Should always be in the same place, for usability.
  26. # [10:28] <fantasai> howcome and glazou arrive
  27. # [10:29] <fantasai> Attendees: howcome, dbaron, glazou, salonir, phillippe, jdaggett, stevez, alexmog, bert, fantasai, anne
  28. # [10:33] <plh> s/phil+ip+e/philippe/
  29. # [10:34] <fantasai> peterl walks by the window, will be here soon we hope
  30. # [10:36] <fantasai> +peterl
  31. # [10:36] <fantasai> +rishida
  32. # [10:42] * Joins: plinss_ (plinss_uk@213.199.146.138)
  33. # [10:43] <Bert> Interlude: quick round the table, now that everybody is here.
  34. # [10:50] <Bert> Text layout topic postponed.
  35. # [10:50] <Bert> Topic: CSS 2.1 issues
  36. # [10:52] <Bert> Topic: CSS 2.1 issue 14
  37. # [10:52] <Bert> http://csswg.inkedblade.net/spec/css2.1#issue-14
  38. # [10:53] <Bert> David: Proposal needs replacing. The condition it includes is always true.
  39. # [10:54] <Bert> David: Issue is when element's top & bottom collapses in presence of min-height.
  40. # [10:54] <Bert> David: If min-height happens to be exactly the intrinsic height, spec currently says margins don't collapse.
  41. # [10:55] <Bert> Fantasai: My proposal: don't say less than or equal, but say "effecting height."
  42. # [10:55] <fantasai> s/effect/affect/
  43. # [10:56] <Bert> Fantasai: Bert had some reference to another part of the spec. which might help as well.
  44. # [10:56] <fantasai> Fantasai: alternate proposal, change "less than" to "not affecting" and "greater than" to "not affecting"
  45. # [10:56] <Bert> Steve: David, are you concerned about the word "affect"?
  46. # [10:57] <Bert> David: Yes.
  47. # [10:57] <Bert> Steve: True that height is *always* affected by min-height in a sense...
  48. # [10:57] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jul/0586.html
  49. # [10:58] <Bert> Fantasai: This is Bert's message.
  50. # [10:58] <fantasai> ACTION: dbaron write new proposed text for Issue 14
  51. # [10:58] * trackbot noticed an ACTION. Trying to create it.
  52. # [10:58] * RRSAgent records action 1
  53. # [10:58] <trackbot> Created ACTION-91 - Write new proposed text for Issue 14 [on David Baron - due 2008-08-27].
  54. # [10:59] <Bert> Peter: Issue also affects max-height.
  55. # [10:59] <Bert> David: Yes, the action applies to that as well.
  56. # [10:59] <Bert> Peter: Are we sure everybody agrees with the behavior, apart form the wording?
  57. # [10:59] <Bert> David: I can make text before the end of this ftf.
  58. # [11:00] <Bert> Daniel: Let's try to come back to this tomorrow then.
  59. # [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
  60. # [11:00] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-42
  61. # [11:01] <Bert> Topic: CSS 2.1 issue 42
  62. # [11:01] <Bert> Fantasai: About static position, should also include assumed 'clear: none'
  63. # [11:01] <Bert> Fantasai: I have no opinion.
  64. # [11:02] <Bert> David: I don't like to think about that...
  65. # [11:02] <fantasai> The suggested addition matches what most UAs do, with the exception
  66. # [11:02] <fantasai> of IE7, but IE8 beta 1 seems to match other UAs now. See [1] for
  67. # [11:02] <fantasai> test details.
  68. # [11:02] <fantasai> er that's not the testcase url
  69. # [11:02] <fantasai> https://bugzilla.mozilla.org/attachment.cgi?id=308701
  70. # [11:03] <Bert> Fantasai: I have a test case that shows that clear is not honored when finding static position.
  71. # [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.
  72. # [11:05] <Bert> Alex: The easier it is to compute the static position the better.
  73. # [11:06] <Bert> Alex: Ignoring clear thus seems right thing to do.
  74. # [11:06] <Bert> Fantasai: No opinion on whther it is better, but at least we have more interop that way.
  75. # [11:06] <Bert> Steve/Daniel: Still confused about what it means...
  76. # [11:07] <Bert> David explains the basic case, 'position: absolute; top: auto'
  77. # [11:07] * Joins: r12a (ishida@128.30.52.30)
  78. # [11:08] <Bert> Steve: It does seem to make sense to use the initial valiue of clear...
  79. # [11:08] <Bert> Fantasai: It makes it easier to express that to say "as if clear had been none."
  80. # [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.
  81. # [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
  82. # [11:10] <Bert> Alex: Who wants to guess at where it would have been if it had floated!?
  83. # [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.
  84. # [11:11] <Bert> David: It's not that much more complicated, just yet another thing to look at.
  85. # [11:11] <Bert> Peter: And 'clear' can make things move *up* can't it?
  86. # [11:11] <Bert> Fantasai: We ficed the spec that that doens't happen anymore.
  87. # [11:12] <Bert> s/ficed/fixed/
  88. # [11:12] <Bert> David: The spec also says that the UA is free to approximate the position...
  89. # [11:13] * Joins: glazou (daniel@213.199.146.138)
  90. # [11:13] <glazou> yoooooo
  91. # [11:14] * Joins: jdaggett (jdaggett@213.199.146.138)
  92. # [11:14] <jdaggett> ah port 80...
  93. # [11:16] * Quits: plinss_ (plinss_uk@213.199.146.138) (Quit: plinss_)
  94. # [11:16] <Bert> Proposal strawpoll: 3 yes, rest abstains
  95. # [11:16] * Joins: plinss_ (plinss_uk@213.199.146.138)
  96. # [11:18] <Bert> Anne: We're probably OK with changing to the proposal...
  97. # [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.
  98. # [11:19] <Bert> Firefox ignores the clear.
  99. # [11:20] <glazou> Opera has no interoperability issue, it only has a bug :-)
  100. # [11:20] <Bert> IE7 behavior appears difficult to interpret.
  101. # [11:21] <fantasai> Webkit is compatible with Firefox
  102. # [11:21] <fantasai> glazou: apparently the proposal makes sense to all browser vendors
  103. # [11:22] <Bert> Daniel: Seems we have implementations and promises of change, so we can accept the proposal. Is that correct?
  104. # [11:22] <Bert> Alex: IE8 *does* ignore clear, what you see is an artifact of something else.
  105. # [11:23] <fantasai> RESOLVED: accept proposal for Issue 42
  106. # [11:23] <Bert> Topic: CSS 2.1 issue 53
  107. # [11:23] <Bert> http://csswg.inkedblade.net/spec/css2.1#issue-53
  108. # [11:24] <Bert> How does justification work in pre?
  109. # [11:25] <Bert> Topic: CSS 2.1 issue 60
  110. # [11:26] <Bert> The issue is described in a 25-page document...
  111. # [11:26] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-48
  112. # [11:26] <Bert> Topic: CSS 2.1 issue 49
  113. # [11:27] <Bert> Topic: CSS 2.1 issue 48 & 49
  114. # [11:27] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-49
  115. # [11:27] <Bert> s/Topic: CSS 2.1 issue 49//
  116. # [11:28] <fantasai> dbaron: goal is to use the next available bolder/lighter font
  117. # [11:28] <fantasai> dbaron: definition of computed value used to be incompatible with this
  118. # [11:28] <fantasai> dbaron: we fixed this, but didn't remove the old text completley
  119. # [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.
  120. # [11:29] <Bert> David: You don't know the available weights and there may also be multiple fonts involved in an element.
  121. # [11:29] <fantasai> jdaggett: Windows has problems with weights. In Windows you have only two weights. On Mac this is more of an issue
  122. # [11:30] <fantasai> glazou does not like the way computed values for font-weight is a tuple when the property takes a single value.
  123. # [11:30] <fantasai> glazou: If the computed value is not a valid value, it is very complex
  124. # [11:30] <fantasai> jdaggett: we have a similar issue with font-stretch, where we have wider and narrower
  125. # [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.
  126. # [11:31] <fantasai> dbaron: whatever we decide for font-weight should also apply to font-stretch
  127. # [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
  128. # [11:31] <Bert> David: Spec is unclear about sequences of multiple bolder and ligher.
  129. # [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
  130. # [11:32] <fantasai> dbaron: or you can see it as the sum of bolders and lighters, e.g. bolderx3 or lighterx2
  131. # [11:32] <fantasai> dbaron: this gives different results
  132. # [11:32] <Bert> John: Have to carry around complex datastructures for cases that never happen.
  133. # [11:33] <Bert> John: Want to make it simpler. Bolder just bumps the weight by two steps.
  134. # [11:33] <fantasai> John: We should do something simpler.
  135. # [11:33] <fantasai> John: 400 to 500 usually won't trigger a bolder font
  136. # [11:34] <fantasai> John: bumbing it up to 600 will get you a bolder font, because 500 falls back to normal
  137. # [11:36] <Bert> Discussion about stepping by 100 or 200 and what the effect is if font has *all* weights (synthesized, e.g.).
  138. # [11:36] <fantasai> dbaron: there's three options for what the computed value should be
  139. # [11:36] <Bert> David draws on white board.
  140. # [11:36] * glazou wonders how many users use more than 'normal' and 'bold'
  141. # [11:36] <fantasai> dbaron: Option A, which was vaguely implied in CSS2, is it's some value 100-900
  142. # [11:36] <Bert> David: option A: computed value is a single number 100-900
  143. # [11:37] <fantasai> dbaron: Option B, it's some value 100-900 and then an integer representing the number of bolders/lighters applied
  144. # [11:37] <fantasai> dbaron: option C, it's value 100-900 and then a sequence
  145. # [11:37] <fantasai> dbaron: Difference between B and C ...
  146. # [11:37] <Bert> David: option B: number 100-900 plus the sum of the bolders (+100) and lighters (-100)
  147. # [11:38] <Bert> David: Option C: weight 100-900 and *sequence* of steps bolder and lighter.
  148. # [11:38] <Bert> David: Options B and C are not the same, depending on the fonts.
  149. # [11:38] <fantasai> <span> <span> <span> [jing] B </span> </span> </span>
  150. # [11:39] <Bert> David: Option C is more complex.
  151. # [11:39] <Bert> Steve: Now I understand why this is an edge case... :-)
  152. # [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
  153. # [11:40] <Bert> John: The computed style is not itself a useful value in options B/C.
  154. # [11:41] <Bert> Steve: There are many fonts where weights differ in only one step (100).
  155. # [11:41] * fantasai votes for B
  156. # [11:41] <fantasai> :)
  157. # [11:42] <fantasai> glazou: a lot of websites use 'bolder' rather than 'bold'
  158. # [11:42] <Bert> Daniel: Many people who use 'bolder' expect to go from 'normal' to 'bold'.
  159. # [11:42] <fantasai> dbaron: For GetComputedStyle, there are manyt hings you could do. You could look up the fonts and return a numeric value.
  160. # [11:43] <fantasai> dbaron: I'm more concerned about what inherits.
  161. # [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?
  162. # [11:44] <Bert> David: I think there are problems with C as well.
  163. # [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?
  164. # [11:45] <Bert> Peter: After 'bolder' and 'lighter', don't you expect to be back where you were?
  165. # [11:46] <Bert> Steve: 'bolder' is more reliable, because fonts don't always have bolder weight at 700.
  166. # [11:47] <Bert> Daniel/David: I expect many people use 'bolder' and 'bold' as synonyms.
  167. # [11:47] <glazou> glazou: most web authors don't even know 100-900 values exist...
  168. # [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.
  169. # [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.
  170. # [11:50] <Bert> David: The spec has been modified many times and not always consitently.
  171. # [11:50] * plh hides under the table with he hears DOM Level 2 style spec
  172. # [11:50] * glazou suggests a first break in 15 minutes or after this issue, the earliest
  173. # [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
  174. # [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.
  175. # [11:52] <fantasai> ... because it is leftover from before we fixed the computed value to use a tuple
  176. # [11:52] <Bert> Peter: If the OS *can* make an arbitrary weight, then that is what the UA should use.
  177. # [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.
  178. # [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
  179. # [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?
  180. # [11:55] <anne> http://hixie.ch/tests/adhoc/css/fonts/weight/
  181. # [11:55] <Bert> s/blder/bolder/
  182. # [11:56] <jdaggett> http://www.hixie.ch/tests/adhoc/css/fonts/weight/002.xml
  183. # [11:56] <anne> http://hixie.ch/tests/adhoc/css/fonts/weight/002.html
  184. # [11:56] <anne> (works prolly better in IE)
  185. # [11:57] * Quits: SteveZ (d5c7928a@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  186. # [11:57] <dbaron> http://dbaron.org/css/test/2008/font-lighter
  187. # [11:57] <Bert> David gives a simpler test.
  188. # [11:59] <Bert> Moz is bold, Opera is normal, Safari is normal.
  189. # [12:00] <fantasai> Peter: What does the author expect in this case?
  190. # [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)?
  191. # [12:03] <Bert> John: There are few systems in practice with fonts with multiple weights. Basically only some Macs.
  192. # [12:04] <Bert> Hakon: We need to cater for higher quality fonts, there will be more of them.
  193. # [12:05] <Bert> Steve: Many fonts have weights that are not normal and bold, has to support those.
  194. # [12:05] <Bert> Fantasai: We can't really answer the question what an author expects after bolder+bolder+lighter?
  195. # [12:05] <Bert> s/\?//
  196. # [12:05] <fantasai> because we have no web designers here today
  197. # [12:06] <fantasai> SteveZ: the other important question is should bolder+lighter give you back the normal font?
  198. # [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
  199. # [12:07] <dbaron> Should we take a B vs. C straw poll?
  200. # [12:07] <glazou> yes
  201. # [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.
  202. # [12:08] <Bert> Philippe: Maybe this is not worth fixing in the time scale for CSS 2.1.
  203. # [12:10] <Bert> Discussion about whether it is important (and if so, when) that computed value is a "string" in CSS syntax.
  204. # [12:10] <Bert> It's an issue for the DOM, is it also for CSS 2.1?
  205. # [12:11] <Bert> Daniel: Should we do a strawpoll?
  206. # [12:12] <fantasai> Anne: abstain
  207. # [12:12] <fantasai> fantasai: B
  208. # [12:12] <fantasai> Bert: 60% B 40% C
  209. # [12:12] * Joins: SteveZ (d5c7928a@128.30.52.43)
  210. # [12:12] <Bert> John: The behavior and the syntax of the computed value are separate questions.
  211. # [12:12] <fantasai> Rcihard: abstain
  212. # [12:13] <fantasai> Alex: C
  213. # [12:13] <fantasai> Peter: B
  214. # [12:13] <fantasai> Steve: B
  215. # [12:13] <fantasai> John: B
  216. # [12:13] <fantasai> Phillippe: Abstain
  217. # [12:13] <fantasai> Saloni: Abstain
  218. # [12:13] <fantasai> Daniel: 60% B 40% C
  219. # [12:13] <fantasai> David: B
  220. # [12:13] <fantasai> Howcome: B
  221. # [12:15] <fantasai> glazou: Add a note saying that GetComputedStyle is unpredictable for anything aside from normal and bold
  222. # [12:15] <Bert> John: IE already has an extesnion to getcomputedstyle for the font weight.
  223. # [12:16] <Bert> Daniel: Seems we have preference for B, but do we have consensus?
  224. # [12:16] <fantasai> Peter: My concern is what happens when we start getting rich fonts with multiple weights.
  225. # [12:16] <Bert> Peter: I want to be sure that result is intuitive for fonts with more than two weights.
  226. # [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.
  227. # [12:18] <Bert> Peter: We need to describe what we want 'bolder' to really *mean*. Different people have a different interpretation.
  228. # [12:19] <Bert> Daniel: Take a break and come back a bit later?
  229. # [12:19] <Bert> Fantasai: Could ask Molly and Jason, but maybe can also just resolve it now.
  230. # [12:19] <fantasai> RESOLVED: Accepted proposal for Issue 48
  231. # [12:19] <fantasai> (49 still open)
  232. # [12:20] <Bert> [Break 15 mins]
  233. # [12:33] * Joins: shepazu (schepers@128.30.52.30)
  234. # [12:38] <Bert> Daniel: Extra agenda for Friday: charter
  235. # [12:38] <glazou> hi doug
  236. # [12:39] <Bert> Daniel: ... about process, milestones, etc., and explaining things to Philippe.
  237. # [12:40] <Bert> Back to issue 49.
  238. # [12:40] <Bert> Alex: Not sure the implementations will want to change.
  239. # [12:40] <Bert> Peter: How about in a future version?
  240. # [12:41] <Bert> Alex: Maybe designers should avoid 'bolder' and 'lighter' and we should say so in the spec.
  241. # [12:41] <Bert> Alex: Because it may have effect on soem systems and not on others.
  242. # [12:43] <Bert> Richard: You were trying to find out how people use it. Should maybe ask that of some actual users.
  243. # [12:43] * Quits: glazou (daniel@213.199.146.138) (Quit: switching to daniel.glazman account)
  244. # [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.
  245. # [12:45] <Bert> Fantasai: Even if we don't say anything in level 2, we should be precise in level 3.
  246. # [12:45] <Bert> Philippe: But there is something in level 2 already.
  247. # [12:45] * Joins: glazou (daniel@213.199.146.138)
  248. # [12:46] <Bert> John: How about font-stretch: wider?
  249. # [12:46] <fantasai> http://www.w3.org/blog/CSS/2007/08/29/backlog_resolutions
  250. # [12:46] <fantasai> "RESOLVED: The Markus Principle: ..." :)
  251. # [12:46] <Bert> Peter: Only reason to not define in CSS 2.1 mightbe that we have differing implementations.
  252. # [12:47] <Bert> Peter: But still want to decide what we'll have in level 3, even if we leave level 2 undefined.
  253. # [12:47] <Bert> Alex: Feedback from designers is necessary here.
  254. # [12:47] <Bert> Fantasai: Can Peter take an action to ask Molly and others?
  255. # [12:48] <Bert> Discussion about leaving it undefined in level 2 and under what conditions.
  256. # [12:49] * Joins: myakura (myakura@118.8.102.216)
  257. # [12:49] <Bert> Fantasai: OK with leaving CSS 2.1, as long as we decide what to do for level 3.
  258. # [12:49] <Bert> Daniel: Or just say that we will resolve for level 3, without saying what way.
  259. # [12:50] <fantasai> SteveZe: "A sequence of bolders and lighters may have different results in different UAs."
  260. # [12:50] <Bert> Steve: We can put a note that sequences of bolder and lighter may have different results on different sstems.
  261. # [12:50] <fantasai> Fantasai: add that this will be defined in CSS3
  262. # [12:51] <Bert> Daniel: "Seq. of bolder and lighter may have unpredictable result in level 2, but will be defined in level 3."
  263. # [12:51] <fantasai> Peter: Add dependence on UA, OS, and font availability
  264. # [12:51] <fantasai> Peter: So authors know how widely they need to test
  265. # [12:51] <fantasai> ACTION: fantasai Draft a note
  266. # [12:51] * trackbot noticed an ACTION. Trying to create it.
  267. # [12:51] * RRSAgent records action 2
  268. # [12:51] <trackbot> Created ACTION-92 - Draft a note [on Elika Etemad - due 2008-08-27].
  269. # [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 :)
  270. # [12:51] <plh> [off] ah, that explains indeed :)
  271. # [12:52] <fantasai> RESOLVED: Leave undefined in CSS2.1, add note as described above
  272. # [12:52] <fantasai> for ISSUE 49
  273. # [12:52] <fantasai> ACTION: Peter Consult Jason, Molly, other web designers, about what is expected behavior for bolder + lighter, bolder+bolder+lighter
  274. # [12:52] * trackbot noticed an ACTION. Trying to create it.
  275. # [12:52] * RRSAgent records action 3
  276. # [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].
  277. # [12:53] <Bert> Philippe: Can you add an issue on CSS3 Fonts about this, so that it doens't get lost?
  278. # [12:53] <Bert> Fantasai: Doing it right now...
  279. # [12:54] <Bert> Philippe: And can you add the test cases to that issue?
  280. # [12:55] <fantasai> ISSUE-61 recorded against CSS3 Fonts
  281. # [12:55] <Bert> Topic: CSS 2.1 issue 52
  282. # [12:55] <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Aug/0154.html
  283. # [12:56] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-52
  284. # [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')
  285. # [12:58] <Bert> David: Seems page-break is a bit like clear, for which we allow UAs to apply it to inlines.
  286. # [12:58] <Bert> Alex: Think it should apply only to BR, not to all inlines.
  287. # [12:58] <Bert> Bert: What is the difference between BR and SPAN?
  288. # [13:00] <Bert> Alex: Not a lot of interoperability on BR, e.g., applying :before to it.
  289. # [13:00] <fantasai> br { content: '\A'; white-space: pre; }
  290. # [13:00] <fantasai> but need to make 'clear' apply specially
  291. # [13:00] <Bert> Anne: That (Fantasai's rule) is what Opera does,
  292. # [13:00] <fantasai> Anne: That's how Opera implements <br>
  293. # [13:01] <Bert> Alex: What is the size and position of BR in Opera in DOM?
  294. # [13:01] <Bert> Fantasai: Same as <span> with a line feed...
  295. # [13:02] <Bert> Daniel: A 'page-break-before' on BR puts a blank line at the top of the page.
  296. # [13:03] <Bert> Steve: Whether page break applies shoudl depend on how the elt is styled, in particular whether it is block-level.
  297. # [13:04] <Bert> Daniel: One use case is a BODY consisting of nothing but text and BR. Want to break page at some BR.
  298. # [13:05] <fantasai> ... or <pre> and <br>
  299. # [13:05] <Bert> Daniel: Users of word processors often work like that: turn some line break into a page break.
  300. # [13:05] <anne> (Opera's behavior with respect to the interaction of 'content', 'clear', and <br> is slightly weird.)
  301. # [13:06] <Bert> Steve: 'last-line-align' applies to last line before the BR.
  302. # [13:06] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  303. # [13:06] <anne> (The moment you use 'content' on <br> it no longer has special 'clear' behavior, even if it is "\A".)
  304. # [13:06] * plh fantasai, be aware that issue 66 has a markup error for its status in the wiki
  305. # [13:06] <Bert> Steve: So it looks also like a natural break point. It *looks* like a paragraph.
  306. # [13:07] * plh thank you :)
  307. # [13:07] <Bert> Daniel: BR could be used for page breaks as well. HTML doesn't have a page break element, but could imagine <BR TYPE=PAGE>
  308. # [13:07] <fantasai> fantasai: The same applies to '\A' in a white-space: pre element
  309. # [13:08] <Bert> Saloni: What if we apply page breaks to all elements, not only block-level?
  310. # [13:08] <Bert> Fantasai: We would make an exception for HTML: page break applies to block-level, except in HTML it also applies to...
  311. # [13:09] <Bert> Steve: Everywhere where last-line-align applies should also accept page break properties.
  312. # [13:10] <anne> fantasai, (since people are talking) you could just define some special construct and then HTML5 says that <br> is such a construct
  313. # [13:10] <Bert> David: Lines in PRE also have last-line-align' applied.
  314. # [13:10] <anne> fantasai, then magic langauges work too
  315. # [13:10] <Bert> David: Which of many "last" lines has the page break applied to?
  316. # [13:11] <Bert> Fantasai: Imagine a pre, *all* lines would have page break properties applied.
  317. # [13:12] <Bert> Steve: The alternative is that 'last-line-align' doens't apply.
  318. # [13:12] <Bert> Fantasai: The 'last-line-align' applies because there is a forced line break.
  319. # [13:13] <Bert> Steve: I wouldn't call that an inline element.
  320. # [13:14] <Bert> David: Maybe the term [inline] is not fully intuitive, but it *is* precisely defined.
  321. # [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.
  322. # [13:16] <Bert> Alex: Many cases: line breaks, page breaks, paragraph breaks, and any of there with or without last line behavior.
  323. # [13:16] <anne> s/langauges/languages/
  324. # [13:16] <Bert> Alex: Seems we need 'display: break'
  325. # [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."
  326. # [13:18] <Bert> Anne: Just adding 'display: block' when needed to make an element into a page break element is not a big deal.
  327. # [13:19] <Bert> Daniel: Consider editing perspective. It's easy to insert an empty element.
  328. # [13:19] <fantasai> br { white-space: pre; content: '\A'; }
  329. # [13:19] <Bert> Fantasai: Just insert an empty element with both page break and display:block
  330. # [13:19] <fantasai> br[type="page"] { display: block; content: none; page-break-before: always; }
  331. # [13:20] <Bert> Daniel: But we can't reproduce HTML's BR in XML.
  332. # [13:20] <Bert> Hakon: Yes you can, the sample style sheet shows how.
  333. # [13:21] <Bert> Fantasai: Anne and I are saying that you can get the functionality you want in XML.
  334. # [13:21] <fantasai> Fantasai: just without the quirkcs
  335. # [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.
  336. # [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.
  337. # [13:24] <Bert> Hakon: Can solve that with selectors, BR + BR.
  338. # [13:24] <anne> http://www.joelonsoftware.com/articles/fog0000000018.html
  339. # [13:25] <Bert> Fantasai: The quirky behavior of BR is that 'clear' applies.
  340. # [13:25] <Bert> Peter: Now imagine I want to set 'content' on my BR, I lose the line breaking behavior.
  341. # [13:25] <Bert> Several: Just add the \A as well.
  342. # [13:26] <Bert> Peter: I want an extra property, or a 'display' value, for BR.
  343. # [13:27] <Bert> Hakon: But that doesn't work in current browsers.
  344. # [13:28] <Bert> Steve comes back to what "inline" means, doesn't think a \A can be called "inline."
  345. # [13:29] <Bert> Fantasai: So you don't want to call the span in "<pre>foo <span>[linebreak]</span> bar</pre>" inline? In CSS it is defined as inline.
  346. # [13:29] <Bert> Daniel: The width of the line box before the break is different.
  347. # [13:29] <fantasai> s/[linebreak]/test[linebreak]test/
  348. # [13:30] <Bert> Hakon: Really? And does that matter at all?
  349. # [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.
  350. # [13:31] <Bert> Saloni: Do we all agree that page break applies to BR, independent of how we explain it?
  351. # [13:32] <Bert> Bert: No, don't make exceptions for HTML.
  352. # [13:32] <Bert> Alex: We (IE) have a special 'display' tupe (more or less) for BR.
  353. # [13:32] <Bert> Hakon: What then happens in IE if I set :before{content:"\A"} on the BR?
  354. # [13:34] <Bert> Hakon: Is that display type hardcoded? Or can you override it with a style rule?
  355. # [13:34] <Bert> Steve: Can you change BR to list-item?
  356. # [13:34] <Bert> Hakon: Should work in Opera, yes.
  357. # [13:34] <Bert> Peter: How can a user override the rules?
  358. # [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.,
  359. # [13:36] <Bert> Hakon: That works in Opera.
  360. # [13:36] <Bert> Peter: I also want the way to override it consistent among browsers.
  361. # [13:36] <Bert> Daniel: That's not the question we are discussing. We started with page breaks...
  362. # [13:37] <Bert> Peter: And I don't want to use the 'content' proeprty.
  363. # [13:37] <Bert> Hakon: Why not?
  364. # [13:37] <Bert> No resolution for issue 52 right now.
  365. # [13:39] <Bert> David: If we decide for 'display: break', we can say that it applies to BR and in level 3 we can say that page-break and clear applies to elements with that display type.
  366. # [13:40] <Bert> Alex: We can just say in 2.1 that level 3 will provide a more generic approach.
  367. # [13:40] <Bert> Peter: I think we need the Markus principle again, because we cannot define it better in CSS 2.1.
  368. # [13:42] <Bert> Strawpoll proposed question: Should page-break-before/afetr apply to BR in CSS 2.1?
  369. # [13:42] <Bert> Peter: Make it more generic, and ask about a BR-like element instead of BR itself?
  370. # [13:42] <anne> -- <br> --
  371. # [13:42] <fantasai> <br type='lunch'>
  372. # [13:42] <glazou> <br type="LUNCH">
  373. # [14:34] * Joins: jason_cranfordtea (jason_cran@64.236.128.12)
  374. # [14:41] <fantasai> hi jason_cranfordtea!!
  375. # [14:41] <jason_cranfordtea> hey
  376. # [14:42] <fantasai> jason_cranfordtea: we had a long discussion about font-weight today. I assure you you wouldn't have wanted to listen to it all, but finally it has boiled down to a question for you and Molly.
  377. # [14:42] <jason_cranfordtea> yeah
  378. # [14:42] <jason_cranfordtea> I saw that in the transcript
  379. # [14:42] <fantasai> jason_cranfordtea: cool
  380. # [14:43] <fantasai> up, we are restarting the meeting
  381. # [14:43] <jason_cranfordtea> expected behavior of lighter and bolder
  382. # [14:43] <Bert> Read: we didn't want to leave the discussion without deciding at least something, and so we decided to ask you :-)
  383. # [14:43] <fantasai> yes
  384. # [14:43] <fantasai> when nested
  385. # [14:43] <jason_cranfordtea> so it's a question of inheritance?
  386. # [14:43] <fantasai> no
  387. # [14:43] <jason_cranfordtea> or absolute?
  388. # [14:43] <fantasai> it's a question of
  389. # [14:43] <fantasai> if you have three nested spans
  390. # [14:44] <fantasai> the outer two with 'bolder'
  391. # [14:44] <fantasai> the inner one with 'lighter'
  392. # [14:44] <fantasai> but your font only has two weights, normal and bold
  393. # [14:44] <fantasai> what is the text of the innermost span?
  394. # [14:44] <fantasai> is it normal or bold?
  395. # [14:44] <jason_cranfordtea> right
  396. # [14:44] <jason_cranfordtea> that's what I was thinking of
  397. # [14:44] <fantasai> then take that same page and render it with a font that has three weights
  398. # [14:44] <jason_cranfordtea> let me think of it
  399. # [14:45] <fantasai> the behavior should make sense to the author in both cases
  400. # [14:45] <fantasai> of course
  401. # [14:46] <SteveZ> Scribe: SteveZ
  402. # [14:46] <SteveZ> We are resuming after a lunch break
  403. # [14:46] <SteveZ> Topic: Definition of BR
  404. # [14:48] <SteveZ> This discussion is for CSS3
  405. # [14:48] <SteveZ> The definition is currently in the Generated Content draft
  406. # [14:49] <SteveZ> The content property does not apply to all elements in CSS 2.1
  407. # [14:49] <anne> (you need br { content:"\A"; ... } for cases such as <br>foobar</br> (possible in XHTML))
  408. # [14:50] <dbaron> ScribeNick: SteveZ
  409. # [14:50] <Bert> (You can do that with ':before {content: "\A"} br {content: none}' as well and still be compliant with the sample style sheet from level 2.)
  410. # [14:51] <SteveZ> Anne, listing solution mechanisms:
  411. # [14:51] <SteveZ> 1. treat the HTML <BR> element as a special HTML only case
  412. # [14:51] <SteveZ> 2. use display: block
  413. # [14:52] <fantasai> s/block/break/
  414. # [14:53] <SteveZ> Anne: using content(/A) would not make "clear" apply to the element because it would still be an inline element
  415. # [14:54] <SteveZ> 3. add a "line-break-*" properties that could apply to inlines
  416. # [14:55] <SteveZ> BB: would this mimic the current <BR> behavior w.r.t. one BR vs two BRs
  417. # [14:56] <SteveZ> EE: does "clear" apply to a run-in element, depending on what it is followed by?
  418. # [14:57] <fantasai> s/apply/apply sometimes/
  419. # [14:57] * plh is now known as plh-css
  420. # [14:57] <SteveZ> DG: requirements include avoiding a special exception for HTML and making the BR element special
  421. # [14:58] <SteveZ> EE: would it be possible to make BR be a run-in; i.e. display: runin
  422. # [14:59] <glazou> s/runin/run-in
  423. # [14:59] <SteveZ> DB: can you have multiple run-ins into the same block?
  424. # [15:00] <SteveZ> BB: if there are multiple run-ins only that last one is before the next block and has the run-in behavior
  425. # [15:00] <SteveZ> DB: note that BR adds height to the line before, note that line after.
  426. # [15:01] <SteveZ> DB: This may only apply in "quirks mode", but I am not sure about this
  427. # [15:01] * glazou needs to know how many people need to check in at the hotel today ; we probably need to end the meeting before the cancellation limit...
  428. # [15:01] <SteveZ> DB: It should not matter in standards mode unless a font-height is appled to the BR
  429. # [15:01] * fantasai call the hotel
  430. # [15:02] * glazou fantasai: that obsolete "telephone" protocol ?-)
  431. # [15:03] <SteveZ> Anne: in Opera, changing the font-size on the BR does not affect the line-height of the previous line
  432. # [15:03] <SteveZ> Anne: It does not in IE6 either
  433. # [15:04] <SteveZ> Anne: only Firefox shows the change of line-height
  434. # [15:04] <anne> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%3Cstyle%3E%20span%20{%20font-size%3A2em%20}%20%3C%2Fstyle%3E%0A...%3Cspan%3E%3Cbr%3E%3C%2Fspan%3E...
  435. # [15:04] <anne> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3E%20br%20%7B%20font-size%3A1.5em%20%7D%20%3C%2Fstyle%3E%0D%0A...%3Cbr%3E...
  436. # [15:04] <SteveZ> Anne: and the line-height change does not show up in quirks mode
  437. # [15:05] <SteveZ> Above are the test cases
  438. # [15:12] <SteveZ> HL: we have a way of defining BR in CSS, namely using the content property to insert a /A
  439. # [15:12] <SteveZ> Opera allows the content property on all elements
  440. # [15:13] <SteveZ> AM: the issue is having a definition that triggers that special behaviors of BR w.r.t. clear and page-break-*
  441. # [15:14] <SteveZ> SZ: the Opera solution does not work for clear or page-break-*
  442. # [15:15] <SteveZ> AM: is it OK to have content language (e.g. HTML) special exceptions
  443. # [15:15] <SteveZ> EE and Anne: we already have special cases
  444. # [15:16] <SteveZ> Anne: it is the element in the HtML namespace that is special cased
  445. # [15:18] <anne> What I said was that the HTML <body> element is special cased in HTML and XML (though the CSS 2.1 still needs an update regarding this)
  446. # [15:18] <SteveZ> DG: It is mandatory to have a way to put in hard line breaks, but special casing BR in HTML only is a hack that does not help in XML
  447. # [15:20] <fantasai> Steve: there four things about <br>
  448. # [15:20] <fantasai> Steve: 1. You get a line break
  449. # [15:20] * Joins: shepazu (schepers@128.30.52.30)
  450. # [15:20] <fantasai> Steve: 2. You get last-line alignement behavior in the previous line (due to the forced break)
  451. # [15:20] <fantasai> Steve: 3. Clear applies
  452. # [15:20] <fantasai> Steve: 4. Maybe page-break applies
  453. # [15:20] <fantasai> Steve: Most of these are because of the line
  454. # [15:20] <fantasai> break
  455. # [15:21] <jason_cranfordtea> Is there a reason that point 4 is not a certainty?
  456. # [15:21] <fantasai> it's not in the spec currently
  457. # [15:22] <fantasai> so it's the issue that started this whole discussion :)
  458. # [15:24] <SteveZ> Anne: if you want properties 3 and 4, you should set the display: block property on the BR
  459. # [15:24] <fantasai> Elika: The problem isn't with XML dialects. It's with backwards compatibility wrt clear on BR.
  460. # [15:24] <fantasai> Elika: In a new XML dialect, you can create a break element that behaves like <br> by using CG line breaks
  461. # [15:25] <fantasai> Elika: And if you want the element to clear (or page break) then you need to set display: block; at the same time.
  462. # [15:25] <Bert> (The "problem" is the same problem we have much too often, unfortunately: browsers have bugs and don't dare fixing them :-( )
  463. # [15:25] <fantasai> Elika: The problem we have here is that you can't do that with BR for backwards compatibility reasons
  464. # [15:25] <fantasai> Elika: Because right now you can set 'clear' without setting 'display: block;' and it works.
  465. # [15:26] <fantasai> Anne: I don't think it makes sense to spend so much time on this based on hypothetical XML vocabularies.
  466. # [15:26] <fantasai> Anne: If someone comes forward and says I need this behavior without setting 'display: block', then we can discuss it further
  467. # [15:28] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  468. # [15:29] <dbaron> <br><br><br clear="both"><br>
  469. # [15:29] <dbaron> (or do I mean "all" instead of "both"?)
  470. # [15:29] <anne> Google says all
  471. # [15:29] <dbaron> (For the record, I was saying verbally that markup like that is probably used a good bit on the Web.)
  472. # [15:31] <SteveZ> Anne and EE: you probably do not need all the quirks of BR if you are just trying to satisfy the requirement for a hard line break in XML
  473. # [15:32] <fantasai> hard line break, clear, and page-break
  474. # [15:33] <SteveZ> PL: what is wrong with adding a "break" value to display?
  475. # [15:33] <SteveZ> Anne: I think it adds more complexity, to the code and the tests
  476. # [15:33] <SteveZ> DG and PL: it simplifies the spec, because it removes all the special cases
  477. # [15:35] <SteveZ> EE: if you add the new display value, you must update the spec for the influence of this new value on the other properties.
  478. # [15:37] <fantasai> EE: If I were to define <br>, I'd define it as an inline element whose contents are a preserved line feed and to which the 'clear' property applies.
  479. # [15:38] <SteveZ> Many: it does not appear that the spec get vastly simpler whether or not you special case the <BR> element or add a "break" value
  480. # [15:39] <SteveZ> Anne: it is more difficult to test because one must test the behavior when this property value is combined with most of the other properties
  481. # [15:41] <SteveZ> BB: Since we have not needed a better defintion of BR up to now why are we so concerned about it now
  482. # [15:41] <SteveZ> SZ: becuase the issue of how does page-break-* apply
  483. # [15:43] <fantasai> SZ: What I got from this discussion is that using display: block; would satisfy the use case requirements for XML.
  484. # [15:44] <fantasai> SZ: So I would conclude that we should special-case BR, but also add a note explaining how to get similar behavior with another mechanism.
  485. # [15:46] <SteveZ> SZ: since display: block gives most of the properites that an XML document would want for a hard line break, we should adopt solution 1 with a note to explain the display: block mechanism
  486. # [15:47] <fantasai> Straw Poll for CSS2.1:
  487. # [15:47] <fantasai> 0. No change to CSS 2.1
  488. # [15:47] <SteveZ> AM: if we are adopting option 1 in CSS2.1, it can describe all the specialiality, including page-break-* behavior
  489. # [15:48] <fantasai> 1. Special-case XHTML <br> to take page-break, add a note explaining how to get it to work for other elements (by using 'display: block')
  490. # [15:48] <fantasai> Peter: I'm ok with saying that page-break also applies to "other elements", not calling out HTML:br
  491. # [15:49] <fantasai> s/1./1a./
  492. # [15:49] <SteveZ> PL: we could have a note, like that in Clear which does not call out the elements to which page-break-* applies
  493. # [15:49] <fantasai> 1b. Say page-break may apply to "other elements"
  494. # [15:52] <SteveZ> The above Straw Poll is w.r.t. Issue 52 only and not for CSS3
  495. # [15:52] <SteveZ> Furthermore, the options apply to what is said about the page-break-* properties
  496. # [15:53] <anne> s/to take page-break/to take page-break and clear/
  497. # [15:53] <anne> s/XHTML <br>/(X)HTML <br>/
  498. # [15:54] <Bert> (option 4: page break applies to all elements?)
  499. # [15:56] <SteveZ> PL: option 1b was proposed so that we can, in the future, adhere to the Markus Principle, agreeing to define in CSS3 this clearly ambiguous behavior; the behavior is, at this point, intentionally left ambiguious to reflect current implementations
  500. # [15:57] <fantasai> play: block; (or some other block-level value)
  501. # [15:58] <fantasai> 0. No normative change.
  502. # [15:58] <fantasai> Add a note to say that if you want this property to apply
  503. # [15:58] <fantasai> you have to set display: block; (or some other block-level
  504. # [15:58] <fantasai> value)
  505. # [15:58] <fantasai> 1a. Special-case HTML:br to say that page-break also applies
  506. # [15:58] <fantasai> Add a note to say that you can get page-break to apply to
  507. # [15:58] <fantasai> other break elements by saying 'display: block'.
  508. # [15:58] <fantasai> 1b. Say page-break applies to block-level elements and may
  509. # [15:58] <fantasai> also be applied to "other elements"
  510. # [15:58] <fantasai> 4. Page-break applies to all elements
  511. # [15:58] <fantasai> Howcome: 0, could live with 1a
  512. # [15:58] <fantasai> David: 1a, second choice 0
  513. # [15:58] <fantasai> Daniel: 0
  514. # [15:59] <fantasai> Saloni: 1b, then 1a
  515. # [15:59] <fantasai> John: abstain
  516. # [15:59] <glazou> Richard, PLH: abstain
  517. # [15:59] <fantasai> Steve: I can live with anything but 4
  518. # [15:59] <fantasai> Peter: 1b
  519. # [16:00] <fantasai> Alex: 50% on 1a or 1b
  520. # [16:00] <fantasai> Bert: 0, can live with 4 and 1b in that order
  521. # [16:00] <dbaron> (this is for CSS 2.1; options (2) and (3) could be relevant for css3)
  522. # [16:00] <fantasai> Elika: 0 or 1a
  523. # [16:00] <fantasai> Anne: 1a
  524. # [16:02] <fantasai> Steve: So we've observed that some implementations currently do this
  525. # [16:02] <fantasai> Steve: 2.1 should reflect what implementations do
  526. # [16:02] <fantasai> Steve: 1b seems consistent with that
  527. # [16:03] <fantasai> Steve: It seems you /may/.
  528. # [16:03] <fantasai> David: It seems unnecessarily broad to me.
  529. # [16:03] <fantasai> David: The clear definition is necessarily broad because of what CSS1 said
  530. # [16:03] <fantasai> Anne: The 'clear' part is a non-normative note. Normatively it's not allowed
  531. # [16:04] <fantasai> Peter: So to move CSS2.1 forward we either need a consensus, or we need to leave it vague and tackle in CSS3.
  532. # [16:05] <SteveZ> SZ: I thought the goal of CSS2.1 was to document what CSS implementation actually do and to be ambiguous where agreement cannot be reached; the goal of CSS3 is to remove ambiguities
  533. # [16:07] <SteveZ> BB, PL and DG: I cannot live with 1a
  534. # [16:07] <fantasai> Daniel: I see no consensus on definition of <br> or on whether page-break should apply to it
  535. # [16:09] <Bert> Daniel/Steve: How do we ask the next question, how do we find the best option that people can all live with?
  536. # [16:10] <fantasai> Fantasai: I note that 1b would allow page-break to apply to table-row elements, which we may actually want
  537. # [16:10] <SteveZ> DB: how about broadening 1b to say "may apply to inline elements"
  538. # [16:10] <fantasai> s/broadening/narrowing/
  539. # [16:11] <fantasai> Philippe: When you do a straw poll, you ask three questions: what do you want, what can you live with, what can you not live with?
  540. # [16:13] <fantasai> Straw poll: Which options can you not live with?
  541. # [16:14] <SteveZ> Everyone can live with 1b
  542. # [16:15] <SteveZ> AM and SR cannot live with 1b
  543. # [16:15] <plh-css> s/1b/0/
  544. # [16:15] <SteveZ> Anne, EE, AM, SR, DB cannot live with 0
  545. # [16:16] <dbaron> s/with 0/with 4/
  546. # [16:16] <fantasai> RESOLVED: Say that page-break "may apply" to other elements besides block-level elements
  547. # [16:27] <dbaron> http://www.metoffice.gov.uk/weather/uk/ee/cambridge_forecast_weather.html
  548. # [16:30] <glazou> http://tinyurl.com/6end6o
  549. # [16:32] <Bert> http://www.metoffice.gov.uk/weather/uk/ee/cambridge_forecast_weather_noscript.html
  550. # [16:43] <SteveZ> We returned from a break at 15:40
  551. # [16:45] <SteveZ> Topic: test harness
  552. # [16:46] <SteveZ> EE: HP is working on this, has sent a prototype
  553. # [16:47] <SteveZ> EE: can run test from groups or single tests; has option to run least tested tests first
  554. # [16:48] <SteveZ> EE: What kinds of charts should the results component generate?
  555. # [16:48] <SteveZ> PL: How are tests placed in the harness?
  556. # [16:49] <SteveZ> EE: There is a script that can be run by someone on the W3C server team to move testcases into the harness
  557. # [16:51] <SteveZ> EE: currently, everynight there is a build of the testsuite; can add to chron job to run the script
  558. # [16:51] <SteveZ> PlH: Can you add a button that says, "I think this test is incorrect" to flag tests in question
  559. # [16:52] <SteveZ> EE: We think this will not be useful for tests used by the general public; getting e-mail messages seems to work better, but still not very well.
  560. # [16:53] <SteveZ> EE: we do not yet have a good system for reviewing tests
  561. # [16:54] <SteveZ> PlH: is there a way to delete results either because the tester has a bad track record or because the test has been changed?
  562. # [16:55] <SteveZ> EE: not yet
  563. # [16:55] <SteveZ> EE: the intent is that if a test changes, all past results will be removed so there is no prior history
  564. # [16:57] <SteveZ> EE: Have a display that shows a table with the tests as the row labels and the UAs and their context as the column labels; the cells show how many checked which box on the test
  565. # [16:58] <SteveZ> EE: the tests will have metadata that will indicate if special device characteristics (e.g., 9dpi displays, letter paper, ...) to run the test. These will appear when test is selected for execution.
  566. # [16:59] <SteveZ> PlH: prior to running a series of tests, it is desirable to have the set of requirements for all the tests in the series.
  567. # [17:01] <SteveZ> SZ: The groups defined by the WG should avoid having conflicting requirements in the series
  568. # [17:02] <SteveZ> PL: there will be a Skip button on the test to allow it to be skipped because the special requirements for the test may not be met.
  569. # [17:02] <SteveZ> EE: the goal is to write the test so that they are DPI independent
  570. # [17:04] <SteveZ> EE: the goal is also to be font independent, but some tests may require the use of a standard set of public usable fonts.
  571. # [17:04] <SteveZ> EE: the tests require a blank user stylesheet.
  572. # [17:07] <SteveZ> PL: we should create one or more test that test the assumptions for the test suite
  573. # [17:07] <SteveZ> PlH: what does "full color" mean to the average user?
  574. # [17:08] <SteveZ> PlH: I would like for other groups in the Interaction Domain to be able to use this test harness
  575. # [17:11] <SteveZ> SZ: can I use the test harness in automatic mode, for example to do regression testing against stored bit maps
  576. # [17:12] <SteveZ> EE: not using the harness, but the test suite is in CVS and it can be pulled and used for anything consistent with the license.
  577. # [17:13] <SteveZ> DB: in Mozilla, we have tests that have to pieces of HTML that must either render to the same bit map or to two different bit maps
  578. # [17:14] <SteveZ> EE: the test are designed without reference rendering; the tester should read the instructions and determine the correctness of the results
  579. # [17:15] <SteveZ> EE: it would be possible to accept reference renderings, however.
  580. # [17:15] <SteveZ> JD: note that with text renderings are rarely, if ever, the same among browsers
  581. # [17:17] <SteveZ> PL: I would like to see Implementation Reports generated from the test harness results
  582. # [17:18] <plh-css> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html?rev=1.85&content-type=text/html;%20charset=iso-8859-1
  583. # [17:18] <SteveZ> SZ: when implementations are generally passing most tests, it would be useful to have the subset of tests that are still being failed
  584. # [17:20] <SteveZ> PlH: suggests that the above dashboard was useful for WSDL WG and might suggest ways to organize the CSS results (which are more complex)
  585. # [17:21] <SteveZ> PlH: one thing that was nice was to see what test assertion(s) were being failed in a given test run
  586. # [17:23] <plh-css> -> http://dev.w3.org/cvsweb/2008/test-harness/ CSS test harness
  587. # [17:24] <SteveZ> JD and EE: there is a bunch of build scripts that build the metadata and other stuff for the test harness which grabs the data from the build process
  588. # [17:25] <SteveZ> EE: one of the reasons for having a user friendly test harness is to allow volunteers to do some of the testing for this.
  589. # [17:27] * Joins: sylvaing (sylvaing@131.107.0.73)
  590. # [17:27] <SteveZ> HL: I would like to have a large page with a collection of tests in a group, perhaps using IFrames, that I can scroll thru to see the failures myself
  591. # [17:27] <SteveZ> EE: HL wants a page like DG did for selectors
  592. # [17:28] <SteveZ> EE: one can add a script to build such an IFrame test; please do not change any of the existing scripts
  593. # [17:29] <fantasai> http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/by-section.xht
  594. # [17:30] <SteveZ> EE: this is the index by section of all the tests in the CSS2.1 test suite
  595. # [17:30] <SteveZ> RI: some of the I18N tests have changed recently; are you picking these up?
  596. # [17:31] <SteveZ> EE: Ira has been working on picking up such tests, but he may be leaving soon.
  597. # [17:32] <fantasai> s/Ira/Eira/
  598. # [17:32] <fantasai> s/he/she/
  599. # [17:32] <SteveZ> EE: for tests that arrive in the wrong format, a repository will be created to store them until that can be adapted to the system
  600. # [17:33] <SteveZ> PlH: could I18N write there tests for the above test harness?
  601. # [17:35] <SteveZ> RI: right now, constructing the test in format suitable is extra work beyond what is being done by I18N (which often means me)
  602. # [17:35] <SteveZ> RI; the I18N format has multiple test per page and has additional info beyond that used by CSS
  603. # [17:37] <SteveZ> EE: there is a relatively simple template for the test; the scripts build the harness code around that test file matching that template
  604. # [17:37] <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2008Aug/0009.html
  605. # [17:37] <fantasai> http://csswg.inkedblade.net/test/css2.1/format
  606. # [17:37] <SteveZ> The above is the URL for the test template
  607. # [17:38] <SteveZ> RI: how does one indicate what the requirements for running a given test are?
  608. # [17:39] <SteveZ> RI: e.g., a special font must be loaded
  609. # [17:40] <SteveZ> EE: uncommon requirements should be in the test instructions, but this will not be pulled out in a requirements summary
  610. # [17:41] * Quits: myakura (myakura@118.8.102.216) (Quit: Leaving...)
  611. # [17:42] <SteveZ> RI: Why not have a "requirements" metatag that takes a string to be displayed as part of the requirements display
  612. # [17:43] <SteveZ> SZ: how could we internationalize such requirements strings?
  613. # [17:44] <SteveZ> EE: the other requirements that are common to many cases are coded as flags that can be internationalized
  614. # [17:46] <SteveZ> EE: the build process generates three versions of each test, 1. mostly a copy of the test, 2. an HTML file and 3. an HTML print file.
  615. # [17:48] <SteveZ> Supporting the test harnes and the test for langauges other than English is out of scope
  616. # [17:48] <SteveZ> s/harnes/harness/
  617. # [17:49] <r12a> example of what PLH is saying: http://www.w3.org/International/tests/test-encoding-detection-6
  618. # [17:51] <SteveZ> EE: agreed that files must be served with specific headers, but that is out of scope for the test harness
  619. # [17:52] <SteveZ> RI: I have a bunch of test for character encoding that require specific headers
  620. # [17:52] <fantasai> EE: The test harness doesn't contain or serve up the tests. They need to be hosted elsewhere. The test harness just links to them
  621. # [17:52] <fantasai> EE: If you have special hosting requirements, you need to set those up where the tests are hosted. There's no interaction there with the test harness
  622. # [17:53] <SteveZ> EE: the test harness just links to the test; therefore it is the server on which the tests are stored that is responsible for generating the correct headers
  623. # [17:54] <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2008Jul/0000.html
  624. # [17:55] * Joins: dsinger (dsinger@217.167.116.128)
  625. # [17:55] <SteveZ> The above URL is a message about the BiDi test that were being converted for the test harness
  626. # [17:57] <SteveZ> That completes this topic
  627. # [17:59] <glazou> dsinger: we just adjourned the meeting for the day !
  628. # [18:00] <SteveZ> The meeting is now adjouned for the day
  629. # [18:00] * Quits: glazou (daniel@213.199.146.138) (Quit: glazou)
  630. # [18:04] * Quits: plh-css (plh@128.30.52.28) (Quit: Ex-Chat)
  631. # [18:04] * Quits: jdaggett (jdaggett@213.199.146.138) (Quit: jdaggett)
  632. # [18:11] * Quits: dsinger (dsinger@217.167.116.128) (Quit: dsinger)
  633. # [18:11] * Quits: alexmog (alexmog@131.107.0.77) (Ping timeout)
  634. # [18:12] * Quits: plinss_ (plinss_uk@213.199.146.138) (Quit: plinss_)
  635. # [18:13] * Quits: SteveZ (d5c7928a@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  636. # [18:14] * Parts: anne (annevk@213.199.146.138)
  637. # [18:15] * Quits: r12a (ishida@128.30.52.30) (Ping timeout)
  638. # [18:18] * Quits: dbaron (dbaron@213.199.146.138) (Ping timeout)
  639. # [18:36] * Joins: alexmog (alexmog@78.25.227.19)
  640. # [18:42] * Quits: alexmog (alexmog@78.25.227.19) (Ping timeout)
  641. # [18:55] * Parts: jason_cranfordtea (jason_cran@64.236.128.12)
  642. # [19:57] * Joins: jdaggett (jdaggett@131.111.225.1)
  643. # [21:06] * Quits: sylvaing (sylvaing@131.107.0.73) (Ping timeout)
  644. # [21:12] * Joins: sylvaing (sylvaing@131.107.0.75)
  645. # [22:56] * Quits: arronei (arronei@131.107.0.72) (Ping timeout)
  646. # [23:01] * Joins: arronei (arronei@131.107.0.71)
  647. # [23:42] * Joins: shepazu (schepers@128.30.52.30)
  648. # [23:47] * Quits: sylvaing (sylvaing@131.107.0.75) (Quit: sylvaing)
  649. # [23:51] * Joins: plinss_ (plinss_uk@217.41.49.207)
  650. # [23:58] * Quits: melinda (melinda.gr@67.142.45.126) (Quit: melinda)
  651. # Session Close: Thu Aug 21 00:00:00 2008

The end :)