/irc-logs / freenode / #whatwg / 2007-06-24 / end

Options:

  1. # Session Start: Sun Jun 24 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) ("Chatzilla 0.9.75-rdmsoft [XULRunner 1.8.0.4/2006060814]")
  4. # [00:08] * Parts: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  5. # [00:11] * Joins: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  6. # [00:25] * Quits: othermaciej (n=mjs@c-67-164-14-77.hsd1.ca.comcast.net)
  7. # [00:36] * Quits: zcorpan (n=zcorpan@81-233-253-112-no13.tbcn.telia.com) (Read error: 110 (Connection timed out))
  8. # [01:15] * Parts: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  9. # [02:04] * Quits: hendry (n=hendry@host86-149-200-239.range86-149.btcentralplus.com) ("leaving")
  10. # [02:18] * Quits: tndH (n=Rob@adsl-87-102-84-66.karoo.KCOM.COM) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  11. # [02:44] * Joins: aroben_ (n=adamrobe@17.255.99.23)
  12. # [02:44] * Quits: aroben_ (n=adamrobe@17.255.99.23) (Client Quit)
  13. # [02:47] * Quits: weinig_ (i=weinig@nat/apple/x-a65d35901f0c5e66)
  14. # [02:49] * Joins: aroben_ (n=adamrobe@17.255.99.23)
  15. # [02:56] * Quits: mpt (n=mpt@121-72-128-43.dsl.telstraclear.net) (Read error: 104 (Connection reset by peer))
  16. # [02:57] * Joins: weinig_ (i=weinig@nat/apple/x-ae3965d4bbd4a59a)
  17. # [02:59] * Joins: ravenn (n=ravenn@124-168-29-83.dyn.iinet.net.au)
  18. # [03:00] * Quits: aroben_ (n=adamrobe@17.255.99.23)
  19. # [03:07] * Quits: weinig_ (i=weinig@nat/apple/x-ae3965d4bbd4a59a)
  20. # [03:10] * Joins: tantek (n=tantek@c-67-174-230-58.hsd1.ca.comcast.net)
  21. # [03:30] * Joins: weinig_ (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  22. # [03:32] * Quits: weinig_ (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net) (Remote closed the connection)
  23. # [03:33] * Joins: weinig_ (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  24. # [04:55] * Quits: Lachy (n=Lachy@203-158-59-119.dyn.iinet.net.au) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502]")
  25. # [05:09] * Parts: ravenn (n=ravenn@124-168-29-83.dyn.iinet.net.au)
  26. # [05:33] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  27. # [05:33] * Quits: webben (n=benh@91.84.143.253) (Client Quit)
  28. # [05:33] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  29. # [05:33] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  30. # [06:05] * Joins: Lachy (n=Lachy@203-158-59-119.dyn.iinet.net.au)
  31. # [07:11] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  32. # [07:35] * Joins: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  33. # [08:05] * Quits: tantek (n=tantek@c-67-174-230-58.hsd1.ca.comcast.net)
  34. # [08:05] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  35. # [08:14] * Joins: mpt (n=mpt@121-72-128-43.dsl.telstraclear.net)
  36. # [08:28] * weinig_ is now known as weinigLao
  37. # [08:28] * weinigLao is now known as weinigLap
  38. # [08:29] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) ("http:/www.csarven.ca")
  39. # [08:29] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  40. # [08:50] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  41. # [08:59] * Quits: weinigLap (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  42. # [08:59] * Quits: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  43. # [09:00] <Lachy> annevk: yt?
  44. # [09:21] * Joins: othermaciej (n=mjs@c-67-164-14-77.hsd1.ca.comcast.net)
  45. # [09:39] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  46. # [10:17] * Joins: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  47. # [10:52] * Joins: zcorpan (n=zcorpan@81-233-253-112-no13.tbcn.telia.com)
  48. # [10:52] * Joins: ROBOd (n=robod@86.34.246.154)
  49. # [10:53] <zcorpan> Lachy: in selectors api, using javascript, if resolver returns undefined, is the namespace then the string "undefined"?
  50. # [10:54] <zcorpan> Lachy: it seems cumbersome to have to explicitly return the empty string instead of just not bothering and let it return undefined...
  51. # [10:55] <zcorpan> or is undefined in javascript equivalent to no return value?
  52. # [10:57] <zcorpan> or hmm, actually, nevermind
  53. # [11:03] <zcorpan> Lachy: anyway, it seems the spec doesn't contain any conformance requirements for documents, and thus, the conforming documents and conforming authoring tools conformance classes can be dropped
  54. # [11:14] * Parts: zcorpan (n=zcorpan@81-233-253-112-no13.tbcn.telia.com)
  55. # [11:15] * Joins: zcorpan (n=zcorpan@81-233-253-112-no13.tbcn.telia.com)
  56. # [11:21] <annevk> Lachy, am now
  57. # [11:23] <annevk> getElementsByClassName returns a live NodeList btw
  58. # [11:23] <annevk> that's a usecase
  59. # [11:24] * Joins: MikeSmith (n=MikeSmit@u-210160014040.hotspot.ne.jp)
  60. # [11:29] <Lachy> zcorpan: in JS, undefined == null, and the spec defines how to handle null
  61. # [11:30] <annevk> however, it's not === null
  62. # [11:30] <annevk> until the binding spec covers this you probably need to handle undefined
  63. # [11:31] <Lachy> How can I make it clearer that anything that == null, should be treated as null
  64. # [11:33] <zcorpan> passing a prefix that is not in the table will return undefined too
  65. # [11:33] <Lachy> zcorpan: I already dropped conforming authoring tool. Were you looking at an old revision?
  66. # [11:34] <zcorpan> Lachy: ah. yes.
  67. # [11:34] <hasather_> Lachy: the resolver could be rewritten a bit more elegantly:
  68. # [11:34] <hasather_> function resolver(prefix) {
  69. # [11:34] <hasather_> return {
  70. # [11:34] <hasather_> "xh": "http://www.w3.org/1999/xhtml",
  71. # [11:34] <hasather_> "svg": "http://www.w3.org/2000/svg"
  72. # [11:34] <hasather_> }[prefix] || "";
  73. # [11:34] <hasather_> }
  74. # [11:34] <Lachy> I'm not sure if I'll keep "conforming application" in there, that's only there cause there's a few authoring requirements.
  75. # [11:35] <zcorpan> given the function above, passing in "foo" as the prefix will return undefined
  76. # [11:35] <Lachy> hasather_: yes, it could, but I chose clarity over being a minimalist
  77. # [11:35] <hasather_> zcorpan: it will return ""
  78. # [11:36] <zcorpan> hasather_: oh, right. ok, given a function in the spec will return undefined
  79. # [11:36] <Lachy> oh, I see
  80. # [11:37] <zcorpan> an unknown prefix should not get the default namespace
  81. # [11:37] <zcorpan> it should raise an exception or something
  82. # [11:37] <zcorpan> as in css, the ruleset will be dropped
  83. # [11:38] <Lachy> hmm. It doesn't look like I handle returning of empty strings for prefixes in a special way.
  84. # [11:38] <Lachy> should I?
  85. # [11:40] <Lachy> annevk: I wanted to ask you about this earlier...
  86. # [11:40] <zcorpan> if you wanted to declare e.g. xhtml as being the default namespace, it should be possible to say ...{ if (prefix == "") return "http://www.w3.org/1999/xhtml"; } right?
  87. # [11:41] <Lachy> It currently says "In doing so, user agents may assume that the object implementing the NSResolver interface (or ECMAScript Function) only relies on scoped variables, doesn't invoke processes outside the object and returns consistent results when its lookupNamespaceURI method is invoked."
  88. # [11:41] <Lachy> in terminology and conventions http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8#terminology
  89. # [11:41] <annevk> hmm
  90. # [11:42] <annevk> I'd make it as simple as possible for authors with copy & paste samples
  91. # [11:42] <Lachy> why should a UA assume scoped variables and not invoking outside processes?
  92. # [11:42] <annevk> you could just define that if it returns anything but a non-empty string
  93. # [11:42] <annevk> and that null and undefined count as the empty string
  94. # [11:45] <Lachy> I'll probably just change that to say this instead, since those other 2 assumptions don't make sense "...user agents may assume that the object implementing the NSResolver interface (or ECMAScript Function) returns consistent results..."
  95. # [11:46] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  96. # [11:51] <Lachy> hmm. No return value in JS means undefined, not void
  97. # [11:56] * Joins: virtuelv_ (n=virtuelv@47.80-202-66.nextgentel.com)
  98. # [12:01] <Lachy> is there a need for the Interoperability Considerations section to be normative? I can't see a reason for it, so I'll make it non-normative
  99. # [12:02] * Quits: virtuelv_ (n=virtuelv@47.80-202-66.nextgentel.com) ("Leaving")
  100. # [12:07] <annevk> as long as sections don't contain normative keywords you don't really have to mention it
  101. # [12:08] <Lachy> I rephrased it and it uses "may", but not really in the RFC2119 sense, so I probably should explicitly state that
  102. # [12:08] <annevk> better to replace the use of may I suppose
  103. # [12:10] <Lachy> this is what it says now: "Since user agents may optimise the algorithms described in this specification, and because some may invoke the NSResolver object more than others, interoperability concerns may arise if the the NSResolver object (or ECMAScript Function) causes side effects or returns inconsistent results each time it is invoked."
  104. # [12:11] <Lachy> any suggestions?
  105. # [12:12] <annevk> can arise
  106. # [12:12] <annevk> are allowed to optimise
  107. # [12:13] <Lachy> that's like what was there before, and I didn't particularly like it
  108. # [12:45] <zcorpan> why not make anything that isn't a string (i.e. ===) raise an exception? in particular, undeclared prefixes shouldn't be silently accepted as the default namespace or no namespace
  109. # [12:46] <zcorpan> that's not consistent with how it works in css
  110. # [12:47] * Joins: tndH (i=Rob@adsl-87-102-84-66.karoo.KCOM.COM)
  111. # [12:48] <zcorpan> should i elaborate in an email?
  112. # [12:51] * Quits: MikeSmith (n=MikeSmit@u-210160014040.hotspot.ne.jp) ("Less talk, more pimp walk.")
  113. # [13:02] <zcorpan> Lachy: yt?
  114. # [13:02] <Lachy> yo
  115. # [13:03] <zcorpan> see above
  116. # [13:03] <Lachy> zcorpan: that's how it does work for prefixes. Only the default namespace allows you to return undefiend/null/etc.
  117. # [13:04] <zcorpan> ah
  118. # [13:04] <zcorpan> ok
  119. # [13:04] <zcorpan> then it's fine
  120. # [13:05] <Lachy> it's a NAMESPACE_ERR exception, see the definition of "unresolvable namespace"
  121. # [13:05] <zcorpan> yeah, i see it now
  122. # [13:06] <zcorpan> then the function doesn't need to return the empty string for the default namespace, you can just let it return undefined. good. :)
  123. # [13:09] <Lachy> yeah, but I'm a perfectionist and I prefer to make it more explicit in the examples
  124. # [13:09] <Lachy> though, I'm not sure if it's better to return "" or null?
  125. # [13:12] <zcorpan> in the examples?
  126. # [13:12] * Joins: Ducki (n=Alex@dialin-145-254-186-044.pools.arcor-ip.net)
  127. # [13:15] <zcorpan> i think it's better to let it return undefined when you don't want to declare a default namespace. when you do, you use the "" prefix the same way as the other prefixes
  128. # [13:18] <zcorpan> function resolver(prefix) {
  129. # [13:18] <zcorpan> var ns = {
  130. # [13:18] <zcorpan> "xh" :"http://www.w3.org/1999/xhtml",
  131. # [13:18] <zcorpan> "xbl" :"http://www.w3.org/ns/xbl",
  132. # [13:18] <zcorpan> "svg" :"http://www.w3.org/2000/svg",
  133. # [13:18] <zcorpan> "math":"http://www.w3.org/1998/Math/MathML"
  134. # [13:18] <zcorpan> };
  135. # [13:18] * Joins: maikmerten (n=maikmert@T78e3.t.pppool.de)
  136. # [13:18] <zcorpan> return ns[prefix];
  137. # [13:18] <zcorpan> }
  138. # [13:18] <zcorpan> if you want to declare xhtml as the default namespace, replace "xh" with ""
  139. # [13:18] <zcorpan> and that is the boilerplate
  140. # [13:20] <zcorpan> imho
  141. # [13:21] * Parts: zcorpan (n=zcorpan@81-233-253-112-no13.tbcn.telia.com)
  142. # [14:06] <Lachy> should I leave returning an empty string for the default namespace, as meaning no default namespace?
  143. # [14:08] <Lachy> hmm. XMLNS says "The empty string, though it is a legal URI reference, cannot be used as a namespace name." -- http://www.w3.org/TR/REC-xml-names/#iri-use
  144. # [14:09] <Lachy> perahps I should make the empty string returned for a prefix throw an exception, and leave it as is for the default ns
  145. # [14:20] * Parts: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  146. # [14:29] * Joins: zcorpan (n=zcorpan@84-216-42-229.sprayadsl.telenor.se)
  147. # [14:35] <zcorpan> Lachy: yeah.
  148. # [14:41] <annevk> namespaces in XML5 are sort of working
  149. # [14:41] * annevk started doing some work on it again
  150. # [14:42] <annevk> I should probably make some enhancements to the tokenizer to make <:foo> not work
  151. # [14:42] <annevk> <x::> is prolly not that harmful although potentially confusing
  152. # [14:45] <Lachy> zcorpan: I adjusted the default NS examples as you suggested
  153. # [14:46] <zcorpan> Lachy: checked in?
  154. # [14:46] <Lachy> not yet
  155. # [14:46] <zcorpan> ok
  156. # [14:47] <annevk> if someone can come up with an extension of the html5lib testsuite format that covers namespace, prefix, localname, name, and value (for attributes) that'd be great
  157. # [14:59] * Quits: Ducki (n=Alex@dialin-145-254-186-044.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  158. # [14:59] * Joins: Ducki (n=Alex@dialin-145-254-186-044.pools.arcor-ip.net)
  159. # [15:21] * Parts: annevk (n=annevk@pat-tdc.opera.com)
  160. # [15:26] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  161. # [15:26] * Quits: zcorpan (n=zcorpan@84-216-42-229.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  162. # [15:28] * Lachy checked in latest changes http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.src.html?content-type=text/html;%20charset=utf-8
  163. # [15:31] <annevk> I'd drop REQUIRED, SHALL and SHALL NOT from the document
  164. # [15:31] <Lachy> ok
  165. # [15:32] * Joins: Aidan_pl (i=adrian54@aaor181.neoplus.adsl.tpnet.pl)
  166. # [15:33] * Parts: Aidan_pl (i=adrian54@aaor181.neoplus.adsl.tpnet.pl)
  167. # [15:33] <annevk> also, selectElement returns an Element, not a Node
  168. # [15:33] * Joins: Adrian_ (n=Adrian@aaor181.neoplus.adsl.tpnet.pl)
  169. # [15:33] * Adrian_ is now known as Aidan[pl]
  170. # [15:34] <Aidan[pl]> hi
  171. # [15:34] <annevk> the last sample has a newline too much
  172. # [15:34] <annevk> Aidan[pl], hi
  173. # [15:34] <annevk> maybe s/Informative/Non-normative/
  174. # [15:35] <Aidan[pl]> wher can I read more about html5. I searching polish site.
  175. # [15:36] <Lachy> annevk: which sample has an extra line?
  176. # [15:36] <annevk> not sure about Polish resources
  177. # [15:36] <annevk> Lachy, the last one in the document?
  178. # [15:36] <Lachy> oh, I see
  179. # [15:37] <annevk> is {lookUpNamespaceURI:function(){ ... }} expected to work?
  180. # [15:38] <Lachy> yes
  181. # [15:38] <annevk> maybe have a sample for that too to make it clear?
  182. # [15:38] <annevk> nm
  183. # [15:38] <Lachy> it's just syntactic sugar
  184. # [15:39] <annevk> what if the object contains more than that member?
  185. # [15:39] <annevk> should the spec say something about that much like putImageData has specific requirements
  186. # [15:39] <Lachy> it makes no difference
  187. # [15:39] * Lachy looks up putImageData
  188. # [15:39] <annevk> it currently doesn't, indeed
  189. # [15:41] * Parts: Aidan[pl] (n=Adrian@aaor181.neoplus.adsl.tpnet.pl) ("bye")
  190. # [15:41] <annevk> the specification doesn't define for instance what to do with objects passed that don't have that method
  191. # [15:41] <Lachy> it's better to just ignore any additional methods, which would allow for any future extensions to NSResolver
  192. # [15:41] <annevk> euhm
  193. # [15:41] <annevk> depends on the extension
  194. # [15:43] <Lachy> it sort of does because it says "An unresolvable namespace is a namespace that cannot be resolved because there was no NSResolver provided...", but it could be made more explicit
  195. # [15:48] <Lachy> should I also remove RECOMMENDED and OPTIONAL?
  196. # [15:48] <annevk> I'd remove everything not used in the spec
  197. # [15:49] <Lachy> then MUST NOT and SHOULD NOT can be removed too
  198. # [15:49] <annevk> sure
  199. # [15:49] <Lachy> "The key words must, should, and may in the normative parts of this document are to be interpreted as described in [RFC2119]."
  200. # [15:49] <annevk> nice
  201. # [15:50] <Lachy> I think it's ready to be published as a WD now
  202. # [15:51] <annevk> did you check in?
  203. # [15:51] <Lachy> will do now
  204. # [15:52] <Lachy> done
  205. # [15:52] <Dashiva> Lachy: The table iteration example could be done a lot easier using the DOM collections. Is the intention just to show gEBTN is clunky?
  206. # [15:53] <Lachy> yes
  207. # [15:53] <Lachy> which DOM collections?
  208. # [15:53] <Dashiva> tBodies, rows, cells
  209. # [15:53] <annevk> .rows
  210. # [15:53] <annevk> maybe make it an XML table
  211. # [15:53] <annevk> <table-row> etc.
  212. # [15:53] <Dashiva> If you're ragging on gEBTN, you should also mention it fails to separate between parent and child structures. Like it would grab the tbodies of inner tables too
  213. # [15:54] <Lachy> why would I want to do that? I think the first example should be HTML, since that will be the most common language used with it
  214. # [15:54] <annevk> in HTML you don't need gEBTN for what you're doing
  215. # [15:55] <annevk> the point Dashiva makes is a good one
  216. # [15:55] <annevk> gEBTN only handles descendents where selectElement handles > too
  217. # [15:56] <Lachy> I don't see how using .rows could make the example much less verbose
  218. # [15:56] <Lachy> I could replace gEBTN("tbody") with .tBodies
  219. # [15:56] <annevk> less typing
  220. # [15:57] <annevk> and it does something slightly different
  221. # [15:57] <annevk> it handles nested tables better
  222. # [15:57] <Lachy> the whole example could also be done using XPath .evaluate() too
  223. # [15:58] <annevk> I suppose the assumption is that that's not always supported, but HTML APIs are...
  224. # [15:58] <annevk> doesn't really matter that much though
  225. # [16:04] * Joins: zcorpan (n=zcorpan@84-216-42-41.sprayadsl.telenor.se)
  226. # [16:07] <Lachy> I could replace the example with this, if that would make you happy:
  227. # [16:07] <Lachy> var table = document.getElementById("score");
  228. # [16:07] <Lachy> var groups = table.tBodies;
  229. # [16:07] <Lachy> var rows = null;
  230. # [16:07] <Lachy> var cells = new Array();
  231. # [16:07] <Lachy> for (var i = 0; i < groups.length; i++) {
  232. # [16:07] <Lachy> rows = groups[i].rows;
  233. # [16:07] <Lachy> for (var j = 0; j < rows.length; j++) {
  234. # [16:07] <Lachy> cells.push(rows[j].cells[1]);
  235. # [16:07] <Lachy> }
  236. # [16:07] <Lachy> }
  237. # [16:07] <annevk> you'd have to use child selectors as well than in the selectors sample
  238. # [16:09] <Lachy> for the example, child selectors aren't really necessary, since the assumption is that table won't ever contain nested tables, which is a reasonable assumption to make when the author of both table and script is the same
  239. # [16:10] <annevk> I suppose that's fair enough
  240. # [16:10] <annevk> it would be faster though
  241. # [16:10] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  242. # [16:11] <Lachy> given that it would be faster, ok
  243. # [16:12] <zcorpan> descendant selectors are more convenient than child selectors... and authors are more familiar with descendant than child. not that i feel strongly about it
  244. # [16:13] <annevk> they are quite expensive compared to child selectors
  245. # [16:13] <annevk> more expensive is a combination of both
  246. # [16:14] <Lachy> there are other examples that show descendant selectors used, it's good to give an example with other combinators
  247. # [16:14] <Lachy> checked it in
  248. # [16:15] <Lachy> how do I get it republished as a WD? Do I just send a mail to public-webapi and propose it?
  249. # [16:15] <Lachy> or maybe to member-webapi?
  250. # [16:16] <Lachy> oh, but I should resolve the last remaining open issue in the tracker
  251. # [16:16] <zcorpan> "...there are at least two approaches that may be taken." -- although it doesn't really matter, it might be nice to avoid using rfc2119 terms in examples
  252. # [16:16] <annevk> you need to generate a new Overview.html
  253. # [16:16] <Lachy> yeah, I will do that
  254. # [16:17] <annevk> then the best thing is probably to say on public-webapi@w3.org that you want to request publication of a new working draft 1st of july or something and that people have until then to raise issues with that idea
  255. # [16:25] * Joins: SavageX (n=maikmert@T6019.t.pppool.de)
  256. # [16:43] * Quits: maikmerten (n=maikmert@T78e3.t.pppool.de) (Read error: 110 (Connection timed out))
  257. # [16:59] * Joins: Ducki_ (i=Alex@dialin-145-254-186-162.pools.arcor-ip.net)
  258. # [17:10] * Quits: Ducki (n=Alex@dialin-145-254-186-044.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  259. # [17:25] * Quits: tndH (i=Rob@adsl-87-102-84-66.karoo.KCOM.COM) (Read error: 110 (Connection timed out))
  260. # [17:55] * Joins: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  261. # [18:21] * Joins: Jero (n=Jero@d207230.upc-d.chello.nl)
  262. # [18:22] * Joins: tndH (i=Rob@adsl-87-102-84-66.karoo.KCOM.COM)
  263. # [18:23] <Jero> http://digg.com/design/Crazy_guy_can_draw_using_HTML
  264. # [18:23] <Jero> Great example of the power of HTML...
  265. # [18:59] * Joins: Ducki__ (n=Alex@dialin-145-254-187-099.pools.arcor-ip.net)
  266. # [19:08] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  267. # [19:22] * Joins: webben (n=benh@91.84.143.253)
  268. # [19:23] <webben> in the current Differences from HTML4 document, this explanation of <b> seems self-contradictory: "The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened."
  269. # [19:24] <webben> surely key words in an abstract are given a "typical" typographical presentation of bold in order to convey their "extra importance"
  270. # [19:25] * Quits: Ducki_ (i=Alex@dialin-145-254-186-162.pools.arcor-ip.net) (Read error: 113 (No route to host))
  271. # [19:34] * Parts: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  272. # [19:35] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  273. # [19:40] * Joins: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  274. # [19:53] * Joins: hendry (n=hendry@91.84.62.62)
  275. # [19:58] * Joins: gsnedders (n=gsnedder@host86-140-190-99.range86-140.btcentralplus.com)
  276. # [20:04] * Quits: gsnedders (n=gsnedder@host86-140-190-99.range86-140.btcentralplus.com)
  277. # [20:26] * Joins: gsnedders (n=gsnedder@host86-140-190-99.range86-140.btcentralplus.com)
  278. # [20:33] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  279. # [20:33] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  280. # [20:41] <Philip`> http://digg.com/design/Crazy_guy_can_draw_using_HTML
  281. # [20:41] <Philip`> Oh, is that the 'paste' button?
  282. # [20:42] * Philip` wonders how to copy instead
  283. # [20:43] <Philip`> Aha, not by right clicking
  284. # [20:47] <webben> "how to copy" with what?
  285. # [20:47] <Philip`> With text inside PuTTY
  286. # [20:48] <webben> Philip`: select the text then click to paste probably
  287. # [20:48] <webben> (on x terms, merely selecting text copies it
  288. # [20:48] <Philip`> (I think my computer's graphics card has melted, so I'm stuck on other computers for a while...)
  289. # [20:49] <Philip`> Okay - just selecting the text seems to work fine :-)
  290. # [20:59] * Joins: Ducki_ (n=Alex@dialin-145-254-187-099.pools.arcor-ip.net)
  291. # [20:59] * Quits: Ducki__ (n=Alex@dialin-145-254-187-099.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  292. # [21:08] <Jero> I think it'd be nice to have a <content> sectioning element
  293. # [21:08] <Jero> it could function as a container element for all the <article>, <section>, <aside> etc. elements
  294. # [21:08] <zcorpan> isn't that <body>?
  295. # [21:08] <Jero> it could be used as <header><h1>Website</h1><nav/></header><content/><footer/>, which is, IMO, a structure many websites use
  296. # [21:09] <zcorpan> (not allowed to have nav in header)
  297. # [21:09] <Jero> <header/<nav/><content/><footer/> then (not completely familiar with the spec yet)
  298. # [21:09] <Jero> *<header/>
  299. # [21:09] <zcorpan> what's in content?
  300. # [21:10] <Jero> <article>, <section>, <aside> etc.
  301. # [21:10] <zcorpan> what does the content element add beond <header/><nav/><article>, <section>, <aside> etc.<footer/>?
  302. # [21:11] <zcorpan> isn't it implicit that things that are not asides or navs are content?
  303. # [21:11] <mpt> webben, I've read many document abstracts, and none of them have used bold (or any special style) for their list of keywords
  304. # [21:13] <Jero> zcorpan: IMO it just makes sense to group all elements that are content in one <content> element
  305. # [21:13] <Jero> (plus it also makes it a lot easier to style using CSS)
  306. # [21:13] <zcorpan> Jero: see topic ;)
  307. # [21:14] <Jero> >_>
  308. # [21:14] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  309. # [21:16] <zcorpan> Jero: i'm not saying it's a bad idea, i just haven't heard any convincing use-cases for <content> yet
  310. # [21:17] <zcorpan> (i haven't heard convincing use-cases for <footer> either, though)
  311. # [21:20] * Jero is brainstorming
  312. # [21:22] * zcorpan likes brainstorms
  313. # [21:24] <mpt> webben, actually, I think some of them might have used italics, but that would have been for the entire paragraph, including the "Keywords:" intro and all the commas between them
  314. # [21:31] * Joins: tantek (n=tantek@c-71-202-121-218.hsd1.ca.comcast.net)
  315. # [21:32] * Joins: ddfreyne (n=ddfreyne@d54C57894.access.telenet.be)
  316. # [21:33] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne) (Remote closed the connection)
  317. # [21:33] * Joins: ddfreyne (n=ddfreyne@d54C57894.access.telenet.be)
  318. # [21:46] * Joins: tantek_ (n=tantek@c-71-202-121-218.hsd1.ca.comcast.net)
  319. # [21:49] <webben> mpt: hence the scare quotes
  320. # [21:49] <webben> mpt: If it isn't a common typographical style, that doesn't really make the text better.
  321. # [21:53] * Quits: SavageX (n=maikmert@T6019.t.pppool.de) ("Leaving")
  322. # [21:56] <webben> zcorpan: Replacing "Skip to main content" links isn't a convincing use case?
  323. # [21:56] <webben> (for <content>)
  324. # [21:57] <webben> also being able to style it properly
  325. # [21:57] <webben> otherwise people are just going to use <div class="content"> anyhow
  326. # [21:57] <zcorpan> webben: isn't the first <article> that?
  327. # [21:58] <webben> zcorpan: Who knows. (Which is kind of the point.)
  328. # [21:58] <zcorpan> what is the main content? isn't it the <article>s?
  329. # [21:58] <webben> zcorpan: whatever the author considers to be the main content.
  330. # [21:59] <Philip`> Lachy: If I had some comments about the Selectors API (just boring trivial things about indentation and grammar and italicisation), is there somewhere I should put them?
  331. # [21:59] <webben> zcorpan: e.g. it might include some introductory text before a list of articles
  332. # [21:59] <webben> s/list/series/
  333. # [22:01] <webben> it might include a <nav> if the whole point of the page is navigation
  334. # [22:02] <zcorpan> like a sitemap?
  335. # [22:02] * Quits: tantek (n=tantek@c-71-202-121-218.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  336. # [22:02] <webben> zcorpan: sitemaps, indexes, tables of contents, lists of stuff
  337. # [22:02] <webben> tag clouds
  338. # [22:02] <webben> the possibilities are pretty endless
  339. # [22:03] <webben> and often might involve explanatory text too
  340. # [22:03] <zcorpan> yeah. so what you're saying is that skipping to the first <article> isn't good enough, and that <content> would be more accurate/flexible
  341. # [22:04] <webben> zcorpan: yeah that sums it up I guess
  342. # [22:04] <zcorpan> good stuff. now forward this information to the list :)
  343. # [22:05] <webben> has this been being discussed on the whatwg list?
  344. # [22:05] * webben wonders if he missed it in the deluge of list mail he receives daily
  345. # [22:05] <zcorpan> what you brought up here is new stuff i think
  346. # [22:06] <zcorpan> <content> has been proposed before but it hasn't been explained really what it's use-cases were
  347. # [22:06] <zcorpan> (beond <article>)
  348. # [22:06] * Quits: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com) (Connection reset by peer)
  349. # [22:07] <zcorpan> http://forums.whatwg.org/viewtopic.php?t=35
  350. # [22:10] <zcorpan> perhaps "skip to main content" could be implemented by simply ignoring the site-wide header (if any), any <nav>s and any <aside>s. instead of skipping to the first <article>.
  351. # [22:12] <webben> zcorpan: Except that the main content might be the nav.
  352. # [22:13] * Joins: weinigLap (i=weinig@nat/apple/x-38dab6943e9591e4)
  353. # [22:13] <zcorpan> in such a case, couldn't you just not use nav? :)
  354. # [22:14] <webben> zcorpan: I think it would be a bit weird to define <nav> as for navigation lists ... except when navigation lists are the main content.
  355. # [22:14] <zcorpan> since the main use-case for nav, aiui, is exactly to avoid the need for skip links
  356. # [22:14] <webben> As authors are going to want a container for main content anyhow, one might as well use a standard one to make UA's life easier.
  357. # [22:14] <webben> zcorpan: Well there are two sorts of skip links
  358. # [22:14] <webben> Type 1: skip /to/ somewhere (typically main content)
  359. # [22:15] <webben> Type 2: skip /over/ something
  360. # [22:15] <zcorpan> right, you can skip to or over a <nav>
  361. # [22:16] <webben> zcorpan: well you can skip to or over a paragraph (if UAs bothered to implement such navigation.)
  362. # [22:16] <webben> but main content is much more of an authorial judgement
  363. # [22:17] <zcorpan> sure
  364. # [22:18] * Quits: tantek_ (n=tantek@c-71-202-121-218.hsd1.ca.comcast.net)
  365. # [22:19] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  366. # [22:21] <Jero> zcorpan, just look at http://digg.com/
  367. # [22:22] <Jero> the "Spreading the Word..." box isn't the main content, the data below that box is
  368. # [22:23] <zcorpan> right. that box might be an aside
  369. # [22:24] <zcorpan> i agree that there are examples of pages that have an area with "main content" that is not purely an <article> or a series of <article>s
  370. # [22:27] <Jero> Hixie, I'd love to hear your opinion on a <content> element
  371. # [22:28] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  372. # [22:28] <zcorpan> Jero: it would be great if you (or someone else) could summarize this discussion and send it to the list
  373. # [22:28] <Jero> also a good idea
  374. # [22:28] <zcorpan> Jero: then Hixie will look at it in due course
  375. # [22:28] <Jero> i see
  376. # [22:34] * Quits: othermaciej (n=mjs@c-67-164-14-77.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  377. # [22:44] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  378. # [22:55] * Joins: KevinMarks (n=Snak@c-76-102-254-252.hsd1.ca.comcast.net)
  379. # [22:59] * Quits: Ducki_ (n=Alex@dialin-145-254-187-099.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  380. # [22:59] * Joins: Ducki_ (i=Alex@dialin-145-254-188-019.pools.arcor-ip.net)
  381. # [23:21] * Quits: hendry (n=hendry@91.84.62.62) ("Zzzzzzzzzzz")
  382. # [23:22] * Joins: zcorpan_ (n=zcorpan@84-216-41-82.sprayadsl.telenor.se)
  383. # [23:27] * Quits: Jero (n=Jero@d207230.upc-d.chello.nl) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502]")
  384. # [23:34] * Quits: zcorpan (n=zcorpan@84-216-42-41.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  385. # [23:40] * Joins: hasather_ (n=hasather@22.80-203-71.nextgentel.com)
  386. # [23:52] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  387. # [23:54] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne) ("kthxbai")
  388. # Session Close: Mon Jun 25 00:00:00 2007

The end :)