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

Options:

  1. # Session Start: Thu May 03 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  4. # [00:06] * Quits: h3h (n=h3h@66-162-32-234.static.twtelecom.net) ("|")
  5. # [00:10] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  6. # [00:10] * Joins: om_interview (i=mjs@nat/apple/x-36dd8bd5f3f7c090)
  7. # [00:38] <Hixie> annevk: btw, i don't even remotely intend to go through and read every piece of feedback sent to public-html. if you see specific things that should be taken into account, please feel free to forward them to me (or the whatwg list, or forward a pointer to the whatwg list) so i can make sure to take them into account.
  8. # [00:46] * om_interview is now known as othermaciej
  9. # [00:50] <Hixie> wow, anne actually caused a spec to not go through the CR transition call
  10. # [00:50] <Hixie> i'm impressed
  11. # [00:51] <othermaciej> really? how?
  12. # [00:51] <hober> pointer?
  13. # [00:51] <othermaciej> and which spec?
  14. # [00:52] <Hixie> http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0146.html
  15. # [00:52] <hober> behind the member-wall :(
  16. # [00:53] <hsivonen> cool!
  17. # [00:55] * Joins: zcorpan_ (n=zcorpan@84-216-43-182.sprayadsl.telenor.se)
  18. # [01:13] * Joins: aroben_ (i=adamrobe@nat/apple/x-6c9ba46211983659)
  19. # [01:15] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  20. # [01:16] * Quits: aroben_ (i=adamrobe@nat/apple/x-6c9ba46211983659) (Read error: 104 (Connection reset by peer))
  21. # [01:17] * Joins: aroben_ (i=adamrobe@nat/apple/x-d77e662ceb414735)
  22. # [01:19] * Quits: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  23. # [01:21] * Joins: tantek (n=tantek@66.116.112.10)
  24. # [01:21] * Quits: aroben (i=adamrobe@nat/apple/x-b56ead43957edd32) (Read error: 60 (Operation timed out))
  25. # [01:22] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
  26. # [01:36] * Joins: fantasai (i=fantasai@connectionreset.info)
  27. # [01:36] <fantasai> hsivonen?
  28. # [01:37] <hsivonen> fantasai?
  29. # [01:37] <fantasai> I'm going through your responses to my comments
  30. # [01:38] <fantasai> I still have some questions
  31. # [01:38] <fantasai> I'll send it to you in a few minutes
  32. # [01:39] <hsivonen> ok.
  33. # [01:49] * Joins: KevinMarks (i=KevinMar@nat/google/x-40289633b2871ccd)
  34. # [01:53] <hsivonen> fantasai: reading your mail now. it is 02:49 in my timezone and I have a lunch meeting at noon, so my judgment may be bad and hasty
  35. # [01:53] <fantasai> k
  36. # [02:04] * Quits: tantek (n=tantek@66.116.112.10)
  37. # [02:13] <hsivonen> fixes as per the first email should be live now.
  38. # [02:13] <hsivonen> I really have to go to bed now, so I'll reply to the rest later
  39. # [02:14] <hsivonen> thanks
  40. # [02:14] <hsivonen> nn
  41. # [02:17] <fantasai> g'night
  42. # [02:22] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.2 (IRC client for Emacs)")
  43. # [02:24] * Quits: h3h (n=h3h@66-162-32-234.static.twtelecom.net) ("|")
  44. # [02:29] * Joins: tantek (n=tantek@66.116.112.2)
  45. # [02:30] * Quits: Toolskyn (n=toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Read error: 110 (Connection timed out))
  46. # [02:41] * Quits: bzed (n=bzed@dslb-084-059-106-147.pools.arcor-ip.net) ("Leaving")
  47. # [02:48] * Quits: KevinMarks (i=KevinMar@nat/google/x-40289633b2871ccd) ("The computer fell asleep")
  48. # [02:55] * moeffju is now known as moeffju[ZzZz]
  49. # [02:59] * Quits: othermaciej (i=mjs@nat/apple/x-36dd8bd5f3f7c090) (Read error: 110 (Connection timed out))
  50. # [03:00] * Quits: tantek (n=tantek@66.116.112.2)
  51. # [03:02] * Joins: tantek (n=tantek@66.116.112.2)
  52. # [03:03] * Joins: aroben (i=adamrobe@nat/apple/x-410fc15432e50510)
  53. # [03:15] * Quits: tantek (n=tantek@66.116.112.2) (Read error: 145 (Connection timed out))
  54. # [03:18] * Philip` wonders if it's a known issue that '<span style="color:red"> One <p> Two </span> Three' parsed by html5lib can't match the mostly-interoperable rendering of IE6/FF2/O9
  55. # [03:19] <Philip`> (because it creates a "Two Three" text node, whereas the browsers all do Two in red and Three in black)
  56. # [03:19] * Quits: aroben_ (i=adamrobe@nat/apple/x-d77e662ceb414735) (Read error: 110 (Connection timed out))
  57. # [03:20] <Hixie> try it with <em>
  58. # [03:20] <Hixie> is it still different?
  59. # [03:20] <Hixie> if yes, then that's because we specifically avoided <span> because Safari said we didn't have to do it for <span>
  60. # [03:20] <Hixie> s/Safari/experience based on Safari's implementation/
  61. # [03:20] <Philip`> html5lib parses that correctly (i.e. splitting into two <em>s)
  62. # [03:21] <Hixie> yeah
  63. # [03:21] <Hixie> in that case it's intentional
  64. # [03:21] <Hixie> we want to keep the number of "magic" elements to a minimum
  65. # [03:21] <Philip`> (span appears to be not mentioned in the parsing algorithm, so it's the same as any unrecognised element)
  66. # [03:21] <Hixie> yup
  67. # [03:21] <Philip`> Ah, okay then
  68. # [03:23] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Get thee behind me, satan.")
  69. # [03:43] * Joins: othermaciej (i=mjs@nat/apple/x-1d89632f40b627ae)
  70. # [03:54] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  71. # [04:09] * Joins: inkbase (n=inkbase@S0106000fb52973b5.vc.shawcable.net)
  72. # [04:12] * Quits: othermaciej (i=mjs@nat/apple/x-1d89632f40b627ae) (Read error: 110 (Connection timed out))
  73. # [04:19] * Parts: fantasai (i=fantasai@connectionreset.info)
  74. # [04:30] * Quits: bewes1 (n=bewest@c-67-164-56-2.hsd1.ca.comcast.net) (Read error: 113 (No route to host))
  75. # [04:38] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  76. # [04:47] * Quits: ozone (n=andrep@starbuck.algorithm.com.au) (Read error: 145 (Connection timed out))
  77. # [04:53] * Quits: aroben (i=adamrobe@nat/apple/x-410fc15432e50510)
  78. # [05:08] * Joins: aroben (i=adamrobe@nat/apple/x-5c54b0b8452cd046)
  79. # [05:09] * Joins: aroben_ (i=adamrobe@nat/apple/x-6bb6c61e44f7229e)
  80. # [05:16] * Quits: aroben (i=adamrobe@nat/apple/x-5c54b0b8452cd046) (Read error: 60 (Operation timed out))
  81. # [05:31] * Quits: aroben_ (i=adamrobe@nat/apple/x-6bb6c61e44f7229e) (Read error: 110 (Connection timed out))
  82. # [05:51] * Joins: htmlr (n=cjb@203-158-34-70.dyn.iinet.net.au)
  83. # [06:10] * Quits: zcorpan_ (n=zcorpan@84-216-43-182.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  84. # [06:11] * Joins: hober (n=ted@unaffiliated/hober)
  85. # [06:22] * Quits: sgillies (n=chatzill@dsl-179-116.dynamic-dsl.frii.net) (Read error: 104 (Connection reset by peer))
  86. # [06:25] * Joins: sgillies (n=chatzill@dsl-179-116.dynamic-dsl.frii.net)
  87. # [06:39] * Joins: pw_thirdfloor (n=pw_third@eth2.pepper.mbase.com.au)
  88. # [06:42] * Quits: marcosc (n=chatzill@131.181.148.226) ("...and I'm gone.")
  89. # [06:53] * Joins: aroben (n=adamrobe@user-64-9-234-227.googlewifi.com)
  90. # [06:55] * Quits: pw_thirdfloor (n=pw_third@eth2.pepper.mbase.com.au)
  91. # [07:02] * Quits: aroben (n=adamrobe@user-64-9-234-227.googlewifi.com)
  92. # [07:22] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  93. # [07:27] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  94. # [07:28] <met_> Someone doesn't undestand joke http://blog.whatwg.org/html6-plan#comment-3728
  95. # [07:42] * Quits: inkbase (n=inkbase@S0106000fb52973b5.vc.shawcable.net)
  96. # [07:45] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.2 (IRC client for Emacs)")
  97. # [08:10] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  98. # [08:11] * Joins: tantek (n=tantek@wsip-24-120-86-254.lv.lv.cox.net)
  99. # [08:28] * Joins: road-kill (i=enderz@euromed.bacau.rdsnet.ro)
  100. # [08:41] <annevk> Hixie, I was referring to his comments on the WHATWG
  101. # [08:42] * annevk will try to write less one-liners
  102. # [09:02] * Quits: tantek (n=tantek@wsip-24-120-86-254.lv.lv.cox.net)
  103. # [09:10] * Quits: htmlr (n=cjb@203-158-34-70.dyn.iinet.net.au)
  104. # [09:28] * Joins: htmlr (n=cjb@203-158-34-70.dyn.iinet.net.au)
  105. # [09:34] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  106. # [09:36] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Client Quit)
  107. # [09:37] * Joins: Martijn_ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  108. # [09:37] * Martijn_ is now known as mw22
  109. # [09:43] * Joins: KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net)
  110. # [09:56] * Joins: met_ (n=Hassman@b14-4.vscht.cz)
  111. # [10:14] * Joins: marcosc (n=chatzill@131.181.148.226)
  112. # [10:26] * Quits: marcosc (n=chatzill@131.181.148.226) (Read error: 104 (Connection reset by peer))
  113. # [10:28] * Quits: MrNaz (n=Naz@203-214-95-166.dyn.iinet.net.au) ("Leaving")
  114. # [10:42] * Joins: Toolskyn (n=toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  115. # [10:48] * Joins: Lachy_ (n=Lachlan@124-168-27-56.dyn.iinet.net.au)
  116. # [10:48] * Quits: Lachy (n=Lachlan@124-168-27-56.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  117. # [10:56] * Joins: ROBOd (n=robod@86.34.246.154)
  118. # [11:00] * Joins: MrNaz (n=Naz@203-214-95-166.dyn.iinet.net.au)
  119. # [11:04] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  120. # [11:08] * moeffju[ZzZz] is now known as moeffju
  121. # [11:19] * Quits: psa (n=yomode@posom.com) (Remote closed the connection)
  122. # [11:58] * Joins: hendry (n=hendry@91.84.53.136)
  123. # [12:57] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) ("reboot biab")
  124. # [13:01] * Joins: KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net)
  125. # [13:19] * Joins: yod (n=ot@bas11-montreal02-1128531044.dsl.bell.ca)
  126. # [14:00] <hsivonen> Hixie: it might be a practical move to give the <font> issue priority in your feedback queue
  127. # [14:01] <annevk> has there been new evidence?
  128. # [14:01] <annevk> apart from the fact that style= is prolly to be made conforming
  129. # [14:02] <hsivonen> annevk: I, for one, have weeks ago presented a technical (backwards compat) argument why <font> with a transparent content model is bad
  130. # [14:03] <hsivonen> annevk: and we all know that UAs will have to support style='' on every element anyway
  131. # [14:03] <annevk> oh, allowing <font> everywhere?
  132. # [14:03] <annevk> yeah, i wasn't talking about UAs
  133. # [14:04] <hsivonen> annevk: as for the popularity point of view, so far it looks like no one (except for Hixie and perhaps you) likes the way <font> is specced
  134. # [14:05] <annevk> i think some people want <font> in there at all
  135. # [14:05] <hsivonen> annevk: the current speccing is inferior compared to allowing style='' on every element for the compat/practical point of view and the current way of speccing is additionally massively unpopular
  136. # [14:06] <annevk> do you want the content model of <font> to change or simply making it non-conforming?
  137. # [14:06] * annevk doesn't really care about <font> atm
  138. # [14:06] <hsivonen> annevk: moreover, repurposing <font> is a bad political move, because the new element doesn't behave like the old <font> but gets the negative reputation of the old <font>
  139. # [14:07] <hsivonen> annevk: I want to:
  140. # [14:07] <hsivonen> 1) Allow style='' on every element
  141. # [14:07] <hsivonen> 2) either
  142. # [14:07] <hsivonen> a) remove <font>
  143. # [14:07] <hsivonen> or
  144. # [14:07] <hsivonen> b) allow font as a strictly inline element that has the attribute color
  145. # [14:08] <hsivonen> I expect accessibility folk to shoot down b)
  146. # [14:08] <hsivonen> but 1) is my main point
  147. # [14:08] <annevk> that has not much to do with <font> then, i think :)
  148. # [14:09] <hsivonen> annevk: it has everything to do with how Hixie has specced <font>
  149. # [14:24] <annevk> fair enough
  150. # [14:25] * Joins: htmlr_ (n=cjb@203-217-80-229.dyn.iinet.net.au)
  151. # [14:25] <annevk> although I doubt people have read that
  152. # [14:43] * Quits: htmlr (n=cjb@203-158-34-70.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  153. # [14:49] <annevk> even entities can have public and external identifiers
  154. # [15:01] <annevk> XML is crazy
  155. # [15:02] <annevk> I especially like that entity declarations can contain XML subtrees and the like and therefore references to other entities
  156. # [15:02] <annevk> so you have to address looping of those entity references in some way
  157. # [15:03] * annevk wonders if there's a blue pill somewhere
  158. # [15:13] <Lachy_> http://lists.w3.org/Archives/Public/public-html/2007May/0305.html - was that supposed to be a joke or something? I know what Groundhog day is, but I don't see the relevance.
  159. # [15:15] <annevk> i didn't understand it
  160. # [15:15] <annevk> also not after looking up Groundhog
  161. # [15:15] <annevk> I've sort of given up, I think
  162. # [15:15] <Dashiva> I think it maybe possibly might be another way of saying "Didn't you say that before, again and again and again?"
  163. # [15:15] <annevk> I'll be waiting until the chairs make some noise
  164. # [15:15] <Dashiva> But that's pure guesswork, not founded in reality
  165. # [15:15] <annevk> Which is unlikely to be soon given that DanC is going away Sunday or so
  166. # [15:16] <annevk> Dashiva, that sounds about right
  167. # [15:17] * annevk repeated it lots of time in different ways hoping they'd just get it at some point
  168. # [15:17] <annevk> how naive
  169. # [15:17] <Dashiva> Don't worry, we'll be doing this for another 10 years, just lean back and enjoy the ride
  170. # [15:19] <annevk> i'm sort of hoping to get something done too
  171. # [15:20] * Joins: tantek (n=tantek@wsip-24-120-86-254.lv.lv.cox.net)
  172. # [15:20] <annevk> and i've the feeling that goal isn't shared
  173. # [15:20] <annevk> or maybe people don't understand the amount of work involved
  174. # [15:37] * Joins: mpt_ (n=mpt@canonical/launchpad/mpt)
  175. # [15:39] <Lachy_> heh, the guy in this video reminds me of the attitudes of some people on public-html (though he's slightly more extreme) :-) - http://www.youtube.com/watch?v=qYgZYkTYUaQ
  176. # [15:41] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  177. # [15:55] * Joins: zcorpan_ (n=zcorpan@84-216-40-239.sprayadsl.telenor.se)
  178. # [15:57] <Lachy_> this would be an awesome colour scheme for acid 3 http://img172.imageshack.us/img172/9812/colorsgq0.png :-)
  179. # [15:58] <wilhelm> (c:
  180. # [16:01] * mpt_ is now known as mpt
  181. # [16:04] <Lachy_> here's one with the actual hex codes http://www.hd-dvd-tee.com/images/bubble.png
  182. # [16:05] <zcorpan_> there can't be any red when it passes :)
  183. # [16:06] <Lachy_> there already is in the current colour scheme
  184. # [16:06] <Lachy_> http://www.hixie.ch/tests/evil/acid/003/reference.html
  185. # [16:06] <zcorpan_> indeed, i think that's not so good
  186. # [16:07] <zcorpan_> test case with red == fail to me
  187. # [16:08] <Lachy_> zcorpan_, acid tests aren't traditional test cases, they're marketing material
  188. # [16:08] <zcorpan_> so?
  189. # [16:08] <zcorpan_> it will contain more red when it fails, no?
  190. # [16:08] <Lachy_> They have to look cool to the average author, not just be all green and say PASS, or whatever
  191. # [16:09] <Lachy_> doesn't look like it
  192. # [16:09] <Philip`> Maybe people would analogise with litmus paper and think red = acid therefore the acid test succeeded
  193. # [16:09] <annevk> would be awesome to have an Acid test that does just that :)
  194. # [16:09] <zcorpan_> i didn't suggest being all green, just don't contain red when it passes
  195. # [16:10] <Lachy_> I just don't see what problem you are trying to solve by elimiating red from the acid 3 test case.
  196. # [16:10] * Quits: yod (n=ot@bas11-montreal02-1128531044.dsl.bell.ca) ("Leaving")
  197. # [16:10] <Lachy_> :-)
  198. # [16:10] * Joins: yod (n=ot@bas11-montreal02-1128531044.dsl.bell.ca)
  199. # [16:11] <zcorpan_> pehaps people will create their own test cases after seeing acid
  200. # [16:11] <Dashiva> Why not let people pick a color stylesheet, then?
  201. # [16:11] <Lachy_> yes, that's what they did with acid 2
  202. # [16:12] <annevk> acid3-red
  203. # [16:12] <zcorpan_> acid2 contained red when it failed
  204. # [16:12] <Lachy_> the acid test isn't useful as is to implementers, except as a way to say "oh look, we have some bugs", but not any more specific without deconstructing it
  205. # [16:12] <zcorpan_> so people might think that acid3 fails if it contains red
  206. # [16:13] * Quits: road-kill (i=enderz@euromed.bacau.rdsnet.ro) ("yes i won't")
  207. # [16:17] * Parts: Lachy_ (n=Lachlan@124-168-27-56.dyn.iinet.net.au) ("Leaving")
  208. # [16:25] * Joins: Lachy (n=Lachlan@124-168-27-56.dyn.iinet.net.au)
  209. # [16:27] <Philip`> Acid2 had a happy face when it passed, but that doesn't mean people will think Acid3 hasn't passed just because it doesn't have a face
  210. # [16:28] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  211. # [16:28] <Philip`> Acid1 had red too
  212. # [16:29] <zcorpan_> indeed, it can contain pretty much anything when it passes
  213. # [16:29] <zcorpan_> it's just a fact that most tests contain red when they fail
  214. # [16:49] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  215. # [16:50] * Joins: billmason (n=billmaso@ip156.unival.com)
  216. # [16:56] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  217. # [16:57] * Quits: hendry (n=hendry@91.84.53.136) ("brb")
  218. # [17:00] <Lachy> it is so confusing having 2 Philip Taylors on the list! I have to check the e-mail address just to see if it's the sensible one, or the other one. :-/
  219. # [17:01] <annevk> they both use the suffic (Webmaster)?
  220. # [17:01] <Lachy> no, which is good
  221. # [17:01] <annevk> so you can just check that
  222. # [17:02] <Lachy> I just got confused at first, cause I thought he had just removed that from his name
  223. # [17:02] <annevk> whoa, already 5pm
  224. # [17:02] * Joins: hendry (n=hendry@openmanage.navisite-europe.com)
  225. # [17:02] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  226. # [17:03] <annevk> I think tomorrow I'll do some implementing then of my xml5lib idea unless something important comes up
  227. # [17:03] * Quits: hendry (n=hendry@openmanage.navisite-europe.com) (Client Quit)
  228. # [17:03] * Joins: hendry (n=hendry@openmanage.navisite-europe.com)
  229. # [17:06] * Joins: Faf (i=eracbbsw@nezmar.netlab.cz)
  230. # [17:11] <Philip`> Lachy: You could check punctuation too - one does /italics/ and double-spaces between sentences and spaces before colons and question marks, whereas the other doesn't :-)
  231. # [17:13] <Lachy> oh no, and I thought you were the sensible one. It's 2 spaces after a full stop! :-)
  232. # [17:14] <othermaciej> 2 spaces between sentences is incorrect when using a proportional font
  233. # [17:15] <Lachy> plain text emails use monospace fonts
  234. # [17:16] <Lachy> (well, actually, they use whatever font the user likes, but typically monospace)
  235. # [17:16] <othermaciej> plain text emails don't use any specific font; how they are displayed depends on the mail client
  236. # [17:16] <gavin_> hmm, really? I'd have thought it'd be incorrect to use it with monospace fonts
  237. # [17:16] <gavin_> but I know nothing about this!
  238. # [17:16] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  239. # [17:17] <annevk> apparently text/plain is displayed using <plaintext> in some UAs
  240. # [17:17] <othermaciej> Mail on Mac OS X displays them by default in a proportional font, for instance
  241. # [17:17] <Lachy> ascii art and code samples look better when viewed with monospace fonts
  242. # [17:17] <annevk> someone please call tag abuse!
  243. # [17:17] <othermaciej> annevk: it's just an example of how browsers hate standards
  244. # [17:17] * Lachy doesn't like proportional fonts for emails, it just looks wrong
  245. # [17:18] <annevk> geek
  246. # [17:18] * annevk uses monospace too though
  247. # [17:18] <othermaciej> proportional fonts look better to me unless someone went out of their way to make a point and align things in a way that requires a monospace font
  248. # [17:18] <othermaciej> when I have a part of my email that requires monospace display to read right, I ususally send an HTML email w/ an explicit font setting
  249. # [17:19] <Lachy> I just assumed most people would use monospace
  250. # [17:19] <othermaciej> so that I know my reader will get the right thing
  251. # [17:19] <othermaciej> I don't know how other mail clients are configured out of the box
  252. # [17:20] <Lachy> I never send HTML email
  253. # [17:20] <othermaciej> gmail doesn't use a monospace font by default
  254. # [17:20] <othermaciej> I don't think any other webmail client does
  255. # [17:20] <Lachy> yeah, gmail is broken
  256. # [17:20] <othermaciej> I'd be very surprised if Exchange does
  257. # [17:21] <Lachy> I don't think it does, but I think it offers the choice, IIRC
  258. # [17:21] <othermaciej> so probably most people use the default settings of popular mail clients
  259. # [17:21] <Lachy> default for Thunderbird is monospace
  260. # [17:21] <mpt> Next up from the WhatWG: RFC5822
  261. # [17:22] <Lachy> LOL
  262. # [17:23] <othermaciej> the RFCs don't go that high yet, do they?
  263. # [17:23] <Lachy> they're up to 4xxx
  264. # [17:23] <annevk> otherwise we'd have 8225
  265. # [17:25] <Lachy> We've got RFC5616, RFC5023 and RFC5854 to write first :-)
  266. # [17:26] <annevk> 3023 -> 5023?
  267. # [17:26] <annevk> right
  268. # [17:26] <Lachy> yes
  269. # [17:26] * annevk will incorperate 3023 in XML5
  270. # [17:26] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  271. # [17:26] <annevk> of course, that won't be done when I fnish my project, but some of it will be in
  272. # [17:26] <Lachy> 2854 (text/html) will be in HTML5 anwya
  273. # [17:26] <Lachy> *anyway
  274. # [17:27] * annevk wonders how many people will appreciate XML5
  275. # [17:27] * annevk thinks it's a nice project for now
  276. # [17:27] <Lachy> I bet Philip Taylor (Webmaster) and Gareth Hays won't be happy
  277. # [17:27] <mpt> XML5? What's that?
  278. # [17:28] <annevk> superset of XML1 and XML1.1 with user friendly error handling
  279. # [17:28] <Lachy> non-draconian XML
  280. # [17:28] <mpt> oh boy
  281. # [17:29] <annevk> mpt, the idea or the mess in e-mail it might create?
  282. # [17:29] <mpt> I don't care about the mess in e-mail, I'm not subscribed to any w3.org lists
  283. # [17:29] <mpt> I'm just wondering whether XHTML5 would ever be an XML5 application
  284. # [17:29] <annevk> all things XML will be XML5
  285. # [17:29] <annevk> it's like all things HTML are HTML5
  286. # [17:29] <mpt> seeing as how HTML5's error recovery is so element-specific
  287. # [17:30] <annevk> oh
  288. # [17:30] <annevk> XHTML5 will use XML5 error handling which is not element-specific
  289. # [17:30] <annevk> if it's up to me
  290. # [17:30] <Philip`> But you couldn't write X(HT)ML5 documents and have them degrade gracefully in legacy user agents
  291. # [17:30] <annevk> XML would just stay a generic language
  292. # [17:30] <mpt> annevk, won't that break the Web?
  293. # [17:30] <annevk> mpt, XHTML isn't used
  294. # [17:30] <Lachy> the web is already broken, XML on teh web isn't well formed
  295. # [17:30] <annevk> mpt, and you'll only render more if you start "fixing" XML
  296. # [17:31] * annevk isn't talking about XHTML as text/html, that's HTML5
  297. # [17:31] <mpt> my head hurts
  298. # [17:31] <annevk> it's all about MIME types :)
  299. # [17:31] <mpt> My day-job is XHTML-as-text/html
  300. # [17:31] <annevk> XML MIME types -> XML5, text/html -> HTML5
  301. # [17:32] <annevk> mpt, that would use the HTML5 parsing algorithm
  302. # [17:32] <mpt> ok, but then, the error recovery for HTML5-with-slashes will still be different from that in XHTML5
  303. # [17:32] <gsnedders> yes
  304. # [17:32] <gsnedders> XHTML-as-text/html is currently parsed as malformed HTML.
  305. # [17:33] <gsnedders> (to the extent of which HTML can be malformed)
  306. # [17:33] <mpt> So XHTML5 will be how we escape to a world of predictable error handling?
  307. # [17:33] <mpt> (as in human-predictable)
  308. # [17:34] <gsnedders> both will be predictable if you know the rules :P
  309. # [17:34] <mpt> gsnedders, I'm assuming most humans won't memorize the HTML5 rules
  310. # [17:34] <gsnedders> mpt: most humans won't memorise XML5 rules either
  311. # [17:35] <mpt> Then make them simpler
  312. # [17:35] <Philip`> Doesn't that just depend on how complex the XML5 rules are?
  313. # [17:35] <annevk> XML5 rules are very simple in my head
  314. # [17:35] <gsnedders> mpt: most humans have bo reason to.
  315. # [17:36] * mpt tries to figure out how to download Opera
  316. # [17:36] <annevk> "</test>" -> if <test> is in scope, close everything up to and including <test>, otherwise, ignore
  317. # [17:36] <annevk> "<test>" -> append a tag to the stack of open elements
  318. # [17:36] <annevk> that's about it
  319. # [17:36] <mpt> ok, that's simple enough
  320. # [17:36] <annevk> on popular request we might get </> -> pop an element from the stack of open elements
  321. # [17:37] <mpt> I guess the simplest counterexample would be <a><b><c><d> </c></b></a>
  322. # [17:37] <mpt> oh wait, no, that works too
  323. # [17:37] <mpt> up to and including
  324. # [17:37] <mpt> Nifty, I like it
  325. # [17:40] <Lachy> I don't think you should define new features that would be incompatible with XML 1.0 well-formedness constraints
  326. # [17:40] <Lachy> in other words, a conforming XML5 doc must be a well formed XML 1.0 doc
  327. # [17:40] * Parts: Faf (i=eracbbsw@nezmar.netlab.cz)
  328. # [17:41] <annevk> I don't want to restrict characters in element names for no good reason
  329. # [17:41] <gsnedders> any well formed XML 1.0 must be a well formed XML 5 document, mapping to the exact same DOM tree, IMO
  330. # [17:42] <annevk> yes
  331. # [17:42] <annevk> that's a requirement
  332. # [17:42] <mpt> annevk, how about not being able to see any error even after a validator points it out, because in an element's end tag you've accidentally used a Unicode character that looks extremely similar to the one you meant
  333. # [17:42] <annevk> I'd like to require the same for XML 1.1
  334. # [17:42] <annevk> mpt, aren't you doing something with usability? :)
  335. # [17:43] <mpt> I don't fully understand that question
  336. # [17:43] <annevk> note that XML 1.1 allows way more characters in tag names
  337. # [17:43] <annevk> almost unrestricted
  338. # [17:44] <annevk> mpt, well, (1) the validator could go to extreme lengths and make sure those are clear, (2) if people are using such tag names they probably know what they're doing
  339. # [17:44] <Lachy> ah, good point
  340. # [17:44] <mpt> (1) "the tools will save us"
  341. # [17:44] * mpt ducks
  342. # [17:45] <annevk> yeah, fair enough
  343. # [17:45] <mpt> (2) "accidentally"
  344. # [17:46] * annevk blames it on XML 1.1
  345. # [17:46] <mpt> but if XML 1.1 already allows non-Ascii characters, I guess that's lost
  346. # [17:47] * annevk likes it when the obvious things (such as "allow unicode") have nasty flaws
  347. # [17:47] <annevk> (it also goes for "use XML" which is fricking complicated compared to say, JSON)
  348. # [17:48] * Quits: tantek (n=tantek@wsip-24-120-86-254.lv.lv.cox.net)
  349. # [17:48] <mpt> The AGM of the Law of Unintended Consequences Fan Club is now in session
  350. # [17:48] <hsivonen> mpt: XML 1.0 allows non-ASCII element names
  351. # [17:48] * Joins: ROBOd (n=robod@86.34.246.154)
  352. # [17:48] <mpt> Ooh, I know, make them non-conformant but define how they should be parsed
  353. # [17:49] <hsivonen> mpt: XML 1.1 is an unpragmatic excercise in markup *nationalization* (not *inter*nationalization) by allowing Khmer, etc. element names that XML 1.0 did not allow
  354. # [17:50] <hsivonen> mpt: XML 1.1 is about political correctness and causes harm to real world
  355. # [17:50] <annevk> no, XML 1.0 only allowed Unicode 2.0 characters
  356. # [17:50] <annevk> XML 1.1 allows all characters (with some restrictions)
  357. # [17:50] <hsivonen> annevk: right. which is why e.g. Khmer was not allowed
  358. # [17:51] <hsivonen> annevk: but most of e.g. Japanese was covered in XML 1.0
  359. # [17:51] <annevk> mpt, that's an idea
  360. # [17:51] * annevk wonders how that will fly
  361. # [17:52] <mpt> <＜﹤≲≳﹥＞></＜﹤≲≳﹥＞>
  362. # [17:53] <hsivonen> annevk: will your XML5 be resilient to Unicode normalization combining an combining solidus with >?
  363. # [17:55] <annevk> aah
  364. # [17:55] <annevk> no more Unicode today
  365. # [17:55] <annevk> it will do whatever experts tell is better
  366. # [17:56] <annevk> but hopefully I can stay mostly silent on the dark corners of character representation for a while
  367. # [18:13] <zcorpan_> Lachy: did you see the entry i wrote for the faq?
  368. # [18:14] * Joins: psa (n=yomode@posom.com)
  369. # [18:14] * Quits: met_ (n=Hassman@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  370. # [18:14] <Lachy> no
  371. # [18:16] <Lachy> zcorpan_, where did you post it?
  372. # [18:17] <zcorpan_> in here... can't find it in the logs though
  373. # [18:21] <Philip`> Was it while Krijn was offline?
  374. # [18:22] <zcorpan_> could be
  375. # [18:23] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  376. # [18:23] <zcorpan_> seems i've lost it too
  377. # [18:23] <Lachy> what was it about?
  378. # [18:23] <Lachy> I have almost full logs, so if you can tell me what to search for...
  379. # [18:24] <zcorpan_> "why does html5 allow for deprecated elements or tag soup?"
  380. # [18:24] <zcorpan_> or something like that
  381. # [18:24] <zcorpan_> "actually it doesn't"
  382. # [18:25] <Philip`> Look for "this should be added to the faq"
  383. # [18:25] <Lachy> May 02 10:38:39 <zcorpan_> Lachy_: perhaps we should add something along the following lines to the faq...
  384. # [18:25] <Lachy> May 02 10:38:46 <zcorpan_> Why does HTML5 allow for deprecated markup or tag soup?
  385. # [18:25] <Lachy> May 02 10:38:46 <zcorpan_> Actually it doesn't. This is a misconception that comes from a fundamental misunderstanding of what the specification is saying.
  386. # [18:25] <Lachy> May 02 10:38:46 <zcorpan_> The HTML5 spec defines what UAs must do when they are confronted with invalid markup, as a way to achieve interoperability and reduce the need for reverse engineering other browsers. For instance, it is defined what to do with misnested tags. This does not imply that authors are allowed to misnest tags.
  387. # [18:25] <Lachy> May 02 10:38:46 <zcorpan_> The HTML5 spec also defines what authors must do in order to create conforming documents, as a way to promote the creation of accessible and device-independent documents. For instance, authors must not use the marquee element. This does not imply that UAs must ignore marquee elements.
  388. # [18:25] <Lachy> May 02 10:38:49 <zcorpan_> You have to be able to make the distinction between the rules that UAs have to follow to be conforming, and the rules authors have to follow to be conforming. They are completely orthogonal.
  389. # [18:25] <zcorpan_> yes, that
  390. # [18:25] <Lachy> I'll review it later
  391. # [18:25] <zcorpan_> ok
  392. # [18:25] * Lachy -> bed!
  393. # [18:26] <zcorpan_> cya
  394. # [18:28] * Joins: bzed (n=bzed@dslb-084-059-104-121.pools.arcor-ip.net)
  395. # [18:35] * Quits: hendry (n=hendry@openmanage.navisite-europe.com) ("leaving")
  396. # [18:45] <zcorpan_> annevk: shouldn't you change http://annevankesteren.nl/img/logo to say "WEBLOG5"? :)
  397. # [18:45] <zcorpan_> or "WEBLOG42"
  398. # [18:50] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  399. # [19:01] * Joins: zcorpan (n=zcorpan@84-216-42-62.sprayadsl.telenor.se)
  400. # [19:06] <mpt> dbaron, where can I find an explanation of your quit message?
  401. # [19:07] <dbaron> it's just a message printed by a lisp implementation I was using
  402. # [19:07] <dbaron> it had a generational GC
  403. # [19:07] <dbaron> it should make sense if you look up generational garbage collection
  404. # [19:07] <mpt> ok, thanks
  405. # [19:07] <mpt> It's been bothering me for years
  406. # [19:07] <dbaron> I suppose the idea is sort of that I'm getting collected by the garbage collector and disappearing. :-)
  407. # [19:08] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  408. # [19:12] <dbaron> Hrm, I have a fixed bug report claiming we implemented http://www.whatwg.org/specs/web-apps/current-work/#alternate-style-sheets
  409. # [19:13] <dbaron> but that anchor doesn't work
  410. # [19:13] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  411. # [19:13] <dbaron> Hrm, I have a fixed bug report claiming we implemented http://www.whatwg.org/specs/web-apps/current-work/#alternate-style-sheets
  412. # [19:13] <dbaron> but that anchor doesn't work
  413. # [19:13] <dbaron> how would I find where that content is now?
  414. # [19:13] <dbaron> Did it move to some other spec?
  415. # [19:13] <dbaron> And if so, shouldn't the anchor stay, with a pointer?
  416. # [19:17] <gavin_> it's probably http://www.whatwg.org/specs/web-apps/current-work/#link-type
  417. # [19:18] * gavin_ also finds https://bugzilla.mozilla.org/show_bug.cgi?id=200930#c96 :)
  418. # [19:18] <Philip`> It would be nice if the links didn't move, but the tools aren't set up to make that happen
  419. # [19:18] <zcorpan> http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.src.html?content-type=text/html;%20charset=utf-8
  420. # [19:18] * Quits: zcorpan_ (n=zcorpan@84-216-40-239.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  421. # [19:22] * Quits: htmlr_ (n=cjb@203-217-80-229.dyn.iinet.net.au)
  422. # [19:23] * Joins: tantek (n=tantek@67.136.237.149)
  423. # [19:27] <jruderman> http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html#dynamically ? seems newer
  424. # [19:28] * Joins: othermaciej (i=mjs@nat/apple/x-a1725f73231c3987)
  425. # [19:29] <Philip`> annevk: The list of acknowledgements in that CSSOM document isn't quite alphabetical ("Sj" before "Si")
  426. # [19:29] <jruderman> if a stylesheet has been in the document before and it's put back into the document, should it go through that algorithm to decide whether it's enabled or should it remember whether it was enabled?
  427. # [19:30] <jruderman> "If new style sheets with titles are added to the document" ... i guess it depends on what "new" means :(
  428. # [19:34] <jruderman> i guess i'll have to ask annevk
  429. # [19:39] <Hixie> dbaron: it's in the CSSOM spec now
  430. # [19:39] <Hixie> http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?rev=1.35&content-type=text/html;%20charset=utf-8
  431. # [19:40] <Hixie> hsivonen: so, my requirements for the <font>/style="" thing is that style="" not be allowed everywhere, since that encourages media-specific markup.
  432. # [19:41] <Hixie> hsivonen: however, i acknowledge that we have to deal with WYSIWYG UAs that don't have any proven-usable way to encode author intent
  433. # [19:41] <Hixie> hsivonen: i'm open to suggestions, but putting style="" everywhere only deals with the use case of one of the camps involved in the discussion
  434. # [19:44] * zcorpan thinks that disallowing style="" on any element results in not using any other element than <font>, thus resulting in even worse media independence
  435. # [19:45] <zcorpan> e.g. instead of <h1 style> wysiwyg tools would just emit <font style>
  436. # [19:50] <Hixie> wysiwyg tools can use the new embedded <style> and IDs or classes with <div>s and <p>s
  437. # [19:51] <Hixie> or we could provide them with style="" everywhere
  438. # [19:51] <Hixie> the thing is wysiwyg tools are a unique case, and what we allow for wysiwyg tools shouldn't apply to templates, hand-written content, etc
  439. # [19:51] <Hixie> imho
  440. # [19:52] <jruderman> how would you allow different things for wysiwyg than for templates?
  441. # [19:53] <zcorpan> Hixie: the result will be that those who hand-write templates will add the <meta> to claim that they are wysiwyg. so they can use style="" and pass validation
  442. # [19:53] <zcorpan> q.v. transitional doctype and target=""
  443. # [19:53] <zcorpan> *or* they will come up with uglier hacks
  444. # [19:53] <zcorpan> q.v. adding target="" with javascript
  445. # [19:56] <zcorpan> so if we find that we need to allow something for wysiwyg, it has to be conforming for anyone (yet we can discourage or say that authors SHOULD NOT do it or whatever, but trying to force them not to will lead to the same path as target="" situation today, i think)
  446. # [19:59] <zcorpan> or say that it isn't conforming but say that wysiwyg tools can emit it anyway
  447. # [20:00] <zcorpan> what i'm saying is that the wysiwyg meta tag is the new transitional doctype
  448. # [20:00] <dbaron> Hixie, but how do I learn that from the URL I gave above?
  449. # [20:01] <zcorpan> there should be a note in WA1 that has that id, saying that it has moved to cssom :)
  450. # [20:04] * Joins: billmason_ (n=billmaso@ip156.unival.com)
  451. # [20:04] <Hixie> learn what?
  452. # [20:04] <zcorpan> that it has moved to cssom
  453. # [20:05] <Hixie> jruderman, zcorpan: i don't know, i don't have a good solution. if i did, we wouldn't be arguing about it.
  454. # [20:05] <Hixie> oh, i see
  455. # [20:05] <Hixie> (re the altss)
  456. # [20:05] <Hixie> i guess i can add a redirecty-like thing
  457. # [20:05] <Hixie> i might end up just merging it back in if anne doesn't get on with it :-)
  458. # [20:07] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  459. # [20:07] <Hixie> ok, added a link
  460. # [20:10] * Quits: billmason (n=billmaso@ip156.unival.com) (Read error: 145 (Connection timed out))
  461. # [20:14] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  462. # [20:17] <Hixie> dbaron: i added a link to the spec
  463. # [20:18] <dbaron> thanks
  464. # [20:19] <Hixie> np
  465. # [20:22] <othermaciej> zcorpan: isolating the use of purely presentational inline markup seems to have some value
  466. # [20:22] <othermaciej> I'm not sure of the right way to do it myself
  467. # [20:22] <othermaciej> except that most of the extremist positions don't seem right to me
  468. # [20:24] <othermaciej> personally I'd just allow the style attribute on everything still, it seems like a useful shortcut for scoped <style> that also degrades gracefully in existing browsers
  469. # [20:24] <othermaciej> and it doesn't preclude including both aural and visual rules, say
  470. # [20:25] <othermaciej> it does rule out having separate print and screen rules, but that doesn't mean you can't use a scoped <style> if you want to do that
  471. # [20:25] <Hixie> the problem with style="" is that it encourages thinking in a media-specific way
  472. # [20:25] <Hixie> imho
  473. # [20:25] <Hixie> i mean we have inline <style> elements now
  474. # [20:25] <Hixie> that go almost anywhere
  475. # [20:25] <Hixie> and are scoped
  476. # [20:25] <Hixie> why use style=""?
  477. # [20:25] <Hixie> just to omit a selector?
  478. # [20:28] <othermaciej> to omit a selector, an id, and an extra element when you want to apply a style to exactly one element
  479. # [20:28] <othermaciej> or, to apply a scoped style that degrades gracefully to HTML4 UAs
  480. # [20:28] <othermaciej> these seem like practical reasons to me that override concerns about encouragement - seems like that is better addressed through providing scoped style for cases where multiple media must be styled differently
  481. # [20:28] <zcorpan> i'd be fine with dropping style="" altogether, but i don't think making it allowed based on a magic <meta>
  482. # [20:28] <zcorpan> ...is a good idea
  483. # [20:28] <Hixie> i agree that the magic <meta> thing sucks
  484. # [20:28] <othermaciej> do you have any data on how many style blocks or stylesheets have an @media rule or are media-scoped?
  485. # [20:28] <Hixie> no, but i don't imagine it's many at all
  486. # [20:28] <othermaciej> (i.e. through the media="" element)
  487. # [20:29] <bewest> what's the issue?
  488. # [20:29] <othermaciej> if it wasn't very many, that seems to be evidence against a theory that <style> better encourages thinking about multiple-media than style=""
  489. # [20:30] <Hixie> bewest: the issue is that we have several groups with contradictory requirements. we have people who don't want people to let people write presentational markup at all (and want style="" gone forever), we have wysiwyg editors who can only output presentational markup and so need style="", and we have everyone in between.
  490. # [20:31] <bewest> ok
  491. # [20:31] <bewest> yeah, I've been trying to follow along
  492. # [20:31] <bewest> thanks
  493. # [20:32] <zcorpan> currently i think the best outcome is to make style="" conforming on any element for anyone, but at the same time say that authors should not use it (and cite reasons why in the spec, and why it is conforming anyway)
  494. # [20:32] <Hixie> the idea of making style="" only apply to <font> was that we could attach the stigma of <font> to style=""
  495. # [20:32] <bewest> isn't the solution in these kinds of circumstances usually to remove some of the requirements until the issue is solveable?
  496. # [20:33] <Hixie> another possibility is to allow style="" on <font> and <div>, and allow them everywhere
  497. # [20:33] <bewest> zcorpan: that sounds like a good idea
  498. # [20:33] <othermaciej> at least some strict opponents of presentational markup would like to eliminate <b>, <i> and <font>, but have no problem with style=""
  499. # [20:33] <Hixie> (as in, remove the wysiwyg flag)
  500. # [20:34] <othermaciej> I'm not sure if they have clearly thought through their point of view though
  501. # [20:34] <zcorpan> Hixie: (yes)
  502. # [20:34] <Hixie> othermaciej: i'm trying to address their underlying requirements, not what they say they want, which is often stupid and illogical :-)
  503. # [20:34] <bewest> is anyone advocating wysiwyg POV or are we guessing?
  504. # [20:34] * Joins: briansuda (n=briansud@bokd085.rhi.hi.is)
  505. # [20:35] <Hixie> bewest: in this discussion, othermaciej and i both represent wysiwyg interests.
  506. # [20:35] <othermaciej> Hixie: I'm not sure removing style="", allowing it on <font> for WYSIWYG only, and adding scoped <style> addresses any actual requirements
  507. # [20:35] <Hixie> othermaciej: i agree
  508. # [20:35] <Hixie> othermaciej: the current spec is a failed experiment
  509. # [20:35] <Hixie> that much is clear
  510. # [20:36] <Hixie> what would the people here think of allowing style="" on certain elements, namely <font>, <div>, maybe <p>, maybe <section>?
  511. # [20:36] <othermaciej> ok, I'm caught up on public-html email for the first time in days, clearly time to unsubscribe
  512. # [20:36] <Hixie> i don't think it makes sense to make style="" apply to all elements (e.g. <head>)
  513. # [20:36] <zcorpan> Hixie: i don't see the benefit of allowing on only some elements
  514. # [20:37] <Hixie> the idea is to give the wysiwyg enough hooks to do what they want, but to still flag errors when mere mortals attempt to use style=""
  515. # [20:37] <zcorpan> contenteditable doesn't make sense on <head> either
  516. # [20:37] <othermaciej> putting style="" on <head> is silly mainly because the head is not normally displayed, not because it is intrinsically more bad
  517. # [20:37] <othermaciej> irrelevant also doesn't make sense on <head>
  518. # [20:38] <bewest> Hixie: yeah, I'm against more modality.. there's no harm in allowing style="" on head
  519. # [20:38] <zcorpan> Hixie: i think allowing style="" on only some elements will lead to authors only using those elements
  520. # [20:38] <Hixie> the argument is that there's harm merely in style="" existing
  521. # [20:39] <bewest> I think the idea that style="" is allowed on everything is currently in the mindshare of many authors, whether or not it's used
  522. # [20:39] <Hixie> i agree
  523. # [20:39] * Hixie is hoping we can change that mindshare
  524. # [20:39] <Hixie> i shouldn't have mentioned <head>
  525. # [20:39] <jruderman> i'd love to have scoped style
  526. # [20:39] <bewest> my suggestion would be to wait for html6 for that
  527. # [20:40] <Hixie> what can we do to move towards that though?
  528. # [20:40] <jruderman> i don't see the point in breaking the style attribute
  529. # [20:40] <bewest> I like zcorpan's suggestion
  530. # [20:40] <othermaciej> I'm not sure what the harm is of style="" existing that isn't also created by scoped <style> existing
  531. # [20:40] <Hixie> if we don't do anything now, we have no reason to believe anything will change in the future
  532. # [20:40] <bewest> you are doing something: 1.) add an informative note that style="" can be harmful because of media assumptions and 2.) allow <style> anywhere
  533. # [20:41] <Hixie> hmm
  534. # [20:42] <bewest> then the next 10 years of useage can inform the next positive step :-)
  535. # [20:42] <Hixie> maybe we can add two levels of conformance, "five star conforming html5" and "four star conforming html5", where the presence of a style="" attribute causes the document to drop to four stars
  536. # [20:42] <Hixie> what do people think of that idea?
  537. # [20:42] <bewest> that's great
  538. # [20:42] <othermaciej> is that a serious suggestion?
  539. # [20:42] <Hixie> yes
  540. # [20:42] <bewest> kind of like yahoo's browser grades?
  541. # [20:42] <bewest> be careful of slipping down the rabbit hole though
  542. # [20:42] <othermaciej> sounds like a slippery slope
  543. # [20:43] <bewest> people will want graded conformance on other areas as well
  544. # [20:43] <Hixie> slippery slope to where?
  545. # [20:43] <zcorpan> it might still lead to ugly workarounds for people who want five stars but also want to use style=""
  546. # [20:43] <othermaciej> to having many conformance grades with all sorts of differences, not just style=""
  547. # [20:43] <bewest> right
  548. # [20:43] <Hixie> true
  549. # [20:43] <othermaciej> which to me seems like clearly a bad thing
  550. # [20:43] <Hixie> yeah
  551. # [20:43] <Hixie> hmmm
  552. # [20:43] <othermaciej> it would be like Strict/Transitional/Frameset DTDs all over again
  553. # [20:43] <bewest> erm not quite
  554. # [20:43] <Hixie> see, this is why i haven't addressed this issue yet
  555. # [20:44] <Hixie> nobody has come up with a solution that works for all sides
  556. # [20:44] <bewest> there is already different ability levels among authorship
  557. # [20:44] <bewest> it might make sense to capitalize on it
  558. # [20:45] <bewest> whether or not that causes too much work for speccing purposes is a different issue
  559. # [20:45] <Hixie> maybe the two conformance levels can be "valid html5" and "astrophy-approved! valid html5"
  560. # [20:45] <bewest> we have technology for doing feature detection... schematron, griddl, etc...
  561. # [20:46] <zcorpan> if allowing style="" anywhere for anyone is not acceptable, then the next best alternative as i see it is to make it non-conforming for everyone but allow wysiwyg-tools to emit it anyway
  562. # [20:46] <Hixie> zcorpan: unfortunately the flag to distinguish wysiwyg markup from non-wysiwyg markup is itself not acceptable to everyone
  563. # [20:47] <zcorpan> Hixie: without the flag
  564. # [20:47] <Hixie> well then what would the conformance checker say? yay on nay?
  565. # [20:47] <zcorpan> wysiwyg-documents that emit style="" would be non-conforming
  566. # [20:47] <zcorpan> nay
  567. # [20:47] <Hixie> editing tools would never accept that
  568. # [20:47] <Hixie> as in, editing tool representatives
  569. # [20:48] <zcorpan> those two options are the ones i see would prevent ugly workarounds we see today with the transitional/strict situation
  570. # [20:49] <zcorpan> one will not be accepted by semanticists. the other will not be accepted by wysiwyg tools that want to emit conforming content
  571. # [20:50] <bewest> I don't see how you can realistically ax style=""
  572. # [20:50] <Hixie> in continues to amaze me how the xforms advocates totally disbelieve that wf2 has actually managed to spec new features in backwards-compatible ways
  573. # [20:51] <bewest> the path forward would probably look like putting a note that says to avoid style if you can, along with something like "when useage of style="" drops below .5% useage, it will be considered deprecated"
  574. # [20:51] <Hixie> heh
  575. # [20:51] <bewest> and then in the subsequent version drop it :-)
  576. # [20:51] <Hixie> we shouldn't make this conforming if we believe they will one day be non-conforming
  577. # [20:51] <othermaciej> I honestly don't see how having both style="" and scoped <style> is worse than having just scoped <style>
  578. # [20:51] <Hixie> that's just silly
  579. # [20:51] <othermaciej> both allow you to make the same set of mistakes
  580. # [20:52] <othermaciej> and give you the same set of tools to avoid those mistakes
  581. # [20:52] <zcorpan> deprecated! :)
  582. # [20:52] * billmason_ is now known as billmason
  583. # [20:52] <Hixie> i really thing that style="" encourages worse behaviour than <style>, but i have no evidence for that.
  584. # [20:52] <Hixie> so i can't really argue the case.
  585. # [20:52] <bewest> deprecate: express strong disapproval of; deplore
  586. # [20:52] <zcorpan> but being deprecated would still lead to ugly workarounds because authors don't want warnings
  587. # [20:53] <bewest> zcorpan: but you can't offer any evidence of that either
  588. # [20:54] <bewest> in fact I'm not sure the evidence supports that
  589. # [20:54] <bewest> most authors do author invalid content
  590. # [20:54] <zcorpan> no, i can't prove that it will happen, i have just seen it happen with target="" and strict/transitional
  591. # [20:54] <zcorpan> indeed, it would only be worked around by authors who want conforming documents but also want to use style=""
  592. # [20:55] <bewest> zcorpan: and if <style> was available, why wouldn't they use that?
  593. # [20:55] <bewest> zcorpan: especially if style="" is discouraged?
  594. # [20:55] <bewest> or, am I missing the problem with <style>?
  595. # [20:55] <bewest> what's wrong with <style> again?
  596. # [20:56] <zcorpan> hmm, good question. perhaps because it's more verbose
  597. # [20:56] <zcorpan> but that would be their simplest "workaround"
  598. # [20:56] <zcorpan> which isn't very ugly
  599. # [20:57] <zcorpan> instead of <section><h1 style=...> you would have <section><style scoped>h1{...}</style><h1>
  600. # [20:57] <bewest> meanwhile everyone can write the article entitled "style="" considered harmful"
  601. # [20:58] <bewest> zcorpan: who would?
  602. # [20:58] <bewest> zcorpan: wysiwyg editors or authors?
  603. # [20:58] <zcorpan> bewest: authors who want to pass conformance-checking
  604. # [20:58] <bewest> zcorpan: why would authors use that when there are better ways that are more familiar?
  605. # [20:59] <zcorpan> same reason they are using style="" today
  606. # [20:59] <bewest> hmmm
  607. # [20:59] <zcorpan> (this is if style="" would be made non-conforming)
  608. # [20:59] <Philip`> zcorpan: Wouldn't they want graceful degradation too? (which <style scoped> doesn't really give, unless they're sufficiently careful and test in both old and new browsers)
  609. # [21:00] <bewest> zcorpan: are most people using style=""?
  610. # [21:00] <bewest> isn't this two separate issues?
  611. # [21:00] <zcorpan> Philip`: yes, and then it would be even more verbose
  612. # [21:01] <zcorpan> bewest: no, most people are using tables and <font color> :)
  613. # [21:01] <zcorpan> my issue is, if style="" becomes non-conforming, then authors who use it today and want to pass conformance-checking will try to replace it with something else that does the same thing
  614. # [21:02] <zcorpan> if that something else is more verbose or bad in other ways then i don't see the win of making it non-conforming
  615. # [21:02] * Joins: epeus (i=KevinMar@nat/google/x-7e2cf49e893ced03)
  616. # [21:02] <bewest> zcorpan: so what is the preferred way, again? <link /> <style> in head or scoped style blocks?
  617. # [21:02] <bewest> zcorpan: and why do you believe they would opt for scoped style blocks over the other options?
  618. # [21:03] <bewest> zcorpan: you are specifically talking about authors who know that they want their documents to conform?
  619. # [21:03] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) (Nick collision from services.)
  620. # [21:03] <zcorpan> they will do what is simplest for them to do. if moving to an external style sheet is simpler than replacing with inline <style>s or something else then they will do that
  621. # [21:03] <zcorpan> bewest: yes (re your last q)
  622. # [21:04] <zcorpan> this is also why i want target="" to be conforming
  623. # [21:04] <zcorpan> (authors are already working around it not being conforming with scripting)
  624. # [21:05] <zcorpan> this is not a large group of people but their workarounds bother me
  625. # [21:05] <bewest> zcorpan: I'm not convinced that people would opt for the nasty workarounds
  626. # [21:06] <zcorpan> bewest: see e.g. http://www.sitepoint.com/print/standards-compliant-world
  627. # [21:06] <zcorpan> they already are
  628. # [21:06] <bewest> zcorpan: is fear of a workaround a good basis for reasoning about a feature?
  629. # [21:07] <zcorpan> not sure. wysiwyg tools could emit similar workarounds too, fwiw, if they want to emit conforming documents
  630. # [21:08] <bewest> I thought that's the use case we're trying to support, though
  631. # [21:08] <bewest> ooo lunch is here
  632. # [21:09] <zcorpan> yes, but why is e.g. scoped style better than equivalent style=""?
  633. # [21:09] <zcorpan> (i know scoped style is more powerful, but it's also more verbose)
  634. # [21:10] * epeus is now known as KevinMarks
  635. # [21:11] * othermaciej is now known as om_food
  636. # [21:22] * Quits: tantek (n=tantek@67.136.237.149)
  637. # [21:38] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) (Read error: 110 (Connection timed out))
  638. # [21:44] * om_food is now known as othermaciej
  639. # [22:00] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  640. # [22:03] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  641. # [22:07] <bewest> zcorpan: scoped style allows decoupling of media-specific stuff
  642. # [22:07] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  643. # [22:08] <zcorpan> bewest: yes
  644. # [22:11] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  645. # [22:12] * Joins: KevinMarks (i=KevinMar@nat/google/x-a6872ae13a78c710)
  646. # [22:26] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  647. # [22:31] * Quits: yod (n=ot@bas11-montreal02-1128531044.dsl.bell.ca) ("Leaving")
  648. # [22:46] * Joins: tantek (n=tantek@wsip-24-120-86-254.lv.lv.cox.net)
  649. # [22:51] <zcorpan> how should i make it easy to contribute to http://simon.html5.org/temp/author-view-of-html5.css ? move it to google code?
  650. # [22:52] <zcorpan> the wiki?
  651. # [22:52] <bewest> google code is good
  652. # [22:53] <bewest> I've seen people serve files straight from google code svn
  653. # [22:53] <zcorpan> ok. perhaps it should be part of the html5 project at google code
  654. # [22:53] <bewest> svn seems to be the favorite tool these days
  655. # [22:54] <zcorpan> Hixie: how do i go about to add it to http://code.google.com/p/html5/ ?
  656. # [22:55] <Hixie> check out the subversion repository
  657. # [22:55] <Hixie> add a directory
  658. # [22:55] <Hixie> check it back in :-)
  659. # [22:56] <zcorpan> ok
  660. # [22:58] <Philip`> hsivonen: For the table at http://hsivonen.iki.fi/doctype/, in Konqueror 3.5.5 I see exactly the same behaviour as the "Moz & Safari" column, in case you want to update it
  661. # [22:58] <Philip`> (Or should I send email or something?)
  662. # [22:58] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  663. # [23:03] * Joins: nlogax_ (n=nlogax@71-219.lerstenen.t3.se)
  664. # [23:04] <zcorpan> http://html5.googlecode.com/svn/trunk/author-view-of-html5/
  665. # [23:06] * Quits: nlogax (n=nlogax@71-219.lerstenen.t3.se) (Read error: 145 (Connection timed out))
  666. # [23:06] <Philip`> javascript:void(document.getElementsByTagName("head")[0].innerHTML+="<link rel=stylesheet href=http://simon.html5.org/temp/author-view-of-html5.css>") looks like a shorter valid (I hope) alternative
  667. # [23:07] <Philip`> ...but that should probably point to the SVN URL in any case
  668. # [23:07] <zcorpan> Philip`: you're free to modify it :)
  669. # [23:07] <zcorpan> the svn url is text/plain
  670. # [23:09] <Philip`> I'd have to remember my password before modifying it :-)
  671. # [23:09] <zcorpan> http://code.google.com/hosting/settings
  672. # [23:10] <Philip`> text/plain: Ah, okay - that seems to make it work in Opera but not Firefox
  673. # [23:10] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  674. # [23:11] <zcorpan> it could perhaps be hosted somewhere at whatwg.org (as text/css) and the spec could include a <link> to that
  675. # [23:11] <zcorpan> either updated automatically or manually
  676. # [23:13] * Joins: KevinMarks (i=KevinMar@nat/google/x-18c42b4e36a8bbce)
  677. # [23:16] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) (Client Quit)
  678. # [23:22] * Joins: KevinMarks (i=KevinMar@nat/google/x-881159e3b17e52fc)
  679. # [23:26] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  680. # [23:27] * Quits: briansuda (n=briansud@bokd085.rhi.hi.is)
  681. # [23:46] * Joins: ajnewbold (n=fax_mach@74-129-102-1.dhcp.insightbb.com)
  682. # [23:49] <Hixie> othermaciej: you need .value on the form control names in your examples, fyi
  683. # [23:49] <Hixie> as in onforminput="value = 'Hello, ' + firstname.value + ' ' + surname.value; ..."
  684. # [23:50] <othermaciej> Hixie: feel free to correct me - I'm pretty sure that the XForms version would still be much longer if not entirely impossible
  685. # [23:50] <Hixie> i don't think it needs corrections
  686. # [23:51] <Hixie> just thought you'd want to know :-)
  687. # [23:51] <Hixie> another thing is that in wf2 instead of onkeypress it's better to use oninput
  688. # [23:51] <Hixie> i love your autosuggest thing though
  689. # [23:51] <Hixie> that's awesome
  690. # [23:51] <Hixie> two lines!
  691. # [23:51] <bewest> ooOOo where?
  692. # [23:52] <Hixie> <input name="search" type="text" list="suggestions" onkeypress="list.data = '/suggest?prefix=' + value">
  693. # [23:52] <Hixie> <datalist id="suggestions" data="/suggest"></datalist>
  694. # [23:52] <Hixie> (except s/keypress/input/)
  695. # [23:53] <bewest> this is in wf2 or xforms?
  696. # [23:53] <gavin_> wf2
  697. # [23:53] <Hixie> wf2
  698. # [23:53] <Hixie> should work in opera 9 today, even
  699. # [23:53] <Philip`> The lack of ugly namespace prefixes should make it obvious :-)
  700. # [23:54] <bewest> ah that's a nice improvement over the acrobatics required to do it today
  701. # [23:54] <Hixie> yeah
  702. # [23:55] <bewest> I assume the suggestions are stylable via css?
  703. # [23:56] <Hixie> that may or may not be a good assumption
  704. # [23:56] <Hixie> not sure
  705. # [23:57] <othermaciej> Hixie: the one thing it doesn't do well is it lacks hysteresis
  706. # [23:57] <othermaciej> Hixie: that could be added w/ a bit of script
  707. # [23:58] <othermaciej> bewest: they are given as <option> elements, so depends on whether your UA respects styles on <option>
  708. # [23:58] <Hixie> othermaciej: the waiting for the user to stop typing?
  709. # [23:58] <othermaciej> yeah
  710. # [23:58] <Hixie> othermaciej: that's why you should use oninput=""
  711. # [23:58] <Hixie> it's defined to fire "when the UA thinks the user has stopped inputting" or some such
  712. # [23:58] <othermaciej> Hixie: if oninput has that behavior then it totally wins :-)
  713. # [23:58] <Hixie> :-)
  714. # [23:59] <Hixie> you sure you want me to write those examples?
  715. # [23:59] * Hixie is tempted to not bother yet and instead just work on html5
  716. # Session Close: Fri May 04 00:00:00 2007

The end :)