/irc-logs / w3c / #html-wg / 2007-12-18 / end

Options:

  1. # Session Start: Tue Dec 18 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:00] <Philip> (http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/index#parse-errors - 30% of pages make that mistake)
  4. # [00:00] <Philip> (which is, like, quite a lot)
  5. # [00:00] <Yudai> and... many servers doesnt support ";", so the browsers cannot use ";".
  6. # [00:01] <Philip> Servers can easily support both, and could have done so last century, and everyone writing HTML could use the ; form, regardless of what browsers submit
  7. # [00:04] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
  8. # [00:05] * Joins: billmason (billmason@69.30.57.156)
  9. # [00:07] * Joins: kingryan (kingryan@66.92.219.50)
  10. # [00:08] <anne> Philip, that would go against copy & paste of URIs though
  11. # [00:09] <Yudai> Philip: Yes. But the browsers cannot change their splitter to ";" if there is even one server that is not support ";"
  12. # [00:11] <Yudai> so "&" will be used as the "default" splitter forever
  13. # [00:12] <Philip> anne: I wouldn't expect many people to copy;paste from the browser's address bar after submitting a GET form, into a link in an HTML page - that doesn't sound very common, compared to manually writing print "<a href=\"foo.cgi?action=bar&id=$id\">" in which case it's just as easy to use ; instead
  14. # [00:12] <anne> I do it all the time for blog entries at least
  15. # [00:15] <Philip> Hmph, it's no fair if you argue from experience
  16. # [00:24] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  17. # [00:26] <Yudai> yeah. but it's very difficult to change historical default thing, i think
  18. # [00:27] <Yudai> the backward compatibility is very important in such a large world like the web
  19. # [00:28] <Philip> I'm not suggesting that browsers change their use of & in form submission - I'm just suggesting that the rest of the world changes their servers and then changes their references to pages on their servers, since those changes can be done incrementally without breaking things
  20. # [00:29] * Quits: tH (Rob@87.102.85.140) (Quit: ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508])
  21. # [00:30] <Yudai> I see. hmm I think it's a good thing to more suggest to use ";" on W3C specs
  22. # [00:31] <Philip> I think we need a Semicolon Task Force
  23. # [00:32] <Yudai> but it's a issue of "URI", I think
  24. # [00:33] <Yudai> because, as you know, many other specs are using GET URIs
  25. # [00:35] <Yudai> creating the Task Force may be a good idea, I think
  26. # [00:38] <Yudai> (btw, I'm sorry. I'm not good at writing English :( )
  27. # [00:38] * Philip tries to think of further compelling arguments, other than "&s are fat"
  28. # [00:42] <Yudai> perhaps "&" is not so bad... except xml parsing error
  29. # [00:46] <Philip> I agree with that
  30. # [00:47] <Philip> but the parsing error / escaping issue is quite significant in practice
  31. # [00:52] <Yudai> yes
  32. # [00:56] <Yudai> problem is that there are many people who dont know thare are easyer way to split arguments than escape to "&amp;"
  33. # [00:57] <Yudai> oops, i have to go to school
  34. # [01:20] * Joins: akaroa (opera@121.72.6.99)
  35. # [01:21] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
  36. # [01:48] * Parts: akaroa (opera@121.72.6.99)
  37. # [01:49] * Joins: akaroa (opera@121.72.6.99)
  38. # [01:50] * Parts: akaroa (opera@121.72.6.99)
  39. # [01:53] * Joins: dean (opera@121.72.6.99)
  40. # [01:54] * Quits: timbl (timbl@128.30.5.98) (Quit: timbl)
  41. # [02:04] * Joins: sbuluf (efhmnfh@200.49.132.113)
  42. # [02:18] * Parts: dean (opera@121.72.6.99)
  43. # [02:34] <MikeSmith> Hixie - what was the rationale for dropping rev? lack of critical mass of it in existing content?
  44. # [02:36] <MikeSmith> main use was just rev=made, I guess
  45. # [02:40] <Philip> MikeSmith: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012975.html
  46. # [02:41] * Quits: kingryan (kingryan@66.92.219.50) (Ping timeout)
  47. # [02:42] <Hixie> yeah that pretty much summarises the problem
  48. # [02:43] <MikeSmith> Philip - thanks
  49. # [02:48] <Philip> MikeSmith: See also http://www.cl.cam.ac.uk/~pjt47/misc/attributes.html (mainly under "link rev (number of pages)") for an independent indication that Hixie isn't just making up all these numbers so they support his points :-)
  50. # [02:50] <Hixie> hehe
  51. # [02:50] * Facedown can't believe he's in the same channel as Hixie and anne.
  52. # [02:51] <Hixie> Facedown: i'm in many channels :-)
  53. # [02:51] <MikeSmith> Philip - there are some gems in that report.. link@rev="New Kadampa Tradition"
  54. # [02:54] <Philip> http://www.kadampanewyork.org/ - <link rev="New Kadampa Tradition" href="http://www.kadampa.org" title="Home site of New Kadampa Buddhism" />
  55. # [03:10] * Joins: kingryan (kingryan@66.92.2.56)
  56. # [03:12] * Quits: adele (adele@17.255.110.63) (Quit: adele)
  57. # [03:14] * Joins: timbl (timbl@209.6.134.246)
  58. # [04:14] * Quits: timbl (timbl@209.6.134.246) (Ping timeout)
  59. # [04:15] * Quits: kingryan (kingryan@66.92.2.56) (Quit: kingryan)
  60. # [04:19] * Joins: adele (adele@67.170.232.64)
  61. # [05:28] * Quits: dbaron_ (dbaron@63.245.220.241) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  62. # [05:48] <MikeSmith> Hixie - so do have any thoughts on CURIE values in rel attributes?
  63. # [06:00] <Hixie> i have various thoughts on CURIEs in general
  64. # [06:00] <Hixie> but they mostly can be summed up as: o_O
  65. # [06:06] <mjs> CURIEs are just a short way of writing a URL, right?
  66. # [06:06] <mjs> why would you want a URL as a rel value?
  67. # [06:07] <Hixie> to make this more complicated, presumably
  68. # [06:07] <Hixie> (i assume their reasoning is that uris are the best way to avoid name clashes)
  69. # [06:09] <MikeSmith> mjs - The main use case I'm aware of is for RDFa
  70. # [06:09] <MikeSmith> http://www.w3.org/TR/rdfa-syntax/#sec_3.3.
  71. # [06:10] <MikeSmith> "URIs are most commonly used to identify web pages, but RDF makes use of them as a way to provide unique identifiers for concepts."
  72. # [06:12] <Hixie> i wonder how long it'll take for people to realise RDF was DOA as far as the wider Web community was concerned
  73. # [06:17] * Joins: billyjack (MikeSmith@mcclure.w3.org)
  74. # [06:17] * Quits: billyjack (MikeSmith@mcclure.w3.org) (Client exited)
  75. # [06:17] * Joins: marcos (chatzilla@131.181.148.226)
  76. # [06:18] * Quits: Shunsuke (Shunsuke@123.176.107.50) (Ping timeout)
  77. # [06:20] * Joins: dbaron (dbaron@71.204.145.103)
  78. # [06:43] <MikeSmith> Hixie - so setting CURIEs aside for a minute, what about the general idea of allowing rel values of the form foo:bar, with a statement that such values are expected to be defined/registered elsewhere (that is, not in the HTML5 spec, not on the Wiki page)?
  79. # [06:44] <MikeSmith> similar to the way in which BCP specifies handling of scheme names
  80. # [06:45] <MikeSmith> except of course that the distinguishing character is a colon instead of a dash
  81. # [06:48] * Joins: Shunsuke (Shunsuke@123.176.107.50)
  82. # [06:58] <Hixie> MikeSmith: colons are already allowed
  83. # [06:58] <Hixie> MikeSmith: and if someone wants to propose a whole range of values, i don't see any reason why they couldn't do that
  84. # [06:59] <MikeSmith> Hixie - OK. but each would need to entered separately on the Wiki page, right?
  85. # [06:59] <Hixie> (of course, there's a good chance that whatever community gets set up to approve/discard the values might discard the range)
  86. # [06:59] <Hixie> MikeSmith: i don't see any reason why a whole range of values couldn't be registered with one row, assuming there are documents explaining the values somewhere
  87. # [07:00] <MikeSmith> OK
  88. # [07:01] <Hixie> how many values are we talking about here?
  89. # [07:05] <MikeSmith> Hixie - I don't know. But I think it could be a relatively large set.
  90. # [07:05] <Hixie> seems unlikely that there would be that many values to add
  91. # [07:05] <Hixie> i mean, how many link relationships can possibly have value to users?
  92. # [07:08] <MikeSmith> Hixie - I think that the set of values that general users would need it probably small, on the order of that in the current enumerated values in the spec and the Wiki
  93. # [07:08] <Hixie> ah well we presumably wouldn't want to allow other values
  94. # [07:10] <MikeSmith> as far as what the others are, looking at the XHTML+RDFa spec, I see examples of foaf: and dc: ... dc:source, dc:creator, etc., and foaf:knows, foaf:depiction and such
  95. # [07:11] <MikeSmith> anyway, one thing that argues against this to me is that there is value in keeping the set of rel values in the core language as small as possible
  96. # [07:12] <MikeSmith> because among other things, that enables editing applications to the present it to users as a relatively small enumerated list
  97. # [07:13] <MikeSmith> and prevents them from entering values that just don't make any sense (because of a misunderstanding of the purpose of rel or whatever)
  98. # [07:38] <Hixie> well i don't think we really should use RDFa as a guide to what to do for HTML5
  99. # [07:39] <Hixie> i mean, RDFa doesn't really follow our design principles
  100. # [07:40] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  101. # [07:45] * Quits: jmb (jmb@152.78.68.189) (Ping timeout)
  102. # [07:47] * Joins: jmb (jmb@152.78.68.189)
  103. # [07:54] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  104. # [07:54] <Hixie> 07:38 < Hixie> well i don't think we really should use RDFa as a guide to what to do for HTML5
  105. # [07:54] <Hixie> 07:38 < Hixie> i mean, RDFa doesn't really follow our design principles
  106. # [07:54] <Hixie> MikeSmith: ^
  107. # [07:54] <Hixie> (you left as i typed it)
  108. # [07:55] <MikeSmith> Hixie - thanks
  109. # [07:56] <mjs> using : prefixes for sets of values is cute
  110. # [07:56] <mjs> but if you can reassign what prefix means what, it creates problems
  111. # [07:56] <mjs> unless DOM APIs understand how to canonicalize
  112. # [07:56] <mjs> and can preserve semantics when moving values around the tree
  113. # [07:56] <Hixie> ew, we definitely don't want to allow prefixes to be mapped on the fly, that's a disaster waiting to happen
  114. # [07:57] <mjs> I don't know if CURIEs share that problem with XML namespaces
  115. # [07:57] <MikeSmith> mjs - I think they do, for applications that are aware of them and process them
  116. # [07:58] <MikeSmith> My understanding is that they are QNames without some syntactic limitations of QNames
  117. # [07:58] <mjs> what defines CURIE prefixes?
  118. # [07:58] <mjs> CURIEs map to a URI
  119. # [07:58] <mjs> not a (URI, localname) pair
  120. # [07:59] <MikeSmith> mjs - I'm not sure, but I think they require a namespace declaration in the document, just as QNames
  121. # [08:00] <MikeSmith> http://www.w3.org/TR/rdfa-syntax/#s_curies
  122. # [08:01] <MikeSmith> "The prefix mappings are provided by the current in-scope namespace declarations of the [current element] during parsing."
  123. # [08:01] <mjs> I see
  124. # [08:01] <mjs> I was looking here: http://www.w3.org/TR/curie/
  125. # [08:01] <mjs> so yeah, CURIEs have the same problem as QNames
  126. # [08:01] <mjs> (when used in attribute values)
  127. # [08:02] <Hixie> MikeSmith: well, that somewhat makes the entire thing moot for HTML5 then... we have no namespace declarations :-)
  128. # [08:04] <MikeSmith> Hixie - right. I have to admit I'm not sure what would be accomplished just by allowing CURIEs in rel values. Because as far as I can see, any real-world XHTML+RDFa document instance is going to contain other markup that is not conformant to the core HTML5 vocabulary.
  129. # [08:04] <MikeSmith> e.g., rev attributes
  130. # [08:05] <MikeSmith> and RDFa-specific attributes
  131. # [08:05] <MikeSmith> http://www.w3.org/TR/rdfa-syntax/#sec_2.1.
  132. # [08:11] <MikeSmith> I really wonder whether what might be helpful would be to have an explicit statement in the HTML5 spec acknowledging the possibility that document types that are extensions of the core (X)HTML5 vocabulary may exist, and that any conformance criteria in specifications for such document types override the conformance criteria specified in HTML5.
  133. # [08:13] <Hixie> not sure i would agree with that statement :-)
  134. # [08:14] * Quits: adele (adele@67.170.232.64) (Quit: adele)
  135. # [08:14] <MikeSmith> Hixie - the "Conformance criteria: Web browsers and other interactive user agents" section already contains "...unless the semantics of those elements have been overridden by other specifications".
  136. # [08:15] <MikeSmith> which seems to already admit the possibility
  137. # [08:16] <mjs> if a spec adds to HTML5 compatibly, HTML5 doesn't need to say anything
  138. # [08:16] <mjs> if it makes incompatible changes, then it's not a form of HTML5
  139. # [08:16] <MikeSmith> mjs - in the case of XHTML+RDFa, it's adding new attributes
  140. # [08:18] <MikeSmith> could adding new attributes be considered adding compatibly?
  141. # [08:18] <Hixie> MikeSmith: oh certainly the possibility exists, e.g. xslt documents that contain html5 have different processing requirements
  142. # [08:18] <Hixie> MikeSmith: but that doesn't make those documents valid html5 documents
  143. # [08:19] <Hixie> but seriously, rdfa isn't worth our time imho
  144. # [08:19] <Hixie> it's totally the wrong solution to a non-existent problem
  145. # [08:24] <MikeSmith> Hixie - I guess I think it might be useful for the spec to make it more clear that what we're trying to do is define a core vocabulary for the "wider web", and that while the possibility exists that there may be other specifications that are extensions based on the core vocabulary, the spec for HTML5 does not attempt to address them.
  146. # [08:28] <Hixie> you mean like in http://www.whatwg.org/specs/web-apps/current-work/multipage/section-scope.html#scope ?
  147. # [08:30] * Quits: hober (ted@68.101.220.172) (Quit: ERC Version 5.3 (devel) (IRC client for Emacs))
  148. # [08:35] <MikeSmith> Hixie - maybe a specific "Relationship to XHTML1-based languages" section there would not hurt
  149. # [08:36] <MikeSmith> I'm happy to write something up if it will help
  150. # [08:40] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
  151. # [08:44] * Quits: dbaron (dbaron@71.204.145.103) (Ping timeout)
  152. # [08:46] * Joins: go (guillaume@146.64.19.212)
  153. # [08:50] * Joins: shepazu (schepers@128.30.52.30)
  154. # [08:56] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  155. # [08:56] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  156. # [08:57] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  157. # [08:59] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  158. # [09:12] <hsivonen> Hixie: if it's helpful for a validator not to whine about the Inkscape cruft, does it follow that RDFa should be allowed as well?
  159. # [09:13] <hsivonen> Hixie: how do you spec an incremental update path such that the next <canvas> happens nicely and cooperatively if you put in language to block RDFa?
  160. # [09:13] * Joins: shepazu (schepers@128.30.52.30)
  161. # [09:15] <hsivonen> (RDFa is different, though, in the sense that it wants to change the data type of existing attributes in a way that looks like very bad idea)
  162. # [09:28] * Joins: tH_ (Rob@87.102.85.140)
  163. # [09:28] * tH_ is now known as tH
  164. # [10:02] * Joins: dedridge (opera@121.72.6.99)
  165. # [10:03] * Joins: zcorpan (zcorpan@83.227.33.203)
  166. # [10:05] <Hixie> hsivonen: what's the inkscape cruft?
  167. # [10:06] <Hixie> hsivonen: <canvas> wasn't valid when it was introduced, and i think that's fine
  168. # [10:06] <Hixie> hsivonen: validators _should_ complain about non-standard extensions
  169. # [10:06] <Hixie> authors shouldn't be sending non-standard extensions over the wire
  170. # [10:12] * Quits: Lachy (Lachlan@84.215.41.149) (Ping timeout)
  171. # [10:13] <hsivonen> Hixie: Inkscape cruft occurs in SVG and stores the editing state of the document
  172. # [10:16] <hsivonen> Hixie: should the Inkscape cruft at http://burningbird.net/technology/standards-take-work/ fill the validator results with error messages?
  173. # [10:17] <hsivonen> Hixie: also, last paragraph in http://lists.w3.org/Archives/Public/public-qa-dev/2007Dec/0000.html
  174. # [10:19] <hsivonen> Hixie: my first reaction to the Inkscape cruft is that it shouldn't be there, but I have a real hard time coming up with an explanation why it would be helpful for validator users to output a lot of errors for that cruft
  175. # [10:20] <hsivonen> Hixie: since in practice, the inkscape cruft is rather harmless to the Web
  176. # [10:20] <mjs> it would be nice if html had a semi-scoped mechanism for extensions
  177. # [10:20] <zcorpan> http://www.w3.org/QA/2007/12/on_considering_the_role_of_w3c_1.html hmm, pretty long answer to a yes/no question, and i don't know what the conclusion actually is
  178. # [10:20] <mjs> CSS has the vendor prefix convention, which is nominally invalid but easy to ignore
  179. # [10:20] <Hixie> you mean the content in the following namespaces?:
  180. # [10:20] <Hixie> xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
  181. # [10:20] <mjs> (and one could teach a validator to ignore it)
  182. # [10:20] <Hixie> xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
  183. # [10:21] <hsivonen> Hixie: yes
  184. # [10:21] <mjs> zcorpan: yeah, pretty wordy
  185. # [10:21] <Hixie> hsivonen: i would expect the validator to say "this file also contains content from the following non-standard namespaces: [...]. This document is invalid HTML5."
  186. # [10:21] <hsivonen> mjs: actually, the inability to configure the oXygen CSS editor to ignore errors on vendor properties makes the CSS error checking useless
  187. # [10:21] <Hixie> hsivonen: or invalid SVG, or whatever.
  188. # [10:22] <zcorpan> mjs: can you extract if it's a "yes" or a "no"?
  189. # [10:22] <hsivonen> Hixie: is it bad to send prince- -webkit-, or -moz- CSS properties over the wire?
  190. # [10:23] <Hixie> hsivonen: re your earlier question (having a hard time coming up with an explanation) if the cruft really is meaningless, it's harmful because it uses up disk space, bandwidth, memory, and cpu cycles.
  191. # [10:23] <Hixie> hsivonen: and if the cruft isn't meaningless, then it's harmful because it requires the end user to have knowledge that you can't reasonably assume it will have (since it is not standard)
  192. # [10:24] <Hixie> hsivonen: however, i agree that there should just be one error and not six bazillion
  193. # [10:24] <Philip> Should we disallow indentation of XML too, since the extra whitespace is meaningless and uses up disk space etc?
  194. # [10:24] <Hixie> Philip: the whitespace has uses
  195. # [10:25] <Hixie> (but there are people who argue it should be removed, see binary xml)
  196. # [10:25] <Hixie> hsivonen: css is an odd case because the entire technology is optional
  197. # [10:25] <mjs> zcorpan: it doesn't really answer the general question
  198. # [10:25] <mjs> zcorpan: on the specific question of what to do about Microsoft's complaint it seems to say:
  199. # [10:25] <hsivonen> Hixie: the Inkscape cruft is optional, too, by design
  200. # [10:25] <Hixie> hsivonen: as in, ignoring the css doesn't affect the meaning of the document
  201. # [10:25] <mjs> a) the chairs should aim to seek consensus first (so unilaterally moving to change the charter is probably not cool)
  202. # [10:25] <Hixie> hsivonen: however, it is still bad form to rely on non-standard extensions
  203. # [10:26] <Hixie> hsivonen: and validators should complain
  204. # [10:26] <Philip> Whitespace just makes documents easier to edit (at least in some editors that don't reindent stuff automaticlly), similarly to how the Inkscape cruft makes documents easier to edit (at least in some editors that are Inkscape)
  205. # [10:26] <mjs> b) if Microsoft or anyone else has a scope issue, it's ok to give them a "modest" amount of time for additional review (not indefinite)
  206. # [10:26] <mjs> c) if consensus is not achieved, you can have a vote instead
  207. # [10:27] <Hixie> hsivonen: the inkscape cruft should, imho, report just a single error, just like i would expect the MSO crap to output a single error (though that error should maybe be expandable to more detail if you are going to try to clean it up)
  208. # [10:27] <Hixie> you as in the user
  209. # [10:27] <mjs> I don't think any of that justifies having a vote and doing the opposite of what the vote says
  210. # [10:28] <shepazu> why should it report an error at all? it's perfectly valid namespaced content
  211. # [10:28] <mjs> zcorpan: it also specifically says that if you do hold a vote, each vote has equal weight
  212. # [10:29] * Joins: ROBOd (robod@89.122.216.38)
  213. # [10:29] <hsivonen> Hixie: I was planning on making the inkscape cruft in XHTML and MathML an error and a single warning in SVG
  214. # [10:29] <jgraham_> Arguably this is case where a warning would be good.
  215. # [10:29] <shepazu> and it does serve a purpose, just not in the display of the SVG... it's a roundtripping mechanism for the authoring tool, and might be useful to someone other than the author if they also want to open that file in Inkscape
  216. # [10:30] <hsivonen> Hixie: arguably, the namespaced cruft is a better round-tripping mechanism than an authoring tool hiding its stuff in comments
  217. # [10:31] <zcorpan> mjs: yep. thanks
  218. # [10:31] <Hixie> hsivonen: well clearly i can't comment on the exact rules of svg (and indeed i think the svg spec explicitly allows any non-svg content, or something); but from an html point of view you don't want to be including data that the end user can't interpret
  219. # [10:31] <hsivonen> Hixie: the main bad feeling I have about this is that I'm not sure if this approach is scalable in a way that doesn't get me accused of being unfair to some other cruft
  220. # [10:31] <Hixie> hsivonen: oh i don't disagree, i just don't think that such content should be published
  221. # [10:31] <Hixie> hsivonen: that is, i agree that namespaced cruft is a good way to store proprietary data during editing
  222. # [10:32] <mjs> what if you don't want to modify your document to remove it before publishing?
  223. # [10:32] <shepazu> Hixie: when does editing end? content is increasingly created in a distributed way
  224. # [10:32] <mjs> or conversely, what is the benefit of removing such cruft before publishing (since there's the cost of extra work and extra process to avoid mistakes)
  225. # [10:33] <zcorpan> hsivonen: with the group messages feature, why would you want to emit one message? one message isn't helpful if you want to fix it
  226. # [10:33] <anne> if that's true you'd want the editing extensions to be standard, not inkscape specific
  227. # [10:33] <zcorpan> s/isn't/is less/
  228. # [10:33] <Hixie> mjs: then you end up sending proprietary/non-standard markup over the wire, which means the end user won't be able to properly interpret your document. q.v. microsoft office html.
  229. # [10:33] <hsivonen> zcorpan: these are not errors that group into one
  230. # [10:33] <shepazu> mjs: inkscape lets you save a stripped-down version without (much) extra kruft
  231. # [10:33] <zcorpan> hsivonen: they could if you have knowledge about them and have the same message for all of them
  232. # [10:34] <zcorpan> "Error: Inscape cruft."
  233. # [10:34] <mjs> Hixie: if the markup is just editing round-trip metadata which is not intended to affect normal display of the document, is that still the case?
  234. # [10:34] <shepazu> heh
  235. # [10:34] <zcorpan> (or warning)
  236. # [10:34] <mjs> I mean, I agree sending proprietary markup is bad in principle, but this seems like a "no harm no foul" situation
  237. # [10:35] <mjs> perhaps there is no way to allow it without also allowing undesirable things
  238. # [10:35] <Hixie> mjs: it's a slippery slope. i have no doubt that some people can avoid crossing the line. but i am also sure that most editors will go so far over the line they won't even be able to see it.
  239. # [10:35] <shepazu> I think it's harmless at worst and useful at best
  240. # [10:35] <mjs> but in principle the inkscape cruft seems no different than a microformat encoded in existing attributes
  241. # [10:35] <zcorpan> as an author, i'd like the validator to tell me if i have product-specific cruft in my content
  242. # [10:35] <Hixie> the simple answer is just microsoft office. Should those documents output by Word as HTML be considered valid?
  243. # [10:36] <hsivonen> mjs: indeed. the main difference is whether a validator can "see" it
  244. # [10:36] * anne compared it to having <apple-canvas> being the de facto standard to do <canvas>
  245. # [10:36] <shepazu> zcorpan: that seems like a useful bit of functionality, but as a warning, not an error
  246. # [10:36] <mjs> I'm glad we didn't call it <apple-canvas>
  247. # [10:36] <anne> indeed
  248. # [10:36] <Hixie> mjs: the big difference is that a microformat is a well known, discussed, peer-reviewed format, whereas the product-specific data is proprietary and likely undocumented.
  249. # [10:36] <jgraham_> Hixie: I think there's a difference if you're carefully keping ll extensions inside a namespace
  250. # [10:36] <Hixie> mjs: and that really is the key difference.
  251. # [10:37] <mjs> I don't know what Word's HTML output looks like, actually
  252. # [10:37] <mjs> Hixie: sure, but if I make up my own convention of magical class names and send that over the wire, that is not invalid
  253. # [10:37] <Hixie> anne: well, <canvas> is a case where we clearly don't want it to be valid, since that actually _does_ affect the document semantics.
  254. # [10:37] <hsivonen> Hixie: is it evil for Word HTML to favor its creator for round-tripping if it renders correctly with the extensions ignored?
  255. # [10:38] <hsivonen> Hixie: would it be evil for e.g. wikipedia publish inkscape SVG effectively making the drawings render in all SVG browsers but favoring a certain editor for tweaking?
  256. # [10:38] <shepazu> hsivonen: it can make it harder to author by copy-paste... it's less intuitive
  257. # [10:39] <mjs> does anyone have a link to an example of what Word's html output looks like?
  258. # [10:39] <Hixie> like i said, i think it's quite possible to do this ina harmless way, and i see no technical problem with, e.g., inkscape's proprietary namespace extensions.
  259. # [10:39] <Hixie> the problem is that it is a slippery slope
  260. # [10:39] <hsivonen> Hixie: I agree that the slope is slippery
  261. # [10:39] <Hixie> and that most editors and tools will go far over the line into the "affecting semantics" side of things
  262. # [10:39] <shepazu> if you don't know the syntax, it would be harder to learn it from krufty code, but that's really not a major case
  263. # [10:39] * jgraham_ dislikes slippery slope arguments
  264. # [10:40] <zcorpan> mjs: http://www.google.com/codesearch?q=%3Co%3Ap%3E&hl=en&btnG=Search+Code
  265. # [10:40] <Hixie> i'm just looking at the big picture here -- i think this is a case of "protecting the ignorant" at the cost of annoying the experts
  266. # [10:40] <hsivonen> Hixie: can anyone propose a neutral n-pronged test for determining if an extension is sliding too much along the slope?
  267. # [10:40] <jgraham_> (although that might not be for any logical reason but more because I associate them with the Daily Mail and its ilk)
  268. # [10:41] <mjs> zcorpan: that mostly seems to find code for dealing with <o:p>
  269. # [10:41] <mjs> does office insert a bunch of that?
  270. # [10:41] <Hixie> <o:p> is office cruft
  271. # [10:41] <Hixie> o: is the mso namespace prefix
  272. # [10:43] <Philip> http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/pages/tag/o:p
  273. # [10:43] <mjs> I can't tell what <o:p> is supposed to be for from examples I have found
  274. # [10:44] <hsivonen> Word has some special syntax for round-tripping empty paragraphs, doesn't it?
  275. # [10:44] <Philip> <p class="MsoNormal" align="center" style="text-align:center"><span
  276. # [10:44] <Philip> style="display:none;mso-hide:all"><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>
  277. # [10:45] <Hixie> mjs: http://www.rootsweb.com/~hcpd/norman/norman.htm is a good example
  278. # [10:45] <mjs> WebKit has a crazy way to round-trip empty paragraphs too I'm afraid
  279. # [10:45] <mjs> but with a magical class value
  280. # [10:46] <mjs> <p><br class="webkit-block-placeholder"></p>
  281. # [10:47] <Hixie> that's far better than word
  282. # [10:47] <Hixie> that might even be considered ok :-)
  283. # [10:47] <hsivonen> Hixie: because it has no colons? :-)
  284. # [10:48] <mjs> other than being less visually ugly in source form, I'm not entirely sure why it's better, though I guess I can't object too hard to such a judgment
  285. # [10:48] <hsivonen> it squats names in the space reserved for authors!11!11! :-)
  286. # [10:49] <zcorpan> mjs: http://simon.html5.org/temp/msword-cruft/
  287. # [10:49] <Hixie> hsivonen: no, because the semantics are actually correct. It's a paragraph whose only contents are a blank line.
  288. # [10:51] <hsivonen> there are certain other cruft spots that probably aren't worth fighting: RDF subtrees in <head> and OpenMath subtrees in <annotation-xml>
  289. # [10:52] <mjs> hsivonen: that's quite a lot of cruft
  290. # [10:53] <Hixie> mjs: from word, you mean?
  291. # [10:53] <Philip> Is that the latest version of Word?
  292. # [10:54] <Hixie> hsivonen: RDF subtrees in <head> are probably fine, since RDF is presumably a standard format (and the ontologies used are RDF's problem, not HTML's). HTML5 as I'm currently editing it allows RDF in <head>.
  293. # [10:54] <mjs> er
  294. # [10:54] <mjs> I meant that to zcorpan I guess
  295. # [10:55] <hsivonen> from what I've seen so far, I'm more worried about the product lock-in aspect of MathML <annotation> and <annotation-xml> than about the Inkscape cruft
  296. # [10:55] <hsivonen> Hixie: saying that RDF is standard is like saying that XML is standard and therefore any embedded XML is OK
  297. # [10:56] <zcorpan> Philip: it's from office xp, i think
  298. # [10:58] <Hixie> hsivonen: yeah, i agree.
  299. # [10:58] <Hixie> hsivonen: i'm really not worried about rdf.
  300. # [11:01] * Quits: beowulf (beowulf@194.74.230.217) (Ping timeout)
  301. # [11:03] * Joins: beowulf (beowulf@194.74.230.217)
  302. # [11:05] <hsivonen> Hixie: speaking of extensios, what your take on the Feed Validator approach to Atom and RSS extensions?
  303. # [11:10] <Hixie> i am not familiar with it
  304. # [11:11] <hsivonen> Hixie: to describe it simply, if you document a deployed extension in Sam's blog comments, it becomes valid.
  305. # [11:13] <Hixie> well that's basically the approach we have in html5 for rel=""
  306. # [11:21] * hsivonen realizes that the W3C QA blog is a Q&A blog now that it hasn't been on the QA topic
  307. # [11:28] * Quits: jmb (jmb@152.78.68.189) (Ping timeout)
  308. # [11:30] * Joins: jmb (jmb@152.78.68.189)
  309. # [11:30] * Joins: Lachy (Lachlan@213.236.208.22)
  310. # [11:45] * Quits: sbuluf (efhmnfh@200.49.132.113) (Quit: sbuluf)
  311. # [11:53] <Hixie> cool, we have a RAISED state now
  312. # [11:53] <anne> but it means CLOSED BY EDITOR
  313. # [11:53] <anne> oh well
  314. # [11:54] <Hixie> oh
  315. # [11:54] <Hixie> ?
  316. # [11:55] <anne> it doesn't?
  317. # [11:56] <Lachy> I thought RAISED meant that the issue was being actively worked on or something like that
  318. # [11:57] <anne> ok
  319. # [11:58] <Hixie> the states are "RAISED", "OPEN", and "CLOSED", in that order
  320. # [11:58] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  321. # [12:02] <Philip> Are they like "UNCO", "NEW", "RESO"?
  322. # [12:02] <Hixie> i have no idea
  323. # [12:02] <Hixie> i just posted to the list again
  324. # [12:02] <Hixie> asking for clarification
  325. # [12:03] <Hixie> i only care about "NEW" and "RESOLVED", from the editor's perspective
  326. # [12:03] <Hixie> i'm fine with bugs coming in as NEW
  327. # [12:03] <Hixie> and I'm fine with RESOLVED being the last state
  328. # [12:03] <Hixie> so it's really up to the working group where the third state fits in
  329. # [12:03] <anne> that's why I thought RAISED might mean "CLOSED BY EDITOR"
  330. # [12:03] <Hixie> either before the editors see the issue or after the editors see the issue
  331. # [12:04] <anne> and "CLOSED" would mean WG agrees
  332. # [12:04] <Hixie> i guess the most important detail we are missing is what is the default state
  333. # [12:04] * Hixie doubts that we'll ever get complete group agreement on anything
  334. # [12:04] <Philip> RAISED could be useful for things that someone has said, but that haven't yet been agreed as relevant for the editor (i.e. not a dupe or a misunderstanding)
  335. # [12:04] <Philip> *editors
  336. # [12:04] <anne> yeah, something would probably be marked CLOSED after publishing a WD
  337. # [12:05] <Philip> to avoid the editors wasting their time on a long list of issues that are mostly irrelevant and could be handled by other group members instead
  338. # [12:10] * Quits: dedridge (opera@121.72.6.99) (Ping timeout)
  339. # [12:20] * Joins: dedridge (opera@121.72.18.70)
  340. # [12:48] * Joins: zcorpan (zcorpan@88.131.66.80)
  341. # [12:57] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  342. # [13:20] * anne thinks the #whatwg discussion is quite confusing
  343. # [13:26] * Quits: jgraham_ (james@81.86.217.3) (Quit: This computer has gone to sleep)
  344. # [13:38] * Joins: matt (matt@128.30.52.30)
  345. # [13:44] * Joins: Lachy (Lachlan@213.236.208.22)
  346. # [13:46] * Joins: timbl (timbl@209.6.134.246)
  347. # [13:53] * Quits: timbl (timbl@209.6.134.246) (Quit: timbl)
  348. # [14:22] * Philip wonders how to do interesting things with X3D that benefit from web integration, rather than being clones of standalone applications
  349. # [14:23] <Philip> I suppose using HTML for UIs (e.g. adding a drop-down list to select the colour of an object) is kind of useful, but not especially compelling
  350. # [14:25] <hsivonen> Is the spreadsheet somewhere without login?
  351. # [14:26] <Philip> hsivonen: http://spreadsheets.google.com/ccc?key=pkNVM1HEQs-wsHB7s1M5Lbw works for me
  352. # [14:26] <Philip> (without being registered as able to edit it)
  353. # [14:27] <Philip> ...but it does require me to log in to Google, it seems
  354. # [14:27] <Philip> so that's not very helpful
  355. # [14:28] <hsivonen> the desktop i have at hand is totally untrusted
  356. # [14:29] * Philip can't see anything better than manually exporting to HTML and uploading elsewhere
  357. # [14:30] <Philip> http://spreadsheets.google.com/pub?key=pCSsfW4GonG_7mUKIKjnyMQ - hmm, that works
  358. # [14:30] <Philip> (by making a copy of the spreadsheet then publishing that)
  359. # [14:31] <hsivonen> thanks
  360. # [14:35] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  361. # [14:41] * Quits: wilhelm (wilhelm@129.241.93.37) (Ping timeout)
  362. # [14:41] * Quits: hsivonen (hsivonen@130.233.41.50) (Ping timeout)
  363. # [14:41] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  364. # [14:42] * Joins: hsivonen (hsivonen@130.233.41.50)
  365. # [14:43] * Joins: Hixie (ianh@129.241.93.37)
  366. # [14:43] * Joins: wilhelm (wilhelm@129.241.93.37)
  367. # [14:50] * Joins: smedero (smedero@158.130.16.191)
  368. # [14:50] * Joins: smedero_ (smedero@158.130.16.191)
  369. # [14:50] * Quits: smedero (smedero@158.130.16.191) (Connection reset by peer)
  370. # [14:50] * smedero_ is now known as smedero
  371. # [15:13] <dedridge> anyone here know anything about the next face to face meeting? I thought I read somewhere that is was in France? Maybe?
  372. # [15:14] <Philip> dedridge: http://www.w3.org/2008/10/TPAC/Overview.html ?
  373. # [15:19] <dedridge> Philip: Thanks
  374. # [15:20] * Joins: timbl (timbl@128.30.5.98)
  375. # [15:28] * Quits: go (guillaume@146.64.19.212) (Quit: Leaving)
  376. # [15:30] * Lachy wonders why the XHR discussion moved from public-webapi to public-html?
  377. # [15:34] * Quits: matt (matt@128.30.52.30) (Quit: matt)
  378. # [15:37] <zcorpan> Lachy: i'd guess that it was a mistake on jonas' part
  379. # [16:06] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  380. # [16:25] * Joins: matt (matt@128.30.52.30)
  381. # [16:32] * Joins: ROBOd (robod@89.122.216.38)
  382. # [16:45] * Joins: billmason (billmason@69.30.57.156)
  383. # [16:49] * Quits: Lachy (Lachlan@213.236.208.22) (Ping timeout)
  384. # [16:57] * Joins: gsnedders (gsnedders@86.135.224.200)
  385. # [16:57] * MikeSmith is now known as Mike^mail
  386. # [16:59] * Joins: Lachy (Lachlan@84.215.9.100)
  387. # [17:01] * Quits: Lachy (Lachlan@84.215.9.100) (Quit: Leaving)
  388. # [17:01] * Joins: Lachy (Lachlan@84.215.9.100)
  389. # [17:08] <Philip> Is the namespace of <element/> (assuming no xmlns="..." in ancestors) different to the namespace of <element xmlns=""/>?
  390. # [17:11] <gsnedders> xml-names is confusing me.
  391. # [17:11] <gsnedders> "The empty string, though it is a legal URI reference, cannot be used as a namespace name."
  392. # [17:11] <gsnedders> "The attribute's normalized value must be either a URI reference — the namespace name identifying the namespace — or an empty string."
  393. # [17:11] <hsivonen> Philip: XML syntaxes for schema languages confuse me
  394. # [17:11] <gsnedders> surely they contradict one another!
  395. # [17:12] <gsnedders> (unless an empty string is a special case, which isn't specified)
  396. # [17:12] <Philip> hsivonen: I'm not thinking about schemas at all - I'm just wondering whether you can use xmlns="" to embed non-namespaced content inside some namespaced content that does use xmlns="something"
  397. # [17:13] <hsivonen> Philip: IIRC, you can
  398. # [17:13] <hsivonen> Philip: but you cannot bind "" to a prefix
  399. # [17:13] <Philip> (i.e. if <a xmlns="b"><c xmlns=""/></a> === <b:a xmlns:b="b"><c/></a>)
  400. # [17:14] <zcorpan> Philip: yes, they're the same (assuming you meant </b:a> at the end)
  401. # [17:14] <Philip> (I did)
  402. # [17:14] <hsivonen> (I thought <element/> was syntax from a schema language)
  403. # [17:15] <Philip> zcorpan: Okay, that sounds good
  404. # [17:15] <Philip> s/zcorpan/zcorpan+hsivonen/
  405. # [17:16] <hsivonen> anne: whatever happened with the licensing of your XBL2 schema?
  406. # [17:17] <hsivonen> anne: also, is it up-to-date and deployment quality?
  407. # [17:18] * zcorpan implements getting innerHTML in html in javascript
  408. # [17:18] <hsivonen> zcorpan: why?
  409. # [17:18] <hsivonen> zcorpan: to compare against native?
  410. # [17:19] <zcorpan> yeah
  411. # [17:20] <zcorpan> it's annoying that there's no way to get the nodeName in a case-preserving way
  412. # [17:20] <zcorpan> it's also annoying to check if an element is e.g. an html <bgsound>
  413. # [17:22] <zcorpan> most elements have an interface you can check against, but bgsound is a... HTMLSpanElement in firefox. and i think just HTMLElement in opera
  414. # [17:23] * Quits: Lachy (Lachlan@84.215.9.100) (Ping timeout)
  415. # [17:25] <hsivonen> Hixie: is your content model overhaul going to allow everything that Strict allowed? what about Transitional?
  416. # [17:26] <zcorpan> hmm, <spacer> also implements HTMLWBRElement in firefox
  417. # [17:26] <zcorpan> <bgsound> does as well
  418. # [17:28] <hsivonen> zcorpan: what method ar you using to discover the implmented interfaces?
  419. # [17:29] <zcorpan> w(x instanceof y) in the dom inspector
  420. # [17:29] * Joins: Lachy (Lachlan@84.215.9.100)
  421. # [17:30] <zcorpan> dom2html doesn't have HTMLSpanElement, but firefox supports that
  422. # [17:45] <hsivonen> zcorpan: so you try every interface name you know about?
  423. # [17:49] <zcorpan> well, atm i'm just testing ad-hoc
  424. # [17:50] <zcorpan> i was in the process of changing from <wbr> to <spacer> and found that it returned HTMLWBRElement still returned true for <spacer>
  425. # [17:50] <zcorpan> s/it returned/
  426. # [17:50] <zcorpan> s/it returned//, even
  427. # [17:55] * Joins: jgraham_ (james@81.86.217.3)
  428. # [17:55] * Quits: jgraham_ (james@81.86.217.3) (Quit: This computer has gone to sleep)
  429. # [17:56] * Joins: jgraham_ (james@81.86.217.3)
  430. # [17:57] * Joins: Lachy_ (Lachlan@84.215.9.100)
  431. # [17:57] * Quits: Lachy (Lachlan@84.215.9.100) (Connection reset by peer)
  432. # [18:00] * Quits: Lachy_ (Lachlan@84.215.9.100) (Ping timeout)
  433. # [18:01] * Joins: hober (ted@68.101.220.172)
  434. # [18:03] * Joins: aaronlev (chatzilla@66.30.196.151)
  435. # [18:06] * Joins: Lachy_ (Lachlan@84.215.9.100)
  436. # [18:08] * Joins: Lachy__ (Lachlan@84.215.9.100)
  437. # [18:10] * Quits: Lachy_ (Lachlan@84.215.9.100) (Ping timeout)
  438. # [18:12] * Quits: Lachy__ (Lachlan@84.215.9.100) (Ping timeout)
  439. # [18:13] <anne> hsivonen, I never licensed it
  440. # [18:13] <anne> hsivonen, since I wrote it, MIT or public domain
  441. # [18:14] <hsivonen> anne: either of those would work for me
  442. # [18:14] <anne> hsivonen, also, I don't think it's of sufficient quality just yet
  443. # [18:14] <hsivonen> ah, ok
  444. # [18:14] <anne> you'd have to implement the micro syntaxes mostly
  445. # [18:15] <anne> the tree structure checking is ok I believe (apart from style-type and script-type checking)
  446. # [18:15] <hsivonen> hmm. interesting. Shelley Powers uses <code><pre> instead of <pre><code>.
  447. # [18:19] * Joins: Lachy__ (Lachlan@84.215.9.100)
  448. # [18:22] * Quits: aaronlev (chatzilla@66.30.196.151) (Client exited)
  449. # [18:27] * Quits: Lachy__ (Lachlan@84.215.9.100) (Quit: Leaving)
  450. # [18:27] <hsivonen> I'm still not sure what to do about <svg version='1.0'>
  451. # [18:29] <anne> warn about there being a version attribute and no namespace declaration?
  452. # [18:30] <hsivonen> anne: I meant the version attribute having value 1.0 instead of 1.1. Complaining about 1.0 is the height of uselessness but not complaining it is in principle wrong
  453. # [18:31] <Philip> You could emit a comment, which is not a complaint but just lets people know you're validating with 1.1 rules instead of 1.0 rules
  454. # [18:32] <anne> i would advise authors against version attributes
  455. # [18:32] <Philip> Or treat it the same as someone trying to check an HTML4-doctyped document in the HTML5 conformance checker
  456. # [18:32] <hsivonen> anne: me too, but complaining about version='1.1' as well would be even less practical
  457. # [18:32] <Philip> (since that would presumably be theoretically consistent)
  458. # [18:32] <hsivonen> Philip: I don't have an SVG 1.0 schema at hand
  459. # [18:32] * Zakim hsivonen, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  460. # [18:33] <hsivonen> why is Zakim here?
  461. # [18:33] <anne> Zakim, leave
  462. # [18:33] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  463. # [18:33] * Joins: aaronlev (chatzilla@66.30.196.151)
  464. # [18:33] <hsivonen> I guess I'm going to make it a warning
  465. # [18:34] <hsivonen> the special cases pile on...
  466. # [18:36] <hsivonen> hmm. "Bad value http://hdh.dyn-o-saur.com:81/~hdh/blog/pyblosxom.py/ for attribute href on XHTML element a: PORT_SHOULD_NOT_BE_WELL_KNOWN in PORT."
  467. # [18:36] <hsivonen> I guess that's proper
  468. # [18:40] * Philip wonders why http://validator.nu/?doc=http%3A%2F%2Flocalhost.microsoft.com%2F returns 403 to itself
  469. # [18:47] * Joins: dbaron (dbaron@71.204.145.103)
  470. # [18:54] <anne> hmm, yet another type of URL: LEIRI
  471. # [18:54] <anne> standing for "Legacy Extended IRI"
  472. # [18:54] <hsivonen> yay for *R* proliferation
  473. # [18:55] <hsivonen> btw, fill-rule=" evenodd " means the same as fill-rule="evenodd" in Gecko and WebKit but not in Opera
  474. # [18:56] <anne> I'd assume we're correct...
  475. # [18:57] <hsivonen> the W3C schema allows fill-rule=" evenodd " but I guess it not working in Opera is at least a pragmatic reason to change the schema
  476. # [18:59] * anne doesn't trust schema's
  477. # [18:59] <hsivonen> fwiw, fill-rule=" evenodd " works in Prince as well
  478. # [19:01] <anne> http://www.w3.org/TR/SVGMobile12/painting.html#FillRuleProperty doesn't seem to allow it
  479. # [19:01] * Quits: jgraham_ (james@81.86.217.3) (Quit: This computer has gone to sleep)
  480. # [19:01] <anne> but it's rather vague
  481. # [19:01] <anne> a lot vaguer than HTML5 for instance
  482. # [19:03] <hsivonen> eww. SVG 1.2 uses qnames in content somewhere
  483. # [19:03] <anne> crap
  484. # [19:03] <shepazu> where?
  485. # [19:04] <hsivonen> shepazu: I don't know yet, but it is listed under datatypes
  486. # [19:04] <shepazu> I don't recalll qname values in SVG1.2
  487. # [19:04] <hsivonen> anne: Batik allows white space, too
  488. # [19:05] <anne> so given implementations it seems like allowing whitespace makes sense
  489. # [19:05] <hsivonen> SVG specs would be so much easier to search if they weren't split across multiple Web pages
  490. # [19:05] <anne> but the specification doesn't really tell either way and is in CR...
  491. # [19:05] <anne> there's a single page version i think
  492. # [19:06] <anne> maybe not
  493. # [19:06] <hsivonen> anne: I can't even find a PDF for 1.2 Tiny
  494. # [19:06] <anne> me neither
  495. # [19:07] <anne> i thought it was better
  496. # [19:07] * Quits: timbl (timbl@128.30.5.98) (Quit: timbl)
  497. # [19:10] * Joins: timbl (timbl@128.30.5.98)
  498. # [19:23] * Joins: Lachy (Lachlan@84.215.9.100)
  499. # [19:43] <hsivonen> I wonder what the situation with enumerated values an MathML is
  500. # [19:46] * Quits: dbaron (dbaron@71.204.145.103) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  501. # [19:52] * Quits: timbl (timbl@128.30.5.98) (Quit: timbl)
  502. # [19:55] <hsivonen> it didn't take much poking to find that the MathML spec and Gecko don't agree on whitespace trimming
  503. # [19:55] * Joins: Sander (svl@86.87.68.167)
  504. # [19:56] * Joins: timbl (timbl@128.30.5.98)
  505. # [20:02] <Philip> http://www.web3d.org/x3d/specifications/ISO-IEC-19776-X3DEncodings-XML-ClassicVRML/Part01/EncodingOfFields.html#SFString
  506. # [20:02] <Philip> They seem really confused about XML syntax vs X3D syntax, particularly in the &quot; example
  507. # [20:04] <Philip> (Also, reality disagrees with the spec - everybody writes <x stringfield='y'/> and not <x stringfield='"y"'/>)
  508. # [20:06] * Parts: zcorpan (zcorpan@88.131.66.80)
  509. # [20:06] <hsivonen> too bad RELAX NG defaults encourage schemas that trim whitespace around enumerated values
  510. # [20:06] <hsivonen> Philip: what apps support X3D?
  511. # [20:06] * Joins: dbaron (dbaron@63.245.220.241)
  512. # [20:07] <hsivonen> I sent feedback to www-math. It'll be interesting to see how it goes
  513. # [20:08] * hsivonen notices that the feedback lacks a preposition :-(
  514. # [20:08] * Joins: adele (adele@17.255.110.63)
  515. # [20:09] <Philip> hsivonen: http://www.web3d.org/x3d/wiki/index.php/X3D_Implementations and http://www.web3d.org/tools/ give some lists
  516. # [20:10] <Philip> (There is a VRML-like encoding of X3D as well as the XML encoding, but I think most people support at least the XML encoding)
  517. # [20:11] <hsivonen> Philip: is X3D intended for model interchange or for presenting 3D stuff to users?
  518. # [20:11] <hsivonen> is VRML still alive?
  519. # [20:11] <hsivonen> VRML was *so* hyped.
  520. # [20:11] <Philip> hsivonen: Both
  521. # [20:12] <Philip> (Compare to e.g. COLLADA, which is designed for use in processing pipelines, i.e. it's not (usually) presented to users and it's not designed for exporting from one 3D modelling program and then importing into another)
  522. # [20:12] <hsivonen> ok
  523. # [20:12] <Philip> VRML is still alive but it changed its name to X3D and started using XML, and hardware has advanced so it's not so rubbish :-)
  524. # [20:14] <hsivonen> I read a book about VRML in 1996. The book was more generic VR hype than a VRML tutorial
  525. # [20:16] <Philip> I remember VRML at around the same time as Quake - the only way Quake worked was with a very limited world where every scene had hours of preprocessing and the renderer was highly optimised for that
  526. # [20:17] <Philip> so there was no way a generic graphics system like VRML could hope to do anything even vaguely decent at reasonable speeds on normal desktop computers
  527. # [20:17] <Philip> which kind of kills the whole idea of doing interesting VR things before the first step
  528. # [20:18] * hsivonen reminisces faking smooth shadows on SGI O2 by pre-raytracing a unique texture for each flat surface
  529. # [20:20] * hsivonen wrote a POV-Ray scene file generating back end for a subset of the OpenGL API in order to extract geometry
  530. # [20:23] <Philip> Now people fake ambient occlusion by pre-raytracing a unique texture for each instance of their model - not much has changed :-)
  531. # [20:26] * Quits: matt (matt@128.30.52.30) (Quit: matt)
  532. # [20:26] * Joins: matt (matt@128.30.52.30)
  533. # [20:32] <hsivonen> RDF vs. IETF on www-archive :-)
  534. # [20:32] <hsivonen> about text/* rules
  535. # [20:32] <anne> yeah
  536. # [20:32] <anne> I think the RDF guy makes a good point
  537. # [20:33] <anne> deferring everything to application/* makes text/* pointless
  538. # [20:33] <anne> and text/* and encoding stuff already is unrealistic in practice
  539. # [20:34] <hsivonen> yeah, I don't see what the IETF folks win by making everyone use application/* for UTF-8 plus LF line breaks formats
  540. # [20:36] <hsivonen> still no minutes at http://www.w3.org/2007/08/video/report.html
  541. # [20:40] * Joins: zcorpan (zcorpan@83.227.33.203)
  542. # [20:44] <hsivonen> Hixie: have you reseached the use of non-W3C namespaces in mainly XHTML/SVG/MathML docs on the Web?
  543. # [20:47] * Joins: jgraham_ (james@81.86.217.3)
  544. # [20:59] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  545. # [21:06] * Parts: timbl (timbl@128.30.5.98)
  546. # [21:11] * Joins: kingryan (kingryan@66.92.219.50)
  547. # [21:22] * Quits: smedero (smedero@158.130.16.191) (Quit: smedero)
  548. # [21:29] * Quits: adele (adele@17.255.110.63) (Client exited)
  549. # [21:29] * Joins: adele (adele@17.255.110.63)
  550. # [21:35] * Quits: aaronlev (chatzilla@66.30.196.151) (Ping timeout)
  551. # [21:35] * Joins: zcorpan (zcorpan@83.227.33.203)
  552. # [21:58] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  553. # [22:00] * Quits: matt (matt@128.30.52.30) (Quit: matt)
  554. # [22:02] * Joins: matt (matt@128.30.52.30)
  555. # [22:06] * Joins: aaronlev (chatzilla@209.6.168.245)
  556. # [22:09] <Philip> http://lists.w3.org/Archives/Public/www-archive/2007Dec/0070.html - "Tim Berners-Lee [...] wrote in 1866:" - wow, I never knew he was that old
  557. # [22:25] <Hixie> hm. the new states seem to miss the one state i care about
  558. # [22:25] <Hixie> d'oh
  559. # [22:26] <Hixie> bummer. i forgot what DanC suggested i do for the issue tracker.
  560. # [22:26] <DanC> hi
  561. # [22:27] <DanC> I think I suggested you close design issues that you're done with (after sending some sort of summary to public-html) and we see if it sticks
  562. # [22:27] <DanC> is that the suggestion you're trying to remember? or is this some other tracker foo?
  563. # [22:29] <DanC> Hixie, ?
  564. # [22:43] * Quits: matt (matt@128.30.52.30) (Quit: matt)
  565. # [22:45] * Quits: ROBOd (robod@89.122.216.38) (Ping timeout)
  566. # [22:46] * DanC wonders about telcon details...
  567. # [22:46] * Joins: smedero (smedero@207.245.69.186)
  568. # [22:46] * DanC waves to smedero
  569. # [22:46] <smedero> Hi DanC
  570. # [22:46] <shepazu> DanC: I'm available Thursday if you need me... I might even be willing to scribe
  571. # [22:47] <DanC> let's see... http://www.w3.org/html/wg/il16 is mostly out of date, but not quite; the telcon time info isn't on http://www.w3.org/html/wg/
  572. # [22:48] <DanC> http://www.timeanddate.com/worldclock/fixedtime.html?month=12&day=21&year=2007&hour=00&min=00&sec=0&p1=0
  573. # [22:49] * DanC changes topic to 'HTML WG telcon Thu 20 Dec 4p Pacific (2007-12-21T00:00UTC) http://www.w3.org/html/wg/tracker/agenda (logs: http://krijnhoetmer.nl/irc-logs/ ) '
  574. # [22:49] <DanC> Chris Wilson isn't available.
  575. # [22:49] <DanC> I think Mike Smith is on holiday too...
  576. # [22:49] <shepazu> http://www.timeanddate.com/worldclock/meetingtime.html?month=12&day=20&year=2007&p1=0&p2=43&p3=64&p4=224
  577. # [22:51] <shepazu> what would be on the Agenda?
  578. # [22:51] <DanC> well, from the /topic I just updated, we have http://www.w3.org/html/wg/tracker/agenda ...
  579. # [22:52] <Hixie> DanC: aha, yeah, that was it. cool.
  580. # [22:52] <Hixie> so my task is to look at OPEN issues and mark them CLOSED after having processed them and sent mail to the list about it
  581. # [22:52] <Hixie> ok
  582. # [22:52] <DanC> in particular, my action re the HTML 5 schedule... http://www.w3.org/html/wg/tracker/actions/28 ...
  583. # [22:53] <Hixie> and i guess if people disagree they can loop it back to RAISED, which reinvokes the WG
  584. # [22:53] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
  585. # [22:53] <DanC> ... 13 Dec deadline there; I hope my telcon cancellation was taken as an implicit postponemnt. I guess I can make it explicit
  586. # [22:53] <DanC> right, Hixie
  587. # [22:53] <Hixie> k, that works for me
  588. # [22:53] <Hixie> let me actually write this down somewhere this time
  589. # [22:53] <hsivonen> so RAISED==UNCONFIRMED, OPEN==ASSIGNED and CLOSED==FIXED in bugzilla terms?
  590. # [22:54] <smedero> catching up via IRC logs, but that makes sense to me.
  591. # [22:54] <Hixie> hsivonen: i guess
  592. # [22:54] <Hixie> s/FIXED/RESOLVED/ maybe
  593. # [22:54] <hsivonen> ok
  594. # [22:54] <Hixie> this would be easier to note down if my server was responding
  595. # [22:54] <DanC> I'm not sure, hsivonen ... I think most of our stuff starts out in OPEN state even though it's not assigned to anyone in particular
  596. # [22:55] <DanC> somebody mentioned "new states"; evidently I missed some tracker enhancement news; somebody wanna clue me in?
  597. # [22:55] <smedero> Well "RAISED" is new
  598. # [22:55] <smedero> A while back, Ian asked for a couple of different states
  599. # [22:56] <smedero> and I explained Ian's request to Dom.
  600. # [22:56] <hsivonen> if issues usually start as OPEN, what's RAISED for?
  601. # [22:56] <smedero> Dom said another working group wanted something like "New" as well... and as if we've got some sorta crazy telephone game going on here, we ended up with "RAISED".
  602. # [22:56] <smedero> which I can live with, if RAISED == UNCONFIRMED
  603. # [22:57] <DanC> I suppose some WGs distinguish RAISED from OPEN where RAISED means the chair hasn't invited WG discussion of it yet
  604. # [22:57] <anne> RAISED = REOPENED?
  605. # [22:57] * hsivonen likes the familiar Bugzilla lifecycly words
  606. # [22:57] <hsivonen> cycle even
  607. # [22:57] <smedero> not that it matters much what I think, I don't have the zany task list that the chairs & editors have...
  608. # [22:57] <DanC> I think we get to figure out right here and how what the states mean for our WG. I'm only vaguely familiar with the bugzilla states.
  609. # [22:58] <smedero> I originally asked Dom for a way to specify our own states
  610. # [22:58] <smedero> but I guess that features isn't available yet.
  611. # [22:58] <smedero> :/
  612. # [22:58] <DanC> if you make a new issue now, smedero , what state do you expect the machine to put it in?
  613. # [22:58] <smedero> well, RAISED.
  614. # [22:59] <DanC> ok...
  615. # [22:59] <smedero> someone RAISED the issue and would like the editors, chairs, and perhaps entire group to look at it.
  616. # [22:59] <DanC> how about we go with that... RAISED means one of the issue tracker elves thinks it's worth working on; OPEN means somebody took an action to follow up, kinda like ASSIGNED
  617. # [22:59] <smedero> this where there is a bit of disconnect between your run of the mill of issue tracker and our working group
  618. # [23:00] <DanC> action = agreement to update the chairs ~weekly
  619. # [23:00] <smedero> Hixie, thoughts?
  620. # [23:01] <Hixie> sounds fine to me
  621. # [23:01] <anne> RAISED = WG needs to look at it, OPEN = editors need to look at it, CLOSED = editor resolved it
  622. # [23:01] <anne> ?
  623. # [23:01] <DanC> anybody care to scribble this into a wiki page?
  624. # [23:01] <smedero> I can do that
  625. # [23:01] <Hixie> i just tried, but the wiki told me i wasn't allowed to log in
  626. # [23:01] <DanC> hmm... the editors are welcome to look at things before somebody takes an action.
  627. # [23:01] <Hixie> dunno what's up with that
  628. # [23:02] <anne> fair enough
  629. # [23:02] <Hixie> DanC: agreed
  630. # [23:02] * DanC wishes for openid in esw.w3.org
  631. # [23:02] <DanC> smedero, try to re-use an existing wiki page, or at least link from one
  632. # [23:03] <smedero> there is this page: http://esw.w3.org/topic/HTML/CommonVocabularyAndDefinitions
  633. # [23:04] <DanC> there's something like HTML/IssueTrackingRequirements , no?
  634. # [23:04] <smedero> not exactly what I would want, though the title leads me to believe so.
  635. # [23:04] <DanC> I think CommonVocabularyAndDefinitions is about HTML design, not issue tracking
  636. # [23:04] <smedero> there's the template: http://esw.w3.org/topic/HTML/IssueTemplate
  637. # [23:04] <smedero> let's see...
  638. # [23:04] <Hixie> we probably need to update the text on the main HTML page too
  639. # [23:04] <DanC> yes, a link from HTML/IssueTemplate is a good way to start
  640. # [23:05] <smedero> at least the wiki search isn't using ht-dig.
  641. # [23:05] <DanC> yes, please update the main esw HTML page, Someone
  642. # [23:05] <Hixie> afk
  643. # [23:05] * DanC resumes gardening http://www.w3.org/html/wg/tracker/agenda ...
  644. # [23:13] <hsivonen> It appears that WebKit turns off CoreGraphics antialiasing when drawing link underlines and as a result link underlines are ugly in rotated foreignObject
  645. # [23:13] <DanC> aria and namespaces... that's actual technical work that I'd like to do, if I could find time. sigh.
  646. # [23:15] <mjs> hsivonen: we should probably fix that (we turn off antialiasing for a few other things too, it's needed to get a crisp look when not rotated, but we can get the current CTM)
  647. # [23:15] <hsivonen> WebKit does rotated OS X native widgets better than Gecko
  648. # [23:16] <Philip> hsivonen: Have you tried foreignObject in Opera?
  649. # [23:16] <hsivonen> Philip: it crashed
  650. # [23:16] <Philip> Ah
  651. # [23:20] <smedero> Well here's a start on cleaning up the intro text: http://esw.w3.org/topic/HTML
  652. # [23:21] <smedero> I've got to run out for a bit
  653. # [23:21] <smedero> (also documents the tracker states... combination of DanC and anne's descriptions...)
  654. # [23:21] <DanC> Lachy, wanna talk about HTML 5 authoring this week? or give a later due date for http://www.w3.org/html/wg/tracker/actions/34 ?
  655. # [23:22] <DanC> hasta, smedero
  656. # [23:22] <smedero> I'll be back in a tad, I've just got deal with contractors. Trying to sell my house like... now. Moving to Seattle from Philadelphia as of Jan 7th.
  657. # [23:23] * Quits: Lachy (Lachlan@84.215.9.100) (Ping timeout)
  658. # [23:23] <DanC> ah. good luck. I'm in a similar situation, though I'm only moving a few miles
  659. # [23:23] * DanC doesn't see any more pruning to do in http://www.w3.org/html/wg/tracker/agenda
  660. # [23:24] <hsivonen> the slashdot comments on HTML V5 and XHTML V2 are sad
  661. # [23:24] <DanC> here's hoping I/we can get enough stuff done tomorrow that I can cancel the telcon.
  662. # [23:24] <Philip> It's easier to just accumulate an unending collection of houses - it saves the hassle of selling the old ones
  663. # [23:24] <DanC> more slashdot? I just caught up on the video foo. http://www.w3.org/QA/2007/12/when_will_html_5_support_soone.html
  664. # [23:25] <hsivonen> DanC: http://developers.slashdot.org/article.pl?sid=07/12/16/1656245
  665. # [23:26] <gsnedders> hsivonen: see mine?
  666. # [23:26] <jgraham_> Slashdot comments are almost always sad
  667. # [23:26] <hsivonen> gsnedders: yes, I noticed you replied, too
  668. # [23:26] <hsivonen> jgraham_: yes
  669. # [23:27] <jgraham_> Incidentally what's the chance of reigniting a flame war by removing all the links to unfilled justification pages from the front of the wiki
  670. # [23:27] <jgraham_> e.g. http://esw.w3.org/topic/HTML/ChangedElementHr
  671. # [23:27] <jgraham_> ?
  672. # [23:27] * Joins: aaronlev (chatzilla@209.6.168.245)
  673. # [23:29] * Joins: Lachy (Lachlan@84.215.9.100)
  674. # [23:30] <DanC> hm... Adriaan de Jonge ... I don't recognize the name. I wonder if Sam Ruby knows ... him? her?
  675. # [23:31] <DanC> "Relatively few HTML enthusiasts understand the concepts of semantic HTML" seems pessimistic.
  676. # [23:31] <gsnedders> DanC: where's that? /.?
  677. # [23:31] <DanC> no, I'm quoting from TFA, http://www.ibm.com/developerworks/web/library/x-html5xhtml2.html?S_TACT=105AGX08&S_CMP=EDU
  678. # [23:32] <DanC> perhaps few HTML authors grok semantic HTML, but I wouldn't call them HTML enthusiasts; they're probably enthusiasts in music and photos and lots of other worthy pursuits
  679. # [23:33] <DanC> why does developerworks use such a tiny font? sigh.
  680. # [23:35] <DanC> I wonder who "An anonymous reader" is. why is this news? what is it doing on /.? just more /. randomness?
  681. # [23:35] <gsnedders> because an ed. thought the summary was interesting (it seems they rarely read the article anyway)
  682. # [23:36] <DanC> slow news day for CmdrTaco, I guess
  683. # [23:36] <DanC> hsivonen, any particular comments you found depressing? or just sturgeon's law in action?
  684. # [23:36] <gsnedders> DanC: the amount of ignorance in some is amazing
  685. # [23:37] <DanC> really? what's remarkable about ignorance? it's the default state for humans, no?
  686. # [23:37] <hsivonen> DanC: ignorance related to realities of how XML and HTML consumption in implemented in real software
  687. # [23:37] <gsnedders> DanC: "Probably because XHTML 5 doesn't even exist. XHTML is working on version 2 at the moment. Who knows, they might one day get to version 5, but at the current speed, that's going to be a while. HTML 5, on the other hand, most definitely does have a DOCTYPE. Or should have, if it expects to be recognised by browsers. DOCTYPE is vital for validation and proper parsing."
  688. # [23:38] <hsivonen> DanC: and the ignorance is presented as knowledge by parroting false prophets
  689. # [23:38] <gsnedders> (comment #21725512)
  690. # [23:38] <DanC> ah. parroting. yes, that _is_ depressing.
  691. # [23:39] <Philip> Perhaps the group should produce informative articles and submit good summaries to sites like Slashdot, when it's an otherwise slow day and there hasn't been an HTML5 article for a while, rather than waiting for random people to submit random articles of random quality
  692. # [23:39] * gsnedders has been pondering doing that
  693. # [23:40] <gsnedders> Might have time over the Christmas holidays to do something about that, though
  694. # [23:44] * Mike^mail is now known as MikeSmith
  695. # [23:56] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  696. # [23:57] * Quits: gsnedders (gsnedders@86.135.224.200) (Quit: 404: Not Found)
  697. # Session Close: Wed Dec 19 00:00:01 2007

The end :)