/irc-logs / freenode / #whatwg / 2007-04-26 / end

Options:

  1. # Session Start: Thu Apr 26 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:05] * Quits: aroben (i=adamrobe@nat/apple/x-ed7d8d94febecfe1) (Read error: 110 (Connection timed out))
  4. # [00:07] * Parts: fantasai (i=fantasai@connectionreset.info)
  5. # [00:10] * othermaciej is now known as om_bubble_tea
  6. # [00:14] * Joins: ajnewbold_ (n=adam@74-129-102-1.dhcp.insightbb.com)
  7. # [00:14] * Joins: aroben (i=adamrobe@nat/apple/x-63d1d0bf44c3856d)
  8. # [00:15] * Quits: aroben_ (i=adamrobe@nat/apple/x-5fbfa52c380a14ca) (Read error: 104 (Connection reset by peer))
  9. # [00:16] * Joins: aroben_ (i=adamrobe@nat/apple/x-0948547b089bdafd)
  10. # [00:17] * Quits: aroben (i=adamrobe@nat/apple/x-63d1d0bf44c3856d) (Nick collision from services.)
  11. # [00:17] * aroben_ is now known as aroben
  12. # [00:18] <Hixie> hm, cool, tbl said he'd be on the call tomorrow
  13. # [00:19] * Quits: webben (n=benh@82.153.134.109) (Client Quit)
  14. # [00:20] <bewest> hrm email says 5pm. I wonder which timezone
  15. # [00:21] <bewest> oh I see
  16. # [00:21] <bewest> who's invited?
  17. # [00:21] * bewest is guessing invited experts aren't invited in general
  18. # [00:21] <Hixie> didn't you get the mail on the list?
  19. # [00:21] <bewest> I'm looking at list email
  20. # [00:21] <Hixie> http://lists.w3.org/Archives/Public/public-html/2007Apr/1458.html
  21. # [00:22] <Hixie> http://www.w3.org/2002/09/wbs/40318/tel26Apr/
  22. # [00:22] <gavin_> to more directly answer your question, and WG member is invited
  23. # [00:22] <gavin_> that includes Invited Experts
  24. # [00:23] <bewest> yeah, I'm looking at that email... following the references now
  25. # [00:23] <bewest> oh WG Participants are invited
  26. # [00:23] <bewest> I thought member means something special
  27. # [00:24] <Dashiva> Member with capital m does
  28. # [00:24] <bewest> ok thanks
  29. # [00:24] <Dashiva> W3C Member, as opposed to WG members
  30. # [00:28] <bewest> Hixie: when someone submits some feedback, there are basically two possibilities, correct? 1.) you respond relatively quickly or 2.) it goes on some queue
  31. # [00:28] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  32. # [00:29] <bewest> if there is no immediate response, is there some way to know if my feedback has been noticed and that I should simply wait?
  33. # [00:29] <Hixie> it's always noticed
  34. # [00:29] <bewest> ah
  35. # [00:29] <Hixie> but if you really want me to check, i can check :-)
  36. # [00:30] <Hixie> (anything sent to whatwg@whatwg.org that isn't replied to and isn't inane ends up in my folders)
  37. # [00:31] <bewest> ah
  38. # [00:31] <bewest> I'm specifically talking about http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010924.html
  39. # [00:32] <Hixie> yeah, that's e-mail 109 of 119 in INBOX.input-for-whatwg-WF2
  40. # [00:32] <bewest> ok
  41. # [00:33] * ajnewbold_ sends the latest hot pharmaceutical offer to whatwg@whatwg.org
  42. # [00:33] <Hixie> qv. inane. :-)
  43. # [00:33] <ajnewbold_> :P
  44. # [00:41] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.2 (IRC client for Emacs)")
  45. # [00:43] * Quits: polin8_ (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net) (Client Quit)
  46. # [00:45] * om_bubble_tea is now known as othermaciej
  47. # [01:05] * Joins: polin8 (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net)
  48. # [01:16] * Quits: Toolskyn (n=toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Remote closed the connection)
  49. # [01:18] * ajnewbold_ is now known as fax_machine
  50. # [01:21] * Quits: aroben (i=adamrobe@nat/apple/x-0948547b089bdafd) (Read error: 110 (Connection timed out))
  51. # [01:34] * Joins: aroben (i=adamrobe@nat/apple/x-08b8f2c0d879516b)
  52. # [01:34] * Quits: aroben (i=adamrobe@nat/apple/x-08b8f2c0d879516b) (Remote closed the connection)
  53. # [01:35] * Joins: aroben (i=adamrobe@nat/apple/x-6b3df944726390dc)
  54. # [01:47] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  55. # [02:10] * Quits: polin8 (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net)
  56. # [02:35] * Quits: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  57. # [02:45] * Quits: h3h (n=h3h@66-162-32-234.static.twtelecom.net) ("|")
  58. # [02:58] * Joins: aroben_ (i=adamrobe@nat/apple/x-184c416ecbd9e624)
  59. # [03:02] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (Read error: 104 (Connection reset by peer))
  60. # [03:07] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  61. # [03:13] * Quits: aroben (i=adamrobe@nat/apple/x-6b3df944726390dc) (Read error: 110 (Connection timed out))
  62. # [03:14] * moeffju[Away] is now known as moeffju[ZzZz]
  63. # [03:34] * aroben_ is now known as aroben
  64. # [03:35] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  65. # [03:44] * Quits: othermaciej (i=mjs@nat/apple/x-0ef24a7be1840312)
  66. # [03:50] * Quits: zcorpan (n=zcorpan@84-216-43-232.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  67. # [03:51] * Joins: othermaciej (i=mjs@nat/apple/x-dd26b09620efc084)
  68. # [03:52] * Quits: othermaciej (i=mjs@nat/apple/x-dd26b09620efc084) (Client Quit)
  69. # [04:18] * Quits: bzed (n=bzed@dslb-084-059-125-190.pools.arcor-ip.net) (Remote closed the connection)
  70. # [04:20] * Joins: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  71. # [04:30] * Quits: sgillies (n=chatzill@dsl-179-116.dynamic-dsl.frii.net) (Read error: 104 (Connection reset by peer))
  72. # [04:36] * Joins: sgillies (n=chatzill@dsl-179-116.dynamic-dsl.frii.net)
  73. # [05:39] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  74. # [05:47] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  75. # [06:07] * Joins: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net)
  76. # [06:43] * Quits: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  77. # [06:51] * Joins: karlUshi (n=karl@133.27.246.11)
  78. # [08:46] * Joins: annevk (n=annevk@86.90.70.28)
  79. # [08:56] * Joins: MikeSmith (n=MikeSmit@IP-193-159-214-250.y-lan.t-online.net)
  80. # [09:04] * Joins: Toolskyn (n=toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  81. # [09:32] <annevk> Flex is open source now...
  82. # [09:33] * Quits: karlUshi (n=karl@133.27.246.11) ("Where dwelt Ymir, or wherein did he find sustenance?")
  83. # [09:33] <annevk> Product competition: Company A does C. Really big company B starts doing C as well. A makes their version of C open source.
  84. # [09:36] <virtuelv> annevk: well, I don't really think Really big company B will do the same
  85. # [09:37] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("brb")
  86. # [09:37] * Joins: KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net)
  87. # [10:19] * moeffju[ZzZz] is now known as moeffju
  88. # [10:27] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
  89. # [10:27] * Joins: othermaciej_ (n=mjs@c-71-202-121-192.hsd1.ca.comcast.net)
  90. # [10:32] * Joins: met_ (n=Hassman@b14-4.vscht.cz)
  91. # [10:36] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  92. # [10:44] <hsivonen> annevk: whoa! URL to Flex announcement? what about Flash player?
  93. # [10:44] <annevk> http://labs.adobe.com/wiki/index.php/Flex:Open_Source
  94. # [10:44] <annevk> (not sure about announcements)
  95. # [10:44] <annevk> (not sure about Flash either)
  96. # [10:44] <annevk> MPL for those who care
  97. # [10:45] * hsivonen hopes they mean the tri-license like Dirac when they say MPL
  98. # [10:46] <hsivonen> annevk: thanks
  99. # [10:46] * Quits: othermaciej_ (n=mjs@c-71-202-121-192.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  100. # [10:46] <annevk> not sure about that
  101. # [10:47] <annevk> but i didn't investigate much
  102. # [10:47] <hsivonen> considering that Flash player in itself is not sold, Flash benefits from maximum deployment, MS is doing Silverlight and GNU Gnash is getting serious, it would make sense to open-source Flash Player
  103. # [10:47] <annevk> you are mistaken
  104. # [10:47] <annevk> Flash is sold
  105. # [10:48] <hsivonen> annevk: the player? to handset makers?
  106. # [10:48] <annevk> yes, yes
  107. # [10:49] <othermaciej> so what exactly does Flex do?
  108. # [10:50] <hsivonen> othermaciej: dunno exactly. looks like a Flash app development kit.
  109. # [10:50] <othermaciej> but it has a markup lanaguage
  110. # [10:50] * Joins: ROBOd (n=robod@86.34.246.154)
  111. # [10:50] <othermaciej> and isn't just the normal flash authoring
  112. # [10:50] <othermaciej> afaik
  113. # [10:51] <hsivonen> hmm. looks like they are releasing parts that their Flex customers would see and build on anyway
  114. # [10:52] <krijnh> MXML!
  115. # [10:52] <othermaciej> corporate-driven open source is hard
  116. # [10:52] <annevk> WebKit is not?
  117. # [10:53] <annevk> or Mozilla for that matter... or do you mean something else?
  118. # [10:54] <othermaciej> WebKit and Mozilla are hard, yes
  119. # [10:54] <othermaciej> and I think Adobe has less clue about how to run an open source project
  120. # [10:54] <krijnh> So now we can all use Flex for free?
  121. # [10:56] <hsivonen> krijnh: only the libs and the compiler, it seems. The IDE will stay proprietary
  122. # [10:56] <krijnh> We can write MXML ourselves, don't we? :)
  123. # [10:58] * othermaciej is now known as om_sleep
  124. # [11:20] * Quits: MikeSmith (n=MikeSmit@IP-193-159-214-250.y-lan.t-online.net) (Read error: 104 (Connection reset by peer))
  125. # [11:20] * Joins: billyjack (n=MikeSmit@IP-193-159-214-250.y-lan.t-online.net)
  126. # [11:27] * Joins: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  127. # [11:33] * Quits: om_sleep (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  128. # [11:55] <met_> my friend David Majda prepared 5 > 2 wallpapers http://whatwg.majda.cz/wallpapers/
  129. # [11:56] <annevk> lol, deployed
  130. # [11:57] <met_> my destop already has it 8-)
  131. # [11:57] <met_> there is also svg original
  132. # [12:11] * Joins: a-ja (n=chatzill@70.230.166.247)
  133. # [12:13] <a-ja> hsivonen: ping
  134. # [12:17] * Joins: bzed (n=bzed@dslb-084-059-117-156.pools.arcor-ip.net)
  135. # [12:21] * Parts: a-ja (n=chatzill@70.230.166.247)
  136. # [12:54] * Joins: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp)
  137. # [12:58] <Lachy> www-html is just getting funnier every day :-) http://www.w3.org/mid/FBABED17-C3FA-4AB8-8942-4BD169FE298A@nickshanks.com
  138. # [12:59] <nickshanks> hilarious isnt it?
  139. # [12:59] * Joins: zcorpan (n=zcorpan@84-216-40-4.sprayadsl.telenor.se)
  140. # [13:00] <Lachy> his argument is self defeating
  141. # [13:01] <Lachy> "... and moreover, that [versioning] cannot be retro-actively be applied to an extant format."
  142. # [13:01] <nickshanks> his = "Philip & Le Khanh" or me?
  143. # [13:01] <annevk> you, I think
  144. # [13:01] <Lachy> oh, that's you! Yes, your argument :-)
  145. # [13:01] <krijnh> lol
  146. # [13:01] <annevk> but I'm not sure Lachy realized that
  147. # [13:01] <annevk> right
  148. # [13:01] <Lachy> I didn't notice the name on the email
  149. # [13:02] * annevk guessed it by the link Lachy pasted
  150. # [13:02] <annevk> users don't blame sites very often
  151. # [13:02] <annevk> they are not actually aware that sites are the problem
  152. # [13:03] <zcorpan> really?
  153. # [13:03] <nickshanks> then make users aware "This website is broekn, it's not an MSIE probelem"
  154. # [13:03] <zcorpan> i hear general complaints about sites sucking or not working all the time
  155. # [13:03] <Lachy> nickshanks, attempting to introduce draconian error handling like you suggest into HTML5 simply wouldn't work, even if it were a good idea
  156. # [13:03] <nickshanks> gah, can't spell :)
  157. # [13:05] <nickshanks> whilst it doesn't have to prevent the site for being displayed, it helps if it is inconvenient for the owners and preferably insults them soehow
  158. # [13:05] <Lachy> but your solution affects the end users, not just developers
  159. # [13:05] <annevk> sounds lovely
  160. # [13:06] <Lachy> give developers tools and browser extensions that notify them of such errors, but don't inflict such errors upon unsuspecting users
  161. # [13:07] <annevk> halting problem makes lots of errors unlikely to be catched anyway
  162. # [13:07] <Lachy> a lot of errors can be caught by tools, though
  163. # [13:08] <annevk> sure
  164. # [13:08] <nickshanks> develoeprs shouldn't need seperate rools
  165. # [13:08] <zcorpan> wow, first spam since we modified the register page
  166. # [13:08] <zcorpan> in the forums
  167. # [13:08] <annevk> nickshanks, what do you mean with separate?
  168. # [13:08] <Lachy> nickshanks, end users don't need developer tools in their browsers
  169. # [13:09] <annevk> people should make it more clear I think that quirks/standards is just an if else switch at some specific places in the code
  170. # [13:09] <nickshanks> the browser *should* inconvenience users, or at least make it clear to them that the owners of the website are stupid
  171. # [13:09] <annevk> not an if else switch for the entire rendering engine
  172. # [13:09] <nickshanks> then the website owners will be inundated with complaints, and they will fix it!
  173. # [13:09] <annevk> nickshanks, maybe in nickshanks pipe dream land
  174. # [13:10] <Lachy> nickshanks, why? You won't help anyone, just inconvenience users and tech support staff
  175. # [13:10] <annevk> handling errors is pretty trivial anyway
  176. # [13:10] <nickshanks> for 1 day, yes, then once the error is corrected there won't be a problem anymore
  177. # [13:10] <annevk> errors are not really the problem
  178. # [13:11] <annevk> the problem is browser sniffing
  179. # [13:11] <nickshanks> and most importantly, web devs will learn to write better code
  180. # [13:11] <annevk> and browser sniffing we won't get around by silly editing tools because it's needed as long as we don't get better interop
  181. # [13:11] <virtuelv> hm. there is one thing irking me with new elements
  182. # [13:11] <virtuelv> given <unknwonelement><p>Other Element</p></unknownelement>
  183. # [13:12] <annevk> virtuelv, that should give the DOM you want
  184. # [13:12] <Lachy> just look at the kind of nonsense that end users ask when presented with errors they don't understand http://lists.w3.org/Archives/Public/www-html-editor/2007JanMar/0053.html
  185. # [13:12] * Quits: fax_machine (n=adam@unaffiliated/faxmachine/x-838442)
  186. # [13:12] <virtuelv> annevk: not in IE
  187. # [13:12] <annevk> virtuelv, right
  188. # [13:12] <annevk> that's indeed problematic
  189. # [13:12] <annevk> but workarounds have been found (you made one yourself, no?)
  190. # [13:12] <virtuelv> you get unknownelement, p #text, /unknownelement
  191. # [13:12] <nickshanks> Lachy: well the task of writing error messages that peasants can understand i leave to someone else
  192. # [13:13] <virtuelv> annevk: if you're talking about my DOM autocorrector, that's a horrible, horrible, horrible hack not deemed fit for any consumption
  193. # [13:13] <Lachy> nickshanks, you can't just present an idea and expect someone else to do all the work
  194. # [13:13] <annevk> the idea that things can always be error free is just flawed imo
  195. # [13:13] <virtuelv> it involves recreating the entire DOM where elements whose names start with / occur
  196. # [13:13] <annevk> virtuelv, people have put more horrible hacks in real world usage
  197. # [13:13] <nickshanks> Lachy: i'm happy to do the work if a web vendor will hire me :)
  198. # [13:14] <annevk> if it's such a great idea maybe you should implement it yourself and earn millions...
  199. # [13:14] <annevk> </sarcasm>
  200. # [13:14] <Lachy> you could always write up a detailed proposal, explain the pros and cons of the ideas and do research to support your claims.
  201. # [13:15] <nickshanks> strictness has to be implemented in existing browsers, basically MSIE and Firefox, others can follow later
  202. # [13:15] <Lachy> If you can prove beyond all reasonable doubt that browsers should implement your idea, it might get done
  203. # [13:15] <nickshanks> Lachy: i was hoping the common sense in my argument would be enough
  204. # [13:15] <Lachy> what common sense?
  205. # [13:15] <zcorpan> 98 new messages in one day :| seems it just gets more and more...
  206. # [13:15] <annevk> 98?
  207. # [13:15] * annevk wonders if he missed them all
  208. # [13:16] <zcorpan> that's what i'm fetching now
  209. # [13:16] <Lachy> maybe zcorpan's spam filter blocked out some of the more annoying contributors :-)
  210. # [13:16] <nickshanks> Lachy: that if we let web developer continue producing tag soup, and not actively prevent them from reaching their customers until they conform, web developers will continue to output crap HTML 5, 6, 7 etc
  211. # [13:16] <zcorpan> Lachy: if only :)
  212. # [13:17] <Lachy> oh, 1495 mails on public-html this month!
  213. # [13:17] <zcorpan> a 0 decisions made so far, right?
  214. # [13:17] <zcorpan> s/a /and /
  215. # [13:18] * Lachy checks his tally
  216. # [13:18] <Lachy> yep, 0!
  217. # [13:18] <zcorpan> now that's productive
  218. # [13:18] <annevk> nickshanks, just like browsers will continue with crap interop for the newer features
  219. # [13:19] <annevk> although <canvas> interop is way better than <object>, to be fair
  220. # [13:20] * Joins: welly (n=george@spc1-harg2-0-0-cust244.seac.broadband.ntl.com)
  221. # [13:20] <Lachy> nickshanks, your argument seems to make the false assumption that all HTML is produced by competent web developers
  222. # [13:20] <welly> lol
  223. # [13:20] <nickshanks> i think going forward vendor interop will be much better than before, the problem lies with HTML authors not realising they are making mistakes because their web browser doesn't yell at them - to many devs, opening the page in IE *is* validation of their efforts
  224. # [13:21] <annevk> nickshanks, having some weird error handling on syntax doesn't help with that
  225. # [13:21] <Lachy> nickshanks, yep
  226. # [13:22] <Lachy> nickshanks, the best we can do is encourage authoring tools to produce better content and promote web standards more among professional web developers
  227. # [13:23] <nickshanks> i disagree: the best we can do is persuade MS that silent recovery from errors is detrimental to both users and IE itself in the longer term
  228. # [13:23] <annevk> that's not the problem with IE
  229. # [13:23] <annevk> the problem is that web authors do browser sniffing
  230. # [13:23] <annevk> (and have to, atm)
  231. # [13:24] <nickshanks> the problem is it's 80% market share? ;)
  232. # [13:24] <annevk> no
  233. # [13:24] <Lachy> how is silent recovery detrimental to users?
  234. # [13:24] <annevk> the problem is lack of interop
  235. # [13:24] <annevk> error recovery is just some silly side debate that's hardly relevant imo
  236. # [13:24] <Lachy> getting interop in browsers for all content, whether it's valid or not, is a much more realisting approach than saying they should reject invalid content
  237. # [13:25] <Lachy> s/realisting/realistic/
  238. # [13:25] <nickshanks> Lachy: because when a web dev only tests in IE, and doesn't see that he has errors, he won't know that other browsers handle things correctly and what he sees is incorrect
  239. # [13:25] <Lachy> that's why we need interop!
  240. # [13:25] <Lachy> not why we need draconian error handlnig
  241. # [13:26] <nickshanks> i would rather have both
  242. # [13:26] <zcorpan> nickshanks: use xml
  243. # [13:26] <Lachy> and then serialise as HTML5 before sending to the end users
  244. # [13:26] <nickshanks> zcorpan: i can't force the creators of every website I visit to do that
  245. # [13:27] <annevk> you can't force them to use your utopia language either
  246. # [13:27] <Lachy> nickshanks, why do you want to force your development tools and opinions on the creators of every web site
  247. # [13:27] <zcorpan> right. if you bring drocanian error handling to html, how do you force the creators of every website I visit to fix their errors?
  248. # [13:27] <Lachy> how does someone else's broken code affect you?
  249. # [13:27] <nickshanks> not my tools, they can use any tools they like (as long as they are black)
  250. # [13:28] <annevk> you're just being silly
  251. # [13:28] <virtuelv> "nickshanks> Lachy: that if we let web developer continue producing tag soup, and not actively prevent them from reaching their customers until they conform, web developers will continue to output crap HTML 5, 6, 7 etc"
  252. # [13:28] <nickshanks> Lachy: because websites don't work in Safari, but work in MSIE which I can't use
  253. # [13:28] <virtuelv> nickshanks: they will continue outputting crap no matter what we tell them
  254. # [13:28] <Lachy> nickshanks, what does the colour of the tool have to do with anything?
  255. # [13:28] * Lachy doesn't understand "as long as they are black"
  256. # [13:28] <nickshanks> virtuelv: you miss my point, it's not what *we* tell them, it's what the browser they test in tells them
  257. # [13:28] <virtuelv> and if we go to draconian error handling, all we do is lose content contributed to the web
  258. # [13:28] <annevk> nickshanks, that has to do with browser sniffing
  259. # [13:29] <annevk> nickshanks, not with IE error correction, most likely
  260. # [13:29] <virtuelv> nickshanks: and I'm saying it won't work
  261. # [13:29] <annevk> you should try to find out what the problem is first
  262. # [13:29] <Lachy> nickshanks, that's to do with lack of interop
  263. # [13:29] <annevk> before screaming you found the perfect solution
  264. # [13:29] <nickshanks> Lachy: it's a refernce to the Model T Ford, , Henry Ford said "You can have any colour you like, as long as it's black." (which was the only colour he offered it in)
  265. # [13:29] * zcorpan goes read his mail instead
  266. # [13:30] * Lachy suggests that nickshanks join the XHTML2WG, who share similar ideas
  267. # [13:31] <annevk> good point
  268. # [13:31] <nickshanks> it doesn't have to prevent display of the site XML-style, just display enough of an error message that CEOs won't allow their web developers to get away with it
  269. # [13:32] <annevk> IE has done that for quite some time
  270. # [13:32] <annevk> and that has been widely ignored
  271. # [13:32] <Lachy> yes, with javascript errors
  272. # [13:32] <Lachy> and so many sites still have errors
  273. # [13:33] <nickshanks> then it doesn't inconvenience a website's customers enough
  274. # [13:33] <Lachy> why do you want to hurt the customers?
  275. # [13:33] <nickshanks> because that's unacceptable to the people in control
  276. # [13:33] <nickshanks> so they won't let it happen on their site
  277. # [13:34] <nickshanks> (i am mostly thinking of commercial sites here)
  278. # [13:34] <Lachy> browsers will not implement such a user hostile approach
  279. # [13:35] <nickshanks> (since they drive a lot of the money in web development)
  280. # [13:35] <nickshanks> Lachy: that's why it needs to be co-ordinated and mandatory (both for vendors and users)
  281. # [13:35] <annevk> you can't mandate UI
  282. # [13:35] <Lachy> inflicting error messages upon end users is simply unacceptable
  283. # [13:36] <annevk> that browsers have implemented the UI for XML that they did, well... dunno why they did that
  284. # [13:36] <Lachy> unless you have a solution that doesn't involve innocent by-standers, this debate is over
  285. # [13:36] <nickshanks> would you rather limp around on a gangrenous leg for the rest of your life, or have it amputated before it gets infected?
  286. # [13:36] <annevk> I suppose it keeps people away from using XML
  287. # [13:36] <nickshanks> HTML will last for 100 years or more
  288. # [13:37] <annevk> yes, including all old content
  289. # [13:37] <nickshanks> anne: no, wrong
  290. # [13:37] <Lachy> nickshanks, I don't understand your analogy
  291. # [13:37] <nickshanks> most old content gets updated
  292. # [13:37] <Lachy> wrong!
  293. # [13:37] <virtuelv> nickshanks: most content on the web is static
  294. # [13:37] <nickshanks> a few years of hurt between 2008 and 2010 won't matter to people in 2050, but continuing to permit tag soup in perpetuity will
  295. # [13:38] * Lachy doesn't think nickshanks understands all the implications of his own ideas
  296. # [13:38] <nickshanks> virtuelv: most content on the web going forward is generated by content management systems
  297. # [13:39] <Lachy> nickshanks, do you have evidence to support that claim?
  298. # [13:39] <nickshanks> updating the CMS to output better code will cause all pages it generates (including old content) to immediatly take on the new code
  299. # [13:40] <Lachy> I can assure you that there is a heck of a lot of content that is not output by a CMS
  300. # [13:40] <nickshanks> Lachy: obviously I haven't collected data from 2050, but lets draw an alalogy from the rail industry
  301. # [13:40] <nickshanks> there used to be many competing gauges of track that were interoperable
  302. # [13:40] <Lachy> nickshanks, I'm asking for evidence from the web, as it is *today*
  303. # [13:40] <nickshanks> they converged on one size
  304. # [13:41] <Lachy> what's your point?
  305. # [13:42] <annevk> so the other problem with your idea about showing an error for <input type=silly> is that we can then never introduce such a control in the future
  306. # [13:42] <annevk> because it would break older clients
  307. # [13:42] <nickshanks> we currently have many websites that use non-interoperable code, i want to get them to converge, rather than have browsers try and handle everything
  308. # [13:42] <annevk> silent error recovery implies a nice extensibility story
  309. # [13:42] <Lachy> nickshanks, pave the cowpaths
  310. # [13:43] <annevk> having silent error recovery for the syntax means the same thing
  311. # [13:43] <nickshanks> annevk: in a versioned document format you can, which is why I advocated versioning along with error display
  312. # [13:44] <annevk> versioning is a very silly idea
  313. # [13:44] <annevk> implementing 38 variants of HTML is just not nice
  314. # [13:44] <Lachy> nickshanks, versioning implies that UAs will implement different processing for each version, and that becomes unworkable because you get an increasing number of versions to maintain
  315. # [13:44] <Lachy> to see how harmful versioning is, see the 11 (or more) incompatible versions of RSS!
  316. # [13:44] <nickshanks> then you can start to drop older versions when they become uncommercial
  317. # [13:45] <annevk> i'd suggest you read a bit more into the subject before suggesting these type of things
  318. # [13:45] <Lachy> and how that led to liberal feed parsers that just don't care
  319. # [13:45] <annevk> nickshanks, drop support for content?!
  320. # [13:45] <annevk> while we can actually support it with a saner extensbility story?
  321. # [13:45] <nickshanks> PDF has versioning, Word has versioning, GIF has versioning, practuically every format under the sun does
  322. # [13:45] <annevk> which is easier for authors, user agents, etc.
  323. # [13:45] <annevk> nickshanks, that doesn't imply it's a good thing
  324. # [13:45] <virtuelv> nickshanks: have you even looked at the three most popular CMSes?
  325. # [13:46] <annevk> Word especially is horrible
  326. # [13:46] <virtuelv> There's not a hint of XML in their toolchain, and its not even possible to plug in to the toolchains
  327. # [13:46] <annevk> to open older versions of Word files in Word 2007 you apparently need to change registry settings to circumvent security warnings
  328. # [13:46] <virtuelv> (That goes for blogger, Movable Type and in particular Wordpress
  329. # [13:46] <nickshanks> virtuelv: only wordpress, which i occasionally fix XHTML bugs on
  330. # [13:46] <Lachy> Word is prohibitively expensive, even for MS, to maintian with support for all those different versions
  331. # [13:46] <virtuelv> wordpress is a cancer
  332. # [13:47] <annevk> no
  333. # [13:47] <annevk> wordpress is development as its typically done
  334. # [13:47] <annevk> and probably much better than that
  335. # [13:47] <annevk> we have to take that into account
  336. # [13:47] <annevk> perfection is not attainable
  337. # [13:47] <nickshanks> virtuelv: but think about this - every site running wordpress can update to the latest version and have better quality HTML applied to all their old content
  338. # [13:47] <virtuelv> nickshanks: patentably false
  339. # [13:48] <nickshanks> uhh, no, that's a fact
  340. # [13:48] <Lachy> ah, no, it's not
  341. # [13:48] <virtuelv> there's bunches of wordpress-based hosting services where the users don't control the installs
  342. # [13:48] <nickshanks> i am not saying every site will, but they could
  343. # [13:48] <virtuelv> besides, upgrading wordpress is applying gold paint to a turd
  344. # [13:48] <annevk> heh
  345. # [13:48] * Lachy is tired of this poinless debate
  346. # [13:48] <nickshanks> virtuelv: i'm not aguing about the merits of one CMS over others here
  347. # [13:48] <Lachy> *pointless
  348. # [13:49] <virtuelv> my point is still that "No, CMSes can't easily leverage XML, and in particular the popular end-user ones"
  349. # [13:50] <nickshanks> i'm not talking about XML, just conformant HTML
  350. # [13:50] <virtuelv> that would inflict serious harm on the users of said tools
  351. # [13:50] <virtuelv> which means they would stay with the older versions.
  352. # [13:50] <virtuelv> eod
  353. # [13:50] <annevk> doesn't matter
  354. # [13:51] <nickshanks> how would making their HTML output more conformant cause any harm?
  355. # [13:51] <annevk> checking if something is conforming HTML is mathematically impossible btw
  356. # [13:51] <mpt> nickshanks, if you want Web browsers to switch to draconian error handling, I recommend you take it up with your elected representatives
  357. # [13:51] <mpt> encouraging them to introduce a law requiring that
  358. # [13:52] <annevk> maybe they can solve the halting problem :)
  359. # [13:52] <mpt> because in an unregulated browser market, it will never happen.
  360. # [13:52] <nickshanks> as i have said, draconian error handling is not necessary, just enough to make CEOs prevent their web developers from outputting tag soup
  361. # [13:52] <annevk> i'm still not sure why you think it's a good idea
  362. # [13:53] <annevk> what exactly is the problem we currently have you think would be solved by having this?
  363. # [13:53] <krijnh> Caring developers, and not caring developers
  364. # [13:53] <krijnh> Who cares
  365. # [13:54] * Quits: aroben (i=adamrobe@nat/apple/x-184c416ecbd9e624)
  366. # [13:54] <annevk> heh, stevenp promoting XForms on www-html
  367. # [13:54] <mpt> And no specification, whether from the W3C or the WhatWG or anyone else without force of law, can make it happen.
  368. # [13:55] <mpt> (I am not at all suggesting that draconian error handling is a good idea.)
  369. # [13:55] <nickshanks> annevk: two problems: browser interop, and future development of web specs being hindered by backwards compatibility issues (like that blasted alt tag!) i don't subscribe to XHTML2's view of dropping backwards compatibility, i just want it to be easy to maintain going forward. currently it is not
  370. # [13:55] <annevk> alt tag?
  371. # [13:56] <annevk> 1 can be solved by creating testsuites
  372. # [13:56] <annevk> 2 not sure what you mean
  373. # [13:56] <annevk> seems that development of specs is going forward
  374. # [13:56] <annevk> see Web Applications 1.0
  375. # [13:56] <nickshanks> re alt tag: the fact that img is empty and so cannot have fallback content, thus we're stuck with the alt tag
  376. # [13:57] <annevk> there's no such thing is an alt tag
  377. # [13:57] <nickshanks> oh, bugger
  378. # [13:57] <mpt> That's what I was going to say
  379. # [13:57] <annevk> and the alt attribute works good enough
  380. # [13:57] <nickshanks> attribute :-)
  381. # [13:57] <nickshanks> i meant to say attribute
  382. # [13:57] <mpt> but then I thought, no, Hixie probably knows of a few occurrences of an alt tag :-)
  383. # [13:57] <annevk> heh
  384. # [13:57] <nickshanks> the alt attribute doesn't work good enough at all
  385. # [13:57] <annevk> Maciej proposed that <source> would be named <alt>
  386. # [13:58] <annevk> use <object>
  387. # [13:58] <krijnh> http://www.technorati.com/tag/alt <-- look, an alt tag :p
  388. # [13:58] <mpt> and will have some cheerful factoid such as "<alt> is used 146.2 times more often than <samp>"
  389. # [13:58] <nickshanks> lol @ krijnh
  390. # [13:58] <annevk> no need to debate much about this
  391. # [13:58] <annevk> mpt, hehe
  392. # [13:59] <mpt> nickshanks, the poor fallback for <img> is almost entirely TimBL's fault
  393. # [13:59] <nickshanks> no, it's Marc Anddressen's fault
  394. # [13:59] <nickshanks> as is the "src" attribute. i like vowels damnit
  395. # [13:59] <mpt> nono
  396. # [14:00] <nickshanks> http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html
  397. # [14:00] <mpt> You see, if TimBL hadn't been so worried about people putting pictures of nekkid ladies on the Web, he would have introduced it himself, with a proper fallback model
  398. # [14:00] <nickshanks> oops, one 'd' two 'e's
  399. # [14:00] <mpt> and then marca wouldn't have needed to do it, and so wouldn't have done it hamfistedly
  400. # [14:01] <nickshanks> mpt: yes, but I lay most of the blame at marc's feet
  401. # [14:01] <mpt> History doesn't repeat itself, but it does rhyme: trying to prevent nekkid ladies from appearing on the Web, and trying to introduce draconian (or even partially draconian) error handling on the Web, are both examples of standardistas fighting economic forces
  402. # [14:02] <nickshanks> with hindsight I'm sure TimBL would have created object, image with fallback, video, audio and all the WA 1.0 elements we have now :P
  403. # [14:02] <Lachy> what's this about TimBL being against nekkid ladies on the web?
  404. # [14:02] <nickshanks> i don't blame him for not seeing what the web would become, no-one did
  405. # [14:03] <annevk> <A HREF="..." INCLUDE>See photo</A> is nice
  406. # [14:03] <krijnh> annevk: Nice for?
  407. # [14:04] <nickshanks> i don't think <A INCLUDE> had any more or less merit than <IFRAME>
  408. # [14:05] <krijnh> Ow, duh
  409. # [14:05] <krijnh> annevk: Never mind :)
  410. # [14:05] <mpt> "At a conference, Berners-Lee yelled at Andreessen, telling him that adding images to the Web was going to bring in a flood of new users who would do things like post photos of nude women. 'He was right,' Andreessen now says with a shrug."
  411. # [14:06] <mpt> http://www.usatoday.com/tech/news/2003-03-09-internet_x.htm
  412. # [14:06] <nickshanks> TimBL wouldn't have got a knighthood without internet porn
  413. # [14:07] <annevk> nickshanks, it's the backwards compatible alternative to <img>, <object>, etc. as seen from HTML1 perspective
  414. # [14:07] <krijnh> IE6 wouldn't be here without internet porn..
  415. # [14:07] <Lachy> heh, that's kind of evidence against Bruce Lawson's theory about TimBL
  416. # [14:07] <mpt> which is?
  417. # [14:07] <Lachy> look it up on brucelawson.co.uk
  418. # [14:07] <Lachy> http://www.brucelawson.co.uk/2005/internet-porn/
  419. # [14:08] <mpt> oh, found it
  420. # [14:08] <mpt> @#$^%!
  421. # [14:08] <zcorpan> annevk: but doesn't work nice with linked images
  422. # [14:09] <mpt> When HTML5 becomes widely used, remind me to add "m {everything: inherit}" to my user style sheet
  423. # [14:09] <mpt> These retarded sites who think I want them to highlight the Google search terms -- no, that's what Google Cache is for
  424. # [14:09] <zcorpan> mpt: you forgot !important
  425. # [14:10] <nickshanks> i think the "m" element has too short a name, it's not clear enough to people what it does
  426. # [14:10] <annevk> zcorpan, nested <a>
  427. # [14:10] <Lachy> mpt, that's also what Google Toolbar is for, and many other extensions
  428. # [14:10] <mpt> zcorpan, that'd be necessary only if the author set !important too, wouldn't it?
  429. # [14:10] * Quits: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  430. # [14:10] <Lachy> mpt, no
  431. # [14:10] <zcorpan> mpt: no
  432. # [14:11] <annevk> mpt, yes
  433. # [14:11] <Lachy> the order goes user normal -> author normal -> author !imporant -> user !important
  434. # [14:11] <Lachy> doesn't it?
  435. # [14:11] <annevk> no
  436. # [14:11] * Lachy should look it up
  437. # [14:11] <annevk> yes
  438. # [14:11] <annevk> user -> author -> author !important -> user !important
  439. # [14:12] <Dashiva> UA -> Author -> User -> Author imp -> user imp
  440. # [14:12] <zcorpan> authors style sheet wins over user stylesheet wins over ua style sheet, regardless of specificity... and !important can't be overridden
  441. # [14:12] <Lachy> annevk, that's what I said
  442. # [14:12] <mpt> ok, I was rusty on that part of the cascade
  443. # [14:12] <annevk> whoa
  444. # [14:12] <Dashiva> You switched user and author normal. I wonder if there are any UA rules with !important
  445. # [14:12] * annevk messed it up again
  446. # [14:13] <mpt> though my current USS does use !important
  447. # [14:13] <annevk> Dashiva, there's no such thing as UA style sheet
  448. # [14:13] <annevk> Dashiva, although some UAs do have such a concept
  449. # [14:13] <krijnh> annevk: Don't follow my example to much plz k10x
  450. # [14:13] <Dashiva> Well, even if it's not a stylesheet, they do provide default styles
  451. # [14:13] <Lachy> Dashiva, UA don't have !important rules officially (though FF uses them for things that can't be overridden)
  452. # [14:13] <zcorpan> user style sheet doesn't need to be a style sheet either
  453. # [14:14] <mpt> input[type="file"] {... !important}, I guess
  454. # [14:14] <annevk> krijnh, heh, I got the theory right, but didn't match it accurately against the given case...
  455. # [14:14] <Lachy> Dashiva, you're the one who switch the user and author. annevk and I got it right
  456. # [14:14] <annevk> which is better than the last time I talked about this part of the cascade...
  457. # [14:14] <Lachy> http://www.w3.org/TR/CSS21/cascade.html#cascading-order
  458. # [14:14] <Dashiva> Lachy: Yeah, I noticed just after writing it
  459. # [14:15] <Dashiva> Mixed up user and user agent :/
  460. # [14:15] <annevk> and more...
  461. # [14:17] <annevk> heh, bac then in 93 they also wanted to generalize
  462. # [14:17] <annevk> afraid of people proposing <aud> next week
  463. # [14:17] <nickshanks> annevk: what are you reading?
  464. # [14:17] <annevk> this thread: http://1997.webhistory.org/www.lists/www-talk.1993q1/0202.html
  465. # [14:18] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  466. # [14:18] <annevk> that e-mail contains probably the worst suggestion from an authoring perspective
  467. # [14:18] <annevk> from timbl...
  468. # [14:18] <krijnh> <aud> would be bad cause people could put sounds of nekkid women online ;p
  469. # [14:18] <Lachy> krijnh, accessible porn for the blind! :-)
  470. # [14:18] <annevk> SVG: http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html
  471. # [14:18] <annevk> (or VML, if you wish)
  472. # [14:19] <krijnh> <dialog><dt>Girl</dt><dd>Ah!</dd><dt>Boy</dt><dd>Oeh!</dd><dt>Girl2</dt><dd>Even more ah!</dd></dialog>
  473. # [14:19] <krijnh> Would be great!
  474. # [14:19] * Lachy notes that there is actually an accessible porn site ;-)
  475. # [14:19] <Lachy> http://www.brucelawson.co.uk/index.php/2006/blind-accessible-porn/
  476. # [14:19] <krijnh> I had a possible client mail me for a porn site 2 weeks ago :]
  477. # [14:20] <krijnh> "Cause I knew how to make GoogleBot happy"
  478. # [14:20] <mpt> Then there's the porn sites proudly sporting "W3C valid HTML 4.01" and "W3C valid CSS" badges...
  479. # [14:20] <krijnh> I think I should have accepted it an build the first HTML5 porn site ;p
  480. # [14:21] <nickshanks> krijnh: i'll do it, i need some work
  481. # [14:21] <Lachy> zcorpan, you should make an Valid HTML5! logo specifically for porn sites. (replace the cat with something slightly more appropriate)
  482. # [14:21] <krijnh> nickshanks: he hasn't mailed me back since :)
  483. # [14:21] <krijnh> Yeah, replace it with a pussy
  484. # [14:21] <Lachy> lol
  485. # [14:21] <nickshanks> send him another email for me
  486. # [14:22] <nickshanks> there's a pussy in the corner of ln.hixie.ch
  487. # [14:22] <krijnh> Ow, crap, this chat is logged in public ;]
  488. # [14:22] <krijnh> nickshanks: That's a cat
  489. # [14:22] <Lachy> nickshanks, that's the cat used on the Valid HTML5 logo already
  490. # [14:22] <nickshanks> replace it with a WebKitten ?
  491. # [14:23] * Lachy notified twitter users of our discussion ;-)
  492. # [14:24] <mpt> -cringe-
  493. # [14:25] * Joins: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  494. # [14:25] <mpt> Oh no, Lachy prefers Vegemite to Marmite -- we must now be sworn enemies
  495. # [14:26] <Lachy> mpt, yes
  496. # [14:26] * annevk vaguely recalls he dislikes both
  497. # [14:26] <nickshanks> well he's an aussie, right?
  498. # [14:26] <Lachy> nickshanks, yes
  499. # [14:27] <mpt> So that's what this Twitter thing is
  500. # [14:27] <nickshanks> vegermite is the national food
  501. # [14:27] <Lachy> annevk, did you remember to buy a pack of tim tams and a jar or vegemite before you left Aus?
  502. # [14:27] <mpt> I just spent half a minute trying to figure out why people use it
  503. # [14:27] <nickshanks> (Lachy: it was a rhetoriccal question ;-)
  504. # [14:27] <annevk> Lachy, I got the cookies
  505. # [14:27] <annevk> Lachy, marcos gave them
  506. # [14:28] <Lachy> cool
  507. # [14:28] <nickshanks> i think twitter is some "listen in to everyone's conversations all over the world thing, because one IRC channel at a time is not enough for most people"
  508. # [14:28] <annevk> Lachy, I also got two toy animals (wonbat(sp?) and platypus) and a boomerang...
  509. # [14:28] <annevk> not sure what to do with those, but they looked funny
  510. # [14:29] <Lachy> *wombat
  511. # [14:29] <annevk> right
  512. # [14:29] <mpt> ... And then I realized "ah, the same reason people write Weblogs, but worse"
  513. # [14:30] <mpt> Wow, Guido van Rossum chimed in on the "proposed new tag: IMG" thread
  514. # [14:30] <mpt> small world
  515. # [14:30] <nickshanks> who's he?
  516. # [14:31] <annevk> python
  517. # [14:31] <nickshanks> he's a snake. gotcha.
  518. # [14:31] <mpt> ... bdfl
  519. # [14:32] <mpt> http://en.wikipedia.org/wiki/Guido_van_Rossum
  520. # [14:33] <mpt> annevk, iirc when British zoologists first received a sample of a platypus they thought it was a hoax
  521. # [14:34] <mpt> http://www.museumofhoaxes.com/platypus.html
  522. # [14:34] <nickshanks> heh, not surprising! what would you have thought?
  523. # [14:36] <annevk> first time I heard about the animal was at http://www.ragingplatypus.com/
  524. # [14:36] <annevk> "Raging Platypus - Geeks drink it for breakfast"
  525. # [14:36] <nickshanks> didn't you get taught at school about it?
  526. # [14:37] <annevk> don't think so
  527. # [14:38] <nickshanks> odd. being the only mammal to lay eggs it usually gets a mention in Biology classes here in the UK
  528. # [14:38] <krijnh> Blinky Bill!
  529. # [14:38] <nickshanks> btw: that site has an inordinate number of RSS links!
  530. # [14:39] <annevk> that's part of the joke, iirc
  531. # [14:52] * Quits: zcorpan (n=zcorpan@84-216-40-4.sprayadsl.telenor.se) (Read error: 145 (Connection timed out))
  532. # [14:55] * Parts: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  533. # [14:59] * Joins: zcorpan (n=zcorpan@84-216-40-4.sprayadsl.telenor.se)
  534. # [15:03] <annevk> http://weblogs.mozillazine.org/roadmap/archives/2007/04/openness.html
  535. # [15:11] * billyjack is now known as MikeSmith
  536. # [15:24] * Parts: Lachy (n=Lachlan@124-168-27-56.dyn.iinet.net.au) ("Leaving")
  537. # [15:28] * Joins: Lachy (n=Lachlan@124-168-27-56.dyn.iinet.net.au)
  538. # [15:30] * Joins: polin8 (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net)
  539. # [15:30] <annevk> what's the short URL for web forms 2?
  540. # [15:31] <Philip`> http://whatwg.org/wf2/ ?
  541. # [15:32] <annevk> oh, duh
  542. # [15:32] * annevk was trying web-forms, web-forms-2, webforms2, web-forms2, etc.
  543. # [15:32] <met_> wf2 ?
  544. # [15:41] <zcorpan> Delivery to the following recipient failed permanently:
  545. # [15:41] <zcorpan>
  546. # [15:41] <zcorpan> commit-watchers-request@lists.whatwg.org
  547. # [15:41] <zcorpan> hm
  548. # [15:43] <zcorpan> confirming the subscription by following the link worked though
  549. # [15:45] <Philip`> http://lists.w3.org/Archives/Public/public-xhtml2/2007Apr/0032.html seems to be considering the same kind of use case as http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010800.html
  550. # [15:50] <annevk> zcorpan, was reported on the list
  551. # [15:50] <zcorpan> Hixie: "We have three lists:" s/three/four/
  552. # [15:50] <zcorpan> annevk: yeah noticed
  553. # [15:51] <zcorpan> fwiw, "+1" to http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/011070.html
  554. # [15:52] <Lachy> yeah, I somewhat agree with that too
  555. # [15:52] <annevk> except for requiring a particular UI, sure
  556. # [15:52] <Lachy> perhaps the pragmatic decision is to make it conforming and just let UAs disable it (like they already do)
  557. # [15:53] <Lachy> disabling target=_blank is definately easier than disabling window.open
  558. # [15:53] <zcorpan> indeed
  559. # [15:53] <Philip`> zcorpan: Or, for improved ease of future extensibility, s/three/several/
  560. # [15:53] <Lachy> although I disable both, having .open() disabled causes problems on a few sites
  561. # [15:59] <zcorpan> annevk: seems firefox does "<html><body marginheight="0" marginwidth="0"><embed type="application/x-shockwave-flash" src="foo" name="plugin" height="100%" width="100%"></body></html>" (no HEAD)
  562. # [16:00] <annevk> wow, why name and type?
  563. # [16:00] <zcorpan> don't ask me :)
  564. # [16:01] <annevk> Opera uses style= for the <body> margin stuff
  565. # [16:01] <annevk> not that it matters
  566. # [16:05] <annevk> krijnh, http://krijnhoetmer.nl/stuff/html/input-type-image-value/ WF2 actually mandates that behavior...
  567. # [16:05] <annevk> krijnh, from MSIE
  568. # [16:05] <annevk> (and Opera)
  569. # [16:09] <zcorpan> krijnh: aren't the images presentational?
  570. # [16:10] * zcorpan thought type=image was for server side image maps... but acknowledges that buttons are hard to style in some browsers
  571. # [16:10] <Philip`> krijnh: The "unobtrusive JavaScript" is a little obtrusive since the button looks like a button momentarily before it's replaced - could it be hidden with CSS before it's rendered to avoid the flash?
  572. # [16:12] <zcorpan> annevk: speaking of which, if a form control is replaced with an image with css3 generated content, but images are disabled, shouldn't the button be rendered as normal? opera renders it like an <img> without an alt attribute
  573. # [16:13] <zcorpan> annevk: your blog is a good test case for that
  574. # [16:15] <annevk> per the definition of 'content' that's not part of css3-content but will be at some point, yes
  575. # [16:15] <annevk> iirc
  576. # [16:17] <zcorpan> should i file a bug?
  577. # [16:18] <annevk> we have one
  578. # [16:18] <zcorpan> ok
  579. # [16:21] <krijnh> Back
  580. # [16:21] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  581. # [16:23] <zcorpan> http://www.robertnyman.com/2007/04/26/geek-meet-may-2007-html-5-and-xhtml/
  582. # [16:25] <annevk> have fun
  583. # [16:25] <zcorpan> :)
  584. # [16:26] <krijnh> annevk: so.. what do you mean?
  585. # [16:27] <annevk> krijnh, I mean that what IE does is correct
  586. # [16:27] <krijnh> zcorpan: they probably are
  587. # [16:27] <annevk> krijnh, and that Firefox and Konquerer etc. are wrong
  588. # [16:27] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) ("bye")
  589. # [16:27] <annevk> per the current specs
  590. # [16:27] <krijnh> annevk: i know
  591. # [16:28] <annevk> okay
  592. # [16:28] <krijnh> But that's what makes it hard to use :0
  593. # [16:28] <krijnh> Or better yet, unusable
  594. # [16:28] * annevk goes back to figuring out what the tag name productions are for XML 1.1
  595. # [16:28] <zcorpan> krijnh: usable for it's intended purpose or for presentational purposes? :)
  596. # [16:29] <krijnh> Usable as in, imho, the nicest solution :)
  597. # [16:29] <krijnh> Philip`: That's possible I think
  598. # [16:29] <krijnh> Philip`: But JS has to hide it in some way
  599. # [16:30] <annevk> so it seems that XML 1.1 pretty much allows any character
  600. # [16:30] <annevk> awesome
  601. # [16:30] * Quits: met_ (n=Hassman@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  602. # [16:30] <krijnh> zcorpan: How would you do it?
  603. # [16:31] <zcorpan> krijnh: <input type=submit name=option value=Edit> ... input[value=Edit] { content:url(edit.png); }
  604. # [16:32] <krijnh> That'd be cool
  605. # [16:32] <zcorpan> works in opera
  606. # [16:32] <krijnh> Even though my very few customers don't use Opera that much
  607. # [16:32] <krijnh> I know ;)
  608. # [16:32] <krijnh> Had to find a way to fix up http://qontent.nl/_img/screenshots/paginas.png
  609. # [16:33] * annevk is amazed with Eliotte Harold
  610. # [16:33] <annevk> the guy with double l
  611. # [16:33] * Joins: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  612. # [16:34] <annevk> guess I had too many silly assumptions about some XML people
  613. # [16:35] <MikeSmith> annevk - for instance?
  614. # [16:36] * MikeSmith is also amazed by EHR sometimes, though maybe not for same reasons as annevk
  615. # [16:37] <annevk> he's promoting it where I thought he would find HTML5 quite a silly adventure
  616. # [16:37] <MikeSmith> who knows, maybe he did
  617. # [16:38] <MikeSmith> and maybe he changed his mind after actually reading the spec
  618. # [16:38] <krijnh> annevk: assumptions are the mother of all fuckups ;)
  619. # [16:38] * jdandrea is late to the chat. Link for EHR?
  620. # [16:38] <Philip`> Maybe he dislikes the HTML5 serialisation but likes the rest of it?
  621. # [16:38] <MikeSmith> Elliotte Rusty Harold
  622. # [16:38] <annevk> jdandrea, see whatwg@whatwg.org
  623. # [16:38] <jdandrea> reading it now in fact - thx
  624. # [16:38] * jdandrea is prolly not caught up - will keep at it ...
  625. # [16:39] <Philip`> (given that he mentioned in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010954.html being very pro-XHTML)
  626. # [16:39] <MikeSmith> not saying that it's necessarily so for his case, but people do change their minds about things sometimes
  627. # [16:40] <annevk> Philip`, ah right, I guess he's still pro XHTML
  628. # [16:41] <MikeSmith> is that XHTML in the sense of well-formed XML serialization of HTML, or XHTML as in the XHTML 1.1/2
  629. # [16:41] * MikeSmith reads and sees now
  630. # [16:41] <annevk> former
  631. # [16:43] * MikeSmith wonders how many people might change their minds about the webapps/HTML5 spec if they actually took time to read it
  632. # [16:44] <Philip`> Are you only considering people who currently object to it, or also the people who currently think they like HTML5 but haven't actually read much of it? :-)
  633. # [16:44] <krijnh> Hehe
  634. # [16:45] <MikeSmith> heh. the former, actually
  635. # [16:45] <MikeSmith> but I guess there probably are a few of the latter as well
  636. # [16:45] <MikeSmith> bible-thumpers on both sides who haven't actually taken the time to read the bible ...
  637. # [16:47] <MikeSmith> but I'd guess that there are far more of the former than latter
  638. # [16:48] * krijnh should log IP addresses of people flagging useless lines; http://krijnhoetmer.nl/irc-logs/whatwg/20070426#l-472
  639. # [16:48] <krijnh> Or dump that feature anyway :/
  640. # [16:48] <Philip`> At least parts of the bible don't keep getting rewritten every few days - it's harder to keep up with the latest version of WA1
  641. # [16:49] <zcorpan> krijnh: you could perhaps highlight lines that get linked to (if that's possible to do)
  642. # [16:49] <MikeSmith> krijnh - I like that feature. but I guess like every other useful interactive feature, it's open to abuse
  643. # [16:49] <annevk> krijnh, i'd like a checkbox
  644. # [16:49] <krijnh> Easy on the requests people ;)
  645. # [16:49] <annevk> krijnh, the current UI doesn't work at all in my Opera installation
  646. # [16:50] <Philip`> annevk: I think it works if you double-click the non-text part of the line
  647. # [16:50] <Philip`> (at least when I last tried it)
  648. # [16:50] <annevk> yeah, sometimes...
  649. # [16:50] <krijnh> Yeah, I had trouble with that as well
  650. # [16:50] <zcorpan> krijnh: as a compromise you could do all of the above ;)
  651. # [16:50] <krijnh> zcorpan: fair enough
  652. # [16:50] <zcorpan> krijnh: (i was joking :P)
  653. # [16:51] <krijnh> ;)
  654. # [16:51] <annevk> don't tell him
  655. # [16:51] <zcorpan> heh
  656. # [16:51] <krijnh> Next time put it in a <sarcasm> tag(!) then ;)
  657. # [16:51] <jdandrea> LOL
  658. # [16:51] <zcorpan> right, forgot :(
  659. # [16:52] <krijnh> zcorpan: so how would you say that's possible?
  660. # [16:52] <annevk> lets introduce <joke> on April 1
  661. # [16:52] <krijnh> If there's a referrer that's not the current document and the location.hash is set
  662. # [16:52] <annevk> or would that be too obvious?
  663. # [16:52] <krijnh> Flag that line
  664. # [16:52] <krijnh> Right?
  665. # [16:52] <annevk> yeah
  666. # [16:52] <zcorpan> something like that
  667. # [16:52] <zcorpan> i have del.icio.used a few lines already
  668. # [16:53] <annevk> maybe that should be the only way to mark lines...
  669. # [16:54] <annevk> kind a like page rank
  670. # [16:54] <krijnh> zcorpan: Yeah, I noticed
  671. # [16:54] <krijnh> Hmm
  672. # [16:54] <krijnh> Would be cool
  673. # [16:54] <krijnh> But that flagging should be done with XHR
  674. # [16:54] <krijnh> Err, AJAX, sorry
  675. # [16:54] <krijnh> So that's probably possible by hand anyway :)
  676. # [16:55] <krijnh> zcorpan: your delicious/zcorpan/zcorpan line is so interesting for the rest of the world btw ;)
  677. # [16:56] <zcorpan> who said del.icio.us musn't contain personal stuff? :)
  678. # [16:56] <krijnh> I don't, but using the new fluffy referrer spam technique that line would be flagged :)
  679. # [16:57] <zcorpan> right
  680. # [16:58] <annevk> maybe the if the referring page contains the name of the person who said the message it should not be marked
  681. # [16:58] <krijnh> Riiight
  682. # [16:58] <annevk> (although it should not be unmarked either, of course, if it already is)
  683. # [16:58] <krijnh> What do you think I am? A competent developer or something?
  684. # [16:58] <annevk> it's not like you got something better to do :p
  685. # [16:58] <Philip`> You could have a Bayesian learning network that decides which lines are interesting, given their content and the replies in IRC and any external links to that line
  686. # [16:59] <annevk> oh, +1
  687. # [16:59] <krijnh> annevk: because I have irc open on one monitor?
  688. # [17:00] <zcorpan> obviously linked to doesn't imply "important"
  689. # [17:00] <krijnh> Nope
  690. # [17:00] <zcorpan> but flagging them as "linked to" (perhaps with a link back) could be nice
  691. # [17:01] <zcorpan> it's not a request, just an idea :)
  692. # [17:09] <krijnh> annevk: checkbox added
  693. # [17:09] <krijnh> Well, somewhat checkboxy
  694. # [17:10] <annevk> cool
  695. # [17:11] <Lachy> krijnh, can you remove the "are you sure?" confirmation for unmarking a line?
  696. # [17:11] <krijnh> No, that's impossible, it will break backwards compat!
  697. # [17:11] <krijnh> Done ;)
  698. # [17:14] <krijnh> I think dynamically adding 1000 checkboxes isn't nice, so this will do
  699. # [17:14] <Philip`> It's odd how the little yellow/red box gets a few pixels taller when you put the mouse over a link on that line
  700. # [17:15] <krijnh> Yeah
  701. # [17:15] <krijnh> In Opera
  702. # [17:15] <krijnh> Oddness removed
  703. # [17:16] <zcorpan> krijnh: you need a version switch then
  704. # [17:16] <krijnh> zcorpan: Perhaps Lachy can tell me about it in a private mail..
  705. # [17:17] <Philip`> krijnh: Ah, it works more evenly now - thanks :-)
  706. # [17:19] <krijnh> Yeah, with this I dropped support for IE6
  707. # [17:19] <krijnh> \o/
  708. # [17:20] <MikeSmith> krijnh - this is not an official request, but given that the /topic for the #html-wg channel references http://krijnhoetmer.nl/irc-logs/ ...
  709. # [17:20] <krijnh> I didn't put it there..
  710. # [17:21] * Joins: jcgregorio (i=chatzill@nat/ibm/session)
  711. # [17:21] <MikeSmith> I'm glad it's there... it's just that part about "(for entertainment ;-)" next to the #xhtml channel
  712. # [17:21] <Philip`> krijnh: Add some <!--[if IE]--> hacks to your code
  713. # [17:22] <krijnh> Yeah, I wondered how long it would take for somebody to fall over that ;)
  714. # [17:22] <krijnh> MikeSmith: removed
  715. # [17:23] <MikeSmith> krijnh - cheers
  716. # [17:23] <MikeSmith> perhaps some would say that numbers there speak for themselves ...
  717. # [17:24] <MikeSmith> making the message in a perhaps more subtle way
  718. # [17:24] * Joins: fantasai (i=fantasai@connectionreset.info)
  719. # [17:25] <zcorpan> krijnh: heh.. a page listing referrers comes up in your list of referrers :)
  720. # [17:28] * Joins: Charl (n=Charl@spotter.nmmu.ac.za)
  721. # [17:32] <krijnh> zcorpan: that .cz page?
  722. # [17:32] <zcorpan> yeah
  723. # [17:33] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  724. # [17:38] <annevk> hmm, writing down a parser for XML in ASCII-art is harder than I expected
  725. # [17:39] <annevk> actually, tokenizer
  726. # [17:40] <Philip`> Would Unicode-art be easier? It has lots of nice lines and double-lines and corners and things
  727. # [17:40] <krijnh> You can make hamburgers with unicode!
  728. # [17:43] * Joins: om_sleep (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  729. # [17:47] <gsnedders> a parser in ASCII-art!?
  730. # [17:47] <zcorpan> krijnh: d(*⌒▽⌒*)b
  731. # [17:47] <Philip`> Bonus points if it's a correctly-operating Befunge program as well as a diagram
  732. # [17:48] <krijnh> ?--------?
  733. # [17:48] <krijnh> Bah
  734. # [17:48] <krijnh> Crap client :)
  735. # [17:49] <zcorpan> heh
  736. # [17:49] <annevk> gsnedders, just the various states indented etc.
  737. # [17:49] <annevk> but I stepped away from that
  738. # [17:49] <gsnedders> aaahhhhh.
  739. # [17:49] <gsnedders> sounds saner :)
  740. # [17:51] <zcorpan> Hixie: the first example on irrelevant="", shouldn't <section id="game"> be <section id="game" irrelevant>?
  741. # [17:56] <Lachy> Hixie, typo in that section too "User agents should net render elements that have the irrelevant attribute specified" -- s/net/not/
  742. # [17:57] <nickshanks> <html irrelevant>
  743. # [17:58] <zcorpan> <!doctype irrelevant>
  744. # [17:58] <nickshanks> doctype is implicitly irrelevent
  745. # [17:58] <Lachy> if only that triggered standards mode, I'd use it :-(
  746. # [17:59] <Philip`> <!doctype html system "irrelevant">?
  747. # [17:59] <Lachy> could use <!doctype html publick "irr
  748. # [17:59] * Lachy was too slow
  749. # [18:01] <nickshanks> how about application/html MIME type as the switch to stop supporting quirks mode?
  750. # [18:01] <nickshanks> then you could leave off the doctype and still be in standards mode
  751. # [18:01] <annevk> not backwards compatible
  752. # [18:02] <nickshanks> anne: that's the point
  753. # [18:02] <Philip`> Is it implicit that 'irrelevant' should cause UAs not to render any child elements of the irrelevant element?
  754. # [18:02] <annevk> nickshanks, the point is adding a few bytes to the MIME type which is way harder to change for people to save a few bytes within the document (which is easy to change)?
  755. # [18:02] <krijnh> Philip`: as I understand it, it's like [irrelevant]{display: none;}
  756. # [18:03] <annevk> and besides that making the whole thing backwards incompatible?
  757. # [18:03] <annevk> seems like way more cost than it's worth to me
  758. # [18:03] <nickshanks> but if you're not going to support tag soup browsers anyway, it doesn't really matter
  759. # [18:04] <zcorpan> Hixie: i don't get the second example of irrelevant=""... the second paragraph seems to be fallback, why don't put that as contents of the <video> (and make <video> fallback on error)?
  760. # [18:04] <annevk> if you don't want to play friendly with the web there's always XHTML2
  761. # [18:04] <nickshanks> what is with you guys keep suggesting that?
  762. # [18:04] <Philip`> I expect XHTML5 will always be rendered in really-standards mode too
  763. # [18:05] <annevk> nickshanks, maybe you should ask yourself?
  764. # [18:05] <annevk> Philip`, yeah
  765. # [18:06] <Philip`> I assume IE will support XHTML(5) at some point, and I assume it'll do it in really-standards mode (since it's not like there's any existing content to break), and if you don't mind backward compatibility then you can just use that instead of a new MIME type
  766. # [18:07] <nickshanks> that's my point, but no-one seems to listen when i say it
  767. # [18:07] <nickshanks> there is no existing HTML 5 content to break
  768. # [18:07] <annevk> the idea of HTML5 is that it's compatible with older UAs
  769. # [18:08] <nickshanks> it will never be
  770. # [18:08] <annevk> the idea is also that UAs implementing HTML5 will automatically support older versions of HTML
  771. # [18:08] <annevk> as in, no versioning
  772. # [18:08] <nickshanks> that is achievable
  773. # [18:08] <nickshanks> but mosaic will never support canvas
  774. # [18:08] <nickshanks> or any other new element
  775. # [18:08] <annevk> compatible does equal support
  776. # [18:08] <annevk> does not*
  777. # [18:08] <annevk> oops
  778. # [18:09] <annevk> Mosaic will render the fallback content
  779. # [18:09] <nickshanks> i'm not suggesting we change anything that makes mosaic unable to parse the document
  780. # [18:09] <krijnh> And it will render irrelevant elements :)
  781. # [18:09] <nickshanks> like replace <a> with [a]
  782. # [18:09] <annevk> (there may be exceptions to this I suppose, <event-source> isn't really backwards compatible at all, but there's no need for it to be)
  783. # [18:10] <annevk> you're suggesting something that will make Mosaic crash or maybe offer a download dialog
  784. # [18:10] <annevk> for no real benefit
  785. # [18:11] <annevk> krijnh, what do you mean?
  786. # [18:11] <nickshanks> well mosaic won't accept application/html so it will get the text/html version
  787. # [18:11] <annevk> you want to author two versions?
  788. # [18:11] <krijnh> annevk: I think it won't know about the irrelevant attribute?
  789. # [18:11] <nickshanks> if i care about old clients
  790. # [18:11] <annevk> to save <!doctype html> in one?!
  791. # [18:11] <annevk> please...
  792. # [18:11] <annevk> krijnh, oh, duh
  793. # [18:11] <nickshanks> no, you are not understanding
  794. # [18:11] <annevk> krijnh, didn't get that
  795. # [18:12] <nickshanks> stop thinking in terms of now
  796. # [18:12] <nickshanks> and think in terms of 2025
  797. # [18:12] <krijnh> annevk: Np, I don't the irrelevant attribute either :)
  798. # [18:12] <krijnh> *don't get even
  799. # [18:12] <annevk> nickshanks, i don't see the point of breaking backcompat then either
  800. # [18:12] <nickshanks> do you really still want to be stuck supporting all the crap that was in HTML 3.2 that far ahead?
  801. # [18:12] <annevk> nickshanks, yes
  802. # [18:12] <zcorpan> nickshanks: yes
  803. # [18:12] <annevk> nickshanks, that's the whole point of HTML5
  804. # [18:13] <annevk> the other option is XHTML2
  805. # [18:13] <annevk> it has been a conscious decision to not break backcompat
  806. # [18:13] <annevk> if we expect to do that anyway in 20 years we might as well do it now
  807. # [18:14] <nickshanks> but it's not possible to both retain backwards compat and add conflicting features without a switch of some kind
  808. # [18:14] <nickshanks> either doctype, mime type or something else
  809. # [18:15] * Joins: johnst (n=johnst@x1-6-00-04-61-4a-1f-54.k459.webspeed.dk)
  810. # [18:15] <annevk> we won't add conflicting features
  811. # [18:15] * Quits: MikeSmith (n=MikeSmit@IP-193-159-214-250.y-lan.t-online.net) ("Get thee behind me, satan.")
  812. # [18:15] <annevk> maybe you should read up on the design principles
  813. # [18:16] <nickshanks> there's no way you can know what will be desired in the future
  814. # [18:17] <zcorpan> nickshanks: if we need conflicting features in the future then we can introduce versioning/new mime type/whatever *then*
  815. # [18:17] <zcorpan> nickshanks: we haven't done so know (afaik) so no need to do so now
  816. # [18:17] <zcorpan> er, s/know/now/
  817. # [18:18] <nickshanks> well, there is an need for versioning now, as shown by doctype switching
  818. # [18:18] <zcorpan> nickshanks: no, there was a need back when doctype switching was introduced. you're suggesting yet another switch, no?
  819. # [18:19] <nickshanks> that need still exists
  820. # [18:19] <annevk> doctype switching is not versioning
  821. # [18:19] <zcorpan> nickshanks: yes, we're stuck with it and probably will be forever
  822. # [18:19] <annevk> it's a few specific rendering differences that depend on a particular string at the start of the document
  823. # [18:19] <nickshanks> no, because HTML doesn't support versioning so we had to come up with a hack
  824. # [18:19] <annevk> it's mostly versioning for the rendering engine, not HTML
  825. # [18:20] <nickshanks> right
  826. # [18:20] <annevk> it should never have been introduced
  827. # [18:20] <nickshanks> but so is any document version
  828. # [18:20] <annevk> but unfortunately it was
  829. # [18:20] <nickshanks> you don't have a better solution
  830. # [18:20] <annevk> i've no idea what you're talking about
  831. # [18:21] <nickshanks> well the application reads a document, and behaves differently depending on what the version number at the start of the document is
  832. # [18:21] <annevk> well yes, as mentioned above, if that's needed we can introduce it
  833. # [18:21] <nickshanks> whether there's one giant switch statement of little if..else's here and there is an implementation detail and not relavent here
  834. # [18:21] <annevk> i don't think we'll ever need it
  835. # [18:22] <nickshanks> i think "we can't be sure we'll never need it, so better to include it and be on the safe side"
  836. # [18:22] <annevk> i don't think quirks mode was needed either, but supposedly it seemed like a good idea back then
  837. # [18:22] * Parts: fantasai (i=fantasai@connectionreset.info)
  838. # [18:22] <annevk> including it and not letting it have effect will just confuse people
  839. # [18:22] <annevk> as mentioned
  840. # [18:22] <nickshanks> i've worked with plenty of C structs that have version numbers at the start, where the only version was 0
  841. # [18:22] <annevk> we can always introduce it
  842. # [18:22] <annevk> we don't need to be safe
  843. # [18:23] <annevk> C is not comparable with HTML
  844. # [18:23] <nickshanks> HTML is instructions to be interpreted and cause an effect
  845. # [18:23] <nickshanks> same as any other computer language
  846. # [18:24] <hasather> nickshanks: no, HTML is no programming language
  847. # [18:25] <nickshanks> i don't see the difference
  848. # [18:26] * om_sleep is now known as othermaciej
  849. # [18:28] <othermaciej> nickshanks: how many C programs have you seen that declare the version of C they are using at the top of the file?
  850. # [18:29] <nickshanks> the version of C is declared outside of the code files in the IDE
  851. # [18:29] <Philip`> HTML6 can say the default value of the 'version' attribute is '5', and an HTML6 browser will apply that rule to every page it sees. You can't do anything like that in C - a change to the struct's layout won't be picked up by all the existing binary code that uses it, so the version has to be explicit
  852. # [18:29] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  853. # [18:30] <annevk> html-wg looks like chaos
  854. # [18:30] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  855. # [18:31] <othermaciej> nickshanks: when I type cc myprogram.c at the command line, I don't include a mention of the C version anywhere
  856. # [18:31] <nickshanks> the version of C is declared outside of the code files in the IDE (you may have missed that)
  857. # [18:32] <nickshanks> and if you compile it with a subset or incompatible version, you get errors
  858. # [18:32] <Philip`> The version there is optional - you could run "gcc -ansi" or "gcc -std=c89"
  859. # [18:32] <nickshanks> but it has a default value
  860. # [18:32] <Philip`> but it seems most people don't use either of those, because the language is largely backward-compatible and so you can compile all your code as C99-plus-GCC-extensions
  861. # [18:33] <nickshanks> anyway, i wasn't talking about the version of C (good example, btw) i was talking about the version of some data structure that your app is reading off disk
  862. # [18:33] <Philip`> but when it doesn't work, you can modify the source code, which is not possible with HTML because it's not your source code
  863. # [18:34] * Joins: MikeSmith (n=MikeSmit@87.139.13.30)
  864. # [18:34] <othermaciej> nickshanks: but HTML is a language, not an on-disk binary formatted data structure
  865. # [18:35] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  866. # [18:35] <annevk> Philip`, nice comparison; (as opposed to modify we fix the source code)
  867. # [18:35] <nickshanks> but how that language is to be interpreted is not consistent across all versions of HTML
  868. # [18:37] <annevk> it's whatever the latest version says
  869. # [18:37] <nickshanks> mostly due to errors in specs
  870. # [18:38] <nickshanks> anne: but not all UAs follow the "latest version" so you lose your back compat right there
  871. # [18:38] <annevk> no
  872. # [18:38] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  873. # [18:38] <annevk> because the latest version is designed with that in mind
  874. # [18:39] <nickshanks> unless it has an error in it
  875. # [18:39] <annevk> in which case that will be pointed out and fixed
  876. # [18:39] <nickshanks> after it has been implemented
  877. # [18:39] <nickshanks> at which point it's too late
  878. # [18:39] <annevk> this also goes for theoretical versioned HTML so I'm not sure what your point is
  879. # [18:40] <annevk> yes, it could also be implemented incorrectly... if that's done and not much breaks it's apparently acceptable
  880. # [18:40] <annevk> languages evolve
  881. # [18:40] <nickshanks> versioning in HTML would basically be about how to recover from mistakes in specs or mistakes in how developers wrote for that version
  882. # [18:40] <nickshanks> so that when it was fixed, you could do it the "old way" when encountering an old file
  883. # [18:40] <annevk> what fixed?
  884. # [18:41] <nickshanks> whatever the original error was
  885. # [18:41] <annevk> the current algorithm is largely compatible with the web
  886. # [18:41] <annevk> it needs more impl experience of course
  887. # [18:41] <nickshanks> usemap in XHTML is a good example
  888. # [18:41] <Philip`> annevk: But evolution requires death, and nobody wants to kill any old HTML content, so HTML can't evolve - it just grows and mutates :-)
  889. # [18:41] <annevk> nickshanks, usemap in XHTML was a bug in the spec
  890. # [18:42] <nickshanks> right
  891. # [18:42] <nickshanks> you can't guarantee that all future versions of HTML won't be bug free
  892. # [18:42] <annevk> and hardly relevant given that 0.00% of the sites out there use XML
  893. # [18:42] <nickshanks> it's an EXAMPLE for god's sake
  894. # [18:42] <annevk> nickshanks, no, you can't
  895. # [18:42] <nickshanks> it could happpen to HTML 5
  896. # [18:42] <annevk> yes, the current spec is imperfect
  897. # [18:42] <annevk> i don't really see the problem
  898. # [18:43] <annevk> if such a bug is found the bug is fixed
  899. # [18:43] <nickshanks> even if it wasn't, the next version might be
  900. # [18:43] <annevk> specs and implementations require many iterations
  901. # [18:43] <othermaciej> if you make a mistake in the spec, you have a problem
  902. # [18:43] <annevk> Philip`, I'm not sure I agree with that
  903. # [18:43] <othermaciej> if you use versioning to address it, you have two problems
  904. # [18:43] <annevk> Philip`, but I can't really refute it either
  905. # [18:43] <annevk> othermaciej, :)
  906. # [18:44] <nickshanks> if I write a site and put <html version="5.0"> at the top, web browsers will know that i mean b when i write a, and if i put version="5.01" they'll know not to change the meaning
  907. # [18:44] <annevk> browsers will ignore that information...
  908. # [18:45] <nickshanks> then they won't know which I meant and will have to guess
  909. # [18:45] <nickshanks> i, the author, provide the answer so no need to guess
  910. # [18:45] <annevk> i've no idea what you're talking about
  911. # [18:45] <annevk> html will just be interpreted by whatever the latest spec says on the matter
  912. # [18:46] * Joins: ddfreyne (n=ddfreyne@d51A5CE12.access.telenet.be)
  913. # [18:46] <Philip`> Is the (theoretical) problem only that HTML5 might specify some behaviour, and lots of sites are built to rely on it, then HTML6 accidentally specifies a different incompatible behaviour, but nobody notices the bug and lots of sites are built that rely on it, and then somebody notices and HTML7 is stuck because it'll break half the sites?
  914. # [18:46] <othermaciej> version info is not generally used to switch anything that is based on the spec
  915. # [18:46] <nickshanks> Philip`: yeah, basically
  916. # [18:46] <othermaciej> doctype switching for standards vs. quirks mode is solely about some CSS rendering differences for compatibility
  917. # [18:46] <othermaciej> HTML 2, HTML 3.2 and HTML 4 are all treated the same
  918. # [18:46] <annevk> nickshanks, that's not a realstic scenario though
  919. # [18:47] <nickshanks> i don't see why you're against having a safty net
  920. # [18:47] <nickshanks> +e
  921. # [18:47] <annevk> it's not needed at this point
  922. # [18:47] <Philip`> I would expect that situation to be unlikely, because people will test their HTML6 sites in HTML5 UAs too, and their HTML5 sites in HTML6 UAs, and so somebody will notice the bug soon (before the next version of market-dominant-browser-of-the-day is released) and the spec can be fixed
  923. # [18:47] <annevk> adding things that are not needed is just adding bloat
  924. # [18:47] <annevk> and sets the wrong precedents
  925. # [18:48] <nickshanks> until next year, when you realise, "oh shit, we screwed up there, and now there are two different interpretations floating about, and no way to tell which one is which because we didn't include differentiation"
  926. # [18:48] <annevk> Philip`, implementors will surely notice such an incompatibility
  927. # [18:48] * Quits: Charl (n=Charl@spotter.nmmu.ac.za)
  928. # [18:48] <annevk> nickshanks, if two UAs do something different introducing versioning doesn't help
  929. # [18:48] <nickshanks> Philip`: a lot of people don't test in more than one browser
  930. # [18:48] <annevk> nickshanks, versioning doesn't solve the UA problem
  931. # [18:49] <annevk> how the hell would it solve that?!
  932. # [18:49] * annevk has the feeling he's wasting his time here
  933. # [18:49] <nickshanks> sorry, which problem?
  934. # [18:49] <annevk> the problem that two UAs might do different things
  935. # [18:50] <nickshanks> i wasn't talking about two USa, i was meaning two subsequent versions of HTML
  936. # [18:50] <nickshanks> UAs *
  937. # [18:50] <Philip`> The problem of two versioned sites using <html version="5.0.6">, each tested in different UAs that have incompatible behaviour
  938. # [18:51] <nickshanks> cross compatibility on the same version of HTML is not what's being discussed
  939. # [18:51] <annevk> nickshanks, such a thing hasn't occured yet, so i don't really see that as a potential problem
  940. # [18:51] <nickshanks> that's hardly a defence
  941. # [18:51] <nickshanks> and it occured with usemap
  942. # [18:51] <annevk> i think it is
  943. # [18:51] <annevk> XHTML is irrelevant to this discussion
  944. # [18:51] <annevk> there's no usage
  945. # [18:52] <annevk> and people did notice and reported the error
  946. # [18:52] <annevk> the spec was just never fixed
  947. # [18:52] <annevk> fortunately we now have more competent people running HTML
  948. # [18:53] <nickshanks> right, my point is that there was an error, and it could happen again (no matter how competent we are)
  949. # [18:53] <Philip`> Was it reported before any implementations were released that used the incompatible behaviour?
  950. # [18:54] <nickshanks> future HTML developers might also realise they have to break back compat in order to move forward (in which case versioning will be required, instead of just being a reserve parachute)
  951. # [18:54] <nickshanks> Philip: it was reported before the spec was finished, they just said "yeah, so what?"
  952. # [18:55] <annevk> nickshanks, in which case they can introduce versioning then
  953. # [18:55] <annevk> nickshanks, introducing versioning and unnoticely introducing a backcompat change doesn't solve this problem either
  954. # [18:55] <annevk> nickshanks, because UAs won't know the behavior has suddenly changed
  955. # [18:56] <nickshanks> anne: do you not see how having a version might help future UAs resolve a dilemma ?
  956. # [18:56] <annevk> nickshanks, in fact, they won't change their current behavior...
  957. # [18:56] <annevk> nickshanks, I don't think the dilemma will ever occur
  958. # [18:56] <nickshanks> as i said, that's no defence
  959. # [18:56] <annevk> how is it not?
  960. # [18:57] <nickshanks> because you could quite easily be wrong!
  961. # [18:57] <annevk> so could you!
  962. # [18:57] <zcorpan> nickshanks: you still haven't said why we need to introduce it *now*. why can't it be introduced when we find that it is needed (if at all)?
  963. # [18:57] <annevk> and then we've added bloat for nothing and all kinds of other crap
  964. # [18:57] <nickshanks> it should have been in every version of html
  965. # [18:57] <zcorpan> why?
  966. # [18:57] <zcorpan> so far there haven't been a need afaict
  967. # [18:57] <Philip`> You could both be wrong - maybe the future is LaTeX
  968. # [18:57] <nickshanks> so we can drop old elements or change their functionality
  969. # [18:57] <nickshanks> like menu
  970. # [18:58] <annevk> Philip`, LaTeX would presumably not use text/html
  971. # [18:58] <nickshanks> menu in HTML 5 bears no relation to menu in html 1
  972. # [18:58] <annevk> nickshanks, the upgrade is done in a compatible way
  973. # [18:58] <nickshanks> and in order to retain back compat there is a whole load of unnecessary bloat in the spec
  974. # [18:58] <annevk> versioning doesn't solve that either
  975. # [18:59] <zcorpan> nickshanks: what's the benefit of dropping support for old elements under a new switch but keeping support for them for pages without the switch? it just adds implementation complexity
  976. # [18:59] <annevk> versioning just introduces more bloat
  977. # [18:59] <annevk> so far versioning just introduces more problems as I see it
  978. # [19:01] * moeffju is now known as moeffju[Away]
  979. # [19:03] <Philip`> nickshanks: The goal of the WHATWG work is to be an implementation comparable with current browsers - if the browsers have to implement <menu> in a certain way because content requires it, then the spec will have to do the same, so it can't just drop it and become less bloaty
  980. # [19:04] <Philip`> (i.e. it's necessary bloat, given the requirements which are placed on the spec)
  981. # [19:05] <Philip`> and that seems like quite a fundamental goal, so I don't see it ever being changed within this group
  982. # [19:05] <nickshanks> on another topic: i think it would idea to take the error handling from WA 1 and apply it to a HTML 4.1, so that we have a version of HTML 4 that is interoperable and standardised as such
  983. # [19:06] <nickshanks> whilst leaving all the new stuff for HTML 5
  984. # [19:06] <Philip`> Like an HTML4-featured profile of the HTML5 spec?
  985. # [19:06] <Philip`> (People don't seem to like profiles that much...)
  986. # [19:06] <nickshanks> whatever you want to call it
  987. # [19:07] <annevk> everything was broken in HTML4
  988. # [19:07] <annevk> it would still be a lot of work
  989. # [19:07] <nickshanks> now you're exaggerating a little :)
  990. # [19:08] <nickshanks> yeah, it would be work
  991. # [19:08] <nickshanks> but we can get the W3C to do that
  992. # [19:08] <annevk> not really...
  993. # [19:08] <annevk> why?
  994. # [19:08] <Philip`> Is a conformant interoperable HTML 4.2 UA more useful than a non-conformant (because it's missing all the new features) interoperable (because the implemented ones follow the spec) HTML 5 UA?
  995. # [19:08] <Philip`> *the implemented features
  996. # [19:09] <zcorpan> more to the point, what's the benefit of such a spec?
  997. # [19:09] <nickshanks> philip: that would depend on what content you were using, primarily 4.2 or 5.0 sites
  998. # [19:10] <nickshanks> zcorpan: it would (i assume) be out more quickly than HTML 5 and web authors can start using it
  999. # [19:10] <nickshanks> and vendors can follow it
  1000. # [19:10] <annevk> you need a testsuite for that
  1001. # [19:10] <nickshanks> without haing to implement the rest of HTML 5.0 befor ethey release too
  1002. # [19:10] <nickshanks> is one not being written?
  1003. # [19:10] <annevk> people are already implementing HTML5
  1004. # [19:10] <annevk> not at lightspeed
  1005. # [19:10] <nickshanks> it would be the HTML 5 test suite with new stuff removed
  1006. # [19:11] <nickshanks> just a stop-gap measure to sure up HTML 4 interop before HTML 5 arives
  1007. # [19:11] <annevk> the best way to get interop is create tests
  1008. # [19:12] <annevk> not by creating specs
  1009. # [19:12] <nickshanks> well the spec exists 99% already
  1010. # [19:12] <zcorpan> nickshanks: why can't UAs just implement a subset of html5, and authors use a subset of html5? i don't see the benefit of having a de jure subset rather than de facto subset for a given point in time
  1011. # [19:12] <Philip`> Are the new HTML5 features much easier/harder to implement than the bugfixes for HTML4 features?
  1012. # [19:12] <annevk> ...
  1013. # [19:12] <nickshanks> okay, alternative plan: create HTML4-compatible tests before the HTML5-only ones
  1014. # [19:13] <nickshanks> and forego a version 4.1 spec
  1015. # [19:13] <zcorpan> since the subset changes over time, when you're done with your html4 subset the implementations have added support for a number of other features which are part of the de facto subset
  1016. # [19:13] <zcorpan> rendering the html4 subset irrelevant
  1017. # [19:14] <annevk> Philip`, implementing <canvas> might be easier than fixing some of the bug... patching legacy code can be tricky
  1018. # [19:14] <Philip`> nickshanks: But then the early HTML5 implementations would have no tests and wouldn't be interoperable, which wouldn't be good, unless the implementations are held back until the tests are finished (which isn't going to happen, since they're not even waiting for the spec to be finished)
  1019. # [19:14] <nickshanks> zcorpan: the tests would never become irrelevent
  1020. # [19:14] <zcorpan> nickshanks: did i say that?
  1021. # [19:15] <nickshanks> yes you did, a few lines up\
  1022. # [19:15] <zcorpan> i meant the de jure html4 subset of html5 you're advocating, not tests
  1023. # [19:15] <nickshanks> i am talking about tests
  1024. # [19:15] <zcorpan> oh, sorry
  1025. # [19:15] <othermaciej> zakim, unmute me
  1026. # [19:15] <othermaciej> doh
  1027. # [19:15] <zcorpan> creating tests for a subset of html5 is good
  1028. # [19:16] <zcorpan> but doesn't mean we have to create a separate spec
  1029. # [19:16] <nickshanks> right
  1030. # [19:16] <nickshanks> specs help HTML authors, tests help UA authors
  1031. # [19:16] <zcorpan> tutorials help authors
  1032. # [19:17] <zcorpan> specs and tests help implementors
  1033. # [19:17] <Philip`> Apart from <!doctype html>, I'd expect most HTML5 tests to not be using any new HTML5 features, so they'd work fine for testing HTML4-featured UAs
  1034. # [19:17] <nickshanks> tutorials are usually written by people who've read and comprehended a specification first though :P
  1035. # [19:18] <zcorpan> nickshanks: right, specs help tutorial authors
  1036. # [19:18] <nickshanks> i can't imagine anyone proposing HTML 6 have no spec and just a bunch of tests :)
  1037. # [19:18] <zcorpan> and authors who know how to read specs
  1038. # [19:19] <Philip`> (Maybe the tests that use new features could just be labelled, rather than intentionally writing tests to a specific subset of the spec)
  1039. # [19:19] <nickshanks> i think anyone with a basic grasp of english can read the spec, and if it's well written, understand it
  1040. # [19:19] <nickshanks> trouble is not many authors do!
  1041. # [19:20] <nickshanks> and even, apparently, some people who write "Lern Yerself HTML Kwik!" type books don't read the spec :-o
  1042. # [19:20] <Philip`> Not many authors do have a basic grasp of English? Maybe there should be an official translation of the spec into Chinese :-)
  1043. # [19:20] <zcorpan> nickshanks: not really, you have to know about rfc2119 terms and be able to distinguish between what applies to authors or not, and what is normative or not
  1044. # [19:20] <nickshanks> Philip: yes, that would be a good idea too
  1045. # [19:21] <nickshanks> I think readers SHOULD know about rfc2199
  1046. # [19:21] <nickshanks> but it makes pretty good sense to an english speaker even if they don't
  1047. # [19:22] <nickshanks> i would expect most errors on web pages are trivial though, not conceptual
  1048. # [19:23] <nickshanks> whether something is normative or not isn't too critical
  1049. # [19:23] <Philip`> Someone (can't quite remember who) had some confusion over http://www.whatwg.org/specs/web-apps/current-work/#lists where it says you need comma-only separators to be valid, but the algorithm accepted spaces too
  1050. # [19:23] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  1051. # [19:23] <jdandrea> That was me.
  1052. # [19:23] <Philip`> because it's not particularly obvious that the former applies to authors, and the latter should never be looked at by authors and only applies to UAs
  1053. # [19:24] <jdandrea> Bingo.
  1054. # [19:24] <jdandrea> Of course now when I read it, I grok. :)
  1055. # [19:24] <jdandrea> (well, maybe not grok but you get the idea - it makes sense now)
  1056. # [19:25] <Philip`> I think that kind of subtlety makes it hard to read the spec properly, even after you can read all the English
  1057. # [19:25] * jdandrea is reminded of: "It's easy when you know how!" :)
  1058. # [19:25] <Philip`> jdandrea: Ah, sorry, I wasn't sure who it was :-)
  1059. # [19:26] <nickshanks> should the WA spec wrap implementor only details with a display: none div?
  1060. # [19:26] <nickshanks> and have a little button to show them
  1061. # [19:26] <nickshanks> it would make it an awful lot shorter for most users! :)
  1062. # [19:27] <Philip`> (jdandrea: Also sorry, can't respond to PMs, since I've been too lazy to register on Freenode :-) )
  1063. # [19:28] <zcorpan> nickshanks: might be nice but how would it be done? should Hixie markup everything with classes?
  1064. # [19:28] <jdandrea> Philip` - no worries. It's a good example (comma-only separators)!
  1065. # [19:28] <zcorpan> nickshanks: or is there a way to programmatically determinate whether something applies to authors or not?
  1066. # [19:28] <jdandrea> There was discussion on this at the time of that chat, IIRC. Checking logs ...
  1067. # [19:29] <nickshanks> zcorpan: well i'm not sure, i'd have to look at the page's code
  1068. # [19:29] <zcorpan> nickshanks: if you figure out a good way, let me know
  1069. # [19:29] <nickshanks> even if it has to be done by hand, it won't take as long as writing the spec down in the first place did
  1070. # [19:30] <nickshanks> zcorpan: were you the one responsible for the multipage script?
  1071. # [19:30] <jdandrea> http://krijnhoetmer.nl/irc-logs/whatwg/20070420
  1072. # [19:30] <zcorpan> nickshanks: no
  1073. # [19:30] <jdandrea> Relevant lines:
  1074. # [19:31] <zcorpan> nickshanks: i have contributed to the status script
  1075. # [19:31] <Philip`> nickshanks: Blame me for that :-)
  1076. # [19:31] <jdandrea> zcorpan_: "people asked for a view of the spec that only had the information that applied to authors, i think." Philip`: "Could we add a new HTML element for it? <relevance who="authors"> " zcorpan: "it would be nice but it's hard to do programmatically as it looks now"
  1077. # [19:31] * othermaciej is now known as om_phone
  1078. # [19:31] <nickshanks> zcorpan: <p>The <dfn id=rules3>rules for parsing a list of integers</dfn> are as follows:
  1079. # [19:32] <nickshanks> so it looks like matching on "<dfn id=rules" and taking the enclosing block-level element might work as a stating point
  1080. # [19:33] <nickshanks> and why is the webapps spec written in HTML 4 :P
  1081. # [19:33] <Philip`> Trying to simply chop out parts of the document would probably be too much of a constraint on the prose if it was going to be precise, and it'd become hard to read and write - a separate author-level not-officially-normative spec may be easier to write
  1082. # [19:34] <Philip`> nickshanks: Apparently just because of the tools used to generate it
  1083. # [19:34] <Philip`> The multipage one is HTML5, since that has nicer tools ;-)
  1084. # [19:34] <nickshanks> fair engough
  1085. # [19:34] <nickshanks> -g
  1086. # [19:35] <Philip`> (I hope the multipage one is using <nav> correctly - I never really checked what the spec says...)
  1087. # [19:35] <zcorpan> nickshanks: ok, but that wouldn't catch very much... if we want to filter out things that don't apply to authors, we have to filter out everything that doesn't apply to authors and find a sane way to do so
  1088. # [19:36] <nickshanks> doing it by hand may be boring, but is probably the only way
  1089. # [19:36] <zcorpan> Philip`: i think it does
  1090. # [19:36] <zcorpan> nickshanks: ok. so who would do it and how exactly?
  1091. # [19:37] <nickshanks> probably hixie, and by putting a div around them
  1092. # [19:37] <nickshanks> or a class on the <p>
  1093. # [19:37] <nickshanks> it need not be hidden at the moment
  1094. # [19:38] <nickshanks> but given a new bg colour
  1095. # [19:38] <nickshanks> or some such
  1096. # [19:38] * zcorpan thinks Hixie's time is better spent on other things
  1097. # [19:38] <nickshanks> zcorpan: does anyone else have authorship access to that document?
  1098. # [19:39] <nickshanks> also, it can wait until the spec gets finalised
  1099. # [19:39] <zcorpan> nickshanks: define finilised
  1100. # [19:39] <nickshanks> but UA implementation instructions should not be shown by default to HTML authors who just want to learn about this new spec that just got announced.
  1101. # [19:40] <zcorpan> agreed, problem is how to do it
  1102. # [19:40] <nickshanks> zcorpan: either CR or REC depending on how busy the editor is
  1103. # [19:40] <nickshanks> well the alternative is cutting up the document into a UA version and a HTML version
  1104. # [19:41] <nickshanks> which would probably take just as long
  1105. # [19:41] <nickshanks> (but wouldn't require javascript, so...)
  1106. # [19:42] <zcorpan> nickshanks: i was thinking of somehow applying a mask on top of the spec with javascript
  1107. # [19:42] <Philip`> I imagine there'd be extra text that probably should be shown only in the author version, not the real-spec version - e.g. the parsing section would be replaced with "you write <tag attr="value">...</tag> but you can skip the closing one on this list of elements, and you have to nest them properly, etc" (but written far better), which (as far as I can tell) is not in the real spec today
  1108. # [19:42] <nickshanks> or painting the screen with TippEx
  1109. # [19:42] <zcorpan> haven't figured out if or how it would work exactly though
  1110. # [19:43] <zcorpan> but perhaps in a similar way as the status markers
  1111. # [19:43] <nickshanks> the red fortresses?
  1112. # [19:44] * Philip` has currently been identifying sentences in the spec by using regexps that match them, which is probably quite fragile and inefficient, but at least it works and doesn't need the spec itself to be modified
  1113. # [19:44] <zcorpan> nickshanks: yes
  1114. # [19:44] <nickshanks> how would that hide them from potentially confusable HTML newbies?
  1115. # [19:45] * Joins: KevinMarks (i=KevinMar@nat/google/x-f6759bb1de81ae92)
  1116. # [19:45] <zcorpan> nickshanks: you locate the elements that are irrelevant to authors, then hide them with css
  1117. # [19:46] <nickshanks> am investingating....
  1118. # [19:46] <nickshanks> okay, so it seems we have code like:
  1119. # [19:46] <nickshanks> <h3 id=forms><span class=secno>3.16. </span>Forms</h3>
  1120. # [19:46] <nickshanks> <!-- XXX everything in WF2 -->
  1121. # [19:46] <nickshanks> <p class=big-issue>This section will contain definitions of the
  1122. # [19:46] <nickshanks> <code>form</code> element and so forth.
  1123. # [19:47] <nickshanks> so is CSS or JS responsible for inserting the [TBW] bit there?
  1124. # [19:47] <zcorpan> nickshanks: look at http://status.whatwg.org/annotate-web-apps.js
  1125. # [19:47] <nickshanks> thx
  1126. # [19:48] * Joins: Voluminous (n=Volumino@unaffiliated/voluminous)
  1127. # [19:49] <nickshanks> okay, so that isn't how the HTML4 version works
  1128. # [19:51] <nickshanks> zcorpan: seems like it would work in HTML5 with some simple changes for what we want
  1129. # [19:51] <nickshanks> but that means the current HTML4 version would need to be a secondary document, one that HTML authors aren't going to come across easily
  1130. # [19:51] * Philip` isn't sure what the difference is
  1131. # [19:52] <nickshanks> Philip`: ? difference with what
  1132. # [19:53] <Philip`> Between the HTML4 version and HTML5 version
  1133. # [19:54] <nickshanks> well the js linked above operated on <section staus=""> tags
  1134. # [19:55] <nickshanks> it would be simpler to write a different javascript IMO
  1135. # [19:55] <nickshanks> not that it matters too much at this point anyway
  1136. # [19:55] <Philip`> Ah, no, that's the <section>s in http://www.whatwg.org/specs/web-apps/current-work/annotate-data.xml
  1137. # [19:56] <nickshanks> ooh, thanks :)
  1138. # [19:59] * Joins: olli (n=olli@229.80-203-95.nextgentel.com)
  1139. # [20:05] <zcorpan> the magic of hiding stuff that doesn't apply to authors could be done in the multipage script instead, i don't know which would be simpler to do
  1140. # [20:05] <Philip`> Depends on whether you like JavaScript or Python, I guess
  1141. # [20:06] * Joins: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  1142. # [20:06] <Philip`> I suppose JS has the problem that you wouldn't want authors to download 1.5MB of spec and then have their JS engine chug over it for a minute and then throw most of the document away
  1143. # [20:07] <zcorpan> that's why it's multipage, no? :)
  1144. # [20:07] <zcorpan> but indeed
  1145. # [20:08] <zcorpan> if done with js, it could work with both the single page version and the multipage version
  1146. # [20:08] <Philip`> Oh, I forgot about that one :-)
  1147. # [20:08] * Quits: johnst (n=johnst@x1-6-00-04-61-4a-1f-54.k459.webspeed.dk) ("Leaving")
  1148. # [20:08] <zcorpan> if done with python, it would only work with the multipage version, which is ok because people who would read the subset view would probably prefer multipage anyway
  1149. # [20:09] <Philip`> The Python one could generate a stripped-down version of the single-page version easily
  1150. # [20:09] <zcorpan> ok
  1151. # [20:09] <nickshanks> just hope it doesn't strip away everything :)
  1152. # [20:09] <Philip`> (just by having it load the original, do the stripping, then write the single-page output, then split it into sections and write all the sections)
  1153. # [20:10] <zcorpan> right
  1154. # [20:10] <Philip`> I suppose at least some sections would involve stripping everything away
  1155. # [20:12] * Joins: polin8_ (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net)
  1156. # [20:15] * Quits: polin8 (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net) (Read error: 145 (Connection timed out))
  1157. # [20:15] <zcorpan> we could perhaps just write css that hides stuff
  1158. # [20:16] <zcorpan> #status+p+p, ...all other thigns that are to be hidden... { display:none; }
  1159. # [20:16] * zcorpan looks into whether that would work
  1160. # [20:17] <Philip`> We really should use the 'irrelevant' attribute, but then it couldn't easily change relevance depending on the audience
  1161. # [20:17] * Quits: polin8_ (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net) (Remote closed the connection)
  1162. # [20:18] * Joins: polin8 (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net)
  1163. # [20:19] <zcorpan> i was thinking of just an alternate style sheet
  1164. # [20:20] <zcorpan> you get the full spec by default, but can change to the subset view using the browser's style sheet switcher
  1165. # [20:20] <zcorpan> or with a scripted link or #hash in the uri or whatever
  1166. # [20:21] <annevk> Acid3 should test :target
  1167. # [20:22] <nickshanks> what about :target needs an acid test?
  1168. # [20:22] <nickshanks> seems to work fine for me
  1169. # [20:23] <Philip`> Maybe HTML5 should allow <div audience="authors">...<p irrelevant="authors">...<p>...<p irrelevant="authors">...</div>
  1170. # [20:23] <zcorpan> :target+p doesn't work correctly in safari
  1171. # [20:23] <Philip`> then you could fake it in legacy browsers with CSs like [irrelevant] { display: none } [audience="authors"] [irrelevant="authors"] { display: inherit }
  1172. # [20:23] <Philip`> *CSS
  1173. # [20:23] * Quits: KevinMarks (i=KevinMar@nat/google/x-f6759bb1de81ae92) ("The computer fell asleep")
  1174. # [20:23] <zcorpan> Philip`: let's not make it harder than it needs to be :)
  1175. # [20:24] <Philip`> zcorpan: CSS is for presentation, but this is altering the semantics of the document so it's a guide for authors instead of a normative spec, hence the need for an HTML attribute rather than CSS :-)
  1176. # [20:25] <zcorpan> Philip`: when there are implementations of irrelevant="" i might change my mind, but for now i'm trying to find the simplest solution possible
  1177. # [20:25] * Philip` likes making things harder than they need to be, as long as he doesn't actually have to do any work for them
  1178. # [20:25] <nickshanks> alternativlyly, you caould say it is the "don't present me with too much info" viewing
  1179. # [20:25] <zcorpan> it's not like authors will read the subset view with lynx or anything... and even if they did lynx doesn't support irrelevant=""
  1180. # [20:26] <Philip`> Authors could submit patches to lynx
  1181. # [20:26] <zcorpan> if selecting already present elements is good enough, it seems to me that just having an alternative stylesheet is the simplest
  1182. # [20:27] <zcorpan> that stylesheet could be created by the status script
  1183. # [20:27] <zcorpan> or inserted by the status script... if we want to maintain the stylesheet separately
  1184. # [20:33] * Quits: primal1_ (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  1185. # [20:36] <zcorpan> this seems to work better than i expected
  1186. # [20:38] * Joins: primal1 (n=primal1@pool-72-87-242-30.lsanca.fios.verizon.net)
  1187. # [20:42] * Joins: mw22_ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  1188. # [20:47] * hsivonen just got more convinced about the relative efficiency of the WHATWG working methods
  1189. # [20:47] <annevk> heh, could have told you that beforehand
  1190. # [20:49] <hsivonen> annevk: John Boyer's reply to you was most interesting
  1191. # [20:49] <om_phone> hsivonen: I can't believe he said "we don't have to answer that"
  1192. # [20:49] * om_phone is now known as othermaciej
  1193. # [20:49] <annevk> hsivonen, to me or someone else?
  1194. # [20:49] <hsivonen> annevk: to you, I think
  1195. # [20:50] <annevk> hsivonen, to be honest, I missed his interesting reply I'm afraid
  1196. # [20:50] <annevk> at least, I don't recall any
  1197. # [20:50] <hsivonen> annevk: what othermaciej quoted above
  1198. # [20:50] <othermaciej> I think that was to MatthewRaymond
  1199. # [20:51] <annevk> didn't DanC say that?
  1200. # [20:51] <hsivonen> oh
  1201. # [20:51] <annevk> in reply to me?
  1202. # [20:51] <othermaciej> I'm pretty sure John Boyer said that
  1203. # [20:51] <jdandrea> <DanC> re "no answer necessary"... I'll have to elaborate in email. that's not a very good record of what I said. or meant. ???
  1204. # [20:51] <annevk> That they're not obliged to answer that question and that we're in this together or something...
  1205. # [20:51] <annevk> That seems to confirm it was indeed the chair
  1206. # [20:51] <othermaciej> well, I was a bit confused about who said what
  1207. # [20:52] <annevk> Although othermaciej raised the question again in a different form and he didn't say it again...
  1208. # [20:52] <hsivonen> I thought it was Boyer's voice
  1209. # [20:52] <hsivonen> anyway, it bothers me that XForms Transitional is taken for granted
  1210. # [20:52] <annevk> from the minutes: "DanC: good question to ask, no answer necessary"
  1211. # [20:52] <annevk> to me it seemed like a reasonable question...
  1212. # [20:53] * Joins: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  1213. # [20:53] <annevk> as it seems that the HTML WG generally agrees WF2 is a good idea
  1214. # [20:53] <othermaciej> oh, per the minutes it says DanC, I assume he'll correct it if it wasn't him
  1215. # [21:03] <annevk> it was him (per #html-wg)
  1216. # [21:07] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  1217. # [21:11] * Joins: aroben (i=adamrobe@nat/apple/x-8dc52e074f3c3384)
  1218. # [21:17] <zcorpan> perhaps the status markers would be easier to implement with a stylesheet too
  1219. # [21:17] <zcorpan> it's already implemented though but we still need a way to maintain it and extend it with "implemented" markers etc
  1220. # [21:18] * Joins: aroben_ (i=adamrobe@nat/apple/x-e7be68454207fde3)
  1221. # [21:18] <zcorpan> a stylesheet seems to be a lot simpler
  1222. # [21:19] <Philip`> Does it have to work in IE7?
  1223. # [21:20] <zcorpan> ie7 doesn't support generated content... so ms would have to implement that for ie8 :)
  1224. # [21:20] <hsivonen> I wonder what browser the people who complain about the single-page spec size use
  1225. # [21:21] <Philip`> Will the IE developers be reading the HTML5 spec in IE? :-)
  1226. # [21:21] <hsivonen> WFM in Firefox and Opera
  1227. # [21:21] <zcorpan> hsivonen: yeah. in ie7 it is a real pain. in firefox it freezes for a second when you do autoscrolling. in opera it works fine.
  1228. # [21:22] <zcorpan> don't know about safari
  1229. # [21:22] <hsivonen> works fine in Opera even a device with 64 MB of RAM (haven't tried in Minimo, yet)
  1230. # [21:22] <Philip`> It seems to work alright for me in IE6 - it takes twenty seconds to load then has a JS error (missing XMLHttpRequest), but otherwise it seems perfectly fine
  1231. # [21:33] * Quits: aroben (i=adamrobe@nat/apple/x-8dc52e074f3c3384) (Read error: 110 (Connection timed out))
  1232. # [21:42] <zcorpan> ponder, some things in the spec are only defined in terms of ua conformance requirements, if i were to hide all ua conformance requirements then authors wouldn't know how e.g. document.URL works
  1233. # [21:42] <annevk> conformance for APIs is a red herring
  1234. # [21:42] <annevk> I'm not entirely sure what "red herring" implies, but I think my usage of it here is correct :)
  1235. # [21:43] <zcorpan> annevk: what i said was that authors want to know what the APIs do
  1236. # [21:44] <annevk> fair enough
  1237. # [21:44] <othermaciej> I don't think "red herring" applies here
  1238. # [21:44] <othermaciej> "red herring" implies that something was brought up as a relevant point but is actually not applicable to the issue at hand
  1239. # [21:44] <othermaciej> a meaningless distraction
  1240. # [21:44] <annevk> hah, ignore me then!
  1241. # [21:45] <zcorpan> so some UA conformance requirements would have to stay in the "author subset view", or would have to be rewritten as statements of facts for authors in that view
  1242. # [21:45] <othermaciej> conformance requirements for API use are in general dubious, since no kind of automated verification is possible
  1243. # [21:45] <othermaciej> however, other languages such as C do have such a concept, basically any program that is syntactically valid and does not rely on undefined behavior
  1244. # [21:45] <othermaciej> I think many C programs implicitly rely on technically undefined behavior though
  1245. # [21:46] <zcorpan> like encoding? (just guessing here)
  1246. # [21:46] <othermaciej> the fact that char is exactly 8 bits
  1247. # [21:46] <othermaciej> is one of the more common ones
  1248. # [21:47] <zcorpan> ok
  1249. # [21:47] <othermaciej> assuming that C strings are in ASCII encoding is another
  1250. # [21:48] <zcorpan> before i asked my teacher in programming what encoding C used. "extended ascii" he said.
  1251. # [21:49] <zcorpan> i said i didn't know what extended ascii meant -- is it windows-1252, iso-8859-1, utf-8, or what? he couldn't answer that
  1252. # [21:49] <zcorpan> google didn't help me either
  1253. # [21:50] <zcorpan> it seems to me that it depends on the compiler, but i'm not sure
  1254. # [21:51] <hsivonen> hrm. Opera doesn't do SVG arrowheads
  1255. # [21:51] <othermaciej> it depends on the compiler and on the C library
  1256. # [21:51] <hsivonen> Prince doesn't either. grr
  1257. # [21:51] <hsivonen> Firefox and WebKit support them
  1258. # [21:51] <hsivonen> yay for interop
  1259. # [21:52] * Joins: aroben (i=adamrobe@nat/apple/x-1df7e624006f5b13)
  1260. # [21:52] <zcorpan> othermaciej: ok
  1261. # [21:55] * Joins: KevinMarks (i=KevinMar@nat/google/x-a35b18b0ce2846a0)
  1262. # [22:03] <Philip`> zcorpan: Do you mean the encoding of the source code files, or of the strings passed to/from the C standard library?
  1263. # [22:03] <zcorpan> the source code files
  1264. # [22:04] <Philip`> C99 says "Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary."
  1265. # [22:04] <Philip`> so that's not undefined behaviour
  1266. # [22:05] <zcorpan> just implementation-defined?
  1267. # [22:06] <othermaciej> implementation-defined behavior is undefined, if you assume it is being done in some specific way
  1268. # [22:06] <othermaciej> for instance, assuming your physical source is UTF-16 and is translated to a source character set of UTF-8 would be wrong
  1269. # [22:06] <Philip`> The source character set is letters, digits, and 29 graphic characters, and some whitespace
  1270. # [22:06] <Philip`> "If any other characters are encountered in a source file (except in an identifier, a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token), the behavior is undefined."
  1271. # [22:07] <zcorpan> ah
  1272. # [22:07] <zcorpan> ok
  1273. # [22:07] <zcorpan> our teacher did printf("hallå där"); all the time
  1274. # [22:07] <Philip`> but inside a string literal, it sounds like it allows any character (i.e. single byte)
  1275. # [22:08] <Philip`> othermaciej: The difference is that implementation-defined behaviour is documented by the implementation, whereas undefined behaviour isn't
  1276. # [22:09] <Philip`> (in their terminology)
  1277. # [22:09] * Quits: aroben_ (i=adamrobe@nat/apple/x-e7be68454207fde3) (Read error: 110 (Connection timed out))
  1278. # [22:09] <Philip`> but it's as good as undefined if you can't find the documentation for it :-)
  1279. # [22:11] <annevk> zcorpan, so to get CSS fixed some browsers need to change behavior...
  1280. # [22:11] <Philip`> Oh, I'm wrong about it being a single byte - only the source character set must be, but you can have other multibyte characters
  1281. # [22:11] <Philip`> (as far as I can see)
  1282. # [22:12] <zcorpan> annevk: what are you referring to?
  1283. # [22:12] <annevk> xhtml body
  1284. # [22:12] <zcorpan> ah
  1285. # [22:12] <zcorpan> yes
  1286. # [22:12] <Philip`> but it all seems like implementation-defined behaviour - the only requirement is that '0'..'9' are sequential character codes, which I guess is true even in EBCDIC
  1287. # [22:13] <Philip`> (In the code I've worked on, we've avoided the problems by rewriting German names to have nice ASCII "ae" instead, though that was problems with editors and SVN rather than with the compiler...)
  1288. # [22:14] <zcorpan> annevk: so it's time to file bugs about this, eh?
  1289. # [22:14] <annevk> think so
  1290. # [22:14] * zcorpan goes ahead and does so
  1291. # [22:20] <annevk> whoa, w3.org is slow
  1292. # [22:20] <zcorpan> indeed
  1293. # [22:21] <annevk> guess the telcon took all their resources :p
  1294. # [22:21] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  1295. # [22:29] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne) ("k lol plz thx bai")
  1296. # [22:34] <annevk> although I don't entirely agree with the CSS WG (which I'm in...)
  1297. # [22:35] <annevk> this is not about what implementations do, but about what's better for XHTML
  1298. # [22:41] <zcorpan> is the css21 spec in cvs? where?
  1299. # [22:42] <annevk> Member only
  1300. # [22:43] <zcorpan> ok
  1301. # [22:43] <annevk> not really :p
  1302. # [22:44] <zcorpan> didn't imply that it was ok :)
  1303. # [22:44] <zcorpan> meant ok as in "so now i know"
  1304. # [22:45] <zcorpan> ...and don't need to search further
  1305. # [22:47] <annevk> i know (hence the smiley)
  1306. # [22:50] * Joins: tantek_ (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  1307. # [22:50] * Quits: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  1308. # [22:52] * zcorpan considers creating equivalent html and xhtml test cases that are the same byte by byte
  1309. # [22:53] <zcorpan> either that or i should run a script that converts html tests to equivalent xhtml
  1310. # [22:53] <annevk> that's doable now
  1311. # [22:54] <Philip`> How do you test that the converter is correct?
  1312. # [22:54] <annevk> not talking about converting
  1313. # [22:54] <annevk> talking about byte identical tests with a different MIME type
  1314. # [22:54] <annevk> where both are conforming
  1315. # [22:55] <zcorpan> Philip`: with the parsing test suite?
  1316. # [22:55] <zcorpan> annevk: [22:50] <zcorpan> either that or i should run a script that converts html tests to equivalent xhtml
  1317. # [22:55] * annevk replies to Philip`
  1318. # [22:55] <Philip`> Ah, are xmlns and xml:lang and stuff now conforming HTML5?
  1319. # [22:55] <annevk> replied* damn it
  1320. # [22:55] <annevk> Philip`, xmlns is
  1321. # [22:56] <annevk> the cool thing about that is not byte identical files though
  1322. # [22:57] <annevk> it's that you can write <html xmlns=http://www.w3.org/1999/xhtml> and do a happy dance
  1323. # [22:57] <zcorpan> lol
  1324. # [23:01] <Philip`> annevk: Aha, okay. (I was remembering what I'd done for HTML->XHTML conversion, and forgot the (xml:)lang is optional)
  1325. # [23:02] <annevk> I think we should get rid of xml:lang and just make it lang throughout
  1326. # [23:02] <annevk> same reasons as for not adopting xml:id
  1327. # [23:03] <annevk> actually, we still have to define that xml:lang takes precedence, when specified
  1328. # [23:03] <zcorpan> annevk: isn't that defined already?
  1329. # [23:04] <zcorpan> or nm
  1330. # [23:04] <annevk> (it was in reply to me suggesting getting rid of it altogether)
  1331. # [23:05] <zcorpan> (figured)
  1332. # [23:07] <Philip`> The spec says the xml:lang attribute takes precedence over the lang attribute, but is that talking about the "lang" attribute in the "xml" namespace, as distinct from the "xml:lang" attribute in the default namespace (like what an HTML5 parser would produce)?
  1333. # [23:07] <hsivonen> offtopic: do I understand correctly that <svg height="50%"> in a compound document refers to the height of the containing block if the containing block has a non-auto height and to the width of the containing block if the height of the containing block is auto?
  1334. # [23:08] <annevk> Philip`, oh, lang in xml:
  1335. # [23:08] <annevk> hsivonen, that sounds wrong
  1336. # [23:08] <zcorpan> Philip`: see #terminology
  1337. # [23:08] <annevk> hsivonen, unless it has an aspect ratio of 1:1
  1338. # [23:08] <annevk> hsivonen, or something
  1339. # [23:09] <hsivonen> annevk: ok. what's the right answer? what do height percentages on outer <svg> refer to?
  1340. # [23:09] <Philip`> annevk: So that precedence rule can only apply to document deserialised from XHTML5 and not HTML5? (I think that makes sense now)
  1341. # [23:10] <annevk> hsivonen, I'm not an expert on this, but I believe it becomes a CSS height of 50%.
  1342. # [23:10] <zcorpan> Philip`: if you don't do scripting then yes
  1343. # [23:10] <annevk> hsivonen, http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width and http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height would then clarify what happens
  1344. # [23:10] * Joins: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  1345. # [23:11] <annevk> hsivonen, the problem is though that I believe the CSS WG agreed to change those sections (again!) so it's likely something different in a couple of weeks
  1346. # [23:12] <hsivonen> annevk: WebKit and Gecko seem to follow my hypothesis
  1347. # [23:12] <hsivonen> annevk: can't figure out what Opera does
  1348. # [23:12] <annevk> Gecko has the wrong implementation of SVG height and width
  1349. # [23:12] * Quits: jcgregorio (i=chatzill@nat/ibm/x-2aae5dd19f6353be) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/0000000000]")
  1350. # [23:12] <annevk> dunno about WebKit
  1351. # [23:13] <annevk> Opera had something close to CSS 2.1 (but now that changed!) in some build (parts might be in Opera 9)
  1352. # [23:13] <hsivonen> annevk: so what's the intrinsic ratio for SVG? the ratio of viewBox?
  1353. # [23:13] <hsivonen> annevk: I've got 9.20
  1354. # [23:13] <annevk> I think so
  1355. # [23:14] <hsivonen> considering that I'm making a document that is supposed to last years unmodified, I don't like this
  1356. # [23:14] <annevk> SVG is either really vague about all this or it's just me
  1357. # [23:14] <annevk> which is certainly possible
  1358. # [23:14] <annevk> Besides 42, I suppose the answer is PNG
  1359. # [23:15] <hsivonen> basically, I wan't to say "give me 100% and the height that is right for the viewBox aspect ratio"
  1360. # [23:15] <hsivonen> s/100%/100% width/
  1361. # [23:16] <hsivonen> annevk: one possibility is that height can compute to auto, but height='auto' is an error and falls back to height='100%'
  1362. # [23:16] * annevk wonders how CSS 2.1 can go to LC while changing intrinsic widths
  1363. # [23:16] <annevk> and heights
  1364. # [23:16] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Leaving")
  1365. # [23:16] <annevk> a block with percentage height within one with height auto becomes 0
  1366. # [23:16] <hsivonen> and it certainly doesn't help that em-sized SVG in horked in Gecko
  1367. # [23:20] <hsivonen> rough interop with the moron method achieved between WebKit, Firefox trunk and Prince
  1368. # [23:20] <hsivonen> unwanted results in Opera
  1369. # [23:21] <hsivonen> I have to say that SVG/CSS cooperation has a serious counterintuitiveness or downright brokenness in this very reasonable use case
  1370. # [23:21] <annevk> post it to www-style
  1371. # [23:21] <annevk> maybe www-svg
  1372. # [23:22] <annevk> I would like to be more of assistence, but people just tell me how they think it should work, without actually saying where that's defined
  1373. # [23:22] <annevk> (for instance, the SVG WG said that percentage widths / heights on svg:svg elements don't contribute to the intrinsic width / height mechanism in CSS)
  1374. # [23:23] <annevk> (where implementors and testcase writers assumed it they would)
  1375. # [23:23] <hsivonen> annevk: current attempt: http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#back-end
  1376. # [23:23] <hsivonen> bed time
  1377. # [23:23] * Joins: hendry (n=hendry@client-82-27-228-178.brnt.adsl.virgin.net)
  1378. # [23:25] <hsivonen> annevk: thanks. I will have to investigate more
  1379. # [23:26] <hsivonen> annevk: perhaps use the Distler em hack and use ems that equal 100% under my particular Prince conditions
  1380. # [23:37] * Quits: polin8 (n=brian@dsl081-134-176.nyc1.dsl.speakeasy.net)
  1381. # [23:41] * Quits: olli (n=olli@229.80-203-95.nextgentel.com)
  1382. # [23:44] * Quits: annevk (n=annevk@86.90.70.28) (Read error: 110 (Connection timed out))
  1383. # [23:49] <zcorpan> is http://simon.html5.org/test/css/magic-body/003.htm too evil?
  1384. # [23:50] <Hixie> too evil for what?
  1385. # [23:50] <Hixie> it's blank on ff2
  1386. # [23:51] <Hixie> seems quite reasonable to me
  1387. # [23:51] <zcorpan> i mean, too much an edge case for being relevant for web content
  1388. # [23:51] <zcorpan> however the situation is more likely in xml so
  1389. # [23:52] <Hixie> it's not something that will be run into frequently, but it should work
  1390. # [23:52] <Hixie> it's not a P1, but it should work
  1391. # [23:52] <zcorpan> ok
  1392. # [23:54] <nickshanks> i get a white page with no text in safari (title works though)
  1393. # [23:54] <Hixie> do you get a js error in safari?
  1394. # [23:55] <Hixie> (if anything fails at replaceChild() you'll get a blank page)
  1395. # [23:55] <zcorpan> blank page in firefox 2 is weird. the dom looks ok and it works in firefox 3 (but it still fails the test)
  1396. # [23:55] <Hixie> i wonder why it doesn't render anything in ff2
  1397. # [23:55] <Hixie> weird
  1398. # [23:55] <Hixie> oh it works on trunk? ok
  1399. # [23:56] <Hixie> then who cares about ff2 :-)
  1400. # [23:56] <zcorpan> indeed :)
  1401. # [23:56] <Hixie> k
  1402. # [23:56] <Hixie> well
  1403. # [23:56] <Hixie> i told the htmlwg that r1000 was the version we were putting forward
  1404. # [23:56] <Hixie> i guess i'd better get cracking on commiting changes
  1405. # [23:57] <Hixie> since we're just under r700 at the moment
  1406. # [23:58] <zcorpan> if you want me to bug you about typos then shout ;)
  1407. # [23:58] <Hixie> nah
  1408. # [23:58] <Hixie> still too early for typos
  1409. # [23:58] <zcorpan> </kidding>
  1410. # [23:58] <Hixie> i think i'll just start responding to feedback
  1411. # [23:58] <Hixie> oh there'll come a time where typos will be critical :-)
  1412. # [23:58] <Hixie> that's when the spec is done :-P
  1413. # [23:58] <zcorpan> yeah
  1414. # Session Close: Fri Apr 27 00:00:00 2007

The end :)