| 07:52 | <Lachy> | annevk: yt? |
| 09:45 | <zcorpan> | Lachy: in selectors api, using javascript, if resolver returns undefined, is the namespace then the string "undefined"? |
| 09:46 | <zcorpan> | Lachy: it seems cumbersome to have to explicitly return the empty string instead of just not bothering and let it return undefined... |
| 09:47 | <zcorpan> | or is undefined in javascript equivalent to no return value? |
| 09:49 | <zcorpan> | or hmm, actually, nevermind |
| 09:55 | <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 |
| 10:13 | <annevk> | Lachy, am now |
| 10:15 | <annevk> | getElementsByClassName returns a live NodeList btw |
| 10:15 | <annevk> | that's a usecase |
| 10:21 | <Lachy> | zcorpan: in JS, undefined == null, and the spec defines how to handle null |
| 10:22 | <annevk> | however, it's not === null |
| 10:22 | <annevk> | until the binding spec covers this you probably need to handle undefined |
| 10:23 | <Lachy> | How can I make it clearer that anything that == null, should be treated as null |
| 10:25 | <zcorpan> | passing a prefix that is not in the table will return undefined too |
| 10:25 | <Lachy> | zcorpan: I already dropped conforming authoring tool. Were you looking at an old revision? |
| 10:26 | <zcorpan> | Lachy: ah. yes. |
| 10:26 | <hasather_> | Lachy: the resolver could be rewritten a bit more elegantly: |
| 10:26 | <hasather_> | function resolver(prefix) { |
| 10:26 | <hasather_> | return { |
| 10:26 | <hasather_> | "xh": "http://www.w3.org/1999/xhtml";, |
| 10:26 | <hasather_> | "svg": "http://www.w3.org/2000/svg"; |
| 10:26 | <hasather_> | }[prefix] || ""; |
| 10:26 | <hasather_> | } |
| 10:26 | <Lachy> | I'm not sure if I'll keep "conforming application" in there, that's only there cause there's a few authoring requirements. |
| 10:27 | <zcorpan> | given the function above, passing in "foo" as the prefix will return undefined |
| 10:27 | <Lachy> | hasather_: yes, it could, but I chose clarity over being a minimalist |
| 10:27 | <hasather_> | zcorpan: it will return "" |
| 10:28 | <zcorpan> | hasather_: oh, right. ok, given a function in the spec will return undefined |
| 10:28 | <Lachy> | oh, I see |
| 10:29 | <zcorpan> | an unknown prefix should not get the default namespace |
| 10:29 | <zcorpan> | it should raise an exception or something |
| 10:29 | <zcorpan> | as in css, the ruleset will be dropped |
| 10:30 | <Lachy> | hmm. It doesn't look like I handle returning of empty strings for prefixes in a special way. |
| 10:30 | <Lachy> | should I? |
| 10:32 | <Lachy> | annevk: I wanted to ask you about this earlier... |
| 10:32 | <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? |
| 10:33 | <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." |
| 10:33 | <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 |
| 10:33 | <annevk> | hmm |
| 10:34 | <annevk> | I'd make it as simple as possible for authors with copy & paste samples |
| 10:34 | <Lachy> | why should a UA assume scoped variables and not invoking outside processes? |
| 10:34 | <annevk> | you could just define that if it returns anything but a non-empty string |
| 10:34 | <annevk> | and that null and undefined count as the empty string |
| 10:37 | <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..." |
| 10:43 | <Lachy> | hmm. No return value in JS means undefined, not void |
| 10:53 | <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 |
| 10:59 | <annevk> | as long as sections don't contain normative keywords you don't really have to mention it |
| 11:00 | <Lachy> | I rephrased it and it uses "may", but not really in the RFC2119 sense, so I probably should explicitly state that |
| 11:00 | <annevk> | better to replace the use of may I suppose |
| 11:02 | <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." |
| 11:03 | <Lachy> | any suggestions? |
| 11:04 | <annevk> | can arise |
| 11:04 | <annevk> | are allowed to optimise |
| 11:05 | <Lachy> | that's like what was there before, and I didn't particularly like it |
| 11:37 | <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 |
| 11:38 | <zcorpan> | that's not consistent with how it works in css |
| 11:40 | <zcorpan> | should i elaborate in an email? |
| 11:54 | <zcorpan> | Lachy: yt? |
| 11:54 | <Lachy> | yo |
| 11:55 | <zcorpan> | see above |
| 11:55 | <Lachy> | zcorpan: that's how it does work for prefixes. Only the default namespace allows you to return undefiend/null/etc. |
| 11:56 | <zcorpan> | ah |
| 11:56 | <zcorpan> | ok |
| 11:56 | <zcorpan> | then it's fine |
| 11:57 | <Lachy> | it's a NAMESPACE_ERR exception, see the definition of "unresolvable namespace" |
| 11:57 | <zcorpan> | yeah, i see it now |
| 11:58 | <zcorpan> | then the function doesn't need to return the empty string for the default namespace, you can just let it return undefined. good. :) |
| 12:01 | <Lachy> | yeah, but I'm a perfectionist and I prefer to make it more explicit in the examples |
| 12:01 | <Lachy> | though, I'm not sure if it's better to return "" or null? |
| 12:04 | <zcorpan> | in the examples? |
| 12:07 | <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 |
| 12:10 | <zcorpan> | function resolver(prefix) { |
| 12:10 | <zcorpan> | var ns = { |
| 12:10 | <zcorpan> | "xh" :"http://www.w3.org/1999/xhtml";, |
| 12:10 | <zcorpan> | "xbl" :"http://www.w3.org/ns/xbl";, |
| 12:10 | <zcorpan> | "svg" :"http://www.w3.org/2000/svg";, |
| 12:10 | <zcorpan> | "math":"http://www.w3.org/1998/Math/MathML"; |
| 12:10 | <zcorpan> | }; |
| 12:10 | <zcorpan> | return ns[prefix]; |
| 12:10 | <zcorpan> | } |
| 12:10 | <zcorpan> | if you want to declare xhtml as the default namespace, replace "xh" with "" |
| 12:10 | <zcorpan> | and that is the boilerplate |
| 12:12 | <zcorpan> | imho |
| 12:58 | <Lachy> | should I leave returning an empty string for the default namespace, as meaning no default namespace? |
| 13:00 | <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 |
| 13:01 | <Lachy> | perahps I should make the empty string returned for a prefix throw an exception, and leave it as is for the default ns |
| 13:27 | <zcorpan> | Lachy: yeah. |
| 13:33 | <annevk> | namespaces in XML5 are sort of working |
| 13:33 | annevk | started doing some work on it again |
| 13:34 | <annevk> | I should probably make some enhancements to the tokenizer to make <:foo> not work |
| 13:34 | <annevk> | <x::> is prolly not that harmful although potentially confusing |
| 13:37 | <Lachy> | zcorpan: I adjusted the default NS examples as you suggested |
| 13:38 | <zcorpan> | Lachy: checked in? |
| 13:38 | <Lachy> | not yet |
| 13:38 | <zcorpan> | ok |
| 13:39 | <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 |
| 14:20 | 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 |
| 14:23 | <annevk> | I'd drop REQUIRED, SHALL and SHALL NOT from the document |
| 14:23 | <Lachy> | ok |
| 14:25 | <annevk> | also, selectElement returns an Element, not a Node |
| 14:26 | <Aidan[pl]> | hi |
| 14:26 | <annevk> | the last sample has a newline too much |
| 14:26 | <annevk> | Aidan[pl], hi |
| 14:26 | <annevk> | maybe s/Informative/Non-normative/ |
| 14:27 | <Aidan[pl]> | wher can I read more about html5. I searching polish site. |
| 14:28 | <Lachy> | annevk: which sample has an extra line? |
| 14:28 | <annevk> | not sure about Polish resources |
| 14:28 | <annevk> | Lachy, the last one in the document? |
| 14:28 | <Lachy> | oh, I see |
| 14:29 | <annevk> | is {lookUpNamespaceURI:function(){ ... }} expected to work? |
| 14:30 | <Lachy> | yes |
| 14:30 | <annevk> | maybe have a sample for that too to make it clear? |
| 14:30 | <annevk> | nm |
| 14:30 | <Lachy> | it's just syntactic sugar |
| 14:31 | <annevk> | what if the object contains more than that member? |
| 14:31 | <annevk> | should the spec say something about that much like putImageData has specific requirements |
| 14:31 | <Lachy> | it makes no difference |
| 14:31 | Lachy | looks up putImageData |
| 14:31 | <annevk> | it currently doesn't, indeed |
| 14:33 | <annevk> | the specification doesn't define for instance what to do with objects passed that don't have that method |
| 14:33 | <Lachy> | it's better to just ignore any additional methods, which would allow for any future extensions to NSResolver |
| 14:33 | <annevk> | euhm |
| 14:33 | <annevk> | depends on the extension |
| 14:35 | <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 |
| 14:40 | <Lachy> | should I also remove RECOMMENDED and OPTIONAL? |
| 14:40 | <annevk> | I'd remove everything not used in the spec |
| 14:41 | <Lachy> | then MUST NOT and SHOULD NOT can be removed too |
| 14:41 | <annevk> | sure |
| 14:41 | <Lachy> | "The key words must, should, and may in the normative parts of this document are to be interpreted as described in [RFC2119]." |
| 14:41 | <annevk> | nice |
| 14:42 | <Lachy> | I think it's ready to be published as a WD now |
| 14:43 | <annevk> | did you check in? |
| 14:43 | <Lachy> | will do now |
| 14:44 | <Lachy> | done |
| 14:44 | <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? |
| 14:45 | <Lachy> | yes |
| 14:45 | <Lachy> | which DOM collections? |
| 14:45 | <Dashiva> | tBodies, rows, cells |
| 14:45 | <annevk> | .rows |
| 14:45 | <annevk> | maybe make it an XML table |
| 14:45 | <annevk> | <table-row> etc. |
| 14:45 | <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 |
| 14:46 | <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 |
| 14:46 | <annevk> | in HTML you don't need gEBTN for what you're doing |
| 14:47 | <annevk> | the point Dashiva makes is a good one |
| 14:47 | <annevk> | gEBTN only handles descendents where selectElement handles > too |
| 14:48 | <Lachy> | I don't see how using .rows could make the example much less verbose |
| 14:48 | <Lachy> | I could replace gEBTN("tbody") with .tBodies |
| 14:48 | <annevk> | less typing |
| 14:49 | <annevk> | and it does something slightly different |
| 14:49 | <annevk> | it handles nested tables better |
| 14:49 | <Lachy> | the whole example could also be done using XPath .evaluate() too |
| 14:50 | <annevk> | I suppose the assumption is that that's not always supported, but HTML APIs are... |
| 14:50 | <annevk> | doesn't really matter that much though |
| 14:59 | <Lachy> | I could replace the example with this, if that would make you happy: |
| 14:59 | <Lachy> | var table = document.getElementById("score"); |
| 14:59 | <Lachy> | var groups = table.tBodies; |
| 14:59 | <Lachy> | var rows = null; |
| 14:59 | <Lachy> | var cells = new Array(); |
| 14:59 | <Lachy> | for (var i = 0; i < groups.length; i++) { |
| 14:59 | <Lachy> | rows = groups[i].rows; |
| 14:59 | <Lachy> | for (var j = 0; j < rows.length; j++) { |
| 14:59 | <Lachy> | cells.push(rows[j].cells[1]); |
| 14:59 | <Lachy> | } |
| 14:59 | <Lachy> | } |
| 14:59 | <annevk> | you'd have to use child selectors as well than in the selectors sample |
| 15:01 | <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 |
| 15:02 | <annevk> | I suppose that's fair enough |
| 15:02 | <annevk> | it would be faster though |
| 15:03 | <Lachy> | given that it would be faster, ok |
| 15:04 | <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 |
| 15:05 | <annevk> | they are quite expensive compared to child selectors |
| 15:05 | <annevk> | more expensive is a combination of both |
| 15:06 | <Lachy> | there are other examples that show descendant selectors used, it's good to give an example with other combinators |
| 15:06 | <Lachy> | checked it in |
| 15:07 | <Lachy> | how do I get it republished as a WD? Do I just send a mail to public-webapi and propose it? |
| 15:07 | <Lachy> | or maybe to member-webapi? |
| 15:08 | <Lachy> | oh, but I should resolve the last remaining open issue in the tracker |
| 15:08 | <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 |
| 15:08 | <annevk> | you need to generate a new Overview.html |
| 15:08 | <Lachy> | yeah, I will do that |
| 15:09 | <annevk> | then the best thing is probably to say on public-webapi⊙wo 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 |
| 17:15 | <Jero> | http://digg.com/design/Crazy_guy_can_draw_using_HTML |
| 17:15 | <Jero> | Great example of the power of HTML... |
| 18:15 | <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." |
| 18:16 | <webben> | surely key words in an abstract are given a "typical" typographical presentation of bold in order to convey their "extra importance" |
| 19:33 | <Philip`> | http://digg.com/design/Crazy_guy_can_draw_using_HTML |
| 19:33 | <Philip`> | Oh, is that the 'paste' button? |
| 19:34 | Philip` | wonders how to copy instead |
| 19:35 | <Philip`> | Aha, not by right clicking |
| 19:39 | <webben> | "how to copy" with what? |
| 19:39 | <Philip`> | With text inside PuTTY |
| 19:40 | <webben> | Philip`: select the text then click to paste probably |
| 19:40 | <webben> | (on x terms, merely selecting text copies it |
| 19:40 | <Philip`> | (I think my computer's graphics card has melted, so I'm stuck on other computers for a while...) |
| 19:41 | <Philip`> | Okay - just selecting the text seems to work fine :-) |
| 20:00 | <Jero> | I think it'd be nice to have a <content> sectioning element |
| 20:00 | <Jero> | it could function as a container element for all the <article>, <section>, <aside> etc. elements |
| 20:00 | <zcorpan> | isn't that <body>? |
| 20:00 | <Jero> | it could be used as <header><h1>Website</h1><nav/></header><content/><footer/>, which is, IMO, a structure many websites use |
| 20:01 | <zcorpan> | (not allowed to have nav in header) |
| 20:01 | <Jero> | <header/<nav/><content/><footer/> then (not completely familiar with the spec yet) |
| 20:01 | <Jero> | *<header/> |
| 20:01 | <zcorpan> | what's in content? |
| 20:02 | <Jero> | <article>, <section>, <aside> etc. |
| 20:02 | <zcorpan> | what does the content element add beond <header/><nav/><article>, <section>, <aside> etc.<footer/>? |
| 20:03 | <zcorpan> | isn't it implicit that things that are not asides or navs are content? |
| 20:03 | <mpt> | webben, I've read many document abstracts, and none of them have used bold (or any special style) for their list of keywords |
| 20:05 | <Jero> | zcorpan: IMO it just makes sense to group all elements that are content in one <content> element |
| 20:05 | <Jero> | (plus it also makes it a lot easier to style using CSS) |
| 20:05 | <zcorpan> | Jero: see topic ;) |
| 20:06 | <Jero> | >_> |
| 20:08 | <zcorpan> | Jero: i'm not saying it's a bad idea, i just haven't heard any convincing use-cases for <content> yet |
| 20:09 | <zcorpan> | (i haven't heard convincing use-cases for <footer> either, though) |
| 20:12 | Jero | is brainstorming |
| 20:14 | zcorpan | likes brainstorms |
| 20:16 | <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 |
| 20:41 | <webben> | mpt: hence the scare quotes |
| 20:41 | <webben> | mpt: If it isn't a common typographical style, that doesn't really make the text better. |
| 20:48 | <webben> | zcorpan: Replacing "Skip to main content" links isn't a convincing use case? |
| 20:48 | <webben> | (for <content>) |
| 20:49 | <webben> | also being able to style it properly |
| 20:49 | <webben> | otherwise people are just going to use <div class="content"> anyhow |
| 20:49 | <zcorpan> | webben: isn't the first <article> that? |
| 20:50 | <webben> | zcorpan: Who knows. (Which is kind of the point.) |
| 20:50 | <zcorpan> | what is the main content? isn't it the <article>s? |
| 20:50 | <webben> | zcorpan: whatever the author considers to be the main content. |
| 20:51 | <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? |
| 20:51 | <webben> | zcorpan: e.g. it might include some introductory text before a list of articles |
| 20:51 | <webben> | s/list/series/ |
| 20:53 | <webben> | it might include a <nav> if the whole point of the page is navigation |
| 20:54 | <zcorpan> | like a sitemap? |
| 20:54 | <webben> | zcorpan: sitemaps, indexes, tables of contents, lists of stuff |
| 20:54 | <webben> | tag clouds |
| 20:54 | <webben> | the possibilities are pretty endless |
| 20:55 | <webben> | and often might involve explanatory text too |
| 20:55 | <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 |
| 20:56 | <webben> | zcorpan: yeah that sums it up I guess |
| 20:56 | <zcorpan> | good stuff. now forward this information to the list :) |
| 20:57 | <webben> | has this been being discussed on the whatwg list? |
| 20:57 | webben | wonders if he missed it in the deluge of list mail he receives daily |
| 20:57 | <zcorpan> | what you brought up here is new stuff i think |
| 20:58 | <zcorpan> | <content> has been proposed before but it hasn't been explained really what it's use-cases were |
| 20:58 | <zcorpan> | (beond <article>) |
| 20:59 | <zcorpan> | http://forums.whatwg.org/viewtopic.php?t=35 |
| 21:02 | <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>. |
| 21:04 | <webben> | zcorpan: Except that the main content might be the nav. |
| 21:05 | <zcorpan> | in such a case, couldn't you just not use nav? :) |
| 21:06 | <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. |
| 21:06 | <zcorpan> | since the main use-case for nav, aiui, is exactly to avoid the need for skip links |
| 21:06 | <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. |
| 21:06 | <webben> | zcorpan: Well there are two sorts of skip links |
| 21:06 | <webben> | Type 1: skip /to/ somewhere (typically main content) |
| 21:07 | <webben> | Type 2: skip /over/ something |
| 21:07 | <zcorpan> | right, you can skip to or over a <nav> |
| 21:08 | <webben> | zcorpan: well you can skip to or over a paragraph (if UAs bothered to implement such navigation.) |
| 21:08 | <webben> | but main content is much more of an authorial judgement |
| 21:09 | <zcorpan> | sure |
| 21:13 | <Jero> | zcorpan, just look at http://digg.com/ |
| 21:14 | <Jero> | the "Spreading the Word..." box isn't the main content, the data below that box is |
| 21:15 | <zcorpan> | right. that box might be an aside |
| 21:16 | <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 |
| 21:19 | <Jero> | Hixie, I'd love to hear your opinion on a <content> element |
| 21:20 | <zcorpan> | Jero: it would be great if you (or someone else) could summarize this discussion and send it to the list |
| 21:20 | <Jero> | also a good idea |
| 21:20 | <zcorpan> | Jero: then Hixie will look at it in due course |
| 21:20 | <Jero> | i see |