/irc-logs / freenode / #whatwg / 2007-12-17 / end

Options:

  1. # Session Start: Mon Dec 17 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:16] * Quits: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no) ("Leaving")
  4. # [00:17] * Joins: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no)
  5. # [00:18] <Lachy> is anyone else having trouble connecting to irc.w3.org?
  6. # [00:18] <gsnedders> I'm on it fine
  7. # [00:18] <Lachy> weird. I'm getting unknown host errors
  8. # [00:19] <gsnedders> just disconnected and reconnected without issue
  9. # [00:19] * Quits: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no) (Client Quit)
  10. # [00:20] * Joins: Lachy (n=Lachlan@ti200710a340-2779.bb.online.no)
  11. # [00:20] * Quits: Lachy (n=Lachlan@ti200710a340-2779.bb.online.no) (Client Quit)
  12. # [00:20] * Joins: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no)
  13. # [00:21] <Lachy> hmm. now it's working
  14. # [00:22] <csarven> 6665 is okay for me
  15. # [00:25] * Joins: jacobolus (n=jacobolu@pool-71-104-40-56.lsanca.dsl-w.verizon.net)
  16. # [00:28] * Quits: gsnedders (n=gsnedder@host86-135-224-200.range86-135.btcentralplus.com)
  17. # [00:40] * Quits: tndH (i=Rob@adsl-87-102-85-165.karoo.KCOM.COM) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  18. # [00:46] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  19. # [00:58] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) ("leaving")
  20. # [01:13] * Quits: webben (n=benh@82.152.16.177) (Remote closed the connection)
  21. # [01:14] * Joins: webben (n=benh@82.152.16.177)
  22. # [01:45] * Joins: spuffle (n=spuffle@cpe-74-72-192-221.nyc.res.rr.com)
  23. # [01:49] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  24. # [02:02] * Joins: gsnedders (n=gsnedder@host86-135-224-200.range86-135.btcentralplus.com)
  25. # [02:09] <othermaciej> I wonder how Andy Clarke came to his conclusions about how to improve CSS
  26. # [02:22] <spuffle> got a link? :)
  27. # [02:25] <othermaciej> http://www.stuffandnonsense.co.uk/malarkey/more/css_unworking_group/
  28. # [02:25] <othermaciej> http://www.stuffandnonsense.co.uk/malarkey/more/csswg_proposals/
  29. # [02:25] <othermaciej> short version, he would like to get rid of implementors and have the W3C pay web designers to be on the working group full time
  30. # [02:25] <othermaciej> or something
  31. # [02:25] <othermaciej> because Opera sued Microsoft
  32. # [02:27] <spuffle> ahha
  33. # [02:27] <spuffle> always gotta make a bold statement
  34. # [02:32] * Joins: doublec (n=doublec@ma60f36d0.tmodns.net)
  35. # [02:33] <spuffle> defintely +1 for leadership
  36. # [02:34] * Joins: roc (n=roc@202.0.36.64)
  37. # [02:34] <spuffle> It's just an opinion though, everyone is entitled to theirs
  38. # [02:48] <othermaciej> leadership is a good thing, given the right leader
  39. # [02:48] <othermaciej> mainly what puzzles me is why he thinks less implementor involvement would be good
  40. # [02:48] <othermaciej> I think a key problem is not enough implementor involvement
  41. # [02:48] <othermaciej> (and the fact that few other parties have the needed skills and the time to spend)
  42. # [02:51] <spuffle> he just wants to see it run like a business
  43. # [02:51] <spuffle> with a more corporate-style hierachy
  44. # [02:52] <roc> I think he's in "X isn't working, panic, let's try Y" mode
  45. # [02:56] <othermaciej> running it like a business certainly wouldn't involve removing the participants that are actual businesses
  46. # [02:56] <othermaciej> "let's treat it like a software project - get rid of the software vendors and let the users drive it from their wishlist"
  47. # [02:56] <othermaciej> that ain't how software gets shipped
  48. # [02:58] <othermaciej> damn, I posted some wordy blog comments
  49. # [03:00] * Quits: jacobolus (n=jacobolu@pool-71-104-40-56.lsanca.dsl-w.verizon.net)
  50. # [03:01] * Quits: doublec (n=doublec@ma60f36d0.tmodns.net)
  51. # [03:01] * Joins: jacobolus (n=jacobolu@pool-71-104-40-56.lsanca.dsl-w.verizon.net)
  52. # [03:01] * Quits: jacobolus (n=jacobolu@pool-71-104-40-56.lsanca.dsl-w.verizon.net) (Client Quit)
  53. # [03:01] <jruderman> i just read http://www.stuffandnonsense.co.uk/malarkey/more/css_unworking_group/ and i don't understand why he thinks Opera's antitrust complaint has anything to do with the development of CSS3
  54. # [03:02] <othermaciej> me neither
  55. # [03:04] <jruderman> "I was surprised to learn that one of the reasons why CSS2.1 is only now nearing its candidate recommendation status is because its features are now widely supported by browsers."
  56. # [03:05] <jruderman> in reality, is it just because there are multiple interoperable implementations?
  57. # [03:05] <jruderman> in which case microsoft dragging its feet doesn't really slow things down
  58. # [03:06] <othermaciej> multiple interoperable implementations, and the fact that implementations showed problems
  59. # [03:06] <othermaciej> I think CSS2.1 may have actually already hit CR once and went back to WD
  60. # [03:07] * othermaciej hopes it wasn't rude to answer the question about how to learn more about CSS internals with a suggestion to get involved w/ an open source browser engine
  61. # [03:07] <othermaciej> obviously, I have some selfish interests there
  62. # [03:08] * Quits: grimboy (n=grimboy@85-211-243-20.dsl.pipex.com) (Read error: 104 (Connection reset by peer))
  63. # [03:09] <hdh> well, that's still a 1/3 chance :)
  64. # [03:10] <othermaciej> I think there's only 2 significant open source browser engines
  65. # [03:10] <othermaciej> but maybe I'm counting wrong
  66. # [03:11] <hdh> khtml isn't dropped yet
  67. # [03:13] <hdh> btw, who's the other maciej?
  68. # [03:17] <othermaciej> someone else
  69. # [03:42] <roc> othermaciej: I believe Dillo, links, and Amaya are all under active development
  70. # [03:43] <roc> oh, significant :-)
  71. # [03:44] <othermaciej> I don't think Dillo is
  72. # [03:44] <othermaciej> and trying to do QA on Amaya would just be depressing
  73. # [03:45] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  74. # [03:56] * Joins: jacobolus (n=jacobolu@pool-71-119-195-74.lsanca.dsl-w.verizon.net)
  75. # [04:02] * Joins: wakaba_ (n=w@79.163.210.220.dy.bbexcite.jp)
  76. # [04:04] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (kubrick.freenode.net irc.freenode.net)
  77. # [04:04] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (kubrick.freenode.net irc.freenode.net)
  78. # [04:04] * Quits: YaaL (i=yaal@hell.pl) (kubrick.freenode.net irc.freenode.net)
  79. # [04:04] * Quits: jgraham (n=jgraham@81-86-217-3.dsl.pipex.com) (kubrick.freenode.net irc.freenode.net)
  80. # [04:04] * Quits: heycam (n=cam@210-84-9-222.dyn.iinet.net.au) (kubrick.freenode.net irc.freenode.net)
  81. # [04:04] * Quits: ianloic (i=yakk@glub.dreamhostps.com) (kubrick.freenode.net irc.freenode.net)
  82. # [04:04] * Quits: Hixie (n=ianh@trivini.no) (kubrick.freenode.net irc.freenode.net)
  83. # [04:04] * Quits: Polar (i=polar@polar.xen.chris-lamb.co.uk) (kubrick.freenode.net irc.freenode.net)
  84. # [04:04] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (kubrick.freenode.net irc.freenode.net)
  85. # [04:04] * Quits: wakaba (n=w@79.163.210.220.dy.bbexcite.jp) (kubrick.freenode.net irc.freenode.net)
  86. # [04:04] * Quits: gavins (n=gavin@firefox/developer/gavin) (kubrick.freenode.net irc.freenode.net)
  87. # [04:04] * Quits: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp) (kubrick.freenode.net irc.freenode.net)
  88. # [04:04] * Quits: arnath01 (n=arnath@d54C1C929.access.telenet.be) (kubrick.freenode.net irc.freenode.net)
  89. # [04:04] * Quits: Philip` (n=philip@zaynar.demon.co.uk) (kubrick.freenode.net irc.freenode.net)
  90. # [04:04] * Quits: Lfe (n=lfe@bergstroem.nu) (kubrick.freenode.net irc.freenode.net)
  91. # [04:04] * Quits: syp| (n=syp@lasigpc9.epfl.ch) (kubrick.freenode.net irc.freenode.net)
  92. # [04:04] * Quits: mitsuhiko (n=mitsuhik@ubuntu/member/mitsuhiko) (kubrick.freenode.net irc.freenode.net)
  93. # [04:04] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (kubrick.freenode.net irc.freenode.net)
  94. # [04:04] * Joins: Hixie (n=ianh@trivini.no)
  95. # [04:04] * Joins: heycam (n=cam@210-84-9-222.dyn.iinet.net.au)
  96. # [04:04] * Joins: ianloic (i=yakk@glub.dreamhostps.com)
  97. # [04:04] * Joins: jgraham (n=jgraham@81-86-217-3.dsl.pipex.com)
  98. # [04:04] * Joins: Polar (i=polar@polar.xen.chris-lamb.co.uk)
  99. # [04:04] * Joins: YaaL (i=yaal@hell.pl)
  100. # [04:04] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  101. # [04:06] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  102. # [04:14] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  103. # [04:14] * Joins: wakaba (n=w@79.163.210.220.dy.bbexcite.jp)
  104. # [04:14] * Joins: gavins (n=gavin@firefox/developer/gavin)
  105. # [04:14] * Joins: arnath01 (n=arnath@d54C1C929.access.telenet.be)
  106. # [04:14] * Joins: mitsuhiko (n=mitsuhik@ubuntu/member/mitsuhiko)
  107. # [04:14] * Joins: Lfe (n=lfe@bergstroem.nu)
  108. # [04:14] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  109. # [04:14] * Joins: Philip` (n=philip@zaynar.demon.co.uk)
  110. # [04:14] * Joins: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp)
  111. # [04:14] * Joins: syp| (n=syp@lasigpc9.epfl.ch)
  112. # [04:20] * Quits: wakaba (n=w@79.163.210.220.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
  113. # [04:22] * Quits: jacobolus (n=jacobolu@pool-71-119-195-74.lsanca.dsl-w.verizon.net)
  114. # [04:33] * Quits: arnath01 (n=arnath@d54C1C929.access.telenet.be) (kubrick.freenode.net irc.freenode.net)
  115. # [04:33] * Quits: Philip` (n=philip@zaynar.demon.co.uk) (kubrick.freenode.net irc.freenode.net)
  116. # [04:33] * Quits: gavins (n=gavin@firefox/developer/gavin) (kubrick.freenode.net irc.freenode.net)
  117. # [04:33] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (kubrick.freenode.net irc.freenode.net)
  118. # [04:33] * Quits: syp| (n=syp@lasigpc9.epfl.ch) (kubrick.freenode.net irc.freenode.net)
  119. # [04:33] * Quits: Lfe (n=lfe@bergstroem.nu) (kubrick.freenode.net irc.freenode.net)
  120. # [04:33] * Quits: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp) (kubrick.freenode.net irc.freenode.net)
  121. # [04:33] * Quits: mitsuhiko (n=mitsuhik@ubuntu/member/mitsuhiko) (kubrick.freenode.net irc.freenode.net)
  122. # [04:33] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (kubrick.freenode.net irc.freenode.net)
  123. # [04:33] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (kubrick.freenode.net irc.freenode.net)
  124. # [04:34] * Joins: syp| (n=syp@lasigpc9.epfl.ch)
  125. # [04:34] * Joins: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp)
  126. # [04:34] * Joins: Philip` (n=philip@zaynar.demon.co.uk)
  127. # [04:34] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  128. # [04:34] * Joins: Lfe (n=lfe@bergstroem.nu)
  129. # [04:34] * Joins: mitsuhiko (n=mitsuhik@ubuntu/member/mitsuhiko)
  130. # [04:34] * Joins: arnath01 (n=arnath@d54C1C929.access.telenet.be)
  131. # [04:34] * Joins: gavins (n=gavin@firefox/developer/gavin)
  132. # [04:34] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  133. # [04:34] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  134. # [04:53] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  135. # [04:54] * Joins: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net)
  136. # [04:55] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  137. # [05:41] * Joins: dean5 (n=opera@121-72-34-68.dsl.telstraclear.net)
  138. # [05:58] * Quits: roc (n=roc@202.0.36.64)
  139. # [06:14] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  140. # [06:53] * Joins: kfish (n=conrad@61.194.21.25)
  141. # [08:01] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  142. # [08:03] * Joins: tndH (n=Rob@adsl-87-102-85-165.karoo.KCOM.COM)
  143. # [08:06] * Joins: roc (n=roc@121-72-4-108.dsl.telstraclear.net)
  144. # [08:08] <hsivonen> Hixie: is there a design reason why video src='' overrides <source>s instead of being the last resort if no <source> matches?
  145. # [08:08] * Joins: colione (n=colione@17.247.241.83.in-addr.dgcsystems.net)
  146. # [08:09] <Hixie> hsivonen: yeah, i thought it would be confusing for the test order to be different than the source order
  147. # [08:09] <Hixie> and i further thought it would look stupid for the two-codec case to have the two codecs at different indent levels and syntaxes
  148. # [08:10] <hsivonen> Hixie: it seems to me that having src='' as the last resort (if changed before any impl ships) would make the selection more resilient against partial implementations and would give a server-side sniffing point as the last resort
  149. # [08:11] <hsivonen> In particular, Anne's comments about Opera's implementation made me concerned that with the current spec a vendor shipping without <source> support would effectively poison the selection mechanism
  150. # [08:12] <Hixie> i agree with both points, but i don't think they justify the author confusion
  151. # [08:12] <othermaciej> I think it would be simplest for src to be the first resort
  152. # [08:12] <hsivonen> but if src='' were the last choice, that wouldn't be a problem
  153. # [08:12] <Hixie> now if a vendor shipped with just src="" and did poison the case, that would be a reason to change, but hopefully that won't happen
  154. # [08:13] <Hixie> <video src="3"><source src="1"><source src="2"></video> is extremely confusion imho
  155. # [08:13] <hsivonen> ok.
  156. # [08:13] <Hixie> er, my grammar sucks
  157. # [08:13] <Hixie> but you get the point
  158. # [08:13] <othermaciej> what about making the first src be the first to try? (I guess that would require video to have a type attribute if it doesn't already)
  159. # [08:14] <Hixie> that's more compelling, but i don't see why authors would want that. <video> doesn't have the attributes <source> does, and it looks weird:
  160. # [08:14] <hsivonen> part of the problem is that it's too easy to ship with semi-broken type support
  161. # [08:14] <othermaciej> It's also unfortunate that video has no good way to handle the "<video> is supported, but none of the codecs I want are available" case
  162. # [08:14] <Hixie> <video src="video.mpg">
  163. # [08:14] <Hixie> <source src="video.ogg">
  164. # [08:14] <Hixie> </video>
  165. # [08:15] <Hixie> othermaciej: i don't believe, by and large, that authors will care about that case
  166. # [08:15] <othermaciej> like say I wanted to use <video> with an Ogg source only, and otherwise fall back to a Java applet
  167. # [08:15] <Hixie> <object> use in the wild suggests that's far rarer than we would hope
  168. # [08:15] <hsivonen> I'm very pessimistic about the abilit of implementations to propertly introspec for dynamically loaded codecs
  169. # [08:15] <othermaciej> or use <video> with an H.264 source only, and otherwise fall back to a Flash or Quicktime plugin
  170. # [08:16] <Hixie> we do have events that fire if authors do want to handle that case
  171. # [08:16] <Hixie> and if it turns out to be common (which i seriously doubt) we can always support that later via some hack
  172. # [08:16] <othermaciej> I guess that's better than nothing
  173. # [08:16] <hsivonen> speaking applets, has anyone started an effort to implement <video> in IE using JS and Cortado?
  174. # [08:16] <Hixie> but i'm skeptical
  175. # [08:16] <othermaciej> what's Cortado?
  176. # [08:16] <hsivonen> othermaciej: pure Java Ogg/Theora/Vorbis player applet
  177. # [08:18] <othermaciej> thinking about video formats makes my brain hurt
  178. # [08:19] <othermaciej> but I do have the concern that if multiple browsers support <video> with different sets of codecs, per the current spec that makes life harder for authors than if only one browser supports <video>
  179. # [08:19] <othermaciej> (well, I guess it depends on how much they care about single encoding of the video vs. consistent API)
  180. # [08:19] <othermaciej> (but QuickTime offers something pretty close to the <video> API in the latest version, by design)
  181. # [08:20] <othermaciej> (and I suspect the same is doable with Flash)
  182. # [08:21] <othermaciej> anyway we'll see what happens
  183. # [08:21] <othermaciej> it's not hard to think of hacks to explicitly allow for such use
  184. # [08:23] <Hixie> if we can't get a common codec, changing the fallback rules will be the least of our problems
  185. # [08:24] <hsivonen> today embedding YouTube Flash involves pasting in magic boilerplate
  186. # [08:25] <hsivonen> it wouldn't be impossible to develop pasteable magic boilerplate that used native Ogg support in Opera and Gecko, XiphQT in Safari and Cortado in IE
  187. # [08:25] <hsivonen> far from ideal, though
  188. # [08:29] <othermaciej> not sure most web authors will do that much work to get non-browser-native support for a worse codec than Flash's non-browser-native support provides
  189. # [08:29] <othermaciej> yet another reason the codec situation sucks
  190. # [08:30] <othermaciej> (obviously some ideologically committed content providers like wikipedia would do so)
  191. # [08:30] <hsivonen> othermaciej: that depends on whether the authors are doing something that shows up on MPEG-LAs radar, I guess
  192. # [08:32] <othermaciej> fortunately still bandwidth and image formats have evolved to the point that patent-encumbered improvements are not worth it
  193. # [08:32] <othermaciej> audio could be close to that point
  194. # [08:32] <othermaciej> maybe video too someday
  195. # [08:32] <othermaciej> (withness the lack of excitement over JPEG2000)
  196. # [08:33] <othermaciej> *witness
  197. # [08:33] <Hixie> microsoft are really starting to royally piss me off with this EOT bullshit
  198. # [08:33] <othermaciej> are they still riding that horse?
  199. # [08:33] <Hixie> yet another reason to start the whatcsswg
  200. # [08:34] <hsivonen> othermaciej: not only is JPEG2000 legally undesirable, it isn't even technically competitive with the old JPEG even in the huffman form of the old JPEG when the level of compression you want is no visible artifacts
  201. # [08:34] <othermaciej> oh, I gotta read the latest bit of that thread
  202. # [08:34] <hsivonen> JPEG2000 is a win technically only if you want to compress so much that there are visible artifacts
  203. # [08:34] <othermaciej> that's sad
  204. # [08:34] <Hixie> othermaciej: i moved the thread to the public list
  205. # [08:35] <hsivonen> in that case, the artifacts of the old JPEG get more ugly faster than the JPEG2000 artifacts
  206. # [08:35] <Hixie> which i'm sure will make them so happy
  207. # [08:36] * weinig is now known as weinig|away
  208. # [08:38] <othermaciej> their latest mail on the subject in the secret list is just embarassing
  209. # [08:39] <othermaciej> I can't believe they got pwned that hard and are still trying to argue their point
  210. # [08:39] * Quits: wakaba_ (n=w@79.163.210.220.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  211. # [08:39] * Joins: wakaba (n=w@79.163.210.220.dy.bbexcite.jp)
  212. # [08:43] <hsivonen> Did Björn send his message to any public archive later?
  213. # [08:43] * Quits: wakaba (n=w@79.163.210.220.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  214. # [08:43] * Joins: wakaba (n=w@79.163.210.220.dy.bbexcite.jp)
  215. # [08:44] <MikeSmith> hsivonen - which message from Björn do you mean?
  216. # [08:44] * Quits: wakaba (n=w@79.163.210.220.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  217. # [08:44] * Joins: wakaba (n=w@79.163.210.220.dy.bbexcite.jp)
  218. # [08:45] <hsivonen> MikeSmith: http://lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0329.html
  219. # [08:45] <othermaciej> someone else could send the same information to a public list
  220. # [08:45] * Quits: wakaba (n=w@79.163.210.220.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  221. # [08:46] <othermaciej> although I'm not sure if the Microsoft request it was responsive to has been made public
  222. # [08:46] * Joins: wakaba (n=w@79.163.210.220.dy.bbexcite.jp)
  223. # [08:48] <Hixie> my new macbook pro has this weird thing where every now and then the network stalls
  224. # [08:48] <MikeSmith> so were the MS reps to the CSS WG aware of this already at the time of the face to face in Boston?
  225. # [08:48] <Hixie> just opening the wireless menu makes it work again
  226. # [08:48] <Hixie> i wonder what's up with that
  227. # [08:49] <MikeSmith> Hixie - is that when you're using a wireless connection or when you're using Ethernet?
  228. # [08:49] <Hixie> wireless
  229. # [08:50] <MikeSmith> I've not had a problem like that when using Airport, but I have when using my wireless HSDPA modem
  230. # [08:50] <MikeSmith> specifically when using Skype
  231. # [08:50] <Hixie> my mac mini hasn't ever had that as far as i know
  232. # [08:50] <Hixie> nor my powerbook
  233. # [08:50] <Hixie> but my mac book pro, and the macbook my girlfriend has, both have it
  234. # [08:52] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  235. # [08:53] <hsivonen> does anyone remember off-hand if Gecko/Opera/WebKit trim SVG enumerated-value attribute values before comparing against an internal token literal?
  236. # [08:53] <MikeSmith> Hixie - are you running Tiger on your other machines?
  237. # [08:53] <hsivonen> that is, does clip-rule=' nonzero ' work?
  238. # [08:54] <Hixie> the mac mini ran tiger then leopard, as did the macbook. the powerbook and the mac book pro are both tiger.
  239. # [08:57] <othermaciej> hsivonen: trim what? whitespace?
  240. # [08:58] <hsivonen> othermaciej: yes
  241. # [08:59] <hsivonen> this is interesting: http://lists.w3.org/Archives/Public/www-math/2007Nov/0007.html
  242. # [08:59] <othermaciej> not easy to tell from code
  243. # [08:59] <hsivonen> othermaciej: I guess I just have to write a test case or two
  244. # [08:59] <hsivonen> thanks
  245. # [09:25] * Quits: kfish (n=conrad@61.194.21.25) ("忘年会！")
  246. # [09:27] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  247. # [09:34] * Joins: zcorpan_lap (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  248. # [09:55] * dean5 is now known as dedridge
  249. # [09:58] * Quits: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  250. # [10:02] * Parts: dedridge (n=opera@121-72-34-68.dsl.telstraclear.net)
  251. # [10:03] * Quits: colione (n=colione@17.247.241.83.in-addr.dgcsystems.net)
  252. # [10:17] * Quits: zcorpan_lap (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  253. # [10:27] * Quits: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no) ("This computer has gone to sleep")
  254. # [10:43] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  255. # [10:43] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Remote closed the connection)
  256. # [10:44] * Joins: Camaban (n=adrianle@host217-41-27-233.in-addr.btopenworld.com)
  257. # [11:01] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  258. # [11:01] * Quits: spuffle (n=spuffle@cpe-74-72-192-221.nyc.res.rr.com)
  259. # [11:02] * Quits: roc (n=roc@121-72-4-108.dsl.telstraclear.net)
  260. # [11:03] * Joins: ROBOd (n=robod@89.122.216.38)
  261. # [11:23] * Joins: roc (n=roc@121-72-4-108.dsl.telstraclear.net)
  262. # [11:41] * Joins: roc_ (n=roc@121-72-4-108.dsl.telstraclear.net)
  263. # [11:41] * Quits: roc (n=roc@121-72-4-108.dsl.telstraclear.net) (Read error: 104 (Connection reset by peer))
  264. # [11:46] * Quits: ROBOd (n=robod@89.122.216.38) (Excess Flood)
  265. # [11:47] * Joins: ROBOd (n=robod@89.122.216.38)
  266. # [11:53] * Joins: annevk (n=annevk@c529c1b12.cable.wanadoo.nl)
  267. # [11:54] * othermaciej is now known as om_sleep
  268. # [11:59] * Joins: Hemebond (n=Hemebond@ip-118-90-3-92.xdsl.xnet.co.nz)
  269. # [11:59] <Hemebond> Where can I find a list of "problems" the WHATWG has with XHTML2?
  270. # [12:01] <annevk> If they are not in our FAQ I don't think we've written them up
  271. # [12:01] <annevk> Then again, the HTML5 draft does mention the relationship of HTML5 with XHTML2
  272. # [12:01] <Hemebond> Hi Anne.
  273. # [12:02] <Hemebond> I'll go have another look.
  274. # [12:02] * Quits: roc_ (n=roc@121-72-4-108.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  275. # [12:06] <Hemebond> Can't see anything in the FAQ.
  276. # [12:07] <Lachy> Hemebond, I don't believe any such list exists, but is there anything specific you would like to know about?
  277. # [12:08] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  278. # [12:08] <Hemebond> I wanted to read about the problems developers had implementing XHTML2.
  279. # [12:08] <Hemebond> I remember when I first questioned the direction of HTML5, the respondent said XHTML2 was a mess to implement.
  280. # [12:08] <Hemebond> Too many gaps.
  281. # [12:08] <Hemebond> Too much room for interpretation.
  282. # [12:09] <Lachy> yes, things are too underspecified to be implemented
  283. # [12:09] <Lachy> for instance, there is no error handling defined anywhere
  284. # [12:09] * Joins: akaroa (n=opera@121-72-6-99.dsl.telstraclear.net)
  285. # [12:09] <Hemebond> XHTML2 is still under development, no?
  286. # [12:10] <Lachy> yes
  287. # [12:11] <Hemebond> "All the browser vendors have already said they will support HTML 5 (yes, that includes MS) and all but MS have said they won't support XHTML 2"
  288. # [12:11] <Hemebond> Is that true?
  289. # [12:11] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  290. # [12:11] <Lachy> where is that quoted from?
  291. # [12:11] <Hemebond> Slashdot comment.
  292. # [12:11] <Lachy> link?
  293. # [12:12] <Hemebond> http://developers.slashdot.org/article.pl?sid=07/12/16/1656245&from=rss
  294. # [12:12] <Hemebond> http://developers.slashdot.org/comments.pl?sid=390646&cid=21718302 < actual comment
  295. # [12:12] <Hemebond> Wait... no it's not
  296. # [12:12] <Hemebond> http://developers.slashdot.org/comments.pl?sid=390646&cid=21718278 < that is
  297. # [12:12] <akaroa> It's not as simple as that Hemebond. There's a lot of politics involved.
  298. # [12:12] <om_sleep> I don't know if there are any formal promises, but all the browser vendors are involved in the HTML working group but not the XHTML2 working group
  299. # [12:12] <Hemebond> Ah politics....
  300. # [12:13] <Hemebond> How I loath thee.
  301. # [12:13] <om_sleep> and all but MS are already implementing some HTML5 features
  302. # [12:13] * om_sleep is now known as othermaciej
  303. # [12:13] <othermaciej> and most have said vaguely negative things about XHTML2 at times
  304. # [12:13] <Hemebond> And yet most haven't finished implementing the specs that are "finished".
  305. # [12:14] <annevk> so 1) XHTML2 doesn't address web applications and 2) it goes against the design principles for HTML
  306. # [12:14] <Hemebond> Design principals?
  307. # [12:14] <annevk> http://www.w3.org/TR/html-design-principles/
  308. # [12:14] <Hemebond> Cheers.
  309. # [12:14] <othermaciej> depends on what you mean by "finished implementing" and "finished spec"
  310. # [12:15] <annevk> they have been mostly "implicit" so far, but now they have a pointer :)
  311. # [12:15] <othermaciej> the latest specs that have REC status (the most mature status for a W3C spec) are CSS1, HTML4.01 and DOM2
  312. # [12:16] <othermaciej> (wait, I'm wrong, DOM 3 Core is also REC)
  313. # [12:16] <hsivonen> and HTML 4.01 shouldn't be a REC by today's requirements
  314. # [12:16] <othermaciej> non-IE browsers actually have very good support for DOM1 and DOM2
  315. # [12:16] <othermaciej> most browsers are pretty good at CSS1
  316. # [12:16] <othermaciej> HTML4.01 leaves a lot of things unspecified, so it's hard to tell if you really implemented it or not
  317. # [12:16] <hsivonen> (when some CSS1 definitions are updated per CSS2.1)
  318. # [12:17] <annevk> (by today's requirements we wouldn't have RECs, which may indicate we need something else)
  319. # [12:17] <hsivonen> indeed
  320. # [12:17] <othermaciej> I like the IETF's standards track maturity levels
  321. # [12:17] <annevk> maybe that can work
  322. # [12:18] <Lachy> I never understood the IETF maturity levels, they seemed to be quite meaningless
  323. # [12:19] <hsivonen> there's a lot of stuff that one needs to implement on the Web but that hasn't been elevated on the IETF ladder
  324. # [12:20] <othermaciej> the point is that you don't need to reach the top of the IETF ladder to be a successful spec
  325. # [12:21] <hsivonen> also, the IETF hasn't addressed Web realities e.g. the text/* encoding mess
  326. # [12:21] <Lachy> where does the IETF list the maturity levels of their specs?
  327. # [12:21] <othermaciej> ftp://ftp.rfc-editor.org/in-notes/bcp/bcp9.txt
  328. # [12:22] <Hemebond> http://www.w3.org/TR/html-design-principles/ < was this made up by the HTML5 crew or has it always been there?
  329. # [12:22] <othermaciej> Hemebond: it was created by the HTML Working Group
  330. # [12:23] <othermaciej> (edited by me and Anne)
  331. # [12:23] <Hemebond> uhuh
  332. # [12:24] <othermaciej> by IETF process, "Draft Standard" has the interoperable implementation requirement, but still leaves the possibility of changes from further implementation experience if needed
  333. # [12:24] <othermaciej> most things don't reach "Internet Standard"
  334. # [12:24] <webben> othermaciej: Not /all/ the browser vendors are involved in HTML WG.
  335. # [12:24] <webben> (Just the most famous ones.)
  336. # [12:24] <othermaciej> webben: ok, the four highest market share and best-known browser vendors, plus some others
  337. # [12:25] <hsivonen> Hemebond: if you want an older reference, there's the Opera/Mozilla Position Paper from The Workshop
  338. # [12:25] * hsivonen looks up the URI
  339. # [12:25] <hsivonen> Hemebond: http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
  340. # [12:25] <Hemebond> cheers
  341. # [12:26] <othermaciej> (browsers not involved in the WG add up to less than 0.16% market share)
  342. # [12:26] <hsivonen> Hemebond: you probably won't find any official statements about XHTML2 from browser vendors
  343. # [12:27] <hsivonen> but then, you probably won't find any official announcements to implement HTML5, either
  344. # [12:27] <Hemebond> Not really after official statements or anything. Just trying to understand the reason for avoiding XHTML2, that's all.
  345. # [12:31] <hsivonen> Hemebond: some things to consider: 1) XHTML2 involves a discontinuity: there isn't a smooth upgrade path for authors. 2) XHTML2 isn't designed to leverage the existing HTML/XHTML implementations in browsers to the extent XHTML5 is and 3) the payoff of being the first-mover to implement XHTML2 does not appear to be favorable when compared to the cost of the implementation
  346. # [12:31] <webben> Hemebond: Basically, the HTML5 draft provides a lot of additional features that developers can go right out and use today (e.g. Canvas, with JS/VML fakery in IE). XHTML 2 doesn't. So there's a lot more pressure from developers on browser vendors to implement HTML5 features.
  347. # [12:31] <webben> Hemebond: XHTML2 does have useful features that HTML5 doesn't have, but it also breaks a lot of backwards compatibility and isn't designed to degrade gracefully in the one browser that pages absolutely must work in.
  348. # [12:32] <Hemebond> You should paste all this into the FAQ or something...
  349. # [12:32] <Hemebond> FAQ-for-hemebond
  350. # [12:32] <Hemebond> .html
  351. # [12:32] <Hemebond> Thanks for that.
  352. # [12:32] <webben> So moving to XHTML 2 (from a developer perspective) would have costs that generally outweigh the gains.
  353. # [12:33] <webben> Hemebond: There are cases where XHTML 2 as currently drafted might be a better choice than HTML5. e.g. for server-side storage of documents.
  354. # [12:34] <akaroa> webben: how is that?
  355. # [12:34] <Hemebond> akaroa: transform to HTML using server-side scripting
  356. # [12:34] <Hemebond> or XSL
  357. # [12:34] <Hemebond> I've thought of using XHTML as a storage markup. Or even opendoc
  358. # [12:35] <webben> akoroa: Well, just for one example, XHTML 2 allows you to store a machine-friendly version of human-friendly data (as commonly needed for microformats) with the content attribute.
  359. # [12:35] <webben> <span content="PT3M23S">about three minutes</span>
  360. # [12:37] <webben> XHTML 2 also has more extension mechanisms like arbitrary roles and mixing in markup from other (perhaps your own) namespaces.
  361. # [12:38] <webben> Although mixing in namespaces can be done in XHTML 5 too.
  362. # [12:41] <webben> Hemebond: You might also want to look at DocBook and TEI.
  363. # [12:41] <Hemebond> Ah yeah, I meant DocBook above.
  364. # [12:41] <Hemebond> TEI is new to me though.
  365. # [12:42] <webben> http://www.tei-c.org/index.xml
  366. # [12:42] <Hemebond> Just found it. Cheers.
  367. # [12:42] <akaroa> I am still not convinced that there is a use case for XHTML2. HTML5 and XHTML5 should take care of everything right?
  368. # [12:42] <webben> akaroa: "Should" and "will" aren't the same thing. :)
  369. # [12:43] <akaroa> If not, we can still add more features to the spec
  370. # [12:44] <webben> akaroa: Well yes, both drafts could change.
  371. # [12:44] <hsivonen> having more features doesn't necessarily mean better when it comes to deciding the storage format of a back end system
  372. # [12:44] <Hemebond> or front end system
  373. # [12:44] <othermaciej> XHTML2 has decided to focus on being an authoring format
  374. # [12:45] <Camaban> The IBM article that the slashdot link referred to talked about the different philosophies of HTML5 and XHTML2, XHTML2 striving for a purer seperation, and HTML5 striving to be more readily 'practical', is that not a big issue that should be mentioned when talking about the differences between the 2?
  375. # [12:45] <Hemebond> Thanks for the info folks, will have to read up more tomorrow. Night.
  376. # [12:45] * Parts: Hemebond (n=Hemebond@ip-118-90-3-92.xdsl.xnet.co.nz)
  377. # [12:46] <othermaciej> I think HTML5 does a reasonably good job with separation of concerns
  378. # [12:46] <othermaciej> I'd state the main differences as:
  379. # [12:46] * Joins: Hemebond (n=Hemebond@ip-118-90-3-92.xdsl.xnet.co.nz)
  380. # [12:46] <othermaciej> - XHTML2 doesn't really care about compatibility with HTML4, or even XHTML1 very much
  381. # [12:46] <Hemebond> I may as well lurk here and record the discussion....
  382. # [12:46] <Hemebond> night
  383. # [12:46] <webben> Camaban: That's sort of true, although the WHATWG line has tended to be that things like <I> are just fine when it comes to separating content and presentation.
  384. # [12:47] <othermaciej> - XHTML2 is more concerned with making things really generic by moving semantics and behavior to attributes
  385. # [12:47] <webben> Hemebond: good night :)
  386. # [12:47] <Camaban> some argue the seperation point when HTML5 is wanting to not only define HTML, but the audio/video codecs used, and I believe bits to do with Bluetooth among others?
  387. # [12:47] <othermaciej> - HTML5 is interested in supporting web applications as well as web documents, XHTML2, not so much
  388. # [12:48] <Camaban> not sure where I sit on these issues, it's an area that interests me, and has me stuck on what i think of the XHTML2 Vs HTML5 thing overall
  389. # [12:48] <akaroa> It's not just about whether XHTML2 is good or not, it's about whether it can fit on to the web alongside HTML5 or not. I don't believe it can, and believe that XHTML5 should replace XHTML2
  390. # [12:49] <Camaban> othermaciej: that's a pretty fundamental difference to HTML as we know it, and I've seen suggestions that if that's the case, should it not be called soemthing else altogether?
  391. # [12:50] <othermaciej> Camaban: what's a pretty fundamental differences?
  392. # [12:50] * Camaban shrugs
  393. # [12:50] <othermaciej> er
  394. # [12:50] <othermaciej> "fundamental difference"
  395. # [12:50] <webben> Camaban: Not necessarily. Part of the issue here is that electronic document formats tend to be application formats too in all but name.
  396. # [12:50] <Camaban> othermaciej: supporting web apss as well as web docs
  397. # [12:50] <Camaban> *apps
  398. # [12:50] <othermaciej> Camaban: people write web apps in HTML today
  399. # [12:51] <othermaciej> HTML5, instead of trying to stop them, tries to make this work better
  400. # [12:51] <webben> Camaban: If you look at formats like ODF, the Office formats, PDF they all have support for dynamic forms, scripting, media formats etc
  401. # [12:51] <Camaban> but HTML4/XHTML aren't designed to be 'web app' languages, it's jsut people have worked out how to combine them with javascript and stuff to do it
  402. # [12:52] <webben> Camaban: That's not obvious.
  403. # [12:52] <hsivonen> webben: although in PDF, the dynamism is an awfully bad idea
  404. # [12:52] <othermaciej> that's true, they haven't been designed that way historically (although forms and client-side image maps are clearly app-like features)
  405. # [12:52] <webben> hsivonen: Why is it a worse idea in PDF than any of the others?
  406. # [12:52] <othermaciej> (as is support for scripting and events)
  407. # [12:53] <Camaban> If HTML5, from my limited understanding (hence I generally just lurk round here) is designed to deal with web apps specifically (as well as web pages), that's quite a philisophical difference
  408. # [12:53] <othermaciej> HTML5 tries to pave over the rough edges
  409. # [12:53] <webben> Camaban: HTML has seen shifts in philosophy before.
  410. # [12:53] <othermaciej> well, web apps like gmail, flickr, upcoming, google maps, and so forth are not going away
  411. # [12:53] <webben> Camaban: e.g. the realization that authors needed more control over suggested presentation, without compromising media independence of content.
  412. # [12:54] <Camaban> as I said, I'm unconvinced either way at the moment, I'm trying to resolve some of the for/agaisnt arguements I've seen
  413. # [12:54] <othermaciej> it seems the web is going more in that direction
  414. # [12:54] <webben> (leading to dropping loads of presentational elements and attributes in favour of CSS)
  415. # [12:54] <othermaciej> so your options are either to improve HTML, so that web apps like that fit into the web better
  416. # [12:54] <othermaciej> or you can ignore the issue
  417. # [12:54] <othermaciej> or you can invent a new, wholly different approach for web apps that is not based on HTML at all
  418. # [12:54] <hsivonen> webben: PDF (1.4) is solves the main problem it was designed to solve phenomenally good. the dynamism risks breaking what PDF is phenomenally good at
  419. # [12:55] <webben> hsivonen: Well, that's certainly been the case with HTML too. e.g. scripting and frames etc regularly breaking the usability of the web.
  420. # [12:55] <hsivonen> webben: fortunately, Adobe now has less need to use PDF as a presentation layer for dynamic apps because they have Flex
  421. # [12:56] <Camaban> othermaciej: which is what I've seen some people suggesting, maybe not wholly new, but something not called 'hypertext markup language'
  422. # [12:56] <webben> Like XUL.
  423. # [12:56] <hsivonen> s/good/well/
  424. # [12:56] <webben> or XAML.
  425. # [12:57] <webben> (or XForms to some extent.)
  426. # [12:57] <othermaciej> or Silverlight
  427. # [12:57] <othermaciej> or Java (for non-markup ways of doing it)
  428. # [12:57] <hsivonen> I wonder if there's a spec for Inkscape's private markup
  429. # [12:57] <othermaciej> or SVG
  430. # [12:57] <othermaciej> or Flex
  431. # [12:58] <hsivonen> webben: the difference is that people want to use HTML for apps. telling them otherwise is not productive
  432. # [12:59] <Camaban> maybe part of the problem is, the people who are pushing the semantic view point, using things for their intended use, rather than just using 'what works', and turning HTML into a web app language doesn't quite fit with some of that
  433. # [12:59] <webben> hsivonen: I don't think people want to use HTML for apps per se. I think people want to write apps that work in popular browsers, and HTML is the cheapest way to do that.
  434. # [12:59] <hsivonen> webben: but twisting PDF from an excellent final-form digital paper into an enterprise app UI layer was a vendor-initiated move to leverage the installed base of a product to gain foothold in a different market
  435. # [12:59] <hsivonen> webben: granted
  436. # [12:59] <annevk> is there any realistic alternative to HTML for doing web apps?
  437. # [12:59] <webben> Flash and (now) Silverlight.
  438. # [12:59] <annevk> if not then I'm not sure if this discussion is productive
  439. # [13:00] <othermaciej> Flash is the only currently realistic alternative
  440. # [13:00] <annevk> I should have said non-proprietary, of course
  441. # [13:00] <othermaciej> Silverlight may get there but does not have the deployment
  442. # [13:00] <annevk> can't have a Web that depends on a single vendor
  443. # [13:00] <othermaciej> Java is widely available but sucks really hard
  444. # [13:00] <hsivonen> webben: but while HTML and Flash make sense as app platforms from the developer POV, what developer would want to choose Adobe Intelligent Document Platform is the UI layer of an app?
  445. # [13:00] <othermaciej> I'm measuring "realistic" solely by feasibility of wide deployment for a web developer
  446. # [13:00] <Camaban> annevk: is HTML the way it *should* be done though? or is this just somehting that's happening because it seems to work?
  447. # [13:00] <webben> hsivonen: I don't know. :)
  448. # [13:01] <annevk> Camaban, I don't really see much issues with using HTML for it
  449. # [13:01] <annevk> along with CSS improvements, API improvements, etc., of course
  450. # [13:01] <webben> annevk: Well, the success of HTML5 web apps is rather dependent on MS actually implementing things. Otherwise you might as well use something like XUL.
  451. # [13:01] <othermaciej> Camaban: I dunno, can you think of a reason it shouldn't be done?
  452. # [13:01] <annevk> webben, no, XUL would be a horrible option
  453. # [13:02] <annevk> everyone, including Moz, is in agreement on that afaict
  454. # [13:02] <annevk> stuff from XUL is useful though and is making its way to HTML5 and CSS
  455. # [13:02] <Camaban> I'm slightly nervous of the idea of an HTML spec including some of the things it's looks like it's going to include, but I don't know if that's because I genuinely htink it's a bad idea, or jsut because it alters my preconceptions of what HTML is and what I 'know', it negates some of my expertise :)
  456. # [13:03] <webben> annevk: And yet there's a community of XUL developers (hence XULRunner etc..)
  457. # [13:03] * webben isn't an XUL developer, he should add.
  458. # [13:03] <othermaciej> a lot of the stuff in html5 is all about web documents, not web apps at all, particularly
  459. # [13:03] <annevk> webben, sure, there's a community of people doing Flash too
  460. # [13:04] <othermaciej> some stuff is hybird (<details> could be thought of as an app feature or for an interactive document, <video> certainly makes sense in the context of an interactive multimedia hypertext document)
  461. # [13:04] <othermaciej> some stuff is pretty web-app-oriented (AJAX history support, <canvas>)
  462. # [13:05] <akaroa> webben: I can't think of anything that can done be in Flash or silverlight that can't be done using Web Standards in the future.
  463. # [13:05] <othermaciej> I can understand being nervous about all the new stuff, but change is the one constant in the tech industry, learning to embrace it and adapt is a strength
  464. # [13:05] <Camaban> to be honest, I think some people might be pacified if it was called something like 'multimedia markup lanuage', instead :)
  465. # [13:05] <webben> SQL
  466. # [13:05] <othermaciej> akaroa: "in the future" is a pretty big out
  467. # [13:06] <webben> akaroa: Yes. But it's coping with current browsers that leads people to hack up HTML solutions.
  468. # [13:06] <annevk> Camaban, it was called Web Applications 1.0 at some point
  469. # [13:06] <othermaciej> Camaban: well, for all sorts of compatibility reasons, it has to keep text/html and application/xhtml+xml as the MIME types
  470. # [13:06] <annevk> people preferred HTML5
  471. # [13:06] <othermaciej> Camaban: and <!DOCTYPE html> as the doctype
  472. # [13:06] <webben> And they'll continue to do so until (unless) a killer app galvanizes end users to change their systems to support something else.
  473. # [13:06] <othermaciej> and use most of the tags historically defined for HTML
  474. # [13:07] <akaroa> othermaciej: I meant with the tools that we have now (CSS, SVG), but improved
  475. # [13:07] <othermaciej> so renaming it would probably be more confusing than helpful
  476. # [13:07] <Camaban> ah, that stuff I wasn't aware of
  477. # [13:07] <othermaciej> akaroa: does "improved" include adding features?
  478. # [13:08] <othermaciej> and in some cases radical performance improvements?
  479. # [13:09] <Camaban> I can see the reasons and desirability for some of the things that HTML5 is doing, I'm just struggling to be convinced that after what was shoved down our throats about XHTML --> XML being the future and all the well defined sepeartion of things etc.... that taking something of a different approach is suddenly meant to be better
  480. # [13:10] <akaroa> othermaciej: yes, adding features I guess. I'm not sure what you mean. I thought you would agree with me :)
  481. # [13:10] <webben> othermaciej: Well, there are a lot of radical performance improvements in stuff like SVG scripting (e.g. the forthcoming tamarin-based improved JS implementation in Moz.)
  482. # [13:11] <othermaciej> akaroa: I'm just saying, it's pretty open-ended to say "you'll be able to do everything in the future"
  483. # [13:11] <othermaciej> I do agree that extending web standards is good
  484. # [13:11] <othermaciej> and improving their implementations
  485. # [13:11] <akaroa> I guess I said it all wrong sorry.
  486. # [13:11] <othermaciej> webben: core JS execution is almost never the bottleneck for scripted SVG animations, in my experience
  487. # [13:12] <webben> othermaciej: What is?
  488. # [13:12] <othermaciej> DOM access, layout, painting
  489. # [13:12] <annevk> yeah, it's not so much JavaScript
  490. # [13:12] <webben> Why should DOM access be intrinsically slower than (say) manipulating Flash objects via actionscript.
  491. # [13:12] <othermaciej> (WebKit is pretty fast on scripted SVG animations, and not because our JS is way better than everyone else's)
  492. # [13:12] <othermaciej> (yet)
  493. # [13:12] <webben> Is that due to something intrinsic or just down to sluggish implementations?
  494. # [13:13] <othermaciej> webben: it doesn't need to be - I'm just saying that Tamarin won't address any of those
  495. # [13:13] <webben> oh okay
  496. # [13:13] <othermaciej> WebKit has a much faster core DOM than Gecko for instance
  497. # [13:13] <othermaciej> as does Opera
  498. # [13:14] <Philip`> JS performance hurts my per-frame lighting calculations for 3D canvas stuff in Opera, so I wouldn't mind that being faster :-)
  499. # [13:15] <othermaciej> this is a fairly good core DOM benchmark
  500. # [13:15] <othermaciej> Philip`: it's certainly worth improving!
  501. # [13:15] <othermaciej> JS performance is one of the top things I personally code on actually
  502. # [13:15] <othermaciej> but it takes a lot of different things to make an excellent web engine
  503. # [13:16] <akaroa> othermaciej: I meant we have a pretty good "web-toolbox" with what is in the (x)html5 spec now + CSS3 SVG etc.
  504. # [13:16] <Philip`> (Firefox does that particular code insanely faster, because it's running as highly optimised code on highly parallel specialised hardware, rather than as JavaScript, which is a better way to solve this problem)
  505. # [13:17] <othermaciej> yeah
  506. # [13:17] <othermaciej> in some cases the best way around JS perf bottlenecks is not to use JS at all
  507. # [13:17] <othermaciej> thus Apple's CSS animation proposal
  508. # [13:17] <othermaciej> btw this is a pretty good core DOM benchmark if anyone would like to test: http://www.hixie.ch/tests/adhoc/perf/dom/artificial/core/001.html
  509. # [13:24] * othermaciej is now known as om_sleep
  510. # [13:46] * Joins: peepo (n=Jay@host86-129-168-72.range86-129.btcentralplus.com)
  511. # [13:47] * Quits: annevk (n=annevk@c529c1b12.cable.wanadoo.nl)
  512. # [13:54] <hdh> /part
  513. # [13:55] * Parts: hdh (n=hdh@118.71.58.207)
  514. # [14:07] * Joins: ROBOd (n=robod@89.122.216.38)
  515. # [14:43] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  516. # [14:56] * Philip` hopes the URI template topic can stay on topic :-)
  517. # [14:58] * zcorpan probably should have let that email stay as a draft :|
  518. # [15:07] * Joins: phsiao (n=shawn@c-24-61-15-24.hsd1.ma.comcast.net)
  519. # [15:21] <hsivonen> RDF and XMLNS show up in the URI template thread...
  520. # [15:33] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  521. # [15:34] * Quits: peepo (n=Jay@host86-129-168-72.range86-129.btcentralplus.com) ("later")
  522. # [15:46] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  523. # [15:57] * Quits: phsiao (n=shawn@c-24-61-15-24.hsd1.ma.comcast.net)
  524. # [16:24] * Quits: jgraham_ (n=james@81-86-217-3.dsl.pipex.com) ("This computer has gone to sleep")
  525. # [16:28] * Joins: jgraham_ (n=james@81-86-217-3.dsl.pipex.com)
  526. # [16:29] * Joins: billmason (n=billmaso@ip156.unival.com)
  527. # [16:35] * Joins: phsiao (n=shawn@nat/ibm/x-a418fd68a032ed23)
  528. # [16:37] * Quits: phsiao (n=shawn@nat/ibm/x-a418fd68a032ed23) (Read error: 104 (Connection reset by peer))
  529. # [16:38] * Joins: phsiao (n=shawn@nat/ibm/x-8ba68e3d4ab72a0a)
  530. # [16:42] * Parts: akaroa (n=opera@121-72-6-99.dsl.telstraclear.net)
  531. # [16:47] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  532. # [16:58] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  533. # [17:13] * gsnedders should take a screenshot of all my mailboxes in Mail.app
  534. # [17:14] <gsnedders> but that's hard seeming there's a scrollbar
  535. # [17:14] <hsivonen> 666 messages and 1337 messages?
  536. # [17:14] <gsnedders> no
  537. # [17:15] <gsnedders> (though, according to Last.fm, I stopped listening to Queen after 1337 plays, so I kinda force myself to never listen to any of their stuff)
  538. # [17:25] * Joins: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no)
  539. # [17:36] * Joins: peepo (n=Jay@host86-129-168-72.range86-129.btcentralplus.com)
  540. # [18:10] * Quits: peepo (n=Jay@host86-129-168-72.range86-129.btcentralplus.com) ("later")
  541. # [18:26] * Quits: billmason (n=billmaso@ip156.unival.com) (Read error: 104 (Connection reset by peer))
  542. # [18:27] * Joins: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net)
  543. # [18:27] * Joins: billmason (n=billmaso@ip156.unival.com)
  544. # [18:29] * Quits: YaaL (i=yaal@hell.pl) (Remote closed the connection)
  545. # [18:29] * Joins: YaaL (i=yaal@hell.pl)
  546. # [18:54] * Quits: weinig|away (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  547. # [18:58] * Parts: Camaban (n=adrianle@host217-41-27-233.in-addr.btopenworld.com)
  548. # [19:06] <zcorpan> Hixie: do you have any idea why the annotation script doesn't work in opera?
  549. # [19:07] <zcorpan> Hixie: it says "Error: (0)."
  550. # [19:08] <zcorpan> which is
  551. # [19:08] <zcorpan> } else if ((x.status != 200) && (x.status != 304)) {
  552. # [19:08] <zcorpan> failure("Error: " + x.statusText + " (" + x.status + ")");
  553. # [19:08] <zcorpan> ...in doXMLHttpRequest()
  554. # [19:12] * Joins: parcelbrat (n=parcelbr@96.239.197.10)
  555. # [19:14] * Joins: hober (n=ted@unaffiliated/hober)
  556. # [19:28] * Joins: maikmerten (n=maikmert@Lab93.l.pppool.de)
  557. # [19:42] * Joins: weinig (n=weinig@17.203.15.140)
  558. # [19:51] * Joins: tndH_ (n=Rob@adsl-87-102-85-140.karoo.KCOM.COM)
  559. # [20:10] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  560. # [20:13] * Quits: tndH (n=Rob@adsl-87-102-85-165.karoo.KCOM.COM) (Read error: 110 (Connection timed out))
  561. # [20:31] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  562. # [20:32] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  563. # [20:33] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Client Quit)
  564. # [20:58] * Joins: Lachy_ (n=Lachlan@ti200710a340-2779.bb.online.no)
  565. # [21:07] * Quits: weinig (n=weinig@17.203.15.140)
  566. # [21:07] * Quits: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  567. # [21:09] * Quits: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no) (Read error: 110 (Connection timed out))
  568. # [21:12] * Disconnected
  569. # [21:12] * Attempting to rejoin channel #whatwg
  570. # [21:12] * Rejoined channel #whatwg
  571. # [21:12] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  572. # [21:12] * Set by Hixie on Tue Apr 03 03:10:22
  573. # [21:12] * Quits: krijnh (n=krijnhoe@ktk.xs4all.nl) (Read error: 104 (Connection reset by peer))
  574. # [21:13] * hober is now known as hober_afk
  575. # [21:14] <krijn> Damn peer
  576. # [21:20] * Philip` sees http://www.bbc.co.uk/iplayer/ is now cross-platform since it uses Flash
  577. # [21:21] <webben> where cross-platform means "more than one platform" presumably
  578. # [21:22] <Philip`> It means "not Windows Media Player"
  579. # [21:23] <Philip`> I can't tell what codec it's using, but it's going over RTMP (unlike e.g. YouTube which is HTTP (I think))
  580. # [21:23] <webben> Windows Media is probably usable on more platforms than Flash. You can run mplayer on 64-bit *nix I presume.
  581. # [21:24] <webben> but I guess they're probably using a lot of DRM or something
  582. # [21:24] <Philip`> Windows Media Player + Windows Media DRM
  583. # [21:24] <Philip`> which I guess mplayer doesn't handle so well
  584. # [21:24] <webben> probably not
  585. # [21:26] <Philip`> Looks like they're still using Windows Media for the download option (with DRM), and Flash only for streaming (which is hard to save to disk, so it has the same effect as DRM)
  586. # [21:28] <Philip`> I guess they're unlikely to use Ogg :-(
  587. # [21:29] <webben> Could one stream Ogg in a way that would make it "hard" to save?
  588. # [21:31] * Quits: hober_afk (n=ted@ip68-101-220-172.sd.sd.cox.net) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  589. # [21:32] <Philip`> I guess RTMP mostly works on the basis of being complex and undocumented, so most people won't bother writing tools to download it and to play it back
  590. # [21:32] <webben> Sounds optimistic.
  591. # [21:32] <Philip`> and the 'undocumented' bit wouldn't go down very well in the Ogg community
  592. # [21:32] <webben> Given the existence of projects like Gnash.
  593. # [21:32] <webben> (which depend on ignoring documentation of complex software for their very existence)
  594. # [21:33] <Philip`> http://osflash.org/documentation/rtmp
  595. # [21:33] <webben> heh
  596. # [21:33] <Philip`> with lots of "Fix Me!" labels
  597. # [21:35] <Philip`> It's just a pain to decode these things, and it looks like it's enough of a pain that nobody has added support for "mplayer -dumpstream rtmp://..." yet
  598. # [21:38] * Joins: zcorpan_lap (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  599. # [21:40] * zcorpan_lap is now known as zcorpan
  600. # [21:51] * Joins: roc (n=roc@202.0.36.64)
  601. # [21:53] * Quits: Lachy_ (n=Lachlan@ti200710a340-2779.bb.online.no) ("Leaving")
  602. # [21:53] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  603. # [21:55] * Quits: maikmerten (n=maikmert@Lab93.l.pppool.de) ("Leaving")
  604. # [22:07] * Joins: weinig (n=weinig@17.203.15.140)
  605. # [22:14] * Joins: Lachy (n=Lachlan@cm-84.215.41.149.getinternet.no)
  606. # [22:17] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  607. # [22:22] <Hixie> i hate how i have to hit _three_ keys to page up and down in a terminal window on mac
  608. # [22:22] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  609. # [22:22] <Hixie> (specifically a mac laptop, though even a desktop still requires two keys)
  610. # [22:24] <gsnedders> peh. it depends on the keyboard!
  611. # [22:25] <gavin_> my mac laptop requires two keys (fn+up)
  612. # [22:25] <gavin_> but I had to tweak terminal.app keymappings
  613. # [22:26] <Hixie> yeah i'm tweaking settings too
  614. # [22:26] <gsnedders> I think it's just fn+up here too
  615. # [22:26] <gsnedders> But there again I've little idea what the defaults are
  616. # [22:28] <Hixie> ok i can do it with one hand now
  617. # [22:28] <Hixie> shift-up and shift-down
  618. # [22:32] <Hixie> i don't suppose there's a way to control what double-click selection behaviour is, either?
  619. # [22:32] <Hixie> s/either/too/
  620. # [22:32] <Hixie> on putty i have it set to just select uri characters, which makes it easy to select uris
  621. # [22:32] * gavin_ doesn't know of any
  622. # [22:33] <gsnedders> Hixie: AFAIK no
  623. # [22:33] <gavin_> pre-leopard Cmd+DblCLick was "load link", not it's Cmd+Shift+DblClick
  624. # [22:33] <gavin_> *now
  625. # [22:33] <gavin_> kind of a pain
  626. # [22:33] <hsivonen> indeed
  627. # [22:34] <Hixie> yeah but that selects | characters
  628. # [22:34] <Hixie> so it doesn't work well for me either
  629. # [22:35] * Quits: Hixie (n=ianh@trivini.no) ("brb")
  630. # [22:35] * Joins: Hixie (i=ianh@trivini.no)
  631. # [22:37] * Quits: Hixie (i=ianh@trivini.no) (Client Quit)
  632. # [22:37] * Joins: Hixie (i=ianh@trivini.no)
  633. # [22:39] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (Read error: 110 (Connection timed out))
  634. # [22:40] * Quits: Hixie (i=ianh@trivini.no) (Client Quit)
  635. # [22:40] * Joins: Hixie (i=ianh@trivini.no)
  636. # [22:42] <hsivonen> Philip`: did you decrypt the overlap in interleave error with no interleave in sight?
  637. # [22:42] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) ("leaving")
  638. # [22:43] * Quits: Hixie (i=ianh@trivini.no) (Client Quit)
  639. # [22:43] * Joins: Hixie (i=ianh@trivini.no)
  640. # [22:46] * Quits: Hixie (i=ianh@trivini.no) (Client Quit)
  641. # [22:46] * Joins: Hixie (i=ianh@trivini.no)
  642. # [22:47] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  643. # [22:49] <hsivonen> interleave problem found
  644. # [22:53] <Hixie> hm?
  645. # [22:56] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  646. # [22:59] <hsivonen> Hixie: I tried to interleave rdf:RDF with *
  647. # [23:01] * Quits: gsnedders (n=gsnedder@host86-135-224-200.range86-135.btcentralplus.com)
  648. # [23:05] * Joins: dbaron_ (n=dbaron@corp-241.mountainview.mozilla.com)
  649. # [23:06] * Joins: hober (n=ted@unaffiliated/hober)
  650. # [23:18] <roc> othermaciej: "although I'm not sure if the Microsoft request it was responsive to has been made public" ... those earlier discussions never were made public (as far as I can tell), that's the problem
  651. # [23:19] <roc> This is a powerful reason why the private w3c-css-wg list needs to die.
  652. # [23:20] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
  653. # [23:23] <Hixie> hsivonen: ah, did it not work?
  654. # [23:24] <hsivonen> Hixie: it didn't since duplicate names in interleave are prohibited and * is a duplicate of everything
  655. # [23:24] <hsivonen> (this is a really annoying feature of RELAX NG)
  656. # [23:24] <Hixie> ah
  657. # [23:25] <Hixie> i don't think we want to allow RDF _anywhere_, btw
  658. # [23:25] <Hixie> <select> <rdf...> would probably not work well
  659. # [23:25] * Joins: doublec (n=doublec@203-211-82-218.ue.woosh.co.nz)
  660. # [23:25] <Hixie> same with various other cases
  661. # [23:25] <hsivonen> Hixie: I thought you said earlies that RDF was OK where metadata elements are OK, i.e. in <head>
  662. # [23:25] <Hixie> i'd recommend just allowing rdf at metadata and block/inline (soon to become "prose") entry points
  663. # [23:26] <Hixie> i may have misunderstood what you meant
  664. # [23:26] <hsivonen> I got rid of the * that was a bug
  665. # [23:26] <hsivonen> I didn't mean * quantifier. I meant the * name class
  666. # [23:27] <hsivonen> currently, I don't allow RDF on the prose level at all
  667. # [23:27] <Hixie> that works for me too
  668. # [23:27] <hsivonen> only in XHTML <head> and SVG <metadata>
  669. # [23:28] <Philip`> hsivonen: I fixed the "Error: Both operands of interleave contain text" by giving up on the RNG conversion and just using XSD
  670. # [23:28] <hsivonen> Philip`: heh
  671. # [23:29] <Philip`> (Now I've imported the XSLT schema and so the XSD->RNG converter just gives up and dies before getting that far)
  672. # [23:30] <Philip`> (Incidentally, I'm probably doing stuff stupidly since I really have no idea about any of this, but at least it seems to be working at the moment)
  673. # [23:37] <hsivonen> Hixie: FYI, http://golem.ph.utexas.edu/~distler/blog/archives/001475.html#c013846
  674. # [23:40] <Hixie> yeah, we need to figure something out
  675. # [23:40] <Hixie> the parsing issue is the biggest problem, frankly
  676. # [23:49] * Quits: parcelbrat (n=parcelbr@96.239.197.10)
  677. # Session Close: Tue Dec 18 00:00:00 2007

The end :)