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

Options:

  1. # Session Start: Sun Apr 29 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:24] * Joins: SpookyET (i=user@75.138.70.34)
  4. # [00:32] <zcorpan_> Hixie: "A date or time string is a valid date or time string if the following algorithm, when run on the string, doesn't say the string is invalid." does that mean that authors have to understand the algorithm in order to know how to write their date or time strings?
  5. # [00:35] * Joins: fax_machine (n=fax_mach@74-129-102-1.dhcp.insightbb.com)
  6. # [00:36] * Quits: SpookyET (i=user@75.138.70.34) ("Client Exiting")
  7. # [00:44] <Dashiva> "If second is not a number in the range 0 ≤ hour < 60, then fail."
  8. # [00:44] <Dashiva> Poor second, not even inside its own range
  9. # [00:45] * zcorpan_ is working on http://simon.html5.org/temp/author-view-of-html5.css
  10. # [00:47] <zcorpan_> it will be a very large ruleset that
  11. # [00:50] <zcorpan_> i hope this will help authors read and review the spec
  12. # [00:54] * moeffju is now known as moeffju[ZzZz]
  13. # [00:59] * Joins: om_sleep (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  14. # [01:01] <Philip`> zcorpan_: Looks like that might be a bit fragile when the spec changes...
  15. # [01:02] * om_sleep is now known as othermaciej
  16. # [01:04] <zcorpan_> Philip`: yes, like the status markers
  17. # [01:05] * Quits: weinig (n=weinig@odin.landmark.edu)
  18. # [01:08] <zcorpan_> having Hixie mark up status markers and what applies to authors or not is not useful use of his time... so if we can set up something that anyone can update it would be better
  19. # [01:10] * Joins: weinig (n=weinig@odin.landmark.edu)
  20. # [01:15] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  21. # [01:18] * Joins: aroben (n=adamrobe@adsl-70-231-231-70.dsl.snfc21.sbcglobal.net)
  22. # [01:19] * Quits: aroben (n=adamrobe@adsl-70-231-231-70.dsl.snfc21.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  23. # [01:19] * Joins: aroben (n=adamrobe@adsl-70-231-231-70.dsl.snfc21.sbcglobal.net)
  24. # [01:22] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne) ("k lol plz thx bai")
  25. # [01:26] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Remote closed the connection)
  26. # [01:26] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  27. # [01:40] * Quits: nlogax (n=nlogax@71-219.lerstenen.t3.se) ("leaving")
  28. # [01:42] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Read error: 104 (Connection reset by peer))
  29. # [01:42] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  30. # [01:44] * Joins: nlogax (n=nlogax@71-219.lerstenen.t3.se)
  31. # [01:46] * Quits: aroben (n=adamrobe@adsl-70-231-231-70.dsl.snfc21.sbcglobal.net)
  32. # [01:57] * Quits: fax_machine (n=fax_mach@unaffiliated/faxmachine/x-838442)
  33. # [02:12] * Joins: aroben (n=adamrobe@adsl-70-231-231-70.dsl.snfc21.sbcglobal.net)
  34. # [02:26] * Quits: aroben (n=adamrobe@adsl-70-231-231-70.dsl.snfc21.sbcglobal.net)
  35. # [02:41] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  36. # [03:10] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  37. # [04:24] * Joins: fax_machine (n=fax_mach@74-129-102-1.dhcp.insightbb.com)
  38. # [04:26] * othermaciej is now known as om_afk
  39. # [04:39] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  40. # [04:45] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  41. # [05:25] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  42. # [06:20] * om_afk is now known as othermaciej
  43. # [06:45] * Quits: zcorpan_ (n=zcorpan@84-216-43-150.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  44. # [08:06] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  45. # [08:11] * Parts: fax_machine (n=fax_mach@unaffiliated/faxmachine/x-838442)
  46. # [08:17] * Joins: Hassman (n=Hassman@r5bx220.net.upc.cz)
  47. # [08:41] * Joins: hendry (n=hendry@82.2.121.203)
  48. # [09:03] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  49. # [09:41] * Joins: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net)
  50. # [09:41] * Quits: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net) (Remote closed the connection)
  51. # [09:41] * Joins: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net)
  52. # [10:37] * Joins: ROBOd (n=robod@86.34.246.154)
  53. # [10:49] * Joins: hendry_ (n=hendry@82.27.227.50)
  54. # [10:54] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  55. # [11:06] * Quits: hendry (n=hendry@82.2.121.203) (Read error: 110 (Connection timed out))
  56. # [11:14] * Joins: ddfreyne (n=ddfreyne@d51A5CE12.access.telenet.be)
  57. # [11:18] * Quits: hendry_ (n=hendry@82.27.227.50) ("leaving")
  58. # [11:40] * Joins: aroben_ (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net)
  59. # [11:40] * Quits: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  60. # [11:41] * aroben_ is now known as aroben
  61. # [12:03] <ddfreyne> The example of the "small" element (http://www.whatwg.org/specs/web-apps/current-work/#the-small) is confusing…
  62. # [12:03] <ddfreyne> If "small" is used to mark up small print, including copyright notices… why can the "copyright" class name not be used on "small"?
  63. # [12:04] <ddfreyne> (the "copyright" predefined class name is only applicable to p and span)
  64. # [12:05] <annevk> The spec is not done yet so you might have encountered an error. The best way forward is to e-mail whatwg@whatwg.org
  65. # [12:05] <ddfreyne> will do
  66. # [12:40] * Joins: Toolskyn (n=toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  67. # [13:29] * Quits: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net)
  68. # [13:29] * Joins: zcorpan_ (n=zcorpan@84-216-42-54.sprayadsl.telenor.se)
  69. # [13:37] <zcorpan_> ddfreyne: just read http://stoneship.org/journal/2007/html5-sucks/
  70. # [13:38] <ddfreyne> ah, neat
  71. # [13:38] <ddfreyne> the "sucks" is just there to catch attention ;)
  72. # [13:39] <zcorpan_> footnote: i think this is an open issue still
  73. # [13:40] <zcorpan_> note: there is class=note
  74. # [13:40] * othermaciej is now known as om_sleep
  75. # [13:40] <zcorpan_> page, comment: this is what article is for
  76. # [13:40] <ddfreyne> class=note… yes
  77. # [13:41] <ddfreyne> zcorpan_: I'm against adding new elements like note/page/comment… i'd prefer the set of elements to be reduced rather than enlarged
  78. # [13:42] <ddfreyne> those are very big changes I'm proposing and they'll probably be ignored…
  79. # [13:42] <zcorpan_> i understand that you prefer that, but i don't understand why
  80. # [13:42] <zcorpan_> i don't think they'll be ignored :)
  81. # [13:43] <zcorpan_> consider this: would you prefer if html4 did the same 10 years ago? <div role="table"> instead of <table>?
  82. # [13:43] <zcorpan_> <div role="object">
  83. # [13:43] <ddfreyne> table, object… are much more specific than <article>
  84. # [13:44] <ddfreyne> hm… sec
  85. # [13:45] <ddfreyne> <article> by itself doesn't have any article-specific attributes
  86. # [13:45] <zcorpan_> should there be?
  87. # [13:46] <ddfreyne> something like a hAtom subset converted to elements where appropriate (<article> instead of <div class="hentry">) would be useful
  88. # [13:46] <ddfreyne> I think it'd be useful
  89. # [13:47] <zcorpan_> yes... <article> is exactly like <div class="hentry"> aiui
  90. # [13:47] <zcorpan_> you can use <artile> for wrapping a blog post and inner <article>s for the comments
  91. # [13:48] <ddfreyne> I don't see why <article> is better than <div class="hentry"> though
  92. # [13:49] <zcorpan_> i'll discuss more in a bit, i have to run to the gym now
  93. # [13:49] <ddfreyne> I sound microformats-biased :)
  94. # [13:49] <ddfreyne> alright, seeya
  95. # [13:49] <zcorpan_> later
  96. # [14:46] <mpt> The only reason I can think of for having <article> is to prevent accidental search results when the search keywords are spread across multiple <article>s that happen to be shown on the same page
  97. # [14:48] <mpt> Because search engines can't know what <div class="some random value representing an article"> means, but they can know what <article> means
  98. # [14:49] <mpt> but, well, blah
  99. # [14:51] <mpt> Reducing the number of <div>s in the world is not a useful goal
  100. # [15:02] <ddfreyne> that problem could be solved with microformats as well
  101. # [15:07] <ddfreyne> (and I'm not saying everything can be solved with microformats)
  102. # [15:07] <gsnedders> how can it be saved with µf?
  103. # [15:07] <gsnedders> *solved
  104. # [15:08] <ddfreyne> class="hentry" on a block element that is an article
  105. # [15:10] * moeffju[ZzZz] is now known as moeffju
  106. # [15:10] <mpt> I'm <div class="hentry" id="the-8th"> I am, I am, I'm <div class="hentry" id="the-8th"> I am...
  107. # [15:13] <ddfreyne> Sorry… not following you there
  108. # [15:13] <nlogax> :D
  109. # [15:26] <mpt> http://en.wikipedia.org/wiki/I'm_Henery_the_Eighth,_I_Am
  110. # [15:32] <ddfreyne> ah, haha
  111. # [15:34] <gsnedders> ddfreyne: but people make up class names, someone might (oddly) use hentry. people don't make up element names (normally)
  112. # [15:42] <mpt> That's an argument against microformats in general, not against <article> in particular
  113. # [15:44] <ddfreyne> gsnedders: yeah, that's why I actually suggested something like role=
  114. # [15:44] <ddfreyne> (which is similar to class, but predefined, with clear semantic meanings for each value)
  115. # [15:45] <ddfreyne> I think it'd be better to not meddle with class… 
  116. # [16:02] <gsnedders> how are unknown attributes treated?
  117. # [16:02] <gsnedders> %Text?
  118. # [16:08] <Philip`> ddfreyne: I think the selection of structural elements in HTML5 (and the lack of footnote, note, comment, etc) is partly justified by http://code.google.com/webstats/2005-12/classes.html - it's trying to cover all of the most common cases, though I guess the cutoff point is largely a subjective choice
  119. # [16:10] * zcorpan_ is back
  120. # [16:12] * weinig is now known as weinig_
  121. # [16:20] * weinig_ is now known as weinig
  122. # [16:30] <zcorpan_> ddfreyne: i think there are several reasons for using elements rather than attributes for article &c
  123. # [16:31] <zcorpan_> ddfreyne: (1) it's easier to author and maintain markup with element names instead of lots of divs
  124. # [16:32] <zcorpan_> ddfreyne: (2) if we continue reusing div for anything new this way we would end up with DivML 1.0 or something after a while
  125. # [16:33] <zcorpan_> ddfreyne: (3) it prevents the case where an element is both an article and nav at the same time, or where the attribute is placed on bogus places
  126. # [16:33] <ddfreyne> zcorpan_: (1) You could keep on adding new elements for anything that is used a lot
  127. # [16:34] <ddfreyne> zcorpan_: (2) using new elements breaks in some browsers, while role=... or class=... does not
  128. # [16:34] <ddfreyne> and I have no 3 yet
  129. # [16:34] <zcorpan_> ddfreyne: (4) it's more performant to process elements than attributes in the general case (look at the headings and sections section for how article is part of the document outline algorithm)
  130. # [16:35] <ddfreyne> I simply think the amount of new elements is too much
  131. # [16:36] <ddfreyne> I like <m> and <section>, but I don't think it's worth adding 10 more elements
  132. # [16:36] <zcorpan_> (2) i don't think it breaks anything (the content is still accessible as if the tags weren't there, no different from say <label>), it just isn't possible to style in some browsers
  133. # [16:37] <ddfreyne> Hmm…  I remember someone mentioning a workaround for that in fact… I've never seen it though
  134. # [16:38] <zcorpan_> why is it better to use attributes instead of elements? as i said, it would complicate processing, so i don't think using attributes would make the language simpler in any way
  135. # [16:39] <zcorpan_> one workaround is to use xhtml5 :) another might be to fix up the dom with script afterwards
  136. # [16:40] <ddfreyne> Hm… what about the predefined class names, though… what is the reasoning for not putting them into a separate element?
  137. # [16:40] <ddfreyne> Hm, they are more like 'properties' of existing elements I suppose
  138. # [16:40] <zcorpan_> they can apply to multiple elements
  139. # [16:40] <zcorpan_> yeah
  140. # [16:42] <zcorpan_> it could be argued that we should combine all sectioning elements (except body) to just <section> and then use an attribute for what kind of section
  141. # [16:43] <zcorpan_> but i'm not sure what the advantage would be
  142. # [16:43] <ddfreyne> There's still the difference between <div> and <section> which isn't entirely clear
  143. # [16:44] <ddfreyne> If you could add a… say, type="header" attribute to <section>… the entire page would be <section>s, with very few divs
  144. # [16:44] <zcorpan_> indeed... i think this needs to be pointed out very explicitly in the spec... in a nutshell div doesn't affect the document outline
  145. # [16:44] <ddfreyne> so you end up replacing <div> by <section> which is pointless
  146. # [16:44] <zcorpan_> section is not intended to be a catch-all replacement of div
  147. # [16:44] <ddfreyne> clearly
  148. # [16:45] <zcorpan_> but i fear many authors will go "oh, section is the new div, i should replace all my divs with sections!"
  149. # [16:45] <zcorpan_> q.v. b->strong
  150. # [16:46] <ddfreyne> yeah
  151. # [16:46] <ddfreyne> I do believe many div's could be replaced by section's though
  152. # [16:46] <zcorpan_> sure
  153. # [16:48] <zcorpan_> here's an experiment: http://simon.html5.org/sandbox/html/w3c-home-in-html5
  154. # [16:49] <ddfreyne> Yeah, I did something similar with my site a few days ago
  155. # [16:49] * Joins: hendry (n=hendry@82.14.65.109)
  156. # [16:50] <ddfreyne> Perhaps I simply haven't used html5 enough to judge the use of new elements
  157. # [16:51] <ddfreyne> What is the reasoning for giving presentational elements a semantic meaning?
  158. # [16:51] <zcorpan_> there isn't much that can be used today in practice :)
  159. # [16:51] <ddfreyne> that too
  160. # [16:52] <Hassman> whow http://simon.html5.org/valid-html5.png with cat inside 8-)
  161. # [16:52] <zcorpan_> :)
  162. # [16:52] <ddfreyne> that's probably the biggest reason why I switched back… HTML4 is stable and predictable
  163. # [16:52] * Hassman met__
  164. # [16:52] <zcorpan_> ddfreyne: probably to not upset the semanticists or so
  165. # [16:52] * Hassman is now known as met__
  166. # [16:53] <ddfreyne> wouldn't it have made more sense to deprecate the elements instead?
  167. # [16:53] <zcorpan_> that will make em and strong be the de facto italics and bold elements
  168. # [16:53] <zcorpan_> but they already are
  169. # [16:54] <ddfreyne> Redefining b, i, small, etc gives me the impression "b, i and small are no longer uncool, and you can use presentational markup again!"
  170. # [16:56] <ddfreyne> Hm… the use of <article> could actually bring back this old "subscription" feature IE5 had…
  171. # [16:56] <zcorpan_> see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html
  172. # [16:57] <ddfreyne> You'd bookmark a page, then tell IE to check whether the page had been updated or not… but that doesn't work on dynamic pages unless the actual content can be extracted
  173. # [16:58] <ddfreyne> which is possible with <article> (anything outside that could be ignored)
  174. # [16:58] <zcorpan_> indeed
  175. # [16:58] <ddfreyne> zcorpan_: ah, interesting…
  176. # [17:00] <zcorpan_> trying to force authors to use semantic markup doesn't work, they will instead misuse semantic elements for presentational purposes
  177. # [17:01] <zcorpan_> additionally, semantics is not an end of itself, it's more a means to achieve device independence
  178. # [17:01] <ddfreyne> zcorpan_: that raises the question… why have four elements instead now (i, em, b, strong) if the more "semantic" ones are supposed to replace the more "presentational" ones?
  179. # [17:01] * weinig is now known as weinig|away
  180. # [17:01] <ddfreyne> (or the other way around)
  181. # [17:01] <zcorpan_> we already have 4. why forbid one pair of them?
  182. # [17:01] <wilhelm> Because they have different meanings.
  183. # [17:02] <ddfreyne> well, <i> and <b>'s meaning changed
  184. # [17:03] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  185. # [17:03] <wilhelm> Yes. To something that makes more sense.
  186. # [17:03] <zcorpan_> wilhelm: in practice, you can't differentiate between <i> and <em> in an app that extracts semantics, and the benefits of differentiating them on the consumer side is questionable
  187. # [17:04] <zcorpan_> so i'm with hsivonen (it took me a while though)
  188. # [17:04] <ddfreyne> How would WYSIWYG editors differentiate between <i> and <em>, and <b> and <strong>?
  189. # [17:04] <zcorpan_> they don't
  190. # [17:05] <ddfreyne> So they could use <b> for important text, and <strong> for bold?
  191. # [17:05] <ddfreyne> That doesn't seem to solve anything…
  192. # [17:05] <zcorpan_> you can use either for any purpose of why you want bold
  193. # [17:06] <zcorpan_> you want bold for a purpose, but most authors don't think about the purpose
  194. # [17:06] <zcorpan_> or they do but they don't want to mark up the purpose
  195. # [17:06] <zcorpan_> they just hit command-b
  196. # [17:07] <zcorpan_> and the reader gets the purpose because of the context
  197. # [17:07] <zcorpan_> search engines can't extract anything useful here
  198. # [17:07] <ddfreyne> I see… Why do <strong> and <b> still have different meanings, then?
  199. # [17:07] <wilhelm> In written Norwegian, titles of books, magazines, newspapers, movies, records, TV programs and plays are to be displayed in italics.
  200. # [17:07] <zcorpan_> ddfreyne: because Hixie isn't convinced yet, i think :)
  201. # [17:07] <wilhelm> Those italics are not emphasis. And they are not really presentational.
  202. # [17:08] <zcorpan_> wilhelm: indeed
  203. # [17:08] <ddfreyne> wilhelm: but italics there has a semantic meaning… it's not italics because it's pretty
  204. # [17:09] <wilhelm> When we have an element that does the job (<i>), there is no point in requring the author to use <span class='title-of-book'> or some other nonsense.
  205. # [17:09] <wilhelm> ddfreyne: Exactly.
  206. # [17:09] <zcorpan_> indeed
  207. # [17:09] <zcorpan_> seems we agree :)
  208. # [17:09] <zcorpan_> now i gotta go again
  209. # [17:09] <ddfreyne> seeya
  210. # [17:09] <zcorpan_> cya
  211. # [17:10] <wilhelm> Which is what the HTML5 spec says. <i> is used to markup “a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized”.
  212. # [17:11] * ddfreyne nods
  213. # [17:13] <ddfreyne> You wouldn't write something like this either…  the <span class="noun">title</span> of a <span class="noun">book</span> <span class="verb">is</span> <span class="adjective">italicized</span>.
  214. # [17:13] <ddfreyne> silly example really
  215. # [17:14] <ddfreyne> You just mark up what's necessary… marking up the title of a book as a separate class doesn't make sense unless you somehow want to do something with a list of book titles
  216. # [17:14] <wilhelm> No. I would write “<i>Menneskehetens rikdommer</i> av Leo Huberman er en bra bok.”
  217. # [17:15] <ddfreyne> which is pretty much why I don't like the introduction of header, footer, section, aside, article, nav, dialog, … because usually it's not necessary to explicitly mark them up that way
  218. # [17:16] <wilhelm> It might not be neccessary. But it is very useful.
  219. # [17:17] <wilhelm> Especially <article> and <section>.
  220. # [17:17] <ddfreyne> Apart from less keystrokes and readability… what is the use of <header> and <footer>?
  221. # [17:17] <ddfreyne> yeah, I like <article> and <section>
  222. # [17:20] <wilhelm> Standardization. I can tell my web browser to don't bother printing <header>s, <footer>s or <nav>s, because they are not useful on paper.
  223. # [17:20] <ddfreyne> But you could simply tell your browser to display the contents of <article> instead.
  224. # [17:22] <wilhelm> That is also possible, I guess. But standardization of commonly used classes of elements is useful anyway.
  225. # [17:23] <wilhelm> Both for page authors and browser vendors.
  226. # [17:24] <ddfreyne> Standardization for standardization's sake doesn't make a lot of sense though
  227. # [17:25] <wilhelm> Standardization makes it easier to write and parse documents.
  228. # [17:26] <zcorpan_> the use-case of <header> is mainly subheadings (that shouldn't be part of the document outline)
  229. # [17:26] <zcorpan_> "footer" was a very common class name
  230. # [17:26] * zcorpan_ shouldn't be here
  231. # [17:26] <ddfreyne> Ahh, hm
  232. # [17:27] <zcorpan_> these elements also remove the need for skip links
  233. # [17:28] <ddfreyne> an <article> element would eliminate the need for skip links as well though
  234. # [17:29] <zcorpan_> <article> and <nav> mainly
  235. # [17:31] <wilhelm> Sure. But why _not_ standardize the most commonly used classes? footer is the most widespread class on the web.
  236. # [17:31] <wilhelm> http://code.google.com/webstats/2005-12/classes.html
  237. # [17:32] <ddfreyne> elementitis :)
  238. # [17:44] * Parts: zcorpan_ (n=zcorpan@84-216-42-54.sprayadsl.telenor.se)
  239. # [18:06] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  240. # [18:06] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  241. # [18:07] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  242. # [18:07] * weinig|away is now known as weinig
  243. # [18:07] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  244. # [18:09] * Quits: hendry (n=hendry@82.14.65.109) ("leaving")
  245. # [18:10] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  246. # [18:11] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  247. # [18:11] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  248. # [19:04] * Joins: peepo (n=Jay@host86-129-174-162.range86-129.btcentralplus.com)
  249. # [19:08] * Quits: peepo (n=Jay@host86-129-174-162.range86-129.btcentralplus.com) (Client Quit)
  250. # [19:14] * Quits: Toolskyn (n=toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Remote closed the connection)
  251. # [19:41] * Joins: zcorpan_ (n=zcorpan@217-211-77-236-no13.tbcn.telia.com)
  252. # [19:51] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  253. # [20:02] * Quits: zcorpan_ (n=zcorpan@217-211-77-236-no13.tbcn.telia.com) (Read error: 110 (Connection timed out))
  254. # [20:57] * Joins: hober (n=ted@unaffiliated/hober)
  255. # [20:58] * Joins: KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net)
  256. # [21:20] * Joins: hendry (n=hendry@82.27.237.53)
  257. # [21:29] * Quits: hendry (n=hendry@82.27.237.53) ("leaving")
  258. # [21:44] * weinig is now known as weinig|bbl
  259. # [22:07] * Joins: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net)
  260. # [22:16] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 113 (No route to host))
  261. # [22:17] * weinig|bbl is now known as weinig
  262. # [22:29] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Remote closed the connection)
  263. # [22:29] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  264. # [22:31] * Quits: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net) (Remote closed the connection)
  265. # [22:31] * Joins: aroben (n=adamrobe@adsl-70-231-225-61.dsl.snfc21.sbcglobal.net)
  266. # [22:41] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  267. # [22:49] * Joins: gavins (n=gavin@firefox/developer/gavin)
  268. # [22:52] * Joins: Lachy_ (n=Lachlan@124-168-27-56.dyn.iinet.net.au)
  269. # [22:52] * Quits: Lachy (n=Lachlan@124-168-27-56.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  270. # [23:01] * Joins: zcorpan_ (n=zcorpan@217-211-77-236-no13.tbcn.telia.com)
  271. # [23:13] * Joins: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp)
  272. # [23:19] * Joins: Toolskyn (n=toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  273. # [23:25] * Joins: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  274. # [23:30] * Quits: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com) (Client Quit)
  275. # [23:48] <zcorpan_> http://forums.whatwg.org/viewtopic.php?t=38#190
  276. # [23:54] <zcorpan_> perhaps the spec should have a non-normative appendix that lists the differences between html5 and xhtml5
  277. # [23:56] <met__> something like this appendix http://www.w3.org/TR/xhtml2/xhtml2-changes.html#a_changes ?
  278. # [23:56] <zcorpan_> heh
  279. # Session Close: Mon Apr 30 00:00:00 2007

The end :)