/irc-logs / w3c / #html-wg / 2007-10-07 / end

Options:

  1. # Session Start: Sun Oct 07 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:05] * Joins: shepazu_ (schepers@128.30.52.30)
  4. # [00:06] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  5. # [00:35] * Joins: zcorpan_ (zcorpan@83.227.34.9)
  6. # [00:53] * Quits: Dashiva (noone@84.48.60.15) (Ping timeout)
  7. # [00:56] * Joins: Dashiva (noone@84.48.60.15)
  8. # [01:05] * Joins: heap (someone@84.39.93.17)
  9. # [01:08] * Quits: zcorpan_ (zcorpan@83.227.34.9) (Ping timeout)
  10. # [01:09] * Parts: heap (someone@84.39.93.17)
  11. # [01:16] * Quits: aroben_ (adamroben@67.160.250.192) (Quit: aroben_)
  12. # [02:00] * Quits: tH (Rob@213.249.237.231) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
  13. # [02:08] * Quits: hasather (hasather@90.227.221.48) (Quit: Lost terminal)
  14. # [02:28] * Joins: aroben_ (adamroben@67.160.250.192)
  15. # [04:50] * Quits: aroben_ (adamroben@67.160.250.192) (Quit: aroben_)
  16. # [04:58] * Joins: hyatt (hyatt@209.173.92.142)
  17. # [05:35] * Joins: Token (Token@201.27.171.251)
  18. # [05:55] * Joins: timbl (timbl@146.115.66.146)
  19. # [06:35] * Quits: Token (Token@201.27.171.251) (Quit: Bin Laden uses The 7 Deadly Sins... Shouldn't you?   [www.t7ds.com.br])
  20. # [08:03] * Joins: aroben_ (adamroben@67.160.250.192)
  21. # [08:22] * Quits: Bob_le_Pointu (blp@80.248.208.232) (Ping timeout)
  22. # [08:28] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
  23. # [08:28] * Joins: Bob_le_Pointu (blp@80.248.208.232)
  24. # [09:31] * Joins: zcorpan_ (zcorpan@83.227.34.9)
  25. # [09:45] * Joins: ROBOd (robod@89.122.216.38)
  26. # [09:58] * Joins: heycam (cam@203.214.114.92)
  27. # [10:09] * Quits: zcorpan_ (zcorpan@83.227.34.9) (Ping timeout)
  28. # [10:28] * Joins: tH (Rob@213.249.237.231)
  29. # [10:37] * Quits: tH (Rob@213.249.237.231) (Ping timeout)
  30. # [10:42] * Joins: tH (Rob@213.249.237.231)
  31. # [10:43] * Quits: aroben_ (adamroben@67.160.250.192) (Quit: aroben_)
  32. # [12:14] * Joins: jmb (jmb@152.78.71.152)
  33. # [12:35] * Quits: gsnedders (gsnedders@86.137.237.196) (Ping timeout)
  34. # [12:35] * Joins: gsnedders (gsnedders@86.137.237.196)
  35. # [13:24] * Joins: hasather (hasather@90.227.221.48)
  36. # [14:09] * Quits: ROBOd (robod@89.122.216.38) (Ping timeout)
  37. # [14:11] * Joins: ROBOd (robod@89.122.216.38)
  38. # [14:18] * Quits: gsnedders (gsnedders@86.137.237.196) (Quit: gsnedders)
  39. # [14:21] * Joins: gsnedders (gsnedders@86.137.237.196)
  40. # [14:44] * Joins: myakura (myakura@124.84.146.88)
  41. # [14:49] <anne> So where's the proposal for <switch> and <case>? http://www.redcanary.ca/view/top-programming
  42. # [15:44] * Joins: Sander (svl@86.87.68.167)
  43. # [15:59] * Joins: tH_ (Rob@87.102.7.125)
  44. # [15:59] * Quits: tH (Rob@213.249.237.231) (Ping timeout)
  45. # [15:59] * tH_ is now known as tH
  46. # [16:00] * Quits: drry (drry@222.225.140.32) (Quit: drry)
  47. # [16:01] * Joins: drry (drry@222.225.140.32)
  48. # [16:25] * Quits: myakura (myakura@124.84.146.88) (Quit: Leaving...)
  49. # [17:07] * Joins: icaaq (icaaaq@85.228.54.71)
  50. # [17:37] * Quits: gsnedders (gsnedders@86.137.237.196) (Quit: 404: Not Found)
  51. # [18:41] * Quits: heycam (cam@203.214.114.92) (Ping timeout)
  52. # [19:04] * Joins: gsnedders (gsnedders@86.137.237.196)
  53. # [19:07] * Quits: shepazu_ (schepers@128.30.52.30) (Ping timeout)
  54. # [19:09] * Joins: shepazu (schepers@128.30.52.30)
  55. # [19:26] * Quits: icaaq (icaaaq@85.228.54.71) (Ping timeout)
  56. # [19:47] <jgraham> html5lib 0.10 (python) is now all packaged up and available for download
  57. # [20:55] <anne> cool
  58. # [21:02] <anne> jgraham, did you make a changelog as well?
  59. # [21:03] * anne looks
  60. # [21:06] * Joins: zcorpan_ (zcorpan@83.227.34.9)
  61. # [21:12] * Joins: aroben_ (adamroben@67.160.250.192)
  62. # [21:20] * anne closed http://code.google.com/p/html5lib/issues/detail?id=50
  63. # [21:22] <anne> also, didn't markp fix http://code.google.com/p/html5lib/issues/detail?id=17 jgraham?
  64. # [21:22] * anne closes that one too
  65. # [21:37] <zcorpan_> haha, copyright issues. i've been playing a game to see how long i could ignore copyrights for my stuff
  66. # [21:38] <zcorpan_> i guess it's about time
  67. # [21:39] <zcorpan_> or patent policy
  68. # [21:41] <zcorpan_> hmm, is it possible to move a local svn repo to somewhere online so people can get diffs?
  69. # [21:43] * Joins: hendry (hendry@89.16.172.32)
  70. # [21:47] <anne> zcorpan_, I'm not really sure what the big problem is; Opera signed the PP, you agreed to it; you e-mailed the proposal to a WG Opera is a member of...
  71. # [21:50] <zcorpan_> right
  72. # [21:51] <anne> what he wrote seems like a lot of fluffy text without substance
  73. # [21:51] <anne> which is annoying as he said he would like to help speed things up
  74. # [21:53] <zcorpan_> shepazu: hi
  75. # [22:00] <anne> http://weblogs.mozillazine.org/roc/archives/2007/10/changing_horses.html is interesting
  76. # [22:05] <jgraham> anne: I lost track of all the changes so it would be inaccurate. I will make a blog.whatwg.org post about the release at some point (maybe tomorrow) though
  77. # [22:06] <jgraham> talking about the fetures
  78. # [22:06] <jgraham> s/fetures/features/
  79. # [22:06] * Quits: zcorpan_ (zcorpan@83.227.34.9) (Connection reset by peer)
  80. # [22:14] * Quits: aroben_ (adamroben@67.160.250.192) (Quit: aroben_)
  81. # [22:30] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  82. # [22:40] <shepazu> anne, did you even read my email?
  83. # [22:42] * Joins: mjs (mjs@141.154.164.153)
  84. # [22:43] <shepazu> that "fluffy text" pointed out at least 2 incompatibilities to the original Role spec, and pointed out why it might be a bad idea to use chameleon namespaces to do what he was proposing, and explained why it was a bad idea not to cc the groups who own the specs he's touching
  85. # [22:44] <shepazu> which seems to be lost on you, I suppose
  86. # [22:44] <shepazu> which is annoying
  87. # [22:45] * Joins: aroben_ (adamroben@67.160.250.192)
  88. # [22:48] <anne> dunno, that and more has already been admitted on the public-html list and other places involved in the role= discussion
  89. # [22:49] <shepazu> I wasn't following that
  90. # [22:51] <shepazu> I am trying to help it move along, obviously, or I wouldn't be trying to reconcile his spec to the Role spec, which is the only way SVG will be able to include it
  91. # [22:51] <shepazu> or is that too fluffy for you?
  92. # [22:52] <mjs> see, this is why it would be better to have an approach to add-on accessibility markup than using the role attribute
  93. # [22:52] <mjs> it would avoid the need to debate issues of spec purity
  94. # [22:52] <shepazu> give me a break
  95. # [22:52] <shepazu> it's not spec purity
  96. # [22:52] <anne> it is
  97. # [22:52] <mjs> XHTML2 is a matter of purely theoretical concern
  98. # [22:53] <mjs> accessibility for web apps built out of div soup is a pragmatic real-world concern
  99. # [22:53] <mjs> I think it might be too late to avoid mixing the two though
  100. # [22:53] <shepazu> please, the Role spec is only peripherally related to XHTML2
  101. # [22:53] <shepazu> it has no inherent dependancies on language
  102. # [22:54] <anne> s/XHTML2/The XHTML2 WG/, if you wish
  103. # [22:54] <mjs> didn't your email about it refer to it as the "XHTML2 Role Attribute Module"?
  104. # [22:54] <shepazu> the reason to have it as its own spec is so that X/HTML and SVG can use it without having to modify both languages if that spec changes
  105. # [22:54] <shepazu> because that's the WG that wrote
  106. # [22:54] <shepazu> it
  107. # [22:55] <shepazu> and the label serves to distinguish between the 2 specs
  108. # [22:55] <shepazu> (simon's and the one by the xhtml2 group)
  109. # [22:55] <anne> also, I'm not sure why you mention chameleon namespaces, they have nothing to do with this
  110. # [22:56] <mjs> yes, and zcorpan is trying to pare down the excessive amounts of theoretical purity in it
  111. # [22:56] <shepazu> talk about theoretical purity, these arguments are full of it
  112. # [22:56] <shepazu> "It's from the XHTML2 WG, it must be bad!"
  113. # [22:56] <mjs> I do agree that in general it would be nice to have a shared way to develop markup and API to be shared by multiple languages
  114. # [22:57] <anne> indeed, the whole point is to simplify the role module and also restrict it to usage of ARIA so that we don't get another <object>
  115. # [22:58] <shepazu> anne, chameleon ns are absolutely part of the problem
  116. # [22:58] <anne> nope
  117. # [22:58] <shepazu> and restricting its usefulness is your agenda, not necessarily the best idea
  118. # [22:59] <anne> based on history it certainly seems better than the alternative
  119. # [22:59] <shepazu> explain how they aren't... I've already explained how they are
  120. # [22:59] <anne> you haven't
  121. # [22:59] <shepazu> then you didn't read my email
  122. # [23:00] <anne> it's problematic if <a:b> and <x:b> are identical (where a and b are bound to different namespaces) it's not problematic that you can use id="" in both HTML and SVG
  123. # [23:00] <shepazu> what if, down the line, SVG decides to put interfaces on @role, and the HTML spec doesn't
  124. # [23:01] <anne> you'd coordinate stuff like that, but afaict the whole point of ARIA role= is to not have APIs
  125. # [23:01] <mjs> markup languages intended to be rendered for interactive display have a lot of things in common beyond general XML
  126. # [23:01] <mjs> for example, the desire for focus APIs, the class attribute, the style attribute, etc
  127. # [23:01] <mjs> it would be nice to have a real way to share those instead of ad-hoc
  128. # [23:02] <mjs> for instance, HTML5 classList is way awesome and would be great for SVG
  129. # [23:02] <shepazu> oh, "you'd coordinate"... because that always goes seamlessly
  130. # [23:03] <mjs> I'd agree that attributes in the null namespace on elements in different namespaces are not an instance of chameleon namespaces in the classic sense
  131. # [23:03] <anne> it does indeed seem better to not coordinate and have them work in completely different ways depending on what namespace the element you use it on is in
  132. # [23:03] <mjs> but it is annoying when such things are specced twice for different languages and the specs come out slightly different
  133. # [23:03] <shepazu> I'm all for pulling in some features from HTML5 into SVG, but it would be even easier if they were done independently
  134. # [23:03] <anne> great for the authors!
  135. # [23:04] <anne> (and implementors)
  136. # [23:04] <anne> might help spec writers in the short term
  137. # [23:04] <shepazu> I agree that it doesn't make sense that attributes on an element are not automatically in that element's ns
  138. # [23:05] <anne> hmm, i once thought that too, but I no longer agree with that sentiment
  139. # [23:05] <shepazu> that never made sense to me, and I suspect it's unintuitive in general
  140. # [23:05] <shepazu> isn't that what you just said?
  141. # [23:05] <shepazu> (effectively)
  142. # [23:05] <mjs> is anything about namespaces that *is* intuitive?
  143. # [23:06] <anne> shepazu, huh?
  144. # [23:06] <anne> mjs, good point
  145. # [23:06] <shepazu> good point? bon mot, at best
  146. # [23:07] <shepazu> if @foo works differently in <bar:a> and <baz:a>, it's adhering to that element's ns.... oh, wait
  147. # [23:07] <mjs> I'm saying that your criticism of attributes with no namespace prefix being in the null namespace instead of the element namespace seems ill-founded, but I think that point is pretty tangentially related to this discussion anyway
  148. # [23:07] * Joins: zcorpan_ (zcorpan@83.227.34.9)
  149. # [23:07] <shepazu> I think you mean that @foo should works differently in the context of <bar:a> and <bar:b>
  150. # [23:08] <shepazu> (which I think would be confusing)
  151. # [23:08] <anne> i think you're confused
  152. # [23:08] <shepazu> or you're not explaining your position well
  153. # [23:08] <anne> i made a sarcastic remark in reply to your 'oh, "you'd coordinate"... ..."
  154. # [23:09] <shepazu> I took you seriously, because it's no crazier than other things I've heard you say ;)
  155. # [23:10] * anne shrugs
  156. # [23:13] <mjs> <span role="sarcasm">...
  157. # [23:13] <mjs> oh wait I forgot to declare my namespaces
  158. # [23:14] <shepazu> that's a serious question I brought up in the SVG WG, actually...
  159. # [23:15] <mjs> what is?
  160. # [23:15] <shepazu> what if an a blog author, who has little or no control over ns declarations in the document root, tries to use some inline SVG?
  161. # [23:16] <anne> <div><svg xmlns="..."> ...
  162. # [23:16] <shepazu> it should work okay if they do all the namespaces in the SVG itself (maybe), but what if they try a shortcut like <svg:circle/> with no root?
  163. # [23:17] <mjs> SVG elements can't really work outside an <svg> element
  164. # [23:17] <mjs> best practice would be to declare all relevant namespaces on the <svg> element
  165. # [23:17] <mjs> (that might include svg as default namespace plus xlink and maybe others I am forgetting)
  166. # [23:18] <anne> (SVG in HTML should not require any namespaces I think, btw)
  167. # [23:18] <mjs> so many things in SVG reference the root svg element that I don't think you can meaningfully define how to render <div><svg:circle .../></div> even with the right namespace declarations
  168. # [23:19] <mjs> anne: I thought about it a bit - you could treat <svg> in classic HTML syntax as declaring an implied SVG default namespace, but what do you do for attributes in the xlink namespace?
  169. # [23:20] <shepazu> I was wondering if maybe we could allow for a sort of virtual expansion, an implicit <svg> root... hadn't gone much beyond that inital question
  170. # [23:20] <shepazu> not sure if it would be significantly easier for authors or not
  171. # [23:21] <shepazu> it's implied in the HTML5 draft that that should be legal, so I thought we'd look into the idea
  172. # [23:22] <shepazu> mjs: you could also add xlink as a default ns
  173. # [23:23] <shepazu> it's a pity that XLink never really went further... as it is, SVG would do just as well with @a in the null NS
  174. # [23:24] <mjs> I'm not so fond of SVG's use of xlink:href, it seems kind of gratuitous and furthermore is not even compatible with the real XLink spec afaict
  175. # [23:24] <mjs> I think it would have been better to use href for links and src for embedding/inclusion
  176. # [23:26] <zcorpan_> it might make sense to introduce href/src when (if) svg would be allowed in text/html
  177. # [23:26] <shepazu> I don't know of any incompatibilities with xlink1.1 (not saying there aren't any), and while it was a good idea at the time, it didn't play out as expected
  178. # [23:26] <mjs> hi zcorpan_!
  179. # [23:26] <zcorpan_> hi mjs
  180. # [23:26] <shepazu> hi, zcorpan_
  181. # [23:26] <zcorpan_> hi shepazu
  182. # [23:27] <shepazu> zcorpan_, that wouldn't validate as is, and would lead to inconsistent content to do the same thing... but it could be reconsidered... I don't feel strongly about it, but I would like to make authors' lives easier
  183. # [23:28] <shepazu> the truth is, the way SVG uses XLink is not really compelling
  184. # [23:28] <shepazu> as far as I can see
  185. # [23:29] <zcorpan_> in particular it would mean that we don't need to do namespace lookup or make ugly hacks in the html parser
  186. # [23:29] <anne> mjs, I think at some point SVG needs to introduce href="" besides xlink:href=""
  187. # [23:30] <shepazu> I think the fear of namespaces is overblown... my *gf* understands them, and she barely does any markup or scripting at all
  188. # [23:31] <shepazu> mjs, you are technically on the SVG WG, if you're interested in these things, you could bring them up
  189. # [23:31] <anne> mjs, you can do that for the HTML variant I think
  190. # [23:31] <shepazu> HTML variant of what?
  191. # [23:31] <anne> well, SVG syntax in HTML
  192. # [23:32] <shepazu> excuse me?
  193. # [23:32] <anne> an idea that people have
  194. # [23:32] <zcorpan_> make svg work in text/html
  195. # [23:32] <shepazu> it clearly says in HTML5 that SVG is defined by the SVG spec, not by the HTML spec
  196. # [23:33] * Quits: mjs (mjs@141.154.164.153) (Ping timeout)
  197. # [23:33] <zcorpan_> it would still be, even if it was made to work in text/html
  198. # [23:33] <anne> well, the syntax for SVG in HTML would have to be part of the HTML parser algorithm
  199. # [23:33] <zcorpan_> it's just the text/html parsing that would change
  200. # [23:33] <anne> that doesn't really affect SVG implementations in any way
  201. # [23:33] <shepazu> oh is that all?
  202. # [23:33] * Quits: aroben_ (adamroben@67.160.250.192) (Quit: aroben_)
  203. # [23:33] <anne> did i suggest anything else?
  204. # [23:34] <zcorpan_> well, introducing a new attribute (href="") would make it simpler
  205. # [23:34] <shepazu> see, that's where it starts
  206. # [23:34] <shepazu> why does the HTML5 group think they need to control everything on the web?
  207. # [23:35] <zcorpan_> i don't think anything more is needed
  208. # [23:35] <zcorpan_> ?
  209. # [23:35] <shepazu> I feel confident that if HTML started changing "just what is needed" about SVG, they would continue on from there
  210. # [23:36] <zcorpan_> ok
  211. # [23:36] <shepazu> I think that if you want to change anything about SVG, you should approach the SVG WG abot it first
  212. # [23:36] <shepazu> including the parsing
  213. # [23:36] <zcorpan_> sure
  214. # [23:36] <shepazu> because SVG is an XML syntax, not an HTML5 syntax
  215. # [23:36] <Dashiva> The amount of changes from approaching other working groups has been so encouraging, after all :)
  216. # [23:37] <zcorpan_> shepazu: that's not really relevant
  217. # [23:37] <zcorpan_> shepazu: parsing xml gives you a DOM
  218. # [23:37] <zcorpan_> shepazu: parsing text/html also gives you a DOM
  219. # [23:37] <shepazu> perhaps if they had been approached in a moderately polite manner, you might have had different results, Dashiva
  220. # [23:38] <shepazu> zcorpan_, I'm not saying we'd shut it down... I'm saying we'd want to be involved
  221. # [23:38] <anne> SVG is a DOM spec
  222. # [23:38] <anne> XML is just one way to get there
  223. # [23:38] <anne> you can already create SVG using APIs...
  224. # [23:39] <zcorpan_> shepazu: i didn't suggest otherwise :)
  225. # [23:39] <anne> I told this the CDF people ages ago: http://annevankesteren.nl/test/cdf/cdi/002.html
  226. # [23:39] <anne> (where ages is roughly two years, it seems)
  227. # [23:39] <shepazu> CDF hasn't been nearly as communicative to SVG as they might have been, I think
  228. # [23:40] <shepazu> even with some overlap in membership
  229. # [23:40] <anne> to be honest, it seems that most "CDF issues" are solved outside CDF
  230. # [23:41] <shepazu> that's part of what CDF should be doing... getting other specs to coordinate and change on their own
  231. # [23:41] <shepazu> and they have done that
  232. # [23:41] <anne> (I'm not sure how you arrive at your conclusions about the HTML5 group above.)
  233. # [23:41] <anne> (fwiw)
  234. # [23:42] <shepazu> perhaps you are simply too focused on HTML5, then, anne
  235. # [23:43] * anne shrugs
  236. # [23:43] * anne goes back to debugging his Python webserver
  237. # [23:43] <shepazu> the HTML5 group has managed to alienate almost every other group that's approached it
  238. # [23:43] <shepazu> I think that's a serious failure of the WHATML WG
  239. # [23:46] <anne> I'm not sure what you're getting at, to be honest
  240. # [23:47] <anne> Although your suggestions to help improve things are welcome at various mailing lists, I'm sure
  241. # [23:47] <shepazu> to be honest, I think you're being disingenuous
  242. # [23:52] <anne> afaict the HTML WG hasn't made a single language decision yet, ask DanC
  243. # [23:53] <shepazu> decsions are being made, because the spec has a current state
  244. # [23:53] <anne> there have been some clashes html4all guys, but it seems that's going better nowadays
  245. # [23:53] <shepazu> regardless of whether that's the official W3C spec, it's serving as the basis for implementations
  246. # [23:54] <shepazu> which is introducing a strong bias
  247. # [23:54] <anne> well, it seems better that we implement that than something we made up ourselves if we want to help authors
  248. # [23:54] <shepazu> then don't pretend no decisions have been made, anne
  249. # [23:54] <anne> that was the whole point of the WHATWG, to clarify things among implementors because nobody else did it for us
  250. # [23:55] <anne> shepazu, the decisions that have been made are in the charter, which calls for backcompat
  251. # [23:55] <shepazu> anne, don't try your jive on me
  252. # [23:56] <anne> it's not a jive, it was tried first at the W3C but that proposal was turned down
  253. # [23:56] <shepazu> yeah, that was a mistake, I agree
  254. # [23:57] <shepazu> I was even there :(
  255. # [23:57] <shepazu> I don't think I was aware of all the implications at the time, which I regret
  256. # [23:57] <anne> I'm not sure if we could've made as much progress within the W3C in such a short time frame, but yeah...
  257. # [23:58] <shepazu> I think it was a sound technological decision, but a faulty market one
  258. # [23:59] <zcorpan_> shepazu: i'm not sure what to reply to your question about patent policy
  259. # [23:59] <anne> hmm, everyone's implementation of HTTP methods for XMLHttpRequest is annoying
  260. # Session Close: Mon Oct 08 00:00:00 2007

The end :)