/irc-logs / w3c / #css / 2009-06-04 / end

Options:

  1. # Session Start: Thu Jun 04 00:00:00 2009
  2. # Session Ident: #css
  3. # [00:41] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  4. # [01:15] * Quits: arronei (arronei@131.107.0.112) (Client exited)
  5. # [01:15] * Joins: arronei (arronei@131.107.0.114)
  6. # [01:34] * Quits: myakura (myakura@122.29.15.50) (Quit: Leaving...)
  7. # [03:47] * RRSAgent excuses himself; his presence no longer seems to be needed
  8. # [03:47] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
  9. # [04:31] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  10. # [05:13] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  11. # [07:04] * Joins: ChrisL (ChrisL@128.30.52.30)
  12. # [07:31] * Quits: ChrisL (ChrisL@128.30.52.30) (Ping timeout)
  13. # [08:01] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  14. # [08:04] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  15. # [08:06] * Joins: annevk (opera@82.227.229.89)
  16. # [08:18] * Quits: jdaggett (jdaggett@82.242.111.184) (Quit: jdaggett)
  17. # [08:29] * Joins: jdaggett (jdaggett@82.242.111.184)
  18. # [08:46] * Joins: mollydotcom (molly@193.51.208.72)
  19. # [08:48] * Quits: jdaggett (jdaggett@82.242.111.184) (Quit: jdaggett)
  20. # [08:55] * Quits: annevk (opera@82.227.229.89) (Quit: annevk)
  21. # [09:05] * Joins: alexmog (alexmog@193.51.208.72)
  22. # [09:18] * Quits: mollydotcom (molly@193.51.208.72) (Quit: mollydotcom)
  23. # [09:22] * Joins: sylvaing (sylvaing@131.107.0.114)
  24. # [09:27] * Quits: sylvaing (sylvaing@131.107.0.114) (Ping timeout)
  25. # [09:28] * Joins: dbaron (dbaron@193.51.208.72)
  26. # [09:28] * Joins: mollydotcom (molly@193.51.208.72)
  27. # [09:30] * Joins: glazou (glazou@193.51.208.72)
  28. # [09:30] <glazou> hi
  29. # [09:30] <dbaron> trackbot, start meeting
  30. # [09:30] * trackbot is starting a teleconference
  31. # [09:30] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  32. # [09:30] <RRSAgent> logging to http://www.w3.org/2009/06/04-CSS-irc
  33. # [09:30] <trackbot> RRSAgent, make logs member
  34. # [09:30] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  35. # [09:30] <RRSAgent> I have made the request, trackbot
  36. # [09:30] <trackbot> Zakim, this will be Style_CSS FP
  37. # [09:30] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
  38. # [09:30] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
  39. # [09:30] <trackbot> Date: 04 June 2009
  40. # [09:30] <dbaron> Zakim, remind us in 8 hours to go home
  41. # [09:30] <Zakim> ok, dbaron
  42. # [09:31] * Joins: sylvaing (sylvaing@193.51.208.72)
  43. # [09:31] <sylvaing> scribenick:sylvaing
  44. # [09:31] <sylvaing> topic: gcpm
  45. # [09:31] <sylvaing> hakon: at last f2f, changes to the draft included: image res property, list of features for WD
  46. # [09:31] * Joins: ChrisL (ChrisL@128.30.52.30)
  47. # [09:32] <dbaron> Present: Sylvain Galineau, Steve Zilles, Daniel Glazman, Bert Bos, Anne van Kesteren, Alex Mogilevsky, Håkon Wium Lie, Molly Holzschlag, Elika Etemad, Arron Eicholtz, Chris Lilley, David Baron
  48. # [09:32] <sylvaing> hakon: i proposed to drop anything that has to do with moving elements
  49. # [09:33] * Joins: Arron (arronei@193.51.208.72)
  50. # [09:33] <sylvaing> hakon: floating into footnotes remain
  51. # [09:33] <sylvaing> hakon: moving elements may conflict with generated content
  52. # [09:34] <sylvaing> hakon: what's left now is mostly implemented by two UAs
  53. # [09:34] <sylvaing> hakon: Prince and Antenna House
  54. # [09:37] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  55. # [09:40] <sylvaing> (hakon showing updated GCPM spec)
  56. # [09:40] <sylvaing> hakon: dropping moving elements e.g. target-text
  57. # [09:41] <sylvaing> hakon: one issue is what do we do with advanced multicolumn features since no one has implemented it
  58. # [09:43] <sylvaing> discussion of CMYK and whether it makes sense for publishing
  59. # [09:44] <sylvaing> hakon: this is customer requirement to produce PDFs for instance
  60. # [09:44] <sylvaing> chrisl: this should really be called device cmyk
  61. # [09:45] <sylvaing> chrisl: there is a standard to specify color profiles
  62. # [09:45] <sylvaing> ACTION: review GCPM CMYK (section 16) and suggest changes/improvements (ChrisL)
  63. # [09:45] * trackbot noticed an ACTION. Trying to create it.
  64. # [09:45] <trackbot> Sorry, couldn't find user - review
  65. # [09:45] * RRSAgent records action 1
  66. # [09:47] <sylvaing> hakon: note that character substitution (text-replace) "applies only to batch processors"
  67. # [09:47] * Joins: szilles (chatzilla@193.51.208.72)
  68. # [09:47] <dbaron> http://dev.w3.org/csswg/css3-gcpm/#text-replace
  69. # [09:47] <sylvaing> szilles, others: what is a batch processor ?
  70. # [09:48] * Joins: howcome (howcome@193.51.208.72)
  71. # [09:48] <sylvaing> dglazman, chrisl: non-interactive agent
  72. # [09:48] <howcome> http://dev.w3.org/csswg/css3-gcpm/#text-replace
  73. # [09:49] <sylvaing> hakon: note that "This property is evaluated after the content property and before text-transform....it is applied after the white-space property"
  74. # [09:49] <sylvaing> dglazman: this is useful for localization. but is it style ?
  75. # [09:50] <sylvaing> dglazman: why not keep the feature, remove the batch processor qualifier and put it at risk ?
  76. # [09:51] <sylvaing> glazou: alternatively, we need a profile or a statement that interactive rendering engines are not required to support the feature
  77. # [09:51] <sylvaing> fantasai: I don't think it belongs to CSS. it changes content.
  78. # [09:52] <sylvaing> glazou: if not then the content property is not a style property either
  79. # [09:53] <sylvaing> chrisl, hakon: this property does not alter the DOM
  80. # [09:53] <dbaron> "This property is applied after the ‘white-space’ property." needs to be defined much more carefully, since 'white-space' applies at multiple stages of the processing model
  81. # [09:55] <sylvaing> ACTION: howcome to rewrite scope of character substitution; from batch processors to not requiring support from interactive rendering engines
  82. # [09:55] * trackbot noticed an ACTION. Trying to create it.
  83. # [09:55] * RRSAgent records action 2
  84. # [09:55] <trackbot> Created ACTION-150 - Rewrite scope of character substitution; from batch processors to not requiring support from interactive rendering engines [on Håkon Wium Lie - due 2009-06-11].
  85. # [09:55] <sylvaing> ACTION: chrisl to review GCPM CMYK (section 16) and suggest changes/improvements
  86. # [09:55] * RRSAgent records action 3
  87. # [09:55] * trackbot noticed an ACTION. Trying to create it.
  88. # [09:55] <trackbot> Created ACTION-151 - Review GCPM CMYK (section 16) and suggest changes/improvements [on Chris Lilley - due 2009-06-11].
  89. # [09:58] <sylvaing> (discussion follows of text processing issues deemed beyond the grasp of 'normal people'; minute-taker assumes he's one of them)
  90. # [10:00] * Joins: jdaggett (jdaggett@193.51.208.72)
  91. # [10:00] <dbaron> Present+: John Daggett
  92. # [10:00] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  93. # [10:06] <sylvaing> discussion about a more complete cascading transformation language that would be more useful to printers and drop the feature from the WD
  94. # [10:07] <sylvaing> glazman: this is not a stylistic feature and therefore belongs outside the specification
  95. # [10:15] <sylvaing> glazman: we can keep as is and scope it to make it optional for interactive rendering engines; or we drop the section from GCPM
  96. # [10:16] <sylvaing> hakon: i'm not comfortable with dropping something that is both pragmatic and useful to printers today
  97. # [10:18] * Quits: ChrisL (ChrisL@128.30.52.30) (Quit: Fire on main board error, client combusted)
  98. # [10:18] <sylvaing> dbaron: as an inherited property, i'm not sure it'd make sense to use it more than once per document
  99. # [10:18] * Joins: ChrisL (ChrisL@128.30.52.30)
  100. # [10:19] <sylvaing> glazman: which brings us some other issues about the feature e.g. whether it's inherited or not
  101. # [10:19] <sylvaing> s/glazman/glazou
  102. # [10:22] <sylvaing> fantasai: the main issue is tha the feature as specified is is incomplete/insufficient and will be hard to complete within the context of CSS
  103. # [10:29] <sylvaing> glazou: third option for the property is to scope it to @media print
  104. # [10:29] <sylvaing> anne: does this mean browsers have to implement it for print ?
  105. # [10:29] <anne> [apparently yes]
  106. # [10:31] <sylvaing> vote: dbaron #2, chrisl #2, arronei #2, elika #2, molly abstains, hakon not 2, alex #2, anne abstains, bert #2, dglazman #2, szilles #2, sylvaing #3
  107. # [10:31] <sylvaing> options were
  108. # [10:31] <sylvaing> #1 scope feature to exclude rendering engines
  109. # [10:31] <sylvaing> #2 drop feature
  110. # [10:32] <sylvaing> #3 like #1 + restrict to @media print
  111. # [10:35] <sylvaing> alexmog: my problem with this doesn't have anything to do with what it does or why but the state of the feature wrt the rest of the spec. I can't implement it as is and I'd rather implement a spec completely
  112. # [10:41] <sylvaing> RESOLVED: character substitution is dropped out of the GCPM working draft
  113. # [10:43] * Quits: Arron (arronei@193.51.208.72) (Connection reset by peer)
  114. # [10:54] * Joins: Arron (arronei@193.51.208.72)
  115. # [10:56] <sylvaing> WG proceeds with quick review of GCPM sections to decide its publication as a WD
  116. # [10:58] <dbaron> Hmm, now that we have leaders and leading I wonder if we could get some other variants of either of the base words so we can confuse ourselves more. :-)
  117. # [11:00] * glazou mentions the Talmud as a good example for multiple footnotes :-)
  118. # [11:04] <sylvaing> fantasai: two issues about footnotes. 1) steve's comment about multicolumn footnotes and 2) what happens to footnotes in scrolling media
  119. # [11:05] <sylvaing> fantasai: specifically, where is the footnote box in the document in that case ?
  120. # [11:06] <glazou> (ongoing discussion about css3-gcpm)
  121. # [11:09] <sylvaing> renaming border-parts to border-clip
  122. # [11:15] <sylvaing> ACTION: howcome to compare and reconcile GCPM border-clip syntax with border-image's
  123. # [11:15] * trackbot noticed an ACTION. Trying to create it.
  124. # [11:15] * RRSAgent records action 4
  125. # [11:15] <trackbot> Created ACTION-152 - Compare and reconcile GCPM border-clip syntax with border-image's [on Håkon Wium Lie - due 2009-06-11].
  126. # [11:15] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  127. # [11:19] <dbaron> 00B9;SUPERSCRIPT ONE;No;0;EN;<super> 0031;;1;1;N;SUPERSCRIPT DIGIT ONE;;;;
  128. # [11:19] <dbaron> 00B2;SUPERSCRIPT TWO;No;0;EN;<super> 0032;;2;2;N;SUPERSCRIPT DIGIT TWO;;;;
  129. # [11:19] <dbaron> 00B3;SUPERSCRIPT THREE;No;0;EN;<super> 0033;;3;3;N;SUPERSCRIPT DIGIT THREE;;;;
  130. # [11:19] <dbaron> 2074;SUPERSCRIPT FOUR;No;0;EN;<super> 0034;;4;4;N;SUPERSCRIPT DIGIT FOUR;;;;
  131. # [11:19] <dbaron> 2075;SUPERSCRIPT FIVE;No;0;EN;<super> 0035;;5;5;N;SUPERSCRIPT DIGIT FIVE;;;;
  132. # [11:19] <dbaron> 2076;SUPERSCRIPT SIX;No;0;EN;<super> 0036;;6;6;N;SUPERSCRIPT DIGIT SIX;;;;
  133. # [11:19] <dbaron> 2077;SUPERSCRIPT SEVEN;No;0;EN;<super> 0037;;7;7;N;SUPERSCRIPT DIGIT SEVEN;;;;
  134. # [11:19] <dbaron> 2078;SUPERSCRIPT EIGHT;No;0;EN;<super> 0038;;8;8;N;SUPERSCRIPT DIGIT EIGHT;;;;
  135. # [11:19] <dbaron> 2079;SUPERSCRIPT NINE;No;0;EN;<super> 0039;;9;9;N;SUPERSCRIPT DIGIT NINE;;;;
  136. # [11:19] <dbaron> 2070;SUPERSCRIPT ZERO;No;0;EN;<super> 0030;;0;0;N;SUPERSCRIPT DIGIT ZERO;;;;
  137. # [11:24] <dbaron> we should probably be adding this new type to http://dev.w3.org/csswg/css3-lists/#numeric as well
  138. # [11:25] <fantasai> yeah
  139. # [11:33] <fantasai> http://dev.w3.org/csswg/css3-lists/#super-decimal
  140. # [11:38] <sylvaing> ACTION: howcome fantasai to move super-decimal counter type from GCPM to Lists
  141. # [11:38] * trackbot noticed an ACTION. Trying to create it.
  142. # [11:38] * RRSAgent records action 5
  143. # [11:38] <trackbot> Created ACTION-153 - Fantasai to move super-decimal counter type from GCPM to Lists [on Håkon Wium Lie - due 2009-06-11].
  144. # [11:38] <sylvaing> previous action is on howcome+fantasai
  145. # [11:50] <sylvaing> ACTION-153 should be removed. instead....
  146. # [11:50] <sylvaing> RESOLVED: super-decimal counter type moves from GCPM to Lists
  147. # [11:55] * Quits: szilles (chatzilla@193.51.208.72) (Client exited)
  148. # [12:02] <anne> fwiw "It's easier to ask forgiveness than it is to get permission"
  149. # [12:03] <sylvaing> ACTION: chrisl to email plinss regarding the removal from CSS2.1 of 'without reliable resolution information' from intrinsic dimensions definition in section 3.1
  150. # [12:03] * trackbot noticed an ACTION. Trying to create it.
  151. # [12:03] * RRSAgent records action 6
  152. # [12:03] <trackbot> Created ACTION-154 - Email plinss regarding the removal from CSS2.1 of 'without reliable resolution information' from intrinsic dimensions definition in section 3.1 [on Chris Lilley - due 2009-06-11].
  153. # [12:03] <anne> (i.e. just make the change)
  154. # [12:05] <sylvaing> (actually, we want Peter and HP's opinion)
  155. # [12:06] <anne> (Are we skipping css3-flexbox and Fonts?)
  156. # [12:07] <sylvaing> (text-replace: "css3-flexbox" "gcpm")
  157. # [12:08] <anne> heh
  158. # [12:11] <sylvaing> RESOLVED: GCPM page-bleed renamed to bleed
  159. # [12:16] <sylvaing> RESOLVED: keep page floats in the GCPM WD
  160. # [12:20] <sylvaing> szilles: I am concerned about the clarity of the dependencies between our outstanding drafts
  161. # [12:21] <sylvaing> szilles: while i'm happy to publish this as a working draft, I'm concerned on our ability to resolve and fix the issues and conflicts that may arise due to those dependencies
  162. # [12:23] <sylvaing> hakon: should we rename this module ?
  163. # [12:23] <sylvaing> chrisl: garbace collection placeholder module ?
  164. # [12:23] <sylvaing> (laughter)
  165. # [12:24] <ChrisL> s/garbace/garbage/
  166. # [12:24] <sylvaing> text-replace: "garbace" "garbage";
  167. # [12:24] <glazou> lol
  168. # [12:27] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
  169. # [12:27] * Quits: jdaggett (jdaggett@193.51.208.72) (Quit: jdaggett)
  170. # [12:28] * Joins: glazou (glazou@193.51.208.72)
  171. # [12:28] * Quits: mollydotcom (molly@193.51.208.72) (Quit: mollydotcom)
  172. # [12:29] <sylvaing> <lunch />
  173. # [12:30] * Quits: Arron (arronei@193.51.208.72) (Ping timeout)
  174. # [12:31] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
  175. # [12:33] * Joins: glazou (glazou@193.51.208.72)
  176. # [12:44] * Joins: mollydotcom (molly@90.52.22.95)
  177. # [12:45] * Parts: mollydotcom (molly@90.52.22.95)
  178. # [12:51] * Quits: alexmog (alexmog@193.51.208.72) (Ping timeout)
  179. # [13:02] * Joins: myakura (myakura@122.29.15.50)
  180. # [13:31] * Quits: sylvaing (sylvaing@193.51.208.72) (Ping timeout)
  181. # [13:44] * Joins: jdaggett (jdaggett@193.51.208.72)
  182. # [13:47] <anne> jdaggett, you can use javascript:alert(navigator.userAgent)
  183. # [13:51] * Joins: sylvaing (sylvaing@193.51.208.72)
  184. # [13:51] * Joins: alexmog (alexmog@193.51.208.72)
  185. # [13:52] * Joins: Arron (arronei@193.51.208.72)
  186. # [13:53] <fantasai> ScribeNick: fantasai
  187. # [13:53] <fantasai> Topic: Flexbox
  188. # [13:54] <dbaron> http://dev.w3.org/csswg/css3-flexbox/
  189. # [13:54] <fantasai> dbaron: we resolved to publish this awhile ago
  190. # [13:54] <fantasai> but it took me awhile to get it into the right format
  191. # [13:54] <fantasai> dbaron: The editor token passed through a lot of revisions
  192. # [13:54] <fantasai> dbaron: The most recent one had a lot of examples removed
  193. # [13:54] <fantasai> dbaron: and also a lot of prose change
  194. # [13:54] <fantasai> dbaron: So somebody ought to evaluate those changes
  195. # [13:55] <fantasai> dbaron: but I also want to get published, because we've been discussing this a lot
  196. # [13:55] <fantasai> dbaron: There are other related proposals too, but I'd like to publish what we have, just to get a draft out
  197. # [13:55] <fantasai> Daniel: Any outstanding issues we should address before publishing?
  198. # [13:56] <fantasai> dbaron: The major issue is interaction with other layout proposals
  199. # [13:56] <fantasai> discussion of Ian's affiliation
  200. # [13:56] <fantasai> Daniel: We preserve the affiliation at the time of the work being done
  201. # [13:57] <fantasai> Alex: Can you give me a summary?
  202. # [13:57] <fantasai> dbaron: A flexible box has children laid out either horizontally or vertically
  203. # [13:57] <fantasai> dbaron: You have a property to choose which direction they go in
  204. # [13:58] <fantasai> dbaron: What you do with the extra space ...
  205. # [13:58] * sylvaing thinks of Ghostbusters everytime someone says 'XUL'. Very annoying.
  206. # [13:58] <fantasai> dbaron: In the dimension the children are laid out in, you can put the space at the beginning, at the end, center the children, or spread the space out
  207. # [13:59] <fantasai> dbaron: Then in the direction that's not the direction you're laying out, you can align the children to one side or the other
  208. # [13:59] <fantasai> dbaron: You can also assign flex to some or all of the children
  209. # [13:59] <fantasai> dbaron: flex controls where the space gets distributed
  210. # [13:59] <fantasai> dbaron: That I think is the part that is implemented in both Mozilla and Webkit
  211. # [13:59] <fantasai> dbaron: There's an unimplemented box-ordinal part
  212. # [14:00] <fantasai> dbaron: Which lets you say that flex goes to groups of elements in priorities
  213. # [14:00] <fantasai> dbaron: I'm not actually sure of the details, and the spec is all we have to go on wrt what it was intended to be because nobody implemented it
  214. # [14:00] <fantasai> dbaron: A lot of the sizes by default, without flex, deal with intrinsic sizes
  215. # [14:00] <fantasai> dbaron: You can sometimes flex down instead of up
  216. # [14:01] <fantasai> dbaron: Because usually you use the preferred width, but you can flex things down to the minimum width
  217. # [14:01] <fantasai> dbaron: There's also another piece that wasn't implemented, box-lines, that allows boxes to lay out in multiple lines
  218. # [14:01] <fantasai> dbaron: The draft might be short on mathematical details for things like preferred and minimum widths...
  219. # [14:02] <fantasai> dbaron: and some of that is its interaction with other parts of the CSS box model
  220. # [14:02] <fantasai> Alex: This is already implemented?
  221. # [14:02] <fantasai> dbaron: yes
  222. # [14:02] <fantasai> Alex: You don't know how it interacts with other models?
  223. # [14:02] <fantasai> dbaron: To some extent, not very well.
  224. # [14:02] <fantasai> dbaron: The important use cases... the one's where you really care about interaction with other models
  225. # [14:02] <fantasai> dbaron: The main one is putting a chunk of block-and-inline layout inside a xul flexbox
  226. # [14:03] <fantasai> dbaron: the other is building some widget-like thing that goes inside HTML
  227. # [14:03] <fantasai> dbaron: In the first case, essentially what you're doing is most of the time the chunk of block-and-inline layout takes up all the available space
  228. # [14:03] <fantasai> dbaron: so you're not using its intrinsic width
  229. # [14:03] <fantasai> dbaron: The not-ver-well understood case is when you're using the intrinsic width for this
  230. # [14:04] <fantasai> dbaron: but shrink-to-fit.... it doesn't work very well half the time in the cases where we use it,too ????
  231. # [14:04] <fantasai> dbaron: .... in floats, most of the time authors give a width
  232. # [14:04] <fantasai> Alex: The challenge is to define the behavior of what David refers to as not very well
  233. # [14:04] <fantasai> Alex: The scenarios that we weouldn't really care about for the purposes of this
  234. # [14:05] <fantasai> dbaron: I think some of that is just getting a definition so everybody does the same thing, nevermind trying to figure out something good to do
  235. # [14:05] <fantasai> Alex: So this is flex layout, but also float:right or tables.. are there issues with that?
  236. # [14:05] <fantasai> dbaron: This is triggered by an additional value of the display property. If you float it, it's a block, no longer a flexbox.
  237. # [14:06] <fantasai> Alex: this is used to create layout. Is this a complete layout model that is good for building user interfaces, or are there other pieces that you'd want?
  238. # [14:06] <fantasai> dbaron: This draft does not have the grids that we use in it
  239. # [14:07] <fantasai> dbaron: The firefox UI is built using the primitives here plus a grid that sort of works the same way, except it lays out its children in both dimensions instead of one
  240. # [14:07] <fantasai> anne says something about tables
  241. # [14:07] <fantasai> dbaron: Our grids are weird, because they're neither row-primary or column-primary
  242. # [14:07] <fantasai> dbaron: I don't know if it's something we'd be happy standardizing
  243. # [14:07] <fantasai> jdaggett: good weird or bad weird?
  244. # [14:07] <fantasai> dbaron: some of both
  245. # [14:08] <fantasai> dbaron: you can have a grid, give it a set of rows, then a set of columns
  246. # [14:08] <fantasai> anne: They overlap?
  247. # [14:08] <fantasai> dbaron: yes (?)
  248. # [14:08] <fantasai> Chris: It might be useful to give some background on what XUL uses
  249. # [14:09] <fantasai> Daniel: you can also say it's already implemented and this is a standardization of the model use by XUL
  250. # [14:09] <fantasai> anne: I still think it's confusing that Ian Hickson is listed as active editor and from Opera Software
  251. # [14:09] <fantasai> Daniel: We can write formerly of Opera Software, or list him as a Previous Editor
  252. # [14:09] <fantasai> people prefer Previous Editor
  253. # [14:10] <fantasai> Alex: I don't think it conflicts with grid-positioning. Overlaps, probably yes
  254. # [14:10] <fantasai> dbaron: I think there's a lot of overlap
  255. # [14:10] <fantasai> dbaron: There's been some discussion on www-style about ways to do flex in other things rather than just the box
  256. # [14:10] <fantasai> dbaron: For example, making margins flexible
  257. # [14:11] <fantasai> dbaron: Some people have been saying flex could be units.. there have been a lot of ideas thrown in here
  258. # [14:11] <fantasai> Daniel: From my experience building apps with XUL, what we have here is adequate
  259. # [14:12] <fantasai> fantasai: You'd have to use a lot of extra elements
  260. # [14:12] <fantasai> dbaron: Yeah, in XUL you typically use spacer elements
  261. # [14:12] <fantasai> jdaggett: Is there interest at Apple for doing more with this?
  262. # [14:12] <fantasai> dbaron: I think so. I think they use this in things like iPhone apps
  263. # [14:13] <fantasai> dbaron: and widget things that use WebKit
  264. # [14:13] <fantasai> Anne: Opera has interest in adding a third implementation, if it's better defined than now
  265. # [14:13] <fantasai> Anne: We haven't started because we think adding a third implementation of vagueness wouldn't be a good idea
  266. # [14:14] <fantasai> RESOLVED: Change Ian's editor's status and publish flexbox as FPWD
  267. # [14:16] <fantasai> Topic: Vertical-align issue
  268. # [14:16] <fantasai> Steve: I had an action item to come up with more testcases
  269. # [14:18] <fantasai> ACTION: Steve post testcase to www-style
  270. # [14:18] * RRSAgent records action 7
  271. # [14:18] * trackbot noticed an ACTION. Trying to create it.
  272. # [14:18] <trackbot> Created ACTION-155 - Post testcase to www-style [on Steve Zilles - due 2009-06-11].
  273. # [14:18] <fantasai> Steve loads his testcase into Safari, IE, and Firefox
  274. # [14:18] <fantasai> Steve: I've got Opera somewhere else...
  275. # [14:19] <fantasai> Steve: Basically the issue was, if I've got large things that are bottom and top aligned, where does the text show up?
  276. # [14:19] <fantasai> Steve: The arrow points up if it's top-aligned, down if it's bottom-aligned
  277. # [14:19] <fantasai> Steve: On all of these, they're the same but
  278. # [14:20] <fantasai> Steve: if I pick up Opera ...
  279. # [14:20] <fantasai> Steve: What we can tell is, if I have only one object that is top or bottom aligned, it makes a difference to these various things
  280. # [14:20] <fantasai> Testcase 1 shows TEST plus an arrow pointing up
  281. # [14:21] <fantasai> all browsers align the top of the text aligned to the top of the container
  282. # [14:21] <fantasai> Testcase 2 shows TEST plus an arrown down
  283. # [14:21] <fantasai> Safari, IE, and Firefox bottom-align TEST, but Opera top-aligns it
  284. # [14:24] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  285. # [14:24] <fantasai> Testcase 3 shows TEST plus an arrow up followed by an arrow down
  286. # [14:25] <fantasai> All but Firefox align TEST to the top; Firefox aligns it down
  287. # [14:25] <fantasai> Testcase 4 shows TEST plus an arrow down followed by an arrow up
  288. # [14:26] <fantasai> All but Opera align TEST to the bottom; Opera aligns it to the top
  289. # [14:26] * ChrisL loves "firefox is kind of like anti-opera"
  290. # [14:26] <fantasai> Testcase 5 shows TEST plus a tall arrow up followed by a short arrow down
  291. # [14:27] <fantasai> TEST is aligned to the top in all but Firefox
  292. # [14:27] <fantasai> Firefox shifts TEST down about 1em
  293. # [14:28] <fantasai> dbaron: It looks like Firefox, whenever it sees something bottom-aligned, it pushes the root so that it's bottom-aligned
  294. # [14:28] <fantasai> dbaron: But it does so only for the height of the things that are bottom-aligned
  295. # [14:28] <fantasai> dbaron: It's pushing the root down to match the bottom-aligned thing, assuming there are no top-aligned things
  296. # [14:29] <fantasai> Testcase 6 shows TEST plus a tall arrow down followed by a short arrow up
  297. # [14:29] <fantasai> All but Opera aligns to the bottom; Opera aligns to the top
  298. # [14:30] <fantasai> Testcase 7 shows TEST plus a short arrow up followed by a tall arrow down
  299. # [14:30] <fantasai> Safari aligns TEST about 1em above the bottom
  300. # [14:31] <fantasai> IE aligns TEST to the bottom
  301. # [14:31] <fantasai> Opera aligns TEST to the top
  302. # [14:31] <fantasai> Firefox aligns TEST to the bottom
  303. # [14:31] <fantasai> Steve: Opera always aligns to the top
  304. # [14:32] <fantasai> Steve: IE seems to be aligning to the biggest thing
  305. # [14:32] <fantasai> Steve: What Safari is doing here seems to be similar to what mozilla is doing, except the other way around
  306. # [14:33] <fantasai> Testcase 8 shows TEST plus a short arrow down followed by a tall arrow up
  307. # [14:33] <fantasai> Safari aligns TEST about 1em below the top
  308. # [14:33] <fantasai> IE aligns to the top
  309. # [14:33] <fantasai> Opera aligns to the top
  310. # [14:33] <fantasai> Firefox aligns TEST about 1em below the top
  311. # [14:34] <fantasai> General agreement that IE's behavior seems to make the most sense
  312. # [14:34] <fantasai> dbaron: So the largest wins, but if there are multiple the same size then the first one wins
  313. # [14:34] * Quits: myakura (myakura@122.29.15.50) (Quit: Leaving...)
  314. # [14:37] <fantasai> concern about randommness when things are close to the same size
  315. # [14:38] <fantasai> dbaron: You can get into that with fonts that are close to the same size, but may or may not be depending on what's available on the system
  316. # [14:40] <fantasai> ....
  317. # [14:40] <fantasai> dbaron: Basically these things are all subtrees, when you're using top/bottom alignment
  318. # [14:40] <fantasai> dbaron: non-top/bottom alignment are all linked up into subtrees
  319. # [14:40] <fantasai> dbaron: When you're doing top/bottom alignement, you're aligning the subtrees
  320. # [14:40] <fantasai> dbaron: Whichever subtree is tallest, that determines the height of the line
  321. # [14:41] <fantasai> (dbaron is addressing Alex's concern about whether alignment will affect line breaking)
  322. # [14:41] <fantasai> dbaron: By the time you do top/bottom align, you've already figured out the height of the line
  323. # [14:42] <fantasai> ...
  324. # [14:44] <fantasai> Steve: You could do what IE does and align to the biggest thing, and then if there are multiple always align to the top or always align to the bottom
  325. # [14:44] <fantasai> Steve: Instead of taking the first
  326. # [14:44] <fantasai> Steve: So the alignment doesn't depend on the order of items
  327. # [14:44] <fantasai> Bert: ...
  328. # [14:44] <fantasai> Steve: We had a discussion about where inline blocks should align
  329. # [14:44] <fantasai> Steve: We went and looked at a bunch of books
  330. # [14:44] <fantasai> Steve: at Tantek's
  331. # [14:44] <fantasai> Steve: went to a bookstore
  332. # [14:45] <fantasai> Steve: Came to the conclusion that the inline block should align its bottom line with the baseline
  333. # [14:45] <fantasai> Steve: I don't know if there's an equivalent thing here, to assume bottom.. would that match what designers would expect
  334. # [14:45] <fantasai> Bert: That might depend on the writing system. Here we might assume bottom, but in India not
  335. # [14:46] <fantasai> Steve: We could ask the design community, but I'm not sure how to express the question in a way that they'd understand
  336. # [14:46] * Joins: myakura (myakura@122.29.15.50)
  337. # [14:46] <fantasai> Steve: But there's no obvious choice from what's implemented
  338. # [14:46] <fantasai> Steve: I think trying to avoid having order matter would be a better solution
  339. # [14:47] <fantasai> Alex: I'm not sure. You might have seven bottom aligned and one top aligned
  340. # [14:47] <fantasai> Alex: ...
  341. # [14:47] <fantasai> Steve: My main reason for concerning myself with ordering is that I suspect the behavior will appear to be more random if I take it into account
  342. # [14:48] * fantasai thinks we should just center it
  343. # [14:52] <fantasai> Steve: I'm willing to take an action item to write the rules if we can decide whether we want it order-specific or not
  344. # [14:52] <fantasai> Bert: If I'm mixing things, I don't think I care.
  345. # [14:53] <fantasai> Alex: IE prefers order dependent alignment :)
  346. # [14:54] <fantasai> ...
  347. # [14:55] <fantasai> Steve: The default for images is to baseline-align
  348. # [14:55] <fantasai> dbaron: I'd like to keep order-dependence because we had three browsers that followed it
  349. # [14:55] <fantasai> correction, only two
  350. # [14:58] <fantasai> IE7 and below render like Opera
  351. # [14:58] <anne> yay for Opera!
  352. # [14:58] <fantasai> dbaron: Then let's do what IE7 and Opera do
  353. # [15:00] <fantasai> Steve: But it gives the wrong answer when you have one thing that's bottom-aligned
  354. # [15:05] * sylvaing -ms-vertical-align-replace: ie7;
  355. # [15:08] <dbaron> http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html
  356. # [15:09] <fantasai> ACTION: Steve write proposals for both order-dependent and order-independent vertical-alignment
  357. # [15:09] * trackbot noticed an ACTION. Trying to create it.
  358. # [15:09] * RRSAgent records action 8
  359. # [15:09] <trackbot> Created ACTION-156 - Write proposals for both order-dependent and order-independent vertical-alignment [on Steve Zilles - due 2009-06-11].
  360. # [15:32] <anne> scribenick: anne
  361. # [15:32] <anne> Topic: Paged Media
  362. # [15:33] <anne> [silence]
  363. # [15:38] <anne> Topic: Paginating content into zero height pages or columns
  364. # [15:38] <anne> dbaron: don't
  365. # [15:38] <anne> fantasai: what do you do
  366. # [15:38] <anne> alexmog: you have to avoid inifinite loops
  367. # [15:38] <anne> fantasai: we can say it's undefined
  368. # [15:39] <anne> [missed]
  369. # [15:39] <anne> fantasai: you need to know when it ends
  370. # [15:39] <anne> s/[missed]/Arron: don't render them
  371. # [15:39] <anne> alexmog: every pagination engine i worked on forced one character on a page
  372. # [15:40] <anne> alexmog: it would have a boolean somewhere "I've put something on this page"
  373. # [15:40] <anne> alexmog: maybe a border, or some other continuation
  374. # [15:40] <anne> fantasai: if I have a 10px box and put it into 3 zero height columns
  375. # [15:40] <anne> fantasai: what do I geT?
  376. # [15:40] <anne> alexmog: I don't think we should define it here
  377. # [15:40] <anne> alexmog: 1px could be considered process
  378. # [15:41] <anne> alexmog: could give up and continue to the next one
  379. # [15:41] <anne> alexmog: we could say that the user agent should make sure there's a finite number of pages
  380. # [15:41] <anne> Topic: image-fit and image-position
  381. # [15:41] <anne> fantasai: SVG didn't like these property names
  382. # [15:41] <anne> fantasai: we have no suggestions
  383. # [15:42] <anne> fantasai: maybe merge with preserveAspectRatio
  384. # [15:42] <anne> fantasai: best I came up with was content-fit
  385. # [15:42] <anne> dbaron: what's wrong with image-fit?
  386. # [15:42] <anne> fantasai: doesn't make sense what SVG would use it for
  387. # [15:42] <anne> fantasai: we called it image-fit to make it clear it does not apply to non replaced element
  388. # [15:42] <fantasai> s/maybe/SVG wants to/
  389. # [15:42] <anne> s/SVG/SVG WG/g
  390. # [15:43] <anne> dbaron: if you don't like a name please propose a better name
  391. # [15:43] <anne> ChrisL: I thought a name was proposed
  392. # [15:43] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Mar/0134.html
  393. # [15:44] <anne> anne: that's actually a message from zcorpan and not from the SVG WG
  394. # [15:44] <shepazu> http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
  395. # [15:45] <fantasai> dbaron: content doesn't sound like something that applies only to replaced elements
  396. # [15:45] <anne> dbaron: content doesn't sound like something that only applies to images or just replaced content
  397. # [15:46] <shepazu> http://www.w3.org/2009/03/16-svg-minutes.html#item06
  398. # [15:46] <anne> ChrisL: Opera has asked for a new property from CSS to which the SVG preserveAspectRatio attribute would match
  399. # [15:46] <shepazu> dbaron: content doesn't sound like something that only applies to images or just replaced content
  400. # [15:46] <anne> ChrisL: however that SVG feature applies to the whole document so naming need to take that into account
  401. # [15:46] * MikeSmith to shepazu - I reckon ed needs to figure out how to quote messages little more succinctly.. instead of ">>>>>>>" x N, with one sentence of actual response
  402. # [15:47] <anne> dbaron: I prefer fit over content-fit
  403. # [15:47] <anne> s/dbaron:/dbaron,/
  404. # [15:47] <dbaron> s/dbaron,/dbaron:/
  405. # [15:47] <anne> s/dbaron: content/dbaron, content/
  406. # [15:47] * shepazu oops... that link is to the minutes where SVG discussed it
  407. # [15:47] * shepazu @MikeSmith yeah :)
  408. # [15:48] <anne> SZ: the natural thing would be fit-replacement
  409. # [15:48] <anne> dbaron: we don't expose the term replace to authors and I'd like to keep it that way
  410. # [15:48] <anne> SZ: if that's what it applies to it seems natural to call it that
  411. # [15:48] <anne> ChrisL: with renaming it the values need to change [example not scribed]
  412. # [15:49] <anne> fantasai: people gave feedback that the new keywords are much clearer
  413. # [15:49] <anne> fantasai: these are fill, cover and contain
  414. # [15:49] <anne> SZ: how does that map to SVG?
  415. # [15:49] <anne> SZ: I think SVG has keywords for things map into a box
  416. # [15:50] <anne> dbaron: fill is the same as slize and cover is the same as meet or is it the other way around?
  417. # [15:50] <fantasai> various suggestions that came in: content-fit + content-position, fit-scaling + fit-position, object-fit or object-scale ...
  418. # [15:50] <anne> SZ: slice and meat both preserve aspect ratio?
  419. # [15:50] <anne> fantasai: cover is the same as slice, contain is the same as meat, and none is the same as fill
  420. # [15:50] <fantasai> s/meat/meet/
  421. # [15:50] <ChrisL> http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute
  422. # [15:50] * sylvaing "it's cool" "wow"
  423. # [15:51] <anne> s/meat/meet/g
  424. # [15:51] <dbaron> [working group undoes substitution and arrives at Salami]
  425. # [15:52] <fantasai> The alignment parts of pAR are a separate property, currently called image-fit
  426. # [15:52] <fantasai> It takes all the value that background-position takes
  427. # [15:52] <anne> ChrisL: I think background-position covers all, yes
  428. # [15:53] <anne> [i.e. covers the same features as SVG]
  429. # [15:54] <anne> fantasai: we can go back to fit and fit-position
  430. # [15:54] * Joins: szilles (chatzilla@193.51.208.72)
  431. # [15:54] <anne> anne: I'd support that
  432. # [15:54] <anne> fantasai: my main problem is that fit is not a shorthand
  433. # [15:54] * Zakim anne, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  434. # [15:55] <anne> Zakim, no
  435. # [15:55] <Zakim> I don't understand 'no', anne
  436. # [15:55] <anne> Zakim, mu
  437. # [15:55] <Zakim> I don't understand 'mu', anne
  438. # [15:55] <anne> anne: we could merge them; i.e. fit: <keyword> <background-position>
  439. # [15:55] <anne> fantasai: fit-position and fit-scale
  440. # [15:55] <anne> anne: why not make it a single property?
  441. # [15:56] <anne> fantasai: position doesn't need to be specified in a lot of cases?
  442. # [15:56] <anne> anne: could make it optional
  443. # [15:56] <anne> SZ: what about inheritance? typical reason for splitting properties
  444. # [15:57] <anne> fantasai, it is currently inherited
  445. # [15:57] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
  446. # [15:57] <anne> s/fantasai,/fantasai:/
  447. # [15:58] <anne> dbaron: existing cases where we have a property that is a superstring of another is font-size and font-size-adjust, pitch and pitch-range and color-interpolation and color-interpolation-filters
  448. # [15:59] <anne> dbaron: plus fill-* and a bunch of stroke-*
  449. # [15:59] <anne> anne: in SVG it's a single attribute and it doesn't seem to be a problem there
  450. # [15:59] <anne> ChrisL: true
  451. # [16:00] <anne> fantasai: would be ok with me; HP prolly has an implementation but they are prolly ok with changing it
  452. # [16:00] <fantasai> Melinda checked with the print implementors before she left
  453. # [16:00] <dbaron> also speak and speak-*
  454. # [16:01] <anne> SZ: one example Melinda was using was generation of compact sheets
  455. # [16:01] <anne> s/compact/contact/
  456. # [16:01] <anne> SZ: rather than taking every image I would like to able to put the fit piece into the body but separately set the position
  457. # [16:02] <anne> SZ: whether that's true or not I don't know
  458. # [16:02] <anne> fantasai: anne said that if we find out there's a reason to split them we can split them later
  459. # [16:02] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  460. # [16:03] <anne> SZ: you might not know what the keyword is
  461. # [16:03] * billyjackass is now known as MikeSmith
  462. # [16:04] <anne> SZ: I don't know; I just tend to distrust pulling things together
  463. # [16:04] <anne> anne: could have fit-type
  464. # [16:04] <anne> fantasai: fit-style!
  465. # [16:04] <dbaron> We could just have a fit. :-)
  466. # [16:05] <anne> [and there was much rejoicing]
  467. # [16:05] <anne> szilles: tentative resolution is to have one property called fit consisting of two components
  468. # [16:06] <anne> SOMEWHAT RESOLVED: have one property called fit that pulls together image-fit and image-position
  469. # [16:06] <anne> Topic: difference between forced page breaks and natural page breaks
  470. # [16:07] <anne> howcome: you edited 9.4 which is currently projected
  471. # [16:07] <anne> howcome: I think rule 1 should be simpler
  472. # [16:07] <anne> howcome: that when a forced page break occurs margins are preserved
  473. # [16:07] <anne> howcome: and when natural page break occurs margins are set to zero
  474. # [16:08] <anne> howcome: I'm suggesting a principle where we also preserve margin-bottom
  475. # [16:08] <anne> howcome: it's a simpler principle
  476. # [16:08] <anne> fantasai: then you'd end up with a gap on the next page
  477. # [16:08] <anne> fantasai: e.g. when you have a 6em bottom margin and 3em space we don't want a new page
  478. # [16:09] <anne> fantasai: how about we say that the margin is truncated
  479. # [16:09] <anne> howcome: I don't reallycare but the principle simpler
  480. # [16:09] <anne> s/reallycare/really care/
  481. # [16:09] <anne> s/principle/principle is/
  482. # [16:09] <anne> dbaron: if there was a border or background on an ancestor then you can tell the difference
  483. # [16:10] <anne> dbaron: the question is how low the background and/or border of the parent has to go
  484. # [16:10] <anne> dbaron: if the border needs some sort of visual space you need some kind of padding
  485. # [16:10] <anne> howcome: I'm ok leaving this as is
  486. # [16:11] <anne> howcome: shouldn't forced page breaks be discussed in the next section
  487. # [16:11] <anne> Topic: border-break properties
  488. # [16:11] <anne> s/border-break/break-*/
  489. # [16:12] <anne> fantasai: I can put those new properties in here
  490. # [16:12] <anne> howcome: that's all I wanted to know
  491. # [16:12] <anne> fantasai: the main concern is that implementations of this module have to implement the new names
  492. # [16:12] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
  493. # [16:12] <anne> howcome: isn't that what we want?
  494. # [16:12] <anne> anne: you could say that some of the values are conditional on the multicol draft
  495. # [16:13] <anne> fantasai: multicol can define those
  496. # [16:13] <anne> howcome: fits better here
  497. # [16:13] <anne> howcome: that's it for me
  498. # [16:13] <anne> glazou: anything else?
  499. # [16:13] <anne> [silence]
  500. # [16:14] <anne> Topic: CSS 2.1 grammar issue
  501. # [16:14] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-71
  502. # [16:15] <anne> fantasai: Bert said this was already clearly defined in 2.1 but the resolution was to change 2.1
  503. # [16:15] <anne> fantasai: the resolution we had was that if you see something that looks like an @rule within a declaration block you have to parse it as if it was an @rule
  504. # [16:16] <anne> Bert: this means that the rule that was in the spec doesn't apply and that implementations have to change
  505. # [16:16] <anne> Bert: i believe we decided that nested @rules have to come at the end
  506. # [16:17] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Sep/0076.html
  507. # [16:17] <anne> Bert: otherwise CSS 2.1 parsers would not skip the @rules
  508. # [16:17] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  509. # [16:17] <anne> Bert: margin boxes inside @page
  510. # [16:18] <anne> Bert: the CSS 2 spec is more stable
  511. # [16:19] <anne> anne: for forward compatible parsing it would be better if @rules were parsed correctly
  512. # [16:19] <anne> Bert: it would be better if @rules where not nested at all
  513. # [16:19] * billyjackass is now known as MikeSmith
  514. # [16:20] <anne> fantasai: change definition of @page to allow atrules
  515. # [16:20] <anne> fantasai: or make it general that it can be done everywhere
  516. # [16:20] <anne> ChrisL: i think it should be general
  517. # [16:20] <anne> glazou: I agree
  518. # [16:20] <anne> anne: I also agree
  519. # [16:21] <ChrisL> better to make the general change, otherwise we always have to explain why @page is special
  520. # [16:21] <anne> dbaron: do these @top-... things take other properties than content?
  521. # [16:21] <anne> fantasai: yes
  522. # [16:21] * Quits: szilles (chatzilla@193.51.208.72) (Ping timeout)
  523. # [16:22] <anne> dbaron: your compat issues would go away if you remove the @ and add a semi colon
  524. # [16:22] <dbaron> top-left: { content: "foo"; };
  525. # [16:22] <anne> dbaron: actually, I was suggesting making the block a value of a property
  526. # [16:23] <fantasai> fantasai: The problem isn't where does the @rule end, it's does the @rule
  527. # [16:23] <fantasai> end the declaration.
  528. # [16:23] <fantasai> property: value; @key { ... } property2: value;
  529. # [16:23] <fantasai> fantasai: The question isn't whether @key { ... } stays together, it's
  530. # [16:23] <fantasai> whether it's considered part of the property2 declaration or not
  531. # [16:23] <anne> Bert: in @page they're not; they're declarations
  532. # [16:25] <anne> glazou: do you have a proposal Bert?
  533. # [16:25] <anne> Bert: as far as I can see it already ignores @rules
  534. # [16:26] <anne> Bert: we recently updated this text
  535. # [16:27] <anne> Bert: statements cannot start with a property
  536. # [16:27] <anne> Bert: @page contains declarations
  537. # [16:28] <anne> Bert: people didn't want a mixture of declarations and atrules
  538. # [16:29] <anne> dbaron: it seems a problem if we extend beyond the room forward compatible parsing rules give
  539. # [16:29] <anne> dbaron: we need either need more room or take better care of what is provided
  540. # [16:30] <anne> Arron: proposals?
  541. # [16:30] <anne> Bert: my proposal was from January '09
  542. # [16:31] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Jan/0173.html
  543. # [16:35] <anne> [proposals on whiteboard; insert possible photo here]
  544. # [16:35] <anne> dbaron: I'm gonna say it's too late for 4
  545. # [16:35] <anne> fantasai: 4 was our last resolution
  546. # [16:37] <anne> Bert: we can define a new construct but we still need implementations to align
  547. # [16:38] <anne> Bert: my proposal grammatically allows mixing of atrules and declarations but atrules have to come after declarations
  548. # [16:38] <anne> Bert: that is compatible with existing implementations, but maybe not good for @page
  549. # [16:39] <anne> howcome: number 3 is just a grammar thing?
  550. # [16:39] <anne> Bert: it would introduce a block in the grammar
  551. # [16:39] <anne> fantasai: the implementations that implement @page have to change
  552. # [16:40] <anne> [some resentment over the design of @page]
  553. # [16:40] <anne> [also some support]
  554. # [16:41] <anne> fantasai: least disruptive solution would be 3
  555. # [16:41] <anne> howcome: yes
  556. # [16:41] <anne> glazou: yes
  557. # [16:41] <anne> Bert: really?
  558. # [16:41] <anne> fantasai: we could make a rule that atrules have to come after declarations
  559. # [16:42] <anne> fantasai: but implementations that support nested atrules will have to keep their support in the current way
  560. # [16:42] <anne> fantasai: it's non-conforming for an @margin- rule to come before declarations
  561. # [16:43] <anne> fantasai: in a conforming CSS file you'd parse it ok regardless of your implementation, but for non-conforming files you keep the current behavior
  562. # [16:43] <anne> Bert: I think less disruptive would be to take the atrules out of @page
  563. # [16:43] <anne> fantasai: there's deployed implementations and content
  564. # [16:43] <anne> howcome: yeah, I think that train has left
  565. # [16:44] <anne> fantasai: my proposal is 3 -- @page can take a mix of atrules and declarations + margin boxes must come after declarations
  566. # [16:45] <anne> anne: please don't bother authors for eternity with a silly conformance requirement because of some two year compat issue
  567. # [16:49] <fantasai> fantasai: So my proposal is a combination of 2 and 3
  568. # [16:49] <fantasai> 1. @margin-box rules must end in semicolon. (Print impl must change)
  569. # [16:49] <fantasai> 2. @margin-box rule smust come after all declarations in @page. (Print impl must change)
  570. # [16:49] <fantasai> 3. @page takes a new mixed declarations+@rules construct
  571. # [16:50] <fantasai> (Impl must change invalid parsing inside @page)
  572. # [16:50] <fantasai> 4. All declaration blocks can parse @rules that take the place of a declaration. (All impl must change invalid parsing in all declarations blocks.)
  573. # [16:50] <fantasai> 4 is our previous resolution
  574. # [16:50] <fantasai> 1 and 2 mess with existing implementations and content the most
  575. # [16:51] <fantasai> 3 is probably the least disruptive
  576. # [16:51] <fantasai> if we combine it with a recommendation that authors keep their @margin-box rules at the end of the @page rule
  577. # [16:51] <fantasai> then they get backwards compatibility with current implementations
  578. # [16:53] <anne> dbaron: I think just 3
  579. # [16:53] <anne> anne: 3
  580. # [16:54] <anne> sylvaing: 3 + 2 as note
  581. # [16:54] <anne> Arron: 3 + 2 as note
  582. # [16:56] <anne> SZ: 3 + 2
  583. # [16:56] <anne> glazou: just 3
  584. # [16:56] <anne> jdaggett: pass
  585. # [16:56] <anne> Bert: 1
  586. # [16:56] <anne> (second best, prefers something else)
  587. # [16:56] <anne> alexmog: pass
  588. # [16:56] <anne> howcome: pass
  589. # [16:57] <anne> fantasai: 3 + 2 as actual req
  590. # [16:57] <anne> ChrisL: 3 + 2 as ...
  591. # [16:58] <fantasai> 3 passes
  592. # [16:58] <fantasai> 2 passes as well, but should it be a note, a recommendation, or a requirement?
  593. # [16:59] <ChrisL> zakim, remind us in 987 hours that its late
  594. # [16:59] <Zakim> ok, ChrisL
  595. # [17:00] <anne> dbaron: note
  596. # [17:00] <anne> sylvaing: note
  597. # [17:00] <anne> SZ: rec
  598. # [17:01] <anne> glazou: abstain
  599. # [17:01] <anne> Bert: rec
  600. # [17:01] <anne> anne: note
  601. # [17:01] <anne> jdaggett: abstain
  602. # [17:01] <anne> alexmog: abstain
  603. # [17:01] <anne> s/rec/req/
  604. # [17:01] <anne> howcome: abstain
  605. # [17:01] <anne> fantasai: rec/req
  606. # [17:01] <anne> Arron: note
  607. # [17:01] <anne> ChrisL: rec
  608. # [17:02] <anne> 4 note
  609. # [17:03] <anne> 4 rec/req
  610. # [17:03] <anne> glazou: move to rec
  611. # [17:03] <anne> dbaron: put it in as PR
  612. # [17:04] <anne> RESOLVED: 3 + 2 = 5
  613. # [17:04] <fantasai> RESOLVED: @page takes a new construct that mixes declarations and @rules (2.1 and css3-page)
  614. # [17:04] <fantasai> RESOLED: css3-page includes a RECOMMENDATION that @margin-box rules come after all declarations in the page context
  615. # [17:04] <fantasai> s/RESOLED/RESOLVED/
  616. # [17:05] <fantasai> s/includes a RECOMMENDATION/RECOMMENDS/
  617. # [17:06] * Parts: howcome (howcome@193.51.208.72)
  618. # [17:15] <dbaron> Is this the group in question? http://www.itu.int/ITU-T/IPTV/
  619. # [17:17] * Joins: howcome (howcome@193.51.208.72)
  620. # [17:18] * Joins: dsinger (dsinger@17.202.35.52)
  621. # [17:18] <dsinger> good evening
  622. # [17:18] <dsinger> you came through as 'unknown' on my cell phone
  623. # [17:19] <dsinger> I'm at my desk, so +1 408 974 3162 should work...
  624. # [17:20] <Bert> http://www.itu.int/ITU-T/studygroups/com16/index.asp
  625. # [17:20] <dbaron> http://www.itu.int/ITU-T/studygroups/com16/sg16-q13.html
  626. # [17:21] <dbaron> dsinger, Bert is dialing
  627. # [17:21] <glazou> calling now
  628. # [17:22] <fantasai> ScribeNick: fantasai
  629. # [17:22] <fantasai> Daniel: We received a liaison statement from the ITU and Bert sent a few comments about it
  630. # [17:23] <howcome> daniel: we receved draft document, bert has commented
  631. # [17:23] <fantasai> ScribeNick: howcome
  632. # [17:23] <howcome> david: theiy're trying to describe a limited environment, but I'm not sure which one
  633. # [17:24] <howcome> stevez: do we want to authorize any subset?
  634. # [17:24] <anne> profiles are teh evil
  635. # [17:24] <howcome> David: we already have a TV subset, no?
  636. # [17:24] <howcome> Bert: webtv was the driver for that, we still have the draft
  637. # [17:25] <howcome> Bert: one of my suggestions was to only have one TV draft
  638. # [17:25] <dsinger> sounds like a good idea. profile proliferation (profileration?) is not good
  639. # [17:25] <howcome> Daniel: whould we reference or publish a document?
  640. # [17:25] <howcome> Bert: in the past, W3C has published
  641. # [17:26] <howcome> Bert: the proposed subset for TV is quite similar to the mobile subset we already have
  642. # [17:26] <howcome> Daniel: lists numerous differences....
  643. # [17:27] <howcome> Various: similarities and differences are discussed
  644. # [17:27] * dsinger that is too far away from the mike (tho I still agree)
  645. # [17:27] <howcome> Chris: we should say: we're interested in your work, but you should reference our documents, not copy for them.
  646. # [17:29] <howcome> SteveZ: I'd like to have a discussion on principles on subsetting. There should be as few as possible
  647. # [17:29] <howcome> Chris: it would be good to have CSS on many devices
  648. # [17:29] <howcome> SteveZ; maybe...
  649. # [17:29] <howcome> <microphones moved>
  650. # [17:30] <howcome> Chris: we shouldn't put them off, but find out what they want to do with it
  651. # [17:30] <howcome> Chris: I'm concerned that they modify our definitions
  652. # [17:30] <Zakim> dbaron, you asked to be reminded at this time to go home
  653. # [17:30] <howcome> Anne: spending time educating them may not be worthwhile
  654. # [17:31] <howcome> Bert: I understand that they want a definition...
  655. # [17:31] <howcome> David: if they're defining a profile, they're not interested in interoperating with the web
  656. # [17:33] <howcome> s/David/DavidBaron/
  657. # [17:34] <howcome> Håkon/Anne: Opera implement CSS on various set-top boxes. We don't really like profiles.
  658. # [17:35] <howcome> Håkon: if they need a profile, we can offer CSS1, CSS Mobile, or CSS 2.1
  659. # [17:35] <dsinger> so, our response.
  660. # [17:35] <dsinger> We're not sure whether you are
  661. # [17:35] <dsinger> a) defining a limited implementation of web services, suitable for deployment on small devices like set-tops or TVs, but handling general web content
  662. # [17:35] <dsinger> b) or defining a restricted environment for restricted purposes, such as displaying menus or other TV-specific content
  663. # [17:35] <dsinger> Our comments are rather tentative, and are based on the assumption that it's (b).
  664. # [17:35] <dsinger> We're unhappy about the fact that your spec. copies our document, and we'd prefer that you reference it, and (if a subset is needed) you identify the sections that you adopt. It's important to us (and implementors) that there not be differences between an 'IPTV' implementation and a 'W3C' implementation, and if you copy our specification and we later, for example, fox an error, that could occur. Even simple re-phrasing can result in subtle, awkward, difference
  665. # [17:35] <dsinger> This is effectively defining a new profile, and we are hesitant to define many, and would prefer to do this collaboratively.
  666. # [17:35] <dsinger> It is important to analyze such a restricted profile from two directions:
  667. # [17:35] <dsinger> * is what is chosen to be included consistent, and complete, and implementable, or is there important functionality missing?
  668. # [17:35] <dsinger> * what are the consequences of the missing material? what functionality and interop is lost?
  669. # [17:35] <howcome> Bert: this makes sense
  670. # [17:36] <howcome> Daniel: happy?
  671. # [17:36] <dsinger> in particular, given general web content, and two browsers, one implementing IPTV CSS and the other W3C CSS, what happens when features in W3C but not IPTV are used in that content?
  672. # [17:36] * Joins: MoZ (chatzilla@82.230.92.154)
  673. # [17:36] <howcome> Elika: we are cocerned...
  674. # [17:36] * glazou waves at MoZ
  675. # [17:36] <howcome> Chris: we are heartbroken...
  676. # [17:37] <glazou> s/cocerned/concerned
  677. # [17:37] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-125
  678. # [17:37] * MoZ google waves glazou
  679. # [17:37] <howcome> Bert: they're expecting us to be stable -- what do we tell them?
  680. # [17:37] <howcome> John: CSS 2.1 is relatively stable...
  681. # [17:38] <howcome> David Singer: CSS3 is also on the way. It's difficult to answer them before we know what they're trying to do.
  682. # [17:39] <dsinger> if they want a subset for a restricted purpose, we don't know what that purpose is...
  683. # [17:39] <howcome> Elika: they should also look at the snapshot...
  684. # [17:39] <fantasai> http://www.w3.org/TR/css-beijing/
  685. # [17:39] <fantasai> It explains a lot of important things about our specs and their relative stability/obsolescence
  686. # [17:39] <howcome> David Singer: ahh
  687. # [17:39] <Bert> liaison statement: http://www.w3.org/Style/Group/2009/ls047-16.doc
  688. # [17:40] * dsinger oohh
  689. # [17:41] <howcome> David Singer: should I draft a response you can look at tomorrow morning? What else should be in there? Beijing draft?
  690. # [17:41] <howcome> Elika: yes
  691. # [17:43] <howcome> Håkon: we should say why we don't like profiles: we like interoperability
  692. # [17:43] <howcome> SteveZ: we don't like ghettos
  693. # [17:45] <howcome> SteveZ: one thing to ask for is a set of requirements
  694. # [17:47] <howcome> Bert/Chris will add general text about W3C to be added to the reply
  695. # [17:47] <Bert> http://www.w3.org/Style/Group/meetings.html
  696. # [17:47] <howcome> DanielG: 2010 meeetings: one meeting will be in the bay area on 22-24 march, 2010 -- can Apple host?
  697. # [17:48] <howcome> DanielG: we need projector, network, room for 15 people
  698. # [17:49] <howcome> David Singer: I can't book a room until 6 months before, but in principle I agree.
  699. # [17:49] * sylvaing free Macbooks ?
  700. # [17:51] * dsinger a zip archive with an HTML page and a stylesheet
  701. # [17:52] <howcome> various discussions: what format should we use for our reply?
  702. # [17:52] * dsinger using features of CSS they chose not to include... :-)
  703. # [17:53] <howcome> <phone hung up>
  704. # [17:53] <sylvaing> cessation of hostilities #2
  705. # [17:53] <howcome> meeting adjourned
  706. # [17:54] * Quits: sylvaing (sylvaing@193.51.208.72) (Quit: sylvaing)
  707. # [17:55] * Quits: dsinger (dsinger@17.202.35.52) (Quit: dsinger)
  708. # [17:55] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
  709. # [17:59] * Quits: ChrisL (ChrisL@128.30.52.30) (Client exited)
  710. # [18:01] * Joins: dsinger (dsinger@17.202.35.52)
  711. # [18:02] <fantasai> http://test.csswg.org/source/submitted/css2.1/tables/
  712. # [18:02] * Quits: jdaggett (jdaggett@193.51.208.72) (Quit: jdaggett)
  713. # [18:05] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009May/0213.html
  714. # [18:08] * Quits: howcome (howcome@193.51.208.72) (Ping timeout)
  715. # [18:13] * Quits: Arron (arronei@193.51.208.72) (Ping timeout)
  716. # [18:21] * Quits: dbaron (dbaron@193.51.208.72) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  717. # [18:25] * Quits: alexmog (alexmog@193.51.208.72) (Ping timeout)
  718. # [19:13] * Quits: dsinger (dsinger@17.202.35.52) (Quit: dsinger)
  719. # [19:30] * Quits: myakura (myakura@122.29.15.50) (Quit: Leaving...)
  720. # [19:30] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.84 [Firefox 3.0.10/2009042315])
  721. # [20:19] * RRSAgent excuses himself; his presence no longer seems to be needed
  722. # [20:19] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
  723. # [22:17] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  724. # Session Close: Fri Jun 05 00:00:01 2009

The end :)