| 00:29 | <Hixie> | well bummer |
| 00:29 | Hixie | ends up speccing an event that fires on garbage collection |
| 00:29 | <Hixie> | that's clearly not a good plan |
| 00:32 | <Dashiva> | Very interoperable, no doubt :) |
| 00:34 | <Philip`> | Would it be non-conforming to just leak memory and not do GC? |
| 00:34 | <Hixie> | so here's the problem |
| 00:34 | <Dashiva> | You'd still be firing it every time you did GC, so it should be conforming |
| 00:35 | <Hixie> | this is for http://www.hixie.ch/specs/dom/messages/0.9 |
| 00:35 | <Hixie> | what should happen if i create an end point, set its message handler, and then forget about my end of it, having passed the other end to another browsing context? |
| 00:35 | <Hixie> | clearly it shouldn't be garbage collected |
| 00:36 | <Hixie> | as it can still receive messages and respond usefully |
| 00:36 | <Hixie> | but then what happens if my Window is closed? |
| 00:36 | <Hixie> | or navigated? |
| 00:37 | <Dashiva> | Is the strong entangling really needed? |
| 00:37 | <Hixie> | should the other side get an unload event for the endpoint? |
| 00:37 | <Hixie> | how do you mean? |
| 00:37 | <Dashiva> | Instead of just having each endpoint have an "other end" property referring to the other endpoint |
| 00:38 | <Hixie> | i don't understand |
| 00:39 | <Dashiva> | Um. Well, could you treat it the same way any old DOM reference in a different window? |
| 00:40 | <Dashiva> | With window references you have .closed, could something similar work for endpoints? |
| 00:40 | <Hixie> | i can set .active to false |
| 00:44 | <Dashiva> | The problematic event was something like "other endpoint is gone"? |
| 00:44 | <Hixie> | i think i've worked out how to spec it for now |
| 00:44 | <Hixie> | we'll see if it handles Workers too in a second |
| 00:45 | <Dashiva> | What's the reason for cloning endpoints sent via postMessage, by the way? |
| 00:45 | <Hixie> | cross-origin concerns |
| 00:47 | <Hixie> | for example, it would be bad if you could do foreignEndPoint.prototype.prototype.toString = function () { my evil function } |
| 00:47 | <Hixie> | or whatever |
| 00:48 | <Dashiva> | So the create function is usually making one just to throw it away later |
| 00:48 | <Hixie> | yep |
| 00:49 | <Dashiva> | I feel like it should be possible to do it the other way around, creating just one endpoint and having the semantics of send be "The endpoint received should be a new one entangled with this here local endpoint I have" |
| 00:49 | <Hixie> | what if you do it twice? |
| 00:50 | <Hixie> | also, you might want to pass the same end point down several pipes |
| 00:50 | <Hixie> | which you couldn't do the way you describe it |
| 00:51 | <Dashiva> | Aren't those two things mutually exclusive? |
| 00:51 | <Hixie> | hm? |
| 00:51 | <Dashiva> | If you want to pass it down several pipes, you are doing it twice (or more) |
| 00:52 | <Hixie> | say you have established pipes A1<->A2 and B1<->B2, and a newly created pipe C1<->C2. |
| 00:52 | <Hixie> | right now you can pass C2 down from A1 to A2, and then from there it can go from B1 to B2 |
| 00:52 | <Hixie> | but your proposal can't do that, as i understand it |
| 00:53 | <Hixie> | however, your proposal would allow sending "C1's other point" down A1 to A2 creating C2, and then sending "C1's other point" again down A1 to A2, creating C2'? |
| 00:53 | <Hixie> | so now you have two C2s |
| 00:54 | <Hixie> | which is confusing |
| 00:54 | <Hixie> | and causes all kinds of problems |
| 00:54 | <Dashiva> | Let me work this out. So you pass C2 from A1 to A2, which gives A2 a C3 connected to C1. Then you pass C3 from B1 to B2, giving B2 a C4 which is connected to C1. In the process you've invalidated C2 and C3. |
| 00:55 | <Hixie> | yah |
| 00:55 | <Hixie> | (i'd prefer the notation C2, C2', C2'', C2''', but sure :-) ) |
| 00:56 | <Dashiva> | Yeah, I see my idea wouldn't support chaining |
| 00:57 | <Dashiva> | (Unless the endpoint included a pointer to its twin) |
| 00:57 | <Dashiva> | And that's what the cloning was supposed to stop |
| 00:58 | <Hixie> | yeha |
| 00:58 | <Hixie> | yeah, even |
| 00:59 | <Dashiva> | So I suppose I'd be writing function setupLink(w) { p = new Pair(); w.postMessage("New pair",p.two); return p.one; } or somesuch then |
| 01:19 | <Hixie> | hmmmmm |
| 01:19 | <Hixie> | workers have to die if no browsing contexts refer to them |
| 01:19 | <Hixie> | not just if nobody refers to them |
| 01:19 | <Hixie> | otherwise you could have a worker refer to another and vice versa |
| 01:19 | <Hixie> | and they'd keep each other alive |
| 01:33 | <Lachy> | I don't know how to address this comment for selectors api http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0000.html |
| 01:34 | <Hixie> | hm, i wrote that text |
| 01:34 | <Hixie> | or suggested it originally |
| 01:34 | <Hixie> | let's see |
| 01:34 | <Lachy> | I can't figure out how to rephrase it to make it clearer |
| 01:34 | <Hixie> | yeah |
| 01:34 | <Hixie> | User agents should ensure that they do not crash or behave erratically when facing... |
| 01:35 | <Lachy> | that might work |
| 01:35 | <Hixie> | ... For example, a user agent could apply a timeout to the NSResolver callback. |
| 01:35 | <Lachy> | but then I'm not totally convinced of the value of having that in there at all, since the same applies to all scripts |
| 01:36 | <Hixie> | well, the difference here is that the script is driving a UA algorithm |
| 01:36 | <Hixie> | i could easily imagine implementations of the algorithm where returning inconsistent results would cause a crash |
| 01:36 | <Hixie> | this is just saying, "beware" |
| 01:36 | <Hixie> | which is all security sections ever say, really |
| 01:36 | <Lachy> | ok |
| 01:37 | <Hixie> | but i can easily imagine someone not thinking about the fact that the resolver might hang, and accidentally not putting the usual scripting timeout constraints around that api |
| 01:37 | <Hixie> | same with changing the dom |
| 01:44 | <Hixie> | http://www.w3.org/2001/tag/doc/passwordsInTheClear-52 |
| 01:45 | <Hixie> | "User agents SHOULD use password masking when passwords are displayed in an HTML form" |
| 01:45 | <Hixie> | i'm so glad the TAG is addressing critical unsolved problems |
| 01:45 | <Hixie> | and not, say, problems from 1993 |
| 01:53 | <Hixie> | http://www.hixie.ch/specs/dom/workers/0.9 is finally ready for broader review |
| 02:18 | <roc> | the recursive definition of "acceptable" is a bit dogy |
| 02:19 | <roc> | a cycle of WorkerWindows talking to each other but disconnected from all real Windows could be deemed "acceptable", and could also be deemed "not acceptable" |
| 02:21 | <roc> | you also need to say something about what's in scope for these worker threads |
| 02:22 | <roc> | oh I see you've got a one-line comment covering that :-) |
| 02:27 | <Lachy> | is createWorker*() designed to make it possible to run JS as a separate thread in the background? |
| 02:27 | <roc> | yes |
| 02:27 | <Lachy> | cool |
| 02:27 | <roc> | a la Gears |
| 03:08 | <Hixie> | roc: yeah, i thought of that when i defined it (the 'acceptable' thing). i was hoping it would go unnoticed. |
| 03:08 | <Hixie> | fat chance of that, apparently :-) |
| 03:08 | <Hixie> | roc: any idea how to better phrase it? |
| 03:09 | <roc> | something like |
| 03:09 | <roc> | "Acceptability is defined inductively by the following rules:" |
| 03:09 | <Hixie> | (these two proposals are very much early early drafts, by the way, hey'll obviously be defined more rigorously if they ever make a real spec) |
| 03:10 | <Hixie> | roc: is that magic phrasing that makes it better? awesome |
| 03:10 | Hixie | edits |
| 03:10 | <roc> | no |
| 03:10 | <roc> | "1. <a thread with an endpoint whose other end is a real Window, is acceptable>" |
| 03:10 | <Hixie> | oh, there's more, ok |
| 03:10 | Hixie | waits |
| 03:10 | <roc> | "2. <a thread with an endpoint whose other end is an acceptable thread, is acceptable>" |
| 03:10 | <roc> | but yeah, "induction" is actually a magic word here :-) |
| 03:11 | <roc> | you might find it useful to take a class or read a book on methods for formal specification |
| 03:12 | <roc> | a lot of it's less useful than its practitioners wish |
| 03:12 | <roc> | but you might pick up some useful stuff anyway |
| 03:12 | <Hixie> | yeah, i try to read up on stuff like that occasionally |
| 03:12 | <Hixie> | do you have any suggestions? |
| 03:12 | <Hixie> | there's a lot of... less than readable material |
| 03:12 | <roc> | yeah |
| 03:12 | <Hixie> | that's either way over my head, or bogus |
| 03:12 | <Hixie> | i can't tell |
| 03:14 | <roc> | I'll ask my old PhD advisor(s), they're into this sort of thing |
| 03:15 | <Hixie> | cool |
| 03:15 | <Hixie> | that would be awesome |
| 03:16 | <roc> | BTW another way of phrasing those acceptability constraints would be to specify that you want the least solution to the constraints, i.e. the solution that makes the minimum number of workers acceptable |
| 03:17 | <Hixie> | true |
| 03:17 | <Hixie> | ok, i've tried taking your structure and applied it to the draft |
| 03:17 | <Hixie> | http://hixie.ch/specs/dom/workers/0.9 |
| 03:17 | <roc> | that's quite a popular approach, although sometimes defining "minimal" is itself quite tricky |
| 03:18 | <roc> | looks good |
| 03:18 | <Hixie> | cool |
| 03:18 | <Hixie> | thanks |
| 03:28 | <roc> | Hixie: weren't you originally an English major? How much mathematics have you done? |
| 03:28 | <Hixie> | physics |
| 03:28 | <roc> | ah ok cool |
| 03:29 | <roc> | so you probably learned lots of calculus and geometry, which is useless :-) |
| 03:29 | <Hixie> | pretty much |
| 03:29 | <Hixie> | and all the stats i learnt, which would have been useful, i forgot |
| 03:30 | <Hixie> | the scientific method is the main thing i got from my degree which i've applied to the spec work |
| 11:04 | <annevk> | passwordsInTheClear-52 lol |
| 11:06 | <annevk> | I wonder if I should point out a small mistake or not |
| 11:12 | <Lachy> | annevk, what's the mistake? |
| 11:13 | <Lachy> | Is this mail basically asking what string can be used for hasFeature() to test for selectors api? http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0035.html |
| 11:13 | <annevk> | I think so |
| 11:13 | <Lachy> | I don't see a compelling reason to define one |
| 11:14 | <annevk> | Me neither |
| 11:14 | <hsivonen> | if(document.whateverthenamewas) |
| 11:14 | <annevk> | exactly |
| 11:14 | <Lachy> | since hasFeature virtually never gets used int he wild and that alternative already works |
| 11:14 | <annevk> | and since hasFeature must die |
| 11:15 | <Lachy> | :-) |
| 11:16 | gsnedders | stabs hasFeature |
| 11:19 | <annevk> | Lachy, as for -52, the second example they give in the HTML section is something the UA can't know and the Web author does and therefore the Web author doesn't use a password field at all and therefore the example is wrong |
| 11:21 | Philip` | wonders how something like target="_blank-but-with-more-security-separation" would work, since JS code will have to determine whether the UA has that feature before deciding to use it (rather than falling back to window.open tricks) and that seems impossible to determine unless there's some API call that returns true when that feature is supported |
| 11:22 | <annevk> | the same is true for rel=noreferrer |
| 11:22 | <annevk> | oh, maybe rel=noreferrer is the solution? |
| 11:23 | annevk | forgot |
| 11:24 | <Lachy> | annevk, I only see 1 HTML example, which appears to be missing the name attribute |
| 11:24 | <Lachy> | in section 3 |
| 11:24 | <Philip`> | I guess in practice people would just use 'if (navigator.userAgent.indexOf('Firefox/4.0.) == -1) { /* use slow ugly fallback mechanism */ }' if they're not given any better way of determining supportedness |
| 11:25 | <annevk> | Lachy, the text that provides exceptions in terms of examples to the SHOULD-level requirement is what I was talking about |
| 11:25 | <annevk> | Philip`, yeah, transition periods are awkward now and then |
| 11:27 | <Philip`> | We're always in a transition period - nothing is going to settle down and stabilise until it's dead |
| 11:30 | <annevk> | individual features have shorter transition periods than that though |
| 11:30 | <annevk> | I agree that the Web as a whole has a slightly different model :) |
| 11:37 | Philip` | wonders if by 2010 he'll be able to use transparent PNGs without style="-filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(...)" |
| 11:40 | hsivonen | has used transparent PNGs without that kind of stuff since circa 2000 |
| 11:41 | Philip` | also needs the transparency to actually be transparent, and needs to work for a sufficiently large proportion of users |
| 13:04 | <Lachy> | I just have 3 more issues to resolve in selectors api, and I'm done. |
| 13:05 | <annevk> | did you make a simple plain text issues list already? |
| 13:05 | <Lachy> | I'm not sure how to deal with these 2 regarding the IDL (see points 2 and 3 in this mail) http://lists.w3.org/Archives/Public/public-webapi/2007Dec/0072.html |
| 13:05 | <annevk> | point to DOM Bindings and say that we're going to use that |
| 13:06 | <Lachy> | not yet, I've just been tagging the mails in my mail archive. I will write out a list of issues from that later |
| 13:06 | <annevk> | k |
| 13:06 | <annevk> | in due course the Web API WG will use http://www.w3.org/TR/DOM-Bindings/ for its deliverables once that reaches a slightly more stable state |
| 13:07 | <annevk> | so currently the IDL syntax is more of an informative nature, really |
| 13:07 | <Lachy> | the 3rd issue is the one about using XHTML syntax instead of HTML syntax in examples http://lists.w3.org/Archives/Public/public-webapi/2008Jan/0004.html |
| 13:07 | <annevk> | and we do plan to fix that before going to PR |
| 13:07 | <annevk> | changing examples always introduces bugs is my experience |
| 13:08 | <Lachy> | I thought about using DOM Bindings, but wasn't sure, since it's not finished yet |
| 13:08 | <Lachy> | I'll check in my current revision now |
| 13:08 | <annevk> | we'll do DOM Bindings before CR or PR, whenever DOM Bindings itself is in PR/REC |
| 13:09 | <annevk> | (well, that's my idea anyway) |
| 13:13 | <Philip`> | When I buy postage stamps, I want them to have the Queen's head on them, not the word "LOVE" in large pink letters :-( |
| 13:17 | <takkaria> | I wonder why they have LOVE in large pink letters |
| 13:20 | <Lachy> | ann latest version checked in http://dev.w3.org/2006/webapi/selectors-api/ |
| 13:20 | <Lachy> | s/ann/annevk/ |
| 13:30 | Lachy | sends off all responses to the last call comments for selectors api to public-webapi |
| 13:35 | <annevk> | I'm not really convinced with the exceptions story, still |
| 13:35 | <annevk> | even thoug I added them |
| 13:35 | <annevk> | using querySelector to test selector support seems wrong |
| 13:38 | <Lachy> | well, send mail about it to public-webapi and see what others think about the idea of removing exceptions |
| 13:38 | <annevk> | i remember having done that before |
| 13:42 | <Lachy> | you only sent me mail privately |
| 13:42 | <Lachy> | I don't recall seeing any discussion about removing exceptions on the mailing list |
| 13:43 | <Lachy> | here's that feedback I got from mjs about exceptions http://krijnhoetmer.nl/irc-logs/whatwg/20080208#l-17 |
| 13:48 | <annevk> | i'm pretty sure it was on the list too and bjoern didn't like it for similar reasons as maciej or something |
| 13:52 | <Lachy> | if you did, I can't find it in pubilc-webapi |
| 15:26 | <Philip`> | Hmm, Firefox doesn't like setAttribute(':', ...) |
| 15:27 | <gavin> | I think jwalden might have a patch for that? |
| 15:27 | <gavin> | oh, no, I was thinking of bug 411103 |
| 15:29 | Philip` | tries filing https://bugzilla.mozilla.org/show_bug.cgi?id=417491 |
| 15:33 | <gavin_> | data:text/html,%3Cbody%20:=""%20onload=%22try%20{%20document.body.setAttribute(':',%20'');%20alert('OK')%20}%20catch(e)%20{%20alert(e)%20}%22%3E works, though |
| 15:33 | <gavin_> | there's a bug on this already, I think |
| 15:34 | <gavin_> | https://bugzilla.mozilla.org/show_bug.cgi?id=390816 |
| 15:35 | <Philip`> | gavin_: That looks different - ';' should be rejected because it's not a valid XML Name |
| 15:36 | <hsivonen> | Philip`: ":" is not a proper XMLNS name, though |
| 15:37 | <hsivonen> | (although Gecko has a dual XML 1.0 / XMLNS 1.0 nature in some things, IIRC) |
| 15:37 | <Philip`> | hsivonen: DOM just says it should be an XML name - the namespace things only affect setAttributeNS etc |
| 15:39 | <gavin_> | hmm |
| 15:39 | Philip` | gives up trying to work out what DOMs can be safely constructed, and just wraps stuff in exception handlers |
| 15:39 | <annevk> | i think it makes sense to require XMLNS Name |
| 15:40 | <annevk> | so createElement can just become a shorthand for createElementNS(htmlns, name) |
| 15:41 | hsivonen | agrees with annevk |
| 15:41 | gavin_ | tries to understand MOZ_XMLCheckQName |
| 15:41 | <hsivonen> | on a second though, that won't work for XHR |
| 15:41 | <hsivonen> | so, no |
| 15:42 | <hsivonen> | since IE XHR is DOM Level 1, stuff like the Flickr API have to be XML 1.0 without XMLNS |
| 15:42 | <hsivonen> | yay for XMLNS |
| 15:43 | <annevk> | i don't understand |
| 15:43 | <annevk> | xhr requires a conforming xmlns parser |
| 15:44 | <hsivonen> | IE6 doesn't expose a namespace-aware API for XHR-loaded docs, IIRC |
| 15:45 | <hsivonen> | and Safari as shipped with Panther missealized namespaced XML |
| 15:45 | <hsivonen> | so RESTful XML APIs that want to be XHR-compatible have to live in the namespaceless XML 1.0 (< 5th ed.) world |
| 15:45 | gavin_ | gives up trying to understand, uses a debugger instead |
| 15:46 | <hsivonen> | isserialized |
| 15:46 | <hsivonen> | misserialized |
| 15:46 | <hsivonen> | typo++ |
| 15:46 | <annevk> | well namespaceless is fine |
| 15:47 | <annevk> | i'm just saying that they have to compatible with XMLNS for things to work |
| 15:48 | <hsivonen> | sure |
| 15:48 | <Philip`> | http://philip.html5.org/tools/parser/?%3C!DOCTYPE%20HTML%3E%0A%3Cx%3Ax%20x%3Ax%3E%3Cx%3A%3Ax%20x%3A%3Ax%3E%3Cx'x%20x'x%3E%3Cfoo%20%3Ax%3E |
| 15:48 | <Philip`> | Opera, Firefox and Safari all give different output :-( |
| 15:48 | <Philip`> | but at least Opera 9.2 and 9.5 are the same, and Firefox 2 and 3 are the same |
| 16:12 | <annevk> | Philip`, heh, cool stuff |
| 16:17 | <annevk> | weinig, jwalden (if you read this), any feedback on adding reply() ? |
| 16:28 | <aroben> | webben: Aaron's reply is interesting |
| 16:29 | <aroben> | annevk: ^^^ |
| 16:29 | <aroben> | webben: sorry, misdirected that message |
| 16:30 | <annevk> | yeah, though then you want a callback for reply() too for longer conversations... |
| 16:31 | <annevk> | hmm |
| 16:33 | <aroben> | annevk: true |
| 16:33 | <aroben> | annevk: you could end up with some very long callback chains on either end |
| 16:33 | <aroben> | annevk: (well, I guess both ends, since the chains would have to be within one callback of each other in length) |
| 16:34 | <annevk> | yeah, seems icky |
| 16:35 | <annevk> | maybe postMessage should return a uuid and that uuid is exposed on the event |
| 16:35 | <annevk> | and when you invoke reply it automatically uses the same uuid |
| 16:36 | <aroben> | annevk: I guess that would be a little easier than what Gears does |
| 16:36 | <aroben> | annevk: since with Gears you have to embed the ID into your message string |
| 16:36 | <annevk> | yeah, with postMessage() you'd have to do that too now |
| 16:37 | <aroben> | annevk: right |
| 16:48 | <annevk> | ok, posted that idea |
| 16:48 | <annevk> | i have a feeling that hixie's endpoints stuff does similar tricks, we'll see |
| 16:49 | <annevk> | but this proposal is not that more complex than what we have now, so it should be easier to have browsers updated in time with everyone's nearing release dates |
| 16:49 | <aroben> | annevk: "endpoints"? |
| 16:50 | <annevk> | http://hixie.ch/specs/dom/messages/0.9 |
| 16:50 | <annevk> | i haven't carefully checked it yet after asking hixie for more rationale |
| 16:50 | aroben | reads |
| 17:03 | <aroben> | hm, I think there's a typo in the example on that page |
| 17:03 | <aroben> | gadgetWindow.endPoint.postMessage('get list-of-names', event.endPoint); |
| 17:03 | <aroben> | seems like it should just be |
| 17:04 | <aroben> | gadgetWindow.postMessage('get list-of-names', event.endPoint); |
| 17:05 | <aroben> | Hixie: ^^^ |
| 18:04 | <Hixie> | oops. fixed. |
| 18:36 | <Philip`> | Ooh, a tokeniser change - how exciting |
| 18:39 | Philip` | updates his four tokeniser implementations |
| 18:40 | <Hixie> | hah |
| 18:41 | <Hixie> | the graph of time-from-message-being-sent against probability of message being replied that day has a spike at t = 0 days |
| 18:43 | <hsivonen> | Hixie: do you have the graph online? |
| 18:46 | <Hixie> | P| |
| 18:46 | <Hixie> | | |
| 18:46 | <Hixie> | |_ |
| 18:46 | <Hixie> | | | |
| 18:46 | <Hixie> | | | ____ ? |
| 18:46 | <Hixie> | | |___...---''' |
| 18:46 | <Hixie> | | |
| 18:46 | <Hixie> | -+-------------------->t |
| 18:47 | <Hixie> | the start of it -- a few months -- looks like that |
| 18:47 | <Hixie> | dunno what the whole thing looks like |
| 18:47 | <hsivonen> | Hixie: thanks |
| 18:52 | <Philip`> | It's kind of odd how the Ruby html5lib claims to pass all the tokeniser tests, despite it not actually passing |
| 18:53 | <Philip`> | Aha, it does "return expected == received" instead of "assert_equal expected, received" |
| 18:53 | <hsivonen> | hmm. I wonder what the perf implications of query strings are with the new Access-Control-Policy-Path thing |
| 18:53 | hsivonen | rereads the spec |
| 18:54 | <hsivonen> | hmm. looks good |
| 18:55 | <hsivonen> | now awaiting for an access-control-enabled browser, then |
| 18:55 | <hsivonen> | for validation mashups |
| 19:07 | <Philip`> | So, I think the Python and Ruby and OCaml and C++ and JS and Perl tokenisers now match the spec again |
| 19:09 | <Philip`> | http://philip.html5.org/tools/parser/?%3C!DOCTYPE%20HTML%20%225%3E2%22%3E%0A... |
| 19:09 | <Philip`> | Hmm, that totally doesn't work right in Opera 9.2 |
| 19:17 | <zcorpan_> | Philip`: you want http://philip.html5.org/tools/parser/?%3C!doctype%20html%20public%20%22%3E%20X |
| 19:18 | <Lachy> | heh, I love how things are only bugs if one actually claims conformance :-) http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0071.html |
| 19:18 | <hsivonen> | Is RIM a browser vendor these days? |
| 19:18 | <Philip`> | zcorpan_: Argh, good point |
| 19:21 | <Philip`> | Lachy: I assume that means "claim" in the "returns true from hasFeature" sense, not in the "marketing material has it as a bullet pointed feature"; i.e. it would be alright for someone to have an incomplete/buggy implementation if hasFeature says it's not properly supported and shouldn't be used |
| 19:21 | <Philip`> | which seems more reasonable than how I initially read it :-) |
| 19:22 | <zcorpan_> | so if hasFeature returns false for everything, the UA is bug-free? |
| 19:22 | <Lachy> | zcorpan_, yes. |
| 19:22 | <zcorpan_> | awsome |
| 19:22 | Lachy | goes to file a bug for opera about hasFeature returning true for somethings |
| 19:23 | SadEagle | wonders whether there is a feature for hasFeature working... |
| 19:23 | <SadEagle> | Core 2.0 or something? |
| 19:23 | <SadEagle> | So if hasFeature for that returns false, doens't that mean that other return values are irrelevant? :-) |
| 19:23 | <Lachy> | SadEagle, I think it would be covered under the "DOM 2.0" features string (or whatever it is) |
| 19:24 | <zcorpan_> | hasFeature("hasFeature", "1.0") |
| 19:24 | <zcorpan_> | false |
| 19:24 | <zcorpan_> | :) |
| 19:25 | <Philip`> | If you return false for hasFeature then you will get the sort-of-gracefully degraded fallback path that authors have conscientiously provided for user agents that don't have the feature, and your users will hate you because they get a degraded experience, and so market forces will compel you to implement the feature perfectly so you can return true from hasFeature |
| 19:28 | <Lachy> | everything should just be implemented perfectly in every browser on the first attempt, and then hasFeature can be changed from a method to a single property that just equals true. |
| 19:30 | <SadEagle> | Philip`: might be interesting to see how many websites actually use hasFeature |
| 19:32 | <Philip`> | http://google.com/codesearch?q=show:mUNqRgxPl_s:oKMDwuYvdP4:CNlRzrngUHA&cs_p=http://www.devlib.org/apache/struts/source/struts-2.0.6-src.zip&cs_f=struts-2.0.6/src/core/src/main/resources/org/apache/struts2/static/dojo/dojo.js.uncompressed.js#l1157 |
| 19:32 | <Philip`> | There's one |
| 19:33 | <Philip`> | http://google.com/codesearch?q=show:BNeIttp5oHc:5g2Z17w4TXQ:BXCuyDas2KE&cs_p=http://openrico.org/svn/openrico/trunk&cs_f=openrico/public/dist/1.1.2/rico.js#l1337 |
| 19:34 | <Philip`> | http://google.com/codesearch?q=show:UWuK4cTDdZc:A3Gk8FzZWSM:L1InoVp7Omk&cs_p=http://gentoo.osuosl.org/distfiles/Plone-2.1.4.tar.gz&cs_f=Plone-2.1.4/kupu/common/sarissa_ieemu_xpath.js#l26 |
| 19:34 | <Philip`> | It seems easy to find quite a few |
| 19:36 | <SadEagle> | heh, #1 follows it up with a UA sniff. #2 uses IE-specific path as a fallback, and will fail in konqueror, since it tests for "CSS", "2.0" --- odd thing to test if you want -events- support. #3 actually looks right :-) |
| 20:32 | <zcorpan_> | "Making an implementation bug-free is outside the scope of the specification." -- http://www.w3.org/mid/24BE9C481C439C48831EB9E52639B9B60A8D4842⊙Xrn |
| 20:32 | <zcorpan_> | hmm, perhaps i have misunderstood the purpose of having specs |
| 20:34 | <SadEagle> | it's to say what 'bug-free' means :-) |
| 20:35 | <zcorpan_> | i think its time for me to finetune my ignore flag again |
| 20:36 | <gsnedders> | I'm bug free. |
| 20:53 | <Lachy> | zcorpan_, technically that statement is correct, depending on how you read it. It's the implementor's responsibility to actually write the bug free code, not the specification. But it is the specification's responsibilty to ensure that things are defined well enough to be implemented in bug free ways |
| 21:42 | <gsnedders> | RFC3986 doesn't reference RFC2119! |
| 21:42 | gsnedders | is amazed |
| 21:45 | <SadEagle> | they don't capitalize SHOULD/MAY/etc. |
| 21:45 | <Dashiva> | http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0076.html |
| 21:45 | <Dashiva> | what on earth |
| 21:46 | <Hixie> | Sent from Yahoo! Mail - a smarter inbox |
| 21:51 | <annevk> | Lachy, one other thing to consider btw is to call StaticNodeList NodeList again and mention specifically that DOM Level 3 Core (and maybe previous versions) contains a bug as it calls it a live list where it just defines an interface |
| 21:52 | <Hixie> | isn't that what i said at the time :-P |
| 21:53 | <annevk> | i was convinced, but some other people were not |
| 21:53 | <annevk> | probably easier to get it through now, especially with webkit already doing it that way! |
| 21:54 | <annevk> | man, these SMIL people are pushy |
| 21:55 | <Hixie> | hm? |
| 21:56 | <annevk> | not really |
| 21:56 | <annevk> | just getting quite a bit of e-mail about this timesheets draft |
| 21:57 | <Hixie> | timesheets? |
| 21:57 | <Hixie> | wtf is that |
| 21:57 | <gsnedders> | That widely implemented draft, obviously. |
| 21:58 | <Lachy> | That would be easier |
| 21:58 | <Lachy> | I had assumed that window.DocumentSelector and window.ElementSelector would be exposed, since the interfaces for other DOM2 APIs are exposed |
| 21:58 | jgraham | assumes timesheets is for doing things that were common on 90s era CD-ROMS |
| 22:00 | <Lachy> | aargh! What is wrong with Sergey's email client? Why is it putting one word per line?! |
| 22:00 | <hsivonen> | one of the spec editors demoed me timesheets |
| 22:00 | <annevk> | I think DocumentSelector and ElementSelector should not be exposed on Window |
| 22:00 | <hsivonen> | the demoed use case was doing S5 without the JS |
| 22:00 | gsnedders | bravely presses send |
| 22:00 | <annevk> | they are redundant |
| 22:00 | <annevk> | hopefully DOM Bindings provides a way to say that |
| 22:01 | <hsivonen> | I quite liked the Apple CSS animation stuff for transitions and the like |
| 22:01 | <annevk> | yeah, we need that |
| 22:01 | <SadEagle> | Lachy: are DocumentTraversal, DocumentViews, ElementTarget, DocumentStyle, etc. exposed? |
| 22:01 | <hsivonen> | fits what already is there much better than SMIL |
| 22:01 | <annevk> | but the $%# CSS WG declared it out of charter |
| 22:02 | <jgraham> | I don't claim my assumptions about the purpose of timesheets are at all accurate |
| 22:02 | <Lachy> | SadEagle, Firefox exposes DocumentTraversal and DocumentStyle |
| 22:03 | <SadEagle> | Odd. But then the entire thing is a mozillaism everyone else had to emulate, making it a defacto standard :-) |
| 22:03 | <annevk> | SadEagle, EventTarget should be exposed, not sure what ElementTarget is |
| 22:03 | <SadEagle> | It's a very problematic thing to do, though. |
| 22:03 | <annevk> | I agree that exposing DocumentStyle and such makes no sense |
| 22:03 | <SadEagle> | annevk: that's what I meant... And I guess EventTarget makes sense, since it can be used as a base class. |
| 22:03 | <SadEagle> | Well, what should DocumentStyle.prototype point to? |
| 22:04 | <Lachy> | FF exposes EventTarget too. WebKit doesn't seem to expose any of them |
| 22:04 | <annevk> | probably maps to Document.prototype |
| 22:04 | <annevk> | I don't really like what Firefox does with interfaces at all |
| 22:04 | <Lachy> | why not? |
| 22:05 | <annevk> | there's now some Web content that relies on XMLDocument and HTMLSpanElement, HTMLUnknownElement and crap like that |
| 22:05 | <Lachy> | It makes sense for the ones that define constants, like Node.ELEMENT_NODE |
| 22:05 | <annevk> | well, that stuff makes sense |
| 22:05 | <annevk> | that stuff is also far more interoperable than what we're discussing here |
| 22:06 | <Hixie> | good lord, the html wg is considering even more mailing lists |
| 22:07 | <Lachy> | Hixie, what more mailing lists are being considered? |
| 22:07 | <Hixie> | see #html-wg |
| 22:07 | <SadEagle> | annevk: those are the interfaces they have aren't in the DOM, right? |
| 22:10 | <annevk> | yeah |
| 22:17 | Lachy | ponders the idea of adding a hasFeature string to selectors api that implementors are not required to support :-) |
| 22:18 | <Dashiva> | hasFeature('Selectors.hasFeature') |
| 22:19 | <Hixie> | good to know that the chair of the html working group doesn't read all the mail to the html working group |
| 22:22 | jgraham | doesn't find that too encouraging |
| 22:23 | gsnedders | wonders how many do |
| 22:23 | <jgraham> | Chairs of the WG or participants in general? |
| 22:23 | <gsnedders> | everyone in the WG |
| 22:23 | <annevk> | I skim each e-mail, though I delete some right away based on subject/sender |
| 22:24 | <annevk> | (that's not specific to the HTML WG though) |
| 22:24 | <Hixie> | i read everything, and save anything that looks useful to the folders for further study later |
| 22:25 | <Hixie> | i read public-html (and whatwg, and public-appformats and -webapi) before reading anything from the groups i'm not as actively in, like css or tag or http |
| 22:25 | <jgraham> | I ignore anything to do with <abbr> vs <acronym> as a matter of course. And occasionally I never get round to reading some messages. |
| 22:25 | <gsnedders> | I skim most things, though there are some things which I know so little about I just ignore from the subject |
| 22:26 | <Philip`> | I tend to look at all the words in everything, but I'm not sure if it counts as reading |
| 22:26 | <Philip`> | Mostly it's just a way of getting rid of the 'unread messages' marker |
| 22:27 | <Hixie> | yeah well some e-mails certainly don't get a very thorough reading |
| 22:27 | <Hixie> | especially those written in reply to e-mails that themselves didn't seem to get a thorough reading |
| 22:27 | <Hixie> | and i rarely spend more time reading an e-mail than the other person spent writing it |
| 22:28 | <Hixie> | (or thinking about it) |
| 22:28 | <gsnedders> | Hixie: I guess that means 10 seconds for most of my emails :) |
| 22:28 | <gsnedders> | (sadly) |
| 22:30 | <Hixie> | :-) |
| 22:33 | <annevk> | http://weblogs.mozillazine.org/doron/archives/2008/02/exe_tld_coming_soon.html :o |
| 22:33 | gsnedders | squints |
| 22:33 | <SadEagle> | that's not a new issue, though, see .pl :-) |
| 22:33 | <gsnedders> | silly Poland, thinking they deserve a TLD! |
| 22:34 | <gsnedders> | Or perhaps: Why's that relevant? I mean, who uses perl nowadays? |
| 22:35 | <annevk> | SadEagle, heh, true |
| 22:35 | gsnedders | is too tired to be truly witty |
| 22:35 | <annevk> | SadEagle, well, actually, .pl is not handled by the browser |
| 22:35 | <Hixie> | i'm mildly amused at how the w3c staff (except for mike) aren't actually an active part of the html5 community, despite them making process decision on the htmlwg |
| 22:36 | <annevk> | i don't really like it |
| 22:37 | <SadEagle> | annevk: it could be though, viewed as text... I am not sure where this distinction matters in mozilla, though (it showed up in KDE, but that was outside a web browser) |
| 22:38 | <annevk> | i wonder where browsers do extension sniffing though |
| 22:38 | <annevk> | HTML5 contains no such thing! |
| 22:38 | <roc> | there's also .au |
| 22:38 | <Hixie> | browsers do extension sniffing in the places where html5 explicitly says not to do extension sniffing |
| 22:39 | <roc> | there was a famous Gecko bug that only happened on files downloaded from Australia |
| 22:39 | <roc> | that took a while to figure out |
| 22:39 | <Hixie> | hah |
| 22:42 | gsnedders | waves g'nite |
| 22:44 | <Hixie> | 'course if .com is no problem, why would .exe be a problem |
| 22:46 | <Philip`> | http://eicar.com/download/eicar.com |
| 22:48 | <annevk> | Dashiva, you registered? |
| 23:09 | <Dashiva> | annevk: Where? |
| 23:11 | <annevk> | freenode, nm though, you're on w3.org too :) |
| 23:39 | <Hixie> | Philip`: the reason one is a list and one is as stack (despite neither being either) is exactly because it makes them easier to distinguish |