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

Options:

  1. # Session Start: Mon Jun 18 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:27] * Quits: heycam (cam@203.214.95.190) (Ping timeout)
  4. # [00:38] * Joins: xover (xover@193.157.66.5)
  5. # [00:48] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  6. # [01:01] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  7. # [01:06] * Joins: gavin_ (gavin@74.103.208.221)
  8. # [01:17] * Joins: heycam (cam@130.194.72.84)
  9. # [02:04] * Joins: karl (karlcow@128.30.52.30)
  10. # [02:51] <karl> hmm I wonder at which level the display of unknown unicode characters is controlled.
  11. # [02:51] <karl> http://kitenet.net/~joey/blog/entry/unicode_eye_chart/
  12. # [02:52] <karl> I see this page in a browser and some of the characters are not displayed properly then replaced with a "?" but a question mark is another character.
  13. # [02:52] <karl> I wonder if there would be a more sensitive way to show that the character has not been displayed properly.
  14. # [03:00] <Dashiva> Which browsers give you what?
  15. # [03:01] <Philip`> FF3 replaces them with boxes containing unreadably tiny letters giving the hex value of the codepoint
  16. # [03:03] <Philip`> (Maybe it's my fault for using a resolution that makes the pixels slightly smaller than the phosphor dots on my monitor, but I don't entirely appreciate letters being three pixels wide...)
  17. # [03:03] <Dashiva> Let's fix that, shall we
  18. # [03:06] <Dashiva> http://folk.ntnu.no/magnusrk/test/unicode-eye.html
  19. # [03:08] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  20. # [03:09] <karl> Dashiva: with Camino now
  21. # [03:09] <Philip`> The undisplayed characters are still unreadably tiny, since I think they're hard-coded bitmap patterns :-)
  22. # [03:10] <karl> I wonder if it changes depending on the font selected in the browser. It should not
  23. # [03:12] <Dashiva> well, I get different displays in different browsers
  24. # [03:12] <karl> so I guess the browser controls it
  25. # [03:12] <karl> then it would be kind of cool to have interop on this
  26. # [03:13] * Joins: gavin_ (gavin@74.103.208.221)
  27. # [03:17] <Philip`> It depends on how the browser cooperates with the OS about finding glyphs
  28. # [03:18] <Philip`> On Windows I have an actual font that is just square boxes with hex inside, for every codepoint, so Windows' font fallback code ends up picking from there when it can't find anything better (as I understand it)
  29. # [03:18] <Dashiva> I thought it was just "If you can't find the glyph, use this one instead" not a proper font. Not that I've researched, though
  30. # [03:19] <Dashiva> IE7 and Opera give me two different kinds of boxes
  31. # [03:19] <Dashiva> FF2 is only question marks
  32. # [03:19] <Philip`> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=UnicodeBMPFallbackFont - I think that's the one I was thinking of
  33. # [03:20] <Philip`> That's unrelated to FF3's use of boxes-with-hex when it can't find a glyph, though
  34. # [03:20] <Dashiva> Ah
  35. # [03:20] <Dashiva> That looks like a very useful font
  36. # [03:34] <karl> I see a difference between WebKit and Gecko
  37. # [03:35] <karl> another interesting thing if I serve in application/xhtml+xml the unicode chart
  38. # [03:35] <karl> there are invalid character numbers
  39. # [03:35] <karl> &#65535;
  40. # [03:40] <karl> http://www.w3.org/2007/06/unicode-test/index.xhtml
  41. # [04:02] <mjs> karl: some fonts include an "unknown character" glyph
  42. # [04:02] <mjs> we don't do the tiny box thing
  43. # [04:24] <karl> it seems that webcore handles it in a better way than gecko on the mac
  44. # [04:46] <karl> hmm I found another benefits of double quotes around attributes values in HTML. Selection by double clicking.
  45. # [04:46] <karl> id=editors <- double-click and it select everything
  46. # [04:46] <karl> selects
  47. # [04:51] * Quits: deltab (deltab@82.36.30.34) (Client exited)
  48. # [04:52] * Joins: deltab (deltab@82.36.30.34)
  49. # [05:02] * karl wonders what it should do with people having their HTML WG mailbox full… unsubscribing people?
  50. # [05:02] <karl> s/it/he/ or maybe it, I might be a robot
  51. # [06:03] * Joins: Zeros (Zeros-Elip@69.140.48.129)
  52. # [06:03] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Client exited)
  53. # [06:13] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  54. # [06:51] <karl> http://www.synchroedit.com/
  55. # [06:51] <karl> "SynchroEdit is a browser-based simultaneous multiuser editor, a form of same-time, different-place groupware. It allows multiple users to edit a single web-based document at the same time, and it continuously synchronizes all changes so that users always have the same version."
  56. # [06:52] <karl> "SynchroEdit is built around W3C's Document Object Module (DOM). It ensures that user modifications do not interfere with each other by keeping track of where each user is located in the DOM tree, by node.
  57. # [06:52] <karl> "
  58. # [06:52] <karl> It might be interesting to get this person review the HTML 5 specification.
  59. # [06:53] <karl> Christopher Allen
  60. # [06:55] <MikeSmith> karl - or at least to join the HTML WG
  61. # [07:00] <karl> http://lists.w3.org/Archives/Public/www-archive/2007Jun/0018 done!
  62. # [07:02] <karl> http://www.lifewithalacrity.com/2007/06/getting_ready_f.html
  63. # [07:02] <karl> One of the biggest things that SynchroEdit needs in order to function is DOM Mutation Events. At a party for WebKit (the open source code underpinnings of Safari's web renderer) and in questions after a session at WWDC it was confirmed that these are available to Safari 3.0 and presumably the iPhone.
  64. # [07:02] <karl> The other key ability that SynchroEdit requires is WYSIWYG editing. This was terribly broken in Safari 2.0, but I saw many demonstrations of it working in Safari 3.0, so I don't anticipate any problems with this.
  65. # [07:02] <karl> SynchroEdit also requires AJAX and in particular the XMLHttpRequest function, and the keynote clearly said that this was available.
  66. # [07:02] <karl> The final thing that SynchroEdit needs is the ability to keep the browser at readystate==3, i.e. not "finish" sending the page, so that we can continue to interactively pass updates to users as they arrive, without creating a new connection for every message. It is not clear if this will be supported on the iPhone, but there are ways to work around it.
  67. # [07:07] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  68. # [07:12] * Joins: gavin_ (gavin@74.103.208.221)
  69. # [07:49] <karl> I wonder what is the status of ruby support in Opera - http://my.opera.com/community/forums/findpost.pl?id=548036
  70. # [07:50] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  71. # [07:51] <karl> IE 6 was supporting it partially at a point.
  72. # [07:51] <karl> I think that would be good to include it in HTML 5
  73. # [07:51] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  74. # [07:51] <karl> because it would make to help cool annotation.
  75. # [07:51] <karl> huh
  76. # [07:52] <karl> it would help to make cool annotation
  77. # [07:52] * karl is in dislexya mood
  78. # [07:52] <anne> as I understand it we are waiting for someone to exactly work out the parsing rules
  79. # [07:52] <anne> I've done some work on that in the past, maybe that's enough, dunno really
  80. # [07:52] <karl> anne: because the spec is not clear enough?
  81. # [07:52] <anne> the XHTML Ruby spec?
  82. # [07:52] <karl> anne: yes I remember your previous work.
  83. # [07:53] <anne> the XHTML Ruby spec doesn't define HTML parsing rules
  84. # [07:53] <anne> it also doesn't define a lot of other things I believe
  85. # [07:53] <anne> such as what those elements mean in different contexts...
  86. # [07:53] <karl> If there is a list of issues you have on top of your mind about ruby parsing rules or if you have them written down somewhere. I think contacting Martin Duerst would help
  87. # [07:57] <anne> hmm, he's an Internet Explorer HTML parsing expert?
  88. # [07:57] <anne> btw, "Writing HTML" applies to authors just as much as it applies to tools
  89. # [07:57] <anne> that not all authors can understand it is a reason to create tutorials and such
  90. # [07:58] <karl> exactly.
  91. # [07:58] <anne> not to rename the section
  92. # [07:58] <karl> yes but you will create more questions, and maintenance by not renaming
  93. # [07:58] <karl> when a simple change of names
  94. # [07:58] <karl> avoid a loooooot of misunderstanding
  95. # [07:59] <karl> we have already been through this discussion
  96. # [07:59] <anne> I think it would be highly inappropriate for the spec not to detail exactly how authors should do things
  97. # [07:59] <karl> this is a "DOS attack" for any human author -> "Optionally, a single U+FEFF BYTE ORDER MARK (BOM) character."
  98. # [08:00] <anne> So saying it's just for tools is wrong
  99. # [08:00] <anne> imo
  100. # [08:00] <karl> anne: so better to not encourage them how to write HTML document
  101. # [08:00] <karl> them to read
  102. # [08:01] <anne> huh
  103. # [08:01] <karl> the more I read this section, the more I see that there is nothing for human authors in there
  104. # [08:01] <karl> talking about http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html#writing
  105. # [08:01] <anne> I'm a human and author...
  106. # [08:02] <karl> A DOCTYPE must consist of the following characters, in this order:
  107. # [08:02] <karl> 1. A U+003C LESS-THAN SIGN (<) character.
  108. # [08:02] <karl> 2. A U+0021 EXCLAMATION MARK (!) character.
  109. # [08:02] <karl> 3. A U+0044 LATIN CAPITAL LETTER D or U+0064 LATIN SMALL LETTER D character.
  110. # [08:02] <karl> 4. A U+004F LATIN CAPITAL LETTER O or U+006F LATIN SMALL LETTER O character.
  111. # [08:02] <karl> this is not usable by an author
  112. # [08:02] <karl> [15:01] <anne> I'm a human and author... AND A GEEK
  113. # [08:02] <anne> sure
  114. # [08:02] <karl> You are disqualified ;)
  115. # [08:02] <anne> i'm not saying authors have to use that section directly
  116. # [08:03] <anne> i'm saying we should pretend that section doesn't apply to authors, because then there's no section that does
  117. # [08:04] <karl> then you have to start the spec at the top of the specification in big red blink letter with trumpets: "You are an author, go away"
  118. # [08:07] <karl> and then the more logical would be that a big part of section 3 is out of HTML 5 as it stands now.
  119. # [08:07] <karl> http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html#semantics
  120. # [08:07] <karl> so it will be easier to not have misunderstanding
  121. # [08:08] <anne> that's about HTML elements
  122. # [08:08] <anne> and applies to XML and HTML serializations...
  123. # [08:09] <karl> anne forget who you are, and take the seat of someone who discover or are used to HTML 4.01. It is not that difficult, isn't it? Stay humble and think about other people.
  124. # [08:09] <karl> People do not master as much as you do.
  125. # [08:10] <anne> HTML4 didn't tell you how to write documents
  126. # [08:10] <anne> authors will just copy the examples anyway
  127. # [08:10] <anne> they don't read specs
  128. # [08:10] <karl> ????
  129. # [08:10] <karl> stop generalizing :)
  130. # [08:10] <karl> it doesn't work
  131. # [08:10] <karl> at least not with me ;)
  132. # [08:11] <anne> dude, who's generalizing?
  133. # [08:11] <karl> I have seen people reading specs, I have seen people asking questions.
  134. # [08:12] <anne> at the end of the day, someone would have to either rewrite that section to make it more author friendly or write another section that says exactly the same and is more author friendly
  135. # [08:12] <karl> there are valid questions from Web designers. They express concerns.
  136. # [08:12] <anne> as long as either doesn't happen, there's not much to discuss I think
  137. # [08:12] <karl> brushing away concerns because we are supposed to know better
  138. # [08:12] <karl> doesn't work
  139. # [08:12] <karl> at least for me
  140. # [08:12] <anne> that's too bad
  141. # [08:13] <karl> for you ;)
  142. # [08:13] <anne> I don't see how your proposed solution makes things better
  143. # [08:14] <anne> It actually makes the spec less useful for authors who can read that section as it suddenly no longer applies to them
  144. # [08:14] <anne> They wouldn't be able to figure out how to write documents?!
  145. # [08:14] <karl> ok let's take it in another way
  146. # [08:14] <karl> how will they benefit from reading that section 8.
  147. # [08:15] <anne> they?
  148. # [08:16] <anne> some might, some might not
  149. # [08:16] <karl> the person who will read HTML 4 Specification who are not implementers of authoring tools, but hand coding. What do they benefit of reading the section 8.
  150. # [08:17] <anne> just as with any other part of the spec
  151. # [08:17] <karl> mwaagagag
  152. # [08:17] <karl> :)
  153. # [08:17] <anne> at some point the sections will contain some more examples and all will be fine
  154. # [08:18] <anne> and maybe someone will step up and write this primer at some point and it will be better
  155. # [08:19] <karl> So if the section is not renamed because it seems to be a pain point for you I would add a paragraph saying. If you are an hand coding, please go read this document instead.
  156. # [08:19] <anne> I suppose that if someone writes that document that could be done
  157. # [08:19] <karl> s/coding/coding author/
  158. # [08:19] <anne> I mean, look at how the XML spec "explains" how to write XML documents...
  159. # [08:20] <anne> or CSS :)
  160. # [08:20] <anne> it's not like the CSS spec is really clear about how to write it
  161. # [08:20] <karl> could you stay serious one minutes and stop being a clown :O) :p
  162. # [08:20] <anne> euh, I'm serious
  163. # [08:21] <karl> XML document, not same public at all
  164. # [08:21] <anne> what HTML5 provides is significantly better than XML and CSS
  165. # [08:21] <anne> karl, I guess the same goes for CSS? ...
  166. # [08:21] <karl> http://www.w3.org/TR/CSS21/intro.html
  167. # [08:22] <anne> HTML5 will get that too
  168. # [08:22] <anne> that doesn't explain how to write CSS though
  169. # [08:22] <karl> for a human yes
  170. # [08:23] <anne> well, HTML5 will get that too
  171. # [08:23] <anne> but we need a normative description as well
  172. # [08:23] <karl> it's why I say that we have to put a message
  173. # [08:23] <karl> because without a message and asking for reviews at the same time
  174. # [08:23] <anne> the spec is not _finished_
  175. # [08:24] <karl> we will get endless efforts of explanation
  176. # [08:24] <karl> we just did between two supposed geeks
  177. # [08:24] <anne> I think time is better spend on writing tutorials
  178. # [08:24] <karl> and that will happen a lot again
  179. # [08:25] <karl> 10 minutes of discussion for one little change in a paragrah or title ;) indeed better use of time
  180. # [08:25] <hsivonen> karl: I don't understand why we'd need "interop" with missing glyph fallback. I think platforms should be able to do something more informative than displaying a glyph for U+FFFD if they so choose
  181. # [08:26] <hsivonen> karl: Mac OS X, for on, has a really nice system-level fallback
  182. # [08:26] <hsivonen> karl: it would be a shame to ban it
  183. # [08:26] <karl> who said Banning it?
  184. # [08:26] <anne> karl, the problem is that changing that paragraph will likely take more time (just in waiting for it to happen) than writing a tutorial
  185. # [08:26] <hsivonen> s/for on/for one/
  186. # [08:27] <hsivonen> karl: I read having interop as having the browsers do the same thing (where same might not be what OS X does since what OS X does requires glyphs that Everytype has made exclusively for Apple)
  187. # [08:27] <karl> hsivonen: nobody said to ban it, and I like what webkit/macosx does. I just wished more interop. having the same behavior for example in firefox
  188. # [08:28] <hsivonen> s/Everytype/Evertype/
  189. # [08:28] <karl> anne: "the problem is that changing that paragraph will likely take more time (just in waiting for it to happen) than writing a tutorial" yes the problem of having only two editors for such a huge document
  190. # [08:31] <anne> having more editors will just slow it down more as it requires lots of coordination between them
  191. # [08:31] <anne> and you get some spaghetti spec like CSS or SVG which is not nice
  192. # [09:00] * Quits: Lachy (Lachlan@203.158.59.119) (Connection reset by peer)
  193. # [09:00] * Joins: Lachy (Lachlan@203.158.59.119)
  194. # [09:14] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  195. # [09:15] <MikeSmith> hsivonen - over the weekend I managed to build an onvdl executable using gcj
  196. # [09:15] <MikeSmith> but it doesn't work as expected
  197. # [09:16] <MikeSmith> or not at all, actually
  198. # [09:16] <MikeSmith> [[
  199. # [09:16] <hsivonen> MikeSmith: any idea why it doesn't work
  200. # [09:17] <MikeSmith> $ ./onvdl html5.nvdl test.html
  201. # [09:17] <MikeSmith> Exception in thread "main" java.lang.NullPointerException
  202. # [09:17] <MikeSmith> at com.thaiopensource.validate.auto.AutoSchemaReader.createSchema(AutoSchemaReader.java:79)
  203. # [09:17] <MikeSmith> at com.thaiopensource.validate.ValidationDriver.loadSchema(ValidationDriver.java:148)
  204. # [09:17] <MikeSmith> at com.thaiopensource.relaxng.util.Driver.doMain(Driver.java:122)
  205. # [09:17] <MikeSmith> at com.thaiopensource.relaxng.util.Driver.main(Driver.java:31)
  206. # [09:17] <MikeSmith> ]]
  207. # [09:17] <MikeSmith> that's why :)
  208. # [09:17] <MikeSmith> I'm sure I'm doing something wrong in building the binary, but no idea what
  209. # [09:18] <MikeSmith> some missing flags I'm supposed to feed the linker probably
  210. # [09:19] * Joins: gavin_ (gavin@74.103.208.221)
  211. # [09:19] <MikeSmith> trying to build with gcj is painful ... bunch of arcane stuff that I can't find any documentaiton for
  212. # [09:20] * Joins: tH_ (Rob@87.102.33.233)
  213. # [09:20] * tH_ is now known as tH
  214. # [09:29] <hsivonen> MikeSmith: ok
  215. # [09:30] <hsivonen> MikeSmith: but wild guess is that you have a problem with gcj emulating a JVM class loader with the Jing extension mechanism
  216. # [09:32] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  217. # [09:36] * Quits: heycam (cam@130.194.72.84) (Ping timeout)
  218. # [09:45] <MikeSmith> hsivonen - if so, I'm not sure how I could fix that
  219. # [09:46] <MikeSmith> or if I could
  220. # [09:46] <hsivonen> MikeSmith: either by hardwiring the validation module class loading by hacking onvdl or by reading gcj docs until you find out how to turn on full class loader emulation if it is optional
  221. # [09:48] <hsivonen> MikeSmith: com.thaiopensource.validate.auto.SchemaReceiverLoader is the class to hack if you choose to try hardwiring the extension loading
  222. # [09:48] <MikeSmith> hsivonen - OK
  223. # [09:49] <hsivonen> MikeSmith: but it should be possible to make this work without hacking the source, because James Clark was able to make Jing work and that piece of code was in Jing already
  224. # [09:49] <hsivonen> (or then I'm guessing the reason of your problem wrong)
  225. # [09:50] * hsivonen doesn't like trouble shooting class loader issues
  226. # [09:59] * Quits: Lachy (Lachlan@203.158.59.119) (Connection reset by peer)
  227. # [10:00] * Joins: Lachy (Lachlan@203.158.59.119)
  228. # [10:05] <MikeSmith> hsivonen - I think for this gcj might end up being more trouble than it's worth ... I thought it might be worth exploring as a way to run onvdl without the costs of of JVM startup -- to enable using it for real-time relaxng and schematron validation in an editing application, for example
  229. # [10:19] * Joins: Jero (Jero@213.46.207.230)
  230. # [10:30] * Joins: zcorpan_ (zcorpan@88.131.66.111)
  231. # [10:30] * Joins: heycam (cam@203.214.95.190)
  232. # [10:44] * Joins: ROBOd (robod@86.34.246.154)
  233. # [10:52] * Joins: edas (edaspet@88.191.34.123)
  234. # [11:03] * Joins: mw22 (chatzilla@84.41.169.151)
  235. # [11:07] * Joins: zcorpan (zcorpan@88.131.66.80)
  236. # [11:08] * Quits: zcorpan_ (zcorpan@88.131.66.111) (Ping timeout)
  237. # [11:15] * Joins: gorme (gorm@213.236.208.22)
  238. # [11:21] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  239. # [11:26] * Joins: gavin_ (gavin@74.103.208.221)
  240. # [11:32] * Joins: frippz (frippz@193.15.86.40)
  241. # [11:46] * Quits: sbuluf (em@200.49.140.201) (Ping timeout)
  242. # [11:55] * Parts: gorme (gorm@213.236.208.22)
  243. # [11:56] * Joins: gorme (gorm@213.236.208.22)
  244. # [12:30] * Quits: xover (xover@193.157.66.5) (Ping timeout)
  245. # [12:52] * Joins: olivier (ot@128.30.52.30)
  246. # [13:01] * Joins: beowulf (carisenda@91.84.50.132)
  247. # [13:03] <beowulf> hi
  248. # [13:03] <beowulf> i joined the wg as an individual, i've since changed jobs and work for a w3c member
  249. # [13:04] <beowulf> do I leave?
  250. # [13:05] <beowulf> no, wait, sratch that...
  251. # [13:05] * beowulf reads more docs
  252. # [13:09] * Quits: heycam (cam@203.214.95.190) (Ping timeout)
  253. # [13:19] * Joins: myakura (myakura@58.88.37.26)
  254. # [13:21] <edas> beowulf,I'm interrested in what you can find. I will be in this situation in two monthes
  255. # [13:22] * Joins: xover (xover@193.157.66.5)
  256. # [13:22] <beowulf> edas: I think, though it's not terribly clear to me, that I have to leave
  257. # [13:24] <beowulf> "Accordingly, the principle that "Public Invited status is not normally granted to individuals employed by organizations which have significant business interest in results from W3C" has been relaxed in the case of the W3C HTML Working Group."
  258. # [13:24] <beowulf> maybe not
  259. # [13:26] * Joins: heycam (cam@203.214.72.248)
  260. # [13:28] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  261. # [13:28] <anne> you can ask the company you work for to nominate you
  262. # [13:33] <edas> I will, but I'm nearly sure it will be difficult (please understand "needless to ask")
  263. # [13:34] * Joins: gavin_ (gavin@74.103.208.221)
  264. # [13:35] <anne> depends on the company
  265. # [13:35] <anne> another factor is prolly if they've joined the group already or not
  266. # [13:35] <hsivonen> whew. implemented the new doctype tokenization states
  267. # [13:35] <anne> damn, you're beating html5lib :)
  268. # [13:36] <hsivonen> :-)
  269. # [13:36] <anne> I guess this is what they mean with competition
  270. # [13:37] <hsivonen> whoa. the tokenizer is over 3 kLOCs with inlined spec text
  271. # [13:51] * Joins: Lionheart (robin@66.57.69.65)
  272. # [14:05] <anne> hey Lionheart
  273. # [14:05] <anne> planning on updating your tests at some point? :)
  274. # [14:10] * Quits: olivier (ot@128.30.52.30) (Client exited)
  275. # [14:10] <anne> hsivonen, you implemented DOCTYPE sniffing as well?
  276. # [14:10] <Lionheart> Howdy
  277. # [14:11] * Joins: olivier (ot@128.30.52.30)
  278. # [14:11] <Lionheart> Indeed
  279. # [14:11] <anne> cool
  280. # [14:20] <Lionheart> Got a game to get ready by the Digital Game Xpo on Friday, so I probably won't have time for it this week.
  281. # [14:52] * Quits: hsivonen (hsivonen@130.233.41.50) (Client exited)
  282. # [15:28] * Joins: karl (karlcow@128.30.52.30)
  283. # [15:33] * Quits: Lionheart (robin@66.57.69.65) (Quit: Leaving.)
  284. # [15:36] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  285. # [15:41] * Joins: gavin_ (gavin@74.103.208.221)
  286. # [15:52] * Joins: icaaq (icaaaq@217.13.228.226)
  287. # [15:58] * Quits: myakura (myakura@58.88.37.26) (Quit: Leaving...)
  288. # [16:18] * Quits: frippz (frippz@193.15.86.40) (Quit: frippz)
  289. # [16:29] * Joins: billmason (billmason@69.30.57.156)
  290. # [16:32] * Joins: sbuluf (zrlbx@200.49.140.173)
  291. # [16:48] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  292. # [16:56] <zcorpan> (wrote in #whatwg, but i'll repeat here...)
  293. # [16:56] <zcorpan> http://simon.html5.org/temp/html5-opera.txt are things that i might write tests for this summer (thought probably less that that, that's just a first filtering)
  294. # [16:56] <zcorpan> anyone want me to look at something in particular?
  295. # [16:59] * Joins: hsivonen (hsivonen@130.233.228.9)
  296. # [17:19] * Quits: gorme (gorm@213.236.208.22) (Ping timeout)
  297. # [17:43] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  298. # [17:46] * Quits: zcorpan (zcorpan@88.131.66.80) (Ping timeout)
  299. # [17:48] * Joins: gavin_ (gavin@74.103.208.221)
  300. # [17:59] * Joins: hasather (hasather@80.203.71.22)
  301. # [18:04] * Quits: Dashiva (noone@129.241.151.35) (Ping timeout)
  302. # [18:04] * Joins: Dashiva (noone@129.241.151.35)
  303. # [18:04] * Quits: hsivonen (hsivonen@130.233.228.9) (Ping timeout)
  304. # [18:06] * Joins: hsivonen (hsivonen@130.233.228.9)
  305. # [18:06] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
  306. # [18:06] * Parts: icaaq (icaaaq@217.13.228.226)
  307. # [18:23] * Joins: Sander (svl@71.57.109.108)
  308. # [18:26] <anne> "poor authoring practices should NOT sway or inform our decisions" lol
  309. # [18:54] <Dashiva> I find it amusing when he says invisible metadata is visible -- to blind people
  310. # [18:57] <Dashiva> "you wouldn't deprecate ALT or LONGDESC would you" (isn't longdesc gone?)
  311. # [18:59] <anne> it is
  312. # [18:59] <anne> and ALT might become optional
  313. # [19:05] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  314. # [19:13] * Joins: ROBOd (robod@86.34.246.154)
  315. # [19:14] * Quits: Dashiva (noone@129.241.151.35) (Ping timeout)
  316. # [19:14] * Quits: xower (link@193.157.66.8) (Ping timeout)
  317. # [19:14] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  318. # [19:14] * Quits: xover (xover@193.157.66.5) (Ping timeout)
  319. # [19:14] * Joins: xower (link@193.157.66.8)
  320. # [19:14] * Joins: Dashiva (noone@129.241.151.35)
  321. # [19:14] * Joins: xover (xover@193.157.66.5)
  322. # [19:21] * Joins: Hixie (ianh@129.241.93.37)
  323. # [19:27] * Joins: Lionheart (robin@198.86.248.1)
  324. # [19:29] * Joins: edas (edaspet@88.191.34.123)
  325. # [19:31] * Joins: laplink (link@193.157.66.161)
  326. # [19:33] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  327. # [19:38] * Quits: edas (edaspet@88.191.34.123) (Ping timeout)
  328. # [19:51] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  329. # [19:55] * Joins: zcorpan (zcorpan@84.216.40.33)
  330. # [19:56] * Joins: gavin_ (gavin@74.103.208.221)
  331. # [20:12] <zcorpan> anne: <menu> has some new attributes. for html4-differences/
  332. # [20:12] <zcorpan> type label autosubmit
  333. # [20:33] * Joins: Dashimon (noone@129.241.151.35)
  334. # [20:33] * Quits: Dashiva (noone@129.241.151.35) (Ping timeout)
  335. # [20:33] * Dashimon is now known as Dashiva
  336. # [20:34] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  337. # [20:34] * Joins: Hixie (ianh@129.241.93.37)
  338. # [20:34] * Quits: xower (link@193.157.66.8) (Ping timeout)
  339. # [20:34] * Joins: xower (link@193.157.66.8)
  340. # [20:51] * Joins: polin8 (polin8@209.176.7.3)
  341. # [20:51] * Quits: polin8 (polin8@209.176.7.3) (Quit: :wq)
  342. # [20:56] * Joins: edas (edaspet@88.191.34.123)
  343. # [20:59] * Quits: schepers (schepers@71.51.208.196) (Connection reset by peer)
  344. # [21:03] * Quits: Lionheart (robin@198.86.248.1) (Connection reset by peer)
  345. # [21:49] * Quits: gsnedders (gsnedders@86.140.190.99) (Client exited)
  346. # [21:50] * Joins: gsnedders (gsnedders@86.140.190.99)
  347. # [21:58] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  348. # [22:00] * Quits: zcorpan (zcorpan@84.216.40.33) (Ping timeout)
  349. # [22:03] * Joins: dbaron (dbaron@63.245.220.242)
  350. # [22:03] * Joins: gavin_ (gavin@74.103.208.221)
  351. # [22:06] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Ping timeout)
  352. # [22:23] * Quits: edas (edaspet@88.191.34.123) (Ping timeout)
  353. # [22:45] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
  354. # [22:46] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  355. # [22:47] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  356. # [22:48] * Joins: kingryan (rking3@208.66.64.47)
  357. # [22:48] * Joins: Lionheart (robin@66.57.69.65)
  358. # [22:54] * Quits: mjs (mjs@64.81.48.145) (Ping timeout)
  359. # [23:04] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  360. # [23:14] * Quits: Jero (Jero@213.46.207.230) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502])
  361. # [23:18] * Joins: dbaron (dbaron@63.245.220.242)
  362. # [23:20] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  363. # [23:21] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  364. # [23:24] * Parts: hasather (hasather@80.203.71.22)
  365. # [23:32] <Hixie> DanC: so, this guy is asking that i publish something on /TR/, and you said I was wrong when I said that /TR/ wasn't under my control... Does that mean I can just go ahead and send things to the pub team? or?
  366. # [23:32] <Hixie> i'm confused
  367. # [23:40] <DanC> my point was that /TR/ isn't *completely* out of your control; you have influence on it.
  368. # [23:40] <DanC> you can't unilaterally publish at /TR/html5/ , but you can do things to make it much more or less likely to happen.
  369. # [23:41] <DanC> and while he might have been literally asking for a redirect, he said "yes please" to a snapshot
  370. # [23:42] * DanC wonders if I'm making more sense now
  371. # [23:42] * DanC tries mentioning Hixie by name in case that helps
  372. # [23:43] <Hixie> sorry, was afk
  373. # [23:43] <Hixie> so, what should i do to make it more likely to happen?
  374. # [23:44] <Hixie> basically i'm just trying to work out what i should do to make this guy happy
  375. # [23:44] <Hixie> i'm not sure how to reply to him
  376. # [23:45] * Hixie tries mentioning DanC by name in the same way :-)
  377. # [23:45] <DanC> I think publishing html5 would be easier if some of the more controversial stuff were taken out for now
  378. # [23:45] <Hixie> what's controversial?
  379. # [23:46] <Hixie> i thought most of the controversy was about what _wasn't_ in the spec
  380. # [23:46] <Hixie> i took out the predefined class names a while back
  381. # [23:46] <DanC> canvas and video come to mind
  382. # [23:46] <DanC> taking out predefined class names helps.
  383. # [23:46] <Hixie> they're controversial? i thought they were the most stable parts!
  384. # [23:47] <Hixie> i don't see much point in publishing a version without <canvas>, i mean, that's the part that's most ready to be published as CR
  385. # [23:47] <DanC> I think apple and microsoft said they oppose the ogg video format, and microsoft is not happy with canvas
  386. # [23:48] <Hixie> (btw it wasn't the same guy who said he wanted a snapshot as the guy who said he wanted a redirect)
  387. # [23:48] <DanC> I suppose I could force the issue. not while Chris W. is on holiday, though.
  388. # [23:48] <Hixie> my understanding is that apple is ok with the text of hte spec for video regarding codecs as is
  389. # [23:48] <DanC> not the same guy? oops; I read too fast.
  390. # [23:48] <Hixie> and i have yet to hear a technical argument from microsoft about, well, anything
  391. # [23:49] <Hixie> still not really sure how to reply though
  392. # [23:50] <Hixie> I guess I'll just punt it to you :-)
  393. # [23:50] <DanC> "I'm all for publishing a snapshot at /TR/html5/" is how I suggest you reply, I guess.
  394. # [23:50] <Hixie> ok
  395. # [23:50] <Hixie> wait, that's what i said that made him say this in the first place
  396. # [23:50] * DanC re-reads...
  397. # [23:50] <Philip`> How frequently would the snapshot be updated?
  398. # [23:51] <DanC> as often as the WG chooses. The WG is only making about one decision every 3 months, so far. :-/
  399. # [23:51] * DanC wonders if Karl is aboot, by chance
  400. # [23:52] <DanC> writing the "status of this document" section is the only critical piece of work in the publication path. or reviewing it.
  401. # [23:52] <Hixie> that's done
  402. # [23:54] <DanC> " that's what i said that made him say this in the first place" help? I can't find where you said that, Hixie
  403. # [23:54] <DanC> ah... now I see it...
  404. # [23:54] * Joins: mjs (mjs@17.255.99.40)
  405. # [23:56] <DanC> on canvas, I recall some argument that it shouldn't be part of HTML. I'm somewhat inclined to discuss requirements that motivate canvas.
  406. # [23:57] * DanC would have to catch up on quite a bit of discussion to be sure
  407. # [23:57] <mjs> botmap images dynamically generated on the client side
  408. # [23:57] <mjs> *bitmap
  409. # [23:58] <mjs> with optional fallback
  410. # [23:58] <Sander> given that it's implemented several times and starting to be actively used on the web, could we really get away with not including it in the spec?
  411. # [23:58] <mjs> plus it's already mostly-interoperably implemented
  412. # [23:58] <DanC> anne, are you around? this is something that I was thinking of for the "differences from HTML 4" document... motivation/status for, e.g., canvas.
  413. # [23:59] <DanC> canvas is more straightforwardly specified in a separate spec, for my money.
  414. # Session Close: Tue Jun 19 00:00:00 2007

The end :)