/irc-logs / w3c / #css / 2011-02-12 / end

Options:

  1. # Session Start: Sat Feb 12 00:00:00 2011
  2. # Session Ident: #css
  3. # [00:18] * Joins: sylvaing (sylvaing@131.107.0.80)
  4. # [00:36] * Joins: plinss (plinss@68.107.116.23)
  5. # [00:38] <fantasai> TabAtkins: you're missing the case of having one dimension
  6. # [00:38] <fantasai> TabAtkins: and no ratio
  7. # [00:39] <TabAtkins> Oh, indeed I am. Hmm.
  8. # [00:39] <TabAtkins> Is that interoperable?
  9. # [00:39] <fantasai> TabAtkins: Typically, that would result in honoring the intrinsic dimension and defaulting to the default sizing area
  10. # [00:39] <fantasai> TabAtkins: In this case we copy the intrinsic dimension to the other one
  11. # [00:39] <fantasai> TabAtkins: I don't know
  12. # [00:40] <fantasai> TabAtkins: I'm don't think we have tests for that
  13. # [00:40] <TabAtkins> Let me do some testing.
  14. # [00:40] <TabAtkins> >_< I hate lack of test coverage.
  15. # [00:40] <TabAtkins> Anyway, I'll be back in a few.
  16. # [00:50] <TabAtkins> fantasai: Only webkit and opera allow svg images for list-style-image, and I don't know any other way to get an image with only a single intrinsic dimension, so I'm only going by their behavior.
  17. # [00:50] <TabAtkins> The answer is no, they follow the ordinary image sizing algorithm.
  18. # [00:50] <TabAtkins> In that the missing dimension is set to 1em.
  19. # [00:51] <TabAtkins> (Well, webkit fills in a weird value if 'height' is missing, which I think is related to the height of a normal bullet. But it definitely uses 1em for width.)
  20. # [00:51] <TabAtkins> I guess I'll bring this up on the list.
  21. # [01:21] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
  22. # [01:29] <fantasai> TabAtkins: Are we otherwise all set to publish?
  23. # [01:32] <TabAtkins> fantasai: Brad still hasn't given me his feedback, but he's aware of the need for it, and I've given him the deadline.
  24. # [01:32] <TabAtkins> So, yes.
  25. # [01:42] <fantasai> TabAtkins: you're missing the image-rendering values from SVG
  26. # [01:42] <fantasai> TabAtkins: they're already in the CSS space, right?
  27. # [01:43] <shepazu> anything I can do to help? anything to review?
  28. # [01:43] <shepazu> tests that need writing?
  29. # [01:44] <fantasai> you have "SVG" hooked to "summon shepazu" don't you
  30. # [01:45] <shepazu> I have :)
  31. # [01:45] <shepazu> my SVG-sense was tingling
  32. # [01:45] <fantasai> heh
  33. # [01:46] <fantasai> TabAtkins: Let me know when you're done editing and I'll generate the draft for Tuesday
  34. # [01:46] <fantasai> TabAtkins: note that Bert has to set up the draft on Monday, so Brad has to send his feedback in this weekend
  35. # [01:48] <fantasai> TabAtkins: what deadline did you give him?
  36. # [01:50] <fantasai> shepazu: I think you need an issue raised against the definition of image-rendering in css3-images, since it doesn't account for SVG's values and the new value is inconsistently named with them. Something to deal with later, though; I think I don't want Tab editing the draft substantively atm so we can actually publish the WD :)
  37. # [01:50] <fantasai> shepazu: It's probably fine to deprecate those values if they're no longer needed, but SVG1.1 impls will need to be able to support them
  38. # [01:52] <shepazu> I thought we decided to use a different name than image-rendering...
  39. # [02:38] <TabAtkins> fantasai: I have the SVG values. They're listed as aliases of "auto".
  40. # [02:47] <fantasai> cool
  41. # [02:48] <fantasai> TabAtkins: so, on the topic of use cases
  42. # [02:48] <fantasai> TabAtkins: how would you distinguish a line drawing from pixel art when scaling?
  43. # [02:48] <TabAtkins> What do you mean?
  44. # [02:49] <fantasai> TabAtkins: In the latter case, the ideal optimize-contrast would trace the lines and then scale up the vectorized image
  45. # [02:49] <fantasai> TabAtkins: but pixel art should be scaled by increasing the size of the "pixel"s
  46. # [02:49] <fantasai> TabAtkins: both are contrast-optimizing ways of scaling
  47. # [02:49] <TabAtkins> That's not true. Check out the EPX algorithm.
  48. # [02:49] <TabAtkins> Which would handle lineart pretty well, actually.
  49. # [02:50] <TabAtkins> I don't know if "treat this raster image as vector" is ever going to be a realistic solution, though.
  50. # [02:51] <fantasai> not expecting it to be :)
  51. # [02:52] <fantasai> just pointing out that if you pixellated art, you can't get that with optimize-contrast
  52. # [02:52] <fantasai> I don't expect it to be a major use case
  53. # [02:52] <fantasai> but I'm wondering if that's what the person on www-style wanted
  54. # [02:52] <TabAtkins> No, they wanted the ability to specify "nearest-neighbor" specifically.
  55. # [02:52] <TabAtkins> Which, in practice, is probably going to be what 'optimize-contrast' means.
  56. # [02:56] <TabAtkins> Most pixel-art scaling algorithms are only designed to handle integer resize factors, after all.
  57. # [02:59] <TabAtkins> I'm gonna bug Brad about giving me the feedback over the weekend.
  58. # [03:02] <fantasai> kk
  59. # [03:03] <fantasai> TabAtkins: but if optimize-contrast used EPX instead, then they'd get a different result. So if they want nearest-neighbor specifically, it won't be cross-platform
  60. # [03:04] <TabAtkins> Right. My point in the thread was that, if they *really* have need for nearest-neighbor specifically, they can do it themselves. The majority of authors would be happy to let their pixel art scale up with EPX or similar, because it's awesome.
  61. # [03:23] * Quits: sylvaing (sylvaing@131.107.0.80) (Ping timeout)
  62. # [03:30] * Joins: sylvaing (sylvaing@131.107.0.101)
  63. # [03:31] * Joins: sgalineau (sylvaing@72.62.96.11)
  64. # [03:32] * Quits: sylvaing (sylvaing@131.107.0.101) (Connection reset by peer)
  65. # [03:33] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  66. # [03:55] * Quits: sgalineau (sylvaing@72.62.96.11) (Quit: sgalineau)
  67. # [04:08] * Joins: deane (dean@119.224.91.235)
  68. # [05:46] * Joins: anne (annevk@95.34.115.33)
  69. # [07:10] * Joins: dbaron (dbaron@98.234.51.190)
  70. # [07:13] * Quits: anne (annevk@95.34.115.33) (Quit: anne)
  71. # [09:27] * Quits: dbaron (dbaron@98.234.51.190) (Ping timeout)
  72. # [09:59] * Joins: Martijnc (Martijnc@91.176.34.19)
  73. # [10:50] * Joins: Ms2ger (Ms2ger@91.181.39.63)
  74. # [14:02] * Quits: Ms2ger (Ms2ger@91.181.39.63) (Quit: bbl)
  75. # [17:19] * Joins: kennyluck (kennyluck@128.30.52.169)
  76. # [17:19] * Quits: kennyluck (kennyluck@128.30.52.169) (Client exited)
  77. # [17:20] * Joins: kennyluck (kennyluck@128.30.52.169)
  78. # [17:23] * Joins: dbaron (dbaron@98.234.51.190)
  79. # [18:52] * Quits: arronei (arronei@131.107.0.85) (Ping timeout)
  80. # [18:57] * Joins: arronei (arronei@131.107.0.71)
  81. # [21:13] * Parts: deane (dean@119.224.91.235)
  82. # [21:46] * Quits: Bert (bbos@mcclure.w3.org) (Quit: leaving)
  83. # [21:46] * Joins: Bert (bbos@mcclure.w3.org)
  84. # [22:10] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  85. # [22:17] * Quits: Martijnc (Martijnc@91.176.34.19) (Quit: Martijnc)
  86. # Session Close: Sun Feb 13 00:00:00 2011

The end :)