/irc-logs / freenode / #whatwg / 2007-03-27 / end

Options:

  1. # Session Start: Tue Mar 27 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:01] * Joins: tantek_ (n=tantek@63.sub-75-208-32.myvzw.com)
  4. # [00:02] * om_coffee is now known as othermaciej
  5. # [00:02] <othermaciej> hsivonen: we don't do page-number-based crossreferences
  6. # [00:04] * Quits: tantek (n=tantek@207.47.10.130.static.nextweb.net) (Connection timed out)
  7. # [00:05] * Quits: Hixie (n=ianh@trivini.no) ("Lost terminal")
  8. # [00:05] * Joins: Hixie (n=ianh@trivini.no)
  9. # [00:06] <Hixie> apologies, i just lost connection here.
  10. # [00:06] <Hixie> and i'm now in a conversation in the csswg
  11. # [00:10] <Dashiva> What about allowing innerHTML on DocumentFragment?
  12. # [00:11] <othermaciej> DocumentFragment is a core DOM interface
  13. # [00:13] <Dashiva> Suppose I could set/get around it using a placeholder div
  14. # [00:13] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  15. # [00:14] * Quits: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
  16. # [00:18] * Quits: tantek_ (n=tantek@63.sub-75-208-32.myvzw.com) (Read error: 104 (Connection reset by peer))
  17. # [00:18] * Joins: tantek (n=tantek@63.sub-75-208-32.myvzw.com)
  18. # [00:20] * Quits: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
  19. # [00:24] * Quits: mpt (n=mpt@121-72-132-31.dsl.telstraclear.net) ("Leaving")
  20. # [00:35] * tylerr needs to memorize the WHATWG spec.
  21. # [00:35] <Hixie> good luck with that
  22. # [00:36] <tylerr> :-)
  23. # [00:38] * Joins: hendry (n=hendry@91.84.53.136)
  24. # [00:39] <tylerr> Hixie: What accessibility work has been done so far on the spec?
  25. # [00:40] <Hixie> the spec. :-)
  26. # [00:40] <Hixie> the entire spec was designed with accessibility in mind.
  27. # [00:40] <tylerr> Ah lovely.
  28. # [00:41] <tylerr> I haven't had enough time to sit down and really study it.
  29. # [00:41] <othermaciej> tylerr: the contents of the spec, or the spec document?
  30. # [00:41] <tylerr> Ah sorry, I believe I meant the contents of the spec.
  31. # [00:43] <zcorpan_> hsivonen: a reason why prince complains about unmatched </p> end tags may be because the status script inserts <div> inside paragraphs in some places (because the annotaions.xml file isn't up to date)
  32. # [00:46] <hsivonen> zcorpan_: ok
  33. # [00:46] <webben> tylerr: what's lacking AFAIK is much in the way of accessibility testing of the spec
  34. # [00:49] <webben> we also seem to lack any discernable involvement from AT developers/manufacturers (who tend not to be very interested in the web for some reason)
  35. # [00:50] <webben> there are also issues inherited from html4 which the spec doesn't yet faciliate resolution of e.g. use of attributes for text that might change language.
  36. # [00:51] * tylerr nods.
  37. # [00:52] * Joins: ericcarlson (n=ericcarl@adsl-64-174-150-42.dsl.sntc01.pacbell.net)
  38. # [00:52] <tylerr> I'd like to work on some of those issues, as accessibility is an interest of mine.
  39. # [00:52] <webben> cool :)
  40. # [00:52] <tylerr> I was rather taken aback to learn that JAWS doesn't even consider CSS Aural.
  41. # [00:53] <webben> tylerr: Well. A lot of issues are UI issues, and HTML5 is generally wary of specifying UI issues.
  42. # [00:53] <webben> (that's what UAAG is for)
  43. # [00:54] <tylerr> Ah nice. I need to spend a weekend diving into the inner workings and specifications of the W3.
  44. # [00:54] <webben> heh ... i'd allot more than a weekend ;)
  45. # [00:55] <tylerr> Are you a part of the HTMLWG currently webben?
  46. # [00:55] <webben> no no ... i just lurk around here and on the main development mailing list
  47. # [00:55] <tylerr> Oh definitely. I have years till I would consider myself a guru.
  48. # [00:56] <tylerr> Ah nice.
  49. # [00:57] <tylerr> I'm getting involved in the WG as a solid learning experience, and to help shape the web, naturally. :-)
  50. # [00:58] <webben> tylerr: with regards to speech CSS, what we need (IHMO) is less specs and more developers on open source projects like Fire Vox, Orca, LSR, NVDA, and Emacspeak.
  51. # [00:59] <webben> oh and mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=47159
  52. # [00:59] <zcorpan_> someone here should work with QA for various AT vendors
  53. # [01:00] <zcorpan_> so they implement html5 and css speech
  54. # [01:01] <webben> I think CSS speech is actually a pretty marginal issue in terms of increasing web content accessibility.
  55. # [01:01] <tylerr> webben: I agree that more work needs to be focused on the developers. Getting them to accept the current specs is a must.
  56. # [01:01] <zcorpan_> ok, so they implement html5
  57. # [01:01] <tylerr> Sure webben. I think once the web becomes more semantic, then we can start looking at things like aural style sheets with more attention and priority.
  58. # [01:02] <webben> (being able to define how your reader reads html is important ... CSS may be a good tool for doing so)
  59. # [01:02] * Quits: ericcarlson (n=ericcarl@adsl-64-174-150-42.dsl.sntc01.pacbell.net) (Remote closed the connection)
  60. # [01:02] <webben> but then Orca and Fire Vox and Emacspeak already have crude support for that
  61. # [01:02] * Joins: ericcarlson (n=ericcarl@adsl-64-174-150-42.dsl.sntc01.pacbell.net)
  62. # [01:04] * tylerr nods.
  63. # [01:04] <webben> bigger issues are 1) helping authors to create accessible content in the first place (hence the stress i put on easy captioning, bookmarking, audio description with <video> 2) ensuring content is easily navigable (stuff like standardized document sectioning, navbars etc, is important there)
  64. # [01:05] <tylerr> Definitely.
  65. # [01:05] <tylerr> See, what I need to do is go through each element "section" of HTML5 and determine what accessibility needs there need to be.
  66. # [01:06] <webben> tylerr: that would be good.
  67. # [01:06] <tylerr> Like how can we make embedded content more accessible, how about phrase elements and prose?
  68. # [01:06] <tylerr> And does tabular data need an accessibility audit?
  69. # [01:07] * Joins: markp (i=chatzill@nat/google/x-174c499703b679e4)
  70. # [01:07] <webben> dunno ... i haven't looked at what HTML5 has done with tables at all actually
  71. # [01:07] <tylerr> I think I've just found my pet project for the next half a year. ;)
  72. # [01:08] <tylerr> Here's the section on it. Doesn't seem much has changed: http://www.whatwg.org/specs/web-apps/current-work/#the-table
  73. # [01:09] * Joins: KevinMarks (n=KevinMar@1433bhost147.starwoodbroadband.com)
  74. # [01:09] <zcorpan_> changed since when?
  75. # [01:09] <webben> html4
  76. # [01:09] <zcorpan_> except that in html4 much was undefined?
  77. # [01:10] <zcorpan_> e.g., how to associate header cells with data cells
  78. # [01:10] <webben> how was that undefined?
  79. # [01:10] <webben> oh you mean without using headers and scope?
  80. # [01:11] <Hixie> how was it defined? :-)
  81. # [01:11] <Hixie> even with scope= and headers= it's somewhat vague
  82. # [01:11] <zcorpan_> and then there's axis="" that no-one understands
  83. # [01:11] <zcorpan_> or uses
  84. # [01:11] <markp> joe clark probably understands it
  85. # [01:11] <tylerr> I read about axis once and forgot what it did about 4 minutes later. ;-)
  86. # [01:12] <webben> does anything support it i wonder
  87. # [01:12] <zcorpan_> don't think so
  88. # [01:12] <tylerr> Time to axe it. ;-)
  89. # [01:12] <markp> Hixie: i was looking for you earlier
  90. # [01:12] <webben> well, not necessarily
  91. # [01:12] <webben> g
  92. # [01:12] <markp> is there any effort afoot to spec out window.navigator?
  93. # [01:12] <webben> could be time to support it with a decent screen reader
  94. # [01:12] <markp> aka window.clientInformation
  95. # [01:13] <tylerr> Oh now you're talking webben.
  96. # [01:13] <othermaciej> markp: if it hasn't been done, I'd assume it will be
  97. # [01:14] <webben> how can you not love an attribute defined like: "This attribute may be used to place a cell into conceptual categories that can be considered to form axes in an n-dimensional space."
  98. # [01:14] <markp> there seem to be recent developments
  99. # [01:14] <markp> in window.navigator
  100. # [01:14] <markp> that i was previously unaware of
  101. # [01:14] <markp> navigator.buildID in firefox 2
  102. # [01:14] * webben tries to think of a useful way to use axis
  103. # [01:14] <markp> navigator.onLine
  104. # [01:15] <markp> and navigator.registerContentHandler / navigator.registerProtocolHandler for feed stuff
  105. # [01:15] <zcorpan_> webben: don't think too hard, you may end up seeing the world as an n-dimensional space
  106. # [01:15] <tylerr> webben: That attribute description is beautiful.
  107. # [01:16] <Dashiva> I can see forever
  108. # [01:17] <webben> hmm looks like JAWS supports axis: http://lau.csi.it/testare/accessibilita/test_user-agent/tabelle_accessibili/screen_reader.shtml
  109. # [01:17] <webben> if i'm understanding the italian right
  110. # [01:17] <markp> awesome
  111. # [01:18] <tylerr> I'd love to hear my web sites being read back to me in an n-dimensional space.
  112. # [01:19] * Quits: ericcarlson (n=ericcarl@adsl-64-174-150-42.dsl.sntc01.pacbell.net)
  113. # [01:24] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  114. # [01:26] <Hixie> markp: navigator.onLine and navigator.register* are in HTML5
  115. # [01:26] <Hixie> markp: (sorry, in csswg meeting mon/tue/wed this week)
  116. # [01:26] <markp> ah
  117. # [01:26] <markp> ok
  118. # [01:26] <markp> what about the rest of window.navigator?
  119. # [01:28] <othermaciej> http://www.whatwg.org/specs/web-apps/current-work/#navigator
  120. # [01:28] <othermaciej> markp: looks like not yet
  121. # [01:29] <markp> thanks
  122. # [01:29] * Joins: auk_ (n=scott@h-69-3-180-73.lsanca54.dynamic.covad.net)
  123. # [01:29] <othermaciej> I'm not sure registerProtocolHandler / registerContentHandler is so great; the proposed solution to security issues is confirmation dialogs
  124. # [01:30] <markp> is there interest in filling out that section, and/or making a separate spec like Window has?
  125. # [01:30] * Joins: Lachy_ (n=chatzill@220-245-91-147.static.tpgi.com.au)
  126. # [01:30] <othermaciej> I think it is a matter of priorities
  127. # [01:30] <othermaciej> it would be good to raise the issue that it is missing the traditional navigator stuff
  128. # [01:31] <othermaciej> I think it would be good for it to be a separate spec, to be fair, Windows has kind of stalled in its separate-spec form
  129. # [01:31] * Quits: auk_ (n=scott@h-69-3-180-73.lsanca54.dynamic.covad.net) (SendQ exceeded)
  130. # [01:32] * Joins: auk_ (n=scott@h-69-3-180-73.lsanca54.dynamic.covad.net)
  131. # [01:34] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  132. # [01:43] <Lachy_> markp: the navigator could probably be moved to a separate spec if someone in the Web API WG was willing to work on it
  133. # [01:44] * Quits: tylerr (n=tylerr@outbound.wa1.ascentium.com) ("Leaving")
  134. # [01:45] <Hixie> although it affects 'window'
  135. # [01:45] <Hixie> and 'window' affects things that affect HTML5
  136. # [01:46] <Lachy_> yeah, that's true
  137. # [01:46] <othermaciej> I think language-neutral bits of API should go in separate specs that are done by Web API, although it may be hard to do the right factoring
  138. # [01:55] * Joins: karlUshi (n=karl@dhcp-246-23.mag.keio.ac.jp)
  139. # [01:56] * Quits: auk_ (n=scott@h-69-3-180-73.lsanca54.dynamic.covad.net) (Read error: 104 (Connection reset by peer))
  140. # [01:58] * Joins: mpt (n=mpt@121-72-132-31.dsl.telstraclear.net)
  141. # [02:00] * Joins: markp_ (i=pilgrim@nat/google/x-fd9aed1cfb6b50de)
  142. # [02:04] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.1.3 (IRC client for Emacs)")
  143. # [02:05] * Quits: Philip` (n=excors@zaynar.demon.co.uk)
  144. # [02:05] * Quits: hendry (n=hendry@91.84.53.136) ("nn")
  145. # [02:13] * Joins: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
  146. # [02:15] * Quits: bzed (n=bzed@dslb-084-059-102-159.pools.arcor-ip.net) ("Leaving")
  147. # [02:16] * Quits: markp (i=chatzill@nat/google/x-174c499703b679e4) (Read error: 110 (Connection timed out))
  148. # [02:17] * Joins: dsinger (i=daitheso@nat/apple/x-7af35e6df04a9223)
  149. # [02:20] * Quits: dsinger (i=daitheso@nat/apple/x-7af35e6df04a9223) (Client Quit)
  150. # [02:24] * Joins: markp__ (i=pilgrim@nat/google/x-62ddf1c3c9981c37)
  151. # [02:24] * markp__ is now known as markp
  152. # [02:34] * Quits: zcorpan_ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  153. # [02:38] * Joins: zcorpan_ (n=zcorpan@84-216-41-128.sprayadsl.telenor.se)
  154. # [02:39] * Quits: h3h (n=h3h@66-162-32-234.static.twtelecom.net) ("|")
  155. # [02:39] * Quits: Dashiva (i=Dashiva@v035b.studby.ntnu.no)
  156. # [02:41] * Quits: markp_ (i=pilgrim@nat/google/x-fd9aed1cfb6b50de) (Read error: 110 (Connection timed out))
  157. # [02:44] * Joins: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  158. # [02:45] * Joins: Dashiva (i=Dashiva@v035b.studby.ntnu.no)
  159. # [03:04] * Quits: KevinMarks (n=KevinMar@1433bhost147.starwoodbroadband.com) ("The computer fell asleep")
  160. # [03:06] * Quits: syp (n=syp@lasigpc9.epfl.ch) (Read error: 104 (Connection reset by peer))
  161. # [03:09] * Quits: markp (i=pilgrim@nat/google/x-62ddf1c3c9981c37) (Read error: 110 (Connection timed out))
  162. # [03:14] * Joins: yod (n=ot@softbank221018155222.bbtec.net)
  163. # [03:21] * Joins: markp__ (n=pilgrim@12.108.175.130)
  164. # [03:21] * markp__ is now known as markp
  165. # [03:21] * Joins: tantek_ (n=tantek@207.47.10.130.static.nextweb.net)
  166. # [03:24] * Quits: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  167. # [03:28] * Quits: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
  168. # [03:28] * Quits: markp (n=pilgrim@12.108.175.130) ("Chatzilla 0.9.77-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  169. # [03:30] * Joins: syp (n=syp@lasigpc9.epfl.ch)
  170. # [03:34] * moeffju is now known as moeffju[ZzZz]
  171. # [03:38] * Quits: othermaciej (i=mjs@nat/apple/x-124d6cb76aa60452)
  172. # [03:41] * Quits: tantek (n=tantek@63.sub-75-208-32.myvzw.com) (Read error: 110 (Connection timed out))
  173. # [03:44] * Joins: othermaciej (i=mjs@nat/apple/x-f6df7b2826c6a11b)
  174. # [03:45] * Quits: othermaciej (i=mjs@nat/apple/x-f6df7b2826c6a11b) (Client Quit)
  175. # [03:45] * Quits: tantek_ (n=tantek@207.47.10.130.static.nextweb.net)
  176. # [03:46] * Quits: aroben (i=adamrobe@nat/apple/x-bda0ad40c354afcc)
  177. # [03:50] * Joins: othermaciej (i=mjs@nat/apple/x-32348e995cd1243a)
  178. # [04:06] * Quits: othermaciej (i=mjs@nat/apple/x-32348e995cd1243a) (Connection timed out)
  179. # [04:40] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  180. # [04:43] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Client Quit)
  181. # [05:08] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  182. # [05:10] * Joins: tantek (n=tantek@208.34.118.237)
  183. # [05:17] * Joins: KevinMarks (n=KevinMar@host194.diegoman59.hyatthsiagx.com)
  184. # [05:21] * Quits: tantek (n=tantek@208.34.118.237)
  185. # [05:24] * Joins: aroben (n=adamrobe@adsl-70-231-234-244.dsl.snfc21.sbcglobal.net)
  186. # [05:25] * Quits: aroben (n=adamrobe@adsl-70-231-234-244.dsl.snfc21.sbcglobal.net) (Remote closed the connection)
  187. # [05:25] * Joins: aroben (n=adamrobe@adsl-70-231-234-244.dsl.snfc21.sbcglobal.net)
  188. # [05:26] * Joins: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com)
  189. # [05:46] * Quits: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com) (Read error: 110 (Connection timed out))
  190. # [05:55] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  191. # [06:06] * Disconnected
  192. # [06:06] * Attempting to rejoin channel #whatwg
  193. # [06:06] * Rejoined channel #whatwg
  194. # [06:06] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  195. # [06:06] * Set by Hixie on Thu Mar 22 01:25:40
  196. # [06:10] * Quits: webben (n=benh@91.84.131.217)
  197. # [06:22] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  198. # [06:37] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  199. # [06:39] * Quits: zcorpan_ (n=zcorpan@84-216-41-128.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  200. # [06:59] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  201. # [08:04] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  202. # [08:15] * Joins: webben (n=benh@91.84.131.217)
  203. # [08:31] * Joins: met_ (n=Martin@b14-4.vscht.cz)
  204. # [08:33] * Quits: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  205. # [08:37] <Hixie> hm
  206. # [08:37] <Hixie> so
  207. # [08:37] <Hixie> if currentLoop = 3
  208. # [08:37] <Hixie> and loopCount = 5
  209. # [08:37] <Hixie> and position is between loopStart and loopEnd
  210. # [08:37] <Hixie> and you set loopCount to 2
  211. # [08:37] <Hixie> what should happen?
  212. # [08:38] <Hixie> should it just set currnetLoop to 2 and let it finish on to end?
  213. # [08:39] <aroben> Hixie: I think that makes sense
  214. # [08:39] <aroben> Hixie: loopCount seems like the kind of thing that would only come into play when deciding whether to start a new loop
  215. # [08:40] <othermaciej> another possibility would be to stop immediatly
  216. # [08:40] <othermaciej> but what you suggested is probably better
  217. # [08:44] <Hixie> k
  218. # [08:45] * Quits: aroben (n=adamrobe@adsl-70-231-234-244.dsl.snfc21.sbcglobal.net)
  219. # [09:01] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  220. # [09:09] <krijnh> http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php
  221. # [09:09] <krijnh> \o/
  222. # [09:10] <Hixie> if you agree with me and maciej about meetings being a bad idea, feel free to actually say so on the survey page
  223. # [09:10] <krijnh> Yeah, sorry
  224. # [09:11] <Hixie> it seems that despite many people telling me they agree, nobody actually said anything except maciej :-)
  225. # [09:11] <krijnh> Well, there are issues; http://www.w3.org/html/wg/il16
  226. # [09:11] <krijnh> But I don't know how telcons work ;)
  227. # [09:11] <krijnh> I know the concept
  228. # [09:11] <krijnh> But I don't know how/if it would help
  229. # [09:12] <Hixie> i guess we'll find out thursday
  230. # [09:12] <Hixie> anyway, sleep time
  231. # [09:12] <Hixie> nn
  232. # [09:12] <krijnh> Exactly
  233. # [09:12] <krijnh> Good night :)
  234. # [09:12] <othermaciej> krijnh: I think the odds are very slim of a telecon leading to useful progress on those issues
  235. # [09:12] <krijnh> I think so too
  236. # [09:12] <othermaciej> I wonder if I should reply at all to the complaints about too much mail
  237. # [09:12] <krijnh> But it's not based on experience, just a feeling
  238. # [09:13] <othermaciej> at some point someone has to say, "this is what it will be like, suck it up, learn what threads to follow and whom to pay attention to"
  239. # [09:13] <othermaciej> but better tools for some things may also help
  240. # [09:13] <othermaciej> I think right now the conversation wanders due to lack of clarity on how to start
  241. # [09:13] <othermaciej> whatwg list actually seems more focused currently
  242. # [09:24] * Quits: karlUshi (n=karl@dhcp-246-23.mag.keio.ac.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
  243. # [09:24] * Quits: webben (n=benh@91.84.131.217) (Client Quit)
  244. # [09:32] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  245. # [09:47] * Quits: yod (n=ot@softbank221018155222.bbtec.net) ("Leaving")
  246. # [09:51] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  247. # [09:52] * Joins: KevinMarks (n=KevinMar@1433ahost168.starwoodbroadband.com)
  248. # [09:55] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  249. # [10:03] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  250. # [10:04] * Joins: webben (i=benh@nat/yahoo/x-40dd6b5ca71663f4)
  251. # [10:05] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  252. # [10:06] * Joins: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com)
  253. # [10:08] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  254. # [10:08] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  255. # [10:08] * mw22____________ is now known as mw22
  256. # [10:26] * Joins: marcosc (n=chatzill@131.181.148.226)
  257. # [10:35] * Joins: bzed (n=bzed@dslb-084-059-114-234.pools.arcor-ip.net)
  258. # [11:05] * Joins: hendry (n=hendry@91.84.53.136)
  259. # [11:08] * Joins: ravenn (n=ravenn@203-214-133-148.perm.iinet.net.au)
  260. # [11:11] * Quits: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com) ("later")
  261. # [11:20] * Joins: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp)
  262. # [11:27] * Quits: KevinMarks (n=KevinMar@1433ahost168.starwoodbroadband.com) ("The computer fell asleep")
  263. # [11:39] * Joins: ROBOd (n=robod@86.34.246.154)
  264. # [11:47] * Quits: Lachy_ (n=chatzill@220-245-91-147.static.tpgi.com.au) ("Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919]")
  265. # [11:59] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  266. # [12:07] * othermaciej is now known as om_sleep
  267. # [12:16] * Parts: tomboh (n=tom@dsl-62-3-122-102.zen.co.uk)
  268. # [12:57] * Quits: webben (i=benh@nat/yahoo/x-40dd6b5ca71663f4) (Read error: 110 (Connection timed out))
  269. # [13:11] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  270. # [13:11] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  271. # [13:30] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
  272. # [13:36] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  273. # [13:36] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  274. # [13:45] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  275. # [13:45] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  276. # [13:46] * moeffju[ZzZz] is now known as moeffju
  277. # [13:58] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  278. # [13:59] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  279. # [14:01] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  280. # [14:11] * Parts: ravenn (n=ravenn@203-214-133-148.perm.iinet.net.au)
  281. # [14:31] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  282. # [14:38] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  283. # [15:20] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 131 (Connection reset by peer))
  284. # [15:20] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  285. # [15:23] * moeffju is now known as moeffju[Work]
  286. # [15:27] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  287. # [15:27] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  288. # [15:47] * bzed is now known as bzed|afk
  289. # [15:49] * Joins: maikmerten (n=maikmert@T7084.t.pppool.de)
  290. # [15:49] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  291. # [15:50] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  292. # [15:51] <maikmerten> hmm... I guess I'm the only one with a Firefox that directly jumps to <audio> on http://www.whatwg.org/specs/web-apps/current-work/#video (hmmm... konqueror does it right)
  293. # [15:53] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  294. # [15:53] <Philip`> maikmerten: That's because there are three elements with id="video" - I believe Hixie said he's fixed it in his working copy
  295. # [15:53] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  296. # [15:53] <maikmerten> ah, okay, sorry for the noise then
  297. # [15:55] * Quits: moeffju[Work] (i=moeffju@ubermutant.net) (Read error: 104 (Connection reset by peer))
  298. # [15:57] <maikmerten> as for the audio codecs: It definately makes sense to require PCM in .wav... that should be playable on basically every platform out there that somehow can turn bits into audible noise
  299. # [15:58] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 54 (Connection reset by peer))
  300. # [15:58] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  301. # [15:59] <maikmerten> however, if you want to go over board with specifying there may be room to e.g. require integer based PCM (8 and 16 bit... not float based PCM) and if someone feels like being uber-specifc there's always the question of µ-law vs. a-law ;)
  302. # [15:59] <maikmerten> just in case the final spec turns out to be not long enough ;)
  303. # [16:00] <krijnh> Philip`: I've turned compression on for the irc logs
  304. # [16:00] <krijnh> Hope it speeds up a bit
  305. # [16:03] <Philip`> krijnh: Looks good - thanks!
  306. # [16:04] <Philip`> With a 95KB (uncompressed) log from yesterday, it takes 2.5 seconds to download without compression and 1.2 seconds with compression
  307. # [16:04] <krijnh> Wow, from 64493 bytes to 17009 :|
  308. # [16:04] <krijnh> Sweet
  309. # [16:05] <krijnh> Thanks for the tip Philip` :)
  310. # [16:14] * Joins: Charl (n=Charl@spotter.nmmu.ac.za)
  311. # [16:14] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  312. # [16:19] <krijnh> Hey Charl
  313. # [16:30] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  314. # [16:32] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  315. # [16:36] * Joins: ericcarlson (i=ericcarl@nat/apple/x-23168eee7bd8a648)
  316. # [16:42] <Charl> krijnh: hi there
  317. # [16:43] <krijnh> Charl: also enabled zlib.output_compression on Miranda, let me know if WP for standards.za.net has trouble with that
  318. # [16:46] <Charl> krijnh: thanks will do
  319. # [16:54] * om_sleep is now known as othermaciej
  320. # [16:57] * weinig|bbl is now known as weinig
  321. # [17:01] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  322. # [17:07] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  323. # [17:07] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  324. # [17:07] * Joins: briansuda (n=briansud@bokd046.rhi.hi.is)
  325. # [17:10] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  326. # [17:10] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 54 (Connection reset by peer))
  327. # [17:14] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  328. # [17:14] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  329. # [17:21] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  330. # [17:21] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  331. # [17:25] * Quits: met_ (n=Martin@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  332. # [17:29] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  333. # [17:42] * Quits: briansuda (n=briansud@bokd046.rhi.hi.is)
  334. # [17:47] * Joins: KevinMarks (n=KevinMar@host194.diegoman59.hyatthsiagx.com)
  335. # [17:48] * Parts: marcosc (n=chatzill@131.181.148.226)
  336. # [17:50] * Joins: briansuda (n=briansud@bokd046.rhi.hi.is)
  337. # [18:01] * weinig is now known as weinig|away
  338. # [18:03] * bzed|afk is now known as bzed
  339. # [18:13] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  340. # [18:28] <Hixie> yeah
  341. # [18:28] <Hixie> we need a way of updating the labels
  342. # [18:29] <Hixie> charl and zcorpan are working on that i think
  343. # [18:29] <Hixie> the script has been getting progressively cooler :-)
  344. # [18:30] * Joins: tylerr (n=tylerr@outbound.wa1.ascentium.com)
  345. # [18:30] <Lachy> ok, moving from #html-wg. I've thought about it a bit more, and the major problem with image maps is the lack of ability to style <area> elements in browsers, whcih is really a CSS issue
  346. # [18:30] <tylerr> Morning folks.
  347. # [18:30] <Hixie> ah
  348. # [18:30] <Hixie> yeah
  349. # [18:30] <tylerr> Hey there Lachy, just jumped in and I wanted to say I agree with you on the image maps.
  350. # [18:31] <Lachy> my use case that I had to implement earlier today was a world map where hovering over each country had a hover effect
  351. # [18:31] * Lachy is looking up the flash version I'm converting to HTML
  352. # [18:33] <Lachy> http://australia-revealed.com/index2.html (sorry, you have to go the long way cause it's flash) --> click Programming tab (bottom) then "Outback Cowbys" (top), and finally "Schedule" (right)
  353. # [18:34] <tylerr> Ah nice, so you'd like to be able to style the polygonal selections. That'd be beautiful if implemented.
  354. # [18:34] * Joins: aroben (n=adamrobe@adsl-70-231-234-244.dsl.snfc21.sbcglobal.net)
  355. # [18:35] * Quits: aroben (n=adamrobe@adsl-70-231-234-244.dsl.snfc21.sbcglobal.net) (Client Quit)
  356. # [18:35] <tylerr> That map is cool. :-)
  357. # [18:35] <Lachy> I had a look at the DOM inspector in Mozilla today and showed weird styles for the area elements. it listed styles that applied to the map element instead
  358. # [18:38] <Lachy> anyway, I should go to bed. have fun at the CSSWG meeting, cya later :-)
  359. # [18:38] <tylerr> Night Lachy.
  360. # [18:39] * Joins: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
  361. # [18:40] * Quits: briansuda (n=briansud@bokd046.rhi.hi.is)
  362. # [18:44] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  363. # [18:44] <Hixie> Lachy: nn
  364. # [18:44] <Hixie> Lachy: i agree with your use case
  365. # [18:44] <Hixie> Lachy: i think it's a csswg issue
  366. # [18:44] <Hixie> or xbl
  367. # [18:44] <Hixie> at least not a core html issue
  368. # [18:46] <tylerr> So folks, anything exciting on schedule for today?
  369. # [18:49] <Charl> Hixie: yeah we are working on the labels; things are going a little slow from my side at the moment because i'm struggling with getting connectivity from home
  370. # [18:49] <Charl> Hixie: if all goes well that should be sorted within the next week
  371. # [18:49] <Hixie> no worries
  372. # [18:49] <Charl> one of those perks of staying in africa i guess ;)
  373. # [18:50] <Charl> thanks
  374. # [18:50] <Hixie> :-)
  375. # [18:51] * Quits: hendry (n=hendry@91.84.53.136) ("leaving")
  376. # [18:55] <Lachy> Hixie, it's actually an issue I sort of brought up on www-style back in 2004 :-)
  377. # [18:57] <Lachy> http://lists.w3.org/Archives/Public/www-style/2004Feb/0529 (geez, it's funny to look at the kind of things I wrote back then)
  378. # [19:00] <Hixie> yeah i usually find that my old e-mails are weird to me
  379. # [19:00] <Hixie> i often find i totally agree with everything i wrote, all the arguments and everything, and get a totally different conclusion
  380. # [19:02] <Lachy> well, that one was back when I was young and naiive, and focussed on solutions rather than use cases - the same thing I complain about with newbies today ;-)
  381. # [19:02] <Hixie> heh
  382. # [19:02] <Hixie> my problem used to be ignoring the real world
  383. # [19:03] <Hixie> i'd suggest things that are ideally correct but wouldn't actually be implementable without difficulties
  384. # [19:03] * Joins: moeffju (i=moeffju@ubermutant.net)
  385. # [19:03] * Quits: Charl (n=Charl@spotter.nmmu.ac.za)
  386. # [19:04] <Lachy> yeah, that'd be where that blog entry about people who don't realise they're wrong came from
  387. # [19:04] <Hixie> yup
  388. # [19:04] <Lachy> anyway, really off to bed this time, cya (again)
  389. # [19:04] <Hixie> nn
  390. # [19:06] * Joins: aroben (i=adamrobe@nat/apple/x-66389958ce19629d)
  391. # [19:09] * Joins: jacobolus (n=jacobolu@1cc-dhcp-157.media.mit.edu)
  392. # [19:10] * Joins: ign (n=as@84-107-154-93.dsl.quicknet.nl)
  393. # [19:11] * Quits: aroben (i=adamrobe@nat/apple/x-66389958ce19629d) (Remote closed the connection)
  394. # [19:12] * Joins: aroben (i=adamrobe@nat/apple/x-b26ae52a6188f822)
  395. # [19:13] <jacobolus> hi. question about block/inline links. I have some chunk of content that I want to turn into a single link. I made it an <a></a>, and then stuck a bunch of block elements inside of that. This seems to work just fine in Webkit/Gecko, but the w3c validator of course doesn't like it
  396. # [19:13] <jacobolus> so is there any way to make a block element with an href, or is there another mechanism to make a block element act as a link?
  397. # [19:13] <jacobolus> without resorting to javascript?
  398. # [19:14] <jacobolus> (actually, it seems that webkit will even accept nested <a></a> elements, which can be kinda fun ;) )
  399. # [19:15] <jacobolus> Hixie: maybe you have some idea?
  400. # [19:16] <Hixie> what's the content?
  401. # [19:16] <jacobolus> a div, and a ul
  402. # [19:16] <jacobolus> with a thumbnail and a description
  403. # [19:16] <Hixie> ah, then no, not really
  404. # [19:17] <jacobolus> so we should just use javascript?
  405. # [19:17] <Dashiva> Or turn each part of it into a link
  406. # [19:17] <Hixie> turning each part into a link is probably best
  407. # [19:17] <jacobolus> how to turn each part into a link?
  408. # [19:17] <jacobolus> we want the whole background to be clickable
  409. # [19:18] <Dashiva> That's trickier
  410. # [19:18] <Hixie> i'd recommend making one part into an explicit link, and then using an onclick handler on the outer box to make that link get followed
  411. # [19:18] * jacobolus pasted http://pastie.textmate.org/49849
  412. # [19:18] <jacobolus> here's our example
  413. # [19:18] <Dashiva> But it reminds me of something else. Often you want to make a link which looks like a standard UA button. How about a predefined class which styles an <a> to look like <input type="button"> or <button>?
  414. # [19:19] <Hixie> just use a button :-P
  415. # [19:19] <jacobolus> i guess we could just make the title and the image clickable.
  416. # [19:20] <jacobolus> it's just kind of a drag to require putting the href in twice
  417. # [19:20] <Hixie> i'd make the title be the <a>
  418. # [19:20] <Hixie> and then put a <div> around the whole thing
  419. # [19:20] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  420. # [19:20] <Hixie> and make that have an onclick which does
  421. # [19:20] <Dashiva> Hixie: Buttons don't have hrefs, typically
  422. # [19:20] <Hixie> onclick="location = this.getElementsByTagName('a')[0].href"
  423. # [19:21] <Hixie> Dashiva: they do in WF2 (well it's called action="", but same idea)
  424. # [19:21] <Hixie> Dashiva: <form><button action="foo.html">Go!</button></form>
  425. # [19:21] <Hixie> or in HTML4, even:
  426. # [19:21] <jacobolus> Hixie: but then that has to be written in every div? or we have to add that with javascript?
  427. # [19:21] <Hixie> <form action="foo.html"><button>Go!</button></form>
  428. # [19:22] <Hixie> jacobolus: yeah each <a> in your current example would be replaced by a <div onclick="location = this.getElementsByTagName('a')[0].href">
  429. # [19:22] <jacobolus> yeah. that's kinda ugly. i guess we can have some javascript add that on page load or something
  430. # [19:22] <jacobolus> but the existing markup is very clean
  431. # [19:22] <Hixie> yeah
  432. # [19:23] <Hixie> we're looking at allowing <a> in other places
  433. # [19:23] <jacobolus> or we could just let it be invalid :) (but maybe that's a bad idea)
  434. # [19:24] <krijnh> jacobolus: just invalidate it; http://krijnhoetmer.nl/stuff/html5/block-level-anchors/ :)
  435. # [19:25] <jacobolus> wouldn't want to incur the wrath of the w3c ;)
  436. # [19:25] <krijnh> Ow, wait, me neither, use the onclick thingy ;)
  437. # [19:26] <jacobolus> krijnh: good to know it works in every browser though :)
  438. # [19:26] <krijnh> Didn't test on a Mac
  439. # [19:26] <jacobolus> seems to work in firefox/camino/safari
  440. # [19:27] <jacobolus> krijnh: wait, are all the boxes on that page supposed to be green?
  441. # [19:27] <krijnh> Doesn't in Lynx :(
  442. # [19:27] <jacobolus> krijnh: should the top two be green?
  443. # [19:27] <krijnh> Well, should
  444. # [19:27] <krijnh> I don't know
  445. # [19:27] <krijnh> The bottom three are
  446. # [19:27] <krijnh> But they have a { display: block; } applied
  447. # [19:28] <jacobolus> right
  448. # [19:28] <jacobolus> krijnh: maybe you should clarify that?
  449. # [19:28] <krijnh> Yeah, I should, sorry I'm not that good at clarifying things
  450. # [19:29] <krijnh> Most stuff in, well, /stuff/, isn't clarified :)
  451. # [19:29] <jacobolus> fair enough :)
  452. # [19:29] * Joins: othermaciej (i=mjs@nat/apple/x-912fd99491e83248)
  453. # [19:29] <jacobolus> Hixie: so, how fearful is the wrath of the w3c?
  454. # [19:29] <Hixie> the top two shouldn't be green without display:block no
  455. # [19:29] <Hixie> hey maciej
  456. # [19:29] <Hixie> jacobolus: ?
  457. # [19:29] <othermaciej> hey Hixie
  458. # [19:30] <jacobolus> Hixie: rather, how fearful should we be of teh wrath of the w3c
  459. # [19:30] <jacobolus> nevermind :P
  460. # [19:30] <Hixie> we = whatwg?
  461. # [19:30] <krijnh> jacobolus: There is none
  462. # [19:30] <jacobolus> no, we = content authors :)
  463. # [19:30] <othermaciej> what wrath of the w3c?
  464. # [19:31] <krijnh> othermaciej: when using <a><block-level></a>
  465. # [19:31] <krijnh> Invalid ^
  466. # [19:31] <othermaciej> well, that's invalid but works
  467. # [19:32] <krijnh> Yeh
  468. # [19:32] <othermaciej> Hixie: anne, hsivonen, marcos__ and I came up w/ this last night, any comments before I send it to the html wg list: http://esw.w3.org/topic/HTML/ProposedDesignPrinciples
  469. # [19:32] <krijnh> Hixie: How does Googlebot handle that btw?
  470. # [19:32] <csarven> is it true that `textarea` doesn't format the characters in utf-8?
  471. # [19:33] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  472. # [19:34] <Hixie> othermaciej: i had a comment on #html-wg
  473. # [19:34] <Hixie> 18:29 < Hixie>|http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html might be a good place to start for design principles (re earlier conversation)
  474. # [19:36] <othermaciej> Hixie: a lot of the items there already exist under different names; I'll try to incorporate any that are not reflected or that are insufficiently clear as stated
  475. # [19:36] <Hixie> cool
  476. # [19:37] <othermaciej> "Backwards compatibility, clear migration path" is, I think, the same basic thing as "Don't Break The Web" / "Degrade Gracefully"
  477. # [19:37] <gsnedders> othermaciej: I think it may be sensible to have something about some sort of basic forwards compatibility
  478. # [19:37] <othermaciej> though the latter is less focused on IE6 and doesn't go into detail about how working in unsupported browsers might make use of script, style, bindings, etc
  479. # [19:38] <othermaciej> gsnedders: what do you mean by forwards compatibility?
  480. # [19:39] <gsnedders> othermaciej: things like specifying whether unknown elements should be put in DOM, whether they should be block or inline, whether they can be styled, etc.
  481. # [19:39] <moeffju> +1
  482. # [19:39] <othermaciej> gsnedders: I think that would fall under "degrade gracefully"
  483. # [19:40] <othermaciej> you need a rule for unknown elements to be able to count on consistent handling of them as features are added
  484. # [19:40] <gsnedders> othermaciej: possibly. I'd assume degrade would mean already existing things, though, unless explicitly said
  485. # [19:40] * Joins: s|k (n=bjorn@ip70-171-201-121.tc.ph.cox.net)
  486. # [19:41] <othermaciej> well, yes, it's not mainly about second-guessing what things can be in future specs
  487. # [19:41] <s|k> er
  488. # [19:41] <s|k> which should we be using
  489. # [19:41] <s|k> in the future, xhtml or html?
  490. # [19:41] <othermaciej> HTML4 already says what to do with unknown elements (they are in the DOM, inline, and can be styled)
  491. # [19:41] <s|k> I had no idea there was an html 5 planned
  492. # [19:42] <othermaciej> s|k: in the present, you should probably be using html, in the future, who knows what will happen?
  493. # [19:42] <kingryan> there is no xhtml
  494. # [19:42] * kingryan waves hand sideways
  495. # [19:43] <s|k> I've been using xhtml for years now
  496. # [19:43] <s|k> even though IE doesn't understand text/xhtml
  497. # [19:43] <gsnedders> s|k: ignoring lack of support of IE and GoogleBot?
  498. # [19:43] <s|k> ;\
  499. # [19:43] <gsnedders> text/xhtml?
  500. # [19:43] <gsnedders> no such MIME type…
  501. # [19:43] <s|k> doesn't it work with firefox?
  502. # [19:44] <gsnedders> if it works with anything, I'll be amazed.
  503. # [19:44] <gsnedders> application/xhtml+xml is the XHTML MIME type
  504. # [19:44] <s|k> well that's what I meant
  505. # [19:44] <gsnedders> rather large difference…
  506. # [19:44] <s|k> hrm
  507. # [19:45] <s|k> wait no I generally do text/xml for xml
  508. # [19:45] <s|k> should I be doing application?
  509. # [19:45] <s|k> using*
  510. # [19:45] <gsnedders> text/xml MUST have the content-type specified at the transport level, if it isn't ISO-8859-1
  511. # [19:45] <gsnedders> wait… US-ASCII
  512. # [19:45] <s|k> I'm getting a lot of strange characters from you
  513. # [19:45] <s|k> wait⦠US-ASCII
  514. # [19:46] <gsnedders> any encoding in the prolog is meaningless
  515. # [19:46] <gsnedders> s|k: all the messages I'm sending are UTF-8
  516. # [19:46] * Joins: hober (n=ted@unaffiliated/hober)
  517. # [19:47] <s|k> xhtml works for me just fine
  518. # [19:47] <s|k> and I prefer it to html
  519. # [19:47] <gsnedders> I prefer support of major UAs.
  520. # [19:48] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  521. # [19:48] * mw22____________ is now known as mw22
  522. # [19:48] <gsnedders> XHTML as text/html relies on UAs not following the spec
  523. # [19:48] <s|k> well will HTML 5 feature the same benefits of xml? device independence? easily integrated into new applications?
  524. # [19:48] <s|k> if the web were valid xhtml, my life would be really easy
  525. # [19:48] <Hixie> othermaciej: for backcompat in particular it's critical to explain exactly what is meant
  526. # [19:48] <Hixie> othermaciej: i usually think of it as three separate things:
  527. # [19:49] * Joins: zcorpan_ (n=zcorpan@84-216-42-228.sprayadsl.telenor.se)
  528. # [19:49] <Dashiva> If everybody instantly changed to using unicode variants everywhere, that would help a lot too
  529. # [19:49] <Dashiva> But I doubt it'll happen overnight, or even over the decade
  530. # [19:49] <Hixie> othermaciej: uas implementing the new spec should be able to handle old docs without any differences
  531. # [19:49] <othermaciej> Hixie: right now we have two separate things (maybe 4 depending on how you count)
  532. # [19:50] <othermaciej> that one is the "Don't Break The Web" principle - old content should work in UAs implementing the new spec
  533. # [19:50] <Hixie> othermaciej: docs written to the old spec should be able to have features from the new spec added without unrelated changes
  534. # [19:50] <gsnedders> s|k: how is XML device independent? how is it easily integrated?
  535. # [19:50] <othermaciej> I don't think that one is expressed
  536. # [19:51] <othermaciej> I added
  537. # [19:51] <othermaciej> "Handle Errors" and a more general "Well-Defined Behavior"
  538. # [19:51] <s|k> gsnedders: every language and framework I develop in has very powerful xml integration
  539. # [19:52] <zcorpan_> benoitt's <document> proposal is <iframe> with controller="" (or ui="" or whatever)
  540. # [19:52] <Hixie> othermaciej: and old uas should be able to render content using new features in ways that aren't fatal - you should be able to write new docs that provide equivalent although not necessarily as wonderful functionality
  541. # [19:52] <Hixie> to old uas, i mean
  542. # [19:52] <gsnedders> s|k: well, surely that's more up to the languages and frameworks to provide the integration?
  543. # [19:52] <Hixie> i.e. graceful degradation
  544. # [19:52] <s|k> gsnedders: with xhtml I have the option of using xpath and xquery
  545. # [19:52] <s|k> and DOM
  546. # [19:52] <Hixie> which i assume you have
  547. # [19:52] <s|k> and etc
  548. # [19:52] <othermaciej> that one is "Degrade Gracefully"
  549. # [19:53] <gsnedders> s|k: the issue of namespaces in HTML is unresolved. DOM is a separate standard, and has rules for HTML already
  550. # [19:54] <s|k> gsnedders: my point is that from a developer perspective, XML is better supported, at least in the tools I work with, than SGML and HTML. There are more options, and more flexibility, and it's more readable
  551. # [19:54] <s|k> that last part though is subjective
  552. # [19:54] <s|k> I know
  553. # [19:54] <othermaciej> there's nothing specific about being able to use new features without unrelated changes
  554. # [19:55] <othermaciej> nothing specific about scripting, avoiding profiles, or open process
  555. # [19:56] <othermaciej> I don't think open process is a design principle
  556. # [19:56] <gsnedders> s|k: writing a spec you can do little about support. if languages chose to support it, so be it. HTML5, not being based on SGML, will be easier to parse
  557. # [19:56] <s|k> oh it's not based on SGML?
  558. # [19:56] <othermaciej> I think many of the stated principles imply and assume that scripting is ok, not sure if it needs to be called out again
  559. # [19:56] <gsnedders> no
  560. # [19:56] <s|k> what's it based on?
  561. # [19:56] <gsnedders> s|k: itself
  562. # [19:56] <s|k> I see
  563. # [19:56] <othermaciej> also, profiling html is clearly out of scope for the group
  564. # [19:57] <hasather> s|k: it's based on browser practice
  565. # [19:57] <s|k> uh oh
  566. # [19:57] <gsnedders> s|k: most documents (including all XHTML served as text/html) rely on browser's error handling, which goes against SGML. HTML5 is partly about standardising error correction
  567. # [19:57] <s|k> I get that comment about User Agents gsnedders was making now
  568. # [19:57] <s|k> well I am all for standardizing the error correction
  569. # [19:57] <gsnedders> s|k: in both cases, both WHATWG and W3C's HTML WG, will have both XML and HTML serialisations of the standard
  570. # [19:58] <s|k> personally I wish browsers didn't correct errors
  571. # [19:58] <s|k> ahhhh
  572. # [19:58] <s|k> I get it
  573. # [19:58] <s|k> it's like RDF
  574. # [19:58] <s|k> and the dublin core
  575. # [19:58] <gsnedders> how?
  576. # [19:58] <s|k> it can have an xml schema
  577. # [19:59] <s|k> or it can have some other implementation
  578. # [19:59] <s|k> it's implementation independent I guess
  579. # [19:59] <s|k> or am I misunderstanding it?
  580. # [19:59] <gsnedders> it can only have two serialisations
  581. # [19:59] <s|k> oh okay
  582. # [20:01] <othermaciej> Hixie: I added the third form of compatibility as "Evolution Not Revolution"
  583. # [20:01] <othermaciej> "Don't Reinvent The Wheel" and "Pave The Cowpaths" are arguably also forms of compatibility (in the sense of compatibility with existing practice)
  584. # [20:03] * Quits: tylerr (n=tylerr@outbound.wa1.ascentium.com) (Read error: 104 (Connection reset by peer))
  585. # [20:04] <Dashiva> I support cowpaths
  586. # [20:06] <Philip`> Hixie: Have you had any feedback on the canvas globalCompositeOperation since http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-June/006771.html ? (If not, I believe I could write up something useful about how it is / should be implemented)
  587. # [20:06] <kingryan> othermaciej, Hixie: this is all sounding very familiar (http://microformats.org/wiki/microformats) :D
  588. # [20:07] <othermaciej> kingryan: not entirely an accident
  589. # [20:07] <kingryan> :D
  590. # [20:11] <othermaciej> not really quite the same though
  591. # [20:15] * Quits: KevinMarks (n=KevinMar@host194.diegoman59.hyatthsiagx.com) (Read error: 60 (Operation timed out))
  592. # [20:17] <zcorpan_> if the spec has SHOULD requirements for support of various other things, would we need to write test cases for those as well in order to move beond CR?
  593. # [20:18] <zcorpan_> if so, then i think such a list should just be non-normative guidelines
  594. # [20:19] <zcorpan_> such a list may become obsolete in 15 years from now too
  595. # [20:20] <othermaciej> I'm not sure how much it makes sense to test SHOULD-level requirements
  596. # [20:21] <gsnedders> zcorpan_: for which WG?
  597. # [20:21] <zcorpan_> othermaciej: fair enough
  598. # [20:21] <Hixie> Philip`: in meeting, dunno, there's lots of canvas feedback i haven't yet dealt with but feel free to send more
  599. # [20:22] <Hixie> othermaciej: so long as you have descriptions as well as the titles :-)
  600. # [20:23] <othermaciej> Hixie: there are descriptions
  601. # [20:23] <Hixie> good good :-)
  602. # [20:23] <Hixie> ship it
  603. # [20:25] * Joins: KevinMarks (n=KevinMar@host194.diegoman59.hyatthsiagx.com)
  604. # [20:42] * Joins: aroben_ (i=adamrobe@nat/apple/x-c1170fb588102453)
  605. # [20:49] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  606. # [20:54] <zcorpan_> "Error handling should be defined interoperably.", is this some construction of english i don't understand or is the sentence wrong? shouldn't it be "Error handling should be defined so that interoperable implementations can be achieved." or something like that?
  607. # [20:59] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  608. # [20:59] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  609. # [20:59] <othermaciej> zcorpan_: that sounds better
  610. # [20:59] <othermaciej> zcorpan_: please feel free to improve it
  611. # [21:03] * Quits: aroben (i=adamrobe@nat/apple/x-b26ae52a6188f822) (Read error: 110 (Connection timed out))
  612. # [21:05] * othermaciej is now known as om_lunch
  613. # [21:09] * Quits: maikmerten (n=maikmert@T7084.t.pppool.de) ("Leaving")
  614. # [21:16] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 54 (Connection reset by peer))
  615. # [21:16] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  616. # [21:25] * Joins: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
  617. # [21:27] <zcorpan_> om_lunch: ok
  618. # [21:27] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 131 (Connection reset by peer))
  619. # [21:28] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  620. # [21:36] * Joins: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com)
  621. # [21:39] * om_lunch is now known as othermaciej
  622. # [21:40] * Joins: hendry (n=hendry@91.84.53.136)
  623. # [21:42] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  624. # [21:45] * aroben_ is now known as aroben
  625. # [21:45] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  626. # [21:47] * Joins: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  627. # [21:56] * Quits: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 110 (Connection timed out))
  628. # [22:01] <jacobolus> Hixie: go here (http://dev.laptop.org/pub/content/newlib/) and click on math & science
  629. # [22:01] * Quits: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  630. # [22:01] * Quits: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  631. # [22:01] <jacobolus> Hixie: i think we'll just go with the invalid markup (block a's) for now
  632. # [22:01] * Joins: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
  633. # [22:01] * Joins: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
  634. # [22:02] <jacobolus> the rest of that page is of course in various stages of disrepair :)
  635. # [22:03] * Quits: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net) (Client Quit)
  636. # [22:08] * Parts: s|k (n=bjorn@ip70-171-201-121.tc.ph.cox.net)
  637. # [22:17] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  638. # [22:20] * Joins: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
  639. # [22:26] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 131 (Connection reset by peer))
  640. # [22:26] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  641. # [22:43] * Quits: ign (n=as@84-107-154-93.dsl.quicknet.nl)
  642. # [22:50] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 104 (Connection reset by peer))
  643. # [22:51] * Quits: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net) (Remote closed the connection)
  644. # [22:52] * Joins: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
  645. # [22:52] * Quits: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com) ("later")
  646. # [22:53] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  647. # [23:04] <Hixie> hmm
  648. # [23:04] * Quits: ericcarlson (i=ericcarl@nat/apple/x-23168eee7bd8a648)
  649. # [23:04] <Hixie> if someone sets loopCount to 0, we should ignore it? or raise an exception?
  650. # [23:05] <othermaciej> probably good to clamp it to 1 or greater
  651. # [23:05] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  652. # [23:06] <othermaciej> I'm not a big fan of exceptions on property setting
  653. # [23:15] * Joins: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  654. # [23:24] * Joins: webben (n=benh@91.84.131.217)
  655. # [23:26] * Quits: Hixie (n=ianh@trivini.no) ("Lost terminal")
  656. # [23:27] * Joins: KevinMarks (n=KevinMar@host194.diegoman59.hyatthsiagx.com)
  657. # [23:27] * Joins: Hixie (n=ianh@trivini.no)
  658. # [23:34] <webben> Does/could HTML5 have any sort of official profiling system for UAs? such that one might have graphical UAs with a certain profile (e.g. support for PNG, OGG, Vorbis), end-user UAs which provide certain UI functionality, etc? would that be useful or un-useful?
  659. # [23:34] <webben> (just looking through recent discussions re <video>
  660. # [23:35] <othermaciej> HTML5 is against profiles
  661. # [23:35] <webben> what does it mean to be against profiles?
  662. # [23:35] <othermaciej> some sort of baseline integration spec for desktop browsers might be interesting, but I don't know who would have motive to make it
  663. # [23:36] <webben> what's the difference between the two?
  664. # [23:36] <webben> (or do you mean HTML5 is against, but profiles might still be useful?)
  665. # [23:36] <Lachy> profiling segregates the web into websites built for one type of UA, and other other web sites for everything else
  666. # [23:36] <Lachy> it's already happening with the mobile profile, for instance
  667. # [23:36] <hsivonen> webben: do you mean that the browser would advertise its capabilities to server or scripts? or do you mean requiring implementors to ship particular features in one go?
  668. # [23:37] <webben> hsivonen: primarily the later actually
  669. # [23:37] <hsivonen> webben: won't work
  670. # [23:37] <Lachy> that wouldn't work in practice
  671. # [23:37] <webben> hsivonen: i don't think authors should depend on featuresets: e.g. they should have text fallbacks
  672. # [23:37] <hsivonen> webben: HTML5 is being implemented piecemeal
  673. # [23:37] <Lachy> again, mobiles are attempting it and failing miserably
  674. # [23:38] <webben> hsivonen: well sure, but one could build profiles piecemeal too
  675. # [23:38] <hsivonen> webben: which is a bit of a problem for the usefulness of conformace checking against the full spec
  676. # [23:38] <othermaciej> it would be good to have an agreement among implementors for something to target
  677. # [23:38] <othermaciej> right now there is a super vague rough almost-consensus
  678. # [23:38] * Quits: bzed (n=bzed@dslb-084-059-114-234.pools.arcor-ip.net) ("Leaving")
  679. # [23:39] <webben> it would be interesting to have actual targets set (e.g. (say) implement a given CSS3 module by date X)
  680. # [23:39] <webben> perhaps
  681. # [23:39] * bewest would be shocked to see MS agree to such a thing
  682. # [23:39] <webben> agreed by at least the major non-IE browsers
  683. # [23:39] <webben> bewest: MS is a special case.
  684. # [23:39] <Lachy> I'd like to see all browsers ship <video> support within 12 to 18 months
  685. # [23:39] <bewest> yes
  686. # [23:40] <bewest> the market distribution would have to change
  687. # [23:40] <hsivonen> othermaciej: it would certainly be nice for authors to have Opera, Apple and Mozilla implement the features roughly in the same order instead of each vendor implementing different pieces during the transitional period
  688. # [23:40] <othermaciej> it would be nice to see a complete and correct implementation of CSS 2.1
  689. # [23:40] <othermaciej> in even one browser, let alone all
  690. # [23:40] <webben> bewest: thinking of Outlook 2007, MS is doing okay as long as they don't go backwards ;)
  691. # [23:40] <bewest> then it seems highly impractical
  692. # [23:40] <othermaciej> hsivonen: it's not really practical for us to synch schedules, let alone priorities
  693. # [23:40] <Lachy> webben, what? Outlook 2007 is backwards
  694. # [23:40] <webben> othermaciej: that's less important actually than implementing the same things
  695. # [23:40] <webben> Lachy: that's what i mean
  696. # [23:41] <Lachy> oh, ok
  697. # [23:41] <hsivonen> I don't disagree about what would be nice, I just don't believe Hixie could enforce requirements on vendor schedules and priorities
  698. # [23:41] <bewest> sure
  699. # [23:41] <webben> othermaciej: e.g. at the end of the day, more helpful to ordinary authors to implement a common subset of CSS than to implement different subsets in pursuit of complete implementation
  700. # [23:41] <othermaciej> we do talk to each other
  701. # [23:41] <Lachy> I don't think it would be worth enforcing in a spec either
  702. # [23:41] <othermaciej> but we are also competitors to some extent and don't have identical goals
  703. # [23:41] <bewest> we == (vendors - MS)?
  704. # [23:41] <webben> othermaciej: sure. But anything like this would have to work through areas of consensus.
  705. # [23:42] <othermaciej> of course any feature that becomes popular will more likely see rapid implementation in other browsers
  706. # [23:42] <webben> (hopefully stuff like CSS, PNG, XBL support is an area of consensus)
  707. # [23:42] <bewest> I suppose you could come up with some kind of consumer group that rates things, much like consumer reports
  708. # [23:42] <bewest> and they could enforce timelines for a particular kind of rating
  709. # [23:42] <othermaciej> well, afaik no browser has complete/correct CSS 2.1, even though that is the rough consensus target for CSS
  710. # [23:43] <othermaciej> PNG is generally agreed, but there are details
  711. # [23:43] <Lachy> if, e.g. WF2 was implemented in FF, it would start taking off
  712. # [23:43] <bewest> but that's completely different from a standards body doing such a thing
  713. # [23:43] <othermaciej> for instance, only Safari respects embedded color profiles in PNGs
  714. # [23:43] <webben> maybe ... SVG and MathML aren't exactly taking off and they're implemented in FF (and XForms too with an addon)
  715. # [23:43] <webben> (admittedly the MathML implementation is presentational)
  716. # [23:44] <Lachy> SVG and MathML can't really be used in HTML and aren't backwards compatible with IE
  717. # [23:44] <hsivonen> othermaciej: my vanity feed suggests that PNG color management in Safari causes confusion :-/
  718. # [23:44] <Lachy> WF2 was designed with back compat in mind
  719. # [23:44] <othermaciej> SVG is seeing implementation in other browsers
  720. # [23:44] <webben> Lachy: I suspect a decent JS implementation of WF2 is much more important than FF support.
  721. # [23:44] <webben> all authors need is a plugin toolkit a la scriptalicious or something
  722. # [23:45] <webben> because that's what will be needed for IE
  723. # [23:45] <Lachy> yeah, unfortunately, the current WF2 script is horrible
  724. # [23:45] <othermaciej> hsivonen: part of the problem is that we don't do colormatching for untagged images
  725. # [23:45] <Lachy> anyway, I gotta go
  726. # [23:45] <Lachy> cya
  727. # [23:45] * Joins: zcorpan (n=zcorpan@84-216-41-107.sprayadsl.telenor.se)
  728. # [23:45] <hsivonen> othermaciej: actually, not doing color management for untagged images is the Right Thing. people were more upset pre-Tiger, when you did
  729. # [23:47] <othermaciej> hsivonen: colormatching for everything would be good
  730. # [23:47] <hsivonen> othermaciej: shipping OS X with 2.2 gamma default would be a far easier fix
  731. # [23:47] <othermaciej> hsivonen: we don't do it for untagged images in part because we can't get plugin changes to match
  732. # [23:47] <othermaciej> hsivonen: well that's out of my hands
  733. # [23:48] <othermaciej> anyway, colormatching, whoo hoo
  734. # [23:49] <hsivonen> othermaciej: I don't object to all-encompassing opt-in color management
  735. # [23:49] <othermaciej> just an example of how listing something you support doesn't give very strong guarantees
  736. # [23:53] <webben> but a consensus group could articulate whether to support stuff like color management
  737. # [23:53] <webben> perhaps such things actually work better separately from the specs
  738. # [23:53] <webben> since in practice browser makers pick and choose what to implement any how
  739. # [23:54] <hsivonen> I had one very confrontational situation at WWDC 2005 and it was with the prepress guy who seriously dislike me voicing my opinion about color management default in WebKit
  740. # [23:54] <othermaciej> color management is a quality-of-implementation issue
  741. # [23:54] <webben> why not push for implementation of color management elsewhere?
  742. # [23:54] <othermaciej> so it's not clear agreement is necessary or good
  743. # [23:55] <webben> or is safari's implementation broken in some way?
  744. # [23:55] <othermaciej> it would be like agreeing exactly how to rasterize text
  745. # [23:55] <webben> (don't know much about the details of PNG so I don't really know what the issue is)
  746. # [23:55] <hsivonen> othermaciej: my point was that color consistency within a page is more important than color managing a piece of the page
  747. # [23:55] <othermaciej> windows doesn't really have good color management APIs, so it would be hard to do there
  748. # [23:55] <hsivonen> in general to be safe, that is.
  749. # [23:55] <webben> how does photoshop do it on win then?
  750. # [23:55] <othermaciej> hsivonen: that's why we don't do colormatching for untagged images (well, that and the perf hit)
  751. # [23:56] <othermaciej> but for a tagged image, it's likely to look terrible if you do no colormatching, and it is assumed the author has expressed a preference for color "correctness" over consistency
  752. # [23:59] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net) (Read error: 104 (Connection reset by peer))
  753. # [23:59] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  754. # [23:59] <jacobolus> hsivonen: untagged images should be assumed to be sRGB
  755. # [23:59] * Quits: zcorpan_ (n=zcorpan@84-216-42-228.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  756. # Session Close: Wed Mar 28 00:00:00 2007

The end :)