/irc-logs / freenode / #whatwg / 2007-08-13 / end

Options:

  1. # Session Start: Mon Aug 13 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:19] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  4. # [00:33] * Joins: mjs (n=othermac@dsl081-048-145.sfo1.dsl.speakeasy.net)
  5. # [00:34] * mjs is now known as othermaciej
  6. # [00:35] * Quits: Lachy (n=Lachlan@124-168-4-56.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  7. # [00:41] * Joins: jgraham (n=jgraham@81-86-212-224.dsl.pipex.com)
  8. # [00:42] * tak|away is now known as takkaria
  9. # [00:42] * Quits: zcorpan_ (n=zcorpan@84-216-40-215.sprayadsl.telenor.se) (Read error: 104 (Connection reset by peer))
  10. # [00:43] * Joins: zcorpan_ (n=zcorpan@84-216-40-215.sprayadsl.telenor.se)
  11. # [00:43] * takkaria loks at those urls
  12. # [00:44] * Joins: tantek (n=tantek@m815f36d0.tmodns.net)
  13. # [00:45] * Quits: tantek (n=tantek@m815f36d0.tmodns.net) (Client Quit)
  14. # [00:46] * Joins: tantek (n=tantek@m815f36d0.tmodns.net)
  15. # [01:01] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  16. # [01:06] <takkaria> Hixie: I'll have a bash at those urls tomorrow (UK time)
  17. # [01:12] * Joins: karlUshi (n=karl@124-144-94-188.rev.home.ne.jp)
  18. # [01:13] <Hixie> cool
  19. # [01:18] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
  20. # [01:18] * Joins: gavin_ (n=gavin@people.mozilla.com)
  21. # [01:23] * Quits: zcorpan_ (n=zcorpan@84-216-40-215.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  22. # [01:35] <Philip`> http://molly.com is interesting in Links, since it has fifty lines of "Link: favicon", "Link: pingback", "Link: archives: August 2007", ... at the top of the screen, followed by the "skip to the content" link at the top of the third page
  23. # [01:37] <Philip`> (Perhaps that counts as an indication that it'd be nice if pages identified where their content was and let the UAs add a skip-to-content link in an appropriate part of their UI)
  24. # [01:41] * Quits: tndH (i=Rob@adsl-87-102-89-143.karoo.KCOM.COM) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  25. # [02:06] * Quits: tantek (n=tantek@m815f36d0.tmodns.net)
  26. # [02:57] * Joins: Lachy (n=Lachlan@124-168-4-56.dyn.iinet.net.au)
  27. # [03:00] * Joins: kfish (n=conrad@61.194.21.25)
  28. # [03:01] <othermaciej> Hixie: what would an implementation have to do to support the new semantic block-level elements?
  29. # [03:02] <othermaciej> Hixie: would it be appropriate to give them default style of display: block, or no?
  30. # [03:02] <othermaciej> Hixie: is it necessary to do some special rendering of <h1> - <h6> in the presence of sectioning elements?
  31. # [03:02] <othermaciej> Hixie: I'm wondering because those seem like some of the least controversial additions in the spec, but I'm not sure what, if anything, implementations should do for those elements
  32. # [03:05] * Quits: karlUshi (n=karl@124-144-94-188.rev.home.ne.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
  33. # [03:06] <Lachy> othermaciej, display: block; for them would be very useful
  34. # [03:07] <Lachy> I'm not sure about heading rendering though
  35. # [03:07] <othermaciej> Lachy: I could see arguments either way - if they don't have display: block, content authors will be more likely to make documents that degrade gracefully by explicitly setting display: block
  36. # [03:07] <othermaciej> I'm not sure what Hixie's intent was
  37. # [03:10] <Lachy> I think content authors will still set display: block for them to be compatible with legacy UAs during the transitional period until most UAs support them, though I think having the default has display: block; would be the most logical
  38. # [03:10] <Lachy> I think the bigger issue of backwards compatibility is the differences in parsing for known vs. unknown elements
  39. # [03:11] <othermaciej> is there a parsing difference per spec?
  40. # [03:14] <Lachy> no, I meant the way in when legacy UAs will handle them as unknown elements and new UAs will parse them more sensibly
  41. # [03:14] <Lachy> although they're not in the parsing algorithm yet (last time I checked), I assume the sectioning elements will end up being parsed more like div
  42. # [03:54] * Quits: aroben (n=adamrobe@unaffiliated/aroben)
  43. # [04:29] * Joins: karlUshi (n=karl@124-144-94-188.rev.home.ne.jp)
  44. # [04:39] * Joins: KevinMarks (n=Snak@c-76-102-254-252.hsd1.ca.comcast.net)
  45. # [05:09] * Joins: mjs (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  46. # [05:10] * Quits: othermaciej (n=othermac@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  47. # [05:10] * mjs is now known as othermaciej
  48. # [05:43] * Joins: zcorpan_ (n=zcorpan@84-216-41-122.sprayadsl.telenor.se)
  49. # [05:46] * Joins: aroben (n=adamrobe@unaffiliated/aroben)
  50. # [05:46] * Quits: aroben (n=adamrobe@unaffiliated/aroben) (Remote closed the connection)
  51. # [05:46] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  52. # [06:10] * Quits: weinig (i=weinig@nat/apple/x-73fd7878da5a9772)
  53. # [06:16] * Quits: zcorpan_ (n=zcorpan@84-216-41-122.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  54. # [06:28] * Joins: G0k (n=hmason@c-67-190-9-212.hsd1.co.comcast.net)
  55. # [06:36] <Hixie> othermaciej: my intent (unsure whether it's workable in reality) is for <h2>-<h6> to continue as is, for all the new block-level elements to have display:block as a style, and for <h1> to automatically style appropriately according to the section depth as defined by the outline section
  56. # [06:37] <Hixie> othermaciej: but i have no idea if that is practical back-compat wise, let alone if it is implementable with good perf
  57. # [06:38] <G0k> hixie: did you get a chance to look at that event-source stuff yet?
  58. # [06:38] <G0k> oh wait i got an email back from you
  59. # [07:01] <G0k> oh heh actually i have another question about that
  60. # [07:03] <G0k> if you have >1 RemoteEventTarget node within a single document, and they all get the same event source URI added to them, should the UA open one connection for each object, or just open one and then dispatch events from that connection to all the listeners?
  61. # [07:06] * Joins: mpt_ (n=mpt@121-72-138-60.dsl.telstraclear.net)
  62. # [07:11] * Quits: mpt (n=mpt@121-72-130-73.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  63. # [07:20] <Hixie> G0k: i believe the spec unambiguously requires the former
  64. # [07:22] <G0k> hm. isn't there like a 2 HTTP connections per UA rule per server?
  65. # [07:22] <Hixie> yes, i wouldn't recommend that people have more than one of these things
  66. # [07:23] <G0k> yeah i suppose that makes sense
  67. # [07:25] <G0k> and is there like a pre-draft of what the Access-Control HTTP header might look like?
  68. # [07:35] <Hixie> yeah
  69. # [07:35] <Hixie> www.w3.org/tr/access-control or some such
  70. # [07:38] <G0k> ah
  71. # [07:40] * Quits: aroben (n=adamrobe@unaffiliated/aroben)
  72. # [07:50] <G0k> i guess this is the wrong place to ask this, but i don't understand what this is supposed to accomplish
  73. # [07:55] <G0k> so i put a document on server-a.com, then another resource on server-b.com, and i want the server-a document to access the server-b resource....so now i have to make server-b.com provide an HTTP header that says it's ok for that to happen?
  74. # [07:56] <Hixie> yeah
  75. # [07:56] <G0k> how is this better than just having server-b check the Referer field?
  76. # [08:18] <Hixie> most servers don't check the referer field
  77. # [08:19] <Hixie> so if we relied on that, most servers would be vulnerable today
  78. # [08:19] <G0k> but...zero servers check the Content-Access-Control fiel
  79. # [08:19] <G0k> *d
  80. # [08:19] * Joins: zcorpan_ (n=zcorpan@pat.se.opera.com)
  81. # [08:19] <Hixie> no the server has to _send_ the field
  82. # [08:19] <G0k> i guess i'm not clear who's being protected here
  83. # [08:20] <Hixie> the user is being protected from server-a pretending to be the user when talking to server-b
  84. # [08:23] <G0k> ah ok so this could prevent the resource from server-b, which is accessed by the user directly, from being sent back to server-a?
  85. # [08:24] <Hixie> right
  86. # [08:24] <Hixie> (on an unrelated note, http://www.w3.org/mid/20070808115703.GC5388@stripey.com summarises where i'm coming from regarding the wysiwyg stuff)
  87. # [08:25] <G0k> though it requires server-b to implement it, and the UA to implement it, and also requires breaking all other current cross-domain communication techniques?
  88. # [08:26] <Hixie> no
  89. # [08:26] <Hixie> it requires server-b to implement it only if server-b wants to allow access
  90. # [08:27] <Hixie> it requires the UA to implement it only if the UA is to support cross-domain stuff
  91. # [08:27] <Hixie> and it doesn't affect any existing cross-domain features
  92. # [08:30] <G0k> ok but tricks like dom-inserting a <script> element could still get around this
  93. # [08:31] <Hixie> dom-inserting a script only works if you're inserting a script
  94. # [08:31] <Hixie> so yes, scripts aren't protected
  95. # [08:38] <G0k> ok but...let's say server-b doesn't want server-a's web pages from loading its images
  96. # [08:38] <G0k> it could say Content-Access-Control: deny server-a.com
  97. # [08:39] <G0k> but that would only be honored by new UAs
  98. # [08:40] <G0k> i mean i guess that's somewhat outside the scope of access control's purpose
  99. # [08:41] <G0k> but it's something of an broken-at-conception default behavior
  100. # [08:46] * Joins: wakaba (n=w@114.165.210.220.dy.bbexcite.jp)
  101. # [08:46] * Joins: met_ (n=Hassman@b14-4.vscht.cz)
  102. # [08:50] <Hixie> G0k: images are also not affected by this
  103. # [08:51] <Hixie> G0k: this doesn't affect anything that is allowed now
  104. # [08:51] <Hixie> G0k: it only affects new cross-domain stuff
  105. # [08:51] <G0k> so it only applies in situations where the same origin policy is currently being used?
  106. # [08:51] <Hixie> it only applies in situations where the specs say it applies :-)
  107. # [08:52] <G0k> yeah right so "To facilitate clear and controlled read access to resources, this specification defines a read access control mechanism that enables a web resource to permit access to its content from external domains when such access would otherwise be prohibited by a same origin policy."
  108. # [08:52] <G0k> i guess my question is....is there a formal definition of when the same origin policy is used?
  109. # [08:53] <G0k> i mean clearly it seems to always apply to XMLHttpRequest stuff
  110. # [08:54] <G0k> and presumably the event-source gunk
  111. # [08:55] <G0k> or is it just always left up the implementation?
  112. # [08:56] * Joins: tantek (n=tantek@cust-216-59-193-114.t-speed.net)
  113. # [08:57] <Hixie> access-control only applies in situations where the specs explicitly say it applies
  114. # [08:57] <Hixie> so e.g. xmlhttprequest
  115. # [08:57] <Hixie> or rather xmlhttprequest2
  116. # [08:58] <G0k> ooo the sequel
  117. # [08:58] <Hixie> because that spec says it applies
  118. # [08:58] <Hixie> same with xbl2
  119. # [08:58] <Hixie> xbl2 says it applies
  120. # [09:00] <G0k> alright
  121. # [09:01] <G0k> well i guess that was a key point i was missing
  122. # [09:01] <G0k> i thought it was more of a replacement for previous access control methods
  123. # [09:04] * Quits: wakaba_ (n=w@114.165.210.220.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
  124. # [09:04] <Hixie> nope
  125. # [09:10] <Hixie> oops, replied to a thread that already got replies
  126. # [09:10] <Hixie> i need to remember to read the whole thread before replying
  127. # [09:18] <zcorpan_> Hixie: what is the legacy parsing behaviour for <address> you're referring to? firefox's behavior?
  128. # [09:27] <Hixie> "address" is mentioned in all kinds of places in the parser
  129. # [09:28] <zcorpan_> i only find two "address" in the parsing section
  130. # [09:30] * Joins: Whiskey_M (n=Richard@host-84-9-127-20.bulldogdsl.com)
  131. # [09:30] <Whiskey_M> 'lo
  132. # [09:31] <zcorpan_> morning Whiskey_M
  133. # [09:31] <Whiskey_M> Good morning, how goes today?
  134. # [09:32] * Quits: G0k (n=hmason@c-67-190-9-212.hsd1.co.comcast.net)
  135. # [09:32] <zcorpan_> tired... woke up 5am this morning
  136. # [09:32] <Whiskey_M> ouch, lots of coffee today then
  137. # [09:33] <zcorpan_> nah
  138. # [09:34] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  139. # [10:25] <met_> http://therealcrisp.xs4all.nl/blog/2007/08/13/getelementsbyclassname-re-re-re-visited/ see also crisp comment
  140. # [10:30] * mpt_ is now known as mpt
  141. # [10:34] * Quits: tantek (n=tantek@cust-216-59-193-114.t-speed.net)
  142. # [10:37] * Joins: BenWard (i=BenWard@nat/yahoo/x-77213854c1b4e294)
  143. # [10:43] * Joins: tndH (i=Rob@adsl-87-102-89-143.karoo.KCOM.COM)
  144. # [10:43] * Joins: ROBOd (n=robod@86.34.246.154)
  145. # [10:50] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  146. # [11:25] * Joins: ROBOd (n=robod@86.34.246.154)
  147. # [11:38] * Joins: hasather (n=david_ha@pat-tdc.opera.com)
  148. # [11:39] <virtuelv> exactly what is Molly talking about here? http://www.molly.com/2007/08/11/dear-w3c-dear-wasp/
  149. # [11:40] <virtuelv> I simply don't get what she's trying to point out
  150. # [11:45] * Dashiva considers a humorous comment, but decides it's just going to end up in another angry mail some time in the future
  151. # [11:48] * Joins: hendry (n=hendry@host81-129-47-12.range81-129.btcentralplus.com)
  152. # [12:09] <gsnedders> virtuelv: the impression I got is W3C's long-term vision for the web (XML)
  153. # [12:09] <gsnedders> and that HTML5 is undermining that
  154. # [12:10] <virtuelv> I _still_ don't get it
  155. # [12:11] <gsnedders> Why is HTML5 being developed at all? It's undermining everything (XML)! Why isn't WaSP and the like doing anything about it?
  156. # [12:12] <virtuelv> xml pretty much undermined itself as a language for end-user display on the web when it defined draconian error handling anyway
  157. # [12:13] <gsnedders> It's obvious that from Molly's POV it _must_ be the future of the web
  158. # [12:13] <Whiskey_M> just a quick one - it's not XML you are talking about, rather XHTML (although the error handling does come from XML parsers)
  159. # [12:14] <gsnedders> Whiskey_M: The W3C's vision is to use XML for everything though, not just XHTML
  160. # [12:14] <virtuelv> Whiskey_M: note that XHTML as text/html is not XHTML
  161. # [12:16] <Whiskey_M> gsnedders, most things yes (and for a lot it works well), virtuelv - if you're on about serving, although transitional format does allow text/html - you're right
  162. # [12:16] <Whiskey_M> heading for tea
  163. # [12:16] <gsnedders> Whiskey_M: all XHTML 1.0 DOCTYPEs are allowed under text/html
  164. # [12:17] <virtuelv> Whiskey_M: note that no: xhtml as text/html is never parsed using an xml parser
  165. # [12:17] * virtuelv points to http://www.hixie.ch/advocacy/xhtml'
  166. # [12:17] <virtuelv> err, http://www.hixie.ch/advocacy/xhtml
  167. # [12:18] <gsnedders> virtuelv: that's not what he's saying.
  168. # [12:18] <gsnedders> virtuelv: he's saying you're allowed to serve it as text/html.
  169. # [12:18] * Quits: kfish (n=conrad@61.194.21.25) ("Pike!")
  170. # [12:18] <gsnedders> virtuelv: what it is parsed as is a whole different matter
  171. # [12:18] <virtuelv> yes, I am not denying that. I'm just saying that you SHOULD NOT
  172. # [12:19] <virtuelv> (I do it on my site, but will stop doing so once I get time to rework the templates)
  173. # [12:19] <gsnedders> virtuelv: then why the "no"?
  174. # [12:20] <virtuelv> gsnedders: because by the time you're doing it, it may have an "xhtml" doctype, but the browser doesn't treat it as such
  175. # [12:20] * Joins: Ducki (n=Ducki@d83-176-151-209.cust.tele2.de)
  176. # [12:20] <gsnedders> virtuelv: but that still doesn't contradict the statement that you can serve it as text/html
  177. # [12:20] <zcorpan_> virtuelv: with what expected benefit except perhaps for a few saved bytes and a pat on the back? re rework the templates
  178. # [12:22] <virtuelv> zcorpan_: just changing the doctype has no real-world benefit as such
  179. # [12:23] <zcorpan_> virtuelv: indeed
  180. # [12:23] <virtuelv> but that isn't the point of redoing the templates. It's rather to get rid of cruft, and incorporating a few html5 features
  181. # [12:23] <zcorpan_> ok
  182. # [12:24] <virtuelv> but it's more of a project utopia, given that I never have the time to do it anyway :-P
  183. # [12:24] <gsnedders> but in the real-world you don't need to redo it to add HTML 5 features
  184. # [12:24] <zcorpan_> removing cruft might need redoing :)
  185. # [12:25] * zcorpan_ -> lunch
  186. # [12:25] <gsnedders> my redesign has gone through so many phases I have no idea what sort of markup it has
  187. # [12:25] <gsnedders> probably HTML 4.01 Strict
  188. # [12:26] <gsnedders> an earlier concept of the redesign was XHTML 1.1, but that was all scrapped anyway
  189. # [12:27] * Joins: Codler (n=Codler@84-218-6-160.eurobelladsl.telenor.se)
  190. # [12:36] <Whiskey_M> gs / virt: On reading the piece and without wanting to put words in Molly's mouth - it would seem to say that although a lot of people, companies and organisations are putting together a lot of good work there does seem to be some pulling in different directions, some of the stuff (AIR), doesn't appear to sit comfortably in standards (also between AIR and Silverlight are we going to see a new "browser wars"), and the normal bodies tha
  191. # [12:41] <mpt> Whiskey_M, "...and the normal bodies th"
  192. # [12:41] <Whiskey_M> mpt?
  193. # [12:41] <mpt> you got cut off
  194. # [12:41] <Whiskey_M> ahhh, sorry
  195. # [12:42] <Whiskey_M> and the normal bodies that you'd expect to try to bring people / companies / organisations together aren't really saying / doing anything about it
  196. # [12:42] <Whiskey_M> btw. I'm neither advocating or disagreeing with the opinion - just how I understood it
  197. # [12:43] <hsivonen> Silverlight is a rather big elephant in the room on Molly's blog. :-(
  198. # [12:51] * Quits: gsnedders (n=gsnedder@host86-138-194-36.range86-138.btcentralplus.com) (Read error: 110 (Connection timed out))
  199. # [13:00] * Joins: Charl (n=charlvn@c1-205-8.wblv.isadsl.co.za)
  200. # [13:02] * Joins: gsnedders (n=gsnedder@host86-139-217-195.range86-139.btcentralplus.com)
  201. # [13:15] * Joins: MikeSmith (n=MikeSmit@60.254.221.207)
  202. # [13:17] * Quits: Ducki (n=Ducki@d83-176-151-209.cust.tele2.de) (Read error: 104 (Connection reset by peer))
  203. # [13:25] * Quits: karlUshi (n=karl@124-144-94-188.rev.home.ne.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
  204. # [13:42] <krijnh> "GET /irc-logs/html-wg/ HTTP/1.1" 302 5 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
  205. # [13:42] <krijnh> :O
  206. # [13:44] * zcorpan_ fires up Mosaic
  207. # [13:44] * Quits: MikeSmith (n=MikeSmit@60.254.221.207) ("Less talk, more pimp walk.")
  208. # [13:46] * Joins: bzed (n=bzed@dslb-084-059-111-101.pools.arcor-ip.net)
  209. # [13:55] * Quits: hendry (n=hendry@host81-129-47-12.range81-129.btcentralplus.com) (Read error: 110 (Connection timed out))
  210. # [14:08] <met_> heh, we has even one IE4 hit today http://en.navrcholu.cz/Statistics/58501/browsers-versions/?s=13.8.2007&e=13.8.2007&p=h&pi=1
  211. # [14:09] * met_ found also one hit from Mozilla Suite 1.1
  212. # [14:10] <krijnh> 38% Fx ? :|
  213. # [14:16] * Philip` probably leaves an unusual log trail of IE6+Win98 when looking around in IE in Wine
  214. # [14:17] * Joins: tantek (n=tantek@m015f36d0.tmodns.net)
  215. # [14:23] <krijnh> "...demeaning comments regarding accessibility issues and "smell-o-vision". [http://krijnhoetmer.nl/irc-logs/whatwg/20070701#l-217]"
  216. # [14:23] <krijnh> And thank you guys for putting those comments on my site! ;)
  217. # [14:25] <krijnh> I should have a disclaimer somewhere..
  218. # [14:32] <met_> krijnh, of course it site for Mozilla/FF users 8-)
  219. # [14:32] <krijnh> met_: Ah :)
  220. # [14:32] <met_> but we have MUCH better if you want http://en.navrcholu.cz/Statistics/81644/browsers-families/?s=13.8.2007&e=13.8.2007&p=h&pi=1
  221. # [14:33] <krijnh> You call that much better? Opera has only 1 visit :(
  222. # [14:33] <zcorpan_> yeah :(
  223. # [14:34] <met_> 99.8% of Gecko, I like it 8-)
  224. # [14:35] <met_> wait Opera has 1/3 or IE usage ther, it's cool, isn't?
  225. # [14:35] <met_> and if you wisit the page once you can increase is twice 8-)
  226. # [14:37] <zcorpan_> done already
  227. # [14:38] <met_> btw http://xhtml.com/en/future/fixing-the-web-1/
  228. # [14:43] <mpt> I don't understand what's so demeaning about smell-o-vision, honestly
  229. # [14:44] <mpt> It was the best example I could think of, because smell is a medium that is very poorly supported
  230. # [14:44] <mpt> actually, that's not quite right
  231. # [14:45] <mpt> Smell is a sense that is supported in very few media.
  232. # [14:45] <mpt> So whenever you watch someone's holiday video, for example, you're missing out on all the wonderful smells
  233. # [14:46] <mpt> but the narrators of such videos *usually* don't mention them, unless they're particularly noteworthy.
  234. # [14:46] <mpt> Similarly, when you listen to radio documentaries, you're missing out on the appearance of all the things being discussed
  235. # [14:47] <mpt> but the narrator usually doesn't mention the appearance of things, unless it's relevant to the topic at hand.
  236. # [14:48] <mpt> (Podcast hosts who say "I'll put the picture of X in the show notes" are the clumsy exception, rather than the rule.)
  237. # [14:50] <mpt> So, I don't think that HTML's accessibility features for people with visual impairments, for example, should take the attitude of "And here's what you would be able to see if you weren't so blind".
  238. # [14:50] <mpt> (Which is what longdesc= does.)
  239. # [14:51] <takkaria> s/does/tries to do/ ;)
  240. # [14:51] <mpt> yeah
  241. # [14:51] <krijnh> Again, I need a disclaimer ;p
  242. # [14:52] <mpt> Rather, I think that they should concentrate on producing the best self-contained text-only version possible
  243. # [14:52] <Whiskey_M> mpt - thinking of an example where longdesc would be appropriate ... describing a chart / graph, just thinking of one of hand
  244. # [14:54] <mpt> Whiskey_M, perhaps, though I think a long alt= could get 90% of the effect.
  245. # [14:54] <Whiskey_M> off hand, sorry
  246. # [14:55] <takkaria> talking of longdesc, I should go over some more URLs and see how many use longdesc correctly
  247. # [14:55] <mpt> Sometimes the best text equivalent to a graph would be a <table>, though
  248. # [14:55] <hsivonen> mpt: out of curiosity, do you work on usability for the general population these days or does your dayjob also involve accessibility issues?
  249. # [14:55] <mpt> which is why the <object> situation is so sad
  250. # [14:56] <Whiskey_M> don't know - would perhaps be overkill for alt. Say we can a graph of user agent usage over the last 12 months - the alt would be "graph of user agent usage over the last 12 months" - the longdesc could give a rough breakdown of the numbers etc. apparent through the chart
  251. # [14:56] <gsnedders> how much content actually relies on IE's treatment of |object|?
  252. # [14:56] <zcorpan_> Whiskey_M: that wouldn't be very good alt text
  253. # [14:56] <mpt> hsivonen, the general population, but a few days ago we had someone on our mailing list who is blind and has trouble with a few pages
  254. # [14:57] <Whiskey_M> zcor: yeah I know
  255. # [14:57] <Whiskey_M> but at the same time you wouldn't want the full breakdown of the data thrown at you in an alt
  256. # [14:57] <zcorpan_> why not?
  257. # [14:58] <mpt> Whiskey_M, perhaps minimums and maximums, or starting and ending values, for each series in the graph
  258. # [14:59] <mpt> for those at least, you have a fair shot at being able to auto-generate them
  259. # [14:59] <mpt> (we have bar charts with auto-generated alt= on our site)
  260. # [14:59] <Whiskey_M> because on something like that it would take too long, especially if it were only suplimental information backing up the rest of the information on the page. Better alt contains an overview and longdesc (if there were one), had the additional information for anyone that wanted to delve in
  261. # [14:59] <hsivonen> mpt: any user feedback on the autogenerated alts?
  262. # [15:00] <mpt> hsivonen, no
  263. # [15:01] <zcorpan_> Whiskey_M: how would you present the information in a text-only context? have a brief overview and a link to a separate page for more detail?
  264. # [15:01] <mpt> I suppose if a graph accompanies a news story where the salient changes are already described in text, the alt= should go into deeper detail, because anyone listening to the graph has already listened to the article
  265. # [15:02] <Whiskey_M> thats what throws me zcorpan - I'm aware longdesc should point to a text resource of more info, but must admit to never seeing it done (not even as an example on accessify forum)
  266. # [15:04] * Joins: Ducki (i=Ducki@nrdh-d9b980ce.pool.mediaWays.net)
  267. # [15:16] <Whiskey_M> Zcor: thinking about how I'd present that info - probably in a table, user agent / month as the two axis
  268. # [15:19] <Whiskey_M> my bad, look and you will find... http://www.accessifyforum.com/viewtopic.php?t=1807
  269. # [15:29] * Quits: tantek (n=tantek@m015f36d0.tmodns.net)
  270. # [15:29] <gsnedders> Hixie: how come the WHATWG WD is 11th Aug, and SVN is 10th?
  271. # [15:30] <Philip`> gsnedders: http://krijnhoetmer.nl/irc-logs/whatwg/20070812#l-324
  272. # [15:31] <gsnedders> ah
  273. # [15:36] <hsivonen> http://www.sitepoint.com/blogs/2007/08/13/nihilism-accessibility-and-the-preponderence-of-amazing-co-incidences/
  274. # [15:36] <hsivonen> "the microformats community and WHATWG are behaving like cabals in their self-interested refusal to acknowledge the accessibility issues with that they’re doing"
  275. # [15:37] <takkaria> sigh
  276. # [15:43] <Lachy> wow, the misconceptions spreading througout the web are getting out of hand
  277. # [15:46] * Joins: Darkluna (n=Codler@84-218-7-13.eurobelladsl.telenor.se)
  278. # [15:50] * Joins: sirPalook (n=chatzill@87.203.169.55)
  279. # [15:50] <takkaria> that comment seems to be a throwaway line before a somewhat existentialist rant about nothing in particular
  280. # [15:50] <Lachy> takkaria, my comment?
  281. # [15:51] <takkaria> no, the "the microformats community and WHATWG are behaving..." quote mentioned above
  282. # [15:51] <Lachy> oh, I thought mine because I am actually writing a rant right now :-)
  283. # [15:51] <sirPalook> Hi. I believe that end tag </li> should be completely ignored.
  284. # [15:52] <sirPalook> Here is why:
  285. # [15:52] <Lachy> sirPalook, yes, IIRC, that idea has been mentioned before
  286. # [15:53] <sirPalook> In <ul><ul><li></li></li></ul></ul>, there is an extra </li> which has the effect of closing the <ul>
  287. # [15:53] <sirPalook> This *does* happen in some pages on the internet (gcc archives)
  288. # [15:53] <sirPalook> And neither mozilla nor any other browser act like that.
  289. # [15:54] <zcorpan_> sirPalook: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011884.html
  290. # [15:54] <Lachy> why would the second </li> close the <ul>? Is that in the spec's algorithm?
  291. # [15:54] <sirPalook> html5lib closes it.
  292. # [15:55] <sirPalook> um, sorry, maybe there is another <li> in the outer list...
  293. # [15:55] <sirPalook> revised example <ul><li><ul><li></li></li></ul></li></ul>
  294. # [15:56] <zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cul%3E%3Cli%3E%3Cul%3E%3Cli%3E%3C/li%3E%3C/li%3E%3C/ul%3E%3C/li%3E%3C/ul%3E
  295. # [15:57] <zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cul%3E1%3Cli%3E2%3Cul%3E3%3Cli%3E4%3C/li%3E5%3C/li%3E6%3C/ul%3E7%3C/li%3E8%3C/ul%3E might be more useful
  296. # [15:57] <sirPalook> ops! maybe i have an old version.
  297. # [15:58] <sirPalook> sorry for the noise.
  298. # [15:58] <zcorpan_> no worries :)
  299. # [15:59] * Joins: Ducki_ (n=Ducki@213-102-93-251.cust.tele2.de)
  300. # [16:00] * Joins: hendry (n=hendry@91.84.53.136)
  301. # [16:08] * Quits: Codler (n=Codler@84-218-6-160.eurobelladsl.telenor.se) (Connection timed out)
  302. # [16:12] * Darkluna is now known as Codler
  303. # [16:17] * Quits: Ducki (i=Ducki@nrdh-d9b980ce.pool.mediaWays.net) (Read error: 113 (No route to host))
  304. # [16:35] * Joins: billmason (n=billmaso@ip156.unival.com)
  305. # [16:38] * Quits: sirPalook (n=chatzill@87.203.169.55) (Read error: 110 (Connection timed out))
  306. # [16:38] * Quits: Codler (n=Codler@84-218-7-13.eurobelladsl.telenor.se) (Connection timed out)
  307. # [16:55] * Joins: grimboy (n=grimboy@85.211.236.85)
  308. # [17:23] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  309. # [17:23] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.2 (IRC client for Emacs)")
  310. # [17:29] <met_> see for the first time, that google suggest you other results http://www.google.com/search?q=html%205 - after three "html 5" results google suggest me "html 4" results
  311. # [17:31] <zcorpan_> met_: that has been so for some time i think
  312. # [17:40] * Joins: dev0 (i=Tobias@unaffiliated/icefox0)
  313. # [17:42] * Quits: Ducki_ (n=Ducki@213-102-93-251.cust.tele2.de) (Read error: 110 (Connection timed out))
  314. # [17:46] * Joins: weinig (i=weinig@nat/apple/x-ebb800f6f4c10b50)
  315. # [17:48] * Quits: Charl (n=charlvn@c1-205-8.wblv.isadsl.co.za) ("Leaving")
  316. # [18:01] * Joins: maikmerten (n=maikmert@L8b1a.l.pppool.de)
  317. # [18:07] * Joins: Codler (n=Codler@84-218-7-66.eurobelladsl.telenor.se)
  318. # [18:18] * Joins: Ducki (n=Ducki@nrdh-d9b9802f.pool.mediaWays.net)
  319. # [18:25] * Parts: Lachy (n=Lachlan@124-168-4-56.dyn.iinet.net.au) ("Leaving")
  320. # [18:26] * Joins: Lachy (n=Lachy@124-168-4-56.dyn.iinet.net.au)
  321. # [18:28] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  322. # [18:29] <Philip`> Hmm, does IE not support iframe.onload?
  323. # [18:39] * Joins: mjs (n=mjs@17.255.106.78)
  324. # [18:40] * mjs is now known as othermaciej
  325. # [18:42] <Philip`> http://canvex.lazyilluminati.com/misc/dom-viewer/ -- half live + half dead = zombie?
  326. # [18:42] <Philip`> http://canvex.lazyilluminati.com/misc/dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Co%3Ap%3E%3Ca%20b%3D - IE, FF and Opera all do different things on each side
  327. # [18:43] * Quits: met_ (n=Hassman@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  328. # [18:44] <Lachy> I've done some more thinking about the design principles and revised my suggestions a bit (see yesterday's discussion http://krijnhoetmer.nl/irc-logs/whatwg/20070812#l-66 )
  329. # [18:44] <Lachy> I think we need to reword Don't Reinvent the Wheel and Pave the Cowpaths
  330. # [18:44] <Lachy> these are my new suggestions: ...
  331. # [18:45] <Lachy> Don't Reinvent the Wheel: Evaluate the success and failure of existing solutions. For those that have proven reasonably successful in terms of benefits, usage and implementation, consider adopting, retaining and/or improving upon them in preference to dismissing and inventing new features.
  332. # [18:45] <Lachy> Pave the Cowpaths: Investigate existing practices and design or adopt features that meet the desires of authors. Where possible, solutions should leverage the existing techniques and skill sets of authors which will help promote the adoption of new features.
  333. # [18:47] <Lachy> I'm going to mail them to the list shortly, any suggestions before I do?
  334. # [18:47] <othermaciej> Lachy: please do mail the list
  335. # [18:52] <Whiskey_M> both admirable, but I wouldn't rule out fresh invention where appropriate. Take for example the DVD, if cow paths were followed we'd just have video recorders with faster rewinds / skips and greater media protection. I know there is a time and place for innovation thus I guess the most important word is *appropriate* - just my 2p worth ;-)
  336. # [18:53] <Lachy> Whiskey_M: that's a perfect example of misunderstanding and inappropriately applying the principle
  337. # [18:54] <Whiskey_M> fair enough, although I might not be the only one to get the wrong end of the stick then
  338. # [18:54] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  339. # [18:54] <Lachy> DVDs solve a significant problem that video tapes had with their quality
  340. # [18:54] <othermaciej> Whiskey_M: the original intent of the principles was:
  341. # [18:56] <othermaciej> Don't Reinvent the Wheel -- if there's a deployed solution in existing implementations (i.e. web browsers) to some problem, then even if it has some quirks and minor problems it is likely to be a better choice than something brand new, and effort is probably better spent on improving it than making up something new
  342. # [18:56] <Lachy> but if you want to apply pave the cowpaths to DVD and VHS, then you would look at how users are already familiar with inserting media into a player and pressing play, seeking, etc. e.g. tapes, CDs, records, etc. So DVDs to leverage that existing skill set
  343. # [18:57] * Quits: BenWard (i=BenWard@nat/yahoo/x-77213854c1b4e294) ("Fades out again…")
  344. # [18:57] <othermaciej> Pave the Cowpaths -- if authors are doing something that is harmless but either forbidden or not explicitly encouraged, it might be a good idea to allow or even encourage it, because if conformance imposes pointless requirements then authors won't do it
  345. # [18:58] * Joins: epeus (i=KevinMar@nat/google/x-e5d02fcec3e48865)
  346. # [18:58] <othermaciej> neither of these principles would be very applicable to inventing a brand new format
  347. # [18:58] <othermaciej> as opposed to making a new version of an existing one
  348. # [18:58] <othermaciej> DVD is not VHS5
  349. # [18:58] <Whiskey_M> thanks macie :-) Lachy ok, bad analogy
  350. # [18:59] <othermaciej> in both cases you need to do some investigation to see what problems are being addressed, whether the de facto solution is a good one, etc
  351. # [18:59] * Joins: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  352. # [19:00] <othermaciej> this is why all the principles are written in a hedged way ("might", "consider", etc) and not as absolute commandments
  353. # [19:00] <othermaciej> it is a balancing act
  354. # [19:01] <Lachy> yes, that's why I've tried to emphasize the necessity of research in the proposed wordings
  355. # [19:03] <Philip`> What are the alternative viewpoints that "don't reinvent the wheel" is opposed to? Is the problem when people just ignore existing implementations entirely, or is it when they actively want to avoid any relation with existing implementations (i.e. implementations of a feature are seen as a negative point)?
  356. # [19:03] <Philip`> (or both?)
  357. # [19:04] <Philip`> (or something else? but presumably there's at least some kind of alternative viewpoint, because otherwise it's just a pointless obvious statement rather than a design principle that's helpful when making decisions)
  358. # [19:06] <othermaciej> Philip`: there's been some active opposition voiced to "Don't Reinvent the Wheel"; the idea is that we can invent better solutions if we start with a blank slate, than if we have to accept the legacy issues of an existing solution
  359. # [19:06] <Lachy> Philip`: pave the cowpaths tends to get conflated with reinventing the wheel and the objection is that it's seen as a way to block the introduction of new features. I think the best example of this would be the in the discussion of the role attribute
  360. # [19:07] <othermaciej> for example, some might propose that instead of <canvas> we should have a whole different approach to immediate-mode graphics that is perhaps somehow part of SVG
  361. # [19:07] <othermaciej> or that instead of contentEditable we should invent a whole new editing API that seems more elegant
  362. # [19:08] * Quits: KevinMarks (n=Snak@c-76-102-254-252.hsd1.ca.comcast.net) (Nick collision from services.)
  363. # [19:08] * epeus is now known as KevinMarks
  364. # [19:08] <othermaciej> obviously it is a matter of balance (no one has proposed adopting IE's support for namespaces in HTML for instance), but some thing that existing de facto implementations should be given no weight at all
  365. # [19:09] <Lachy> IIRC, some people have even compared it with introducing CSS for layout when tables were already in use for that purpose, and then using that as a strawman to object to it
  366. # [19:09] <othermaciej> a similar line of argument has been used to argue against "Support Existing Content" - that we can make something better and "fix the web" if we break compatibility
  367. # [19:09] <hsivonen> othermaciej: actually, discussion Re: namespaces has come pretty close to adopting what IE does
  368. # [19:10] <Lachy> crap! I don't want to adopt what IE does for namespaces :-(
  369. # [19:11] <hsivonen> I'm on a PPC Mac, so I'm not personally in a good position research IE's behavior. I'm hoping that MS or Opera would share their experiences on this.
  370. # [19:11] <Philip`> I thought IE looked almost sensible, but that's just because I was using the Live DOM Viewer which gives incorrect answers
  371. # [19:12] <Philip`> (like http://canvex.lazyilluminati.com/misc/dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cbody%3E%0D%0A%3Co%3Ap%3E%0D%0A%3Chtml%20xmlns%3Ao%3E%0D%0A%3Co%3Ap%3E has "p > p" on the left, "O:P + p" on the right)
  372. # [19:12] * Joins: aroben (n=adamrobe@17.203.15.181)
  373. # [19:13] <Lachy> in IE, <foo:bar>...</foo:bar> is parsed as pseudo-XML, rather than as ordinary unknown tags. The major problem with it is that it also creates it's typical broken DOM with badly nested elements
  374. # [19:14] <Lachy> so some special variation of the adoption agency algorithm would need to be developed for it
  375. # [19:14] <othermaciej> is there a lot of legacy content depending on details of IE's parsing for namespaces in HTML?
  376. # [19:15] <Lachy> sadly, there's a lot of XForms in tag-soup on the web
  377. # [19:15] <Lachy> and probably MathML too
  378. # [19:15] <Lachy> thanks in part to applications like FormsPlayer and MathPlayer (or whatever they're called)
  379. # [19:16] <Philip`> It's (generally) only parsed as pseudo-XML if you have a <html xmlns:foo> before it, and not if you use document.write, and people do use document.write with IE namespaces, which probably makes it painful to reproduce
  380. # [19:16] <hsivonen> Lachy: aren't you taking the purist attitude instead of paving the cowpaths there? ;-)
  381. # [19:17] <Philip`> There's loads of <o:p> and quite a bit of VML, but I don't know if people care how that's parsed or how it interacts with the DOM
  382. # [19:17] <othermaciej> if IE's implementation would be hard to emulate enough to be interoperable then I guess it is better to have syntax which won't collide with it instead
  383. # [19:18] <Lachy> hsivonen, possibly :-)
  384. # [19:18] <Philip`> ("loads" = more than 1% of pages)
  385. # [19:19] <Lachy> well, actually, I don't object to adding support for MathML and SVG in HTML, but I just the existing solution of using pseudo-XML syntax in HTML is more harmful, and thus it is a case where a better solution should be developed
  386. # [19:21] <hsivonen> Lachy: just adding SVG and MathML isn't the kind of distributed extensibility Sam called for
  387. # [19:21] <Lachy> I don't understand Sam's use cases for adding it.
  388. # [19:22] <Lachy> although I haven't read that whole thread yet.
  389. # [19:22] * Quits: Whiskey_M (n=Richard@host-84-9-127-20.bulldogdsl.com)
  390. # [19:22] <hsivonen> Lachy: the cases cited thus far have been about non-browser server-side templating languages leveraging HTML5 toolchains
  391. # [19:22] <Lachy> But I think the facebook example he gave is actually a case where the authoring environment should be XML, and then serialised as HTML after processing
  392. # [19:23] <hsivonen> Lachy: well, yeah, except that XML is too hard
  393. # [19:24] <Lachy> do you really think it's too hard for the developers that FBML is targetted at?
  394. # [19:25] <othermaciej> There's really multiple reasons people have for wanting namespaces in HTML, and they don't necessarily all point to the same solution
  395. # [19:25] <hsivonen> othermaciej: agreed
  396. # [19:25] <othermaciej> 1) support for specific well-known XML vocabularies (perhaps best handled via special-casing of the root elements, but needs a good fallback story)
  397. # [19:26] <hsivonen> Lachy: did you notice Sam's PHP spaghetti example? it has all the same problems regarding well-formedness as PHP spaghetti spewing XHTML
  398. # [19:26] <Philip`> https://secure.mysociety.org/cvstrac/fileview?f=mysociety/pb/phplib/pbfacebook.php&v=1.1
  399. # [19:26] <othermaciej> 2) support for well-known custom tags without regard to XML compatibility but with the ability for any third party to define an extension that is not expected to be understood natively by browsers
  400. # [19:27] <othermaciej> 3) same as 2 but with the additional requirement of being able to correspond to a "namespaces in XML" infoset
  401. # [19:27] <othermaciej> (and to generate an XML namespace DOM)
  402. # [19:27] <hsivonen> othermaciej: 4) same as 3) with non-XHTML nodes
  403. # [19:28] <othermaciej> hsivonen: non-XHTML nodes?
  404. # [19:28] <hsivonen> (#3 is satisfied with all elements being in the XHTML namespace)
  405. # [19:28] <othermaciej> ah, I see, you could make custom elements in the XHTML namespace, yes
  406. # [19:29] <othermaciej> I guess my point is that the solution for #2 that has the best backward compatibility and best behavior in pre-HTML5 browsers is probably something that doesn't use XML namespaces at all
  407. # [19:31] <Lachy> hsivonen: I hadn't noticed the PHP example, but that's a problem with PHP and a good illustration of the danger of developing XML under tag soup conditions
  408. # [19:31] <Philip`> Does it matter how #2 is handled in pre-HTML5 browsers, since the extensions are (if they're like FBML) meant to be processed by the HTML5 tools on the server and are no longer present in what's served to the browser?
  409. # [19:32] <hsivonen> Philip`: Sam said he was targeting both browsers and non-browsers
  410. # [19:32] * Joins: kingryan (n=kingryan@corp.technorati.com)
  411. # [19:33] <othermaciej> it does matter if you want to serve it on the public World Wide Web
  412. # [19:34] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  413. # [19:34] <hsivonen> I'm not so convinced that distributed extensibility on the Web is a good idea. as opposed to extensibility by centralized clearing houses like the microformats community
  414. # [19:35] <Philip`> hsivonen: othermaciej's #2 was for things not understood by browsers, so perhaps there's room for separate browser (#1) vs non-browser (#2/#3) solutions
  415. # [19:36] <othermaciej> Philip`: I meant not natively understood by browsers with special handling; not necessarily not served to browsers
  416. # [19:36] * othermaciej hopes that distinction is clear
  417. # [19:37] <othermaciej> I think IE's weird handling of unknown tags may break any hope of a backwards-compatible extension mechanism
  418. # [19:37] <hsivonen> whoa, http://hsivonen.iki.fi/producing-xml/ is almost 2 years old. (speaking of PHP and XML)
  419. # [19:38] <Lachy> I don't object to the principle of extensibility on the web, but I really think it needs to be done in a way that doesn't mess too much with the parsing. i.e. I don't think letting authors make up their own elements is a good idea
  420. # [19:39] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  421. # [19:39] <othermaciej> there does not seem to be a huge need for custom elements that are unknown to browsers, in publicly served content
  422. # [19:39] <Lachy> I think extension mechanisms using attributes can be successful, like microformats have used class and rel.
  423. # [19:40] <othermaciej> you would probably get better results by styling an existing semantic-free element like <span> or <div> with a class
  424. # [19:40] <Lachy> also something like role="", if it were introduced
  425. # [19:41] <Philip`> You could perhaps have UAs treat <x:y> the same way as HTML5 currently does (i.e. an element named "x:y"), except say UAs may support specific namespace prefixes (svg, math, etc) and parse them under different rules into an XML-like DOM. Then HTML5 browsers wouldn't break old content (<o:p>, <v:rect>, etc), but they could support new content (<svg:svg>), and the new content would degrade no worse than any other tag soup in IE, and non-browser tools cou
  426. # [19:41] <Philip`> ...could support their own extensions
  427. # [19:41] <othermaciej> custom attributes seem more potentially useful
  428. # [19:41] <othermaciej> for cases where you want key/value data and would rather not parse it out by hand
  429. # [19:41] <gsnedders> Philip`: having an <svg> element has already been suggested without namespaces at an HTML document level, by simply changing the namespace that the elements are put within
  430. # [19:42] <othermaciej> what's the o namespace referred to in <o:p>?
  431. # [19:42] <Lachy> I supposed we should also consider which use cases are solved by things like XBL, which can give all the practical benfits of extending the language, but without all the mess
  432. # [19:42] <othermaciej> is that a real commonly used namespace or just a popular random example?
  433. # [19:42] <Philip`> othermaciej: <o:p> is from Microsoft Office
  434. # [19:42] * Quits: Codler (n=Codler@84-218-7-66.eurobelladsl.telenor.se) (Connection timed out)
  435. # [19:43] <othermaciej> Philip`: ewww
  436. # [19:43] <Philip`> (and it was in 1.7% of pages I looked at a while ago)
  437. # [19:43] <Lachy> Philip`: that seems a little low
  438. # [19:44] <othermaciej> Lachy: XBL+CSS lets you add new behavior and presentation, but it doesn't help you represent the custom semantics that you want to attach this styling and behavior to
  439. # [19:44] <othermaciej> Lachy: so it's kind of orthogonal
  440. # [19:45] <othermaciej> using XBL with <div class="foobar"> doesn't address any of the reasons people might want a <foobar> tag in their markup, whatever those might be
  441. # [19:46] <othermaciej> XBL also potentially creates a greater need for custom attributes
  442. # [19:46] <Lachy> hmm, I suppose, though it's not really clear what the use cases are for such extensibility on the client side
  443. # [19:47] <Lachy> if it's extensibility like microformats are doing, then their solution already works.
  444. # [19:48] <Lachy> maybe it's something like these JavaScript triggers http://www.alistapart.com/articles/scripttriggers/
  445. # [19:48] <Lachy> basically, custom attributes to extend existing elements
  446. # [19:49] <othermaciej> it seems like XBL is more likely to increase rather than reduce the desire to send custom elements and attributes
  447. # [19:50] <Lachy> really?
  448. # [19:50] <Lachy> why?
  449. # [19:50] <othermaciej> if you make some kind of complex custom control using XBL, you'll tend to think it should be its own tag
  450. # [19:50] <othermaciej> rather than binding it to <div class="something">
  451. # [19:59] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  452. # [20:18] <othermaciej> so was Molly actually just annoyed about that article anointing Zeldman as "King of Web Standards"?
  453. # [20:18] <othermaciej> is that the personal agenda she was referring to?
  454. # [20:19] * Quits: Ducki (n=Ducki@nrdh-d9b9802f.pool.mediaWays.net) (Read error: 113 (No route to host))
  455. # [20:28] * Joins: Whiskey_M (n=Richard@host-84-9-127-20.bulldogdsl.com)
  456. # [20:28] <Whiskey_M> 'lo
  457. # [20:29] <Lachy> what does 'lo mean?
  458. # [20:29] <Whiskey_M> as in hello
  459. # [20:30] <Lachy> ah
  460. # [20:33] <Philip`> It's the opposite of 'hi' and therefore means the same
  461. # [20:34] * Joins: grimeboy (n=grimboy@85-211-248-44.dsl.pipex.com)
  462. # [20:36] * Quits: grimboy (n=grimboy@85.211.236.85) (Read error: 110 (Connection timed out))
  463. # [20:52] * Quits: aroben (n=adamrobe@unaffiliated/aroben)
  464. # [20:54] * Joins: aroben (n=adamrobe@17.203.15.181)
  465. # [20:55] * Quits: Whiskey_M (n=Richard@host-84-9-127-20.bulldogdsl.com) ("bye")
  466. # [20:55] * Quits: aroben (n=adamrobe@unaffiliated/aroben) (Client Quit)
  467. # [20:56] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  468. # [21:09] <met_> http://www.molly.com/2007/08/13/dear-what-wg-and-html-5-wg/
  469. # [21:16] * Quits: KevinMarks (i=KevinMar@nat/google/x-e5d02fcec3e48865) (Read error: 110 (Connection timed out))
  470. # [21:17] <othermaciej> wow, molly sure likes all-caps boldface
  471. # [21:21] * Quits: zcorpan_ (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
  472. # [21:22] <hsivonen> hmm. having the spec on too servers seems to be perceived as a problem. but XBL is published by 2 orgs. as is RELAX NG and ODF
  473. # [21:23] <hsivonen> at least in the case of HTML 5 and XBL, the content is verbatim as opposed to ISO RELAX NG having gone through the ISO obfuscation process
  474. # [21:23] <hsivonen> s/too/two/
  475. # [21:24] * Joins: KevinMarks (i=KevinMar@conference/plone/docsprint/x-b5a668b0b901c607)
  476. # [21:41] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  477. # [21:45] * Joins: aroben (n=adamrobe@17.203.15.181)
  478. # [21:55] * Joins: mattly (n=matt@66-214-204-123.dhcp.snlo.ca.charter.com)
  479. # [21:55] * Joins: weinig_ (i=weinig@nat/apple/x-f50d3549d58849a4)
  480. # [21:57] * Quits: weinig (i=weinig@nat/apple/x-ebb800f6f4c10b50) (Read error: 104 (Connection reset by peer))
  481. # [21:57] * weinig_ is now known as weinig
  482. # [22:00] * Joins: molly (n=mollyhol@63-252-121-133.ip.mcleodusa.net)
  483. # [22:01] <molly> Hi all
  484. # [22:01] <molly> I've posted some clarifications as many WHAT WG members were concerned about conversation on my blog, perhaps this will help http://www.molly.com/2007/08/13/dear-what-wg-and-html-5-wg/
  485. # [22:02] * Joins: grimboy_uk (n=grimboy@85-211-250-15.dsl.pipex.com)
  486. # [22:03] <molly> Hixie
  487. # [22:03] <molly> hsivonen
  488. # [22:03] <molly> kevinmarks
  489. # [22:03] <molly> lachy
  490. # [22:03] <hasather_> molly: s/Sevonin/Sivonen/
  491. # [22:04] <molly> hello?
  492. # [22:04] <jgraham> molly: hello (although I am not on your list :))
  493. # [22:05] <molly> hi jgraham
  494. # [22:05] <molly> hasather, thanks, I always do that to Henri!
  495. # [22:05] <molly> sorry Henri
  496. # [22:05] <molly> fixed no
  497. # [22:05] <molly> now
  498. # [22:06] <jgraham> One reason there are two lists dealing with HTML5 stuff is that the W3C policy prevents members of W3C-Member organisations who are not nominated representatives from providing feedback
  499. # [22:06] <hasather_> molly: now it's Sevonen which is still wrong :)
  500. # [22:07] <molly> ha! ok, fixed again.
  501. # [22:07] <molly> jgraham, that's a problem then that W3C policy needs to repair
  502. # [22:07] <molly> having two lists at two trajectories is a fragmentation
  503. # [22:08] * Quits: maikmerten (n=maikmert@L8b1a.l.pppool.de) ("Leaving")
  504. # [22:08] <jgraham> I agree that the dual-list situation is not ideal. But I don't think it's more harmful than the alterntaives
  505. # [22:08] <gsnedders> then we have the issue of the time taken to change the process document
  506. # [22:08] <molly> I think it's very harmful.
  507. # [22:08] <jgraham> Why?
  508. # [22:09] <jgraham> Most discussion now happens on public-html
  509. # [22:09] <molly> which is authorotative? How is that expressed to the wider public?
  510. # [22:09] <molly> gsnedders: agree that the time issue with w3c is awful. But that's why my initial comments were explicitly not to the WHAT WG
  511. # [22:09] <molly> but to the W3C and to WaSP
  512. # [22:10] <jgraham> Neither. The spec is authoritative. public-html is authoritative in producing deliverables insofar as the W3C brand carries much more weight than the WHATWG brand
  513. # [22:10] <gsnedders> molly: but it's why we can't do anything about the issue with the W3C mailing list situation. It'd be nice if we were just allowed to use the existing mailing list.
  514. # [22:11] <gsnedders> (which to this day still has more subscribers)
  515. # [22:11] <molly> so how do we make that allowable? The W3C bears enormous responsibility in accommodating WHAT WG process as it relates to HTML 5.
  516. # [22:11] <jgraham> (or rather the HTMLWG, which conducts its business via public-html, is authoritative)
  517. # [22:11] <hsivonen> molly: hi
  518. # [22:11] <molly> Hi Henri!
  519. # [22:11] <molly> sorry to mis-spell your name so many times, I think I corrected it now :D
  520. # [22:11] <hsivonen> molly: no problem
  521. # [22:12] <gsnedders> molly: we'd have to get the W3C group re-chartered
  522. # [22:13] <molly> so what's the point of HTML 5 serialization under W3C then?
  523. # [22:13] <hsivonen> molly: I still stand by what I said earlier (not in the comments of your previous post but even earlier): HTML 5 fixes many things in HTML 4.01, but releasing merely the fixes is not a good idea as it would slow down launching new features
  524. # [22:13] * jgraham doesn't really understand that question
  525. # [22:13] * gsnedders doesn't either
  526. # [22:13] <hsivonen> which need to be launched to keep HTML competitive
  527. # [22:14] <molly> I understand the need and desire to keep HTML moving forward. I have no problem with that
  528. # [22:14] <molly> but I think there's an audience that people are missing
  529. # [22:14] <molly> and that's why I keep digging around this issue
  530. # [22:14] <jgraham> The point of the HTML 5 serialization compared to what? An XML serialisation?
  531. # [22:14] <gsnedders> I, in many ways, would've preferred we developed the spec separate from the W3C and just submit it when completed, thereby avoiding the entire over-bureaucracy of the W3C
  532. # [22:14] <jgraham> Compared to leaving HTML stagnant?
  533. # [22:14] <molly> and that is the fact that we don't even have stable specs implemented as is
  534. # [22:15] <hsivonen> molly: merely releasing bug fixes is not interesting enough to justify a new thing to people who don't know how important the fixes are
  535. # [22:15] <molly> no, jgraham, i didn't mean that
  536. # [22:15] <molly> I meant under w3c
  537. # [22:15] <molly> not that WHAT WG wouldn't continue its work
  538. # [22:15] <molly> but if the W3C is an impediment
  539. # [22:15] <hsivonen> molly: if anything, new exciting features are needed for marketing and the bug fixes are delivered on the side
  540. # [22:15] <molly> a detriment
  541. # [22:15] <jgraham> From who's point of view?
  542. # [22:15] <molly> well, this is all well and good but what do you say to the poor suckers of the world who still don't know what a DOCTYPE is much less why they should care?
  543. # [22:15] <jgraham> Rejoice!
  544. # [22:16] <molly> we forget how we see this versus how the rest of the world sees it
  545. # [22:16] <hsivonen> molly: I'd give them a link to my doctype page :-)
  546. # [22:16] <gsnedders> your markup will be parsed consistently!
  547. # [22:16] <jgraham> For HTML5 is designed to make your life easier
  548. # [22:16] <molly> MY life?
  549. # [22:16] <jgraham> (at least, if I can help it at all... ;))
  550. # [22:16] * hsivonen has been educating people about doctypes since 2000
  551. # [22:16] <molly> yes, Henri, and I often to send people to you
  552. # [22:16] <jgraham> The life of people who know little about doctypes + etc.
  553. # [22:16] * gsnedders once ended up doing HTML in computing at school.
  554. # [22:16] <molly> however, perhaps the magnitude of "them"
  555. # [22:16] <gsnedders> I ended up teaching the class, not the teacher
  556. # [22:16] <molly> um, these are people who work the Web today
  557. # [22:16] <molly> yes, exactly
  558. # [22:16] * Quits: grimeboy (n=grimboy@85-211-248-44.dsl.pipex.com) (Read error: 110 (Connection timed out))
  559. # [22:16] <molly> thank you
  560. # [22:17] <molly> now you see my pov
  561. # [22:17] <molly> I'm the educator
  562. # [22:17] <molly> that's the role I play
  563. # [22:17] <molly> I have to take this and make it make sense to people
  564. # [22:17] <molly> not only who are doing daily work
  565. # [22:17] <hsivonen> molly: the hardest part in that is this: http://annevankesteren.nl/2007/04/html-red-pill
  566. # [22:17] <molly> but who can't figure out how the fuck to implement anything as it is much less as we all see it through our various colored glasses
  567. # [22:17] <jgraham> Right, so one thing that has been happening is to simplify needness complexity
  568. # [22:18] <jgraham> like now we have <!DOCTYPE html> rather than the HTML4 cruft
  569. # [22:18] <molly> I know
  570. # [22:18] <jgraham> so it's easier to learn what a doctype is
  571. # [22:18] <molly> I'm not so sure that's true
  572. # [22:18] <jgraham> Why not?
  573. # [22:18] <gsnedders> jgraham: maybe not what it is
  574. # [22:18] <jgraham> It's a magic string...
  575. # [22:19] <molly> most of the people working on specs seem to not realize that the majority of people working in the front lines of web design and dev
  576. # [22:19] <gsnedders> a doctype is a far from simple concept
  577. # [22:19] <molly> are not trained, do not understand
  578. # [22:19] <molly> do not get exposed to the ideas
  579. # [22:19] <molly> and just do "what works"
  580. # [22:19] <gsnedders> jgraham: what's magic about it?
  581. # [22:19] <hsivonen> molly: how can we do anything if we assume no learning at all?
  582. # [22:19] <jgraham> That depends what you mean by "what"
  583. # [22:19] * Joins: weinig_ (i=weinig@nat/apple/x-1fa9bfb8288f1e41)
  584. # [22:19] <molly> in fact, one of the most common questions in XHTML classes? "if elements are supposed to be lower case, why is DOCTYPE upper case?"
  585. # [22:19] <jgraham> :)
  586. # [22:19] <molly> :: bangs head on desk ::
  587. # [22:20] <molly> back to Anne's "no sgml" point
  588. # [22:20] <othermaciej> hi molly, thanks for visiting
  589. # [22:20] <molly> hi! other maciej
  590. # [22:20] <molly> are you really another maciej?
  591. # [22:20] * Quits: weinig (i=weinig@nat/apple/x-f50d3549d58849a4) (Read error: 104 (Connection reset by peer))
  592. # [22:20] <molly> or the one I'm familiar with? :D
  593. # [22:20] <othermaciej> probably the one you are familiar with
  594. # [22:20] <hsivonen> molly: HTML5 solves that. no more explaining XHTML-as-text/html that doesn't have an explanation that makes sense to students
  595. # [22:20] <othermaciej> but there is a different maciej on this server
  596. # [22:20] * gsnedders ponders where the other comes from
  597. # [22:20] <othermaciej> damn him for stealing my name
  598. # [22:20] <gsnedders> I'm too slow, dangnamit!
  599. # [22:20] <molly> hehe
  600. # [22:21] <Hixie> molly: commented on your blog
  601. # [22:21] <molly> Hixie, hi there
  602. # [22:21] <molly> thank you!
  603. # [22:21] <jgraham> gsnedders: If the class were sufficiently competent you could explain that it's needed to turn off some odd behaviour needed for back-compat
  604. # [22:22] <gsnedders> jgraham: what's wrong with the odd behaviour?
  605. # [22:22] <hsivonen> gsnedders: odd behavior is counter-intuitive
  606. # [22:22] <jgraham> It's odd :)
  607. # [22:22] <hsivonen> gsnedders: counter-intuitive is hard
  608. # [22:22] * gsnedders is trying to remember how he explained it
  609. # [22:22] <Hixie> molly: to answer your question "so what's the point of HTML 5 serialization under W3C then?", the answer is that we had to move the spec development to have it covered by the w3c's patent policy in order to get microsoft to review the spec.
  610. # [22:22] <gsnedders> hsivonen: HTML is odd regardless, though
  611. # [22:23] <Philip`> People seem to be very good at remembering <html> and <head> and <body> - what makes <!doctype html> so much harder?
  612. # [22:23] <Hixie> molly: (there were other minor benefits of having it under the w3c, but that was by far the main reason)
  613. # [22:23] <molly> Hixie, I am following the lists but part of my frustration is the volume. I will be present at the working group during the tech plenary in november
  614. # [22:23] <jgraham> Anyway molly, things like the parsing algorithm will, eventually, make things better for authors and they won't even know about it
  615. # [22:23] <molly> yes, Chris filled me in on that part
  616. # [22:23] <othermaciej> having it covered by the w3c patent policy is a benefit to all interested parties
  617. # [22:23] <molly> but there is still expressed concern over that
  618. # [22:24] <Hixie> othermaciej: indeed
  619. # [22:24] <molly> I'm not well-versed on IP/Patent issues so I really wouldn't want to comment on that
  620. # [22:24] <othermaciej> the mail volume is indeed hard to follow
  621. # [22:24] <molly> but I understand the general points
  622. # [22:24] * Quits: grimboy_uk (n=grimboy@85-211-250-15.dsl.pipex.com) (Read error: 110 (Connection timed out))
  623. # [22:24] <othermaciej> it would be good if it was easier to follow only a subset of issues, for those who have strong interest and expertise in particular areas but limited time
  624. # [22:24] * Joins: grimboy_uk (n=grimboy@85.211.238.49)
  625. # [22:24] <othermaciej> I'm not sure how to make that happen though
  626. # [22:24] <molly> that's a really good point maciej
  627. # [22:25] <othermaciej> having the whatwg list is good as a forum for those who are for whatever reason unwilling or unable to join the HTML WG
  628. # [22:25] <Hixie> you don't really have to follow the lists to contribute, though
  629. # [22:25] <othermaciej> but the balance of useful work continues to shift more towards the HTML WG list
  630. # [22:25] <molly> Hixie: I know, and as I said, I'll be there in person in November
  631. # [22:25] <Hixie> in the public-html list you need but send out your feedback, then write it up in the wiki according to that e-mail i sent
  632. # [22:25] <Hixie> and then it'll be taken into account
  633. # [22:26] <molly> sot hat's a good starting point for me in terms of any actual participation
  634. # [22:26] <molly> I have lots of reasons to be hesitant, as you can see
  635. # [22:26] <jgraham> The flip side is public-html probably has a poorer signal/noise than the WHATWG list still
  636. # [22:26] <Hixie> molly: i'm not sure i will, we'll see (i don't see much point to face-to-face meetings, they cost a lot in carbon offsets and they don't tend to bring the spec forward much)
  637. # [22:26] <molly> Hixie: Funny, i find it the opposite. The effort and commitment to show up, pay the way, and face each other can be very useful IMO
  638. # [22:27] <gsnedders> molly: there are plenty of people, like myself, who simply cannot afford to go to meetings for whatever reason
  639. # [22:27] <molly> I understand that gsnedders
  640. # [22:27] <molly> that's a realistic barrier that's an unfortunate one
  641. # [22:27] <molly> but we all work in different ways
  642. # [22:28] <othermaciej> face-to-face meetings can be useful on a human and community level, but are rarely an efficient way to make progress on the spec
  643. # [22:28] <gsnedders> molly: which thereby has the affect that everything has to go through the mailing lists after a real meeting
  644. # [22:28] <molly> Those here who have met me know that I'm a very personable human and enjoy the F2F work a great deal
  645. # [22:28] <molly> and benefit most from it
  646. # [22:28] <othermaciej> meeting people in person aids mutual understanding and helps soften future online disputes
  647. # [22:28] <molly> this is my feeling too, maciej
  648. # [22:28] <Hixie> othermaciej: yeah, i would be interested in an unconference style meeting, if we could get a good chunk of the group to attend (like, 50-100)
  649. # [22:28] <molly> that's what works for me
  650. # [22:28] <molly> how could something like that work? Be affordable for people and actually happen?
  651. # [22:28] <molly> I'd love to see something of that nature
  652. # [22:29] <molly> "unconference style meeting"
  653. # [22:29] <Hixie> othermaciej: i just don't want to sit around a table for 3 days while people talk about how their pet feature is a good idea but without even having explained what they're trying to solve and without any evidence
  654. # [22:29] <hsivonen> molly: I guess the big problem is where to have it: Paris, Boston or the Bay Area
  655. # [22:29] <Hixie> to support their claims
  656. # [22:29] <jgraham> hsivonen: Why one of those
  657. # [22:29] <molly> Hixie: I surely can't disagree with you on THAT! :D
  658. # [22:29] <jgraham> ?
  659. # [22:30] <Hixie> molly: i don't think i can think of a single f2f meeting i've been to that hasn't involved hours of that :-(
  660. # [22:30] <othermaciej> Hixie: I would echo your loathing of the standard w3c format
  661. # [22:30] <hsivonen> jgraham: the hot spots of Europe, East Coast and West Coast
  662. # [22:30] <molly> within the W3C format yesw
  663. # [22:30] <molly> well, Henri - we had that informal day in Paris
  664. # [22:30] <molly> something could grow from that sort of thing
  665. # [22:30] <Hixie> gotta go, bbiab
  666. # [22:30] <molly> that approach, let's say
  667. # [22:31] <molly> round table discussion external from W3C, corporate agendas
  668. # [22:31] <molly> etc.
  669. # [22:31] <molly> no one's saying any of this is easy or has a fast solution
  670. # [22:31] <molly> my real concern is what happened to WaSP
  671. # [22:31] * Quits: mattly (n=matt@66-214-204-123.dhcp.snlo.ca.charter.com) ("screw you guys, i'm going home")
  672. # [22:31] <molly> and the failings of the W3C
  673. # [22:31] <gsnedders> less and less appears to be happening at WaSP
  674. # [22:31] * Quits: weinig_ (i=weinig@nat/apple/x-1fa9bfb8288f1e41) (Read error: 104 (Connection reset by peer))
  675. # [22:31] <molly> to provide a fair forum and process
  676. # [22:31] * Joins: weinig (i=weinig@nat/apple/x-ea4d2914f7e6633c)
  677. # [22:32] <jgraham> In any case the problem is not where to have it, it's getting enough people to attend
  678. # [22:32] <molly> gsnedders: As its retired mom, you know it breaks my heart
  679. # [22:32] <molly> jgraham: maybe it has to take place in several locations and we synch up somehow
  680. # [22:32] <molly> this way it can be global and reduce the carbon concerns that Hixie pointed to
  681. # [22:33] <gsnedders> and also, most likely, get more attendees
  682. # [22:33] <gsnedders> (due to lower costs of travel, etc)
  683. # [22:33] <molly> yes
  684. # [22:33] <molly> absolutely
  685. # [22:33] <hsivonen> jgraham: exactly, the three places I mentioned probably are the best for attendance, but still people are reluctant to travel across the Atlantic or from coast to coast. so no matter what the place is, it is always wrong from some point of view
  686. # [22:33] <molly> that's why maybe several locations
  687. # [22:33] <molly> where there's onsite, linked up
  688. # [22:33] <molly> Paris, SF, etc.
  689. # [22:33] <gsnedders> (though if there's one in Paris, and it's in late Oct, maybe I'll be there :P)
  690. # [22:33] <jgraham> molly: Even if you have three locations, most people would have expenses of >£100 ($200) to attend
  691. # [22:34] <jgraham> which is a lot for people not being paid for this stuff
  692. # [22:34] <molly> hey, you're preaching to the soprano in the choir here
  693. # [22:34] <molly> I've spent a fortune in my own money
  694. # [22:34] <molly> on standards-related efforts
  695. # [22:34] <molly> believe me, I know
  696. # [22:34] <gsnedders> what about students, who simply don't have their own money to spend?
  697. # [22:35] * Parts: billmason (n=billmaso@ip156.unival.com)
  698. # [22:35] <molly> there has to be some kind of relay
  699. # [22:35] <molly> clearly we'd be synched up
  700. # [22:35] <molly> and on IRC
  701. # [22:35] <othermaciej> maybe we could get some of the big corporations involved to provide travel stipends for at least some volunteer contributors
  702. # [22:35] <molly> and there can be some kind of moderated approach where people who could not do it F2F
  703. # [22:35] <molly> and maciej - I would be willing to knock on a lot of doors to try and get some resources for that
  704. # [22:36] * jgraham should mention he is very much in favour of a f2f since it would help sort out some of the most persistent culture problems on public-html
  705. # [22:36] <gsnedders> othermaciej: end up with people screaming "I DESERVE IT MORE THAN HIM!"
  706. # [22:36] <molly> gsnedders: yes but there could be specifics put into place
  707. # [22:36] <jgraham> gsnedders: Maybe that's not a problem
  708. # [22:36] <molly> such as agreements that a sponsored participation requires an equal action (ie, involvement for a year with the group, etc.)
  709. # [22:36] <othermaciej> gsnedders: I'm not too worried about that
  710. # [22:36] <molly> neither am I to be honest
  711. # [22:37] <molly> there are ways to manage that
  712. # [22:37] <jgraham> People have to compete for funding all the time
  713. # [22:37] <molly> but I think we're on to something here
  714. # [22:37] <gsnedders> wasn't it brought up before when we last discussed a f2f on public-html?
  715. # [22:37] <molly> this would be third party
  716. # [22:37] <molly> or non party
  717. # [22:37] <molly> I should say
  718. # [22:37] <jgraham> gsnedders: Yes. I think some people didn't like it
  719. # [22:38] <jgraham> but maybe they were wrong
  720. # [22:38] <molly> in other words, this is not W3C, not WHAT WG, not WaSP, not Microsoft, Mozilla, etc.
  721. # [22:38] <hsivonen> the problem with the mountain view f2f was that it lacked any stated purpose
  722. # [22:38] <jgraham> or it was pitched in the wrong way
  723. # [22:38] <molly> well, a big plate of food for thought, I Think
  724. # [22:39] <gsnedders> arguably the state of the politeness of some is a purpose on its own, now
  725. # [22:39] <molly> yes
  726. # [22:39] <molly> yes yes yes
  727. # [22:40] <molly> but I wonder if some F2F time can help that. I mean, not just sitting around the table arguing, but gaining real insight into perspectives. That, at least for me, comes through human discourse
  728. # [22:40] <molly> that is not guided by process
  729. # [22:40] <gsnedders> molly: I think just being dumped F2F might help on its own. Plenty of people are acting far worse than you ever would offline.
  730. # [22:40] <molly> I know. I think this is why I'm so upset
  731. # [22:41] <molly> I've got long-term friends and colleagues fighting with each other
  732. # [22:41] <molly> when clearly they have common goals as well as uncommon ones
  733. # [22:41] <molly> it disturbs me very much
  734. # [22:41] <molly> to see people getting that frustrated
  735. # [22:41] <jgraham> hmm. have to go for a bit.
  736. # [22:41] <molly> I don't want to add to the frustration, I didn't realize what I was stepping in honestly
  737. # [22:41] <hsivonen> molly: tantek had insightful things to say about the culture clash
  738. # [22:42] <molly> so now I'd like to help reduce the frustration
  739. # [22:42] * hsivonen looks up the URL
  740. # [22:42] <molly> yes, he and I had a long talk about it last night Henri
  741. # [22:42] <molly> I thought he made some excellent points about the various factions
  742. # [22:42] <hsivonen> http://krijnhoetmer.nl/irc-logs/whatwg/20070812#l-123
  743. # [22:42] <molly> but that's still no excuse for what Tantek himself points out as extremely negative behavior
  744. # [22:43] <molly> not from anyone, including myself. I get frustrated too
  745. # [22:43] <molly> but the accessibility guys, for one
  746. # [22:43] <molly> that stuff has to stop
  747. # [22:43] <molly> I mean, you'll never get Joe Clark to stop
  748. # [22:43] <molly> but that's Joe
  749. # [22:43] <molly> however, there have to be some human connections made here between those factions
  750. # [22:44] <molly> or more accurately, those fractions (badumpump) ;-)
  751. # [22:44] <gsnedders> I think one thing that people need to get past is that evangelism is not enough on its own. Too many people are pretty much saying that any accessibility feature MUST NOT be removed, without any justification.
  752. # [22:44] <molly> I think removing things is part of the fear and concern over HTML 5 in general
  753. # [22:45] * Quits: grimboy_uk (n=grimboy@85.211.238.49) (Read error: 104 (Connection reset by peer))
  754. # [22:45] <molly> why do things have to be "removed" per se
  755. # [22:45] <hsivonen> it seems to me that not all "accessibility guys" are the same. and there are some who don't think HTML 5 is all bad. but I understand that they don't want to engage in the smear discussions
  756. # [22:45] <gsnedders> my posting has gone down and down the more and more this has all taken over
  757. # [22:45] <gsnedders> because there's very little real discussion happening
  758. # [22:45] <molly> yes, and that's a problem!
  759. # [22:45] <molly> signal / noise
  760. # [22:46] <gsnedders> not just that, it's that there is barely any signal at all, now
  761. # [22:46] <molly> Everyone who cares, I think, feels that
  762. # [22:46] <gsnedders> I've been posting everything bar HTML WG spec review to the WHATWG list
  763. # [22:48] * Quits: dev0 (i=Tobias@unaffiliated/icefox0) ("dev0 has no reason")
  764. # [22:48] <hsivonen> molly: part of the problem is that public-html is so unpleasant that the signal get routed around it (e.g. to here)
  765. # [22:48] <molly> I think I'd also like to see some status stuff
  766. # [22:48] <molly> like "these are the key points"
  767. # [22:48] <hsivonen> s/get/gets/
  768. # [22:48] <molly> I'd help with that - but writtten for the masses
  769. # [22:48] <molly> not for the groups
  770. # [22:49] <molly> that might help cause less concern in the broader community?
  771. # [22:49] <molly> right now, that noise is frightening people
  772. # [22:49] <molly> or overwhelming them, even our best and brightest
  773. # [22:50] * Joins: mjs (n=othermac@17.255.106.78)
  774. # [22:50] * Joins: zcorpan_ (n=zcorpan@85.227.145.211)
  775. # [22:50] * Quits: othermaciej (n=mjs@17.255.106.78) (Read error: 104 (Connection reset by peer))
  776. # [22:51] <gsnedders> the other interesting factoid is that as the volume of email has increased, the time taken for me to read them has gone down, simply as more and more of it is pointless and takes scarcely any time to deal with
  777. # [22:51] * mjs is now known as othermaciej
  778. # [22:51] <gsnedders> molly: what sort of status things?
  779. # [22:51] <molly> some way of sorting through the noise
  780. # [22:51] <molly> to get to the signal
  781. # [22:52] <molly> and clarify those points on a regular basis to the broader public
  782. # [22:52] * Joins: weinig_ (i=weinig@nat/apple/x-970ab8bb8e934074)
  783. # [22:52] * Quits: weinig (i=weinig@nat/apple/x-ea4d2914f7e6633c) (Read error: 104 (Connection reset by peer))
  784. # [22:52] <gsnedders> so some sort of summary about what is going on?
  785. # [22:52] <molly> exactly
  786. # [22:52] <gsnedders> and do it how frequently? when needed?
  787. # [22:53] <molly> I think an update now would be great, something to provide the community at large with more insight into the signal and get the frustration level that the noise is creating down a bit
  788. # [22:53] <molly> I think another update around the Tech Plenary time would also be good
  789. # [22:53] <molly> and if needed in between
  790. # [22:53] <gsnedders> when is the Tech Plenary?
  791. # [22:53] <molly> November
  792. # [22:54] * Joins: RogerJ (n=Roger456@213-64-74-230-no57.tbcn.telia.com)
  793. # [22:54] <hsivonen> molly: there's no clear WG level going on. but watching Hixie here and watching the svn commit messages gives an idea of the goings on with the spec
  794. # [22:54] <molly> http://www.w3.org/2007/11/TPAC/overview.html
  795. # [22:55] <molly> like the Twitter updates? Those are cool. But how about annotated every few weeks
  796. # [22:55] <molly> that sort of thing
  797. # [22:55] <hsivonen> molly: btw, one PR problem is that since Hixie doesn't really do firefighting in spec writing, the time it takes from an issue flaring up to the spec changing can be in the order of months
  798. # [22:56] <hsivonen> molly: so even if Hixie says here that a bad part of the spec sucks, people still keep thinking that the spec is destined to remain sucky on that point
  799. # [22:57] <Hixie> can even take years
  800. # [22:57] <hsivonen> (I think not doing firefighting is the reasonable way, but it still creates the wrong impressions sometimes)
  801. # [22:58] <hsivonen> molly: so people who don't follow along here get outraged about <font> again and again
  802. # [22:58] <hsivonen> molly: I'm here, so I just leave <font> unimplemented in the conformance checker and trust that the part will go away in due course
  803. # [22:58] <Hixie> i should go around adding red boxes to the most controversial parts
  804. # [22:58] <Hixie> that might help
  805. # [22:58] <hsivonen> Hixie: yeah
  806. # [22:59] <molly> Something of that nature, yes!
  807. # [22:59] <molly> good idea
  808. # [22:59] <Hixie> can you send a mail to me or one of the lists listing the controversial parts and suggesting i add red boxes? i'll try to do it after my next commit (the alt text revamp)
  809. # [22:59] <Hixie> i have to go get my bike fixed first
  810. # [23:01] <gsnedders> g'nite
  811. # [23:01] * Joins: grimboy_uk (n=grimboy@85.211.251.21)
  812. # [23:01] <gsnedders> but, molly, if you want any help to do such an update, I'm more than welcome to do so
  813. # [23:02] <molly> absolutely!
  814. # [23:02] <molly> I'd totally like to do that
  815. # [23:02] <molly> HTML 5 news capsules, like Hixie does on Twitter but with annotations
  816. # [23:03] <gsnedders> molly: I'm on here pretty much all the time (though not always physically here, but I'll read anything addressed to me), and there are other contact details listed on my blog <http://geoffers.uni.cc/the-author/>
  817. # [23:04] <gsnedders> (that design is almost two years old. wow.)
  818. # [23:04] <Hixie> anyone should feel free to post on the WHATWG blog if they want to post regular updates
  819. # [23:04] <Hixie> in fact i highly encourage it
  820. # [23:05] <Hixie> just sign up to the blog and then post (and ask Lachy to set you up as an editor so you can actually post the entries once you've drafted them, we had to turn that off because spammers were using it)
  821. # [23:05] <molly> but see, that goes back to the issue of fractioning
  822. # [23:05] <molly> Shouldn't that really be also on the W3C?
  823. # [23:05] <Hixie> well, feel free to post on the w3c blog too :-)
  824. # [23:05] <molly> hahaha
  825. # [23:05] <Hixie> or instead :-)
  826. # [23:05] <Hixie> but you'll have to speak to DanC about that, i don't know how to post to that blog
  827. # [23:06] <Hixie> it's not an open blog like the whatwg's
  828. # [23:06] <molly> yep
  829. # [23:06] <Hixie> my point is just that you should just go ahead and do things
  830. # [23:06] <molly> Hixie, I think my track record proves I learned that one a long time ago ;-)
  831. # [23:07] * Quits: RogerJ (n=Roger456@213-64-74-230-no57.tbcn.telia.com)
  832. # [23:07] <molly> however, battles must be picked carefully
  833. # [23:07] <molly> that's my concern.
  834. # [23:07] <molly> for me, personally. That's why I think WaSP has a responsibility here.
  835. # [23:07] <Hixie> well, i don't care who does the updates or where
  836. # [23:07] <Hixie> i just don't have time to edit the spec _and_ do the updates
  837. # [23:07] <Hixie> so someone else has to do it
  838. # [23:07] <molly> no of course not
  839. # [23:07] <Hixie> it can be you, or it can be someone else, that's not my problem :-)
  840. # [23:08] <molly> getting the highlighting done would be an awesome thing to help out too
  841. # [23:08] <molly> so you committed to that
  842. # [23:08] <molly> I'll commit to working with whoever here wants to work on
  843. # [23:08] <molly> summaries
  844. # [23:08] <molly> and we can cross blog 'em
  845. # [23:08] <hsivonen> also http://people.w3.org/mike/planet/html5/
  846. # [23:08] <molly> which is the best idea to get the word out to broad communities anyway
  847. # [23:09] <molly> Henri: thanks!
  848. # [23:09] <Hixie> (i recommend starting by assuming no-one will help out, because usually people only help out once it is proven that something is happening)
  849. # [23:11] <molly> Hixie: I appreciate your kind guidance.
  850. # [23:11] * Parts: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  851. # [23:11] <molly> I'm pretty used to herding cats.
  852. # [23:12] <molly> and occasionally effective at it, too :D
  853. # [23:12] <Hixie> :-)
  854. # [23:12] <Hixie> bbiab
  855. # [23:14] <gsnedders> molly, Hixie: IMO such a blog should be separate to both WHATWG and the W3C
  856. # [23:14] <molly> gsnedders: I think if it's just updates
  857. # [23:14] <molly> it is best in as many places as possible
  858. # [23:15] <gsnedders> I think it's both or separate. People will always conclude something wrong if it is just in one place.
  859. # [23:17] * Quits: weinig_ (i=weinig@nat/apple/x-970ab8bb8e934074) (Read error: 110 (Connection timed out))
  860. # [23:24] <hsivonen> molly: thanks for following up to my question
  861. # [23:24] <hsivonen> bed time now
  862. # [23:24] <hsivonen> nn
  863. # [23:26] <molly> night Henri!
  864. # [23:26] <molly> thank you
  865. # [23:28] * Quits: KevinMarks (i=KevinMar@conference/plone/docsprint/x-b5a668b0b901c607) ("The computer fell asleep")
  866. # [23:28] <gsnedders> time for me to go sleep now, too (I really mean it, this time)
  867. # [23:34] * Joins: weinig (i=weinig@nat/apple/x-6287f8fc02f7ce0b)
  868. # [23:34] * Quits: grimboy_uk (n=grimboy@85.211.251.21) (Read error: 110 (Connection timed out))
  869. # [23:34] * Joins: grimboy_uk (n=grimboy@85.211.235.93)
  870. # [23:40] <molly> night :D
  871. # [23:40] <molly> time for me to get ready for a meeting - thanks everyone. I'll be interested as to where this goes, and I shall visit again very soon
  872. # [23:40] * Quits: molly (n=mollyhol@63-252-121-133.ip.mcleodusa.net) ("Quitting!")
  873. # [23:41] * Quits: hendry (n=hendry@91.84.53.136) ("sleep")
  874. # [23:57] * Quits: othermaciej (n=othermac@17.255.106.78)
  875. # Session Close: Tue Aug 14 00:00:00 2007

The end :)