| 00:46 | <Lachy> | Hixie, in web workers, this sentence is grammatically incorrect: "The origin and effective script origin of scripts running in workers are both the origin of the absolute URL given by the value of the URL attribute of the worker's WindowWorker object." |
| 00:47 | <Lachy> | it says "are both", but then it only mentions one thing |
| 00:48 | <Hixie> | in english, verbs are conjugated relative to the subject, not the object |
| 00:48 | <Lachy> | what? |
| 00:49 | <Hixie> | two apples are a pear |
| 00:49 | <Hixie> | not two apples is a pear |
| 00:49 | <Hixie> | similarly, an apple is two pears |
| 00:49 | <Hixie> | not an apple are two pears |
| 00:50 | <Lachy> | my problem is with the word both, not the word are |
| 00:50 | <SadEagle> | May I suggest "Both the origin and effective script origin of scripts running in workers are the absolute URL given by the value of the URL attribute of the worker's WindowWorker object." |
| 00:50 | <Hixie> | the word both in that sentence is also relating to the subjects |
| 00:50 | <Hixie> | a and b are both letters |
| 00:50 | <Lachy> | then SadEagle's suggestion makes more sense |
| 00:51 | <SadEagle> | Yeah, but that's a syntactic ambiguity. My mind parsed is the same as Lachy's. |
| 00:51 | <Hixie> | fair enough |
| 00:51 | <Hixie> | changed |
| 00:52 | <SadEagle> | Hixie: may I abuse you to clarify the definition of CSS2.1's clip property? |
| 00:52 | <Hixie> | you can try but i make no promises of knowing the answer |
| 00:53 | <SadEagle> | It just seems to be defined to be off top-right corner for RTL direction, and everyone seems to implement to alway sbe off the top-left corner... Unless direction:rtl somehow reversed the meaning of left and right borders... |
| 00:53 | <Hixie> | i have no idea how it is supposd to interact with directionality |
| 00:54 | <SadEagle> | fair enough, thanks for your time :-) |
| 01:06 | <Hixie> | ok sicking has convinced me to remove Window from workers |
| 01:06 | <Hixie> | what should we call the global object? |
| 01:18 | <Philip`> | Linuk |
| 01:25 | <Hixie> | he suggested WorkerGlobalScope, with that object only containing two members, "self" pointing to itself, and "utils" pointing to a separate object with APIs |
| 01:25 | <Hixie> | so you'd do utils.openDatabase() etc |
| 01:26 | <Hixie> | not sure if you'd need to do |new utils.XMLHttpRequest()| or if we'd still have constructors in the global scope |
| 01:26 | <Hixie> | he vanished before i could ask |
| 01:29 | <Lachy> | Hixie, in step 6 of "When a script invokes the import(url) method...", it says "or gets prematurely aborted by the "kill a worker" algorithm below." - s/below/above/ |
| 01:30 | <Hixie> | thx |
| 01:38 | <Lachy> | Hixie, is URL_MISMATCH_ERR a new exception code that you invented for this, or is it defined somewhere other than DOM3Core? |
| 01:38 | <Hixie> | invented |
| 01:38 | <Lachy> | ok |
| 01:39 | <Lachy> | I guess that's the reason for the "Code 19" issue after it |
| 01:39 | <Hixie> | it's on the list in the wiki :-) |
| 01:39 | <Lachy> | which page? |
| 01:40 | <Hixie> | exception codes |
| 01:42 | <Lachy> | oh, nice. SECURITY_ERR is useful. |
| 01:42 | <Lachy> | but there doesn't appear to be any response to your proposal for it on public-webapi |
| 01:45 | <Hixie> | we so need someone to own DOM Core and actually write the spec |
| 01:47 | <Lachy> | is there anyone in webapps who's supposed to be working on it? |
| 01:47 | <Lachy> | or is zcorpan still intending to write DOM5 one day? |
| 01:47 | <Hixie> | dunno |
| 01:49 | <Lachy> | ok. well, if no-ones working on it by the time I get Selectors API to CR, then I might pick it up. |
| 01:50 | <Lachy> | also, I might have to incorporate :context/:scope directly into Selectors API. I got no response from the CSSWG saying whether or not the proposal has been accepted or rejected, and it really needs to get done before browsers ship with selectors api |
| 01:51 | <Lachy> | I should probably wait till anne gets back, since hes our csswg rep |
| 01:56 | <Hixie> | i've found that just doing things and letting people know is an effective incentive for them to get their act together |
| 01:56 | <Hixie> | ask for forgiveness, not permission, and all :-) |
| 01:59 | <jcranmer> | hmm, that's the first and, to date, only discussion I've participated in on the W3C mailing list |
| 02:01 | <jcranmer> | (debate over whether or not scoping stylesheets should refer to rerooting the selection tree or merely limiting the possible set of nodes to match) |
| 02:03 | <Lachy> | jcranmer, looks like you've participated in 2 other threads as well |
| 02:04 | <Lachy> | with just one message each, though |
| 02:04 | <jcranmer> | I made a response and didn't follow up |
| 02:04 | <jcranmer> | that doesn't count in my book |
| 02:04 | <Lachy> | ok, so participation requires at least 2 posts per thread? |
| 02:04 | <jcranmer> | well, maybe the later one counts |
| 02:05 | <jcranmer> | since I did rebutt a point |
| 02:05 | <jcranmer> | the other one was "oh, we've already done that, look here:" |
| 02:05 | <Lachy> | I like people who contribute once, say what they need and leave. It makes reading the thread so much easier and non-repetitive |
| 02:06 | <jcranmer> | I guess I prefer my discussions... back-and-forth |
| 02:06 | <jcranmer> | so long as both sides are understanding each other |
| 02:06 | <jcranmer> | if not, it's only a giant shouting match |
| 02:06 | <Lachy> | Hixie, the workers spec would be a lot easier for me to comprehend if the unwritten tutorial section was actually written demonstrated how the API was intended to be used |
| 02:07 | <Hixie> | yeah i intend to write that section tonight |
| 02:07 | <Lachy> | oh good. Then I should have waited a day before reviewing the spec :-) |
| 02:07 | <Hixie> | heh |
| 02:07 | <Hixie> | i just checked in big changes |
| 02:08 | <Lachy> | well, I aint reading it again yet it was hard enough the first time |
| 02:08 | <Hixie> | hah |
| 02:16 | <Hixie> | hmmmm |
| 02:17 | <Hixie> | one way to solve the problem that was being discussed the other day is to make the first port that a worker receives be automatically assigned to a variable in the global scope |
| 02:17 | <Hixie> | that way you can never hit the case where you GC straight away |
| 02:20 | <Hixie> | ports could also be simplified by having them queue events until such time as someone enables them manually |
| 06:59 | <hsivonen> | Hixie: ARIA has aria-hidden=true for irrelevant='' |
| 07:27 | <hsivonen> | I just realized I broke my promise not to use SVG in hypothetical examples. |
| 07:52 | <Hixie> | hsivonen: aria-hidden="" isn't accessible, as i understand it (since it doesn't do anything except for ATs) |
| 07:54 | <hsivonen> | Hixie: you are supposed to use it together with *[aria-hidden="true"] { display:none; } |
| 07:55 | <hsivonen> | Hixie: doesn't work with non-CSS non-AT UAs, though. |
| 07:55 | <hsivonen> | unless those UAs start triggering on ARIA |
| 07:56 | <Hixie> | CSS is optional, anything that relies on CSS is not accessible almost by definition :-) |
| 07:56 | <Hixie> | isn't triggering on ARIA specifically counter to ARIA? |
| 07:57 | <hsivonen> | Hixie: yes and yes |
| 07:57 | <hsivonen> | are there contemporary UAs that support JS but not CSS? |
| 09:01 | <Hixie> | heycam: can't we have some flag on the interface that says that HasProperty returns true for anything that NamedGetter would find, or something? |
| 09:01 | <Hixie> | i don't want to have to spec this all over the place if i can help it :-) |
| 09:02 | <heycam> | Hixie, but it's more than that. Object.prototype.hasOwnProperty() returns true, too. |
| 09:02 | <heycam> | so they're real properties |
| 09:02 | <Hixie> | ok, well then a flag that says that then |
| 09:02 | <Hixie> | (i have no idea what that means :-) ) |
| 09:02 | Hixie | looks up hasOwnProperty |
| 09:02 | <heycam> | so, ecma-262 defines Object.prototype.hasOwnProperty as just returning true if the object has such a property |
| 09:03 | <Hixie> | so we can define an interface attribute says specifies that the object has, in addition, properties for each of the things that namedgetter would return, or something |
| 09:03 | <Hixie> | or, alternatively: |
| 09:04 | <Hixie> | define a spec "hook" that i can refer to which automatically defines all of NameGetter, IndexGetter, etc |
| 09:04 | <heycam> | yeah i think a spec hook sounds better |
| 09:04 | <Hixie> | e.g. so that I can just write: |
| 09:05 | <Hixie> | "The BlaBla interface is a _Magical Land of Fairies_ in which the properties are the list of blablas, and for which the _Magical Fairy Setter Operation_ is foobarbaz." |
| 09:05 | <Hixie> | or whatever |
| 09:05 | <Hixie> | (not sure exactly what i would need to hook up each time) |
| 09:06 | <heycam> | i think you just need to define a set of (name, value) pairs, and call the hook with that |
| 09:06 | <Hixie> | or alternatively, have an attribute to enable this magic, and then say that the prose must define the _List Of Pixies_ and the _Pixie Getting_ and _Pixie Setting_ operations |
| 09:06 | <heycam> | yeah |
| 09:06 | <Hixie> | i think i need a list and an operation for setting, since that's usually non-trivial on my end |
| 09:06 | <Hixie> | and maybe deleting, if we decide we are ever going to support 'delete foo' |
| 09:07 | heycam | enqueues |
| 09:08 | <heycam> | will it be anything more than 'nodes in the document that match these criteria'? |
| 09:08 | <heycam> | anyway, bbl |
| 09:09 | <Hixie> | probably |
| 09:09 | <Hixie> | (e.g. localStorage) |
| 09:52 | <Hixie> | does anyone have an example of some mathematical sequence that would be useful to calculate, is simple to code, but which takes a disproportionally high amount of processor time to calculate? |
| 09:52 | <Philip`> | Prime numbers? |
| 09:52 | <Hixie> | and for which numbers can be obtained one after the other as computation continues? |
| 09:53 | <webben> | hsivonen: I think http://www.webbie.org.uk/ might be an example. |
| 09:53 | <Hixie> | prime numbers could work |
| 09:53 | <webben> | (it's a weird customization of IE used with Thunder: http://www.screenreader.net/ ) |
| 09:53 | <webben> | hsivonen: (example of "contemporary UAs that support JS but not CSS" that is) |
| 09:54 | <Philip`> | http://www.research.att.com/~njas/sequences/ has a lot of sequences |
| 09:54 | <othermaciej> | Hixie: what counts as "disproportionately high"? |
| 09:54 | <webben> | hsivonen: also http://edbrowse.sourceforge.net/ though I'm not sure how actively developed that is. |
| 09:54 | <othermaciej> | the naiive way to code fibonacci is pretty slow |
| 09:54 | <Hixie> | othermaciej: like, something which would take a minute to give 10 numbers |
| 09:54 | <othermaciej> | ackerman is inherently slow |
| 09:55 | <Hixie> | i'm gonna try a very naive prime number search |
| 09:55 | <Hixie> | and see if that's slow enough for a worker demo |
| 09:55 | <othermaciej> | that won't take a minute to give 10 numbers |
| 09:55 | <Hixie> | it might if i start it high enough :-) |
| 09:55 | <othermaciej> | calling ack() with large-ish parameters would though |
| 09:55 | <Philip`> | There's no non-naive algorithm that will take a minute to give 10 numbers |
| 09:56 | <Philip`> | because you could rewrite it as "function f() { return [ 12376, 9162, 649, ... ] }" |
| 09:56 | <Philip`> | which is a less naive algorithm |
| 09:56 | <Philip`> | so I suppose you'll have to use some artificial pointless example instead |
| 09:57 | <othermaciej> | you can pass in a parameter asking what number |
| 09:57 | <othermaciej> | to ensure a lookup table would have to be impractically large |
| 09:58 | <othermaciej> | numerically estimating a definite integral might be slow enough |
| 09:58 | <othermaciej> | given the right integrand |
| 10:02 | Hixie | has just written the world's simplest yet the world's most advanced prime number search program ever |
| 10:02 | <Hixie> | so simple it's 13 lines of JS, so complex it won't work in any Web browser today! |
| 10:02 | <Hixie> | http://www.whatwg.org/demos/workers/compuation/ |
| 10:03 | <Hixie> | renamed to http://www.whatwg.org/demos/workers/primes/ |
| 10:06 | <hendry> | Hixie: doesn't work for me. first time i've seen syntax like var worker = createWorker('worker.js'); |
| 10:06 | <Philip`> | You should only loop up to i <= Math.sqrt(n) else it's unnecessarily inefficient |
| 10:07 | <Hixie> | Philip`: might that not distract from the point of the code? |
| 10:07 | <Hixie> | hendry: that's how advanced it is |
| 10:07 | <Hixie> | Philip`: (fixed) |
| 10:08 | <Philip`> | It would distract me less than the obvious easily-fixable inefficiency would :-) |
| 10:08 | <Hixie> | :-) |
| 10:11 | <Philip`> | Obviously the next step is to develop a multithreaded general number field sieve in JS |
| 10:12 | <Hixie> | if that would make a good example, please do so, i can fill in the worker-related bits |
| 10:12 | <mcarter> | Hixie, well, the chicken/egg question is answered -- real people are writing real code with calls to createWorker. so what are the browser vendors waiting for? |
| 10:12 | <jacobolus> | Philip`: because otherwise this is super-efficient code! |
| 10:12 | <Hixie> | mcarter: :-P |
| 10:13 | <jacobolus> | mcarter: you should tell them |
| 10:13 | <Philip`> | Hixie: I wasn't being serious :-p |
| 10:14 | <Hixie> | Philip`: aww :-( |
| 10:14 | <Philip`> | A C++ version at http://factor-by-gnfs.cvs.sourceforge.net/factor-by-gnfs/gnfs/ looks non-trivial |
| 10:14 | <mcarter> | jacobolus, if they don't know now, they should know on their own in the morning. At least some of them. |
| 10:14 | <iarwain> | Sorry for this off-topic question: What IRC logging software does this channel use? |
| 10:14 | <jacobolus> | why in the morning? |
| 10:14 | <Hixie> | iarwain: krijnh rolledh is own, i believe |
| 10:15 | <iarwain> | Hixie: oh, ok. Thanks. |
| 10:30 | <Hixie> | http://www.whatwg.org/specs/web-workers/current-work/#tutorial |
| 10:30 | <Hixie> | first example |
| 10:30 | <Hixie> | is the style ok? |
| 10:32 | Lachy | is reading it now |
| 10:32 | <hsivonen> | webben: thanks. the first one of those two while a UA is not a browser, it seems |
| 10:33 | <webben> | hsivonen: Not sure quite what distinction you're drawing? |
| 10:33 | <webben> | what's the difference between using it and IE itself in that sense? |
| 10:35 | <hsivonen> | webben: oops. I skipped the word "browser" and saw "Accessible RSS news reader" |
| 10:36 | <hsivonen> | webben: it's for the blind, though, so it presumably is OK for it to key its presentation off ARIA |
| 10:37 | <webben> | hsivonen: It uses Trident so it's conceivably possible it would apply display:none; by not displaying that text; one would have to test that (or email the dev) to confirm I guess. |
| 10:37 | <Lachy> | Hixie, the port variable isn't mentioned anywhere else in the spec, AFAICS |
| 10:37 | <webben> | hsivonen: Yeah, I guess it will get ARIA with IE8. |
| 10:39 | <Hixie> | Lachy: fixed |
| 10:41 | <hsivonen> | webben: anyway, it seems that Hixie's "not accessible" scenario needs a visual UA that cannot be considered constituting AT in any way that doesn't support CSS and that supports scripting the DOM with JS |
| 10:42 | <Hixie> | e.g. firefox (with styles disabled) |
| 10:43 | <webben> | hmm ... "cannot be considered constituting AT" seems a rather high bar to set (especially since, as Hixie mentioned, rejecting publisher CSS can itself be an accessibility feature) |
| 10:44 | <webben> | I wonder if there's mobile browser that does that though. |
| 10:44 | <Hixie> | links also supports JS, as i understand it |
| 10:44 | <webben> | links doesn't (I /think/) ; but ELinks sort of does. |
| 10:45 | <hsivonen> | that must have been fun to hack in considering the level of documentation in the Links codebase |
| 10:45 | <webben> | but ELinks also supports CSS. |
| 10:45 | <Lachy> | Hixie, where is the MessagePort interface defined? Did it get renamed to something else? |
| 10:45 | <Hixie> | also, ARIA, if i'm not mistaken, is only supposed to be used to expose things to the system accessibility apis, it's not supposed to be natively interpreted by the UA. (but i'm not sure i really follow aria's goals and requirements) |
| 10:45 | <Hixie> | (so i could be wrong) |
| 10:45 | <Hixie> | Lachy: html5 |
| 10:45 | <hsivonen> | is ELinks a rewrite or does it actually build on the original Links? |
| 10:46 | hsivonen | one considered hacking on Links as a weekend project and gave up after seeing the source |
| 10:46 | <webben> | Hixie: Not sure that's right actually. |
| 10:46 | <hsivonen> | s/one/once/ |
| 10:46 | <webben> | hsivonen: dunno; ask in #elinks ;) ... I have a vague memory it's a partial rewrite. |
| 10:52 | <Lachy> | Hixie, why is the port property added seperately, instead of being defined in the interface and just set accordingly? |
| 10:53 | <Hixie> | because webidl doesn't yet have the concept of replaceable properties, and i want authors to be able to delete it or replace it or whatever, since it indirectly controls the lifetime of the worker |
| 10:53 | <Lachy> | ok |
| 11:07 | <Lachy> | hsivonen, given the new alt text requirements, how are you intending to adjust your validator? Will it now raise an error when alt is missing? |
| 11:27 | <hsivonen> | Lachy: I'm going to wait until accessibility advocates come back from vacation and the PFWG responds to the petitions of PFWG participants petitioning the PFWG as HTML WG participants and then Hixie responding to the response. |
| 11:31 | <Hixie> | can someone look over http://www.whatwg.org/demos/workers/stocks/ and tell me (a) what parts need explaining and (b) what parts have errors? The intro to this is at http://www.whatwg.org/specs/web-workers/current-work/#a-worker0 |
| 11:31 | <gDashiva> | hsivonen: It's a bit disheartening when it sinks in that you're not even joking :) |
| 11:33 | <gDashiva> | Hixie: for..in on an array is kinda meh |
| 11:34 | <Hixie> | fixed |
| 11:34 | <gDashiva> | Not setting button.type that I can see |
| 11:35 | <gDashiva> | li.appendChild(a) should probably be (button)? |
| 11:35 | <Hixie> | doesn't it default to 'button'? |
| 11:35 | <Hixie> | oops, yes |
| 11:35 | <gDashiva> | Hixie: only in IE :) |
| 11:36 | <Hixie> | fixed and fixed |
| 11:37 | <Philip`> | I guess you might miss the first messages sent from the workers, since onmessage isn't set until a later script block after creating them |
| 11:37 | <Philip`> | which sounds suboptimal |
| 11:37 | <Hixie> | the messages are queued until you set onmessage (or call .start() on the port) |
| 11:38 | <Philip`> | Oh, okay |
| 11:39 | <Hixie> | though actually in this case it makes no difference since the workers don't send data until it is requested |
| 11:39 | <Hixie> | oh actually, no, you're right, it would make a difference |
| 11:39 | <Hixie> | since we postMessage() first |
| 11:39 | <Hixie> | nm |
| 11:39 | <Hixie> | but anyway, not a problem |
| 11:39 | <Hixie> | i'll comment on that in the prose |
| 11:40 | <gDashiva> | If stock.cgi is slow (or just slow net), you'll get time shift on the ticker timer |
| 11:40 | <Philip`> | http://www.whatwg.org/demos/workers/stocks/io.js tries to uses async XHR but returns the responseText without waiting for the response |
| 11:40 | gDashiva | shakes fist at Philip` |
| 11:40 | <gDashiva> | I was gonna say that now :) |
| 11:40 | <Hixie> | time shift? |
| 11:40 | <Hixie> | oh, "true" is async? oops |
| 11:40 | <Hixie> | man who makes APIs with optional arguments that default to true |
| 11:40 | <gDashiva> | Hixie: You'll get updates at 10s, 20s+delay, 30s+2xdelay, etc |
| 11:41 | <Hixie> | gDashiva: that's ok, better than overloading the server :-) |
| 11:41 | <Hixie> | Philip`: fixed, thanks |
| 11:41 | <gDashiva> | kk |
| 11:42 | <Philip`> | http://www.whatwg.org/demos/workers/stocks/ticker.js puts a semicolon after the function statement, which is inconsistent with the rest of the code |
| 11:42 | <gDashiva> | No, it's an assignment |
| 11:42 | <Hixie> | oops fixed, thanks |
| 11:42 | <Hixie> | he means the first one |
| 11:42 | <gDashiva> | Oh, my bad |
| 11:44 | <gDashiva> | Now we just need a script to fake createWorker :) |
| 11:45 | <Philip`> | If there's a temporary network error then an exception will be thrown out of get(), and the ticker will permanently silently stop updating |
| 11:46 | <Hixie> | reload io.js |
| 11:46 | <Hixie> | does that work? |
| 11:47 | <Philip`> | I think so |
| 11:56 | <gDashiva> | 500 when you access search.cgi without a query :) |
| 11:58 | <Philip`> | 500 when you access it with a query, too |
| 11:58 | <Philip`> | Oh, no, it worked this time |
| 11:58 | <Hixie> | just finished writing them |
| 11:59 | <Philip`> | http://www.whatwg.org/demos/workers/stocks/search.cgi?%00 gives a peculiar error message |
| 11:59 | <Hixie> | heh |
| 12:00 | <Hixie> | appears to be an apache bug |
| 12:00 | <Hixie> | works ok at the command line |
| 12:00 | <zcorpan> | Hixie: isn't it try/catch, not try/except (in io.js)? |
| 12:00 | <Philip`> | Why does http://www.whatwg.org/demos/workers/stocks/search.cgi?GO return BGLH? |
| 12:01 | <Hixie> | because it matches "Goodger", which has stock ticker BGLH |
| 12:01 | <Hixie> | zcorpan: fixing |
| 12:01 | <Philip`> | Oh |
| 12:01 | <Hixie> | search with a blank string to see all the symbols it knows |
| 12:02 | <Hixie> | there's no way to determine what labels it is matching them against though |
| 12:02 | <Hixie> | short of a brute force attack |
| 12:02 | hsivonen | learns that the participant list of some W3C WGs is visible to Members only |
| 12:03 | <Philip`> | It seems kind of bad that http://www.whatwg.org/demos/workers/stocks/search.cgi?%47 doesn't work |
| 12:03 | <zcorpan> | http://www.whatwg.org/demos/workers/stocks/search.cgi?%00 gives 503 |
| 12:04 | <Philip`> | zcorpan: Old :-p |
| 12:04 | <zcorpan> | oh |
| 12:04 | <Hixie> | Philip`: for %xx -- eh, whatever :-) |
| 12:11 | <hsivonen> | I wonder which ones are most common: unquoted, double-quoted or single-quoted attributes |
| 12:11 | <hsivonen> | my guess is double-quoted |
| 12:11 | <Philip`> | Double-quoted, then single-quoted, then unquoted |
| 12:12 | <hsivonen> | Philip`: thanks |
| 12:12 | <Philip`> | or maybe not |
| 12:12 | <Philip`> | s/maybe// |
| 12:14 | <Philip`> | http://canvex.lazyilluminati.com/misc/statestats.txt - state transitions from some collection of documents: BeforeAttributeValueState -> AttributeValueDoubleQuotedState: 1505620 BeforeAttributeValueState -> AttributeValueUnquotedState: 137469 BeforeAttributeValueState -> AttributeValueSingleQuotedState: 50487 |
| 12:14 | <Philip`> | Argh, why does irssi forget to paste newlines? |
| 12:14 | <Philip`> | BeforeAttributeValueState -> AttributeValueDoubleQuotedState: 1505620 |
| 12:14 | <Philip`> | BeforeAttributeValueState -> AttributeValueUnquotedState: 137469 |
| 12:14 | <Philip`> | BeforeAttributeValueState -> AttributeValueSingleQuotedState: 50487 |
| 12:14 | <Philip`> | suggests double-quoted is most popular by far, and single-quoted is least |
| 12:15 | <hsivonen> | Philip`: thanks |
| 12:15 | <Philip`> | but I wouldn't necessarily recommend trusting me |
| 12:16 | <zcorpan> | Hixie: it would be nice with a close button on the spec updates box which makes the box disappear and not appear again until there's a later revision again |
| 12:16 | <Hixie> | remind me in a couple of days |
| 12:16 | <Hixie> | or just hit reload :-) |
| 12:17 | <zcorpan> | i've reloaded but it still says "You are reading r2025 but the latest revision is r2026" |
| 12:19 | <hsivonen> | It's fun how document published by Dublin Core Metadata Initiative start excessive visible metadata labeling |
| 12:20 | <hsivonen> | I would never have guessed that "Using Dublin Core" was the title if it hadn't "Title: " in front of it |
| 12:21 | <Hixie> | zcorpan: your browser is caching something |
| 12:23 | <Hixie> | ok, workers spec is stable for another 12 hours. bed time. |
| 12:30 | <zcorpan> | oh, 12h, maybe that'll be enough time to implement it |
| 12:32 | <hsivonen> | I wonder if HTML5 should define a mapping to Dublin Core from HTML5 and HTTP 1.1 native data |
| 13:08 | <Lachy> | hsivonen, why? Does anyone actually do anything useful with Dublin Core? |
| 13:09 | <hsivonen> | Lachy: DC is all the rage for archivists |
| 13:09 | <hsivonen> | Lachy: DC has useful parts like title |
| 13:10 | <hsivonen> | Lachy: DC also has utterly bogus parts like date |
| 13:10 | <hsivonen> | (date isn't a field. it's a datatype) |
| 13:11 | <hsivonen> | Lachy: (I'm not a big metadata believer. Participation in two goverment metadata projects made me a non-believer.) |
| 13:11 | <hsivonen> | government even |
| 13:12 | <hsivonen> | Lachy: we could define the obvious. |
| 13:12 | <Lachy> | I like metadata when it actually serves a useful purpose for users. Like embedding track title, artist and album cover art, etc. in music, videos. |
| 13:12 | <hsivonen> | like: <title> is the DC title |
| 13:12 | <hsivonen> | HTTP Content-Type is the DC format |
| 13:13 | <Lachy> | I just found most of the DC metadata was largely useless for documents on the web |
| 13:13 | <Lachy> | ok, mappings like those could work |
| 13:13 | <hsivonen> | Lachy: of course it is. there's always more value in writing software that looks at <title> than in writing software that look for DC.Title in meta |
| 14:01 | <gDashiva> | Anyone know the rationale for not allowing html entities in innerHTML on XHTML? |
| 14:02 | <annevk> | innerHTML simply uses an XML parser in that case without anything special |
| 14:03 | <gDashiva> | Yes, but why? |
| 14:04 | <annevk> | to not complicate things require support for things that are optional |
| 14:04 | <annevk> | or require* |
| 14:05 | <gDashiva> | Yet another roadblock to using xhtml |
| 14:07 | <Lachy> | gDashiva, how is missing entity refs a roadblock to using XHTML? |
| 14:08 | <Lachy> | they're not necessary. You can always use the numeric referece or JavaScript's \u#### syntax |
| 14:08 | <gDashiva> | Because innerHTML stops working where it used to work |
| 14:09 | <Lachy> | did any browser ever support entity refs in innerHTML for XHTML? |
| 14:09 | <gDashiva> | Opera does |
| 14:09 | <gDashiva> | I haven't tested safari |
| 14:09 | <Lachy> | even without the XHTML DOCTYPE in the document? |
| 14:10 | <gDashiva> | Yes |
| 14:11 | <gDashiva> | But if there's no doctype, it will error on entities in the initial markup |
| 14:13 | <takkaria> | why can't .innerHTML in XHTML use the html5 parser? |
| 14:14 | <hsivonen> | takkaria: Namespaces and tag inference |
| 14:15 | <annevk> | gDashiva, Opera doesn't use an XML parser for innerHTML afaict |
| 15:02 | gsnedders | is tempted to do some Pingback testing when he gets back home |
| 15:40 | <zcorpan> | http://simon.html5.org/test/html/dom/interfaces/HTMLElement/HTMLMediaElement/src/003.htm seems to freeze firefox |
| 15:42 | <Philip`> | Is it intentional that it claims to be testing "absent src=''" but actually has <source src="#">? |
| 15:46 | <mpilgrim> | Hixie: for class=note, class=issue screenreader problem -- try putting <span class="type">note</span> before each line, then hide it offscreen with span.type{display:block;position:absolute;top:-500px;width:1px;height:1px} |
| 15:47 | <mpilgrim> | jaws should read it but it won't show up in visual browsers |
| 15:47 | <mpilgrim> | adapted from http://code.google.com/p/doctype/wiki/ArticleAccessibility11 |
| 15:48 | <mpilgrim> | hmm, that page needs a link back to webaim's skiplinks article |
| 15:51 | <Philip`> | http://krijnhoetmer.nl/irc-logs/whatwg/20080805#l-32 |
| 15:52 | <mpilgrim> | well, great minds think alike |
| 15:52 | <zcorpan> | Philip`: yeah |
| 15:52 | <zcorpan> | Philip`: it doesn't have src on the <video>/<audio> element |
| 15:53 | <Philip`> | zcorpan: Oh, right |
| 16:09 | <csarven> | HTML5 appears to discontinue rel=section? In HTML4 @rel=section "Refers to a document serving as a section in a collection of documents." http://www.w3.org/TR/html401/types.html#type-links -- Would you say this is sort of talking about the common navigation items that lead to main sections of the site? |
| 16:10 | <jcranmer> | "JS and Flash must have the capacity to be slow... CSS... does not have to be slow" |
| 16:45 | <gsnedders> | Hixie: DuplicateTermException: dom-messageport-close (i.e., multiple dfns of it) |
| 16:52 | <annevk> | Hixie also made like 150 revisions |
| 17:01 | <gsnedders> | Hmm. |
| 17:01 | <gsnedders> | I still can't see why onreadystatechange isn't being called :\ |
| 17:06 | gsnedders | plays around with null bytes in HTTP headers |
| 17:28 | <gsnedders> | readystatechange isn't called when async=false in Gecko, as far as I can see |
| 17:29 | <gsnedders> | annevk: you have any idea? |
| 17:29 | <gDashiva> | gsnedders: It's a rather meaningless venture |
| 17:29 | <gsnedders> | gDashiva: Like life itself. |
| 17:29 | <gDashiva> | By the time the event can be handled, the entire request is finished |
| 17:30 | <gsnedders> | gDashiva: It works in Saf and Op and IE! |
| 17:32 | <annevk> | it's a bug |
| 19:45 | <takkaria> | the guy who's posting to whatwg in an aggressive tone about javascript seem to be an <term ns="http://diveintomark.org/archives/2004/08/16/specs">asshole</term>; |
| 19:45 | <takkaria> | judging by his website, anyway |
| 20:06 | <zcorpan> | hah, i was just thinking "hmm, nothing has happened on the whatwg blog for a while" and when i take a look, markp has posted a "This week in HTML 5" that hasn't yet reached my feed reader |
| 20:06 | <hsivonen> | now that Troy McLure is blogging about the new alt, I wonder if there will be comments |
| 20:09 | <Hixie> | hey, mpilgrim++ |
| 20:09 | <Hixie> | i hope he does do that regularly! |
| 20:10 | <zcorpan> | hsivonen: pointer? |
| 20:10 | <annevk> | zcorpan, it's a reference to markp I believe |
| 20:11 | <zcorpan> | ah |
| 20:12 | <hsivonen> | http://blog.whatwg.org/omit-alt#comment-7771 |
| 20:12 | <hsivonen> | (should be McClure) |
| 20:14 | <hsivonen> | I feel that Namespaces have hurt me personally |
| 20:15 | <hsivonen> | perhaps I should blog about what proportion of lines of code in my XML serializer is devoted to prefix allocation |
| 20:15 | <zcorpan> | can something obvious be done in xml5 to make it better? |
| 20:16 | <hsivonen> | zcorpan: not as far as I can tell |
| 20:20 | <hober> | how, err, eloquent: http://blog.whatwg.org/omit-alt#comment-8380 |
| 20:22 | <Hixie> | i was going to edit it, but wordpress doesn't let me |
| 20:22 | <Hixie> | oh well |
| 20:27 | <Hixie> | ok i added a 'close' button, for whoever was asking for that |
| 20:28 | <annevk> | what did you want to do with the "fucker" comment? |
| 20:28 | annevk | can edit it |
| 20:28 | <Hixie> | nah it's ok |
| 20:29 | <Hixie> | i was going to change it to be very polite formal english and then leave a comment saying "edited for language" |
| 20:29 | <Hixie> | but it's a year old, who cares |
| 20:29 | <zcorpan> | Hixie: thanks! |
| 20:29 | <annevk> | fair enough |
| 20:29 | <Hixie> | for reference, how do you edit comments? |
| 20:32 | <zcorpan> | Hixie: though, it pops up again after 30s |
| 20:33 | <Hixie> | oh |
| 20:33 | <Hixie> | heh |
| 20:35 | zcorpan | wonders if the script could be made to work on the multipage version too, other than the first page |
| 20:36 | <Hixie> | man you people are never happy |
| 20:36 | <Hixie> | it probably could, speak to philip :-) |
| 20:37 | <zcorpan> | :) |
| 20:37 | <zcorpan> | Hixie: if you don't do anything, there's nothing to complain about :P |
| 20:38 | <zcorpan> | Hixie: when you do things there are always things that can be improved :) |
| 20:38 | <Hixie> | i'd complain if i did nothing :-P |
| 20:38 | <Hixie> | ok what simple demo can i do for shared workers |
| 20:38 | <Hixie> | i'm thinking maybe a party line demo |
| 20:41 | <annevk> | Hixie, log in, hit the edit button next to the comment |
| 20:41 | <gsnedders> | Hixie: DuplicateTermException: dom-messageport-close (i.e., multiple dfns of it) |
| 20:42 | <Hixie> | annevk: i didn't see an edit button |
| 20:44 | <annevk> | Hixie, next to the date? |
| 20:44 | <annevk> | (it's a link, not a button; sorry) |
| 20:44 | <Hixie> | oh yeah! |
| 20:48 | <zcorpan> | didn't the spec have "Big Issue:" markers before? |
| 20:48 | <zcorpan> | i seem to remember Lachy implemented them |
| 20:56 | <Hixie> | zcorpan: yes, went away when i wrote the annotation stuff |
| 20:57 | <Hixie> | sam just said it wasn't productive to address feedback on proposals |
| 20:57 | <Hixie> | that's... an interesting opinion |
| 20:58 | <hsivonen> | RDFa would be more importable to HTML5 if it used full URIs instead of CURIEs |
| 20:58 | <hsivonen> | that would remove the Namespace dependency and the qnames-in-content anti-pattern |
| 20:59 | <zcorpan> | hsivonen: i've been told that CURIEs don't depend on namespaces |
| 20:59 | <hsivonen> | zcorpan: how so? |
| 21:01 | <zcorpan> | wait let me dig it up |
| 21:09 | <zcorpan> | hmm can't find it in email, but i remember someone (rich?) saying that the xmlns mechanism is just one way to do CURIEs, you could equally well use any other mechanism like <meta> tags or other attributes |
| 21:10 | <zcorpan> | which left me even more confused |
| 21:10 | <hsivonen> | zcorpan: ah. no you need a mapping scope even if it isn't established by xmlns |
| 21:10 | <hsivonen> | zcorpan: it seems that you'd still get all the problems of mapping scopes |
| 21:11 | <zcorpan> | yes |
| 21:11 | <hsivonen> | Hixie: have you considered supporting RDFa with full URIs instead of CURIEs? |
| 21:13 | <zcorpan> | i don't understand what problem curies is trying to solve |
| 21:13 | <hsivonen> | zcorpan: they try the solve the problem of URIs being too long to be used as convenient identifiers |
| 21:14 | <hsivonen> | having the cake and eating it too |
| 21:14 | <zcorpan> | well apparently they weren't good enough for aria implementors :) |
| 21:15 | <zcorpan> | aria implementors wanted strings, not URIs |
| 21:15 | <Lachy> | Hixie, can you add one more link the spec update UI, pointing to: "http://html5.org/tools/web-apps-tracker?from="; + current_revision |
| 21:15 | <hsivonen> | I can't blame ARIA implementors for that |
| 21:15 | <Hixie> | hsivonen: to solve what problem? |
| 21:16 | <Hixie> | Lachy: :-P |
| 21:16 | <hsivonen> | Hixie: the problem of overlaying RDF-mappable metadata onto HTML with object literals as visible metadata without tantek's approval |
| 21:17 | <Hixie> | is that a rael problem? |
| 21:17 | <Hixie> | real, even |
| 21:17 | <hsivonen> | I don't know. |
| 21:18 | Hixie | moves on |
| 21:20 | <zcorpan> | i wonder if i should write a script that handles CURIEs correctly, just to see how ugly it gets |
| 21:21 | <hsivonen> | zcorpan: with which XML API? |
| 21:21 | <zcorpan> | hsivonen: no with javascript |
| 21:21 | <hsivonen> | zcorpan: I read DOM as the API :-) |
| 21:22 | <zcorpan> | fair enough :) |
| 21:22 | <hsivonen> | zcorpan: is it even *possible* to handle CURIEs correctly if the DOM tree has undergone arbitrary scripted mutations? |
| 21:22 | <hsivonen> | unless you do some bookkeeping before any mutations take place |
| 21:22 | <zcorpan> | well i didn't intend it to be performant |
| 21:23 | <hsivonen> | I mean bookkeeping like traversing the DOM tree and storing a snapshot of the namespace mapping scope locally at each element node before mutations |
| 21:25 | <Hixie> | Lachy: i added the link but it doesn't work, because the html5.org page is out of date (?) |
| 21:26 | <zcorpan> | Hixie: web-apps-tracker just tracks source, not whatwg-header |
| 21:26 | <Hixie> | oh, right, ok |
| 21:26 | <Hixie> | that would explain it |
| 21:26 | <Hixie> | so it'll work for the next revs :-) |
| 21:33 | <Lachy> | Hixie, thanks |
| 21:34 | <Lachy> | did someone else moderate the 2 comments in the blog's moderation queue already? I got mail about them being there, but they're gone now. |
| 21:37 | <hsivonen> | http://dubinko.info/blog/2008/07/28/erdf-11-proposal-discussion/ |
| 21:37 | <hsivonen> | A new profile string of: |
| 21:37 | <hsivonen> | "http://purl.org/NET/erdf11/profile"; |
| 21:54 | <Lachy> | does eRDF prefixed class names with fixed prefixes, or with prefixes bound to a URI, like xmlns? |
| 21:55 | <hsivonen> | Lachy: bound to URI |
| 21:55 | <hsivonen> | in head |
| 21:56 | <Lachy> | ok. how unfortunate. |
| 21:57 | <Lachy> | it seems like using defined prefixes like foaf.depicts and cc.license would be sufficient |
| 21:57 | <hsivonen> | Lachy: how would that work for less known RDF vocabularies |
| 21:57 | <hsivonen> | ? |
| 21:58 | <hsivonen> | assuming you want to be able to map to RDF |
| 21:58 | <jgraham> | But Lachy what it I wanted to use cc.licese to represent the license plate of my clasic car ?!! |
| 21:58 | <hober> | heh |
| 21:59 | jgraham | wonders who the end users consuming all this RDF are |
| 21:59 | <hsivonen> | how about eRDF5: like eRDF but with full URIs? |
| 22:00 | <Lachy> | hsivonen, jgraham, it would require communication with the community to settle on a prefix for a common vocabulary |
| 22:01 | <hsivonen> | jgraham: feed RDF into Naked Objects and you get generated UIs: http://www.nakedobjects.org/tutorial/index.shtml |
| 22:01 | <Lachy> | jgraham, the RDF model seems to be built mostly with publishing metadata in mind, rather than actually making use of what's published |
| 22:02 | <Lachy> | I'm yet to see any killer app for RDF metadata, unlike the many that exist for microformats |
| 22:03 | <hsivonen> | I haven't seen a killer app for microformats |
| 22:03 | <Lachy> | hsivonen, I've seen people extracting hcard information and storing it in a user's address book |
| 22:04 | <Lachy> | there was a tool somewhere that, given a URL to a page with hcard, would spit out a vcard file |
| 22:04 | <hsivonen> | Lachy: I'd call that an application but not a killer one |
| 22:05 | <Lachy> | there's also various calendar webapps. |
| 22:05 | <Lachy> | hsivonen, perhaps not, it's more than I've seen for RDF |
| 22:06 | <Lachy> | we might start seeing more soon. Firefox 3 has built in support for microformats, exposed through some extension api, so extension developers can make use of it |
| 22:16 | Hixie | agrees with hsivonen |
| 22:17 | <Hixie> | the future of microformat type data as far as i can tell lies in heuristic analysers like those that detect addresses in e-mails in yahoo mail or google mail |
| 22:17 | <Hixie> | data that isn't explicitly structured, which the computer determines is of a particular type |
| 22:18 | <Hixie> | certainly so far we as a race have had better luck convincing computers to detect data than we have had convincing humans to mark it up |
| 22:19 | <roc> | depends on the data |
| 22:20 | <roc> | we haven't been successful at getting computers to extract programs from text, for example |
| 22:20 | <Hixie> | sure. i'm talking primarily about the kind of data a microformat or RDF would be used for. |
| 22:21 | <Hixie> | for things for which we typically use a whole format, e.g. documents, programs, images, etc, users seem willing to write data in a semi-structured way (usually using tools, though not always) |
| 22:27 | <othermaciej> | when it comes to user interface, even a fairly low rate of false-positive detection can be extremely irritating if it has a visible result |
| 22:27 | <Hixie> | indeed |
| 22:27 | <othermaciej> | thus, microformats are valuable as a higher-confidence indicator of particular structured data, perhaps trustworthy enough to decorate the UI |
| 22:28 | <othermaciej> | so far no one has turned this into a good UI |
| 22:28 | <Hixie> | so far it seems you get a better rate of detection if you rely on heuristics than if you rely on authors getting their semantics right |
| 22:28 | <othermaciej> | but it doesn't seem impossible |
| 22:28 | <othermaciej> | and many web sites have decent chunks of interesting microformat data |
| 22:28 | <othermaciej> | well, if microformats lead to a user-visible effect authors will be more likely to get them right |
| 22:28 | <hsivonen> | virtually all data detection in Mail.app is false positives |
| 22:29 | <Hixie> | othermaciej: <title> has a relatively high rate of bogus contents, to the point where google has to run heuristics on the contents of <title> to determine whether to show that or something else |
| 22:30 | <Hixie> | i guess maybe the right approach is more of a hybrid approach |
| 22:30 | <hsivonen> | Hixie: dc:title to rescue! |
| 22:30 | <othermaciej> | lol |
| 22:30 | <Hixie> | with the semantics being somewhat broad (e.g. <title>, as opposed to RDF triples) and the heuristics start from those hints and work from there |
| 22:30 | <Hixie> | s/start/starting/ |
| 22:49 | <Lachy> | wow, the Aurora concept browser is horribly cluttered. http://labs.mozilla.com/2008/08/introducing-the-concept-series-call-for-participation/ (see the first video on that page) |
| 22:50 | <Lachy> | http://www.pcpro.co.uk/news/216897/mozilla-reveals-the-firefox-of-the-future.html |
| 22:51 | <Lachy> | it has some nice hypothetical features in it though, not sure how implementable they are though. But the UI is so bad, it makes it unusable even if they could be implemented |
| 22:53 | <Hixie> | the idea of concept browsers isn't the ui, it's the features :-) |
| 22:56 | <roc> | "Firefox of the future"? I don't think so :-) |
| 22:56 | <Lachy> | I realise, that, but they should try to focus on presenting the features, instead of destroying the whole idea with over engineered and flashy UI |
| 22:57 | <Hixie> | to be honest i had too much trouble with the "scenario"-type presentation to actually see the ui |
| 22:57 | <Hixie> | i don't understand why people always waffle so much instead of just saying their piece and shutting up |
| 22:57 | <Hixie> | (though i'm sure i waffle sometimes too) |
| 22:59 | <roc> | the fact is, bling sells |
| 23:00 | <Lachy> | the second video with the history search feature is ok. Being able to search and filter history by both keywords and approximately when I visited a page is something I've wanted for a long time |
| 23:01 | <Hixie> | i've been telling people that search browsers should have full-text-search through history of all pages ever viewed (and no expiring ever) for some time |
| 23:01 | <Hixie> | the number of times i want to search for something i saw recently but can't find any more is mindboggling |
| 23:02 | <Lachy> | sometimes, i visit a page, close it and then want to return to it a couple of hours later. But then just searching for keywords doesn't help when I have about 6 months of browsing history |
| 23:02 | <Lachy> | I set my history expiration to 999 days |
| 23:02 | <roc> | you need good heuristics for searching all that data though |
| 23:03 | <roc> | I hate to be parochial, but FF3's urlbar search is better than Opera's for that reason, even though it indexes less data |
| 23:04 | <Lachy> | my opera profile isn't kept around long enough for me to have a decent history, since I'm always testing with internal builds. So I can't really comment on the quality of Opera's history search |
| 23:05 | <Lachy> | I use Firefox for personal stuff and opera for testing, to keep things separate |
| 23:05 | <roc> | you can't use the same opera profile across different internal builds? |
| 23:06 | <aboodman> | hello playmobil |
| 23:06 | <roc> | My Opera upgrades seem to preserve my profile just fine |
| 23:06 | <Lachy> | I can, but internal builds have so many bugs, I like to keep a more stable profile for everyday use separate from the testing profile. |
| 23:06 | <playmobil> | Hey there aboodman! |
| 23:06 | <Lachy> | also, running 2 separate instances of Opera, even with separate profiles, is confusing |
| 23:06 | Hixie | commits another workers example |
| 23:07 | <Hixie> | the longest one so far |
| 23:07 | <Hixie> | can't wait for people to implement workers so i can test these things! |
| 23:07 | <aboodman> | that reminds me |
| 23:07 | <aboodman> | Hixie: I had an idea for the gc issue |
| 23:08 | <Lachy> | Hixie, is the google gears team intending to update that to use this API to provide support in existing browsers? |
| 23:08 | <Hixie> | a lot of the gc stuff got simplified away last night |
| 23:08 | <Hixie> | but go ahead |
| 23:08 | <aboodman> | I wanted to write it up but you had too many responses to m yfeedback and I got distracted |
| 23:08 | <Hixie> | Lachy: no idea, ask aboodman :-) |
| 23:08 | <aboodman> | Lachy: no idea, ask playmobil |
| 23:08 | <Lachy> | LOL |
| 23:09 | <aboodman> | Hixie: your latest idea I think still doesn't work consistently |
| 23:09 | <aboodman> | if gmail opens a named worker on instance 1, then instance 2 |
| 23:09 | <aboodman> | then the user closes instance 1 |
| 23:09 | <aboodman> | then the behavior of xhr is different than if he had closed instance 2 first |
| 23:09 | <aboodman> | i fully admit this is a crazy edge case, but it irritates me that its inconsistent |
| 23:10 | <Hixie> | only if gmail doesn't keep a reference to instance 2 |
| 23:10 | <Hixie> | but yes |
| 23:10 | <Hixie> | i agree |
| 23:10 | <Hixie> | so |
| 23:10 | <aboodman> | what if instead, the list of things that i suggested keeps the worker live, but... |
| 23:10 | <Hixie> | i was thinking of not including the 'port' global for shared workers |
| 23:11 | <Hixie> | which would make it consistent, though bring back the odd behaviour for shared workers |
| 23:11 | <aboodman> | i don't like the port global anyway |
| 23:11 | <Hixie> | it makes the code so much easier, check out the examples |
| 23:11 | <Hixie> | but what was your idea? |
| 23:11 | <aboodman> | once all pages that ever had a MessagePort that refers to a worker unload, the worker is killed |
| 23:12 | <aboodman> | does that make sense at all? |
| 23:12 | <Hixie> | so basically make the lifetime be the maximum lifetime that it could have today, and prevent it from ever shutting down automatically before that? |
| 23:13 | <Hixie> | sure, i could buy that |
| 23:13 | <aboodman> | basically, workers are ref counted by the messages pending to them, and the messageports that are live, and the script running in them. this is what you have today. |
| 23:14 | <Lachy> | without the port global, what would be used instead of port.postMessage()? |
| 23:14 | <Hixie> | Lachy: see the example i just added |
| 23:14 | <aboodman> | additionally, things like httprequests that are pending can keep the worker alive past the point where it has no more references, but only if a page is alive that ever had a mesasgeport for that worker. |
| 23:14 | <Hixie> | oh, ok |
| 23:14 | <Hixie> | yeah i could buy that |
| 23:15 | <Hixie> | shall i go ahead and make those changes? |
| 23:15 | <aboodman> | i think it is better than what is there now |
| 23:16 | <Hixie> | agreed |
| 23:16 | <Lachy> | oh, ok. So listening for onconnect and getting a reference to the port from there. |
| 23:19 | <aboodman> | Hixie: you say that MessagePort implements EventTarget, but I don't see it in the interface description |
| 23:19 | <aboodman> | is there some convention that I am missing? |
| 23:20 | <Hixie> | search for "eventtarget" |
| 23:20 | <Hixie> | oops, i made the wrong object implement it |
| 23:20 | <Hixie> | my bad |
| 23:20 | <Hixie> | let me fix that |
| 23:20 | <Hixie> | as soon as i've done this lifetime change |
| 23:24 | <aboodman> | and as long as I have you |
| 23:24 | <aboodman> | utils-- |
| 23:24 | <aboodman> | i will send mail with all this too |
| 23:25 | <Hixie> | utils was sicking's idea, basically he said we shouldn'e be poluting the global scope with new features over time as it will cause clashes |
| 23:25 | <Hixie> | (a lesson to learn from Window) |
| 23:25 | <Hixie> | hey so what happens if you have a Window |
| 23:25 | <Hixie> | and it creates a worker |
| 23:26 | <Hixie> | and that worker creates a worker |
| 23:26 | <Hixie> | and the nested worker then starts an XHR |
| 23:26 | <Hixie> | and everyone drops their references so all the ports get GC'ed |
| 23:28 | <aboodman> | so first of all, I think workers count as 'asynchronous things' |
| 23:28 | <aboodman> | (we need a better word) |
| 23:28 | <aboodman> | so a nested worker could keep its parent alive same as an xhr |
| 23:29 | <Hixie> | so if a worker creates a worker, those two workers can never die until the window is closed? |
| 23:29 | <Hixie> | that seems bad |
| 23:29 | <aboodman> | no they can die |
| 23:29 | <aboodman> | if they aren't doing anything and no ports or mesages reference them |
| 23:29 | <Hixie> | this is going to be the most complicated set of conditions i have ever written |
| 23:29 | Hixie | flexes his wrists |
| 23:29 | <aboodman> | agree |
| 23:30 | <aboodman> | stop me if it won't work, it's just an idea |
| 23:31 | <aboodman> | i haven't thought through nested workers |
| 23:31 | <aboodman> | nested workers are another thing i could live without |
| 23:31 | <Hixie> | i see no reason why it shouldn't work, it'll just be a bitch to write in english |
| 23:31 | <Hixie> | but that's what i do |
| 23:31 | <Hixie> | :-) |
| 23:31 | <roc> | I haven't really been paying attention, but how about saying that closing a window stops all workers it owns; any other early termination is just an optimization only |
| 23:31 | <roc> | *and* provide a method for transferring ownership explicitly |
| 23:31 | <Hixie> | roc: workers can be shared between windows, like XHR objects and so on |
| 23:31 | <Hixie> | oh |
| 23:31 | <Hixie> | hm |
| 23:32 | <Hixie> | that seems like it's pushing the complexity on the author |
| 23:32 | <roc> | complicated constraints are also complexity for the author |
| 23:32 | <Hixie> | not necessarily |
| 23:35 | <roc> | your call. Just thought I'd mention it as an option |
| 23:35 | <aboodman> | ideally, the issue of when workers shut down doesn't come up |
| 23:35 | <aboodman> | they just sort of do the right thing |
| 23:35 | <aboodman> | from an author's point of view |
| 23:36 | <aboodman> | and all the complexity is pushed onto UA developers |
| 23:38 | <roc> | of course, that's always the goal for every feature |
| 23:38 | <roc> | another tradeoff to keep in mind is that you don't want to create mysterious worker leaks |
| 23:42 | <aboodman> | yep |
| 23:42 | <aboodman> | i think my proposal achieves both of these (no mysterious leaks and 'does the right thing') |
| 23:42 | <aboodman> | complexity is another issue |
| 23:45 | <Hixie> | aboodman: ok http://www.whatwg.org/specs/web-workers/current-work/#the-workers |
| 23:45 | <Hixie> | text with a green underline is a reference to the main html5 spec |
| 23:46 | <Hixie> | i haven't set up cross-references cross-spec yet |
| 23:46 | <Hixie> | i got rid of the "front line" stuff too |
| 23:48 | <Hixie> | aboodman: fixed the eventtarget thing |
| 23:48 | <aboodman> | looking |
| 23:49 | <aboodman> | i just sanity tested the lifetime idea with michaeln |
| 23:49 | <aboodman> | he said it seemed reasonable |
| 23:49 | <aboodman> | i am not sure about nested worker |
| 23:49 | <aboodman> | do we really need workers creating workers? |
| 23:49 | <Hixie> | sure, why not? |
| 23:49 | <Hixie> | seems a bit weird to disallow it |
| 23:50 | <Hixie> | especially since you can always just create a worker and pass the channel port to the worker |
| 23:50 | <aboodman> | http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#messageport0 |
| 23:50 | <Hixie> | so it's not like you'd remove complexity by not allowing it |
| 23:50 | <aboodman> | i still don't see it |
| 23:50 | <Hixie> | oh MessagePort! |
| 23:50 | <Hixie> | i thought you meant WorkerGlobalScope |
| 23:50 | <aboodman> | same question for both |
| 23:52 | <Hixie> | hm yes, MessagePort isn't right |
| 23:52 | Hixie | fixes |
| 23:53 | <Hixie> | fixed, see just below the idl |
| 23:53 | <aboodman> | what should i look for in the worker document about lifetime |
| 23:53 | <Hixie> | http://www.whatwg.org/specs/web-workers/current-work/#the-workers |
| 23:54 | <Hixie> | section "2.4 The worker's ports |
| 23:54 | <Hixie> | " |
| 23:54 | <Hixie> | and then search for "Closing orphan workers" which uses those erms |
| 23:54 | <Hixie> | terms |
| 23:55 | <aboodman> | sorry , but I still see nothing about 'EventTarget' near 'interface MessagePort' |
| 23:56 | <aboodman> | dang, now i see it |
| 23:56 | <aboodman> | so, why don't these IDL files use " : EventTarget" ? |
| 23:56 | <aboodman> | that would be more clear |
| 23:56 | <Hixie> | they don't inherit from EventTarget |
| 23:57 | <aboodman> | err... |
| 23:57 | <Hixie> | it's just that that one object implements several interfaces |
| 23:57 | <aboodman> | why not say that MessagePort inherits EventTarget |
| 23:58 | <Hixie> | why would you say that? what about all the other interfaces that it might implement one day? |
| 23:58 | <Hixie> | e.g. the way Document implements Document, HTMLDocument, SVGDocument, EventTarget, etc |
| 23:58 | <Hixie> | Document inherits from Node |
| 23:58 | <Hixie> | because a Document is-a Node |
| 23:59 | <aboodman> | i see your question |
| 23:59 | <aboodman> | in many languages there is a way to say "implements" |
| 23:59 | <aboodman> | i'm requesting this for WebIDL |
| 23:59 | <Hixie> | that might be useful, yes |
| 23:59 | <Hixie> | we'd also need the opposite, "is implemented by" |
| 23:59 | <Hixie> | i requested both of these some time ago i believe :-) |