/irc-logs / w3c / #css / 2011-05-10 / end

Options:

  1. # Session Start: Tue May 10 00:00:00 2011
  2. # Session Ident: #css
  3. # [00:00] <TabAtkins> Do you think I send them something explicitly?
  4. # [00:00] <TabAtkins> Probably.
  5. # [00:00] <fantasai> dunno
  6. # [00:00] <TabAtkins> I'll go ahead and do so.
  7. # [00:00] <fantasai> depends on whether they follow the WAI-PF workflow or not
  8. # [00:01] <fantasai> in which case we'd need glazou to send a comment or something -__-
  9. # [00:01] <TabAtkins> They need to get off their ass and finally decide that their stupid "maybe fragments should just highlight part of the full image!" idea should be dropped.
  10. # [00:01] <TabAtkins> On account of it being stupid.
  11. # [00:02] <fantasai> note, it's consistent with HTML
  12. # [00:02] <fantasai> where we show the whole document and then :target the right piece
  13. # [00:02] <TabAtkins> Not quite. If you target an SVG fragment, for example, you're referring to just that piece.
  14. # [00:02] <TabAtkins> There's precedent on both sides.
  15. # [00:03] <fantasai> That's actually something I'm not totally clear on -- what does it mean to target a piece of an SVG
  16. # [00:03] <TabAtkins> But chopping an image is actually useful, whereas highlighting is silly.
  17. # [00:03] <TabAtkins> So, it depends on what level you're talking about.
  18. # [00:03] <fantasai> in the URL bar
  19. # [00:03] <fantasai> or <img>
  20. # [00:03] <fantasai> or <object>
  21. # [00:03] <TabAtkins> Within SVG, targetting a fragment in, say, a fill property refers to the thing that you're targetting, only.
  22. # [00:04] <fantasai> also, should we define background: image(svg#gradient-element); to do something useful?
  23. # [00:05] <TabAtkins> Within an embedding environment, I don't think it's well-defined. But there's been discussion on it, and it should just grab the subset of the SVG, I believe, as if you defined an xywh fragment with the appropriate dimensions.
  24. # [00:05] <TabAtkins> And if you refer to a paint server like an SVG gradient element, it should act as a paint server.
  25. # [00:05] <fantasai> That would be cool for <rect>s and <path>s and <group>s and <svg>s and things
  26. # [00:05] <TabAtkins> This should be defined by SVG.
  27. # [00:05] <fantasai> yes
  28. # [00:05] <fantasai> yes
  29. # [00:06] <TabAtkins> Which, now that I'm part of SVG, I can help do.
  30. # [00:06] <fantasai> excellent
  31. # [00:07] <TabAtkins> The only problem with the "act like a paint server" thing is that CSS and SVG have kinda weird differences in precisely how they handle coordinates referred to in paint server definitions.
  32. # [00:07] <TabAtkins> brb
  33. # [00:13] <shepazu> TabAtkins, fantasai, in SVG, only 'graphics elements' can be meaningfully targeted for rendering changes
  34. # [00:13] <fantasai> shepazu: If I load an SVG in my browser and target a <rect>, what happens
  35. # [00:13] <fantasai> shepazu: Do I see the whole SVG image, or just the stuff inside the <rect>?
  36. # [00:14] * fantasai has some recollection of the former being the case
  37. # [00:16] <TabAtkins> fantasai: Right now, pretty sure you get the whole thing, because the fragment has no effect.
  38. # [00:17] <fantasai> TabAtkins: Right, and then you can style that thing with :target if you wanted to
  39. # [00:18] <fantasai> I'm wondering if we can incorporate some error-handling here
  40. # [00:18] <fantasai> Maybe if you use image() and you have a fragment identifier
  41. # [00:18] <fantasai> if it can't be resolved into an image, then the whole image() is treated as nonexistent
  42. # [00:19] <fantasai> So
  43. # [00:19] <fantasai> image(foo.png#bar) would return nothing
  44. # [00:19] <fantasai> image(foo.png#xywh=...) would return the fragment per MF
  45. # [00:19] <TabAtkins> But foo.png#bar does resolve to an image, doesn't it? It's just the whole image.
  46. # [00:20] <fantasai> image(foo.svg#xywh=...) would return the SVG fragment per MF
  47. # [00:20] <shepazu> sorry, had a phone call
  48. # [00:20] <fantasai> image(foo.svg#gradient) would return nothing, currently, but would return a gradient paint server once we define that
  49. # [00:20] <fantasai> image(foo.svg#rect) similarly would return nothing, currently, but would return the clipped out <rect> once we define how that works
  50. # [00:21] <shepazu> fantasai: per the spec, the UA should zoom in on the rectangle
  51. # [00:21] <shepazu> but that doesn't happen in most browsers
  52. # [00:21] <fantasai> shepazu: interesting
  53. # [00:21] <TabAtkins> So what you mean is that we define a subset of fragments that do something useful and allow them to work as normal (defined by the respective other specs), and explicitly say that all other fragments cause the image to be ignored.
  54. # [00:21] <shepazu> because it wasn't clearly stated in SVG 1.1
  55. # [00:21] <fantasai> TabAtkins: Yeah
  56. # [00:21] <fantasai> shepazu: got it
  57. # [00:21] <shepazu> TabAtkins: yeah
  58. # [00:21] <TabAtkins> That's possible, I guess.
  59. # [00:22] <fantasai> shepazu: How about we put some clip-out SVG examples in the spec :)
  60. # [00:22] <fantasai> the css3-images spec, I mean
  61. # [00:22] <shepazu> TabAtkins: of course, it would be the same if the fragment isn't found
  62. # [00:22] <shepazu> fantasai: sure, I'd be happy to help
  63. # [00:22] <TabAtkins> shepazu: The "zoom" behavior actually works for this, too, given that images are, by default, clipped to their concrete object size.
  64. # [00:23] * fantasai was thinking the same thing
  65. # [00:23] <TabAtkins> Even if the rest of the SVG is "rendered", it would then be clipped away.
  66. # [00:23] <fantasai> TabAtkins: Although, non-rectangular shapes /could/ be interpreted differently
  67. # [00:23] <shepazu> hmmm, which spec is this?
  68. # [00:23] <fantasai> TabAtkins: zooming would get you the bounding box
  69. # [00:23] <fantasai> http://dev.w3.org/csswg/css3-imgaes/
  70. # [00:23] <TabAtkins> shepazu: Image Values.
  71. # [00:23] <fantasai> http://dev.w3.org/csswg/css3-images/
  72. # [00:24] <TabAtkins> fantasai: Yeah, the zooming should clearly be to some notion of bounding box.
  73. # [00:24] <shepazu> TabAtkins: well, per SVG 1.1, it wouldn't count the stroke-width in the bbox calc
  74. # [00:24] <shepazu> just the "geometry"
  75. # [00:24] <TabAtkins> Yeah, that's a bit of a problem.
  76. # [00:24] <TabAtkins> And things like filter effects wouldn't work either.
  77. # [00:24] <shepazu> it's different
  78. # [00:24] <fantasai> why wouldn't filter effects work?
  79. # [00:24] <shepazu> yeah, and what about transforms?
  80. # [00:24] <shepazu> some filter effects color outside the lines
  81. # [00:24] <fantasai> wouldn't you zoom to the transformed result?
  82. # [00:24] <fantasai> the UI makes no sense otherwise :)
  83. # [00:25] <shepazu> sure, but that's not the bbox
  84. # [00:25] <fantasai> so you're saying
  85. # [00:25] <shepazu> that's the "rendering area" or something SVG doesn't define
  86. # [00:25] <fantasai> that if I target the <rect> element
  87. # [00:25] <fantasai> it zooms in to someplace where the <rect> might not actually be?
  88. # [00:25] <fantasai> that's silly
  89. # [00:25] <TabAtkins> So, we need to define this in a more useful manner in SVG2 I guess?
  90. # [00:26] <shepazu> no.... I don't think we were that silly
  91. # [00:26] <shepazu> lemme look
  92. # [00:28] <shepazu> http://www.w3.org/TR/SVGTiny12/linking.html#SVGFragmentIdentifiers
  93. # [00:28] <shepazu> that's the improved (but probably not very good) SVG Tiny 1.2 definition
  94. # [00:28] <shepazu> in SVG 2, we will make this better
  95. # [00:29] <shepazu> wow... did we completely punt on the transformation?
  96. # [00:29] <shepazu> wtf?
  97. # [00:30] <TabAtkins> Do transformations not talk about the decorated bounding box?
  98. # [00:30] * Joins: nimbupani (Adium@24.18.47.160)
  99. # [00:30] <shepazu> looking
  100. # [00:30] * Parts: nimbupani (Adium@24.18.47.160)
  101. # [00:31] <shepazu> yeah, I think it accounts for transforms
  102. # [00:31] <shepazu> gah
  103. # [00:31] <shepazu> I don't see it
  104. # [00:31] <fantasai> errata? :)
  105. # [00:32] <shepazu> I really really want to rewrite this whole thing from scratch
  106. # [00:32] <TabAtkins> DO IT
  107. # [00:32] <TabAtkins> Also: define it in XML5.
  108. # [00:32] <fantasai> So, back to css3-images
  109. # [00:32] <fantasai> :)
  110. # [00:33] <fantasai> one of the things we talked about with gradients was using SVG gradients in CSS
  111. # [00:33] <fantasai> can we do that yet?
  112. # [00:33] <TabAtkins> Not yet, no.
  113. # [00:33] <fantasai> do we want to do that here?
  114. # [00:33] <fantasai> or does that need work?
  115. # [00:33] <TabAtkins> Ideally, it should be doable by saying url(foo.svg#grad), and doing some magic twiddling to make the coordinates do something useful.
  116. # [00:34] <fantasai> or image(foo.svg#grad)
  117. # [00:34] <TabAtkins> Sure.
  118. # [00:34] <fantasai> the latter, if we define it to work in css3-images before you drop prefixes
  119. # [00:34] <fantasai> means authors can use our fallback parsing
  120. # [00:34] <TabAtkins> Are you intending that image() have different behavior than url() sometimes?
  121. # [00:34] <fantasai> I don't know if it should have different behavior sometimes.
  122. # [00:34] <fantasai> bz thinks it should
  123. # [00:35] <fantasai> I'm kinda undecided
  124. # [00:35] <TabAtkins> Interesting. Why?
  125. # [00:35] <fantasai> He's concerned about backwards-compat for some reason.
  126. # [00:35] <TabAtkins> I though image() was just url(), but better because it's specialized toward images.
  127. # [00:35] <fantasai> That's how I had it originally
  128. # [00:35] <fantasai> But there was /one/ thing that was special
  129. # [00:36] <fantasai> I made image fragment support mandatory if you want to implement image()
  130. # [00:36] <TabAtkins> Oh, huh. That seems... weird. Surely it's orthogonal?
  131. # [00:36] <fantasai> Because otherwise you can't use parsing fallback
  132. # [00:36] <fantasai> tying fragment support to image() means authors can rely on the fragment working when they use image()
  133. # [00:37] <fantasai> if they use url(), then old browsers will load the entire image
  134. # [00:37] <fantasai> ignoring the frag id
  135. # [00:37] <fantasai> this way old browsers will not load anything, because it failed ot parse
  136. # [00:37] <fantasai> s/ot/to/
  137. # [00:37] <TabAtkins> I don't know if I like them being tied together like that purely so you're assured that an orthogonal feature will always fallback.
  138. # [00:38] <fantasai> do you have a better suggestion for phasing things in?
  139. # [00:38] <TabAtkins> Just let them evolve on their own, and hope that the two features arrive at roughly the same time?
  140. # [00:38] <TabAtkins> Alternately, define a frag() function or something, and handle media fragments on our own (deferring to MF for the actual processing).
  141. # [00:39] <fantasai> TabAtkins: I'd rather have the hack be reliable than accidental.
  142. # [00:39] <shepazu> TabAtkins: I don't know if we are going to define SVG in terms of XML... if there were an XML5 to reference, maybe we would... we might simply define parsing and fallback behavior, like in HTML5
  143. # [00:39] <TabAtkins> frag(image, rect 0 0 100 100), frag(video, frame 200), etc.
  144. # [00:39] * Quits: dsinger (dsinger@68.126.197.146) (Quit: dsinger)
  145. # [00:40] <TabAtkins> shepazu: That works too. The point is just to have a simpler reference that isn't as silly as XML.
  146. # [00:40] <fantasai> TabAtkins: we /could/ do that. I'm not sure it's a good idea given MF is defining syntax for it already.
  147. # [00:40] <TabAtkins> Yeah, I dunno if I like it either. But it does make it explicitly a prefixable feature.
  148. # [00:40] <fantasai> TabAtkins: If authors can learn one syntax and use it everywhere, isn't that better?
  149. # [00:40] <shepazu> (or as silly as HTML5)
  150. # [00:41] <TabAtkins> shepazu: That silliness is, unfortunately, required for legacy. But yes, god yes.
  151. # [00:41] <shepazu> TabAtkins: only for HTML legacy... not for SVG legacy
  152. # [00:41] <TabAtkins> Yes, of course.
  153. # [00:41] <shepazu> ours can be simpler
  154. # [00:41] <TabAtkins> Anne has an XML5 draft on his blog.
  155. # [00:41] <shepazu> whatever :)
  156. # [00:42] <TabAtkins> http://code.google.com/p/xml5/
  157. # [00:42] <shepazu> telegraph me when he finishes it
  158. # [00:43] <shepazu> we may simply define a parsing model in a separate chapter, which could actually be broken out
  159. # [00:43] <TabAtkins> Yeah, that's cool too.
  160. # [00:44] <shepazu> that google code page is less than inspiring
  161. # [00:46] <fantasai> TabAtkins: the image-resolution issue should be closeable just by doing some testing in Prince/Antenna House
  162. # [00:46] <TabAtkins> It defines most of the processing model, just with a few obvious bits left out, and a few difficult bits (finding the encoding, how to handle entities) also currently undefined.
  163. # [00:46] <fantasai> TabAtkins: We might consider reverting from-image to 'auto' though, according to the docs that's what's implemented...
  164. # [00:47] <TabAtkins> fantasai: So, like, "auto 2dppx"?
  165. # [00:48] <fantasai> I think so, not sure
  166. # [00:48] <fantasai> I think they're not consistent in that respect, actually :/
  167. # [00:48] <TabAtkins> Yay.
  168. # [00:49] <TabAtkins> That means I can define what I want!
  169. # [00:49] <fantasai> um
  170. # [00:49] <fantasai> if I agree, sure ^_^
  171. # [00:49] <fantasai> the main issue is whether image-rendering applies to bg images by default
  172. # [00:49] <fantasai> or list-style-image
  173. # [00:49] <TabAtkins> Yeah.
  174. # [00:49] <TabAtkins> I had it defined to apply to everything previously.
  175. # [00:50] <fantasai> I think you had it marked as an issue
  176. # [00:50] <TabAtkins> Or, wait, did you mean image-rendering or image-resolution?
  177. # [00:50] <fantasai> image-resolution
  178. # [00:50] <fantasai> sorry
  179. # [00:51] <fantasai> http://princexml.com/doc/7.0/properties/prince-image-resolution/
  180. # [00:51] <TabAtkins> image-resolution is virtually untouched by me. It's currently defined to only apply to content images, with a note that it maybe should apply to all.
  181. # [00:51] <fantasai> 'normal' means 1dppx
  182. # [00:52] <fantasai> http://www.antennahouse.com/CSSInfo/css_reference.html#image-resolution
  183. # [00:52] <fantasai> Ah, GCPM
  184. # [00:52] <fantasai> it was an issue in gcpm, that's hat
  185. # [00:53] <TabAtkins> ...hat?
  186. # [00:53] <fantasai> s/hat/what/
  187. # [00:53] * fantasai is so not doing well on the typing thing today
  188. # [00:54] <TabAtkins> I don't understand why they're both list-valued. Do they apply to backgrounds or something?
  189. # [00:54] <TabAtkins> (In Prince and AH.)
  190. # [00:54] <fantasai> they're listed because that was an older syntax
  191. # [00:54] <TabAtkins> These are horrible docs.
  192. # [01:02] <TabAtkins> fantasai: Who do I ping to ask about AH stuff?
  193. # [01:10] <fantasai> Murakami-san
  194. # [01:15] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
  195. # [01:20] * Joins: homata_ (homata_@58.158.182.50)
  196. # [02:24] * Quits: sylvaing (sylvaing@98.232.9.174) (Ping timeout)
  197. # [02:44] * Quits: TabAtkins_ (tabatkins@216.239.45.4) (Ping timeout)
  198. # [02:47] * Joins: TabAtkins_ (tabatkins@216.239.45.19)
  199. # [02:59] * Joins: sylvaing (sylvaing@98.232.9.174)
  200. # [03:02] * Joins: myakura (d2e8220d@109.169.29.95)
  201. # [03:12] <myakura> fantasai: http://dev.w3.org/csswg/css-2010/ doesn't point to the roadmap draft but css-2007 does. is that intentional?
  202. # [03:12] <fantasai> myakura: yes
  203. # [03:13] <myakura> okay. thanks!
  204. # [03:13] * Quits: TabAtkins_ (tabatkins@216.239.45.19) (Ping timeout)
  205. # [03:13] <fantasai> myakura: I only linked to the roadmap because that's kindof required/good practice when you're replacing a /TR/shortname
  206. # [03:13] <fantasai> with another set of docs
  207. # [03:18] <myakura> makes sense.
  208. # [03:27] * Joins: homata (homata@58.158.182.50)
  209. # [03:36] <myakura> fantasai: you may need to fix the pubdate. http://dev.w3.org/cvsweb/~checkout~/csswg/css-2010/Overview.html?rev=1.22 says it's a 2010-05-10 draft.
  210. # [03:42] * Quits: myakura (d2e8220d@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
  211. # [03:53] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  212. # [03:55] * Joins: dbaron (dbaron@74.103.171.70)
  213. # [04:04] * Joins: homata (homata@113.34.70.146)
  214. # [04:08] * Quits: homata (homata@113.34.70.146) (Ping timeout)
  215. # [04:53] * Quits: sylvaing (sylvaing@98.232.9.174) (Ping timeout)
  216. # [05:21] * Joins: homata (homata@58.158.182.50)
  217. # [05:31] * Quits: dbaron (dbaron@74.103.171.70) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  218. # [06:19] * Joins: homata__ (homata@58.158.182.50)
  219. # [06:21] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  220. # [06:51] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
  221. # [08:29] * Quits: homata__ (homata@58.158.182.50) (Quit: Leaving...)
  222. # [10:56] * Quits: jdaggett (jdaggett@202.221.217.73) (Quit: jdaggett)
  223. # [10:56] * jdaggett_ is now known as jdaggett
  224. # [11:46] * Quits: plinss (plinss@68.107.116.23) (Ping timeout)
  225. # [12:54] * Quits: jdaggett (jdaggett@118.243.227.145) (Quit: jdaggett)
  226. # [15:34] * Joins: dbaron (dbaron@74.103.171.70)
  227. # [15:57] * Joins: sylvaing (sylvaing@173.147.183.37)
  228. # [16:14] * Quits: sylvaing (sylvaing@173.147.183.37) (Ping timeout)
  229. # [16:20] * Joins: sylvaing (sylvaing@173.147.183.37)
  230. # [16:23] * Quits: sylvaing (sylvaing@173.147.183.37) (Ping timeout)
  231. # [16:36] * Joins: sylvaing (sylvaing@131.107.0.80)
  232. # [17:36] * Joins: Martijnc (Martijnc@84.192.44.100)
  233. # [17:43] * Quits: Martijnc (Martijnc@84.192.44.100) (Quit: Martijnc)
  234. # [17:47] * Joins: Martijnc (Martijnc@84.192.44.100)
  235. # [17:56] * Quits: sylvaing (sylvaing@131.107.0.80) (Connection reset by peer)
  236. # [18:05] * Joins: Ms2ger (Ms2ger@91.181.115.237)
  237. # [18:47] * Joins: sylvaing (sylvaing@131.107.0.101)
  238. # [19:09] * Quits: dbaron (dbaron@74.103.171.70) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  239. # [19:30] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
  240. # [19:50] * Quits: sylvaing (sylvaing@131.107.0.101) (Connection reset by peer)
  241. # [20:19] <TabAtkins> fantasai: I've heard before that :link only exists for legacy reasons, to make it easier to distinguish the link case from the named anchor case. Do you remember if there was a good reason why something like a[href] wasn't sufficient for that?
  242. # [20:20] <TabAtkins> Were attribute selectors just not invented yet at that time or something?
  243. # [20:20] <Ms2ger> That sounds likely
  244. # [20:21] <Ms2ger> :link is CSS1
  245. # [20:21] <TabAtkins> Actually, yeah, looking at CSS1, I don't see attribute selectors.
  246. # [20:38] * Joins: plinss (plinss@192.6.114.30)
  247. # [21:06] * Quits: Ms2ger (Ms2ger@91.181.115.237) (Connection reset by peer)
  248. # [21:09] * Joins: Ms2ger (Ms2ger@91.181.115.237)
  249. # [21:40] * Joins: karl (karlcow@128.30.54.58)
  250. # [21:53] * Quits: Martijnc (Martijnc@84.192.44.100) (Quit: Martijnc)
  251. # [22:48] * Quits: Ms2ger (Ms2ger@91.181.115.237) (Quit: nn)
  252. # [23:10] * Joins: sylvaing (sylvaing@131.107.0.80)
  253. # [23:28] * Joins: arronei (arronei@131.107.0.85)
  254. # [23:29] * Quits: arronei_ (arronei@131.107.0.76) (Ping timeout)
  255. # [23:30] * Quits: sylvaing (sylvaing@131.107.0.80) (Connection reset by peer)
  256. # [23:36] * Joins: sylvaing (sylvaing@131.107.0.80)
  257. # [23:55] * Quits: sylvaing (sylvaing@131.107.0.80) (Connection reset by peer)
  258. # Session Close: Wed May 11 00:00:00 2011

The end :)