/irc-logs / w3c / #css / 2009-11-03 / end

Options:

  1. # Session Start: Tue Nov 03 00:00:00 2009
  2. # Session Ident: #css
  3. # [00:00] <dbaron> jdaggett: I'm not keen on writing a spec for that, at least initially.
  4. # [00:00] <dbaron> Håkon: When I said I wanted to go down the @font-face route, I meant that only for arbitrary features, not for features that we standardize.
  5. # [00:00] <dbaron> Håkon: For the features we standardize, I think we should absolutely have properties that work the normal way.
  6. # [00:00] <dbaron> SteveZ: So it sounds like we're mostly in agreement.
  7. # [00:00] <dbaron> ChrisL: So we can start moving this stuff into the spec?
  8. # [00:01] <dbaron> jdaggett: I still don't have a sense of the alternates...
  9. # [00:01] <dbaron> ChrisL: I think it's time to start moving it into a spec now.
  10. # [00:01] <dbaron> fantasai: I agree with that.
  11. # [00:01] <dbaron> ChrisL: exposes it to more people, get wider review
  12. # [00:01] <dbaron> jdaggett: Still not confident of ...
  13. # [00:01] <dbaron> dbaron: Put big red issues in the spec so people know.
  14. # [00:02] <fantasai> fantasai: That's why we have class="issue" :)
  15. # [00:02] <ChrisL> Don't let that put you off. Lets get it into the spec
  16. # [00:02] <dbaron> Topic: multicol
  17. # [00:02] <dbaron> Håkon: Yes, I want to advance it.
  18. # [00:03] <dbaron> Peter: So all the comments have been addressed?
  19. # [00:03] <dbaron> Håkon: yes
  20. # [00:03] <dbaron> fantasai: Do you have a disposition of comments?
  21. # [00:03] <dbaron> Håkon: It's linked from the wiki page.
  22. # [00:03] <howcome> http://dev.w3.org/csswg/css3-multicol/last-call.html
  23. # [00:04] <dbaron> ChrisL: What are the uncolored rows?
  24. # [00:04] <Zakim> -[Mozilla]
  25. # [00:05] <dbaron> Håkon: They're not really comments, just questions.
  26. # [00:05] <dbaron> ChrisL: put that in the grid at the top
  27. # [00:05] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
  28. # [00:05] <dbaron> ChrisL: Sylvain, could you send email about whether you're ok with that resolution.
  29. # [00:05] <dbaron> Håkon: The other orange... he sent a message saying it was ok.
  30. # [00:06] <dbaron> fantasai: I disagree with Håkon's disagreements.
  31. # [00:06] <dbaron> Håkon: I'm happy to change.
  32. # [00:06] <dsinger> comment #1: change "coing" to "going"
  33. # [00:07] <dbaron> Daniel: some green rows have no action
  34. # [00:07] <dbaron> Håkon: didn't result in changes
  35. # [00:07] <dbaron> Daniel: so put "no changes needed"
  36. # [00:08] <dbaron> Daniel: Don't use "white". Use "green".
  37. # [00:08] * Joins: Kangchan (Kangchan@72.254.83.174)
  38. # [00:09] * Parts: Kangchan (Kangchan@72.254.83.174)
  39. # [00:10] <dbaron> ChrisL: Also need CR exit criteria.
  40. # [00:10] <dbaron> fantasai: We have boilerplate for that.
  41. # [00:11] <dbaron> Håkon: Should I prepare a CR draft then?
  42. # [00:11] <dbaron> Bert: Yes, everything except the status.
  43. # [00:11] <Zakim> -Hakon_Lie
  44. # [00:11] <dbaron> fantasai: Bert can take care of the status right before publication.
  45. # [00:11] <dbaron> RESOLVED: Advance css3-multicol to CR
  46. # [00:11] <dbaron> Zakim, who is on the phone?
  47. # [00:11] <Zakim> On the phone I see Salon_9
  48. # [00:11] <glazou> #howcome { color-replace: white green; }
  49. # [00:12] <Zakim> -Salon_9
  50. # [00:12] <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
  51. # [00:12] <Zakim> Attendees were Hakon_Lie, Salon_9, [Mozilla]
  52. # [00:12] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
  53. # [00:12] * Quits: dethbakin (dethbakin@72.254.115.244) (Quit: dethbakin)
  54. # [00:12] <ChrisL> zakim, remind us in 3 hours to go home
  55. # [00:12] <Zakim> ok, ChrisL
  56. # [00:13] * Quits: bradk (bradk@72.254.115.105) (Quit: Computer has gone to sleep)
  57. # [00:13] <dbaron> <break duration="17min" />
  58. # [00:13] * Quits: smfr (smfr@72.254.115.22) (Quit: smfr)
  59. # [00:14] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
  60. # [00:19] * Joins: dethbakin (dethbakin@72.254.115.244)
  61. # [00:20] * Joins: glazou (glazou@72.254.115.247)
  62. # [00:27] * Quits: glazou (glazou@72.254.115.247) (Ping timeout)
  63. # [00:31] * Joins: glazou (glazou@72.254.115.247)
  64. # [00:35] * Joins: smfr (smfr@72.254.115.22)
  65. # [00:35] * Quits: hyatt (hyatt@98.201.21.231) (Quit: hyatt)
  66. # [00:36] <dsinger> zakim, you should have told us that break is over
  67. # [00:36] <Zakim> I don't understand you, dsinger
  68. # [00:40] * Quits: dethbakin (dethbakin@72.254.115.244) (Client exited)
  69. # [00:41] * Joins: bradk (bradk@72.254.115.105)
  70. # [00:41] * Joins: dethbakin (dethbakin@72.254.115.244)
  71. # [00:44] <fantasai> ScribeNick: fantasai
  72. # [00:44] <fantasai> Topic: grid, flexbox, css3-layout
  73. # [00:45] * Joins: tantek (tantek@72.254.62.180)
  74. # [00:45] * Curt`|away is now known as Curt`
  75. # [00:45] <fantasai> Alex: Are there specific issues about these specs being inconsistent, overlapping, etc?
  76. # [00:45] * Joins: Arron (arronei@72.254.111.4)
  77. # [00:45] <fantasai> glazou: THe issue is that these specs are in limbo for 2 years
  78. # [00:45] <fantasai> Tab: I added it to see if there is any way to unify the concepts, esp. between template, flexbox, and tables
  79. # [00:46] <fantasai> Tab: These are 3 separate ways of dealing with layout, was wondering if we can combine them
  80. # [00:46] <fantasai> dbaron: Tables have so many backwards-compatibility constraints that you probably don't want to do that
  81. # [00:46] <fantasai> Alex: Flexbox is the first concept of layout that is completely independent of the rest of CSS
  82. # [00:46] <fantasai> ...
  83. # [00:46] <fantasai> Alex: There are two exceptions to that: table and flexbox
  84. # [00:47] <fantasai> Alex: each uses its own algorithm to do layout
  85. # [00:47] <fantasai> Alex: Which keeps its really simple: only layout concepts of this model apply
  86. # [00:47] <fantasai> Alex: It's awesome
  87. # [00:47] <fantasai> Alex: It's cool if this same model applies to something else
  88. # [00:47] <fantasai> Alex: If it can be added as its own model without added any complexity of interference with other features
  89. # [00:48] <fantasai> Tab: So you prefer the layoud modes bein completely separate from each other?
  90. # [00:48] <fantasai> Markus: Depends on how you want to apply it
  91. # [00:48] <fantasai> Markus: Flexbox is great for layout
  92. # [00:48] <fantasai> Markus: Then use flow layout for the content inside
  93. # [00:48] <fantasai> Alex: yes, I prefer different models separate
  94. # [00:48] <fantasai> Alex: We can certainly discuss how this applies to CSS, where mostly everything applies to everything in combination
  95. # [00:48] <fantasai> Alex: This is great for flow content
  96. # [00:48] <fantasai> Alex: but the there are other systems like Silverlight, WPF, etc.
  97. # [00:49] <fantasai> Alex: Where most layout models are self-contained and independent
  98. # [00:49] <fantasai> Alex: Everyone has hits own model and it's extensible, you add a model
  99. # [00:49] <fantasai> Alex: Is it good to go forward to have both system in CSS .. and ad flexbox and add somethign else and add something else... I don't know
  100. # [00:50] <fantasai> Alex: I think the existence of flexbox as something separate is good. I would be worried if we tried to integrate with regular CSS layout
  101. # [00:50] <fantasai> Tab: Ok, seems reasonable
  102. # [00:50] <fantasai> Alex: Flexbox is a parent that has complete control of its descendents (?)
  103. # [00:50] <fantasai> Alex: The model of the ocntainer overrides the contents
  104. # [00:50] <fantasai> Alex: Abspos has that kind of gray area
  105. # [00:50] <fantasai> Tab: That makes sense, esp within the context of flexbox
  106. # [00:50] <fantasai> Tab: Jumping over to template
  107. # [00:51] <fantasai> Tab: we have some definite parallels with how tables work
  108. # [00:51] <fantasai> Tab: Might makes sense to align
  109. # [00:51] <fantasai> Tab: E.g. apply table border concepts to template slots
  110. # [00:51] <fantasai> Tab: Do we want to redesign this, or treat them as applying to both
  111. # [00:51] <fantasai> Peter: things like border-collapse could apply to flexbox too
  112. # [00:52] <fantasai> Tab: Anytime I use a table, I'm almost always border-collapsing
  113. # [00:52] <fantasai> Tab: I think most times for templates I'd want to collapse the borders
  114. # [00:52] * Joins: CesarAcebal (acebal@85.152.177.207)
  115. # [00:53] <fantasai> fantasai isn't sure if that's the case, a lot of designs put margins around their boxes
  116. # [00:53] <fantasai> Tab: I think the biggest problem is making sure the drafts have some life into them
  117. # [00:53] <fantasai> Tab: All three are extremely important to me as a web design
  118. # [00:53] <fantasai> Tab: Static design right now is workable, but bloats my markup and requires many compromises
  119. # [00:53] <fantasai> Tab: I would make many sites faster and easier if I had layout modes like flexbox and template, and even tables now that they're implemented widely
  120. # [00:54] <fantasai> Tab: I want these specs to move and be implemented well so I can use them in a few years
  121. # [00:54] <fantasai> Bert: For the spec writing part of that, I've been thinking it should be possible to merge grid and template together
  122. # [00:54] <fantasai> Bert: flexbox is different, but some can also be used with template and grid
  123. # [00:54] <fantasai> Bert: I was thinking to put them in all in one spec. What to do with flexbox display values they are rather separate
  124. # [00:54] <fantasai> Bert: But the flex property can be applied to other things
  125. # [00:55] <fantasai> Tab: That makes sense I think. Grid matches really well with template
  126. # [00:55] <fantasai> Tab: Grid positioning basically does a static template
  127. # [00:55] <fantasai> Tab: Template just has some extra magic with slot pseudo elements
  128. # [00:56] <fantasai> fantasai: There are some things you can do with grid that you can't do with template
  129. # [00:56] <fantasai> fantasai: Although template would be better for some of the examples Alex had, last time he showed some interesting examples
  130. # [00:56] <fantasai> (they are minuted in the last F2F minutes)
  131. # [00:57] <fantasai> Alex describes some things you can do with grid and .e.g multicol interactions
  132. # [00:58] <fantasai> fantasai: Another thing about grid is that it creats a grid that you can use to align things
  133. # [00:58] <fantasai> fantasai: have a snap-to-grid feature
  134. # [00:58] <fantasai> fantasai: That you could use for flow content
  135. # [00:58] <fantasai> fantasai: e.g. say this box should fit its content, but should snap to the grid
  136. # [00:58] <fantasai> fantasai: and you adjust the margins to make that happen
  137. # [00:58] <fantasai> ...
  138. # [00:58] <fantasai> Bert: I wanted to do abspos the right way.
  139. # [00:59] <fantasai> Bert: You want to position not by numbers, but say "this is next to that", and "this is just as tall as that"
  140. # [00:59] <fantasai> Bert: I wanted to have that abstraction there.
  141. # [00:59] <glazou> hum hum http://daniel.glazman.free.fr/weblog/position__new.html
  142. # [00:59] <fantasai> Bert: you can put any element anywhere, but they align to each other
  143. # [00:59] <fantasai> Markus: I'm not sure we should merge them
  144. # [00:59] <fantasai> Markus: They each have their use cases
  145. # [01:00] <fantasai> Markus: Grid is very much a pixel-perfect wireframe thing
  146. # [01:00] <smfr> grid: http://www.w3.org/TR/css3-grid/
  147. # [01:00] <fantasai> Markus: I think if we merge them, we might lose the original use cases
  148. # [01:00] <fantasai> Markus: I see the benefit of what you say
  149. # [01:00] <smfr> template layout: http://www.w3.org/TR/css3-layout/
  150. # [01:00] <fantasai> ...
  151. # [01:01] <fantasai> Markus: Grid was intended to be a positioning system over whatever positioning scheme you use
  152. # [01:01] <fantasai> ...
  153. # [01:01] * glazou thinks that we would not have this discussion if CSS was able to position an element relatively to any other element, like P language did 20 years ago
  154. # [01:01] <fantasai> Alex: could just as well be the other way, the grid defined as a side-effect of something else, e.g. a template
  155. # [01:01] <fantasai> Alex: Currently it's explicit, but it doesn't have to be
  156. # [01:02] <fantasai> shepazu: Have you guys talked about a fallback mechanism?
  157. # [01:03] <fantasai> Alex: I'm not sure it makes sense to do fallback at the property level, you'd probably need an entirely separate style sheet
  158. # [01:03] <fantasai> shepazu: What about for authoring tools?
  159. # [01:03] <fantasai> glazou: Depends on if you need to preserve ... relation of prose
  160. # [01:04] <fantasai> glazou: If I used this I wouldn't care about legacy browsers
  161. # [01:04] <fantasai> shepazu asks when can browsers be relied on to support this stuff
  162. # [01:06] <fantasai> fantasai: You'd need a media-query-like thing
  163. # [01:06] <fantasai> fantasai: for something like this
  164. # [01:07] <fantasai> shepazu: Yes. Is that a stupid question?
  165. # [01:07] <fantasai> glazou: No, it's important
  166. # [01:07] <fantasai> glazou: This has come up many times before
  167. # [01:07] <fantasai> (shift that sentence up 2)
  168. # [01:07] <fantasai> ...
  169. # [01:07] <fantasai> shepazu: It's come up in dom3 events
  170. # [01:07] * glazou said it's not the 1st time we want to do one thing if one couple (property/value) is parsed and something else if not
  171. # [01:07] <fantasai> shepazu: Before, hasFeature only worked on a very gross level
  172. # [01:07] <fantasai> shepazu: e.g. do you support Mouse Events?
  173. # [01:08] <fantasai> shepazu: if you support 5 events and not 1, then can you say you support them?
  174. # [01:08] * glazou just for the record http://www.glazman.org/weblog/dotclear/index.php?post/2009/03/04/CssHackz
  175. # [01:08] <fantasai> shepazu: It's very hard to say at a group level whether a feature is supported
  176. # [01:08] <fantasai> shepazu: but if you have granularity, do you support this aspect of grid, then it's much easier to get an accurate response from the browser
  177. # [01:08] <fantasai> Tab: You'd still run into bugs
  178. # [01:08] * glazou and http://www.glazman.org/weblog/dotclear/index.php?post/2009/03/22/CssHackz-2
  179. # [01:09] <fantasai> Tab: That's something that JS-based feature testing can do
  180. # [01:09] * Joins: Kai (chatzilla@72.254.114.142)
  181. # [01:09] <fantasai> Tab: Maybe you just defer to JS
  182. # [01:09] <fantasai> Brad: Then JS has to be turned on
  183. # [01:11] <fantasai> fantasai, glazou: testing at the property: value level is probably good enough
  184. # [01:11] <fantasai> fantasai: If you need to detect specific bugs, then use a JS library
  185. # [01:11] <fantasai> fantasai: but at the property: value level, then it's probably usable
  186. # [01:12] <fantasai> fantasai: it's unlikely a browser would lie about hat
  187. # [01:12] <fantasai> Peter: back on target
  188. # [01:13] <fantasai> Tab: Personally I like the idea of template being built on top of grid and aligning a grid onto a box
  189. # [01:13] <fantasai> Tab: Then you can align other boxes onto that grid (????)
  190. # [01:13] <fantasai> Tab: But it works the other way for tables ...
  191. # [01:13] * fantasai is not understanding enough to minute correctly
  192. # [01:13] <fantasai> Alex: I don't think merging the specs would help to resolve these questions
  193. # [01:13] <fantasai> Alex: I prefer keeping it separate as a coordinate system
  194. # [01:13] <fantasai> Alex: doesn't say what you use it for
  195. # [01:13] <fantasai> Alex: or where it's coming from
  196. # [01:13] <fantasai> Alex: Just defines a grid
  197. # [01:13] <fantasai> Alex: make sesnse and can be implemented
  198. # [01:14] <fantasai> Alex; they don't have to merge to be able to interact
  199. # [01:14] <fantasai> Tab: The only problem I have
  200. # [01:14] <fantasai> Tab: Is if you have e.g. on the body both a template and a type grid
  201. # [01:14] <fantasai> fantasai: I think you should be able to have multiple grids on a element, name them, and be able to align differnet things to different grids
  202. # [01:15] <fantasai> Markus: Keeping the specs separate also makes implementing easier
  203. # [01:15] <fantasai> faster
  204. # [01:15] <fantasai> Tab: I think multiple grids is useful and important
  205. # [01:15] <fantasai> Tab: And should be addressed if we want grid and template to interact nicely
  206. # [01:15] <fantasai> shepazu: While I appreciate your case, just from a deployment standpoint,
  207. # [01:16] <fantasai> shepazu: I'd rather see something like this implemented at a simple level
  208. # [01:16] <fantasai> shepazu: Than talk about how to merge them
  209. # [01:16] <fantasai> shepazu: It seems to me that grid is solving a lot of cases designers care about
  210. # [01:16] <fantasai> shepazu: slowing it down to add templates doesn't seem like a good idea
  211. # [01:16] <fantasai> Tab: I want template to be done
  212. # [01:16] <fantasai> shepazu: I don't know template as well :)
  213. # [01:16] <fantasai> Tab: A table defines its grid along its borders.
  214. # [01:16] * Quits: Kai (chatzilla@72.254.114.142) (Ping timeout)
  215. # [01:17] <fantasai> Tab: A type grid, you align your table cells along that grid
  216. # [01:17] <fantasai> Tab: you give the table width and height to that grid
  217. # [01:17] <fantasai> Tab: In that case you want multiple grids
  218. # [01:17] <fantasai> Tab: you'll be introducing other grids along the way
  219. # [01:17] <fantasai> Tab: I think it's useful to do so
  220. # [01:17] <fantasai> Tab: but you still want to maintain access to your original type grid
  221. # [01:17] <fantasai> Markus: To move these specs forward.. what are you asking for?
  222. # [01:18] <fantasai> Tab: Do you have specific feedback on this? Then we can look at your comments and address them and move forward
  223. # [01:18] <fantasai> s/Tab/Markus/
  224. # [01:18] <fantasai> Markus: or are you asking ... or are you asking just how they itneract
  225. # [01:18] <fantasai> Tab: Right now there's a note in the spec saying that it interacts with other specs
  226. # [01:18] <fantasai> Tab: And thats the area where I want more attention
  227. # [01:18] <fantasai> Markus: TO move theses things forward, we need to go through the process to maek that happen
  228. # [01:18] <fantasai> markus: Here that means working through the issues
  229. # [01:19] <fantasai> Markus: If there are no issues, then we leave the note and do nothing
  230. # [01:19] <fantasai> ...
  231. # [01:19] <fantasai> Tab: The note suggests right now an interaction that I don't think is good
  232. # [01:19] <fantasai> Alex: The note just says the interaction might not happen, removing it doesn't change anything.
  233. # [01:19] <fantasai> Tab: If grid and table don't interact and there are no plans for it, I'd like to keep it that way
  234. # [01:20] <fantasai> Alex: Maybe someone comes in and implements that.
  235. # [01:20] <fantasai> Steve: I'm losing track of where this discussion is going
  236. # [01:20] <fantasai> Steve: I don't see any concrete proposal to discuss
  237. # [01:20] <fantasai> Tab: I'm getting there
  238. # [01:20] <fantasai> Chris: I think the discussion start with "shouldn't we merge them because they do the same thing" and has gotten to "no they're doing different things" and now we should move on
  239. # [01:21] <fantasai> Tab: If we're going for simplicity, I'd there not to be a suggestion that tables create a gird
  240. # [01:21] <fantasai> Tab: I want it either removed, or something stating that it will be added later
  241. # [01:21] <fantasai> motion to remove note
  242. # [01:21] <fantasai> RESOLVED: remove note about interaction between grid and tables
  243. # [01:22] <fantasai> Peter: While we're on the topic, can we get better traction on these modules?
  244. # [01:22] <fantasai> Chris, to MSFT: You could ship your experimental implementation.
  245. # [01:22] <fantasai> Steve: There are two things missing
  246. # [01:23] <fantasai> Steve: One is an agreement that people will focus their attention on at least one particular one of the mechanisms and make some progress there
  247. # [01:23] <fantasai> Steve: I tend to agree with Tab's comment that there are too many mechanisms there
  248. # [01:23] <fantasai> Steve: There are too many, so people say there are too many, and I won't do anything
  249. # [01:23] <fantasai> Steve: The lack of agreement on one thing everyone will try and do is one of the blocks.
  250. # [01:23] <fantasai> Steve: Second thing is, esp with grid, there are open questions on syntax etc.
  251. # [01:24] <fantasai> Steve: Some things talked about in 2007 that need to get addressed.
  252. # [01:24] <fantasai> Steve: e.g. backwards intrusions of flaots
  253. # [01:24] <fantasai> Alex: Grid invites that kind of positioning ...
  254. # [01:24] <fantasai> Steve: syntax and sizing...
  255. # [01:25] <fantasai> Steve: Basically there are still open issues on grid
  256. # [01:25] <fantasai> shepazu: experimental implementations would help
  257. # [01:25] <fantasai> Bert: There are three prototypes for template
  258. # [01:26] <fantasai> Bert: Cesar's JS implementation, a JQuery implementation, and Andrew's htmllayout implementation
  259. # [01:26] <fantasai> shepazu: MSFT is interested in grid. Mozilla or Apple?
  260. # [01:26] <fantasai> shepazu: Is it a matter of priorities, or a matter of not liking the technology?
  261. # [01:27] <fantasai> dbaron: I don't know enough about the tech to answer
  262. # [01:28] <fantasai> ACTION Alex: remove note from grid wrt table interaction sect 4.something
  263. # [01:28] * RRSAgent records action 4
  264. # [01:28] * trackbot noticed an ACTION. Trying to create it.
  265. # [01:28] <trackbot> Created ACTION-192 - Remove note from grid wrt table interaction sect 4.something [on Alex Mogilevsky - due 2009-11-10].
  266. # [01:28] <fantasai> Topic: run-in definition
  267. # [01:28] * Quits: arronei (arronei@131.107.0.82) (Ping timeout)
  268. # [01:28] <plinss> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
  269. # [01:29] <fantasai> 4.2 and 4.3
  270. # [01:30] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  271. # [01:31] <fantasai> dbaron motions to shift discussion to later, maybe get bz on the phone
  272. # [01:31] <fantasai> bert would also like more time to prepare
  273. # [01:32] <fantasai> steve: 9am?
  274. # [01:32] <fantasai> resolved: move to 9am tomorrow
  275. # [01:32] <fantasai> Topic: Size to Fit (for text)
  276. # [01:33] <fantasai> Bert: it's basically to do what John was showing: make each line the same size
  277. # [01:33] <fantasai> Bert: Useful for titles especially
  278. # [01:33] <fantasai> Bert: Mostly used in advertisements
  279. # [01:34] * Joins: Kai (chatzilla@72.254.114.142)
  280. # [01:34] <fantasai> Bert: You make a block of text look like a block of text by varying font size until it fits
  281. # [01:34] <fantasai> Bert: We had a proposals for that
  282. # [01:34] <fantasai> Bert: It was given with last-line-align
  283. # [01:34] * Joins: arronei (arronei@131.107.0.80)
  284. # [01:34] <fantasai> Bert: and we had min and max font properties
  285. # [01:36] <fantasai> fantasai doesn't understand why you would want to apply only to the last line
  286. # [01:37] <fantasai> http://www.w3.org/TR/2003/CR-css3-text-20030514/#last-line-alignment-prop
  287. # [01:37] <fantasai> 'size' value
  288. # [01:37] <fantasai> fantasai: Why would you want only the last line at the bottom to blow up in size, even though the rest of the paragraph is a small type size?
  289. # [01:41] <fantasai> fantasai: It should apply to all lines
  290. # [01:42] <fantasai> someone argues that it's only one line of text
  291. # [01:42] <fantasai> because of forced breaks
  292. # [01:42] <fantasai> fantasai argues that on web pages, which are flex layout, you don't want to force breaks everywhere
  293. # [01:43] <fantasai> the title should be able to adapt to the available space
  294. # [01:43] <fantasai> and with css3-text's text-wrap: suppress, you can get the title to break in the appropriate places as the available space shrinks
  295. # [01:44] <fantasai> in such a case, if you wanted each line to size up to fill, you'd want the sizing to apply to all lines
  296. # [01:44] <fantasai> not just the last line
  297. # [01:45] <fantasai> Steve discusses another case where you size up the whole paragraph
  298. # [01:45] <fantasai> to fill space
  299. # [01:46] <fantasai> ?
  300. # [01:47] <dbaron> copyfit: none | size-each | size-largest
  301. # [01:47] <dbaron> text-justify-last: ...
  302. # [01:48] <TabAtkins> You'd want a min/max size on the copyfit too, to avoid runaway craziness.
  303. # [01:48] <fantasai> There was a discussion somewhere of a last-line-length
  304. # [01:48] <fantasai> Which would trigger rejustification if the last line was too short
  305. # [01:49] <fantasai> Peter: Another case is wanting to trigger justification on the last line or not based on how long it is; e.g. if it's 70% of the line, justify it, if it's only 2 words, left-align
  306. # [01:49] <fantasai> fantasai: If I was adding this to the spec, I would add 'size' as a keyword to text-justify
  307. # [01:50] <fantasai> fantasai: text-align: justify turns on justification
  308. # [01:50] <fantasai> fantasai: text-justify specifies how you justify: which algorithm
  309. # [01:52] <fantasai> ....
  310. # [01:52] * Quits: Curt` (curt@76.243.219.200) (Quit: Sleep)
  311. # [01:52] <fantasai> dbaron: There's been a bunch of discussion of changing the last line behavior
  312. # [01:52] <fantasai> s/behavior//justification/
  313. # [01:52] <fantasai> dbaron: and then discussion of changing the size of the text.
  314. # [01:52] <fantasai> dbaron: These seem largely independent
  315. # [01:52] <fantasai> dbaron: I suggested a copy-fit property
  316. # [01:52] <fantasai> dbaron: one value is none, which is now
  317. # [01:52] * Joins: shepazu (schepers@128.30.52.169)
  318. # [01:52] <fantasai> dbaron: One is size the largest thing to fill thes pace
  319. # [01:53] <fantasai> dbaron: and then everything else size up to match
  320. # [01:53] * Quits: shepazu (schepers@128.30.52.169) (Client exited)
  321. # [01:54] <fantasai> s/thing/line/
  322. # [01:54] <fantasai> dbaron: the last one is to scale each line independently
  323. # [01:55] <fantasai> dbaron: explicit letter-spacing happens before this, justification afterward
  324. # [01:56] <fantasai> ACTION fantasai: Add this stuff as notes in css3-text
  325. # [01:56] * trackbot noticed an ACTION. Trying to create it.
  326. # [01:56] * RRSAgent records action 5
  327. # [01:56] <trackbot> Created ACTION-193 - Add this stuff as notes in css3-text [on Elika Etemad - due 2009-11-10].
  328. # [01:57] <fantasai> pierre: You often want to do this in certain ratios
  329. # [01:57] <fantasai> mentions of character stretching and compression for justification
  330. # [01:58] * Joins: shepazu (schepers@128.30.52.169)
  331. # [01:58] <fantasai> Steve: There are properties other than size that you'd want to tweak for this
  332. # [01:59] <fantasai> Steve: Perhaps have a value to add to properties saying how much to tweak
  333. # [01:59] <fantasai> or whether
  334. # [02:00] <fantasai> dbaron: Not sure if we want this available on blocks or inlines
  335. # [02:00] <fantasai> Tab: was thinking of chaining techniques, specify in detail how you want something justified
  336. # [02:00] <fantasai> ....
  337. # [02:01] <fantasai> Steve: In InDesign the size of the window doesn't change
  338. # [02:01] <fantasai> dsinger: right, you're designing for a specific size of paper for print
  339. # [02:01] <fantasai> Tab: I think the techniques we're talking about right now are enough for cases where you want that effect. For a movie poster, you'd not use CSS
  340. # [02:02] <fantasai> Bert: I made a collection of examples... trying to find it
  341. # [02:02] <fantasai> Peter: I think that's it for the day
  342. # [02:03] <tantek> http://wiki.csswg.org/planning/tpac-2009
  343. # [02:03] <Bert_lap> http://www.w3.org/Style/Group/2009/Santa-Clara.html
  344. # [02:03] <Bert_lap> http://wiki.csswg.org/planning/tpac-2009
  345. # [02:04] <fantasai> Tantek: Color draft?
  346. # [02:05] <fantasai> Steve: your issue with color, gamma paragraph?
  347. # [02:06] <fantasai> ...
  348. # [02:06] <fantasai> Steve: since I won't be here for that discussion
  349. # [02:06] <fantasai> Steve: Don't break plugins
  350. # [02:06] <fantasai> Steve: work with them to fix the problem
  351. # [02:07] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
  352. # [02:07] * Parts: TabAtkins (chatzilla@72.254.56.183)
  353. # [02:07] * Quits: bradk (bradk@72.254.115.105) (Quit: Computer has gone to sleep)
  354. # [02:07] * Quits: plinss (plinss@72.254.111.33) (Quit: plinss)
  355. # [02:08] * Quits: jdaggett (jdaggett@72.254.115.101) (Quit: jdaggett)
  356. # [02:09] <Bert_lap> -> http://www.w3.org/Style/Group/1999/10/copyfit-examples.html justifying by font size
  357. # [02:09] * Quits: sylvaing (sylvaing@72.254.116.25) (Ping timeout)
  358. # [02:10] * Joins: myakura (myakura@114.163.221.102)
  359. # [02:11] * Quits: dsinger (dsinger@72.254.95.64) (Quit: dsinger)
  360. # [02:12] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  361. # [02:13] * Quits: smfr (smfr@72.254.115.22) (Quit: smfr)
  362. # [02:13] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
  363. # [02:13] * Quits: mmielke (mmielke@72.254.83.160) (Ping timeout)
  364. # [02:13] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
  365. # [02:14] * Quits: alexmog (alexmog@72.254.94.79) (Ping timeout)
  366. # [02:15] * Joins: tantek (tantek@72.254.62.180)
  367. # [02:16] * Quits: szilles (chatzilla@72.254.62.158) (Ping timeout)
  368. # [02:17] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
  369. # [02:19] * Quits: Bert_lap (bert@128.30.52.169) (Ping timeout)
  370. # [02:20] * Quits: myakura (myakura@114.163.221.102) (Ping timeout)
  371. # [02:21] * Parts: Kai (chatzilla@72.254.114.142)
  372. # [02:23] * Joins: myakura (myakura@118.15.135.158)
  373. # [02:23] * Quits: dethbakin (dethbakin@72.254.115.244) (Quit: dethbakin)
  374. # [02:27] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  375. # [02:34] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  376. # [02:39] * Parts: jfkthame (jonathan@66.207.206.178)
  377. # [02:40] * Quits: mjs (mjs@72.254.93.235) (Quit: mjs)
  378. # [02:40] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  379. # [02:59] * Quits: myakura (myakura@118.15.135.158) (Quit: Leaving...)
  380. # [03:12] <Zakim> ChrisL, you asked to be reminded at this time to go home
  381. # [03:15] * Zakim excuses himself; his presence no longer seems to be needed
  382. # [03:15] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  383. # [03:17] * Joins: sylvaing (sylvaing@72.254.116.25)
  384. # [03:20] * Joins: tantek (tantek@98.248.34.230)
  385. # [03:20] * Parts: anne (annevk@72.254.94.228)
  386. # [03:23] * Quits: hamaji (hamaji@72.254.84.191) (Ping timeout)
  387. # [04:07] * Quits: tantek (tantek@98.248.34.230) (Quit: tantek)
  388. # [04:38] * Joins: mmielke (mmielke@72.254.107.105)
  389. # [04:38] * Joins: Arron (arronei@72.254.111.4)
  390. # [04:47] * Joins: jdaggett (jdaggett@12.229.246.2)
  391. # [04:51] * Quits: mmielke (mmielke@72.254.107.105) (Ping timeout)
  392. # [04:52] * Joins: mmielke (mmielke@72.254.107.105)
  393. # [05:08] * Joins: dsinger (dsinger@68.126.189.44)
  394. # [05:43] * Joins: mjs (mjs@69.181.42.237)
  395. # [06:03] * Quits: mmielke (mmielke@72.254.107.105) (Ping timeout)
  396. # [06:39] * Joins: TabAtkins (chatzilla@72.254.56.183)
  397. # [07:00] <fantasai> http://www.w3.org/Style/CSS/Specs/Read
  398. # [07:10] * Quits: sylvaing (sylvaing@72.254.116.25) (Ping timeout)
  399. # [07:34] * Joins: TabAtkins_ (chatzilla@72.254.56.183)
  400. # [07:34] * Quits: TabAtkins (chatzilla@72.254.56.183) (Connection reset by peer)
  401. # [07:34] * TabAtkins_ is now known as TabAtkins
  402. # [08:03] * Quits: TabAtkins (chatzilla@72.254.56.183) (Ping timeout)
  403. # [08:11] * Joins: shepazu (schepers@128.30.52.169)
  404. # [08:27] * Joins: TabAtkins (chatzilla@72.254.56.183)
  405. # [08:38] * Joins: TabAtkins_ (chatzilla@72.254.56.183)
  406. # [08:38] * Quits: TabAtkins (chatzilla@72.254.56.183) (Connection reset by peer)
  407. # [08:38] * TabAtkins_ is now known as TabAtkins
  408. # [08:54] * Parts: howcome (howcome@80.203.19.119)
  409. # [09:47] * Quits: TabAtkins (chatzilla@72.254.56.183) (Ping timeout)
  410. # [09:50] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
  411. # [11:28] * RRSAgent excuses himself; his presence no longer seems to be needed
  412. # [11:28] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
  413. # [11:47] * Joins: Arron (arronei@72.254.111.4)
  414. # [11:50] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
  415. # [11:53] * Quits: CesarAcebal (acebal@85.152.177.207) (Quit: CesarAcebal)
  416. # [12:15] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
  417. # [14:32] * Joins: annevk (opera@72.254.82.30)
  418. # [15:30] * Joins: kohei (kohei@67.203.153.14)
  419. # [15:30] * Parts: kohei (kohei@67.203.153.14)
  420. # [15:30] * Joins: kohei (kohei@67.203.153.14)
  421. # [15:30] * kohei changes topic to ''
  422. # [15:30] * kohei changes topic to ''
  423. # [16:01] * Joins: sylvaing (sylvaing@72.254.86.181)
  424. # [16:22] * Quits: jdaggett (jdaggett@12.229.246.2) (Quit: jdaggett)
  425. # [16:22] * Quits: dsinger (dsinger@68.126.189.44) (Quit: dsinger)
  426. # [16:23] * Joins: jdaggett (jdaggett@12.229.246.2)
  427. # [16:27] * Joins: shepazu (schepers@128.30.52.169)
  428. # [16:28] * Joins: mmielke (mmielke@72.254.124.123)
  429. # [16:30] * Quits: jdaggett (jdaggett@12.229.246.2) (Ping timeout)
  430. # [16:36] * Quits: kohei (kohei@67.203.153.14) (Quit: Computer goes to sleep!)
  431. # [16:51] * Joins: MoZ (chatzilla@82.230.92.154)
  432. # [16:52] * Joins: TabAtkins (chatzilla@72.254.99.227)
  433. # [17:01] <annevk> lots of questions so early in the morning TabAtkins :)
  434. # [17:02] <TabAtkins> They're from Elika. She's too lazy to get out of bed. ^_^
  435. # [17:03] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
  436. # [17:04] <annevk> I see :)
  437. # [17:10] * Joins: Arron (arronei@72.254.101.153)
  438. # [17:10] * Parts: Yves (ylafon@128.30.52.169)
  439. # [17:23] * Joins: dsinger (dsinger@17.197.23.228)
  440. # [17:23] * Quits: sylvaing (sylvaing@72.254.86.181) (Ping timeout)
  441. # [17:23] * Joins: sylvaing (sylvaing@72.254.86.181)
  442. # [17:27] * Joins: bradk (bradk@72.254.101.220)
  443. # [17:28] * Joins: hamaji (hamaji@72.254.92.142)
  444. # [17:28] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  445. # [17:30] * Quits: sylvaing (sylvaing@72.254.86.181) (Ping timeout)
  446. # [17:31] * Joins: kohei (kohei@72.254.59.20)
  447. # [17:33] * Quits: Arron (arronei@72.254.101.153) (Ping timeout)
  448. # [17:36] * Joins: smfr (smfr@72.254.92.79)
  449. # [17:38] * Quits: mmielke (mmielke@72.254.124.123) (Ping timeout)
  450. # [17:45] * Joins: sylvaing (sylvaing@72.254.86.181)
  451. # [17:47] * Joins: mmielke (mmielke@72.254.93.74)
  452. # [17:47] * mmielke is now known as markusm
  453. # [17:48] * Joins: Arron (arronei@72.254.101.153)
  454. # [17:48] * Joins: dbaron (dbaron@63.245.220.11)
  455. # [17:49] * Joins: Bert_lap (bert@128.30.52.169)
  456. # [17:55] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
  457. # [17:56] * Joins: bradk (bradk@72.254.101.220)
  458. # [17:57] * Joins: jdaggett (jdaggett@72.254.82.75)
  459. # [17:58] * Quits: TabAtkins (chatzilla@72.254.99.227) (Ping timeout)
  460. # [17:59] * Joins: plinss (plinss@72.254.59.50)
  461. # [17:59] * Joins: dethbakin (dethbakin@72.254.103.251)
  462. # [18:01] * Joins: bz (bzbarsky@66.92.65.154)
  463. # [18:05] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  464. # [18:06] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  465. # [18:06] <RRSAgent> logging to http://www.w3.org/2009/11/03-CSS-irc
  466. # [18:06] <plinss> rrsagent make logs public
  467. # [18:06] * Joins: TabAtkins (chatzilla@72.254.99.227)
  468. # [18:06] <plinss> zakim, this will be style
  469. # [18:06] <Zakim> ok, plinss; I see Styl_CSS-FP(TPAC)12:00PM scheduled to start 6 minutes ago
  470. # [18:07] <fantasai> Topic: Run-ins
  471. # [18:07] <dbaron> Zakim, what is the number?
  472. # [18:07] <Zakim> I don't understand your question, dbaron.
  473. # [18:07] <dbaron> Zakim, what is the phone number?
  474. # [18:07] <Zakim> I don't understand your question, dbaron.
  475. # [18:07] * Joins: glazou (glazou@72.254.63.160)
  476. # [18:07] <dbaron> Zakim, passcode?
  477. # [18:07] <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dbaron
  478. # [18:08] <plinss> zakim, dial salon 9
  479. # [18:08] <Zakim> I don't understand 'dial salon 9', plinss
  480. # [18:08] <fantasai> Zakim, dial Salon_9
  481. # [18:08] <Zakim> ok, fantasai; the call is being made
  482. # [18:08] <dbaron> bz, conference code is above^
  483. # [18:08] * Quits: annevk (opera@72.254.82.30) (Ping timeout)
  484. # [18:09] <dbaron> Zakim, who is on the phone?
  485. # [18:09] <Zakim> Styl_CSS-FP(TPAC)12:00PM has not yet started, dbaron
  486. # [18:09] <Zakim> On IRC I see glazou, TabAtkins, RRSAgent, Zakim, bz, dethbakin, plinss, jdaggett, bradk, Bert_lap, dbaron, Arron, markusm, sylvaing, smfr, kohei, hamaji, dsinger, MoZ, arronei,
  487. # [18:09] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
  488. # [18:09] <Zakim> ... Hixie, karl, krijnh, fearphage, fantasai, trackbot, Bert
  489. # [18:09] * bz calls
  490. # [18:09] * Joins: Kai (chatzilla@72.254.88.78)
  491. # [18:10] <dbaron> Zakim, who is on the phone?
  492. # [18:10] <Zakim> Styl_CSS-FP(TPAC)12:00PM has not yet started, dbaron
  493. # [18:10] <Zakim> On IRC I see Kai, glazou, TabAtkins, RRSAgent, Zakim, bz, dethbakin, plinss, jdaggett, Bert_lap, dbaron, Arron, markusm, sylvaing, smfr, kohei, hamaji, dsinger, MoZ, arronei,
  494. # [18:10] <Zakim> ... Hixie, karl, krijnh, fearphage, fantasai, trackbot, Bert
  495. # [18:10] * Joins: bradk (bradk@72.254.101.220)
  496. # [18:10] <dbaron> Zakim, this is Style
  497. # [18:10] <Zakim> ok, dbaron; that matches Styl_CSS-FP(TPAC)12:00PM
  498. # [18:10] <dbaron> Zakim, who is on the phone?
  499. # [18:10] <Zakim> On the phone I see SteveZ, Salon_9, +1.617.487.aaaa
  500. # [18:10] <dbaron> Zakim, aaaa is bzbarsky
  501. # [18:10] <Zakim> +bzbarsky; got it
  502. # [18:11] * Joins: annevk (opera@72.254.82.30)
  503. # [18:11] * Joins: Lachy (Lachlan@72.254.56.137)
  504. # [18:12] * Joins: tantek (tantek@72.254.103.162)
  505. # [18:12] <TabAtkins> Scribenick: TabAtkins
  506. # [18:12] <dbaron> Zakim, who is noisy?
  507. # [18:12] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
  508. # [18:12] <Zakim> dbaron, listening for 10 seconds I heard sound from the following: SteveZ (37%), Salon_9 (20%)
  509. # [18:13] <bz> how do I mute myself?
  510. # [18:13] <bz> via the phone system?
  511. # [18:13] <dbaron> Zakim, mute bzbarsky
  512. # [18:13] <Zakim> bzbarsky should now be muted
  513. # [18:13] * dsinger zakim, mute me
  514. # [18:13] * Zakim sorry, dsinger, I do not know which phone connection belongs to you
  515. # [18:13] <dbaron> Zakim, unmute bzbarsky
  516. # [18:13] <Zakim> bzbarsky should no longer be muted
  517. # [18:13] <TabAtkins> Bert: As a reminder, general idea of runin is a heading followed by a paragraph, and you want to display the header inline, perhaps with styles to make it stand out.
  518. # [18:13] <bz> aha, nice
  519. # [18:13] <bz> zakim, mute bzbarsky
  520. # [18:13] <Zakim> bzbarsky should now be muted
  521. # [18:13] <TabAtkins> Bert: Another application is a dl wheree the dt runs into the dd that follows rather than above it.
  522. # [18:13] <TabAtkins> Bert: First issue: When can this happen? When can the run-in element become inline in the next element, and when not?
  523. # [18:13] <TabAtkins> Bert: This dpeends on the element itself, and what follows.
  524. # [18:14] * bz wonders whether he should be able to tell what's being said right now..
  525. # [18:14] <TabAtkins> Bert: There must be a block afterward, for it to run into, and it can't contain blocks.
  526. # [18:14] * fantasai ideally, yes
  527. # [18:14] <bz> mmm
  528. # [18:14] <TabAtkins> Bert: Original definition wasn't precise.
  529. # [18:14] * Joins: alexmog (alexmog@72.254.94.217)
  530. # [18:14] * fantasai bert is just summarizing, Tab's got the minutes pretty good
  531. # [18:14] <dbaron> bz, can't here bert?
  532. # [18:14] <bz> I can't make out any of it
  533. # [18:14] <dbaron> hear
  534. # [18:14] <bz> it's very quiet and pretty noisy
  535. # [18:14] <TabAtkins> Bert: *points to email*
  536. # [18:14] <bz> but only when speaker is talking
  537. # [18:14] * sylvaing dubs Tab's desktop theme 'Chernobyl'
  538. # [18:15] <bz> aha
  539. # [18:15] <bz> this is better!
  540. # [18:15] <bz> yes!
  541. # [18:15] <bz> much better
  542. # [18:15] * glazou waves at bz :)
  543. # [18:15] <TabAtkins> Bert: The first link goes to pag holding conditions for element following the runin.
  544. # [18:15] <bz> which page are these links on?
  545. # [18:15] <TabAtkins> Bert: It must have a following sibling.
  546. # [18:15] <TabAtkins> Bert: Ignore anything that's not in flow.
  547. # [18:15] <bz> ah, I see, archives
  548. # [18:15] <bz> ok
  549. # [18:15] <TabAtkins> Bert: Such as floats, display:none elems, etc.
  550. # [18:16] <TabAtkins> Bert: At top of the message, first point is about run-in itself. Come back to that later.
  551. # [18:16] <TabAtkins> Bert: Point 2!
  552. # [18:16] <TabAtkins> Bert: You need to have an element after the run-in that is either block or list-item, or else the element displays as block.
  553. # [18:16] <TabAtkins> Bert: Also, it clarifies that run-in comes before any pseudoelements of the following sibling, so element order is retained.
  554. # [18:17] <TabAtkins> Bert: There was discussion about whether block+list-item was sufficient. Frex, would run-in+run-in+block causes the two run-ins to run together, or would the first make the second a block, and then the second doesn't run in.
  555. # [18:17] <TabAtkins> Bert: Frex, an <h2> followed by an <h3>. Perhaps the content between the two headers is temporarily suppressed.
  556. # [18:18] <fantasai> s/h2/h3/
  557. # [18:18] <fantasai> fantasai: What about <h2> followed by <h3>?
  558. # [18:18] <TabAtkins> Tantek: You can just put several run-ins in a row, right? And they'll all run in?
  559. # [18:18] <TabAtkins> Bert: No, not by current language. The first would go block, the second would run-in.
  560. # [18:19] <TabAtkins> Bert: The dt case makes a stronger example. You may want multiple <dt>s applying to the same <dd> to run together.
  561. # [18:19] <TabAtkins> Bert: But I think the heading case is strong enough that we don't want to make multiple consecutive run-ins go together.
  562. # [18:19] <TabAtkins> Bert: Point 1! Conditions on the run-in, and what children it can contain.
  563. # [18:19] <TabAtkins> Bert: You have to look not only at children, but at all in-flow descendants.
  564. # [18:20] * Joins: shepazu (schepers@128.30.52.169)
  565. # [18:20] <TabAtkins> Bert: The definition is in terms of elements that are incompatible with run-in behavior; elements that inhibit run-in.
  566. # [18:20] <TabAtkins> Bert: If one of the children inhibits run-in, the run-in must go block.
  567. # [18:20] <TabAtkins> Bert: Again, ignore out-of-flow children. But if one of the remaining children is block/list-item/table/run-in, the run-in cannot go inline.
  568. # [18:21] <TabAtkins> Bert: The remaining children must be inline, so recursively descend to look for children with block/list-item/etc. If there are no in-flow children that inhibit, the element can run-in.
  569. # [18:21] <TabAtkins> Fantasai: You can combine a,b,d and say "all children, including :before and :after".
  570. # [18:21] <TabAtkins> Bert: Yeah, that's already done.
  571. # [18:22] <TabAtkins> Bert: Rewritten definition at bottom of email that has only two clauses.
  572. # [18:22] <TabAtkins> fantasai: Can we say block-level element or display type, so we're not tying things to a specific list?
  573. # [18:22] <TabAtkins> fantasai: The more we can do that, the better we'll be in the future when we introduce new types.
  574. # [18:22] <TabAtkins> tantek: That's mostly good, but it might also causes problems if a future display type specially should interact with run-in.
  575. # [18:23] <TabAtkins> fantasai: More things should prevent run-in than less.
  576. # [18:23] <TabAtkins> plinss: It's far more likely that something new would inhibit run-in than allow it.
  577. # [18:23] <TabAtkins> Bert: I haven't looked into that specifically, to see if the definition of "block-level" would work.
  578. # [18:23] <TabAtkins> fantasai: Yeah, we've just had a lot of problems with inline-blocks, because a lot of specific lists didn't take it into account.
  579. # [18:24] <TabAtkins> tantek: That's a good argument. inline-block may act like a block *or* inline.
  580. # [18:24] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  581. # [18:24] <TabAtkins> fantasai: What we need is the ability to say something is a block on the eoutside, or a block on the inside.
  582. # [18:24] <TabAtkins> tantek: Yeah, but we didn't even know that until we made inline-block. We didn't realize the abstraction was even necessary.
  583. # [18:25] <TabAtkins> fantasai: You have the same problem with tables and table-cells. Table cells act like a block container, but it's not like a block on the outside.
  584. # [18:25] <TabAtkins> fantasai: I don't want to introduce a new display-type and say "Let's go audit CSS2.1 and fix all the places."
  585. # [18:25] <TabAtkins> fantasai: But I think for the new display types, our abstractions are good enough to talk about.
  586. # [18:25] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
  587. # [18:26] * Joins: Lachy (Lachlan@72.254.56.137)
  588. # [18:26] <TabAtkins> plinss: If we have a new list, we're *guaranteed* to update it. An abstraction *may* need to be updated.
  589. # [18:26] <TabAtkins> tantek: I'd rather have things fail obviously than subtly.
  590. # [18:26] <TabAtkins> fantasai: It's never obvious. People look at the list of things that are allowed, and just assume that it's still correct.
  591. # [18:26] <TabAtkins> dbaron: We do have the terms "inline-level" and "block-level" elements, which can work as the excluded/included lists.
  592. # [18:27] <bz> That was updated
  593. # [18:27] <TabAtkins> dbaron: I've noticed the list of Bert's seems to be wrong. A run-in containing a run-in is inhibited.
  594. # [18:27] <TabAtkins> Bert: That's what is says.
  595. # [18:27] <TabAtkins> dbaron: Sorry, yeah.
  596. # [18:27] <bz> http://lists.w3.org/Archives/Public/www-style/2009Sep/0013.html has the right text
  597. # [18:27] <fantasai> Peter: If we had an include list and an exclude list, then people would notice "oh, it's missing". But if we have an include list and "everythingg else" is excluded, nobody notices that something's wrong.
  598. # [18:27] <TabAtkins> tantek: How many implementors have some kind of run-in.
  599. # [18:27] <TabAtkins> smfr: Webkit has basic run-in behavior, but sort of broken.
  600. # [18:28] <TabAtkins> dbaron: I think everyone but Moz implements, but they all do it differently.
  601. # [18:28] <TabAtkins> tantek: And presumably the test-cases that demonstrate lack of interop is published?
  602. # [18:28] <TabAtkins> TabAtkins: Yeah, I think Boris published those.
  603. # [18:28] <TabAtkins> tantek: It would be good to get a pointer for that.
  604. # [18:28] <Bert> -> http://www.w3.org/Style/Group/css2-src/visuren.html#block-boxes Definition of "block-level elements" (9.2.1)
  605. # [18:28] <Zakim> -SteveZ
  606. # [18:28] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Sep/0018.html
  607. # [18:29] * Joins: mjs (mjs@72.254.84.91)
  608. # [18:29] <TabAtkins> dbaron: I think Boris is waiting to publish the test-cases until he's sure that they're right.
  609. # [18:29] <TabAtkins> tantek: It's useful to have real examples, not just specified abstractly.
  610. # [18:29] <sylvaing> correction; a testcase from bz: http://lists.w3.org/Archives/Public/www-style/2009Sep/0017.html
  611. # [18:29] <TabAtkins> tantek: It may turn out that once we see a real exampl of the prose text, it's not what we wanted.
  612. # [18:29] <TabAtkins> Bert: I don't have a preference for a list or a "block-level" definition.
  613. # [18:30] <TabAtkins> Bert: There's some subtlety in that it would refer to run-ins and say "some of the time".
  614. # [18:30] <TabAtkins> Bert: Verdict on the definition?
  615. # [18:31] <TabAtkins> fantasai: I think I'd prefer it to say "block-level elements", but I don't need to block this on this. We can raise a separate issue for it.
  616. # [18:32] <TabAtkins> Bert: So that sounds like proposal #1?
  617. # [18:32] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Aug/0607.html
  618. # [18:32] <fantasai> accept text at bottom
  619. # [18:32] <bz> http://lists.w3.org/Archives/Public/www-style/2009Aug/0594.html
  620. # [18:32] <TabAtkins> RESOLVED accept text at bottom.
  621. # [18:32] <TabAtkins> Bert: Next issue. Should still be easy.
  622. # [18:32] <TabAtkins> Bert: What do to with replaced elements?
  623. # [18:32] <bz> I assume we decided that behavior is ok?
  624. # [18:33] <bz> Zakim, unmute bz
  625. # [18:33] <Zakim> bzbarsky should no longer be muted
  626. # [18:33] <TabAtkins> Bert: Maybe a wider issue. In my implementation replaced elements are always empty.
  627. # [18:33] <TabAtkins> fantasai: No.
  628. # [18:33] <TabAtkins> Bert: I know what I think.
  629. # [18:33] <TabAtkins> fantasai: In the document tree it's not necessarily empty: textarea, object, etc.
  630. # [18:33] <TabAtkins> Bert: That's the issue. Do you look in the document tree, or just in the things considered for rendering?
  631. # [18:33] <TabAtkins> Bert: In replaced elements, the children are thrown away.
  632. # [18:34] <TabAtkins> fantasai: And form elements may or may not b replaced, depending.
  633. # [18:34] <TabAtkins> Bert: Let's look at the proposal. There's proposed text to clarify.
  634. # [18:34] <TabAtkins> Bert: Section 3.1
  635. # [18:34] <dbaron> bz, doesn't the table-cell have a block wrapping it in that case?
  636. # [18:34] <TabAtkins> Bert: Do we consider replaced elements as empty so we never look at its children, or do we look at the children of the replaced element?
  637. # [18:35] <bz> dbaron: it doesn't
  638. # [18:35] <TabAtkins> fantasai: Replaced elements are defined as children being outside of the scope. Per CSS, there aren't any children.
  639. # [18:35] <bz> dbaron: or rather....
  640. # [18:35] <TabAtkins> Bert: So that seems to mean that we don't have to look at them.
  641. # [18:35] <bz> dbaron: the interaction is interesting
  642. # [18:35] <fantasai> s/Per CSS, there aren't any children//
  643. # [18:35] <fantasai> fantasai: Whether or not it has children doesn't matter
  644. # [18:35] <TabAtkins> Boris: I think the behavior is well-defeined for if the runin is into a table cell or not.
  645. # [18:36] <TabAtkins> Boris: It's a little weird because if it has a table child it can't run in, but I think it's all consistent.
  646. # [18:36] <TabAtkins> Boris: It's something to be careful with.
  647. # [18:36] <tantek> sylvaing thanks - http://lists.w3.org/Archives/Public/www-style/2009Sep/0017.html helps but would prefer actual live test cases we can quickly click and run across browsers/machines.
  648. # [18:36] <TabAtkins> dbaron: I would think that if it has any table stuff in it, except inline-table, it should inhibit run-in.
  649. # [18:36] <TabAtkins> Bert: But if you ahve a table-cell inside an inline element, it automatically generates an inline table.
  650. # [18:37] <TabAtkins> tantek: Did we ever define pseudoelems for the generated wrappers for tables?
  651. # [18:37] <TabAtkins> fantasai: No.
  652. # [18:37] <TabAtkins> Boris: Anonymous blocks have to have something to do with what's going on here.
  653. # [18:37] <fantasai> s/fantasai/?/
  654. # [18:37] <TabAtkins> dbaron: I don't think there's an inconsistency between bori's two cases, because it only occurs into inlines and not other things.
  655. # [18:37] <dbaron> bz, I don't think we're inconsistent between those two cases, since the recursion in Bert's proposal only recurs into inlines
  656. # [18:38] <TabAtkins> Boris: The issue raised here was addressed in Bert's proposal, and should both result in the run-in running in.
  657. # [18:38] <Zakim> +SteveZ
  658. # [18:38] <tantek> anonymous table pseudoelements and anonymous table-row pseudoelements - that get auto-generated when an element is set to display:table-cell outside of any kind of table context for example
  659. # [18:38] <TabAtkins> Bert: Back to replaced elements. Proposal is to clarify definition in section 3.1, where it says "out of scope"
  660. # [18:39] <bz> tantek, http://lists.w3.org/Archives/Public/www-style/2009Jul/0030.html has another test
  661. # [18:39] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
  662. # [18:39] <bz> tantek: but yes, testcases that are clickable (or at least reftest-like) will happen
  663. # [18:39] <TabAtkins> Bert: Definition of replaced elements in 3.1 says that content it out of scope. I want to clarify that you don't have to look inside a replaced element to determine if it inhibits run-in.
  664. # [18:39] * Joins: Lachy (Lachlan@72.254.56.137)
  665. # [18:39] <TabAtkins> fantasai: I disagree with what Bert hasn't said yet.
  666. # [18:39] <bz> tantek, my current estimate is we need ~100ish tests to test all reasonably
  667. # [18:40] <tantek> bz - thanks much - that will help a lot
  668. # [18:40] <tantek> ouch!
  669. # [18:40] <TabAtkins> Bert: Proposal is that document tree is empty for CSS.
  670. # [18:40] <bz> tantek, dynamic changes make it extra fun. ;)
  671. # [18:40] <TabAtkins> Bert: you disagree, fantasai?
  672. # [18:40] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
  673. # [18:40] <bz> tantek, e.g. webkit gets confused if you change textnodes between the run-in and the block from whitespace to not or vice versa
  674. # [18:40] <TabAtkins> fantasai: Yeah, in the document tree the elements isn't considered empty, and for selectors and such you don't *want* it to be empty.
  675. # [18:40] <tantek> bz - even just a few live static tests to start with, even if "exploratory" in nature (i.e. not knowing exactly what *should* occur) would help answer some of the design questions.
  676. # [18:40] <tantek> bz - agreed, things are much more difficult when dynamic.
  677. # [18:41] <TabAtkins> fantasai: We'll be referring back to this later, and you can't screw around with the document tree for future extentions.
  678. # [18:41] <tantek> useful to at least get the static cases figured out first though right?
  679. # [18:41] * Joins: glazou (glazou@72.254.63.160)
  680. # [18:41] <TabAtkins> Bert: But that's the definition of replaced. The content that was there no longer appears.
  681. # [18:41] <bz> yeah, no point testing dynamic much till static is defined
  682. # [18:41] <TabAtkins> fantasai: But what about inline SVG? There's obviously children there.
  683. # [18:41] * tantek implemented some degree of CSS2 display:run-in in IE5/Mac about 10 years ago.
  684. # [18:41] <TabAtkins> Bert: But it looks empty for CSS.
  685. # [18:41] * tantek curious how many cases he got right/wrong.
  686. # [18:41] <bz> tantek, http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html has an attached testcase
  687. # [18:42] <bz> tantek, with lots of different cases tested
  688. # [18:42] <TabAtkins> fantasai: You're talking about the rendering tree, which is different from the document tre.
  689. # [18:42] <tantek> http://lists.w3.org/Archives/Public/www-style/2009Jul/att-0025/test.html is a good start
  690. # [18:42] <TabAtkins> Bert: There is no rendering tree.
  691. # [18:42] <bz> tantek, sadly, without much description of what _should_ happen
  692. # [18:42] <glazou> "There is no rendering tree" -- Bert 2009-11-03
  693. # [18:42] <TabAtkins> fantasai: If we can reword it so we don't say the element is empty, I may be happy with it.
  694. # [18:42] <tantek> bz - presumably red means wrong?
  695. # [18:42] <TabAtkins> Bert: We may avoid 'empty', but need to say that the contents of a replaced leement is ignored for CSS.
  696. # [18:42] <bz> tantek, sorry, no. color is just used to tell apart the various blocks
  697. # [18:42] <TabAtkins> Fantasai: Sure, just don't call it empty.
  698. # [18:43] <bz> tantek, I should have used purple or blue.....
  699. # [18:43] <TabAtkins> tantek: so it's opaque
  700. # [18:43] <bz> tantek, all the right/wrong is in whether things run in or not. So whether they're on one line or two lines
  701. # [18:43] <bz> tantek, and which is contained in which border
  702. # [18:43] * bz gathered this was normal, yes. ;)
  703. # [18:44] <TabAtkins> fantasai: What about the parent selector? object:has(a), should we just say this doesn't match? Selectors should work on the actual DOM.
  704. # [18:44] <bz> I just have nothing to say on this; the behavior we want is obvious; the only question is how to define it.
  705. # [18:44] <fantasai> Let's say I have a <p> element with an <a> inside it
  706. # [18:45] <fantasai> I write a selector for <p>s that have <a>s inside them using Selectors 4
  707. # [18:45] <fantasai> then I say { content: url(image.png); }
  708. # [18:45] <bz> so...
  709. # [18:45] <fantasai> That makes it replaced
  710. # [18:45] <bz> it's even simpler
  711. # [18:45] <fantasai> which makes the selector no longer applyl
  712. # [18:45] <bz> Say I have an HTML <img>
  713. # [18:45] <bz> that I style with :empty
  714. # [18:45] <fantasai> because it's replaced
  715. # [18:45] <fantasai> and now it's empty!!
  716. # [18:45] <tantek> fantasai - no selector feedback loops
  717. # [18:45] <bz> img:empty { border: 10px solid purple; }
  718. # [18:45] * Joins: ChrisL (ChrisL@128.30.52.169)
  719. # [18:45] <TabAtkins> glazou: But why would this no longer apply?
  720. # [18:46] <TabAtkins> fantasai: Because we say that it's a replaced element now, and thus it would be empty. No selector can target the contents anymore.
  721. # [18:47] <TabAtkins> dbaron: We should fix this issue in the run-in section, not by changing the definition of a replaced element.
  722. # [18:48] <TabAtkins> TabAtkins: fantasai is saying that run-ins can ignore children of replaced, but we shouldn't just say that the children don't exist.
  723. # [18:48] <TabAtkins> Bert: We don't care about the DOM, we care if CSS says they exist.
  724. # [18:48] <TabAtkins> fantasai: But they do exist. You can select on them.
  725. # [18:49] <TabAtkins> Chris: Ignoring them and making them disappear are two different things.
  726. # [18:49] <TabAtkins> Bert: I just want to clarify that we're using a definition is internally consistent.
  727. # [18:49] <TabAtkins> Bert: Per CSS, whatever's inside a replaced element simply isn't there.
  728. # [18:49] <dbaron> object:empty only matches some of the time
  729. # [18:49] <TabAtkins> fantasai: Let's just say that you can't do anything with it, not say that it isn't there.
  730. # [18:50] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  731. # [18:50] <TabAtkins> dbaron: You're saying the object:empty should match *all* of the time.
  732. # [18:50] <TabAtkins> Bert: Yeah, it should say that.
  733. # [18:50] <TabAtkins> glazou: When doesn't object:empty work?
  734. # [18:50] <TabAtkins> dbaron: When <object> has fallback, frex.
  735. # [18:51] <TabAtkins> glazou: Object has children in the DOM.
  736. # [18:51] <TabAtkins> Bert: If it's replaced it has no children.
  737. # [18:51] <TabAtkins> glazou: It does.
  738. # [18:51] <TabAtkins> Bert: Does not.
  739. # [18:51] <bz> is too, is not
  740. # [18:51] <TabAtkins> Chris: We're going in circles. Chairs?
  741. # [18:52] * Joins: dbaron (dbaron@63.245.220.11)
  742. # [18:52] * ChrisL your MOM has no children!!!
  743. # [18:52] <TabAtkins> tantek: How do you assign different styles to an object based on whether the object loads or not.
  744. # [18:52] <TabAtkins> tantek: This decision is made before CSS happens.
  745. # [18:52] <TabAtkins> tantek: How do you decide?
  746. # [18:52] <TabAtkins> TabAtkins: :incomplete?
  747. # [18:52] <glazou> ChrisL: rofl
  748. # [18:53] <TabAtkins> tantek: That's an old thing, right?
  749. # [18:53] <TabAtkins> fantasai: Nah, it's relatively recent. But it's out of scope of the conversation.
  750. # [18:53] <TabAtkins> Bert: Let's make it clear that you don't look at the DOM content of replaced elements.
  751. # [18:53] <TabAtkins> fantasai: Yes.
  752. # [18:53] <TabAtkins> Bert: We just need to exclude children from being looked at for this.
  753. # [18:53] <TabAtkins> Bert: So how do we phrase this?
  754. # [18:54] <fantasai> "The children of replaced elements are not considered in the CSS rendering model."
  755. # [18:54] <fantasai> for 3.1
  756. # [18:55] <TabAtkins> Bert: But that sounds like a contradiction. Replaced elements don't have children.
  757. # [18:55] <TabAtkins> glazou: Nah, everyone agrees that it does.
  758. # [18:55] <TabAtkins> dbaron: So if a <select> is a replaced element, browsers can't render <option>s.
  759. # [18:56] <TabAtkins> fantasai: They're not unrenderable, just CSS won't see them. Whatever draws forms will.
  760. # [18:56] <TabAtkins> Bert: In CSS1 form elements were defined as replaced, but we've gradually been removing that.
  761. # [18:56] <TabAtkins> tantek: And in CSS3, <select> is appearance:popup-menu.
  762. # [18:57] <tantek> http://w3.org/TR/css3-ui
  763. # [18:57] <TabAtkins> glazou: Bert, do you have a counterproposal, since you're blocking this sentence?
  764. # [18:57] <TabAtkins> Bert: Can we say that the "content", not "children"?
  765. # [18:57] <TabAtkins> fantasai: Okay.
  766. # [18:57] <Zakim> -SteveZ
  767. # [18:58] <fantasai> "The content of replaced elements is not considered in the CSS rendering model."
  768. # [18:58] <TabAtkins> Bert: That's fine.
  769. # [18:59] <TabAtkins> Chris: So what about <foo-img src=bar><tooltip>baz</tooltip></foo-img>. Does this mean we can't ever style the tooltip?
  770. # [18:59] <TabAtkins> ChrisL: I think the real answer is we *can* target and style the tooltip. Maybe it has display:tool-tip or whatever, but it should be there.
  771. # [19:00] <TabAtkins> Bert: How do you display that image? Does it replace the contents?
  772. # [19:00] <TabAtkins> ChrisL: Ys.
  773. # [19:00] * sylvaing expects an :nth-illegitimate-child() proposal by end of day
  774. # [19:00] <TabAtkins> Bert: Defined by the document format?
  775. # [19:00] <TabAtkins> ChrisL: Yes.
  776. # [19:00] <annevk> XBL!
  777. # [19:00] <TabAtkins> Bert: Then it has no children.
  778. # [19:00] <TabAtkins> ChrisL: But we may want to do so.
  779. # [19:00] <dbaron> So which case of run-in behavior are we trying to affect, anyway?
  780. # [19:01] <TabAtkins> Bert: Then we'll need to change CSS to do so.
  781. # [19:01] <TabAtkins> Bert: When we use CSS3 Generated Content, we'll be able to do so.
  782. # [19:01] <dbaron> The definition for whether things run in seems fine for replaced elements already.
  783. # [19:01] <TabAtkins> Bert: If th document language says how to display it, we can no longer say anything about it.
  784. # [19:02] <TabAtkins> ChrisL: I was trying to get away from <object>, because the children there are clearly alternates. I wanted an example where the children are used alongside the content.
  785. # [19:02] <TabAtkins> glazou: What Chris is saying is that this restricts new language design.
  786. # [19:02] <TabAtkins> fantasai: CSS2.1 model: 1) parse document, 2) I'll let fantasai reminute the list.
  787. # [19:02] <fantasai> http://www.w3.org/TR/CSS21/intro.html#processing-model
  788. # [19:02] <dbaron> Instead, I propose changing:
  789. # [19:03] <dbaron> C has a computed value for 'display' of 'inline' and it has one or
  790. # [19:03] <dbaron> more children that inhibit run-in behavior
  791. # [19:03] <dbaron> to:
  792. # [19:03] <TabAtkins> ChrisL: I'm happy to say "formatting structure" rather than "rendering tree". It's in *that* that replaced elements have no children.
  793. # [19:03] <dbaron> C has a computed value for 'display' of 'inline', is non-replaced, and has one or
  794. # [19:03] <dbaron> more children that inhibit run-in behavior
  795. # [19:03] <TabAtkins> ChrisL: The point is that it's not the source tree, so we don't have to *pretend* that the document-tree has no children.
  796. # [19:03] <dbaron> and changing:
  797. # [19:03] <dbaron> If A has any children
  798. # [19:03] <dbaron> to:
  799. # [19:03] <TabAtkins> Bert: Ok.
  800. # [19:03] <dbaron> If A is non-replaced and has any children
  801. # [19:03] * Quits: tantek (tantek@72.254.103.162) (Client exited)
  802. # [19:04] <TabAtkins> glazou: We were at 3. Accept the proposal with Bert's text?
  803. # [19:04] * Quits: jdaggett (jdaggett@72.254.82.75) (Quit: jdaggett)
  804. # [19:04] * Joins: tantek (tantek@72.254.103.162)
  805. # [19:04] <TabAtkins> RESOLVED Accept Bert's text for issue 3 in the run-in email
  806. # [19:04] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
  807. # [19:05] <TabAtkins> Bert: Next issue. What is the containing block of the run-in and children?
  808. # [19:05] <TabAtkins> Bert: Every box needs a containing-block. If the run-in goes inline, which box is containing it?
  809. # [19:05] <TabAtkins> Bert: 10.1 supposedly defines the containing block for all elements.
  810. # [19:05] <TabAtkins> Bert: In my reading, it does, and the definition there only follows the document tree. It doesn't look at the visual place it appears, just ancestors in the document tree.
  811. # [19:06] <TabAtkins> Bert: So the run-in will have it's normal parent as the containing block, not the sibling that it's flowing into.
  812. # [19:06] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
  813. # [19:06] <TabAtkins> Bert: Do we want that, or do we want the sibling to be the containing block?
  814. # [19:06] <TabAtkins> fantasai: The second one.
  815. # [19:06] * Joins: Lachy (Lachlan@72.254.56.137)
  816. # [19:07] <TabAtkins> fantasai: Frex, width:50% on the run-in should be taking its width from the sibling it's flowing into.
  817. # [19:07] <TabAtkins> sylvain: So it would get its color, frex, from its parent, but other things would come from the eparent.
  818. # [19:07] <TabAtkins> fantasai: Yeah, we do something similar with abspos. The containing block may be an ancestor far up, even though it still inherits from its parent.
  819. # [19:08] <fantasai> s/run-in/run-in's inline-block child/
  820. # [19:08] <TabAtkins> Boris: To be clear, I think we want to say this...
  821. # [19:08] <TabAtkins> Boris: The other question is if you have floating children of the run-in, then what happens with those? Which block is the containing block for those floats?
  822. # [19:08] <TabAtkins> Boris: And with abspos children of the run-in.
  823. # [19:09] <TabAtkins> fantasai: For floats it should be the same - the containing sibling.
  824. # [19:09] <TabAtkins> fantasai: For abspos children, I have no opinion. I'm happy to go with whatever's easiest.
  825. # [19:09] <TabAtkins> TabAtkins: For consistency, I'd prefer abspos to do the same thing.
  826. # [19:10] <TabAtkins> Bert: It seems most are in favor of taking the sibling as the containing element for run-in and all children?
  827. # [19:10] <bz> yay! ;)
  828. # [19:10] <TabAtkins> RESOLVED The sibling that the run-in runs into is the containing block for it and all children.
  829. # [19:10] <TabAtkins> Bert: Next issue. Boris believes 10.1 is ambiguous. It says "ancestor box".
  830. # [19:11] <TabAtkins> Bert: In my reading it's just the ancestor. But Boris thinks it might refer to the formatting structure, and so it may refer to thee ancestor in the formatting structure.
  831. # [19:11] * Joins: jdaggett (jdaggett@72.254.82.75)
  832. # [19:12] <TabAtkins> Bert: So should we go through the spec and look for "ancestor box", "parent box", etc and replace it with something umabiguous, so we're clear if it refers to the content or the visual structure or containing block.
  833. # [19:12] <TabAtkins> Bert: I don't personally think it's necessary. I read "ancestor box" as referring to the document structure.
  834. # [19:12] <TabAtkins> Bert: But if others think it's ambiguous, we have to go through the text and replace those occurences. Thoughts?
  835. # [19:13] <TabAtkins> fantasai, sylvain: I always interpreted that as being formatting structure.
  836. # [19:13] <TabAtkins> plinss: Especially since it says "box", not "element".
  837. # [19:13] <TabAtkins> ChrisL: Yeah, it's ambiguous, especiall frex for abspos.
  838. # [19:13] * tantek changes topic to 'display:run-in'
  839. # [19:13] <TabAtkins> dbaron: Why is "ancestor" clearly one tree and not the other?
  840. # [19:14] <TabAtkins> dbaron: I think it's clear that it's in the formatting tree.
  841. # [19:14] <TabAtkins> ChrisL: If you have an abspos element, is the ancestor the whole document?
  842. # [19:14] <TabAtkins> Bert: That's the ICB, not an ancestor.
  843. # [19:14] <TabAtkins> plinss: The fact that we're having the conversation means it's ambiguous.
  844. # [19:14] <TabAtkins> Bert: You can say that about any line in the spec.
  845. # [19:15] <TabAtkins> Bert: It's a bit of work to go through the spec.
  846. # [19:15] <TabAtkins> ChrisL: I'm okay with saying it's unambiguous if someone explains it clearly.
  847. # [19:15] <TabAtkins> plinss: If it's supposed to be the box of the ancestor, say "box of the ancestor".
  848. # [19:15] <TabAtkins> fantasai: In run-in, we dont' want to look up the element tree. We want to look up the formatting tree.
  849. # [19:16] <TabAtkins> fantasai: Frex, with several runs of nested spans around an abspos, is the run-in's containing block (sibling) relpos? That's a formatting ancestor, not a document ancestor.
  850. # [19:16] <TabAtkins> fantasai: We don't want to make this decision unless we're careful about run-ins?
  851. # [19:17] <TabAtkins> Bert: Are you saying that if we keep it how it is we don't need to make a change? I think you're going opposite from me.e
  852. # [19:17] <TabAtkins> Bert: I think we'll have to rewrite 10.1 anyway, at least an extra clause.
  853. # [19:17] <TabAtkins> fantasai: I'm saying for children of the run-in, frex when they're looking for fixpos/relpos ancestors, they're going up the formatting tree and will find the run-in's containing block.
  854. # [19:18] <TabAtkins> fantasai: So I guess file this as an issue and deal with it later? Somebody has to go through and look through the whole spec and figure out what we're doing all over the place.
  855. # [19:18] <TabAtkins> Bert: I think deciding that is progress already. At least we know it has to be done.
  856. # [19:19] <TabAtkins> RESOLVED File an issue to go through the spec for this. Either Elika or Bert will take care of this. At least clarify/define the "ancestor box".
  857. # [19:20] <TabAtkins> Bert: Now the famous ::first-line issue.
  858. # [19:20] <TabAtkins> Bert: Consider a run-in displayed inline in the sibling. The sibling has a ::first-line pseudo. Where does the first line get its properties from?
  859. # [19:20] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-142
  860. # [19:20] <TabAtkins> Bert: Imagine the run-in is short, so half of the first line comes from th run-in, and half comes from the content.
  861. # [19:21] <TabAtkins> Bert: There are 3 or 4 reasonable ways of creating that inheritance tree.
  862. # [19:22] <TabAtkins> Bert: Tab's proposal was to avoid the whole issue and just create ::run-in. Then ::first-line doesn't apply to run-in, just the content from the paragraph.
  863. # [19:22] <TabAtkins> Bert: But we don't have that pseudo in CSS2, so it's quite a change.
  864. # [19:22] <TabAtkins> fantasai: I proposae following the document tree.
  865. # [19:22] <TabAtkins> plinss: I don't know if that makes stylistic sense.
  866. # [19:23] <TabAtkins> plinss: I don't think a run-in should pick up any style from the first line of the paragraph that it's running in.
  867. # [19:23] <TabAtkins> Bert: What about background?
  868. # [19:23] <TabAtkins> fantasai: Run-in should be included in ::first-line, but shouldn't inherit from ::first-line.
  869. # [19:27] <Bert> [Tab explains the issue ::run-in is trying to solve: being able to style the element differently when it run in than when it is block.]
  870. # [19:27] * Quits: dsinger (dsinger@17.197.23.228) (Quit: dsinger)
  871. # [19:27] * Joins: dsinger (dsinger@17.197.23.228)
  872. # [19:27] * Quits: dsinger (dsinger@17.197.23.228) (Quit: dsinger)
  873. # [19:27] <Bert> [Tantek says you typically use run-in when you're pretty sure the element *will* run in.]
  874. # [19:28] <fantasai> [tantek and fantasai point out that you can't have a pseudo-element match depending on display type]
  875. # [19:28] <fantasai> s/element/class/
  876. # [19:29] <fantasai> Peter: but you could have a pseudo-element
  877. # [19:29] <fantasai> Peter: that selects its contents
  878. # [19:30] <fantasai> RESOLVED: run-ins inherit from their document tree parent
  879. # [19:30] <fantasai> dbaron: what about the ancestor's ::first-line?
  880. # [19:32] <fantasai> s/ancestor/common ancestor/
  881. # [19:32] <fantasai> dbaron: I don't think we want to ignore the paragraph's ::first-line but honor the ancestor's
  882. # [19:32] <fantasai> fantasai: Yeah, we shoudl either ignore all ::first-lines for run-in inheritance, or honor all of them
  883. # [19:33] <fantasai> bz, can you type in your example pls? :)
  884. # [19:33] <bz> <div style="color: blue">
  885. # [19:33] <bz> <div style="display: run-in">Text</div>
  886. # [19:33] <bz> <div style="color: yellow"></div>
  887. # [19:33] <bz> </div>
  888. # [19:33] <fantasai> bz: If there aer no ::first-lien styles, then we've just decided the run-in is color: blue
  889. # [19:34] <fantasai> bz: If there is a ::first-line style on the second <div>, what happens?
  890. # [19:34] <fantasai> bz: If that ::first-line style also sets color: orange, what happens?
  891. # [19:34] <fantasai> (orcolor: yellow; )
  892. # [19:36] <TabAtkins> plinss: I think the run-in should inherit from its parent always. The remaining content of the sibling on the first-line coms from the sibling's ::first-line, the run-in doesn't care.
  893. # [19:36] <TabAtkins> fantasai: If you have ::first-line{color:green;} on the ancestor, should it affect the run-in?
  894. # [19:36] <TabAtkins> plinss: yes.
  895. # [19:36] <TabAtkins> plinss: You're in effect getting two separate first-line boxes.
  896. # [19:37] <TabAtkins> TabAtkins: Is this actually any more difficult than current ::first-line behavior?
  897. # [19:38] <bz> of course
  898. # [19:38] <TabAtkins> dbaron: I don't think we implement the full ::first-line behavior anyway, so we can't really say.
  899. # [19:38] <bz> first-line + inheritance is just a bad scene, no matter what
  900. # [19:38] <TabAtkins> fantasai: counterproposal is to ignore ::first-line for run-ins always.
  901. # [19:38] * annevk still likes the idea of dropping run-in :)
  902. # [19:40] <TabAtkins> TabAtkins: So the sibling's ::first-line never affects the run-in. The difference is whether the ancestor's ::first-line applies to the run-in or not.
  903. # [19:40] * Quits: markusm (mmielke@72.254.93.74) (Ping timeout)
  904. # [19:40] <TabAtkins> dbaron: I think it's more consistent to say the run-in always ignores ::first-line.
  905. # [19:42] <Bert> [Fantasai copies bz's mark-up to the flipover and starts drawing...]
  906. # [19:43] <bz> annevk, can we drop first-line too? ;)
  907. # [19:44] <annevk> I wouldn't mind :)
  908. # [19:44] <TabAtkins> fantasai: Does ::first-line have values for properties that aren't epxlicitly set on it?
  909. # [19:45] <TabAtkins> alex: I've ejust tried this in several browsers.
  910. # [19:46] <alexmog> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0Adiv%3Afirst-line%20%7Bcolor%3Agreen%7D%0D%0Ap%3Afirst-line%20%7Btext-decoration%3Aunderline%7D%0D%0Ab%20%7B%20display%3Arun-in%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%3E%0D%0A%3Cb%3Erun-in%3C%2Fb%3E%0D%0A%3Cp%3E%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20pa
  911. # [19:46] <TabAtkins> alex: In IE8, the run-in does inherit from parent first-line, but not sibling first-line
  912. # [19:46] <TabAtkins> alex: FF and Opera it doesn't make it a run-in.
  913. # [19:46] * annevk ... the way it works with inheritance and how it may have to depend on the property is just too hairy
  914. # [19:47] <TabAtkins> alex: IN Safari, the ancestor style is ignored, and the run-in gets the sibling's ::first-line.
  915. # [19:47] <TabAtkins> dbaron: Just punt it as undefined and move on?
  916. # [19:47] <TabAtkins> fantasai: 2 things we can leave undefined.
  917. # [19:48] <TabAtkins> fantasai: 1 is inheritance for run-ins in general. 2 is inheritance for run-ins just in ::first-line.
  918. # [19:49] <TabAtkins> RESOLVED Run-ins inherit from their document parent, not their sibling. It is explicitly undefined what happens with parent/sibling ::first-lines and run-ins.
  919. # [19:49] <bz> mmm yummy undefined
  920. # [19:49] <TabAtkins> RESOLVED ADDENDUM: Undefined for CSS2.1, maybe for CSS3 (Box Module may be able to take care of it.)
  921. # [19:50] * bz looks forward to implementing "the simplest thing that doesn't crash"
  922. # [19:50] <fantasai> :)
  923. # [19:50] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
  924. # [19:50] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
  925. # [19:50] * Quits: kohei (kohei@72.254.59.20) (Quit: Computer goes to sleep!)
  926. # [19:50] * bz has no outstanding run-in issues
  927. # [19:50] <fantasai> yay!
  928. # [19:50] <bz> well, other than the fact that I have to write the code... ;)
  929. # [19:50] * Joins: bradk (bradk@72.254.101.220)
  930. # [19:50] * Quits: plinss (plinss@72.254.59.50) (Quit: plinss)
  931. # [19:51] <tantek> http://wiki.csswg.org/planning/tpac-2009
  932. # [19:51] * fantasai thinks her next contract should be "deal with outstanding css2.1 issues"
  933. # [19:51] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
  934. # [19:52] * Quits: TabAtkins (chatzilla@72.254.99.227) (Ping timeout)
  935. # [19:53] * Quits: Kai (chatzilla@72.254.88.78) (Ping timeout)
  936. # [19:55] * bz is going to sign off, since we seem to be done with run-in
  937. # [19:57] <ChrisL> bz, yes we are on break now
  938. # [19:58] * Joins: markusm (mmielke@72.254.124.123)
  939. # [19:58] <dbaron> bz, yep
  940. # [19:58] <dbaron> Zakim, who is on the phone?
  941. # [19:58] <Zakim> On the phone I see Salon_9, bzbarsky
  942. # [19:58] * Quits: mjs (mjs@72.254.84.91) (Quit: mjs)
  943. # [19:58] <dbaron> Zakim, disconnect Salon_9
  944. # [19:58] <Zakim> Salon_9 is being disconnected
  945. # [19:58] <Zakim> -Salon_9
  946. # [19:59] * bz hangs up
  947. # [19:59] <bz> time for another meeting in 2 mins, yay
  948. # [20:02] * Joins: kohei (kohei@72.254.59.20)
  949. # [20:05] * Joins: glazou (glazou@72.254.63.160)
  950. # [20:06] * Joins: mjs (mjs@72.254.84.91)
  951. # [20:10] * Joins: bradk (bradk@72.254.101.220)
  952. # [20:15] * Joins: dsinger (dsinger@72.254.82.131)
  953. # [20:16] * Joins: plinss (plinss@72.254.59.50)
  954. # [20:17] <dbaron> Zakim, who is on the phone?
  955. # [20:17] <Zakim> On the phone I see bzbarsky
  956. # [20:17] <dbaron> Zakim, disconnect bzbarsky
  957. # [20:17] <Zakim> bzbarsky is being disconnected
  958. # [20:17] <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
  959. # [20:17] <Zakim> Attendees were SteveZ, Salon_9, +1.617.487.aaaa, bzbarsky
  960. # [20:17] <dbaron> Zakim, remind us in 7 hours to go home
  961. # [20:17] <Zakim> ok, dbaron
  962. # [20:17] <dbaron> RRSAgent, pointer?
  963. # [20:17] <RRSAgent> See http://www.w3.org/2009/11/03-CSS-irc#T19-17-50
  964. # [20:18] <dbaron> RRSAgent, make logs public
  965. # [20:18] <RRSAgent> I have made the request, dbaron
  966. # [20:18] <dbaron> RRSAgent, this meeting spans midnight
  967. # [20:18] <RRSAgent> ok, dbaron; I will not start a new log at midnight
  968. # [20:18] * Joins: TabAtkins (chatzilla@72.254.99.227)
  969. # [20:21] <Bert> Scribe: Bert
  970. # [20:21] <Bert_lap> Scribe: Bert_lap
  971. # [20:22] <Bert_lap> [Discussion about which issues need discussion]
  972. # [20:24] * tantek changes topic to 'selectors'
  973. # [20:24] <Bert_lap> Topic: Selectors
  974. # [20:24] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2009Nov/0022.html
  975. # [20:24] <TabAtkins> Default attribute thread
  976. # [20:25] <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
  977. # [20:25] <Bert_lap> http://www.w3.org/mid/4AEFE294.8070104@inkedblade.net
  978. # [20:25] <Bert_lap> Fantasai: Default attributes, e.g., colspan is default 1. Can you match against them?
  979. # [20:26] <Bert_lap> ... Spec leaves it open.
  980. # [20:26] <Bert_lap> ... Should we allow both behaviors?
  981. # [20:26] <Bert_lap> ... Most impl. don't match default attrs.
  982. # [20:27] <Bert_lap> Tantek: Impl. shouldn't be required to read DTD, so they don't necessarily know the default.
  983. # [20:27] <Bert_lap> ... That's the background behind the current spec.
  984. # [20:27] <Bert_lap> Glazou: You *can* check if an attribute is absent.
  985. # [20:28] <Bert_lap> DavidB: But need to select all unknowns, can get a long selector...
  986. # [20:28] <Bert_lap> Fantasai: So agreed that spec allows both matching and not matching?
  987. # [20:28] * Parts: glazou (glazou@72.254.63.160)
  988. # [20:28] * Joins: glazou (glazou@72.254.63.160)
  989. # [20:28] * Parts: glazou (glazou@72.254.63.160)
  990. # [20:28] <Bert_lap> Arron: Are you goin gto send proposed text?
  991. # [20:28] <Bert_lap> Fantasai: Yes, I will.
  992. # [20:29] * Joins: glazou (glazou@72.254.63.160)
  993. # [20:29] <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
  994. # [20:29] <Bert_lap> Fantasai: Next is impl. reports. Looks like Opera fails several. Do we have other impls.?
  995. # [20:29] <Bert_lap> ChrisL: Webkit was not tested yet.
  996. # [20:29] <Bert_lap> DaivdB: Webkit seems pretty good.
  997. # [20:29] <Bert_lap> ChrisL/DavidB: 15C may not matter
  998. # [20:30] <Bert_lap> [DavidB trying out things in webkit.]
  999. # [20:30] <dbaron> we don't have 2 impls for 174a, 174b, and d3
  1000. # [20:30] <dbaron> also 0 impls for 15c, but I don't think that matters
  1001. # [20:30] <dbaron> Mozilla is the only impl passing 174a, 174b, and d3 that I know of
  1002. # [20:31] <Bert_lap> Glazou: I am trying to get impl. report from zoomorama(sp?}
  1003. # [20:31] <Bert_lap> Fantasai: Should we also look at Prince?
  1004. # [20:32] <Bert_lap> Glazou: Yes, Prince is interesting.
  1005. # [20:32] <Bert_lap> ... May also look at Andrew Fedoniouk's HTMLayout.
  1006. # [20:32] <Bert_lap> [Several discussions at the same time]
  1007. # [20:33] <Bert_lap> Fantasai: I'll run tests on Prince.
  1008. # [20:33] <Bert_lap> ChrisL: I can try Webkit.
  1009. # [20:34] <Bert_lap> [Discussion about most efficient way to quickly press keys.]
  1010. # [20:34] <Bert_lap> Fantasai: We need another impl. for some tests. Webkit not enough.
  1011. # [20:34] * Joins: Kai (chatzilla@72.254.88.78)
  1012. # [20:34] <Bert_lap> ChrisL: I talked to Opera about their failures. Maybe they can do something about it.
  1013. # [20:35] <Bert_lap> Beth: I tested the failures and they still fail in latest build.
  1014. # [20:35] <Bert_lap> Topic: Color and gamma correction
  1015. # [20:35] * tantek changes topic to 'CSS3 Color and gamma correction'
  1016. # [20:35] <Bert_lap> DavidB: Gamma may not be the right term.
  1017. # [20:36] <Bert_lap> ... Colors are in sRGB.
  1018. # [20:36] <Bert_lap> ... But nobody really impleents it.
  1019. # [20:36] <dsinger> see 3.1.1 in http://www.w3.org/TR/css3-color/
  1020. # [20:36] * Quits: markusm (mmielke@72.254.124.123) (Ping timeout)
  1021. # [20:36] <Bert_lap> ... Do we relax the spec?
  1022. # [20:36] <Bert_lap> ChrisL: On many platforms sRGB is right by default.
  1023. # [20:37] <Bert_lap> Beth: Not on the mac.
  1024. # [20:37] <Bert_lap> DavidB: 2nd question is do we give authors a way to opt in?
  1025. # [20:37] <Bert_lap> ... Plugins are a known problem.
  1026. # [20:38] <Bert_lap> ... The right thing would be to treat CSS colors as well as untagged images to be in sRGB.
  1027. # [20:38] <Bert_lap> ... I don't know what Flash defines.
  1028. # [20:38] <Bert_lap> ChrisL: Nothing.
  1029. # [20:38] <Bert_lap> DavidB: Flash guys may be interested in defining something.
  1030. # [20:38] <Bert_lap> ... But we may also want to give authors a choice.
  1031. # [20:38] <ChrisL> s/Nothing/No color management, currently/
  1032. # [20:39] <fantasai> Prince passes 174a and 174b and 15c
  1033. # [20:39] <fantasai> fails d3 (since it's dynamic)
  1034. # [20:39] <Bert_lap> DavidS/Beth: A vague idea we had:
  1035. # [20:39] <Bert_lap> ... An ability to turn it on with a property.
  1036. # [20:39] <Bert_lap> ... Not crazy about the idea, but needed it for a client.
  1037. # [20:39] <Bert_lap> Tantek: So you needed it per element?
  1038. # [20:40] <fantasai> Konqueror passes d3
  1039. # [20:40] <Bert_lap> ChrisL: A need per element maybe because of video, of which there is more and more,as well as tagged images.
  1040. # [20:41] <Bert_lap> DavidS: And if you it on body, it applies to everything?
  1041. # [20:41] <Bert_lap> ... Example: a background behind a flash, and only that, should be uncorrected.
  1042. # [20:42] <Bert_lap> Beth: We don't want to override color profiles when explicit in an image.
  1043. # [20:42] <ChrisL> Need to override *tagged* immages is minimal
  1044. # [20:42] <Bert_lap> DaviDS: There are also many incorrectly tagged images.
  1045. # [20:42] <Bert_lap> DavidB: Gecko now corrects tagged images.
  1046. # [20:42] <Bert_lap> Tantek: DavidS, what do you want, more precisely?
  1047. # [20:43] <ChrisL> Not clear that there are many incorrectly tagged images
  1048. # [20:43] <Bert_lap> DavidS: You can say that the color space of this element is such and such, or is 'none'.
  1049. # [20:43] <Bert_lap> Tantek: And if the image is tagged, it will override?
  1050. # [20:43] <Bert_lap> ... So you described the 'auto' value that we had in a previous draft.
  1051. # [20:44] <Bert_lap> DavidB: But we also need our current behavior.
  1052. # [20:44] <Bert_lap> ... Which is not interoperable.
  1053. # [20:44] <Bert_lap> DavidS: But it is consistent in a single browser.
  1054. # [20:46] * dsinger does anyone have a pointer to the previous version that had this feature?
  1055. # [20:46] <Bert_lap> Beth: We want 'auto' to match whatever browser decides to do. Which may even change over time...
  1056. # [20:46] <Bert_lap> Tantek: If you use 'auto', you cannot count on any specific behavior.
  1057. # [20:47] <Bert_lap> DavidB: You can count on it being consistent with a single browser.
  1058. # [20:47] <Bert_lap> DavidS: We may want to force platform-specific colors.
  1059. # [20:47] <Bert_lap> DavidB: Not sure we want that.
  1060. # [20:47] * Joins: myakura (myakura@72.254.84.172)
  1061. # [20:48] <Bert_lap> Tantek: Would there be no standardized value in the UA style sheet?
  1062. # [20:48] * glazou just noticed tantek has two macs in front of him, the good ol'days are back :-)
  1063. # [20:48] <Bert_lap> ChrisL: Difference between platform color spce and platform specific behavior, which may be color managed.
  1064. # [20:49] <Bert_lap> DavidB: Mozilla changed to be compatible with Webkit and go a lot of negative feedback.
  1065. # [20:49] <Bert_lap> Tantek: 'Default' could be another keyword.
  1066. # [20:50] <Bert_lap> ... It means you cannot count on cross-platform conistency.
  1067. # [20:50] <Bert_lap> Beth: Sounds good.
  1068. # [20:50] <Bert_lap> ... It means: what UA would do if the property weren't specified at all.
  1069. # [20:50] <Bert_lap> ... That can change over time.
  1070. # [20:50] <Bert_lap> ... E.g., at the moment we don't do color managament at att.
  1071. # [20:50] <Bert_lap> ... But we may do so in the future.
  1072. # [20:51] <Bert_lap> s/att/all/
  1073. # [20:51] <Bert_lap> Tantek: So 'auto' means treat as sRGB, except for images that are tagged.
  1074. # [20:51] <Bert_lap> ... And 'sRGB' means override the image tags.
  1075. # [20:52] <ChrisL> Pointer to the relevant part of the old spec http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color
  1076. # [20:52] <Bert_lap> DavidS: So we have 'historical' and 'correct' (as keywords?).
  1077. # [20:53] <ChrisL> we don't want to encourage overiding of images, so the old proposal is not very good. Tantek's current wording is better
  1078. # [20:53] <Bert_lap> Tantek: Two values for reintroduced color-profile: default (as per Beth) and srgb, defined the way 'auto' used to be defined.
  1079. # [20:53] <ChrisL> "All colors are presumed to be defined in the sRGB color space unless a more precise embedded profile is specified within content data. For images that do have a profile built into their data, that profile is used. For images that do not have a profile, the sRGB profile is used so that the colors in these images can be kept "in synch" with the colors specified in CSS and HTML."
  1080. # [20:53] <Bert_lap> Tantek: a'uto' exactly as that quoted text.
  1081. # [20:54] <Bert_lap> Tantek: And just two values seems enough.
  1082. # [20:54] <Bert_lap> Brad: Wrong tags in images?
  1083. # [20:54] <dsinger> note that the correct application of color spaces in plugins is the responsibility of the plugin and not the browser
  1084. # [20:55] <ChrisL> Brad is concerned about images saves with incorrect profiles, which was not noticed because browsers only started dealing with tagged images fairly recently
  1085. # [20:55] <Bert_lap> DavidB: That will never cause probelsm on some machine but not others. You will see the problem immediately.
  1086. # [20:55] <dsinger> note that the color spaces used in video are different, and the color correction of video is handled by the video subsystem
  1087. # [20:55] <Bert_lap> Peter: Didn't you, DavidB, say there were tools that generated wrongly tagged images?
  1088. # [20:55] <Bert_lap> DavidB: I think I said there were many untagged images.
  1089. # [20:56] <Bert_lap> chrisL: Most common tag is Adobe RGB.
  1090. # [20:56] <Bert_lap> DavidS: I want authors to tag images correctly.Not provide a work-around.
  1091. # [20:56] <ChrisL> most common after untagged, or tagged as sRGB, is AdobeRGB
  1092. # [20:57] <Bert_lap> [Discussion of DavidS text above]
  1093. # [20:57] <Bert_lap> ChrisL: Untagged video is almost sRGB in practice.
  1094. # [20:58] <Bert_lap> Tantek: Can DavidS find out if it is OK to treat unagged video as sRGB?
  1095. # [20:58] <ChrisL> its the same primaries (CCIR 709 primaries) the transfer curve is slightly different
  1096. # [20:58] <tantek> re-introduce 'color-profile' property, two values. 'default' per Beth's definition, and 'sRGB' per definition of 'auto' from http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color
  1097. # [20:58] <tantek> specifically
  1098. # [20:59] <tantek> 'sRGB'
  1099. # [20:59] <Bert_lap> ACTION on DavidS check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
  1100. # [20:59] * trackbot noticed an ACTION. Trying to create it.
  1101. # [20:59] <trackbot> Sorry, couldn't find user - on
  1102. # [20:59] <tantek> "All colors are presumed to be defined in the sRGB color space unless a more precise embedded profile is specified within content data. For images that do have a profile built into their data, that profile is used. For images that do not have a profile, the sRGB profile is used so that the colors in these images can be kept "in synch" with the colors specified in CSS and HTML."
  1103. # [20:59] <Bert_lap> ACTION on Singer check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
  1104. # [20:59] * trackbot noticed an ACTION. Trying to create it.
  1105. # [20:59] <trackbot> Sorry, couldn't find user - on
  1106. # [21:00] <ChrisL> ACTION: DavidS to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
  1107. # [21:00] * trackbot noticed an ACTION. Trying to create it.
  1108. # [21:00] <trackbot> Sorry, couldn't find user - DavidS
  1109. # [21:00] * RRSAgent records action 1
  1110. # [21:00] <ChrisL> trackbot, status
  1111. # [21:00] * trackbot knows about the following 39 users: Alex, Chris, Timothy, Masayuki, Elika, Peter, Anne, Daniel, Yasuhiro, Steve, Cesar, Shinyu, Beth, Svante, Saloni, Jeff, Tokushige, David, Robert, Arron, Giorgi, Øyvind, David, Ian, John, Bert, Sylvain, Tab, Molly, Markus, Brad, Chris, David, Emily, Håkon Wium, Ben, Dean, Simon, Tona
  1112. # [21:00] <ChrisL> ACTION: Dsinger to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
  1113. # [21:00] * trackbot noticed an ACTION. Trying to create it.
  1114. # [21:00] <trackbot> Sorry, couldn't find user - Dsinger
  1115. # [21:00] * RRSAgent records action 2
  1116. # [21:00] <ChrisL> ACTION: singer to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
  1117. # [21:00] * trackbot noticed an ACTION. Trying to create it.
  1118. # [21:00] * RRSAgent records action 3
  1119. # [21:00] <trackbot> Created ACTION-194 - Check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [on David Singer - due 2009-11-10].
  1120. # [21:01] * ChrisL finally!
  1121. # [21:02] <Bert_lap> RESOLUTION: re-add a 'color-profile'-like property with the two values 'auto' and 'srgb'
  1122. # [21:02] <smfr> s/auto/default
  1123. # [21:03] <Bert_lap> Beth: We are working on -webkit- prefixed property, May be available by end of week.
  1124. # [21:03] <ChrisL> s/color-profile/color-correction/
  1125. # [21:03] <Bert_lap> ChrisL: Name should not clash with SVG.
  1126. # [21:04] <Bert_lap> Tantek: Other name is fine.
  1127. # [21:04] <Bert_lap> Tantek: call it 'color-correction'
  1128. # [21:05] <Bert_lap> DavidB: Per element is harder than per document.
  1129. # [21:05] <Bert_lap> ChrisL: Won't be changed very often.
  1130. # [21:06] <Bert_lap> [Dicussion about allowing UA to only do per document.]
  1131. # [21:06] <Bert_lap> Tantek: So require per-element?
  1132. # [21:06] <ChrisL> please lets
  1133. # [21:07] <Bert_lap> DavidB: I don't want to have to check it for every color paint.
  1134. # [21:08] <tantek> also proposed: drop section 3.1.1 Gamma correction
  1135. # [21:08] <Bert_lap> Bert: How do you get untagged images to match CSS text?
  1136. # [21:08] <tantek> http://www.w3.org/TR/2008/WD-css3-color-20080721/#gamma
  1137. # [21:09] <Bert_lap> Tantek: You say 'color-correction: srgb'
  1138. # [21:10] <Bert_lap> ChrisL: Do we have sufficient text for this property?
  1139. # [21:10] <Bert_lap> Tantek: Yes, everything is in IRC [above]
  1140. # [21:10] <Bert_lap> DavidB: Another last call for Color?
  1141. # [21:10] <Bert_lap> Tantek: Can we not go to CR with this change?
  1142. # [21:10] <Bert_lap> ChrisL: It's a change, needs a WD.
  1143. # [21:11] <Bert_lap> ... But can go straight to PR after the LC, if we have implementation reports.
  1144. # [21:11] <Bert_lap> .. So, write the test, and make sure UAs pass them, in particular Safari and Firefox.
  1145. # [21:12] <Bert_lap> ... Opera doesn't do color management. I want to try to get them to change.
  1146. # [21:12] <tantek> write tests including vendor prefixed properties for color-correction to allow for those implementations to enable passing the tests.
  1147. # [21:12] <Bert_lap> ... Some of the platforms it runs on are hard to determine.
  1148. # [21:12] <Bert_lap> Arron: We don't do color management either.
  1149. # [21:13] <Bert_lap> DavidB: Is 'srgb' the right keyword?
  1150. # [21:13] <ChrisL> s/needs a WD/needs a Last Call/
  1151. # [21:13] <Bert_lap> Tantek: We can always add 'srgb-force-damnit'...
  1152. # [21:13] <Bert_lap> DaviDB: Also, retract that comment.
  1153. # [21:13] <Bert_lap> Glazou: Next steps?
  1154. # [21:14] <Bert_lap> ChrisL: Some editing, test cases, LC, and PR.
  1155. # [21:14] <dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Color/current/
  1156. # [21:15] <ChrisL> http://www.w3.org/Style/CSS/Test/CSS3/Color/20081014/reports/
  1157. # [21:15] <Bert_lap> RESOLUTION: drop section 3.1.1
  1158. # [21:17] <Bert_lap> Topic: Media Quries in HTML5 video
  1159. # [21:17] <Bert_lap> DavidS: Proposal is to add media query to VIDEO element.
  1160. # [21:17] <Bert_lap> ... And then also add queries for the user's special needs.
  1161. # [21:18] <Bert_lap> Glazou: Seems like a good idea. I never thought it was just the media, always the context.
  1162. # [21:18] <Bert_lap> Tantek: So DavidS want some new terms to be added to the spec.
  1163. # [21:19] <Bert_lap> ... And then a new LC.
  1164. # [21:19] <Bert_lap> Several: Or a second version.
  1165. # [21:19] <Bert_lap> General agreement to not change the current spec, but write a new one.
  1166. # [21:19] <Bert_lap> ChrisL: So just a draft for the new values, not repating the old ones?
  1167. # [21:19] <Bert_lap> Glazou: Yes.
  1168. # [21:20] <Bert_lap> Topic: ftf dates 2010
  1169. # [21:21] <Bert_lap> Old proposal was 22-24 March, but AC is 21-22 March, and in Boston, not in California.
  1170. # [21:22] <Bert_lap> DavidS: 23-25 in Boston is possible, if we have a host...
  1171. # [21:22] <Bert_lap> DavidB: Do we have the list of conflicts still from last time we discussed this?
  1172. # [21:23] <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0179.html
  1173. # [21:24] <Bert_lap> DavidB: SXSW is Mar 12-16, WWW2010 is Apr 26-30
  1174. # [21:24] <Bert_lap> ... How many people *will* be at AC?
  1175. # [21:25] <Bert_lap> DavidS: I will need to be at AC, but need not be in CSS WG.
  1176. # [21:25] <Bert_lap> Fantasai: I'd like to be on east coast around that time.
  1177. # [21:26] <Bert_lap> Bert: Organizing at W3C is likely to be possible.
  1178. # [21:26] <dsinger> http://www.w3.org/Member/Eventscal
  1179. # [21:27] <Bert_lap> ChrisL: Co-locating with WWW2010, in Raleigh, NC?
  1180. # [21:28] <Bert_lap> DavidB: How many will go there?
  1181. # [21:28] <Bert_lap> [Discussion about weather in Boston in March.]
  1182. # [21:29] <Bert_lap> Fantasai: How many would come in Calif? How many would come in Boston?
  1183. # [21:29] <Bert_lap> DavidS: 24-26 March, the rest of the week after AC.
  1184. # [21:29] <Bert_lap> [Looking for Easter dates.]
  1185. # [21:30] <Bert_lap> Glazou: And August?
  1186. # [21:30] <Bert_lap> DavidB: SteveZ had a family event conflict.
  1187. # [21:31] * annevk wonders when CSS will have lunch
  1188. # [21:31] <Bert_lap> [Currently scheduled for Oslo, Aug 18-20]
  1189. # [21:31] * Bert_lap : right now, in theory.
  1190. # [21:31] * annevk cool, me too
  1191. # [21:31] <Bert_lap> DavidS: I also have a conflict for Aug.
  1192. # [21:32] * Quits: Lachy (Lachlan@72.254.56.137) (Quit: This computer has gone to sleep)
  1193. # [21:32] <Bert_lap> Glazou: Let's keep August as it is for now. Now Håkon here anyway.
  1194. # [21:32] * sylvaing .csswg { transition: lunch 1mn; }
  1195. # [21:32] <glazou> s/Now/not
  1196. # [21:32] <Bert_lap> DavidS: 2 questions for W3C: host in March? and is there a TPAC end of the year?
  1197. # [21:32] * Quits: dethbakin (dethbakin@72.254.103.251) (Quit: dethbakin)
  1198. # [21:33] <Bert_lap> LUNCH
  1199. # [21:33] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
  1200. # [21:33] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1201. # [21:33] * Quits: jdaggett (jdaggett@72.254.82.75) (Quit: jdaggett)
  1202. # [21:33] * Quits: smfr (smfr@72.254.92.79) (Quit: smfr)
  1203. # [21:33] * Quits: dsinger (dsinger@72.254.82.131) (Quit: dsinger)
  1204. # [21:33] * Quits: plinss (plinss@72.254.59.50) (Quit: plinss)
  1205. # [21:34] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  1206. # [21:34] * Quits: TabAtkins (chatzilla@72.254.99.227) (Ping timeout)
  1207. # [21:34] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  1208. # [21:35] * Quits: kohei (kohei@72.254.59.20) (Quit: Computer goes to sleep!)
  1209. # [21:35] * Quits: annevk (opera@72.254.82.30) (Quit: annevk)
  1210. # [21:35] * Quits: tantek (tantek@72.254.103.162) (Quit: tantek)
  1211. # [21:35] * Quits: Kai (chatzilla@72.254.88.78) (Ping timeout)
  1212. # [21:35] * Quits: sylvaing (sylvaing@72.254.86.181) (Ping timeout)
  1213. # [21:35] * Quits: Arron (arronei@72.254.101.153) (Ping timeout)
  1214. # [21:35] * Quits: alexmog (alexmog@72.254.94.217) (Ping timeout)
  1215. # [21:37] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
  1216. # [21:38] * Quits: hamaji (hamaji@72.254.92.142) (Ping timeout)
  1217. # [21:38] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  1218. # [21:40] * Quits: Bert_lap (bert@128.30.52.169) (Ping timeout)
  1219. # [21:40] * Quits: mjs (mjs@72.254.84.91) (Quit: mjs)
  1220. # [21:54] * Quits: myakura (myakura@72.254.84.172) (Quit: Leaving...)
  1221. # [22:02] * Joins: jdaggett (jdaggett@72.254.82.75)
  1222. # [22:10] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  1223. # [22:15] * Joins: TabAtkins (chatzilla@72.254.99.227)
  1224. # [22:15] * Joins: Curt` (curt@76.241.65.125)
  1225. # [22:15] * Joins: bradk (bradk@72.254.101.220)
  1226. # [22:15] * Joins: markusm (mmielke@72.254.93.74)
  1227. # [22:20] * Joins: Kai (chatzilla@72.254.88.78)
  1228. # [22:20] * Quits: TabAtkins (chatzilla@72.254.99.227) (Connection reset by peer)
  1229. # [22:21] * Joins: mjs (mjs@72.254.84.91)
  1230. # [22:21] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
  1231. # [22:22] * Joins: bradk (bradk@72.254.101.220)
  1232. # [22:22] * Joins: Arron (arronei@72.254.101.153)
  1233. # [22:23] * Joins: dbaron (dbaron@63.245.220.11)
  1234. # [22:27] * Joins: Lachy (Lachlan@72.254.56.137)
  1235. # [22:29] * Joins: dethbakin (dethbakin@72.254.103.251)
  1236. # [22:30] * Joins: glazou (glazou@72.254.63.160)
  1237. # [22:30] * Joins: hamaji (hamaji@72.254.92.142)
  1238. # [22:31] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
  1239. # [22:32] * Joins: annevk (opera@72.254.82.30)
  1240. # [22:32] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
  1241. # [22:33] * Joins: shepazu (schepers@128.30.52.169)
  1242. # [22:33] * Joins: tantek (tantek@72.254.103.162)
  1243. # [22:34] * Joins: TabAtkins (chatzilla@72.254.99.227)
  1244. # [22:34] * Joins: plinss (plinss@72.254.59.50)
  1245. # [22:35] * Joins: dsinger (dsinger@72.254.82.131)
  1246. # [22:36] * Joins: Bert_lap (bert@128.30.52.169)
  1247. # [22:36] * Joins: alexmog (alexmog@72.254.94.217)
  1248. # [22:37] * Joins: smfr (smfr@72.254.92.79)
  1249. # [22:38] * Joins: glazou (glazou@72.254.63.160)
  1250. # [22:38] * Joins: bradk (bradk@72.254.101.220)
  1251. # [22:38] * Joins: ChrisL (ChrisL@128.30.52.169)
  1252. # [22:39] * Joins: kohei (kohei@72.254.59.20)
  1253. # [22:39] <dsinger> followed by a break for non-persistent cookies
  1254. # [22:39] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
  1255. # [22:40] * Joins: ChrisL (ChrisL@128.30.52.169)
  1256. # [22:40] <ChrisL> Scribe: Chris
  1257. # [22:40] <ChrisL> ScribeNick: ChrisL
  1258. # [22:40] <ChrisL> Topic: Test suite status
  1259. # [22:43] <ChrisL> Aaron: What's that staus, who has reviewed their tests
  1260. # [22:43] * tantek changes topic to 'Test suite status'
  1261. # [22:43] <ChrisL> Elika: I'm doing a coverage report
  1262. # [22:43] <ChrisL> AAron: Still targetting 15 January?
  1263. # [22:43] <ChrisL> Elika: yes
  1264. # [22:44] <ChrisL> s/Aaron/Arron/
  1265. # [22:44] * Joins: bradk_ (bradk@72.254.102.156)
  1266. # [22:44] <dbaron> s/AAron/Arron/
  1267. # [22:44] <ChrisL> action: arron to create a template fr CSS 2.1 test suite reports
  1268. # [22:44] * trackbot noticed an ACTION. Trying to create it.
  1269. # [22:44] * RRSAgent records action 4
  1270. # [22:44] <trackbot> Created ACTION-195 - Create a template fr CSS 2.1 test suite reports [on Arron Eicholz - due 2009-11-10].
  1271. # [22:44] <ChrisL> s/Aaron/Arron/
  1272. # [22:44] <glazou> BTW, not sure everyone in the WG got news from Robert Stevahn : http://twitpic.com/o63vs :-)
  1273. # [22:45] <ChrisL> Elika: we have implementations for all selectors tests, counting prince, webkit, opea and firefox
  1274. # [22:45] * Joins: sylvaing (sylvaing@72.254.86.181)
  1275. # [22:45] <ChrisL> ... appart from the 15c subtest which needs multiple id support, already listed as feature at risk
  1276. # [22:46] <ChrisL> glazou: champagne
  1277. # [22:46] * Quits: bradk_ (bradk@72.254.102.156) (Quit: Colloquy for iPhone - http://colloquy.mobi)
  1278. # [22:47] <ChrisL> http://www.cardsunlimited.com/largeimage/Champagne.jpg
  1279. # [22:48] * dbaron thought the resolution was 1400x1050 :-)
  1280. # [22:48] <ChrisL> Resolution: Advance to Proposed Recommendation for the Selectors spe
  1281. # [22:48] <ChrisL> s/spe/spec/
  1282. # [22:50] <ChrisL> Topic: Gradients and Image Sprites
  1283. # [22:50] <ChrisL> Arron: recall this had to but not sure what it is
  1284. # [22:51] <ChrisL> David: Who added it
  1285. # [22:51] <ChrisL> Tab: Not sure what it means either
  1286. # [22:51] <ChrisL> (we are all confused)
  1287. # [22:52] <ChrisL> Tab: Asked Shepazu to help with SVG equivalents of the gradient examples
  1288. # [22:52] <ChrisL> ... for sprites, its choosing between options
  1289. # [22:52] <ChrisL> Elika: No, i just liked to the various proposals
  1290. # [22:52] <ChrisL> David: We implemented moz-image-rect
  1291. # [22:53] <ChrisL> Elika: the URI based syntax has no fallback. Could addit by putting it im the image not in the URI
  1292. # [22:53] <ChrisL> Elika: no need to a separate functional notation.
  1293. # [22:53] <dbaron> s/moz-image-rect/-moz-image-rect()/
  1294. # [22:53] <ChrisL> ... if linked to image functional notation and require both to be iplemented
  1295. # [22:54] <ChrisL> ... waiting for media fragments wg to publish a spec
  1296. # [22:54] <ChrisL> Elika: Image sprites should make it more efficient that specifying explicit coods in the stylesheet
  1297. # [22:54] <ChrisL> ... not so much to discuss therefore
  1298. # [22:55] * Joins: szilles (chatzilla@72.254.83.13)
  1299. # [22:55] <ChrisL> Simon: I have some feedback, will send on list
  1300. # [22:55] <ChrisL> ACTION: Simon to send gradients feedback to www-style
  1301. # [22:55] * trackbot noticed an ACTION. Trying to create it.
  1302. # [22:55] * RRSAgent records action 5
  1303. # [22:55] <trackbot> Created ACTION-196 - Send gradients feedback to www-style [on Simon Fraser - due 2009-11-10].
  1304. # [22:56] <bradk> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html
  1305. # [22:56] <ChrisL> Topic: Drop shadows
  1306. # [22:56] <ChrisL> (brad demonstrates)
  1307. # [22:59] <ChrisL> brad: we want something that casts a shadow under the element, casts from background and border
  1308. # [23:00] <ChrisL> ... transparecy affects the color of the shadow where it overlaps. based on alpha channel
  1309. # [23:00] <ChrisL> (brad fiddles with the drop shadow dialog in photoshop)
  1310. # [23:01] <ChrisL> Brad: shadow has translucency
  1311. # [23:02] <ChrisL> ... inner version of a shadow
  1312. # [23:03] <ChrisL> Chris: Please define how you are using the term inner
  1313. # [23:03] <fantasai> CSS2.1 coverage report (thrown rather haphazardly together, somewhat incomplete): http://lists.w3.org/Archives/Public/www-archive/2009Nov/att-0002/index.xht
  1314. # [23:03] <ChrisL> Brad: the shape is cut out of the background and the shadow is on that
  1315. # [23:04] <ChrisL> Chris: the shadow is in fact still on top
  1316. # [23:04] <ChrisL> Brad: yes
  1317. # [23:04] <ChrisL> (we discover the projector really needs color management)
  1318. # [23:06] <ChrisL> Brad: so this is easy with sharp edges. with soft edges people seemed to be confused
  1319. # [23:06] <ChrisL> Chris: its the same copy, remove color, add color, blur, opacity operation
  1320. # [23:08] <ChrisL> Chris: notice you are using blending modes - svg has those
  1321. # [23:11] <ChrisL> (discussion on what exactly is happening in photoshop as people get their heads around it)
  1322. # [23:11] <ChrisL> Simon: Easier to look at the actual proposal
  1323. # [23:14] <ChrisL> Tab: the shadow is cast by a negative of the alpha channel, then clipped to the actual alphs channel
  1324. # [23:16] <ChrisL> John: what is the use case for this?
  1325. # [23:17] <ChrisL> ... the photoshop is not convincing me of the utility
  1326. # [23:17] <ChrisL> Elika: We have box shadows already
  1327. # [23:17] <ChrisL> David: And we implement that, but lets decide if this part is useful before deciding exactly how it works
  1328. # [23:18] <ChrisL> (brad demonstrates inner shadow on text)
  1329. # [23:19] <ChrisL> Simon: With box and text shadow, the shadow does not depend on the transparency of the element
  1330. # [23:19] <ChrisL> ... fully transparent text still casts a shadow, with text-shadow
  1331. # [23:20] <ChrisL> Brad: suppose you want just the border, or the background, or *one* of the backgrounds shaddowed
  1332. # [23:20] <ChrisL> Simon: That seems more useful in the filters discussion
  1333. # [23:21] <bradk> apply-to(border + foreground, background-image + background-color)
  1334. # [23:21] <bradk> apply-to(border + foreground, background-image + background-color)
  1335. # [23:21] <bradk> apply-to(border + foreground, background-image + background-color)
  1336. # [23:21] <ChrisL> Brad: pluses mean the shapes composite before shadow calculation, commas mean they each have their own shadow
  1337. # [23:23] <ChrisL> David; apply-to gives the z-order?
  1338. # [23:23] <ChrisL> .. what if you apply to things that are not z-ordered together?
  1339. # [23:23] <ChrisL> Elika: you cant composite the text and the background and composite onto the border
  1340. # [23:24] <ChrisL> Simon: this is trying to get photoshop into css, i don't see the use case. Separate elements can be used to do this
  1341. # [23:25] <ChrisL> John: This sort of effect is better done in SVG, we don't need another language to do this. its a complex mechanism that duplicates something which already exists
  1342. # [23:25] <ChrisL> Elika: So SVG filters can be used but we lack the ability to select parts of the border
  1343. # [23:25] <ChrisL> John: If the goal is to do something this complex, is CSS the right language?
  1344. # [23:27] <ChrisL> Chris: We are headed for a fairly complex selector model if we do this, to get at parets of the border
  1345. # [23:28] <ChrisL> Elika: getting the whole border would be sufficient, but we need to address the different background layers
  1346. # [23:29] <bradk> ::apply-to(border + foreground, background-image + background-color)
  1347. # [23:30] <ChrisL> Chris: could imageine pseudo elements to address the border, the background(s) and the content
  1348. # [23:31] <fantasai> Then how do you turn it off?
  1349. # [23:31] <fantasai> How many pseudo-elements do you need to write to turn it off?
  1350. # [23:31] <fantasai> dbaron: I don't think this is the right way to do it...
  1351. # [23:31] <ChrisL> Brad: just targetting the whole border would satisfy my needs
  1352. # [23:32] <fantasai> fantasai: The pieces we'd need to address, in various combinations: background layers, border (one piece), content (one piece)
  1353. # [23:32] <ChrisL> Brad: we don't want to implement all of svg in css, sure. We want to be eble to use parts of them
  1354. # [23:33] <ChrisL> David: we already do SVG filters on any element
  1355. # [23:33] <ChrisL> Brad: but only the whole parts
  1356. # [23:33] <ChrisL> David: add to source-graphic source-alpha etc to add source-border, source-background ......
  1357. # [23:34] <fantasai> dbaron attempts to summarize how svg filters work
  1358. # [23:34] <smfr> http://www.w3.org/TR/SVG/filters.html#FilterPrimitivesOverview
  1359. # [23:34] <smfr> (scroll down)
  1360. # [23:34] <ChrisL> Simon: fill-apint and stroke-paint
  1361. # [23:34] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
  1362. # [23:35] <ChrisL> David: things to address the border, background or contents
  1363. # [23:35] <ChrisL> Tab: Could we use parameters with that
  1364. # [23:36] <ChrisL> Chris: Sure
  1365. # [23:36] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Oct/0072.html
  1366. # [23:36] <ChrisL> Elika: need a way to aprameterise that so we have a library of effects and apply them, without writing new filters
  1367. # [23:37] <ChrisL> Simon: background image in SVG is what has already been painted by other elements
  1368. # [23:38] <ChrisL> Elika: roc has some name suggestions
  1369. # [23:38] <ChrisL> Chris: please pass those on to the SVG WG. The editor is Erik Dahlstrom from Opera. We can add them
  1370. # [23:38] <ChrisL> David: Put them in the order you want and thats how they end up
  1371. # [23:39] <shepazu> [I'd be happy to talk to the CSS about my SVG parameters specification, which could pass parameters through a CSS property]
  1372. # [23:39] <jdaggett> shepazu: cmon down dear
  1373. # [23:39] <ChrisL> Elika: does not make sense for a border to cast a shadow *under* the background
  1374. # [23:40] <fantasai> border casts a shadow immediately under the border, i.e. over the background
  1375. # [23:40] <ChrisL> Brad; we should retain the natural stacking order
  1376. # [23:41] <fantasai> if border and background ar composited, then their shadow casts underneath the composited layer
  1377. # [23:41] <fantasai> i.e. directly underneat the background
  1378. # [23:42] * sylvaing next year, Tab's t-shirt: "Shadow. It drops, bitches"
  1379. # [23:42] <ChrisL> (discussion on how to pass opacity to a filter)
  1380. # [23:46] <ChrisL> Sion: how to get the putput of the filter int he right place
  1381. # [23:47] <ChrisL> s/Sion/Simon/
  1382. # [23:48] <ChrisL> Shepazu: we are adding more canned filter effects, we could add more if you identify the. Adds a merge for the border etc
  1383. # [23:48] * Quits: arronei (arronei@131.107.0.80) (Ping timeout)
  1384. # [23:48] <ChrisL> Elika: a filter to make the border and background partly transparent
  1385. # [23:49] <ChrisL> Shepazu: filters can be computationally intensive. Though canned filters can be optimised. need to warn authors
  1386. # [23:49] <ChrisL> Tab: Yes
  1387. # [23:50] <ChrisL> ... but won't trigger unexpectedly. Its clearly an opt-in
  1388. # [23:50] <ChrisL> Shepazu: Need to make a tradeoff between power, speed and authoring ease
  1389. # [23:50] * Quits: annevk (opera@72.254.82.30) (Quit: annevk)
  1390. # [23:50] <ChrisL> Simon: want to see blur and colour manip filters
  1391. # [23:51] <ChrisL> Shepazu: sepia, b&w
  1392. # [23:51] <ChrisL> Brad: so value in having a simple drop shadow?
  1393. # [23:51] <ChrisL> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html
  1394. # [23:51] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
  1395. # [23:52] * Joins: Lachy (Lachlan@72.254.56.137)
  1396. # [23:52] <ChrisL> Shepazu: need review from Erik and Anthony
  1397. # [23:52] * Quits: alexmog (alexmog@72.254.94.217) (Ping timeout)
  1398. # [23:53] <ChrisL> Brad: syntax there is more similar to the existing box-shadow property. Illustrations were done in photoshop
  1399. # [23:53] <ChrisL> Shepazu: Need to discuss, only now introducing canned filter effects so open to syntax that makes sense for CSS authors
  1400. # [23:53] * Joins: arronei (arronei@131.107.0.104)
  1401. # [23:56] <ChrisL> (we look at innter shadow on text again)
  1402. # [23:56] <ChrisL> Simon: for canned filters we would likely go to core graphics
  1403. # [23:57] <Bert_lap> s/innter/inner/
  1404. # [23:58] <ChrisL> Elika: happy to join any SVG telcons about this
  1405. # [23:58] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.85 [Firefox 3.5.4/20091016081620])
  1406. # [23:58] <ChrisL> filters spec is here http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html
  1407. # [23:59] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Ping timeout)
  1408. # [23:59] <dbaron> http://lists.w3.org/Archives/Public/public-fx/
  1409. # [23:59] <ChrisL> Shepazu: there is a public-fx@w3.org list
  1410. # [23:59] * Curt` is now known as Curt`|away
  1411. # [23:59] <ChrisL> http://lists.w3.org/Archives/Public/public-fx/
  1412. # Session Close: Wed Nov 04 00:00:00 2009

The end :)