/irc-logs / freenode / #whatwg / 2010-01-04 / end

Options:

  1. # Session Start: Mon Jan 04 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:24] * Quits: Rik` (n=Rik`@ARennes-352-1-49-40.w81-53.abo.wanadoo.fr)
  4. # [00:26] * Quits: payman` (n=payman@193.170.48.62) (Read error: 60 (Operation timed out))
  5. # [00:28] * Joins: nessy (n=Adium@124-171-24-116.dyn.iinet.net.au)
  6. # [00:28] * Quits: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 60 (Operation timed out))
  7. # [00:32] * Joins: erlehmann (n=erlehman@dslb-092-078-128-103.pools.arcor-ip.net)
  8. # [00:49] * Quits: virtuelv (n=virtuelv@162.179.251.212.customer.cdi.no) (Read error: 110 (Connection timed out))
  9. # [01:11] * Joins: bfrohs (n=chatzill@75-134-215-82.dhcp.trcy.mi.charter.com)
  10. # [01:32] * Quits: workmad3 (n=workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Read error: 54 (Connection reset by peer))
  11. # [01:48] * Quits: erikvold (n=erikvvol@S01060024012860e9.gv.shawcable.net) (Remote closed the connection)
  12. # [01:48] * Joins: erikvold (n=erikvvol@S01060024012860e9.gv.shawcable.net)
  13. # [01:49] * Quits: ttepasse (n=ttepas--@dslb-088-077-092-239.pools.arcor-ip.net) (Read error: 60 (Operation timed out))
  14. # [01:50] * Joins: ttepasse (n=ttepas--@dslb-084-060-039-164.pools.arcor-ip.net)
  15. # [01:59] * Quits: ttepasse (n=ttepas--@dslb-084-060-039-164.pools.arcor-ip.net) ("?Q")
  16. # [02:00] * Quits: jwalden (n=waldo@adsl-70-131-131-131.dsl.emhril.sbcglobal.net) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.1.6/20091216142458]")
  17. # [02:06] * Quits: bfrohs (n=chatzill@75-134-215-82.dhcp.trcy.mi.charter.com) ("ChatZilla 0.9.86 [Firefox 3.5.8pre/20100102054004]")
  18. # [02:20] * Joins: wakaba_ (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  19. # [02:24] * Quits: gunderwonder (n=gunderwo@118.80-202-84.nextgentel.com) (Read error: 60 (Operation timed out))
  20. # [02:30] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
  21. # [02:30] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  22. # [02:37] * Quits: Huvet (n=Emil@c-2fc1e555.07-131-73746f39.cust.bredbandsbolaget.se) ("Leaving.")
  23. # [02:38] * Joins: aboodman (n=slau@c-98-210-196-233.hsd1.ca.comcast.net)
  24. # [02:45] * Joins: mpt (n=mpt@canonical/mpt)
  25. # [02:49] * Quits: mpt (n=mpt@canonical/mpt) (Client Quit)
  26. # [03:00] * Joins: shepazu (n=schepers@adsl-227-106-143.rmo.bellsouth.net)
  27. # [03:01] * Joins: annodomini (n=lambda@wikipedia/lambda)
  28. # [03:03] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  29. # [03:10] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  30. # [03:39] * Joins: bzed_ (n=bzed@devel.recluse.de)
  31. # [03:42] * Quits: bzed_ (n=bzed@devel.recluse.de) (Read error: 104 (Connection reset by peer))
  32. # [03:42] * Joins: bzed_ (n=bzed@devel.recluse.de)
  33. # [03:48] * Joins: bzed__ (n=bzed@devel.recluse.de)
  34. # [03:49] * Joins: jwalden (n=waldo@adsl-70-131-131-131.dsl.emhril.sbcglobal.net)
  35. # [03:53] * Quits: bzed (n=bzed@devel.recluse.de) (Read error: 111 (Connection refused))
  36. # [03:53] * bzed__ is now known as bzed
  37. # [03:58] * Joins: erikvvold (n=erikvvol@S01060024012860e9.gv.shawcable.net)
  38. # [03:59] * Quits: erikvold (n=erikvvol@S01060024012860e9.gv.shawcable.net) (Read error: 60 (Operation timed out))
  39. # [03:59] * erikvvold is now known as erikvold
  40. # [03:59] * Joins: erlehmann_ (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net)
  41. # [04:08] * Quits: bzed_ (n=bzed@devel.recluse.de) (Read error: 111 (Connection refused))
  42. # [04:15] * Quits: erlehmann (n=erlehman@dslb-092-078-128-103.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
  43. # [05:14] * Joins: MikeSmith (n=MikeSmit@EM114-48-3-227.pool.e-mobile.ne.jp)
  44. # [05:14] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  45. # [05:27] * jcranmer is now known as adsf
  46. # [05:27] * adsf is now known as jcranmer
  47. # [05:43] * Quits: erikvold (n=erikvvol@S01060024012860e9.gv.shawcable.net) ("me so sleepy")
  48. # [05:44] * Joins: erikvold (n=erikvvol@S01060024012860e9.gv.shawcable.net)
  49. # [05:51] <Dashiva> Hum
  50. # [05:57] <Dashiva> "IO Error: Resource size exceeds limit" for http://validator.nu/?doc=http%3A%2F%2Fdev.w3.org%2Fhtml5%2Fspec%2FOverview.html
  51. # [05:57] <Dashiva> I was trying to check if the w3c version of the spec is real html4, or just html5 with a html4 doctype
  52. # [06:02] * Quits: nessy (n=Adium@124-171-24-116.dyn.iinet.net.au) ("Leaving.")
  53. # [06:13] * Quits: eighty4 (n=eighty4@eighty4.se) (Excess Flood)
  54. # [06:13] * Joins: eighty4 (n=eighty4@eighty4.se)
  55. # [06:19] <MikeSmith> Dashiva: please try on http://qa-dev.w3.org:8888/
  56. # [06:20] <MikeSmith> I upped the limit there
  57. # [06:20] <MikeSmith> the upstream limit at validator.nu is 4096KB
  58. # [06:20] <MikeSmith> and the spec is around 4300KB or so now
  59. # [06:52] * Joins: wakaba_0 (n=wakaba_@119-228-219-41.eonet.ne.jp)
  60. # [07:08] * Quits: wakaba_ (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Read error: 110 (Connection timed out))
  61. # [07:17] * Quits: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Read error: 110 (Connection timed out))
  62. # [07:34] * Quits: jwalden (n=waldo@adsl-70-131-131-131.dsl.emhril.sbcglobal.net) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.1.6/20091216142458]")
  63. # [07:46] * Joins: zalan (n=zalan@catv-89-135-144-122.catv.broadband.hu)
  64. # [07:55] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  65. # [08:06] * Quits: annodomini (n=lambda@wikipedia/lambda)
  66. # [08:13] * Joins: nessy (n=Adium@124-171-24-116.dyn.iinet.net.au)
  67. # [08:19] <hsivonen> I wonder if the spec is going to grow like gmail storage space
  68. # [08:20] <Hixie> the sum of specs that define the web will, certainly
  69. # [08:21] <Hixie> whether we have that in one document or a great many or something in between is an editorial issue
  70. # [08:21] <hsivonen> well, looks like validator.nu needs to have its limit grown once in a while to accommodate the spec
  71. # [08:22] <hsivonen> it'll be interesting to see if at some point the limit grows larger than what would be appropriate to protect the VM from DoS
  72. # [08:26] <MikeSmith> hsivonen: welcome back
  73. # [08:26] <hsivonen> MikeSmith: thanks
  74. # [08:27] <hsivonen> MikeSmith: I'll look at your patches in due course.
  75. # [08:27] <MikeSmith> no hurry
  76. # [08:27] <MikeSmith> I got a couple more on the way
  77. # [08:28] <MikeSmith> I don't mean to overload you, just took advantage of the holiday break to try to get a few things written up
  78. # [08:31] <MikeSmith> hsivonen: btw, do you know of any reason why <style><!--></style> should be conforming?
  79. # [08:31] <MikeSmith> it's not conforming in the current spec
  80. # [08:31] <MikeSmith> in the ABNF for the contents of the style element
  81. # [08:32] <Hixie> hsivonen: the spec shouldn't have grown... it was working fine before the holidays for me, and i validate the complete version of the spec before preprocessing (i.e. about 13 specs at once)
  82. # [08:32] <Hixie> maybe the preprocessor overhead is more than i realised
  83. # [08:33] <MikeSmith> it was hitting the v.nu size limit well before the holidays
  84. # [08:33] <hsivonen> MikeSmith: how does that parse in legacy browsers?
  85. # [08:33] <MikeSmith> Hixie: a month or more ago
  86. # [08:33] <MikeSmith> hsivonen: not sure
  87. # [08:33] <Hixie> MikeSmith: the post-processed version?
  88. # [08:33] <MikeSmith> hsivonen: maybe Simon knows
  89. # [08:33] <Hixie> or the version i validate with all the specs?
  90. # [08:34] <Hixie> and w3c or whatwg?
  91. # [08:34] <hsivonen> I reran the deployment script. let's see if the new limit of 5 MB takes effect or if I need to restart the validator manually
  92. # [08:34] <MikeSmith> Hixie: the w3c one for sure
  93. # [08:34] <MikeSmith> but I thought the whatwg version also
  94. # [08:34] <hsivonen> MikeSmith: in any case, it seems to me that it's not important to make <style><!--></style> conforming
  95. # [08:34] <Hixie> MikeSmith: post-processed?
  96. # [08:34] <MikeSmith> hsivonen: OK
  97. # [08:35] <MikeSmith> Hixie: yesh
  98. # [08:35] <Hixie> i'm very surprised that the processing overhead is so high that html5 alone is bigger than the source of all the specs together
  99. # [08:36] <MikeSmith> hsivonen: I was asking mainly because it was conforming before -- the spec said something like, "An escaping text span start can share its "--" characters with its escaping text span end".
  100. # [08:37] <MikeSmith> so was wondering if somebody has maybe requested that it be conforming for some reason
  101. # [08:37] <hsivonen> MikeSmith: I haven't made any change in that area knowingly other than trying to implement the new tokenizer states as specced
  102. # [08:38] <MikeSmith> hsivonen: I meant just that it was conforming in the spec, before Hixie switched to the specific ABNF definition for style content
  103. # [08:39] <MikeSmith> I didn't mean to say that parser behavior had changed
  104. # [08:40] <hsivonen> MikeSmith: oh. I haven't looked at what the spec says about the conformance of style and script content now
  105. # [08:40] <MikeSmith> OK, anyway, I was wondering about it because I wrote up a style-content checker (after bug from Simon)
  106. # [08:41] <MikeSmith> which is one of the other patches I still need to send you for review
  107. # [08:41] <MikeSmith> and if that case were conforming, it would mean adding another state to the state machine that does the check
  108. # [08:42] <MikeSmith> but anyway, for now, I just implemented it to spec
  109. # [08:44] <MikeSmith> if there were ever somebody who wanted "<!-->" to be conforming, I guess they'll need to re-review the spec and send a comment to Hixie
  110. # [08:46] <MikeSmith> hsivonen: so the other patch I have ready is for this:
  111. # [08:46] <MikeSmith> http://qa-dev.w3.org:8888/?doc=http%3A%2F%2Fdev.w3.org%2Fhtml5%2Ftests%2Fvalidation%2Ffull%2Finvalid%2Fmissing-attributes%2Flink-missing-href.html
  112. # [08:47] <hsivonen> MikeSmith: what's the mechanism for making that happen?
  113. # [08:48] <MikeSmith> hsivonen: added all required-attributes to Assertions.java and have the build make copies of the meta.rnc, embed.rnc, media.rnc, and microdata.rnc files with the required attributes made optional in the schema
  114. # [08:49] <MikeSmith> the copies are, e.g, meta-vnu.rnc
  115. # [08:49] <MikeSmith> and are generated, so not in version control
  116. # [08:49] <hsivonen> ok
  117. # [08:49] <MikeSmith> used only internally by vnu
  118. # [08:49] <MikeSmith> does that sound sane?
  119. # [08:51] <hsivonen> MikeSmith: yes
  120. # [08:51] * Joins: roc (n=roc@121-72-165-156.dsl.telstraclear.net)
  121. # [08:51] <hsivonen> (I really wish Jing could do this)
  122. # [08:51] <MikeSmith> hsivonen: OK
  123. # [08:51] <MikeSmith> yeah, I wish jing would do it too
  124. # [08:52] <MikeSmith> but one case I can imagine it being hard for Jing itself to report usefully on is the data and type attributes on the object element
  125. # [08:54] <MikeSmith> hsivonen: do you know if MSV reports usefully for required-but-missing attributes cases?
  126. # [08:54] <hsivonen> MikeSmith: I don't
  127. # [08:54] <MikeSmith> I tried to check with relaxed earlier, but the site seems to be down
  128. # [08:59] * Quits: Heimidal (n=heimidal@unaffiliated/heimidal) (Remote closed the connection)
  129. # [09:01] <Hixie> ok, vacation over
  130. # [09:02] <Hixie> so i'm supposed to get all these bugs done by sunday huh
  131. # [09:02] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  132. # [09:05] <hsivonen> Hixie: at least most of them are clear for straightforward fixing or wontfixing
  133. # [09:07] <hsivonen> what's the deal with the assignee change here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238 ?
  134. # [09:09] <othermaciej> Hixie: would be nice to get 'em done, yeah - how many are open right now?
  135. # [09:09] <othermaciej> hsivonen: looks like an accident to me
  136. # [09:09] <Hixie> 212, shouldn't be a problem. though a number of them are things i'd really rather not resolve without knowing how the microdata issue gets resolved.
  137. # [09:11] <othermaciej> it's fine to pick out that subset and hold off, as long as you say so in the bugs (though I think we can have it resolved sometime in the coming week)
  138. # [09:12] <othermaciej> btw looking at the source of <http://dev.w3.org/html5/status/issue-status.html> it seems we have resolved 6 HTML WG tracker issues since I started the status list
  139. # [09:12] <Hixie> http://damowmow.com/playground/htmlwg/chart.html looks good, indeed
  140. # [09:14] <othermaciej> probably at least some of the upcoming batch of bugs will turn into issues
  141. # [09:37] * Quits: smaug (n=chatzill@cs181150024.pp.htv.fi) ("ChatZilla 0.9.85 [Firefox 3.7a1pre/20091213211355]")
  142. # [09:44] * Joins: smaug_ (n=chatzill@cs181150024.pp.htv.fi)
  143. # [09:51] * Joins: smaug (n=chatzill@cs181150024.pp.htv.fi)
  144. # [10:14] * Joins: workmad3 (n=workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  145. # [10:16] * Joins: mpt (n=mpt@canonical/mpt)
  146. # [10:17] * Joins: cedricv (n=cedric@112.199.233.48)
  147. # [10:23] * Quits: wakaba_0 (n=wakaba_@119-228-219-41.eonet.ne.jp) (Read error: 60 (Operation timed out))
  148. # [10:25] <Hixie> othermaciej: remind me - if i've included the boilerplate once, should i do it again if i'm closing the bug for the same reason?
  149. # [10:25] <Hixie> e.g. http://www.w3.org/Bugs/Public/show_bug.cgi?id=8096
  150. # [10:25] <othermaciej> Hixie: if someone reopened it?
  151. # [10:25] <Hixie> marked it NEEDSINFO, asked for data, someone reopened it with information i still don't understand
  152. # [10:25] <Hixie> when i ask for further clarification and mark it NEEDSINFO again, do i include the "rejected" boilerplate again?
  153. # [10:26] <othermaciej> I think an explanation of why the new info is not helpful is sufficient, but it would be fine to also add the boilerplate
  154. # [10:26] <workmad3> ooh, I remember that one from mailing list discussions :)
  155. # [10:27] <workmad3> I quite liked the idea, up until the point someone made note of the fact it would be ****ing awful for backwards compatibility
  156. # [10:27] <Hixie> k
  157. # [10:27] <AryehGregor> Hixie, there was a long discussion here on that one. It's completely crazy. He wants to have different resources served under the same URL, distinguished by the client's Accept header, like mysite.com/ returning a feed if you send Accept: application/rss+xml and a web page if you send Accept: text/html, or something similarly lunatic.
  158. # [10:27] * AryehGregor should probably be more polite in a publicly-logged channel, sorry to any readers who might have been offended
  159. # [10:28] <workmad3> :)
  160. # [10:28] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  161. # [10:29] <Hixie> AryehGregor: well i asked him to describe the user problem he's trying to solve, hopefully that will lead to him demonstrating that he isn't crazy and you just misunderstood him :-)
  162. # [10:29] <workmad3> oh wait... I just confused this one with the (very similar) discussion about <base>
  163. # [10:30] <AryehGregor> If I totally misunderstood him after like an hour-long IRC argument, good luck on that.
  164. # [10:31] * Joins: ROBOd (n=robod@89.122.216.38)
  165. # [10:31] * Quits: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) (Remote closed the connection)
  166. # [10:31] <workmad3> I *think* I can see the rationale behind the idea... basically allowing you to link to RESTful sites by specifying the content type
  167. # [10:32] <workmad3> but I don't see the rationale behind doing it all through one <link> tag... that just seems overcomplicated. Just specify a couple of <link> tags with different content types and pointing to the same URL
  168. # [10:32] <AryehGregor> The idea of returning an HTML page or an RSS feed from the same URL is crazy.
  169. # [10:32] <workmad3> couple that with the fact that multiple <link> tags already works and multiple type attributes on a <link> tag will break older browsers...
  170. # [10:33] <AryehGregor> If you want to link to them or use them differently in any user-visible way, then they're different resources.
  171. # [10:34] <workmad3> AryehGregor: both views have weight unfortunately... although I agree that if they are both of relevance to a user then they should be distinguished in a user-visible way
  172. # [10:34] <AryehGregor> Actually, content negotiation ends up not being very useful altogether, even when used for its intended purpose. At least in general web development, maybe not in some other uses of HTTP.
  173. # [10:34] <workmad3> as opposed to it being hidden behind some web service call that is :)
  174. # [10:35] <workmad3> still, if the guy wants to do this, a mechanism already exists (multiple <link>s) and the way he is suggesting just overcomplicates things and breaks backwards compatibility
  175. # [10:37] * Joins: wakaba_ (n=wakaba_@119-228-219-41.eonet.ne.jp)
  176. # [10:37] <workmad3> and HTML on the 'human web' shouldn't need to get confused with support for RESTful web services
  177. # [10:38] <AryehGregor> Not sure how REST works, but does it care about <link> in HTML documents?
  178. # [10:38] <workmad3> the REST principles don't
  179. # [10:38] * Joins: csarven (n=csarven@ip157-77-212-87.adsl2.static.versatel.nl)
  180. # [10:38] <workmad3> but a RESTful web service can be 'correct' to those principles and work like the guy is suggesting (so the rss feed and the html page are just 2 representations of the same resource)
  181. # [10:40] <workmad3> so it's not so much that they care about <link>s, more that multiple type's can be blugeoned into looking like REST support... if that makes sense and I'm not sounding as crazy as the original guy :)
  182. # [10:41] * Quits: roc (n=roc@121-72-165-156.dsl.telstraclear.net)
  183. # [10:49] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  184. # [10:52] * Joins: payman` (n=payman@193.170.48.62)
  185. # [10:59] <hsivonen> sigh. the autobuffer thread just keeps growing
  186. # [11:02] * Quits: wakaba_ (n=wakaba_@119-228-219-41.eonet.ne.jp) ("Leaving...")
  187. # [11:06] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  188. # [11:06] * Joins: Phae (n=phaeness@gateb.thls.bbc.co.uk)
  189. # [11:06] * Joins: MikeSmithX (n=MikeSmit@EM114-48-9-107.pool.e-mobile.ne.jp)
  190. # [11:08] * Joins: vvv (n=vvv@mediawiki/VasilievVV)
  191. # [11:08] <annevk> hsivonen, not in my inbox
  192. # [11:09] * annevk lets foolip deal with it :)
  193. # [11:15] * Quits: nessy (n=Adium@124-171-24-116.dyn.iinet.net.au) ("Leaving.")
  194. # [11:18] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
  195. # [11:20] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  196. # [11:24] * Quits: MikeSmith (n=MikeSmit@EM114-48-3-227.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  197. # [11:26] <hsivonen> Hixie: maybe boolean attributes should be called something other than boolean
  198. # [11:26] <hsivonen> Hixie: since it seems people assume they take values true and false
  199. # [11:26] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  200. # [11:26] <hsivonen> too late to change the language design pattern itself at this point, of course
  201. # [11:26] <hsivonen> and ARIA really doesn't help by failing to use the pre-existing design pattern
  202. # [11:29] <annevk> othermaciej, why would a non-normative guide be taken to Last Call?
  203. # [11:29] <annevk> othermaciej, typically they're published as W3C Note
  204. # [11:35] * Joins: adactio (n=adactio@host213-123-197-180.in-addr.btopenworld.com)
  205. # [11:36] <othermaciej> annevk: good point
  206. # [11:36] <othermaciej> annevk: does the W3C ever publish non-normative references or "primer" type guides as REC instead of Note?
  207. # [11:37] <annevk> maybe they have actually
  208. # [11:37] <othermaciej> I found at least one example: http://www.w3.org/TR/2009/REC-owl2-primer-20091027/
  209. # [11:38] <annevk> yeah http://www.w3.org/TR/rdf-primer/
  210. # [11:38] <othermaciej> but I also found many examples that are Notes
  211. # [11:39] <annevk> should've remembered that I guess
  212. # [11:39] <annevk> but I'm not sure why we'd bother with the additional hassle if it's not at all needed
  213. # [11:40] <othermaciej> I'm not sure if the TAG overlooked this, or if they specifically want it to end up a non-normative REC instead of a Note
  214. # [11:41] <Hixie> hsivonen: file a bug
  215. # [11:42] <hsivonen> Hixie: I will after lunch. gotta go now
  216. # [11:46] <annevk> presence attributes
  217. # [11:46] * Joins: myakura (n=myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp)
  218. # [11:58] <Lachy> flag attributes might be a better name
  219. # [12:00] * Joins: archtech (i=stanv@83.228.56.37)
  220. # [12:03] * Joins: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  221. # [12:04] <Lachy> it sucks that we have contenteditable, spellcheck and draggable=true/false, but inconsistently have autocomplete=on/off
  222. # [12:05] <annevk> spellcheck should have been on/off too
  223. # [12:06] <annevk> because it and autocomplete are about turning things off
  224. # [12:07] <jgraham> autocomplete=true would have been fine
  225. # [12:08] <Hixie> contenteditable and autocomplete were decided long before html5 was written
  226. # [12:08] <Hixie> so we were screwed either way
  227. # [12:08] <Lachy> yeah, I know that
  228. # [12:08] <annevk> no
  229. # [12:08] <annevk> we could've done spellcheck as on/off
  230. # [12:08] <annevk> but we didn't
  231. # [12:08] <Hixie> and had 2 and 2?
  232. # [12:08] <Hixie> that
  233. # [12:08] <Hixie> is even worse
  234. # [12:08] <Hixie> imho
  235. # [12:08] <annevk> no, they have different purposes each
  236. # [12:09] <Hixie> *shrug*
  237. # [12:09] <Hixie> actually by the time i added spellcheck it already had 2 implementations iirc
  238. # [12:09] <othermaciej> contentEditable and draggable are phrased as adjectives but also have the purpose of turning on/off
  239. # [12:09] <Lachy> if we introduce a buffering attribute, would buffering=on/off or true/false be better? Or should we go with none/auto/full as foolip suggested?
  240. # [12:09] <annevk> I think you might actually be the first that positioned the whole thing as such
  241. # [12:09] <Hixie> yeah i originally wrote it as a draft on damowmow.com
  242. # [12:09] <othermaciej> I would suggest not using on/off or true/false as the values if it has more than 2 states (which it should)
  243. # [12:10] <annevk> I meant the distinction between the attributes, not spellcheck (though you did that too)
  244. # [12:10] <Hixie> Lachy: last i looked at the thread it didn't seem that there was a strong use case for anything different than what the spec says now, but i have only skimmed so far
  245. # [12:10] <Lachy> othermaciej, draggable has 3 states and uses true and false, and omitted as the 3rd state
  246. # [12:10] <Hixie> it's all in my video bucket
  247. # [12:10] <jgraham> Wouldn't "missing attribute" do for the auto state?
  248. # [12:11] * jgraham hasn't caught up[ on the thread yet
  249. # [12:11] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) (Remote closed the connection)
  250. # [12:12] <othermaciej> Lachy: that's true - I'm not sure there needs to be an explicit way to say the same as the omitted state
  251. # [12:12] <othermaciej> I will try to summarize the thread into a bug when it settles down
  252. # [12:12] <Lachy> Hixie, if we keep the spec as is, then having autobuffer omitted must then mean no buffering. But that doesn't allow for browsers to provide sensible heuristic based approaches
  253. # [12:13] <othermaciej> what Lachy said - I think there needs to be a way to specifically hint "don't buffer" that's distinct from giving no hint at all
  254. # [12:13] <Hixie> what's the use case for that?
  255. # [12:14] <jgraham> "authors really want to conserve bandwidth"
  256. # [12:14] <Lachy> the main use case mentioned on the list has been a blog that includes a video as part of one of the entires, but the author doesn't think all users will want to watch the video just because the article still happens to be on the front page
  257. # [12:14] <Hixie> wouldn't that be all authors who don't want buffering?
  258. # [12:14] <jgraham> Hixie: ?
  259. # [12:15] * Joins: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  260. # [12:15] <Hixie> what's the distinction between the author who doesn't want buffering (and so doesn't set autobuffer) and the author who wants no buffering (and so sets nobuffer)?
  261. # [12:15] <zcorpan_> MikeSmithX: <style><!--> opens an escape in opera
  262. # [12:16] <jgraham> Hixie: The author that doesn't set autobuffer may still get buffering if the browser so choses
  263. # [12:16] <Lachy> the difference is that the omitted attribute doesn't give a clear indication of author preference, and so browsers should be allowed to optimise for the best user experience
  264. # [12:17] <othermaciej> Hixie: authors who don't think about the issue likely won't include any particular attribute, thus the browser might choose to guess whether buffering would be good based on things like number of videos on the page, their prominence and relative size, etc
  265. # [12:17] * Joins: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com)
  266. # [12:18] <Lachy> e.g. If I'm on a high speed connection with no bandwidth limits, as I am here in Norway, then I wouldn't mind having my browser autobuffer for me automatically on most sites. However, if I'm stuck in Australia on a slow, usage-capped connection then I'd prefer not to unless I really wanted to watch the video
  267. # [12:18] <othermaciej> Hixie: except that you can't distinguish "no opinion" from "specifically don't want buffering"
  268. # [12:18] <othermaciej> with the current spec design
  269. # [12:18] <doublec> how would the browser know you're on a usage capped connection?
  270. # [12:18] <Hixie> jgraham: the author who does set an explicit nobuffer may still get buffering if the browser so choses
  271. # [12:18] <Lachy> doublec, probably user preference
  272. # [12:19] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 60 (Operation timed out))
  273. # [12:19] <Hixie> Lachy: browsers should always be allowed to optimise for the best user experience, whatever attributes are set
  274. # [12:19] <Hixie> othermaciej: is that a hypothetical or are browsers really doing that?
  275. # [12:19] * hsivonen considers pay per byte deals a bug
  276. # [12:20] <othermaciej> Hixie: I'd like to make Safari do that, if I could
  277. # [12:20] <doublec> I'm a fan of no attribute - author doesn't want to buffer, with attribute = author does want to buffer, and the browser can override if it feels necessary
  278. # [12:20] <Philip`> hsivonen: What about pay-per-month-with-3GB-per-month-cap?
  279. # [12:20] <doublec> but on the html mail list authors seemed to think this wasn't a good idea
  280. # [12:20] <othermaciej> if the spec remains as-is, then we'll probably either always buffer for autobuffer and never buffer when it's missing
  281. # [12:20] <hsivonen> Philip`: I consider that a bug, too
  282. # [12:20] <othermaciej> (unless we know we're on a limited connection or constrained-resource device in which case never buffer at all)
  283. # [12:20] <Philip`> hsivonen: (That and pay-per-byte seem to be the only mobile internet services available here)
  284. # [12:20] <hsivonen> Philip`: I approve of capping per second bandwidth, though
  285. # [12:20] <jgraham> Hixie: It seems reasonable to make that behaviour non-conforming as it may have a disproportionate impact on the authouring side (making bandwidth bills too high is <video> is used) so encouraging people to use a solution that doesn't allow unrequested autobuffering
  286. # [12:20] <Lachy> Hixie, sure, but that doesn't give the author an opt-out to conserve their own bandwidth. e.g. If I visit a site that embed's a video without specifying autobuffer, and my personal user preferences is to automatically buffer the video anyway, that doesn't allow the author to tell the browser not to
  287. # [12:21] * hsivonen pays 9.90 EUR per month for 384 Kb/s without other caps
  288. # [12:22] <hsivonen> HSDPA/UMTS/EDGE/GPRS as supported by the tower
  289. # [12:22] <Hixie> well i'm very skeptical, but if implementations are going to use it i guess we can change autobuffer from a boolean attribute to autobuffer=always/never/etc (i.e. maybe adding other values in the future)
  290. # [12:22] * Quits: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 110 (Connection timed out))
  291. # [12:22] <Hixie> with the lack of an attribute being the "auto" case
  292. # [12:23] <Hixie> seems pretty silly though, why would anyone use a host where bandwidth was an issue?
  293. # [12:23] <hsivonen> Hixie: so autobuffer=never would buffer more than the lack of the attribute in Firefox 3.5
  294. # [12:23] <hsivonen> Hixie: seems like a pretty big fail
  295. # [12:23] <doublec> yes, you'd probably need to change the name
  296. # [12:23] <Hixie> hsivonen: doesn't matter, nobody is going to use video for ages anyway, plenty of time for ff4 to replace ff3.5
  297. # [12:23] <doublec> I still have a fair proportion of users watching video using Firefox 3.1 believe it or not
  298. # [12:23] <doublec> according to my logs
  299. # [12:24] <adactio> Just a reminder: this isn't just about video, it's also about audio (which I *would* like to use today).
  300. # [12:24] <hsivonen> Hixie: "ages" gets longer every time you move the earliest client deployment forward
  301. # [12:24] <Hixie> use of either audio or video is not going to take off until we have a common codec
  302. # [12:24] <Hixie> everything until then is peanuts
  303. # [12:24] <zcorpan_> can't we leave autobuffer alone and fix the bug in webkit?
  304. # [12:24] <hsivonen> aside: what's up with the On2 shareholders voting to adjourn repeatedly?
  305. # [12:25] <jgraham> zcorpan_: That is necessary but not sufficient
  306. # [12:25] <hsivonen> so much for getting the news in 2009Q4
  307. # [12:25] <Hixie> anyway it's way past my bedtime
  308. # [12:25] * Philip` uses a host with 30KB/s upload bandwidth because it's convenient to run a box at home, and wouldn't want people unnecessarily using up that bandwidth
  309. # [12:25] <Hixie> nn :-)
  310. # [12:25] <adactio> Hixie: not necessarily ...because I can put fallback content (such as a Flash player) inside the <audio> tags, the element is usable today, even if it isn't implemented in all browsers ...but the autobuffering question is the big sticking point.
  311. # [12:25] <Lachy> Hixie, consider YouTube providing embed code to authors, as they do now. I'm sure Google wouldn't want every page to begin auto buffering their videos. Currently, YouTube videos don't autobuffer on 3rd party sites.
  312. # [12:25] <zcorpan_> it's easy to say "no autobuffer": don't include the <video> at all
  313. # [12:25] <zcorpan_> until you want to play it
  314. # [12:26] <jgraham> zcorpan_: Well yes if you want to fuss about with js every time you include a video
  315. # [12:26] <Philip`> zcorpan_: Or use Flash
  316. # [12:26] <Lachy> zcorpan_, that requires mildly complex scripts to work around a bug that should be easily solveable with markup
  317. # [12:26] <Philip`> Those solutions harm the user experience, though
  318. # [12:26] <jgraham> Not really compatible with "copy this small fragment of markup to embed this video"
  319. # [12:31] * Quits: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Remote closed the connection)
  320. # [12:31] * Joins: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  321. # [12:34] * Joins: mpt (n=mpt@canonical/mpt)
  322. # [12:34] * Quits: csarven (n=csarven@ip157-77-212-87.adsl2.static.versatel.nl) ("Leaving.")
  323. # [12:38] <annevk> http://virtualdub.org/blog/pivot/entry.php?id=293
  324. # [12:39] <annevk> I had a similar experience trying to write an XML parser
  325. # [12:40] * Quits: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
  326. # [12:40] * smaug_ likes the comment "First, it's so much easier to work off of a spec that essentially fits on one page and doesn't have spaghetti hyperlinks" ;)
  327. # [12:42] <annevk> sniping from the sideline is easy; where's your spec?
  328. # [12:43] <annevk> :)
  329. # [12:43] <workmad3> yes, it's a lot easier to work off a spec that fits on one page
  330. # [12:43] <workmad3> normally because something that can be specced in one page is fairly simple to do :P
  331. # [12:45] <Philip`> Something that is specced in many more pages isn't necessarily inherently harder to do
  332. # [12:46] <Philip`> It might be just be specced in an overly complex way for your requirements
  333. # [12:46] <Philip`> s/be//
  334. # [12:46] <annevk> the other points in the post are the more interesting ones imo
  335. # [12:46] <Philip`> (Serialising a tree of strings really shouldn't be hard)
  336. # [12:48] <workmad3> Philip`: true, good points all
  337. # [12:49] <workmad3> I just find it funny when people come across things that are complex and complain that they are then difficult to implement... as if that wasn't frickin' obvious :)
  338. # [12:50] <annevk> well, for XML it isn't that obvious
  339. # [12:50] <annevk> because 50% of its features are almost never used
  340. # [12:51] <workmad3> true
  341. # [12:51] <annevk> but are still required for conforming implementations
  342. # [12:52] <hsivonen> does JSON have a parsing spec now?
  343. # [12:52] <hsivonen> regardless of whether the parsing spec fits on a page or has hyperlinks
  344. # [12:53] <annevk> I am a bit scared by his assertion that JSON mandates UTF-32
  345. # [12:53] <annevk> I hope that's a mistake
  346. # [12:54] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  347. # [12:55] <workmad3> annevk: I think he meant that the JSON parser spec mandates that the parser be able to understand UTF-32
  348. # [12:55] <workmad3> not that all JSON should be in utf-32 :)
  349. # [12:55] <annevk> Opera recently killed UTF-32 support
  350. # [12:55] <workmad3> hmm... lunch time
  351. # [12:55] <hsivonen> workmad3: what's "the parser spec"?
  352. # [12:55] <annevk> HTML5 recommends against UTF-32
  353. # [12:56] <annevk> and http://tools.ietf.org/html/rfc4627 mentions UTF-32 including how to detect it but does not seem to require it...
  354. # [12:56] <workmad3> http://www.ietf.org/rfc/rfc4627 <-- rfc for it
  355. # [12:56] <workmad3> there's also apparently a slightly different spec for JSON in the ECMAScript 5 spec
  356. # [12:56] <annevk> but then it never requires UTF-8 support or UTF-16 either
  357. # [12:56] <hsivonen> workmad3: looks like a partial syntax spec to me
  358. # [12:56] <annevk> maybe it does not have UA requirements
  359. # [12:56] <hsivonen> workmad3: see section 4 for spectacular underspecification
  360. # [12:59] <annevk> section 4 assumes the input stream is in Unicode
  361. # [12:59] <annevk> or something
  362. # [12:59] <annevk> so no encoding requirements there either
  363. # [12:59] <Lachy> annevk, section 3 also specifies "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.", so I guess that assumption is section 4 is reasonable
  364. # [13:00] * workmad3 is now known as wm3|lunch
  365. # [13:00] <Lachy> though, it mentions nothing about what to do with non-conforming streams
  366. # [13:00] <annevk> no, I mean that it assumes it is a character stream rather than a byte stream
  367. # [13:01] <annevk> there's no requirements about bytes to characters afaict
  368. # [13:04] <jgraham> FWIW I would regard the ES5 version of JSON as being "correct" rather than the RFC in as much as the differences are deliberate and reagrded as bug fixes
  369. # [13:04] * Joins: nessy (n=Adium@124-171-24-116.dyn.iinet.net.au)
  370. # [13:04] <jgraham> (but that is, I guess, less likely to be helpful with encoding issues)
  371. # [13:29] * Joins: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net)
  372. # [13:32] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
  373. # [13:38] <gsnedders> Well, the ES5 section assumes the same as the rest of ES5 wrt to text: you get an abstract Unicode stream with UTF-16 surrogates somehow.
  374. # [13:39] <hsivonen> jgraham: does ES5 say what to do with stream that don't match the grammar?
  375. # [13:43] * Joins: Rik` (n=Rik`@ARennes-352-1-91-155.w86-195.abo.wanadoo.fr)
  376. # [13:47] <gsnedders> hsivonen: It throws SyntaxError
  377. # [13:49] <jgraham> gsnedders: Right so it doesn't really cover standalone json
  378. # [13:49] * Quits: Rik` (n=Rik`@ARennes-352-1-91-155.w86-195.abo.wanadoo.fr)
  379. # [13:50] <gsnedders> Right, it defines the grammar, and the JSON object in ES
  380. # [13:50] <hsivonen> gsnedders: what about the open-ended permission to accept extensions in the RFC? does ES5 plug that hole?
  381. # [13:51] <gsnedders> hsivonen: For JSON.parse, anything that doesn't match the grammar throws SyntaxError, so for JSON.parse, yes.
  382. # [13:52] <hsivonen> cool
  383. # [13:52] <gsnedders> Speaking of ES, anyone found any bugs in Carakan?
  384. # [13:53] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) ("ChatZilla 0.9.86 [Firefox 3.5.6/20091215231754]")
  385. # [13:58] * Joins: Rik` (n=Rik`@ARennes-352-1-91-155.w86-195.abo.wanadoo.fr)
  386. # [14:06] <jgraham> gsnedders: I have :)
  387. # [14:06] <gsnedders> jgraham: NO WAI.
  388. # [14:10] * Joins: timz (n=mostrovo@dc51469cbe.adsl.wanadoo.nl)
  389. # [14:10] * Joins: annodomini (n=lambda@c-75-69-96-104.hsd1.nh.comcast.net)
  390. # [14:12] * Quits: Rik` (n=Rik`@ARennes-352-1-91-155.w86-195.abo.wanadoo.fr)
  391. # [14:14] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  392. # [14:24] <Philip`> gsnedders: Yes, but when I told you you told me you'd already tested everything, so I stopped looking :-p
  393. # [14:26] * Joins: pmuellr (n=pmuellr@nat/ibm/x-wzjrkriosherujsz)
  394. # [14:27] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  395. # [14:27] <jgraham> Philip`: You didn't tell me
  396. # [14:28] <jgraham> (or maybe you did and I just didn't read the logs)
  397. # [14:28] * wm3|lunch is now known as workmad3
  398. # [14:33] * Joins: MikeSmithXX (n=MikeSmit@EM114-49-10-205.pool.e-mobile.ne.jp)
  399. # [14:34] <gsnedders> jgraham: He told me and I said it was known
  400. # [14:36] <hsivonen> so now there's a bug saying that extensibility is bad for accessibility: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8619
  401. # [14:36] <hsivonen> (I agree, FWIW, that extenders making stuff up is bad for accessibility)
  402. # [14:37] <zcorpan> accessibility is bad for extensibility!
  403. # [14:37] * Quits: MikeSmithX (n=MikeSmit@EM114-48-9-107.pool.e-mobile.ne.jp) (Read error: 60 (Operation timed out))
  404. # [14:38] <annevk> it's not exactly clear what part of that section 8619 is addressing
  405. # [14:38] <annevk> the issue marker?
  406. # [14:40] <MikeSmithXX> zcorpan: so you don't want "<style><!--></style>" to be conforming, right?
  407. # [14:41] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  408. # [14:41] <zcorpan> MikeSmithXX: right
  409. # [14:41] * MikeSmithXX is now known as MikeSmith
  410. # [14:41] * paul_irish is now known as paul_irish_
  411. # [14:42] <MikeSmith> zcorpan: so you want a warning reported for <title><!--</title> and <textarea><!--</textarea> ?
  412. # [14:44] <zcorpan> MikeSmith: yes
  413. # [14:44] <zcorpan> MikeSmith: but not for <title>&lt;!--</title>
  414. # [14:45] <hsivonen> ouch
  415. # [14:45] <annevk> anyone have some charset tables handy?
  416. # [14:45] <annevk> if you send a FF byte through a HTTP header and it comes out as C3 BF
  417. # [14:45] <annevk> what happened?
  418. # [14:46] <MikeSmith> oh, &lt;!-- is a problem
  419. # [14:46] <annevk> decoded as UTF-8
  420. # [14:46] <annevk> that's what happened
  421. # [14:47] <annevk> maybe even transmitted as UTF-8 hmm
  422. # [14:49] <annevk> oh no duh
  423. # [14:49] <MikeSmith> zcorpan: I have a style-content checker live on qa-dev, including the title and textarea warnings
  424. # [14:50] <annevk> that's iso-8859-1
  425. # [14:50] <Philip`> Validators really don't seem like an ideal place to practice clean separation of layers in software architecture
  426. # [14:51] <Philip`> since their function is to deal with user errors, and erroneous users don't cleanly separate layers
  427. # [14:52] <MikeSmith> heh
  428. # [14:56] <annevk> bah
  429. # [14:56] <annevk> it seems iso-8859-1 is used in browsers for HTTP
  430. # [14:56] <annevk> instead of windows-1252 everywhere
  431. # [14:56] <annevk> lame
  432. # [14:57] <gsnedders> Opera trims on \x00 with HTTP headers
  433. # [14:57] <annevk> all browsers do
  434. # [14:57] <annevk> or maybe it's my server that does
  435. # [14:58] <gsnedders> Only Opera does.
  436. # [14:58] * gsnedders has tests for this
  437. # [14:58] <gsnedders> Probably server.
  438. # [14:58] <gsnedders> I had to write my own server to test a fair bit of stuff
  439. # [14:58] <zcorpan> MikeSmith: nice
  440. # [15:00] <annevk> gsnedders, hmm
  441. # [15:01] <MikeSmith> zcorpan: well, except failing for &lt!-- and --&gt; of course
  442. # [15:01] * Quits: MikeSmith (n=MikeSmit@EM114-49-10-205.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  443. # [15:02] <annevk> gsnedders, guess you're right
  444. # [15:02] <annevk> but then testing 00 is not really needed
  445. # [15:02] * Joins: MikeSmith (n=MikeSmit@EM114-49-10-205.pool.e-mobile.ne.jp)
  446. # [15:02] <annevk> WebKit is buggy here btw
  447. # [15:02] <annevk> or whatever HTTP impl Chrome is using is buggy
  448. # [15:03] <zcorpan> MikeSmith: and it checks in xhtml, which is a bit bogus (but per spec, i filed a spec bug iirc)
  449. # [15:03] <gsnedders> WebKit has no HTTP impl in it itself
  450. # [15:03] <gsnedders> That's platform specific
  451. # [15:03] <annevk> right
  452. # [15:03] <gsnedders> Chrome has its own
  453. # [15:03] <annevk> anyway, it's buggy
  454. # [15:03] <annevk> not necessarily platform
  455. # [15:03] <gsnedders> How so?
  456. # [15:03] <annevk> browser-specific
  457. # [15:03] <gsnedders> Well, WebKit port specific.
  458. # [15:03] <annevk> it decodes http using utf-8 or so
  459. # [15:04] <gsnedders> If they can get away with that, that's very interesting.
  460. # [15:04] <annevk> dunno
  461. # [15:04] <hsivonen> Opera 10.50 <video> support doesn't work nicely with Wikipedia :-(
  462. # [15:04] <gsnedders> I doubt it uses UTF-8 for everything
  463. # [15:04] <annevk> but FF ends up as EF BF BD rather than C3 8D
  464. # [15:05] <hsivonen> aside: shipping gstreamer with Opera on Windows looks like a pretty significant change to the previous way of Opera implementing everything from scratch in-house
  465. # [15:05] <annevk> and similar story for other characters above 7E
  466. # [15:05] <annevk> hsivonen, not really
  467. # [15:06] <annevk> hsivonen, though some things have changed I guess, we used to have an open source XML parser
  468. # [15:06] <annevk> we still use various external sources, but no longer that XML one
  469. # [15:06] <hsivonen> ok
  470. # [15:07] <annevk> OpenSSL and Zlib are prolly somewhat well-known
  471. # [15:07] <gsnedders> FreeType stuff is there too
  472. # [15:07] <hsivonen> gsnedders: on Windows?
  473. # [15:07] <gsnedders> Dunno. I'm just looking at opera:about ;P
  474. # [15:08] * Quits: MikeSmith (n=MikeSmit@EM114-49-10-205.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  475. # [15:08] * Joins: MikeSmith (n=MikeSmit@EM114-49-10-205.pool.e-mobile.ne.jp)
  476. # [15:09] <hsivonen> whoa. the menubar is gone in Opera 10.50 on Windows
  477. # [15:10] <annevk> also on Linux
  478. # [15:10] <hsivonen> Java seems to make Opera 10.50 on Windows awfully slow
  479. # [15:10] * Joins: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net)
  480. # [15:10] <gsnedders> I thought Java didn't work at all in 10.50 currently.
  481. # [15:10] <hsivonen> I wonder if using the cortado fallback for <video> is a good idea anymore
  482. # [15:11] <hsivonen> gsnedders: well, at least I think I had an applet in the tab I just closed
  483. # [15:12] <hsivonen> no tab resurrection with ctrl-shift-t it seems :-(
  484. # [15:13] * Joins: BlurstOfTimes (n=blurstof@168.203.117.66)
  485. # [15:13] <hsivonen> apparently the tab I thought had cortado in it instead was playing <video> without reaching cortado
  486. # [15:14] <hsivonen> what happened to the idea of making an Ogg/Theora/Vorbis/<video> signed ActiveX control for IE?
  487. # [15:15] * erlehmann_ is now known as erlehmann
  488. # [15:23] * Joins: hobertoAtWork4 (n=hobertoa@gw1.mcgraw-hill.com)
  489. # [15:24] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (niven.freenode.net irc.freenode.net)
  490. # [15:24] * Quits: foolip (n=philip@h-63-95.A163.priv.bahnhof.se) (niven.freenode.net irc.freenode.net)
  491. # [15:24] * Quits: hendry (n=hendry@webvm.net) (niven.freenode.net irc.freenode.net)
  492. # [15:24] * Quits: Philip` (n=philip@zaynar.co.uk) (niven.freenode.net irc.freenode.net)
  493. # [15:24] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  494. # [15:24] * Quits: gavin (n=gavin@firefox/developer/gavin) (niven.freenode.net irc.freenode.net)
  495. # [15:24] * Quits: kinetik (n=kinetik@121.98.132.55) (niven.freenode.net irc.freenode.net)
  496. # [15:24] * Quits: jcranmer (n=jcranmer@ltsp2.csl.tjhsst.edu) (niven.freenode.net irc.freenode.net)
  497. # [15:24] * Quits: doublec (n=doublec@li30-216.members.linode.com) (niven.freenode.net irc.freenode.net)
  498. # [15:24] * Quits: mitsuhiko (n=mitsuhik@ubuntu/member/mitsuhiko) (niven.freenode.net irc.freenode.net)
  499. # [15:24] * Quits: syp (n=syp@lasigpc9.epfl.ch) (niven.freenode.net irc.freenode.net)
  500. # [15:24] * Joins: syp_ (n=syp@lasigpc9.epfl.ch)
  501. # [15:24] * Joins: hendry_ (n=hendry@webvm.net)
  502. # [15:24] * Joins: doublec (n=doublec@li30-216.members.linode.com)
  503. # [15:24] * Joins: jcranmer (n=jcranmer@ltsp2.csl.tjhsst.edu)
  504. # [15:24] * Joins: Philip` (n=philip@zaynar.co.uk)
  505. # [15:24] * Joins: foolip (n=philip@79.136.63.95)
  506. # [15:24] * Joins: kinetik (n=kinetik@121.98.132.55)
  507. # [15:24] * Joins: hsivonen (n=hsivonen@130.233.41.50)
  508. # [15:24] * Joins: AryehGregor (n=Simetric@cpe-68-175-61-233.nyc.res.rr.com)
  509. # [15:24] * Joins: gavin (n=gavin@people.mozilla.com)
  510. # [15:24] * Joins: mitsuhiko_ (n=mitsuhik@hammett.srv.pocoo.org)
  511. # [15:27] <gsnedders> hsivonen: ctrl-z should undo closing tabs
  512. # [15:28] * Joins: miketaylr (n=miketayl@38.117.156.163)
  513. # [15:28] <hsivonen> gsnedders: that's an odd use of ctrl-z!
  514. # [15:29] <MikeSmith> maybe for reporting on "<!--" in <style> it can only reported as a warning, "Content *appears to* contain the character sequence <!-- without a later occurrence of the character sequence -->"
  515. # [15:29] * Joins: Huvet (n=Emil@c-2fc1e555.07-131-73746f39.cust.bredbandsbolaget.se)
  516. # [15:30] <Huvet> ok, I'm definately going crazy... can't I make html5lib remove everything but divs when parsing?
  517. # [15:30] <Huvet> there's some kind of patch here: http://code.google.com/p/html5lib/issues/detail?id=62
  518. # [15:30] <hsivonen> MikeSmith: do you mean title and textarea?
  519. # [15:30] * Quits: jcranmer (n=jcranmer@ltsp2.csl.tjhsst.edu) (Read error: 104 (Connection reset by peer))
  520. # [15:30] <MikeSmith> hsivonen: yeah
  521. # [15:30] <Huvet> but that seems rejected, and the fifth comment posts some code, that I can't get to work
  522. # [15:31] <MikeSmith> I guess it's a warning already.. myabe just need to tweek the wording
  523. # [15:32] <MikeSmith> hsivonen: hmm, what about the case of <style> also?
  524. # [15:32] * Joins: jcranmer (n=jcranmer@ltsp1.csl.tjhsst.edu)
  525. # [15:33] <hsivonen> MikeSmith: in style it could be straightforward to implement it as an error, right?
  526. # [15:34] <MikeSmith> I just tested and "&lt;" is getting interpreted by v.nu as "<"
  527. # [15:34] <MikeSmith> in style also
  528. # [15:34] <hsivonen> whoa
  529. # [15:34] <hsivonen> that's a bug
  530. # [15:35] <MikeSmith> seems so
  531. # [15:36] <hsivonen> odd. I don't see the bug in Gecko
  532. # [15:41] <MikeSmith> hsivonen: maybe a problem in how I implemented the check?
  533. # [15:42] <annevk> hsivonen, what would you use instead of ctrl+z ?
  534. # [15:42] <annevk> i learned it by trying ctrl+z :)
  535. # [15:42] <TabAtkins> annevk: Alt+Home, and click on "Recently Closed Tabs".
  536. # [15:43] <hsivonen> MikeSmith: that's possible
  537. # [15:43] <hsivonen> annevk: ctrl-shift-t :-)
  538. # [15:43] <MikeSmith> hsivonen: because when I test with http://c.validator.nu/debug/ set, I get "Warning: Characters: &lt;--." as expected, instead of "Warning: Characters: <".
  539. # [15:44] <hsivonen> I expect ctrl-z to undo the last modification I've made to the content of the frontmost tab
  540. # [15:44] <hsivonen> MikeSmith: very odd
  541. # [15:44] <hsivonen> MikeSmith: it's possible that V.nu and Gecko are out of sync
  542. # [15:44] <annevk> TabAtkins, ctrl+z seems easier
  543. # [15:44] <annevk> hsivonen, heh
  544. # [15:45] <MikeSmith> hsivonen: fwiw, I just implemented it using the existing TextContentHandler and corresponding new datatype
  545. # [15:45] <TabAtkins> annevk: But what if you're editting a textarea in that tab? Then there's a conflict in what should be Undone.
  546. # [15:45] <MikeSmith> and the new datatype class just gets the character stream same as any other
  547. # [15:46] <annevk> they don't need to be mutually exclusive
  548. # [15:46] <annevk> e.g. tabs could just be put on the stack
  549. # [15:46] <annevk> not sure how it actually works in Opera
  550. # [15:46] <annevk> I only ever use it when I press ctrl+w per accident
  551. # [15:47] * Joins: jcranmer_ (n=jcranmer@ltsp2.csl.tjhsst.edu)
  552. # [15:47] <annevk> (Opera puts them on a stack)
  553. # [15:47] <gsnedders> TabAtkins: They're both just events in the stack
  554. # [15:47] <gsnedders> TabAtkins: There's nothing magic about tabs being closed
  555. # [15:47] <annevk> (though some things are global-stack and some are page-stack)
  556. # [15:48] * jgraham has a weird mix of expectations about how undo close tab should work
  557. # [15:49] <TabAtkins> gsnedders: (a) what Anne just said about the different stacks. (b) There's still a mental conflict. If I close something and then turn to my textarea and realize I need to undo what I just wrote, I'll be surprised when I reopen the old tab.
  558. # [15:49] <jgraham> I think I expect a unique undo command for tabs but avaliable from the edit menu
  559. # [15:51] * gsnedders wants how to cope with TOCs is different forms in Anolis
  560. # [15:51] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  561. # [15:51] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  562. # [15:51] <gsnedders> s/wants/wonders/
  563. # [15:52] <gsnedders> Like, coping with multi-file TOCs, single-file TOCs, TOCs just for the current section, just of one level...
  564. # [15:52] <gsnedders> TOCs just for the current section I think I can probably ignore
  565. # [15:53] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  566. # [15:53] * Quits: jcranmer (n=jcranmer@ltsp1.csl.tjhsst.edu) ("leaving")
  567. # [15:53] * Quits: cedricv (n=cedric@112.199.233.48) (Remote closed the connection)
  568. # [15:53] * jcranmer_ is now known as jcranmer
  569. # [15:54] * Joins: cedricv (n=cedric@112.199.233.48)
  570. # [15:56] * Joins: aroben (n=aroben@unaffiliated/aroben)
  571. # [15:57] <jgraham> gsnedders: Why do you need any of that?
  572. # [15:58] <gsnedders> Also, if anyone is interested, html5lib tip is no quicker at parsing the complete spec in unladen than it is in normal CPython
  573. # [15:58] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  574. # [15:59] <gsnedders> jgraham: Multi-doc TOC: see http://w3.org/TR/CSS21/; just for a certain section: see some section of CSS 2.1, the TOC in HTML 5
  575. # [15:59] <jgraham> gsnedders: We should put together a benchmark and then try to get the unladen people to use it ;)
  576. # [15:59] <gsnedders> Flexibility of depth: see the short TOC in HTML 5
  577. # [16:00] <zcorpan> hsivonen: what doesn't work nice with video on wikipedia?
  578. # [16:00] <hsivonen> zcorpan: clicking the browser-native play button doesn't start playing soon
  579. # [16:01] <hsivonen> then if I come back later, the video has played to the last frame, but pressing the button again doesn't restart it
  580. # [16:01] <zcorpan> the latter issue is probably because seeking doesn't work yet
  581. # [16:01] <hsivonen> ah
  582. # [16:02] <zcorpan> is there a url i can use to test the first issue?
  583. # [16:03] <hsivonen> zcorpan: http://en.wikipedia.org/wiki/Groundhog
  584. # [16:03] <hsivonen> hmm. it could be a server problem
  585. # [16:03] <hsivonen> but Firefox gives more useful feedback while it is waiting for the server
  586. # [16:04] * Quits: cedricv (n=cedric@112.199.233.48) (Remote closed the connection)
  587. # [16:04] <zcorpan> indeed
  588. # [16:05] <zcorpan> (it plays fine for me)
  589. # [16:07] * Joins: cedricv (n=cedric@112.199.233.48)
  590. # [16:07] * Quits: nessy (n=Adium@124-171-24-116.dyn.iinet.net.au) ("Leaving.")
  591. # [16:08] <zcorpan> MikeSmith: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8567 was the spec bug
  592. # [16:10] * MikeSmith looks
  593. # [16:11] * Joins: mpt_ (n=mpt@canonical/mpt)
  594. # [16:11] <zcorpan> MikeSmith: can't <!-- checking be in the tokenizer instead?
  595. # [16:12] <hsivonen> zcorpan: it could--by adding more states
  596. # [16:12] <zcorpan> true
  597. # [16:13] * gsnedders fixes more issues in html5lib
  598. # [16:13] <zcorpan> might also get messy with the <!--> thing
  599. # [16:13] <MikeSmith> but it seems like it would be only useful for conformance checkers, not for other uses of the tokenizer/parser
  600. # [16:13] <jgraham> gsnedders: I have a local patch that fixes something
  601. # [16:14] <jgraham> I just don't recall what
  602. # [16:14] <jgraham> (not the thing that you just pushed at least)
  603. # [16:14] <zcorpan> i don't care overly about title/textarea; checking script and style is most important
  604. # [16:15] <zcorpan> my research showed that people don't use <!-- in title or textarea, so it might be pointless to check them
  605. # [16:18] <jgraham> gsnedders: Oh it was to raise a DeprecationWarning when the BS treebuilder is used
  606. # [16:19] <gsnedders> Ah
  607. # [16:21] * Quits: archtech (i=stanv@83.228.56.37) (Read error: 113 (No route to host))
  608. # [16:22] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  609. # [16:22] <annevk> how the hell do you get access to request headers in python?
  610. # [16:23] * Quits: weinig (n=weinig@c-71-198-185-234.hsd1.ca.comcast.net)
  611. # [16:23] <annevk> where is the basic http interaction tutorial that does not involve making requests from Python?
  612. # [16:23] <annevk> i can never find it
  613. # [16:23] <annevk> never
  614. # [16:23] * annevk is just a little frustrated with his lack of luck
  615. # [16:23] <annevk> I could do it in PHP, but I wanna move away from that at some point...
  616. # [16:24] <jgraham> Well if you need the raw unprocessed stuff and are using CGI you presumably want os.environ
  617. # [16:27] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 113 (No route to host))
  618. # [16:28] * mitsuhiko_ is now known as mitsuhiko
  619. # [16:32] <annevk> and how do you get headers out of that?
  620. # [16:32] <annevk> environment variables do not exactly appear to be documented :/
  621. # [16:32] <annevk> os.environ has not a single pointer ?!
  622. # [16:34] <Philip`> CGI doesn't pass raw unprocessed stuff
  623. # [16:34] * Quits: payman` (n=payman@193.170.48.62) ("Leaving")
  624. # [16:34] <Huvet> can I trust that the document is properly nested (all StartTags have an EndTag) in a subclass to HTMLSanitazion (while overriding sanitize_token)?
  625. # [16:35] <Philip`> It just gives you environment variables like HTTP_CONTENT_TYPE and HTTP_X_FOO_BAR etc, parsed from the headers
  626. # [16:35] * mpt_ is now known as mpt
  627. # [16:35] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  628. # [16:35] <Huvet> hmm... I guess not... because only the tree I get from html5lib is properly nested...
  629. # [16:35] <Huvet> i guess
  630. # [16:36] <annevk> Philip`, if I set a header test I do not get it back with HTTP_TEST
  631. # [16:37] <annevk> or HTTP_test or HTTP_X_TEST
  632. # [16:37] <gsnedders> Huvet: Dunno whether <img> will give both
  633. # [16:37] <Philip`> Huvet: Sounds like that's working at the tokenizer level, so there's no nesting fixups or guarantees
  634. # [16:38] <Huvet> thanks, that figures
  635. # [16:38] <Philip`> annevk: What if you set a header X-Test?
  636. # [16:38] <annevk> never mind
  637. # [16:38] <annevk> I fail
  638. # [16:38] <annevk> forgot to import os
  639. # [16:38] <annevk> though also Python fail for not throwing server errors
  640. # [16:39] <annevk> imo
  641. # [16:39] <annevk> cheerio
  642. # [16:39] <MikeSmith> hsivonen: fyi, the problem was I was seeing with &lt!-- was just a stupid oversight in the code I added
  643. # [16:39] <MikeSmith> fixed now
  644. # [16:39] <MikeSmith> sorry for the noise
  645. # [16:39] <Philip`> annevk: import cgitb
  646. # [16:39] <Philip`> or something like that
  647. # [16:39] <Philip`> to get error reports
  648. # [16:40] <gsnedders> jgraham: So, we need some file that takes a second or two to parse
  649. # [16:40] <Philip`> gsnedders: I suggest the first n lines of the HTML5 spec
  650. # [16:42] * MikeSmith takes a break
  651. # [16:42] * Quits: erlehmann (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net) ("Ex-Chat")
  652. # [16:42] <hsivonen> MikeSmith: ok
  653. # [16:44] <MikeSmith> hsivonen: btw, what's the rationale for having the error messages in TextContentHandler also report the namespace?
  654. # [16:44] <MikeSmith> e.g., "The text content of element style from namespace http://www.w3.org/1999/xhtml was not in the required format"
  655. # [16:44] <hsivonen> MikeSmith: consistency with way Jing reports stuff, IIRC
  656. # [16:45] <jgraham> import cgitb; cgitb.enable()
  657. # [16:45] * Philip` wonders if somebody is going to make a user-friendly validator frontend that gives more understandable error messages
  658. # [16:45] <MikeSmith> hsivonen: I see
  659. # [16:46] <jgraham> But you will get errors in /var/log/apache2/error.log or similar if the import failed
  660. # [16:46] <MikeSmith> but it's not consistent with how v.nu reports stuff
  661. # [16:46] * Quits: myakura (n=myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  662. # [16:47] <annevk> for setRequestHeader() it seems browsers just go for UTF-8 octets?
  663. # [16:47] <annevk> hmm
  664. # [16:47] <Philip`> (Seems like there's an opportunity to match the low-level validator output against patterns from common user errors, and give more high-level advice about what the problem is and how to fix it)
  665. # [16:48] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
  666. # [16:51] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  667. # [16:52] <MikeSmith> Philip`: that would involve some guessing about the root cause of the user error, right?
  668. # [16:54] * Joins: cohitre (n=cohitre@64-40-56-46-dsl.itltd.net)
  669. # [16:54] * Joins: erlehmann (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net)
  670. # [16:54] <MikeSmith> Philip`: anyway, if I understand you correctly, hsivonen has some of that already in the htmlparser error messages
  671. # [16:55] * Parts: cohitre (n=cohitre@64-40-56-46-dsl.itltd.net)
  672. # [16:55] <Philip`> MikeSmith: Call it "heuristics" rather than "guessing" :-)
  673. # [16:55] <MikeSmith> heh
  674. # [16:55] <Philip`> and have it informed by statistics
  675. # [16:56] <MikeSmith> Philip`: first part of many htmlparser error messages reports what the actual error is, then the last part reports, "Probable cause: ..."
  676. # [16:57] <Philip`> MikeSmith: Is that ever based on patterns of more than one error message?
  677. # [16:58] <MikeSmith> Philip`: no, I don't think so, not currently
  678. # [16:58] * Philip` hasn't actually used the validator enough to know whether those problems occur much and could be reported better, so he's just making this all up and could be completely wrong
  679. # [16:59] * Philip` imagines it's harder when you have to actually implement it
  680. # [16:59] <MikeSmith> basing reporting on patterns of more than one error condition would seem to require keeping a lot of state information around about what errors have already occurred
  681. # [17:00] <Philip`> Sure
  682. # [17:00] <Philip`> Memory is cheap :-)
  683. # [17:00] <MikeSmith> heh
  684. # [17:01] * Quits: pmuellr (n=pmuellr@nat/ibm/x-wzjrkriosherujsz)
  685. # [17:01] <MikeSmith> OK, I gotta get some food
  686. # [17:01] <MikeSmith> bbiab
  687. # [17:02] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  688. # [17:03] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  689. # [17:06] * Joins: Heimidal (n=heimidal@cpe-76-168-254-92.socal.res.rr.com)
  690. # [17:07] * Joins: pmuellr (n=pmuellr@nat/ibm/x-wjjpoluqpdhzrmhb)
  691. # [17:11] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) (Remote closed the connection)
  692. # [17:12] * Joins: pmuellr_ (n=pmuellr@nat/ibm/x-xjlxsfmjolekqbox)
  693. # [17:13] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  694. # [17:14] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
  695. # [17:16] * Joins: danbri (n=danbri@unaffiliated/danbri)
  696. # [17:27] * Quits: pmuellr (n=pmuellr@nat/ibm/x-wjjpoluqpdhzrmhb) (Read error: 110 (Connection timed out))
  697. # [17:27] * pmuellr_ is now known as pmuellr
  698. # [17:34] <MikeSmith> Philip`: what you describe could be implemented in a third-party app that consumes output from v.nu
  699. # [17:45] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  700. # [17:45] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  701. # [17:52] * Joins: abernier (n=abernier@nor75-28-88-183-29-231.fbx.proxad.net)
  702. # [17:58] * hendry_ is now known as hendry
  703. # [18:04] * Joins: jwalden (n=waldo@70.131.131.131)
  704. # [18:06] * Joins: Lachy (n=Lachlan@85.196.122.246)
  705. # [18:08] * Quits: onar (n=onar@17.226.20.255)
  706. # [18:15] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  707. # [18:20] * Quits: sebmarkbage (n=miranda@213.80.108.29) (Read error: 104 (Connection reset by peer))
  708. # [18:21] <abernier> html5 introduces new elements like <header>, <footer>, <nav>, ... is it a good idea for html4 authoring to replace them by <div class="(header|footer|nav)" ?
  709. # [18:22] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Read error: 60 (Operation timed out))
  710. # [18:25] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) ("ChatZilla 0.9.86 [Firefox 3.5.6/20091215231754]")
  711. # [18:27] * Quits: scherkus (n=scherkus@74.125.59.73) ("lol")
  712. # [18:36] * Joins: scherkus (n=scherkus@74.125.59.65)
  713. # [18:36] * Joins: ap (n=ap@17.246.19.5)
  714. # [18:39] <AryehGregor> abernier, doesn't really matter, unless it will make transition easier or something.
  715. # [18:40] <AryehGregor> abernier, the point of the new elements is to add standardized semantics, you don't get those in HTML4 for these elements either way.
  716. # [18:41] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 60 (Operation timed out))
  717. # [18:41] <abernier> AryehGregor: yes, and adding semantics through class attributes is a quite common concept, no?
  718. # [18:42] * Joins: maikmerten (n=maikmert@port-92-201-4-178.dynamic.qsc.de)
  719. # [18:42] * Joins: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  720. # [18:43] * Joins: dglazkov (n=dglazkov@nat/google/x-cwpcvvgwggiwgfzc)
  721. # [18:43] * Quits: cedricv (n=cedric@112.199.233.48) (Read error: 60 (Operation timed out))
  722. # [18:46] * Quits: Phae (n=phaeness@gateb.thls.bbc.co.uk)
  723. # [18:50] <AryehGregor> abernier, but they aren't standardized semantics. Nothing other than your own page is going to treat <div class="header"> any differently from <div class="snafflefloozer">. For all any third-party semantics-inferring tool knows, you prefer to call your headers snafflefloozers and vice versa. So there's no reason to use one over the other except personal preference/legibility/etc.
  724. # [19:02] * Joins: weinig (n=weinig@17.246.18.80)
  725. # [19:03] * Joins: daedb_ (n=daed@h11n1fls34o986.telia.com)
  726. # [19:04] <AryehGregor> I know users underestimate how much effort development takes, but this is still a pretty impressive statement: ". . . I want everything perfect and without any flaws. Is that to much to ask ?" http://code.google.com/p/chromium/issues/detail?id=16482
  727. # [19:12] * Joins: cying (n=cying@70.90.171.153)
  728. # [19:15] * AryehGregor supposes that when open-source software takes over the world, users will interact with developers more and have a better understanding of how much effort it takes to implement something well.
  729. # [19:15] * Quits: danbri (n=danbri@unaffiliated/danbri) (Remote closed the connection)
  730. # [19:20] * Joins: danbri (n=danbri@unaffiliated/danbri)
  731. # [19:21] * Quits: daedb (n=daed@h11n1fls34o986.telia.com) (Read error: 110 (Connection timed out))
  732. # [19:23] * Joins: dimich (n=dimich@74.125.59.65)
  733. # [19:26] * Parts: adactio (n=adactio@host213-123-197-180.in-addr.btopenworld.com)
  734. # [19:28] * daedb_ is now known as daedb
  735. # [19:30] * Joins: jwalden_ (n=waldo@adsl-70-131-131-131.dsl.emhril.sbcglobal.net)
  736. # [19:31] * Quits: jwalden (n=waldo@70.131.131.131) (Read error: 113 (No route to host))
  737. # [19:31] * jwalden_ is now known as jwalden
  738. # [19:42] * Quits: vvv (n=vvv@mediawiki/VasilievVV) ("KVIrc Insomnia 4.0.0, revision: 3410, sources date: 20090703, built on: 2009/08/12 22:29:13 UTC http://www.kvirc.net/")
  739. # [19:43] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  740. # [19:46] * Joins: ttepasse (n=ttepas--@ip-95-222-120-117.unitymediagroup.de)
  741. # [19:59] <smaug_> so what is the current way to get changes to the draft; do I always need to file bugs @w3c or is the old way (send email to whatwg) still enough?
  742. # [19:59] <smaug_> Hixie: ^^^
  743. # [20:05] <gsnedders> smaug_: either
  744. # [20:05] <smaug_> ok, thanks
  745. # [20:14] * Joins: jorlow (n=jorlow@nat/google/x-zwkypjucygexmvgi)
  746. # [20:14] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  747. # [20:14] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  748. # [20:14] * Quits: erlehmann (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net) ("Ex-Chat")
  749. # [20:14] * Joins: erlehmann (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net)
  750. # [20:17] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  751. # [20:20] <jgraham> gsnedders: BTW I know a blog engine that always uses a proper serializer
  752. # [20:20] <gsnedders> jgraham: NAmely?
  753. # [20:20] <jgraham> http://code.cmlenz.net/diva/wiki/Divan
  754. # [20:21] <jgraham> It fails on "easy to set up and use" though
  755. # [20:21] <jgraham> (but you didn't list those as requirments)
  756. # [20:22] <jgraham> (in particular you need an atompub client to create/edit entires)
  757. # [20:22] <jgraham> (and you need couchdb which is not trivial to run in all hosting situaions)
  758. # [20:25] <Philip`> "Seriously: You probably don't want to be using this."
  759. # [20:25] <Philip`> (on the framework for which Divan is an example application)
  760. # [20:25] <Philip`> That doesn't sound entirely promising
  761. # [20:26] * Joins: dave_levin (n=dave_lev@74.125.59.73)
  762. # [20:30] * Quits: erlehmann (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net) ("Ex-Chat")
  763. # [20:32] * Joins: MikeSmithX (n=MikeSmit@EM114-48-135-69.pool.e-mobile.ne.jp)
  764. # [20:33] * Joins: archtech (i=stanv@83.228.56.37)
  765. # [20:36] * Quits: MikeSmith (n=MikeSmit@EM114-49-10-205.pool.e-mobile.ne.jp) (Nick collision from services.)
  766. # [20:36] * MikeSmithX is now known as MikeSmith
  767. # [20:38] * Joins: othermaciej (n=mjs@17.203.15.164)
  768. # [20:40] * Quits: smaug_ (n=chatzill@cs181150024.pp.htv.fi) ("ChatZilla 0.9.86 [Firefox 3.7a1pre/20091230113157]")
  769. # [20:41] * Joins: erlehmann (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net)
  770. # [20:43] * Quits: archtech (i=stanv@83.228.56.37) (Client Quit)
  771. # [20:47] * Joins: bfrohs (n=chatzill@75-134-215-82.dhcp.trcy.mi.charter.com)
  772. # [20:49] * Joins: sebmarkbage (n=miranda@213.80.108.29)
  773. # [20:51] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  774. # [20:57] * Quits: erlehmann (n=erlehman@dslb-188-102-052-202.pools.arcor-ip.net) ("Ex-Chat")
  775. # [21:13] * Joins: KevinMarks (n=KevinMar@157.22.22.46)
  776. # [21:14] * Quits: weinig (n=weinig@17.246.18.80)
  777. # [21:15] * Joins: weinig (n=weinig@17.246.18.80)
  778. # [21:16] * aroben is now known as aroben|lunch
  779. # [21:25] * Quits: aroben|lunch (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  780. # [21:25] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
  781. # [21:29] * Quits: zalan (n=zalan@catv-89-135-144-122.catv.broadband.hu)
  782. # [21:37] * Joins: archtech (i=stanv@83.228.56.37)
  783. # [21:40] <gsnedders> Oooo, MS have joined SVG WG.
  784. # [21:48] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) ("Leaving...")
  785. # [21:53] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  786. # [21:55] * Quits: maikmerten (n=maikmert@port-92-201-4-178.dynamic.qsc.de) (Read error: 104 (Connection reset by peer))
  787. # [21:56] * Joins: BlurstOfTimes (n=blurstof@168.203.117.66)
  788. # [21:57] * Quits: cying (n=cying@70.90.171.153) (Read error: 54 (Connection reset by peer))
  789. # [21:57] * Joins: cying (n=cying@70.90.171.153)
  790. # [22:07] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  791. # [22:08] * aroben_ is now known as aroben
  792. # [22:11] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  793. # [22:12] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  794. # [22:16] * Joins: franksalim (n=frank@adsl-76-221-202-115.dsl.pltn13.sbcglobal.net)
  795. # [22:17] <Dashiva> "If I'm designing an XML vocabulary, I usually like to associate a namespace with my vocabulary, as it gives a feeling to me, that this vocabulary belongs to me"
  796. # [22:17] <bfrohs> Could someone give me insight as to why two margins are appearing? - http://frohsenwebdesign.com/projects/css3-tests/multiple-floats-and-margin.html
  797. # [22:18] <AryehGregor> bfrohs, what do you mean, two margins?
  798. # [22:19] <bfrohs> Go to the link (refresh if you went to immediately). I have a top margin of 50 px set to the second element in each group
  799. # [22:19] <bfrohs> It appears between the first and second element as well as above the first element
  800. # [22:19] * AryehGregor is intrigued by the seemingly random use of <section> and <aside> instead of <div> here
  801. # [22:20] <bfrohs> It's from a website I'm working on... basically removed pieces of code until it was the bare minimum - didn't take the time to change things.
  802. # [22:21] <AryehGregor> What browser are you testing in?
  803. # [22:21] <AryehGregor> It looks very different between Firefox and Chrome.
  804. # [22:21] <bfrohs> Firefox 3.5, 3.6, and 3.7 on ubuntu
  805. # [22:21] <bfrohs> Yes, that's why I'm confused
  806. # [22:21] <bfrohs> Hoping someone has insight here
  807. # [22:22] <AryehGregor> Tried #css?
  808. # [22:22] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  809. # [22:22] <bfrohs> On freenode?
  810. # [22:23] <AryehGregor> Yes.
  811. # [22:23] <AryehGregor> Curious.
  812. # [22:23] <bfrohs> Nope - will do now. I'm not one to use IRC
  813. # [22:24] <AryehGregor> . . . you're using IRC.
  814. # [22:24] <AryehGregor> You can make a more minimal test case, by the way.
  815. # [22:24] <AryehGregor> A lot of the stuff you have is still extraneous.
  816. # [22:24] <AryehGregor> Would be easier to understand if you only had like three elements there, and a minimal set of rules.
  817. # [22:26] <bfrohs> The problem only occurs with floats - hence the multiple floats... and the first rules (before /*important*/) are purely cosmetic
  818. # [22:27] <AryehGregor> You can get rid of a lot of elements, like the .layout > aside.
  819. # [22:27] <AryehGregor> Would make things simpler to look at.
  820. # [22:27] <jgraham> cosmetics have no place in testcases :)
  821. # [22:27] <AryehGregor> You have relative positioning, etc., all extraneous.
  822. # [22:28] * Joins: svl_ (n=me@ip565744a7.direct-adsl.nl)
  823. # [22:28] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  824. # [22:28] <bfrohs> Alright, thanks. I'll take care of that now :)
  825. # [22:29] * Quits: archtech (i=stanv@83.228.56.37) (Client Quit)
  826. # [22:29] <Philip`> Dashiva: If I'm designing an XML vocabulary, I like to prefix every element and attribute name with my name, so that I feel it belongs to me
  827. # [22:29] <Philip`> Also it means people can return it to me if I accidentally lose it somewhere
  828. # [22:30] * Quits: timz (n=mostrovo@dc51469cbe.adsl.wanadoo.nl) ("Leaving.")
  829. # [22:30] <Dashiva> Philip`: Or if it's stolen
  830. # [22:31] <Philip`> Dashiva: It wouldn't help in that case, the thieves would just strip off the obvious identifying marks
  831. # [22:31] <Dashiva> But then it wouldn't be stealing
  832. # [22:31] <Philip`> That's why I also hide my name steganographically in the first letter of every element and attribute name in the vocabulary
  833. # [22:31] <Dashiva> Since they wouldn't be my elements anymore
  834. # [22:35] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  835. # [22:37] * Joins: onar (n=onar@17.226.20.255)
  836. # [22:37] * svl_ is now known as svl
  837. # [22:41] * Quits: pmuellr (n=pmuellr@nat/ibm/x-xjlxsfmjolekqbox)
  838. # [22:48] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams) (Read error: 104 (Connection reset by peer))
  839. # [22:48] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  840. # [22:50] <bfrohs> If anyone wants an update to my problem from earlier regarding CSS in Firefox, it's a bug in the Gecko engine as far as anyone can tell. Thanks for the direction to #css ! :)
  841. # [22:54] <jgraham> bfrohs: I take it you will file a bug? :)
  842. # [22:54] <jgraham> (assuming there isn't one already)
  843. # [22:56] <bfrohs> jgraham: Aye, taking care of now.
  844. # [22:58] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  845. # [23:00] * Quits: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  846. # [23:01] * Joins: taf2 (n=taf2@pool-98-117-216-229.bltmmd.fios.verizon.net)
  847. # [23:02] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  848. # [23:02] * Quits: miketaylr (n=miketayl@38.117.156.163) (Remote closed the connection)
  849. # [23:03] <bfrohs> jgraham: https://bugzilla.mozilla.org/show_bug.cgi?id=537808 if you want it fixed
  850. # [23:10] <jwalden> bfrohs: generally, when filing bugs, you should create a self-contained testcase and upload it to the bug; a URL might change in the future (even if it's something you control -- what if you forget about the external reference?), so it's important to capture exactly what was there for permanent reference -- mind doing that?
  851. # [23:10] * Joins: egn (n=egn@li101-203.members.linode.com)
  852. # [23:10] <egn> hi, for an html5 media element, how would I signal it to stop buffering?
  853. # [23:10] <jwalden> inline external stylesheets, create data: URLs for images and such, etc.
  854. # [23:10] <annevk> not include the autobefuffer attribute
  855. # [23:10] <bfrohs> jwalden: yeah, I can. But the location is permanent... but I'll still do just in case.
  856. # [23:11] <annevk> egn, ^^
  857. # [23:11] <AryehGregor> Is the procedure for getting canconfirm or editbugs on Mozilla's Bugzilla still to e-mail Gerv?
  858. # [23:11] <jwalden> AryehGregor: that's one method; you thinking of asking?
  859. # [23:12] <AryehGregor> jwalden, yes. I seem to meet the requirements at <http://www.gerv.net/hacking/before-you-mail-gerv.html> for at least canconfirm.
  860. # [23:12] <AryehGregor> Bugs I've filed: https://bugzilla.mozilla.org/buglist.cgi?emailreporter1=1&emailtype1=exact&email1=Simetrical%2Bff@gmail.com
  861. # [23:12] <jwalden> AryehGregor: bugmail address?
  862. # [23:12] <jwalden> ah
  863. # [23:12] <AryehGregor> Simetrical+ff@gmail.com.
  864. # [23:12] <AryehGregor> I have one patch that's r+ and awaiting super-review, and a few other bugs with test-cases (mostly inline as data URLs).
  865. # [23:13] <jwalden> AryehGregor: fixed; bugzilla's administrative permissions are sufficiently fine-grained that there are probably at least a dozen or so people with ability to grant those
  866. # [23:13] <AryehGregor> jwalden, thanks.
  867. # [23:13] <egn> annevk: k, it's not autobuffering, but I need to be able to stop buffering after a play() happens. I think when I pause() it continues to buffer
  868. # [23:13] <jwalden> no problem
  869. # [23:13] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) ("Leaving...")
  870. # [23:13] <AryehGregor> MediaWiki just gives everyone editbugs, because we're crazy. \o/
  871. # [23:14] <AryehGregor> (Bugzilla actually works pretty well for that, surprisingly. Not much software does. It keeps good logs and nothing much is irreversible.)
  872. # [23:14] <roc> given that we've had to remove editbugs from people from time to time, that wouldn't work for us
  873. # [23:14] <jwalden> egn: buffering is really a quality-of-implementation issue for the client, except for the hinting mechanism (which may, but probably should not, be ignored)
  874. # [23:14] <AryehGregor> At that stage we usually just disable their account. :)
  875. # [23:14] <AryehGregor> Anyway, just a random comment.
  876. # [23:14] <Dashiva> AryehGregor: And if they create a new one?
  877. # [23:14] <roc> that's a good point
  878. # [23:14] <roc> Dashiva: that tends to not happen
  879. # [23:14] <AryehGregor> Dashiva, same as if they create a new wiki account.
  880. # [23:14] <roc> for some reason
  881. # [23:15] <AryehGregor> I mean, if they want to be disruptive they could also create a new account and write a script to file a constant stream of bugs with goatse hidden in them. Or even do it by hand.
  882. # [23:15] <roc> the exact limits of craziness and malice on the Internet are hard to understand
  883. # [23:15] <AryehGregor> Anyway, it's worked for us so far, although of course we have a much less active Bugzilla than Mozilla does.
  884. # [23:16] * jwalden wonders what gnome's bugzilla does, given that it might be the largest out there publicly these days
  885. # [23:20] <egn> jwalden: hm, k. is there any way I can just kill the media element which would stop the buffering after a play()?
  886. # [23:21] <jwalden> egn: not in a cross-browser manner, although disconnecting it from the DOM, making sure it's paused, and then nulling out any and all names and properties that refer to it will likely expedite the process
  887. # [23:22] <jwalden> garbage collection is perhaps the primary non-deterministic behavior on the web that will never be standardized
  888. # [23:22] <Philip`> egn: You could open lots of popup windows so the user gets annoyed enough to terminate their browser process
  889. # [23:23] * jwalden snickers
  890. # [23:23] <egn> jwalden: k, thanks
  891. # [23:25] * Parts: bfrohs (n=chatzill@75-134-215-82.dhcp.trcy.mi.charter.com)
  892. # [23:26] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  893. # [23:27] <roc> egn: if you remove the element from the DOM, it will automatically pause and IIRC we'll stop the download
  894. # [23:31] * Quits: franksalim (n=frank@adsl-76-221-202-115.dsl.pltn13.sbcglobal.net) ("Ex-Chat")
  895. # [23:31] * Joins: abernier_ (n=abernier@nor75-28-88-183-29-231.fbx.proxad.net)
  896. # [23:32] * Quits: abernier (n=abernier@nor75-28-88-183-29-231.fbx.proxad.net) (Read error: 60 (Operation timed out))
  897. # [23:32] * abernier_ is now known as abernier
  898. # [23:34] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  899. # [23:40] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  900. # [23:50] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  901. # Session Close: Tue Jan 05 00:00:00 2010

The end :)