| 00:00 | <Hixie> | zewt: e.g. you dump the ImageData to the console, and boom, now you need to synchronously fetch the data across both the GPU and process boundaries |
| 00:00 | <zewt> | also, ImageData is really bad at certain types of optimizations |
| 00:00 | <zewt> | for example, in principle an ImageData might be backed by a PNG until it's read--but that means you have a huge synchronous (and possibly UI thread) hitch on the first access, since you have to decompress it |
| 00:01 | <Hixie> | right |
| 00:01 | <zewt> | which you can give workarounds for, but they're just that |
| 00:01 | <Hixie> | which is bad enough, but that access might be in debug code |
| 00:01 | <Hixie> | which makes it even worse |
| 00:02 | <zewt> | i wonder if there's overlap between ImageWhatever and Blob |
| 00:04 | <MikeSmith> | Hixie: hey wasn't the sortable-tables idea part of the datagrid spec? |
| 00:04 | <MikeSmith> | essentially |
| 00:05 | <Hixie> | yes, datagrid had that too |
| 00:09 | <MikeSmith> | I think the sortable-table part of datagrid is what was most appealing thing to web developers |
| 00:09 | <Hixie> | possibly |
| 00:09 | <Hixie> | the only reason for datagrid was the lack of a DOM backing |
| 00:09 | <MikeSmith> | OK |
| 00:10 | <Hixie> | the just-in-time API |
| 00:10 | <Hixie> | dunno what it's formally called |
| 00:16 | <MikeSmith> | good feedback from nessy on that thread |
| 00:19 | <MikeSmith> | Hixie: btw thanks again for the heads-up the day before yesterday about the validator-related message on the whatwg help list |
| 00:19 | <MikeSmith> | it help me find and fix a bug |
| 00:20 | <MikeSmith> | also made me take time to read Henri's file-upload handling code |
| 00:20 | <MikeSmith> | anyway I wasn't subscribed the the help list before but I am now |
| 00:25 | <Hixie> | MikeSmith: cool |
| 00:28 | <wirepair_> | might be interesting to some people here: http://www.veracode.com/blog/2012/11/security-headers-report/ |
| 00:33 | <zewt> | heh searching pdfs in chrome is still seriously annoying |
| 00:33 | <zewt> | type one letter, wait several seconds while it counts the letter in the whole document before being able to type anything else |
| 00:38 | <Hixie> | searching the spec in chrome is even worse |
| 00:38 | <Hixie> | you type something not in the document and it just stops working for a few minutes |
| 00:38 | <zewt> | searching the spec works for me in chrome, except whenever i do, it jumps back to the top of the page |
| 00:38 | <zewt> | which is maddening |
| 00:39 | <zewt> | to search from the current position, i have to type it somewhere else, and copy and paste it into the search box |
| 00:39 | <Hixie> | try clicking on the text where you want to search from |
| 00:39 | <Hixie> | like you're putting the caret down |
| 00:40 | <zewt> | i've tried that, doesn't help |
| 00:40 | <zewt> | mostly i just load in FF to search |
| 00:41 | <zewt> | ff is also better at navigating anchors, eg. i can go to the address bar and hit enter and it'll jump back to the current #hash |
| 00:41 | <zewt> | if i do that in chrome it reloads |
| 00:41 | <zewt> | maybe that's just a weird usage pattern that only i do, using the hash as a short-term bookmark then doing the above to jump back to it |
| 00:42 | <Hixie> | i do that all the time. in chrome i worked around it by just changing the url to end in an x and then deleting the x :-) |
| 00:42 | <Hixie> | http://junkyard.damowmow.com/515 <- new strawman for canvas in workers |
| 00:42 | <zewt> | the "weird browser dance" |
| 00:44 | <zewt> | Hixie: i wonder how things like this (canvas in workers) would actually work for shared workers, where afaik (unlike dedicated workers) you may not be in the same process |
| 00:45 | <zewt> | (unlike dedicated workers created by the UI thread, i mean) |
| 00:45 | <MikeSmith> | wirepair_: interesting |
| 00:45 | <zewt> | maybe just a really slow path? dunno |
| 00:45 | <wirepair_> | MikeSmith: hence why i was asking those questions yesterday :) |
| 00:46 | <wirepair_> | got the answer from mozilla folks |
| 00:46 | <MikeSmith> | ah yeah |
| 00:46 | <MikeSmith> | about Strict Transport Security |
| 00:46 | <Hixie> | zewt: i don't understand |
| 00:46 | <Hixie> | zewt: how would that matter? |
| 00:46 | <Hixie> | zewt: dedicated worekrs aren't likely in the same process either |
| 00:46 | <MikeSmith> | wirepair_: incidentally speaking of browsers taking a long time to do things, that page seems to take a long long time to load for me |
| 00:47 | <zewt> | an implementation can guarantee that dedicated workers created by a browsing context are in the same process, but it's impossible to guarantee otherwise |
| 00:47 | <zewt> | (that is, they can guarantee it if they want to) |
| 00:47 | <zewt> | i guess it's a case of "this is hard, deal with it" |
| 00:47 | <zewt> | such is the web |
| 00:48 | <zewt> | (hard as in, harder than "just" rendering from another thread in the same process--you have to support an IPC path too) |
| 00:48 | <wirepair_> | hmm odd seems to load fine for me ;) |
| 00:49 | <MikeSmith> | anyway, retweeted |
| 00:49 | <Hixie> | zewt: same process as what? The graphics are happening on the GPU... |
| 00:50 | <zewt> | same process as the process that's displaying the results, which owns the OS window where the results are going, etc |
| 00:51 | <wirepair_> | MikeSmith: what's your twitter handle? |
| 00:51 | <MikeSmith> | sideshowbarker |
| 00:51 | <wirepair_> | cheers |
| 00:51 | <zewt> | i guess it all gets more complex depending on how the browser's compositing system works anyway |
| 00:52 | <zewt> | (which I have no idea about) |
| 00:52 | <zewt> | anyway, you probably want implementor feedback on that, not mine |
| 00:54 | <Hixie> | zewt: all feedback is welcome :-) |
| 00:57 | <zewt> | Hixie: is there no analog to toDataURL and toBlob from within the thread? (since CanvasTransferableRenderingContext doesn't have those, and since it neuters, they wouldn't work anyway) |
| 00:59 | <zewt> | and a way to createImageBitmap in the thread from another canvas in that thread (since you don't have the HTMLCanvasElement) |
| 01:04 | <Hixie> | zewt: .canvas on the 2d context |
| 01:05 | <Hixie> | zewt: returns an ImageBitmap object |
| 04:27 | <msangel> | hi |
| 04:29 | <msangel> | all is sleaping |
| 04:29 | <msangel> | ok |
| 04:30 | <Hixie> | all is watching US election :-) |
| 05:16 | <MikeSmith> | the gonna fly the flag at half staff at all NASCAR races for a while I guess |
| 05:16 | <MikeSmith> | poor crackers |
| 05:17 | <MikeSmith> | but wait I see from the map that Mexico and Canada have not voted yet! |
| 05:25 | <MikeSmith> | in other news I wonder why I didn't realize Hubbub was as far along as it is |
| 05:25 | <MikeSmith> | http://www.netsurf-browser.org/projects/hubbub/ |
| 06:05 | <annevk> | oh lol, Roy called me a terrorist? |
| 06:09 | <MikeSmith> | annevk: not by name |
| 06:10 | <MikeSmith> | sorta just by association |
| 06:11 | <MikeSmith> | anyway, wear it with pride man |
| 06:11 | <MikeSmith> | considering the source |
| 06:13 | <MikeSmith> | the part where is he spoke about "anti-social behavior within the WHATWG" was fun too |
| 06:14 | <MikeSmith> | considering, you know, how social and civil he is |
| 06:14 | <MikeSmith> | and his lovable, charming way with words that just endears everybody to him so much |
| 06:14 | <MikeSmith> | we should be more like him |
| 06:14 | <MikeSmith> | follow his example |
| 06:15 | <annevk> | the irc-logs from (for me) last night crack me up |
| 06:16 | <MikeSmith> | the funniest part was where you said you're going to run for the TAG |
| 06:16 | <MikeSmith> | next thing you'll be telling us your going to run for the Supreme Court of the IETF |
| 06:20 | <annevk> | yeah man, IAB, IESG, all the acronyms |
| 06:20 | <annevk> | Hixie: I wonder if we should merge XHR and Workers a bit more, or maybe Workers in general with the rest of the platform |
| 06:21 | <annevk> | Hixie: that instead of Workers saying how APIs behave, APIs define how they work in Workers |
| 06:21 | <annevk> | Hixie: e.g. I just noticed you can set responseType to "document" in a Worker per the XHR spec, which makes little sense |
| 06:23 | <MikeSmith> | annevk: it almost sounds like you're discussing architecture right now |
| 06:24 | <annevk> | MikeSmith: don't tell anyone, they might get the wrong impression |
| 06:24 | <MikeSmith> | hehheh |
| 06:25 | <annevk> | https://twitter.com/sideshowbarker/status/265980959848022020 he was surprised? |
| 06:25 | <annevk> | sounds more like Film at 11 to me |
| 06:27 | <MikeSmith> | wirepair_: annevk is saying "You must be new here" |
| 06:29 | <annevk> | that people get CORS wrong is kinda funny, because if you don't get it right, stuff won't work... |
| 06:29 | <annevk> | afaict the other headers are about additional protection |
| 06:36 | <annevk> | twitter is basically useless now |
| 06:37 | <annevk> | will it take another day for the election thing to go away? |
| 06:39 | <MikeSmith> | don't think it'll take that long |
| 06:39 | <MikeSmith> | Turn out the lights the party's over |
| 06:40 | <Hixie> | annevk: i'm all for making xhr know about workers, sure |
| 06:41 | <annevk> | Hixie: it would be nice if we had simple language like "in Window context" and "in Worker context" to hook into |
| 06:42 | <annevk> | Hixie: currently I'm using some hack based on whether or not XHR has an associated Document, but that's not very clear |
| 06:43 | <annevk> | Hixie: so I guess you'd need to provide those hooks, and then I can take some probable future work and maintenance away from you |
| 06:47 | <annevk> | Hixie: oops, you already do |
| 06:47 | <annevk> | Hixie: document and worker environment, great |
| 06:49 | <Hixie> | yeah, added those recently cos i needed them for the same reason :_) |
| 06:55 | <annevk> | Hixie: so I guess I'll make those changes when we do the Image thing |
| 06:55 | <Hixie> | i think i may end up not needing the Image thing |
| 06:55 | <Hixie> | i'm just gonna have a way to go from Blob to ImageBitmap |
| 06:56 | <annevk> | that works too, we can always add it later as convenience (we have "json" too) |
| 06:56 | <Hixie> | yeah |
| 07:09 | <annevk> | so yesterday was copyright, today capital-p Process http://annevankesteren.nl/2012/11/process |
| 08:00 | <hsivonen> | must. resist. making. technical. arguments. about. polyglot. on. public-html. |
| 08:02 | <MikeSmith> | snort |
| 08:02 | <hsivonen> | (people in that thread seem to have forgotten query strings) |
| 08:03 | <hsivonen> | I must look away. otherwise, it would be 386 time. |
| 08:05 | <kennyluck> | must. resist. opening. public-html. archive |
| 08:12 | <annevk> | Hixie: http://junkyard.damowmow.com/515 Alex Russell is going to nuke you |
| 08:12 | <annevk> | Hixie: "ImageBitmapFactory"... |
| 08:12 | <annevk> | Hixie: need to use constructors man |
| 08:12 | <MikeSmith> | annevk: the punctuation in the last paragraph of your blog posting shows that you've reached the next level of the game and are now ready to start writing Lisp |
| 08:13 | <MikeSmith> | annevk: the next thing you need to do is start growing a neckbeard |
| 08:13 | <annevk> | heh, on it :) |
| 08:13 | <annevk> | the parenthesis nicely illustrate the complexity |
| 08:13 | <MikeSmith> | indeed |
| 08:13 | <MikeSmith> | clever |
| 08:15 | <yuhong> | /msg NickServ identify asdasd |
| 08:16 | <annevk> | Hixie: I see, you want ImageBitmap to be created asynchronously, but I'm not sure why that's necessary if the object itself is async... |
| 08:16 | <hsivonen> | not that strong a password to begin with |
| 08:16 | <yuhong> | On the TAG, I hope this work can be finished: |
| 08:16 | <yuhong> | http://www.w3.org/2001/tag/2011/12/evolution/ |
| 08:17 | <yuhong> | hsivonen: I know. |
| 08:18 | <yuhong> | http://www.w3.org/wiki/Evolution |
| 08:18 | <yuhong> | It will be useful in proving that the W3C process and versioning HTML is flawed. |
| 08:38 | <MikeSmith> | hey guys we need somebody to write a rebuttal blog posting explaining all the positive aspects if the current publication Process |
| 08:38 | <MikeSmith> | oops |
| 08:38 | <MikeSmith> | wrong channel |
| 08:38 | <Ms2ger> | MikeSmith, I'll do that |
| 08:38 | <Ms2ger> | "None" |
| 08:39 | <Ms2ger> | Want to publish it? I don't have a blog |
| 08:39 | <MikeSmith> | we pay by the word |
| 08:39 | <annevk> | Stevef_: don't worry, technical stuff is next |
| 08:39 | <MikeSmith> | or alternatively by the depth of parenthesis |
| 08:39 | <Ms2ger> | (((((((((None))))))))))))) |
| 08:40 | <Ms2ger> | http://xkcd.com/1131/ < Hah |
| 08:41 | <Stevef_> | annevk: not worried, just thinking aloud about the general tone of your posts, which I understand, but don't necessarily agree with |
| 08:42 | <Stevef_> | annevk: I have experienced the BS, but also the opportunity |
| 08:42 | <annevk> | copyright is dialed down a bunch from what I had initially, but sure |
| 08:42 | <yuhong> | Ms2ger: http://www.reddit.com/r/IAmA/comments/120oif/we_are_mozilla_aua/c6r65h3 |
| 08:42 | <Stevef_> | annevk: and "I have experienced the BS, but also the opportunity" this goes for both w3C and whatwg |
| 09:10 | <annevk> | Stevef_: happy to reword things on request btw |
| 09:11 | <annevk> | Stevef_: I wouldn't write a critique if I didn't care and if I can improve it all the bette |
| 09:11 | <annevk> | r* |
| 09:34 | <annevk> | Hixie: aah, I guess the main problem with "data is valid" is Blob |
| 09:37 | <annevk> | Hixie: but if it's just for Blob, something like ImageBitmap.create(Blob, callback) might be nicer |
| 09:37 | <annevk> | Hixie: more like URL.createFromObject() or whatever we ended up calling that |
| 09:38 | <jgraham> | annevk: Iy might be worth mentioning the unicode exception on your blog |
| 09:38 | <jgraham> | Also the last paragraph reads like lisp |
| 09:39 | <annevk> | Unicode is not quite an exception always I think. See IDNA2003 and XML |
| 09:41 | <annevk> | Unicode is also decidedly less modular. It affects e.g. what whitespace and identifiers can consist of in JavaScript |
| 09:42 | <Stevef_> | annevk: no requests, you have to telll it as you see it |
| 09:43 | <SimonSapin> | what’s the unicode exception? |
| 09:43 | <jgraham> | Unicode is unstable, but people tend not to object when you reference it |
| 09:43 | <jgraham> | (without specifying a particular version) |
| 09:45 | <jgraham> | For some reason, in that case, people accept that the dependency will be a single reusable library |
| 09:46 | <annevk> | https://twitter.com/dirkschulze/status/263591602960879617 hehe |
| 09:48 | <SimonSapin> | I think that stability is not binary: there is a whole scale from something widely implemented and in a "set in stone" rec, to the crazy idea in a CSS editor’s draft that no-one heard about or intends to implement |
| 09:50 | <jgraham> | Well yes, I think that everyone agrees on that in principle |
| 09:50 | <annevk> | "set in stone" is exactly right, typical RECs are bogus if you look at details, and most if you just glance over them |
| 09:50 | <annevk> | (I meant including the quotation marks is exactly right.) |
| 09:50 | <jgraham> | The Process is a lot further toward the binary end of the scale though |
| 09:51 | <annevk> | SimonSapin: the "crazy idea in a CSS editor's draft" is a distraction I think |
| 09:51 | <SimonSapin> | how so? |
| 09:51 | <annevk> | SimonSapin: it's the exception |
| 09:51 | <SimonSapin> | do you mean it shouldn’t be there at all? |
| 09:51 | <jgraham> | FWIW,if I were editing, I think I would work like this: |
| 09:52 | <jgraham> | Bugfixes - straight into the main spec |
| 09:52 | <jgraham> | New ideas without any review - onto a work branch to get review |
| 09:52 | <annevk> | no I mean that a) that argument carries way less weight and b) everyone agrees a stability annotation system would be useful |
| 09:52 | <jgraham> | Then I would annotate sections for actual stability |
| 09:53 | <annevk> | SimonSapin: the "crazy idea" argument is often used, but in practice it's rarely a problem, whereas a REC not describing what you actually need to implement whereas there's an "editor's draft" that does is common |
| 09:53 | <annevk> | and is a problem |
| 09:54 | <SimonSapin> | my point is that the crazy idea might gradually get more and more attention, discussion and acceptance : the stability scale is not discrete, there are all the intermediate states |
| 09:54 | <jgraham> | Yeah |
| 09:54 | <jgraham> | Of course |
| 09:54 | <annevk> | if it gets acceptance it might not be so crazy :) |
| 09:54 | <annevk> | anyway, I'm gonna miss yet another train this way |
| 09:55 | <jgraham> | But if it is "fantasai's personal scratchpad for collaboration with TabAtkins_" (a use case that came up at TPAC), that sounds like "shared branch" to me |
| 09:55 | <SimonSapin> | agreed |
| 09:55 | <jgraham> | If it is something that is a new idea, that the editor thinks is good and that shows some interest, that should be main spec + a label indicating high instability |
| 09:56 | <SimonSapin> | another data point: I just made a clarification change to Selectors4. It applies equally to level 3 but I didn’t bother because of the Process |
| 09:56 | <jgraham> | If it is something that has two implementations that don't yet fully interoperate, that is main spec + a label that says high stability |
| 09:59 | <zcorpan> | hsivonen: maybe v.nu should validate http headers |
| 10:00 | <zcorpan> | " Of the 217 invalid values, most were attempting to mix SAMEORIGIN with Allow-From, which ends up causing Chrome and IE9 to simply fail open and allow any site to frame the resource." seems scary |
| 10:00 | <zcorpan> | (http://www.veracode.com/blog/2012/11/security-headers-report/ ) |
| 10:07 | <zcorpan> | for STS, maybe we should ignore the specified value and always treat it as "long max-age" |
| 10:11 | <odinho> | zcorpan: That's a good idea. |
| 10:12 | <zcorpan> | these results need pondering |
| 10:27 | <annevk> | jgraham: yeah, I don't scratch in the spec, like Hixie I use some text file on a server or mailing list discussion |
| 10:32 | <zcorpan> | annevk: http://lists.w3.org/Archives/Public/uri/2012Nov/0013.html |
| 10:33 | <annevk> | sweet |
| 10:34 | <annevk> | zcorpan: I think what he should maybe do first is produce a grid of results |
| 10:34 | <annevk> | zcorpan: then we can re-evaluate the specs |
| 10:35 | <zcorpan> | so keep webkit as the expected result for now? |
| 10:37 | <annevk> | we could make them match the URL Standard |
| 10:38 | <annevk> | just noticed fragment behavior is even weirder than I thought :/ |
| 10:39 | <annevk> | back in a bit |
| 11:15 | <jgraham> | SteveF: You might find http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1897 illuminating |
| 11:15 | jgraham | assumes he will read the logs |
| 11:36 | <MikeSmith> | zcorpan: about v.nu providing validation for headers, in a follow-up comment to that security-headers posting somewhere, I remember seeing a mention of the idea of a linter for headers |
| 11:38 | <MikeSmith> | would be good to have at least for whatever higher-priority problem cases we might be able to identify |
| 11:38 | <MikeSmith> | like the same-origin with Allow-From case you cited there |
| 11:41 | <hsivonen> | MikeSmith: which reminds me that I should drive the HttpClient update into the repo |
| 11:41 | <hsivonen> | as a side effect of updating HttpClient, I ended up validating the headers that the validator uses as part of its own operation |
| 11:41 | <MikeSmith> | oh |
| 11:41 | <MikeSmith> | nice |
| 11:42 | <hsivonen> | i.e. Content-Length and the like |
| 11:43 | <jgraham> | hsivonen: BTW <main><p></main><p> seems like particularly nasty behaviour |
| 11:45 | hsivonen | expects IE10 to surpass IE6 for Christmas in usage |
| 11:45 | <hsivonen> | jgraham: ouch. yeah. :-( |
| 11:46 | <hsivonen> | <p> still sucks |
| 11:46 | <hsivonen> | (though Hixie considers it a feature) |
| 11:46 | <hsivonen> | I may have to revise my opinion of not changing the parser if <main> is introduced to the platform |
| 11:55 | <annevk> | I like <p> too |
| 11:57 | <odinho> | <p> and not doing </p> is a feature. I use it a lot :P[6~[D[D[D[C[C[D |
| 11:58 | <Stevef_> | jgraham:thanks |
| 12:00 | <Stevef_> | so i guess that I add advice about adding main as per zcorpans email and let implementers fight it out... |
| 12:00 | <karlcow> | hsivonen: nice for HTTP validation. I often wished that http://redbot.org/ was into the markup validator |
| 12:01 | <jgraham> | Stevef_: Yes, I think I would monkey-patch the parsing algorithm for now and look for pushback |
| 12:02 | <Stevef_> | jgraham: OK thanks again! |
| 12:03 | <jgraham> | (it is easier to put the change in and back out later than the opposite) |
| 12:22 | <annevk> | zcorpan: my tentative plan is to require http://unicode.org/reports/tr46/ btw for IDNA |
| 12:22 | <annevk> | zcorpan: prolly with "Transitional" set |
| 12:23 | <MikeSmith> | ah that |
| 12:23 | <MikeSmith> | yeah |
| 12:23 | <annevk> | zcorpan: trying to work out with Mark Davis if we can improve the language around the hooks somehow |
| 12:23 | <MikeSmith> | I remember now that Mark Davis brought that to everybody's attention when we had he TPAC in Santa Clara |
| 12:24 | <MikeSmith> | there was even a dinner meeting to talk about it |
| 12:24 | <annevk> | I wish I started this a year earlier :/ |
| 12:24 | <annevk> | He emailed me a bunch of times too, but I wasn't involved in any way with any of this |
| 12:24 | <MikeSmith> | yeah you lazy sluggard |
| 12:24 | <MikeSmith> | you just sat around daydreaming all this time |
| 12:27 | <MikeSmith> | annevk: do any UAs actually implement that yet? |
| 12:37 | <annevk> | MikeSmith: I'm not sure what UAs do |
| 12:46 | <SimonSapin> | http://beta.ohmytoast.com/toast/view/3f4b8a72-dda2-6834-bdbe-d0203c46bade |
| 12:46 | <zcorpan> | annevk: that's close but not exactly what opera does, right? |
| 12:47 | <zcorpan> | the emails about conversion of opera's tests annoy me |
| 12:48 | <zcorpan> | people should be thankful that we released tests at all |
| 12:48 | <zcorpan> | not complain that them not being in the right format yet blocks the Process |
| 12:49 | <zcorpan> | W3C, if you don't give us a pleasant work environment for testsuites, well, you know the drill |
| 12:51 | <karlcow> | is /007 a leading zero a license to kill http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07727.html |
| 12:51 | <karlcow> | * double zero |
| 12:52 | <annevk> | zcorpan: I'm not sure what Opera does |
| 12:53 | <zcorpan> | annevk: ok. same here :-( |
| 12:53 | <annevk> | zcorpan: Opera e.g. applies Punycode to â„¢ whereas that's invalid per IDNA2008 and should be mapped per IDNA2003 / #46 |
| 12:53 | <zcorpan> | though i haven't looked at this closely either |
| 12:53 | <annevk> | zcorpan: I would strongly encourage to revert the IDNA2008 patch for now |
| 12:57 | <annevk> | zcorpan: I need to fix some bugs in the DOM and XHR, I guess then I'll work on that |
| 12:57 | <annevk> | I read the relevant RFCs now so I do at least know what the ideas are behind the 3 strategies, need to look into the details a bit more |
| 12:58 | <annevk> | and maybe make a post comparing the models |
| 13:47 | <annevk> | http://www.microsoft.com/learning/en/us/offers/html5.aspx (via #fronteers) |
| 13:48 | <zewt> | first impression of this stuart guy: he doesn't have much experience with list discussions (as I skip over his mail) |
| 13:57 | <annevk> | which list? |
| 13:58 | <zewt> | whatwg, just a four-page wall of text |
| 14:00 | <annevk> | oh, he's been around for a long time |
| 14:00 | <hsivonen> | are the minutes from last night’s URL meeting still available somewhere? or the audio? |
| 14:02 | <hsivonen> | note to self: don’t install OpenJDK security patches when Eclipse is running |
| 14:02 | <zewt> | easy solution: don't run eclipse |
| 14:03 | <zewt> | (results may vary) |
| 14:03 | <annevk> | seems actually like he gives extremely useful feedback |
| 14:03 | <zewt> | not saying it's not useful, just that it's a wall of text, heh |
| 14:05 | <annevk> | hsivonen: all I can find is http://tools.ietf.org/wg/iri/minutes which is not yet filled in |
| 14:05 | <hsivonen> | annevk: ok. :-( |
| 14:05 | <annevk> | hsivonen: there's some humorous minuting in #whatwg irc-logs |
| 14:05 | <hsivonen> | did they record audio? |
| 14:05 | <hsivonen> | annevk: I saw those and wanted to see more |
| 14:05 | <hsivonen> | podcast idea: audio from URL meetings |
| 14:10 | <annevk> | hsivonen: it looks like there should be, but it's not clear there is |
| 14:10 | <annevk> | in particular http://www.meetecho.com/ietf85/recordings is 404 |
| 14:13 | <annevk> | hsivonen: http://www.ietf.org/audio/ietf85/ietf85-209-20121106-1700-pm3.mp3 |
| 14:13 | <annevk> | hsivonen: starts at 1:43 |
| 14:13 | <annevk> | hsivonen: I guess I'm gonna listen now too |
| 14:17 | <annevk> | hsivonen: really starts 4:30 or so |
| 14:26 | <zcorpan> | "this is a working group that is not doing very much work" |
| 14:33 | <annevk> | so this is news to me |
| 14:33 | <annevk> | I thought Larry was planning to tackle this, but he's actually trying to find someone else to do it |
| 14:37 | <odinho> | annevk: Are you doing the MS HTML5 course? :D |
| 14:41 | <MikeSmith> | he's teaching it |
| 14:41 | <MikeSmith> | without access to IE |
| 14:41 | <hsivonen> | annevk: thanks. is that file still being appended to? or is just a case of the IETF serving a file without Content-Length? |
| 14:41 | <karlcow> | brainwaves |
| 14:42 | <hsivonen> | apparently just the latter |
| 14:42 | <annevk> | hsivonen: it has been buffering here for a while and now seems complete, I should have downloaded it instead I guess |
| 14:42 | <annevk> | hsivonen: but these are supposed to be static resources |
| 14:42 | <annevk> | hsivonen: static resources are hosted elsewhere |
| 14:42 | <annevk> | hsivonen: euh, streaming resources |
| 14:42 | <hsivonen> | yeah, it’s a static resource without Content-Length |
| 14:43 | <annevk> | HTTP is hard |
| 14:43 | <annevk> | even for the IETF |
| 14:44 | <annevk> | stuff gets good at 28 |
| 14:44 | <annevk> | it has the terrorists bit |
| 14:45 | <hsivonen> | only has left audio channel? |
| 14:45 | <hsivonen> | MP3 is hard, too? |
| 14:46 | <annevk> | even text/plain is hard :) |
| 14:46 | <annevk> | or moving away from it is, maybe :p |
| 14:55 | <annevk> | I wish the IETF was on IRC |
| 14:59 | <jgraham> | NIH |
| 15:01 | <annevk> | 44 minutes in it is explained that only browsers want "fixup" and web spiders don't |
| 15:01 | <annevk> | it's like all the arguments and explanation I gave on the mailing list went to waste |
| 15:01 | <karlcow> | annevk: which web spiders? |
| 15:02 | <karlcow> | because if I remember at least for Google, there was an intent to behave like a headless browser. |
| 15:02 | <annevk> | karlcow: curl/wget? Bing/Google |
| 15:02 | <annevk> | anything really |
| 15:03 | <danbri> | is there a transcript? |
| 15:04 | <karlcow> | It is strange to think that (search engine) web spiders will not want to behave like browsers as they are made to index what a human could access. |
| 15:06 | <danbri> | so a headless old-style browser was something that showed you a document; a headless shiny-futuristic browser, is an all singing, all dancing pseudo-OS |
| 15:06 | <karlcow> | I can imagine a client which do not want fixup for testing an API, but that could be implemented with a switch in the client. |
| 15:06 | <danbri> | wanting to behave like the former sounds easier |
| 15:07 | <hsivonen> | the observation that there’s Stop Energy against URL work everywhere except the WHATWG was pretty apt |
| 15:07 | <karlcow> | The Web is not an easy ride. :) |
| 15:07 | <hsivonen> | the naming because there’s no versioning thing is so theoretical. sad. |
| 15:08 | <annevk> | danbri: couldn't find a transcript |
| 15:08 | danbri | nods |
| 15:08 | <annevk> | danbri: I would appreciate one because I can't easily scan this MP3 file in Chrome and I think I'm missing points people are making |
| 15:09 | <danbri> | tried Opera? |
| 15:09 | karlcow | loves scribes o/ |
| 15:09 | <annevk> | so far though I'm not really convinced this is a good use of my time, especially since they appear to not have read my emails closely which would take them only a couple of minutes |
| 15:09 | <annevk> | whereas this is taking me an hour |
| 15:13 | <annevk> | Larry is channelling the WHATWG now |
| 15:13 | <annevk> | 51 in |
| 15:13 | <annevk> | it's pretty good |
| 15:17 | <annevk> | lol |
| 15:17 | <annevk> | hober gave actual feedback, they skipped over it, prolly didn't know he represented a browser |
| 15:21 | <annevk> | oh, they get to it now |
| 15:22 | <sedovsek> | Is position: sticky already implemented in any of the browsers? |
| 15:25 | <annevk> | "The W3C is at a lower level in the standards food chain than the IETF" |
| 15:28 | <odinho> | Don't like the sticky. |
| 15:29 | <broquaint> | sedovsek: http://updates.html5rocks.com/2012/08/Stick-your-landings-position-sticky-lands-in-WebKit |
| 15:30 | <sedovsek> | Support right now is Chrome 23.0.1247.0+ (current Canary) and WebKit nightly. |
| 15:30 | <sedovsek> | Thanks. |
| 15:31 | <odinho> | Seems like a feature designed in a very restrictive way to do a popular thing right now. |
| 15:34 | <hsivonen> | "The error handling in a health information system is different from error handling on a porn site." |
| 15:34 | <odinho> | And help, anyone know how to get to the real page of player.vimeo.com/video/52914691 ? I don't have flash, so I always push the "download" button on vimeo to see videos, -- but I can't get to the non-flash site from that url. vimeo.com/52914691 doesn't work. |
| 15:34 | <hsivonen> | I guess whoever said that hasn’t looked at the screens in a hospital and seen that there are browser-based interfaces to heald information systems |
| 15:35 | <hsivonen> | *health |
| 15:36 | <annevk> | sometimes I wonder if you hear like decade old arguments that were never updated |
| 15:39 | <hsivonen> | I wonder if anyone told the IETF about xsd:anyURI |
| 15:41 | <annevk> | I like how the IESG had a similar range of reactions to doing the URL Standard at the IETF (from optimistic to snickering) |
| 15:41 | <annevk> | 1:07 in |
| 15:43 | <annevk> | iPad Mini commercial 12:30 in, mnot got one! |
| 15:43 | <annevk> | 1:12:30* |
| 15:45 | karlcow | heads to hsivonen http://losangeles.cbslocal.com/2012/01/17/city-council-to-vote-on-mandatory-condom-use-for-adult-film-stars/ |
| 15:56 | <jgraham> | karlcow: If real life is like Grey's Anatomy, I think porn stars and hospital staff need exactly the same kind of error protection in that regard |
| 15:56 | <jgraham> | (note: I have never seen Grey's Anatomy) |
| 15:59 | <annevk> | I wonder if beyond 1:20 there's anything useful or if it's just about chartering |
| 15:59 | <karlcow> | I don't know what is Grey Anatomy, but yes for the rest. |
| 15:59 | <jgraham> | It seems to be a hospital drama in which there is very little hospital and lots of drama |
| 16:00 | <karlcow> | ah ! ok ☺ like Web standards then… little technology and lots of drama ;) |
| 16:05 | <annevk> | so earlier in (forgot the time) mnot asked about normatively referencing WHATWG |
| 16:05 | <annevk> | could be done, but you'd had to copy the relevant bit in |
| 16:05 | <annevk> | so it wouldn't change |
| 16:05 | <annevk> | brilliant |
| 16:08 | <annevk> | at 1:28:-- there's a bit about URI scheme registration |
| 16:08 | <annevk> | someone from Microsoft bulk registered the schemes mentioned on Wikipedia |
| 16:35 | <GPHemsley> | FTR: http://wiki.whatwg.org/wiki/WHATWG_Wiki:How_to_create_a_user_account |
| 17:36 | <gavinp> | Is an autoconfirmed user here able to help me, gavinp⊙co get a whatwg wiki account? |
| 17:36 | <gavinp> | Hixie: pingity |
| 17:37 | <smaug____> | annevk: ^ |
| 17:37 | <annevk> | yeah I can |
| 17:38 | <gavinp> | actually, I already had an account. |
| 17:38 | <gavinp> | Gavinp |
| 17:39 | <annevk> | ah okay |
| 17:39 | <gavinp> | my apologies for taking your time. Thanks all the same for your time! |
| 17:39 | annevk | goes back to refactoring XHR |
| 17:58 | <annevk> | Hixie: XHR now uses JavaScript global environment as a concept |
| 17:59 | <annevk> | Hixie: it became much easier to follow I think as a result :) |
| 18:14 | <annevk> | relevant bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19892 |
| 18:35 | <hober> | anything i should bring up in the unicode meeting? |
| 18:37 | <TabAtkins_> | FINISH THE UTR-50 REPORT |
| 18:37 | <TabAtkins_> | IT'S BEEN MONTHS SINCE THEY DECIDED ON WHAT TO DO |
| 18:40 | <hober> | yeah, that's why i'm in the room :) |
| 19:02 | <MikeSmith> | where's the details on the unicode meeting? |
| 19:03 | <MikeSmith> | hober: ↑ |
| 19:04 | <hober> | MikeSmith: i don't know offhand where the meeting info is posted |
| 19:04 | <MikeSmith> | ok |
| 19:05 | <MikeSmith> | oh |
| 19:05 | <Adept> | Hello |
| 19:05 | <MikeSmith> | yall are hosting it |
| 19:05 | <MikeSmith> | http://www.unicode.org/timesens/logistics-utc133.html |
| 19:05 | <MikeSmith> | hey Adept |
| 19:05 | <MikeSmith> | hmm |
| 19:06 | <MikeSmith> | not much details there |
| 19:06 | <hober> | yeah, i biked over for the utr50 discussion |
| 19:07 | <MikeSmith> | I bet the meeting next week in Hanoi would be more fun |
| 19:07 | <MikeSmith> | you should have picked that one instead man |
| 19:07 | <MikeSmith> | the beer costs like 20 cents |
| 19:07 | <MikeSmith> | though it's unpasteurized |
| 19:07 | <Adept> | sentatic beer ? :) |
| 19:08 | <MikeSmith> | and the guy that serves it to you has to suck out of hose from a bucket |
| 19:08 | <TabAtkins> | Do shared workers outlive the last page that opened them? |
| 19:08 | <MikeSmith> | bia hoi |
| 19:08 | <gavinp> | I'm confused. What does it mean for a beer to be unpasteurized? |
| 19:08 | <gavinp> | Most beer is not a sterile product; there's live yeast in it, or at least yeast cysts. |
| 19:08 | <TabAtkins> | gavinp: It means... they don't pasteurize it? |
| 19:08 | <gavinp> | And you can't make beer without boiling it first, that's how you catalyze the breakdown of the malt so it will ferment. |
| 19:09 | <MikeSmith> | gavinp: I'm not good with words |
| 19:09 | <gavinp> | OK. I guess I don't understand beer production. |
| 19:09 | <Adept> | only English language , or some russian ? |
| 19:09 | <MikeSmith> | it doesn't keep like other beer |
| 19:09 | <MikeSmith> | or something |
| 19:09 | <MikeSmith> | bia hoi man |
| 19:09 | <TabAtkins> | Adept: If you're asking what languages you can speak in this room, mostly English, though we have some Dutch lying around. |
| 19:09 | <karlcow> | wooot next week in Hanoi… damn. |
| 19:10 | <karlcow> | too late I'm already heading to Fujisawa next week. |
| 19:10 | <Adept> | TabAtkins , thk :) |
| 19:10 | <gavinp> | Ah, I just don't know 'bout beer production. In the USA, foreign draught beer and canned & bottled beer is normally pasteurized, but domestic draught beer is not. |
| 19:10 | gavinp | idles again. |
| 19:10 | <TabAtkins> | So anyway, hey, about those Shared Workers. |
| 19:10 | TabAtkins | doesn't want to try and decipher lifetime semantics from the spec right now. |
| 19:11 | MikeSmith | was going to ask HIxie's boilerplate question, "Does the spec not make that clear?" |
| 19:11 | <TabAtkins> | Lifetime semantics are nearly never clear. |
| 19:11 | <Adept> | red wine like some ? |
| 19:12 | <MikeSmith> | even Hixie doesn't always know that "that" is when he asks it |
| 19:12 | <Hixie> | tis true |
| 19:13 | <Adept> | gavinp , now beer is powder |
| 19:13 | <MikeSmith> | btw some of the band names from the band names list at the bottom of http://www.unicode.org/timesens/calendar.html should be added to our band-names list |
| 19:13 | <MikeSmith> | e.g., Ideographic Rapporteur Group |
| 19:14 | <Adept> | But I do my natural red wine :) |
| 19:16 | <Adept> | You can find out? who tried Native Client SDK ? |
| 19:31 | <MikeSmith> | wow dhyatt over on #webkit asking for review |
| 19:32 | <MikeSmith> | oh he's asking SImon Fraser |
| 19:32 | <MikeSmith> | but still |
| 19:33 | <MikeSmith> | there should be a "Hyatt's waiting on me for code review" beer mug awarded for that |
| 19:38 | <MikeSmith> | TabAtkins: Hixie is ignoring your question about persistent workers |
| 19:39 | <Hixie> | what's the question? |
| 19:39 | <MikeSmith> | Hixie: "Do shared workers outlive the last page that opened them?" |
| 19:40 | <Hixie> | shared workers last as long as people have references to them |
| 19:40 | <Hixie> | doesn't have to be documents |
| 19:40 | <Hixie> | could e.g. be other workers |
| 19:40 | <Hixie> | so long as they're themselves opened (indirectly) by a document |
| 19:40 | <Hixie> | the ownership is decided via the MessagePort objects |
| 19:40 | <Hixie> | iirc |
| 19:40 | <Hixie> | so short answer no, long answer yes. |
| 19:41 | <MikeSmith> | that sounds like a good message for a fortune cookie, man |
| 19:41 | <divya> | ahaha |
| 19:41 | <karlcow> | :D |
| 19:41 | divya | thinks of posting it to w3cmemes and have a yoda meme around it |
| 19:42 | <divya> | MikeSmith: your gin joke never made it :( |
| 19:43 | <MikeSmith> | divya: I tried to pushed the w3cmemes button at the time but I was too ginned up and pushed another button and send it somewhere else |
| 19:43 | <MikeSmith> | divya:btw I hope you over your cold |
| 19:44 | <MikeSmith> | and high five on your book getting published soon |
| 19:44 | <MikeSmith> | I will shoplift some copies of it for sure once I can get my hands on some |
| 19:44 | <divya> | MikeSmith: i am miraculously over it. i am shocked myself. |
| 19:44 | <divya> | MikeSmith: LOLOLOLOL thanks |
| 19:45 | <MikeSmith> | thank Jesus for you cold recovery |
| 19:45 | <divya> | ahahahah |
| 19:45 | <divya> | or should I thank TPAC |
| 19:45 | <divya> | everyone who was at TPAC is sick @ office. |
| 19:45 | <MikeSmith> | oh |
| 19:45 | <MikeSmith> | well that sucks |
| 19:45 | <MikeSmith> | but at least you're better so too bad for the rest of em! |
| 19:45 | <divya> | inorite. i think I am the only one left standing. |
| 19:45 | <divya> | ahahaha |
| 19:45 | <divya> | EXACTLY |
| 19:46 | <MikeSmith> | anyway I think God was focusing on helping you get over your cold instead of listening to prayers from Mitt |
| 19:46 | <divya> | HAHAHAHHAA |
| 19:46 | <divya> | this might make me a believer again. |
| 19:46 | divya | makes note to visit temples next time in India |
| 19:47 | <MikeSmith> | I can take you to some good temples when you visit here |
| 19:48 | <MikeSmith> | get you some of the voodoo trinkets they sell at temples here |
| 19:48 | <MikeSmith> | problem is those are almost all for traffic safety or getting good grades at school |
| 19:48 | <divya> | MikeSmith: naiceee |
| 19:48 | <divya> | all the more reason to find excuses to visit japan |
| 19:49 | <divya> | traffic safety trinklets would be good. |
| 19:49 | <divya> | i assume all mechanical means of transportation must give way to pedestrians. |
| 19:49 | <MikeSmith> | heh |
| 19:49 | <divya> | which is not a good assumption when the traffic signal is red for pedestrians |
| 19:53 | <MikeSmith> | divya: mostly here the taxi drivers pretend they can't see you |
| 19:53 | <MikeSmith> | so you have to kick their mirrors off with you boots |
| 19:53 | <MikeSmith> | to teach them a lesson |
| 19:54 | <MikeSmith> | because they roll their windows up when they see you coming |
| 19:55 | <MikeSmith> | all right friends we have a Disposition of Comments |
| 19:55 | <MikeSmith> | of sorts |
| 19:55 | <MikeSmith> | http://w3c.github.com/html/CR/doc/ |
| 19:55 | <MikeSmith> | FWIW |
| 19:55 | <divya> | ahahah MikeSmith |
| 19:55 | <divya> | what the what is a DOC |
| 19:56 | <MikeSmith> | shows how many comments we responded to during Last Call |
| 19:56 | <MikeSmith> | and how we responded |
| 19:56 | <MikeSmith> | where "we" equals Hixie |
| 19:56 | <divya> | ahaha |
| 19:57 | <MikeSmith> | in this case it shows that Hixie is agreeable 38.75% of the time and disagreeable 61.25% of the time |
| 19:57 | <MikeSmith> | which pretty much matches my anecdotal experience closly |
| 19:58 | <divya> | AHAHAH |
| 19:58 | <karlcow> | divya: Disposition Of Comments. :) |
| 19:58 | <divya> | ya ya i know that karlcow which is why i was asking. coz i didnt know what that meant |
| 19:58 | <karlcow> | the nightmare of working groups |
| 19:59 | <divya> | ahaha |
| 20:05 | <Hixie> | ok i have a shed here, i figure we'll put bikes in it |
| 20:06 | <Hixie> | anyone got an opinion on the colour? |
| 20:06 | <Hixie> | specifically: |
| 20:06 | <Hixie> | what should this ImageBitmap interface be called |
| 20:06 | <Hixie> | it's an interface with initially no properties, though i expect we'll eventually add stuff like height, width, maybe some methods |
| 20:06 | <Hixie> | it represents bitmap data, i.e. image, that can be used for drawing with minimal delay |
| 20:07 | <Hixie> | and it can be copied around over postMessage() |
| 20:07 | <Hixie> | it's the replacement for HTMLImageElement in workers |
| 20:07 | <Hixie> | candidate colours so far are "Bitmap", "BitmapImage", and "ImageBitmap". I think I prefer the second of these; the former kind of implies you can edit the pixels. |
| 20:08 | <annevk> | hober: I want them to fix UTS #46 |
| 20:08 | <annevk> | hober: In particular I want the algorithm there to be clearer |
| 20:09 | <annevk> | hober: I need something which you pass the domain string, which allows ASCII characters such as "_" and prolly ";", and then returns a list of ASCII labels, with either the last label being empty for a trailing dot, or an explicit trailing dot flag |
| 20:09 | <annevk> | hober: (or of course an error of some kind) |
| 20:10 | <Hixie> | annevk: you can only get a Blob out of XHR once the download is complete, right? |
| 20:10 | <annevk> | hober: Mark Davis has probably seen this in his inbox |
| 20:10 | <annevk> | Hixie: that is currently the case |
| 20:10 | <Hixie> | k |
| 20:11 | <MikeSmith> | Hixie: in your party-rocking survey I vote for "BitMap" |
| 20:11 | <Ms2ger> | That sounds like something else to me |
| 20:11 | <MikeSmith> | what else would it be? |
| 20:11 | <Hixie> | slightlyoff: i have an object which needs to represent something that can only be created once the data for it is available (don't want the object to be constructed while it's pending network I/O, so that the object can be used synchronously) |
| 20:11 | <Ms2ger> | A map of bits |
| 20:12 | <Ms2ger> | /flags |
| 20:12 | <annevk> | Hixie: for HTMLImageElement you know the data is available, same for HTMLCanvasElement and such |
| 20:12 | <annevk> | Hixie: so those can be done sync and via a constructor |
| 20:12 | <Hixie> | slightlyoff: this means that when the data for this object is coming from the network, its construction has to be done async, so for some of the ways it is created, it needs a factory method |
| 20:12 | <annevk> | Hixie: I think for Blob we should have ImageBitmap.create(blob) (static method) |
| 20:12 | <Hixie> | slightlyoff: my question is, which do you think is more important: providing a consistent way of building this object for all mechanisms, or providing a real constructor for the ones where it's not necessary to be async? |
| 20:13 | <Hixie> | annevk: HTMLImageElement can be delayed on network I/O. |
| 20:13 | <annevk> | Hixie: you'd throw or something if load has not dispatched yet |
| 20:13 | <Hixie> | i'm leaning towards consistent mechanism, otherwise the error handling has to be drastically different |
| 20:13 | <Hixie> | annevk: that's lame. |
| 20:14 | <annevk> | Hixie: that's how drawImage() already works |
| 20:14 | <Hixie> | annevk: the way it works in practice is that you want for the image's onload. |
| 20:15 | <Hixie> | annevk: which means you have this object hanging around that you could use to paint, but which you're avoiding using because if you do it'll fail. |
| 20:16 | <annevk> | hmm mkay; I still prefer ImageBitmap.create(..., callback) over the factory thing though |
| 20:16 | <Hixie> | that would be inconsistent with, like, the entire rest of the platform |
| 20:17 | <annevk> | putting factory methods on the global object is not necessarily consistent either, and static methods are used on e.g. URL |
| 20:17 | <Hixie> | URL is new and wildly inconsistent with the platform :-) |
| 20:18 | <annevk> | not much platform without them :p |
| 20:19 | <Hixie> | ? |
| 20:19 | <Hixie> | i mean the object |
| 20:19 | annevk | was using a smiley |
| 20:19 | <Hixie> | k :-P |
| 20:19 | <Hixie> | anyway really my question is "consistency for life" or "constructors where possible" |
| 20:20 | <Hixie> | i guess the other option is toImageBitmap(callback) on all these objects |
| 20:20 | <annevk> | (I'll also note Element.create() has been floating around) |
| 20:20 | <Hixie> | yeah but that seems DOA |
| 20:21 | <annevk> | I'd be interested what slightlyoff has to say about this |
| 20:21 | <annevk> | It's kinda annoying to wait for load I suppose, but otherwise you have to wait for the callback... |
| 20:23 | <Hixie> | you'll have to most of hte time anyway |
| 20:23 | <Hixie> | since most of the time you'll be using either HTMLImageElement or Blob |
| 20:26 | <Hixie> | annevk: btw instead of Element.create I now use http://junkyard.damowmow.com/516 |
| 20:26 | <Hixie> | annevk: which i find works rather nicely |
| 20:26 | <Hixie> | E('element', { title: "attributes" }) returns an element with an attribute |
| 20:26 | <Hixie> | attribute dict is optional |
| 20:27 | <TabAtkins> | Hixie: The context of the question about SharedWorkers was if that would help us with the more complex use-cases around the "kill onbeforeunload" jihad. |
| 20:27 | <Hixie> | annevk: E('element', E('anotherElement')); returns an element with a child |
| 20:27 | <Hixie> | annevk: E('element', 'text') returns an element with a child text node "text" |
| 20:28 | <TabAtkins> | Hixie: Yes, I use that too. What proved useful was to make the thing fully n-ary, with complete array flattening. |
| 20:28 | <Hixie> | so e.g. E('p', 'Hello ', E('a', { href: "/" }, 'World'), '!'); is like <p>Hello <a href="/">World</a>!</p> |
| 20:28 | <Hixie> | TabAtkins: yeah |
| 20:28 | <TabAtkins> | So you can pass as many arguments as you want, *and* group them arbitrarily into arrays. |
| 20:28 | <Hixie> | yup |
| 20:29 | <Hixie> | i don't recall if i support multiple arrays, but i agree that'd be a good thing too |
| 20:29 | <Hixie> | (and F(...) is like E() but returns a fragment instead of an element) |
| 20:29 | <TabAtkins> | Though I ended up with El.div(...) |
| 20:29 | <annevk> | Hixie: looks simple enough to script too... It would be nice to add something like that, but we can't just take up window.E I think :) |
| 20:29 | <TabAtkins> | HTML.div would be fine too. |
| 20:30 | <Hixie> | ah, yes, i do support multiple arrays. neat. |
| 20:30 | <arv> | What methods may throw TYPE_MISMATCH_ERR? Should it be deprecated in favor of TypeError? |
| 20:30 | <Hixie> | TabAtkins: yeah, doing that would be interesting, and would mean you could easily do SVG. and MathML. |
| 20:30 | <TabAtkins> | Yup. |
| 20:30 | <annevk> | arv: yeah maybe, if you think it's worth it |
| 20:31 | <TabAtkins> | And we already have a CSS global sitting around for this purpose, too. |
| 20:31 | <annevk> | arv: file a bug on DOM? |
| 20:31 | <annevk> | arv: I can do a query |
| 20:31 | <arv> | annevk: thanks |
| 20:31 | <arv> | annevk: It is used in a whole lot of places in WebKit but they all look like TypeErrors |
| 20:32 | <Hixie> | ok well back to ImageBitmap, I'm gonna stick all these factories on the global object and see how many people complain |
| 20:32 | <annevk> | arv: I bet HTML uses it a lot |
| 20:32 | <annevk> | anyway, gotta run |
| 20:33 | <Ms2ger> | Hixie, hmm, I don't seem to find email about your canvas changes in March |
| 20:33 | <Ms2ger> | I don't have to go look into public-html archives, do I? :) |
| 20:33 | <TabAtkins> | Hixie: Do you just discriminate the second argument based on being an Object, for determining whether it's an attr bag or a child? |
| 20:34 | <Hixie> | Ms2ger: you mean v3? |
| 20:34 | <Ms2ger> | ... maybe? |
| 20:34 | <Ms2ger> | I would've guessed v5 |
| 20:34 | <Hixie> | TabAtkins: (typeof attributes != 'string') && (!(attributes instanceof Node)) |
| 20:34 | <Hixie> | Ms2ger: uh yeah. v5. |
| 20:34 | <Hixie> | whatever |
| 20:34 | <Hixie> | v some number. |
| 20:35 | <Ms2ger> | Unless you just happen to remember if lineDashOffset is the thing we implement as mozDashOffset |
| 20:35 | <Hixie> | Ms2ger: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Mar/0269.html |
| 20:36 | <Hixie> | Ms2ger: it's similar, but not identical, iirc. |
| 20:36 | <Hixie> | Ms2ger: (based on feedback from mozilla that we shouldn't do what mozDashOffset did, also iirc) |
| 20:36 | <Hixie> | TabAtkins: so just checking it's not a valid child, basically |
| 20:43 | <zcorpan_> | Hixie: instanceof Node fails cross-window |
| 20:43 | <Hixie> | close enough for my purposes |
| 20:44 | Ms2ger | goes back to marking <main> emails as read |
| 20:50 | <Ms2ger> | Hixie, this is one for you: http://i.minus.com/ibx7mxJlLVaXp5.gif |
| 20:56 | <TabAtkins> | Hixie: And not an array either, presumably? |
| 21:10 | <gavinp> | Dumb question: how do I create a page in the wiki? |
| 21:11 | <TabAtkins> | Make a link to a non-existent page. Follow that link. |
| 21:11 | <TabAtkins> | Then edit the page you end up at. |
| 21:11 | <gavinp> | OK. I just navigated to a non existent page |
| 21:11 | <annevk> | or just URL hack it |
| 21:11 | <gavinp> | http://wiki.whatwg.org/wiki/Link_prerender_events |
| 21:11 | <gavinp> | As annevk suggested |
| 21:11 | <gavinp> | and there was no edit option presented to me. |
| 21:11 | <gavinp> | Does Gavinp lack the mojo? |
| 21:11 | <TabAtkins> | Don't url-hack it, because then there's no guarantee that you'll remember to actually link the page from somewhere. ^_^ |
| 21:11 | <TabAtkins> | Free-floating pages are the death of wikis. |
| 21:12 | <gavinp> | OK. I will stop URL hacking, since I love TabAtkins. |
| 21:12 | <annevk> | gavinp: left from search there should be "create" |
| 21:12 | <annevk> | gavinp: as long as you add a category URL hacking is fine |
| 21:12 | <gavinp> | Here's the complete text: "Link prerender events |
| 21:12 | <gavinp> | There is currently no text in this page. You can search for this page title in other pages, or search the related logs." |
| 21:12 | <annevk> | also, pretty sure GPHemsley and I track stuff that's being added and make sense out of it |
| 21:14 | <divya> | annevk: ahahaha glad to know your views are being expanded (w.r.t chat conversation) |
| 21:14 | <annevk> | gavinp: http://html5.org/temp/whatwg-wiki-create.png |
| 21:15 | <annevk> | gavinp: if you don't see that, I can create it for you I guess |
| 21:18 | <gavinp> | I do not see that. That's what I have been trying to say. |
| 21:18 | <gavinp> | Please create it for me, or, I'd prefer to have the mojo so that I don't come beg each time. |
| 21:18 | <gavinp> | But, I doubt I do this often. |
| 21:18 | <gavinp> | I am "Gavinp" |
| 21:19 | <annevk> | gavinp: sorry about that |
| 21:19 | <annevk> | there's a page now, hopefully GPHemsley upgrades your account |
| 21:19 | <annevk> | I have no idea how to do that and couldn't find it either |
| 21:19 | <gavinp> | Outstanding, thanks! |
| 21:35 | <GPHemsley> | gavinp: Ah, one of the requires to become an autoconfirmed user is to have a minimum number of edits. (Only autoconfirmed users can create new pages.) |
| 21:35 | <GPHemsley> | gavinp: I forget whether the minimum is 1 or 5. |
| 21:35 | <GPHemsley> | gavinp: If it's 1, then just creating the dead link should be enough. |
| 21:36 | <GPHemsley> | gavinp: But there is also a time aspect to being autoconfirmed. |
| 21:38 | <GPHemsley> | gavinp: You may also be at a disadvantage because your account is older. (Counter-intuitive, I know.) |
| 21:40 | <annevk> | GPHemsley: because we vet who's registered I think we should allow those registered to do most things |
| 21:40 | <annevk> | GPHemsley: or is there some hole in that reasoning? |
| 21:40 | <GPHemsley> | annevk: It's a bit of a cushion in case we turn registration back on. |
| 21:41 | <GPHemsley> | annevk: But I don't necessarily disagree with you. |
| 21:42 | <GPHemsley> | As soon as I remember how, I'll make gavinp a permanent autoconfirmed user. |
| 21:46 | GPHemsley | wonders if he made a permission change that made the option disappear. |
| 21:47 | <GPHemsley> | Apparently I did. |
| 21:47 | <GPHemsley> | >_< |
| 21:48 | <Hixie> | TabAtkins: i don't check if it's an array, but that's just a bug. |
| 21:53 | <GPHemsley> | annevk: OK, administrator will now see the "User rights management" link restored to the Special pages page. |
| 21:53 | <GPHemsley> | +s |
| 21:53 | <annevk> | IRI WG may have given up on the WHATWG, but I thought I'd give it one last shot: http://lists.w3.org/Archives/Public/uri/2012Nov/0015.html |
| 21:53 | <annevk> | GPHemsley: cool |
| 21:55 | <Hixie> | annevk: not saying you should do this, but if you want to get them on board, what might help is documenting what software you have tested, what software you intend to test but haven't, and what software you haven't tested and are unlikely to test |
| 21:56 | <Hixie> | annevk: not sure exactly how to test a lot of this, e.g. URLs are used all over the place in the SIP stack, but I dunno how you'd test a SIP client's or server's URL handling exactly |
| 21:56 | <annevk> | I mainly want to stop misrepresenting my position |
| 21:56 | <Hixie> | good luck with that |
| 21:56 | <annevk> | want them* |
| 21:56 | <annevk> | yeah, too much 386 I guess |
| 21:57 | <Hixie> | people still fight strawmen over what i do with html :-) |
| 21:57 | <GPHemsley> | gavinp: You are now a permanent autoconfirmed user. Enjoy! |
| 21:57 | <annevk> | And I should test more than wget/curl and browsers I suppose, but then there's enough difference there to converge first |
| 21:59 | <Hixie> | i suspect they're all basically sharing the same relatively small set of URL parsing libraries, and that it's therefore possible to converge somewhat reasonably |
| 21:59 | <Hixie> | but it's always possible that e.g. the SIP world's handling of URLs is so far from the browser's world, that WebRTC browsers are going to have to end up with two different URL parsers. |
| 22:00 | <Hixie> | that would be worth discovering and speccing, maybe by calling them different things |
| 22:00 | <Hixie> | no idea how to test the SIP side of that, really, though |
| 22:03 | <annevk> | I don't know SIP so there's that |
| 22:03 | GPHemsley | finds a standard dated 1987-04-31 |
| 22:03 | <divya> | what is that? |
| 22:03 | <annevk> | but I suspect it will come up if what you say is the case. Someone is going to notice there's more than one library, attempts to merge them, and succeed/fail. |
| 22:30 | <Hixie> | bikeshed painters, if any of you have a better idea for the name of the object that you get using getContext('foo') that represents a transferable <canvas> proxy, let me know |
| 22:30 | <Hixie> | also if you can think of a better term than "worker" for the argument to getContext() |
| 22:30 | <Hixie> | right now i'm using "CanvasTransferableRenderingContext" which isn't ideal |
| 22:31 | <TabAtkins> | How do you know what kind of context it'll be if you start out with getContext('worker')? |
| 22:31 | <Hixie> | the object you get back itself has a getContext() method |
| 22:31 | <TabAtkins> | Oh, weird. |
| 22:31 | <Hixie> | see http://junkyard.damowmow.com/515 |
| 22:31 | <Hixie> | and yeah, if you have any better ideas for this i'm definitely all ears |
| 22:32 | <Hixie> | i'm not sure how else to do it |
| 22:32 | <Hixie> | the idea is to be able to have a worker paint to a canvas |
| 22:32 | <Hixie> | but you can't send the canvas to the worker |
| 22:32 | <Hixie> | so you have to send a kind of proxy object |
| 22:32 | <TabAtkins> | I think someone already shot down the idea of just making Canvas transferable, and turn into the neutered thing when passed to a worker? |
| 22:33 | <Hixie> | the main problem with doing that is that i'm scared of whehter it'll block up from ever adding the DOM to workers |
| 22:33 | <Hixie> | because transfering another element would presumably take it out of its home DOM |
| 22:33 | <Hixie> | but we'd be stuck with transfering a canvas not doing that |
| 22:33 | <TabAtkins> | Ah, true. |
| 22:33 | <TabAtkins> | Why can't you make the context object transferable? |
| 22:33 | <Hixie> | too much state |
| 22:34 | <TabAtkins> | Hm, that makes sense. You'd have to copy over the entire stack of context data. |
| 22:34 | <Hixie> | e.g. i don't even want to consider how much pain it'd be to transfer a live 3D GL context around between processes |
| 22:34 | <Hixie> | bad enough that we're requiring implementations have a way to push instructions across process boundaries |
| 22:35 | <TabAtkins> | Actually, from my conversations with Greg (one fo the webgl people, and my cubemate), that's not problematic to him. |
| 22:35 | <Hixie> | good, maybe he can convince some of the others ;-) |
| 22:35 | <TabAtkins> | He just wants a way to hook up a canvas on the DOM end to a context on the Worker end, so that you can blit across. |
| 22:36 | <Hixie> | my plan is to have a commit() method on the CanvasTransferableRenderingContext that tells the UA "ok, now apply all of that to the context" |
| 22:36 | <Hixie> | the on-screen context, that is |
| 22:36 | <Hixie> | s/context/surface/ |
| 22:36 | <TabAtkins> | Actually, though, I think your idea is what he's asking for. You get a canvas hooked up to a dummy bitmap, which can only be manipulated in teh worker. |
| 22:36 | <TabAtkins> | Right? |
| 22:37 | <Hixie> | well |
| 22:37 | <Hixie> | you can describe it in various ways depending on how you look at it |
| 22:37 | <Hixie> | but basically yes, except there's also a link to a <canvas> in the Document that you can push to |
| 22:37 | <Hixie> | if you want to |
| 22:37 | <TabAtkins> | Yeah, that's what I meant. |
| 22:38 | <Hixie> | (push to without using postMessage()) |
| 22:38 | <Hixie> | i may also provide a way to get a context that is just entirely in the worker |
| 22:38 | <Hixie> | on which commit() does nothing |
| 22:38 | <TabAtkins> | You have a canvas on the document side which is solely a dumb bitmap, can't be manipulated directly. It's just a rectangle into the Worker world, which is doing the actual drawing on the context. |
| 22:38 | <Hixie> | yeah |
| 22:38 | <TabAtkins> | Yeah, both of those are good. |
| 22:38 | <Hixie> | you'll probably be able to grab a frame of the canvas bitmap from the main thread |
| 22:39 | <TabAtkins> | Yeah, you can always draw that canvas onto another canvas. |
| 22:39 | <Hixie> | which grabs a frame at some arbitrary call to commit() |
| 22:41 | <TabAtkins> | What's the purpose of ImageBitmap here? I'm not sure I understand it from these notes. |
| 22:42 | <Hixie> | something you can pass drawImage() in a worker |
| 22:42 | <TabAtkins> | Can't you just pass an ImageData? |
| 22:43 | <TabAtkins> | I presume you mean for the Document to send something to the worker, that it can use for drawing? |
| 22:43 | <Hixie> | well whatever solution we use, has to be something you can populate lazily. ImageData can be implemented lazily, but only so long as the author doesn't accidentally poke at the actual pixel data. |
| 22:44 | <Hixie> | and it's really easy to accidentally do that. |
| 22:44 | <Hixie> | e.g. dumping state to the console |
| 22:44 | <Hixie> | so you really want an ImageData that specifically doesn't expose any pixels |
| 22:45 | <TabAtkins> | Oh, interesting. You want it to be lazy so that it's cheaper to send to the Worker? |
| 22:45 | <Hixie> | yeah |
| 22:45 | <annevk> | Hixie: ImageBlob maybe? |
| 22:45 | <annevk> | but I guess it wouldn't implement the same stuff so that's not really good |
| 22:45 | <Hixie> | TabAtkins: and back again; one common use case will be for the worker to do the drawing, then grab a frame to send back to the document so that it can be drawn at the same time as something on the DOM is moved |
| 22:46 | <Hixie> | annevk: it's not a Blob, yeah. Also that sounds like it'd include SVG. |
| 22:46 | <TabAtkins> | Okay, I see. And if it's lazy, you can just late-compute the actual data in the Document, drawing directly from the Worker's information (or reverse), without exposing transfer details in a detectable way. |
| 22:46 | <TabAtkins> | s/detectable/unsafe/ |
| 22:46 | <Hixie> | yeah |
| 22:46 | <Hixie> | you can in fact just do it all on the GPU |
| 22:46 | <Hixie> | at least, i assume so :-) |
| 22:47 | <TabAtkins> | Yeah, okay. |
| 22:47 | <TabAtkins> | (I think so, yeah.) |
| 22:47 | <TabAtkins> | I'd like to run this through Greg next time he shows up in the office. |
| 22:47 | <TabAtkins> | And I'll think on the names I guess. ^_^ |
| 22:48 | <Hixie> | i'm speccing the strawman so hopefully it'll be something concrete people can comment on |
| 22:52 | <TabAtkins> | Okay, I think I'm okay with this, and I'll give you concrete feedback from the dude who pesters me about this exact subject every month or so soon. ^_^ |
| 22:52 | <Hixie> | :-) |
| 22:53 | <annevk> | getContext returning a <canvas>-like object seems a bit weird |
| 22:53 | <Hixie> | this whole thing is weird |
| 22:54 | <annevk> | doing getWorkerCanvas() or some such seems cleaner |
| 22:54 | <Hixie> | what's the difference? |
| 22:54 | <Hixie> | it's just another method that's mutually exclusive |
| 22:54 | <Hixie> | it's semantically identical |
| 22:56 | <annevk> | makes it clear what's actually going on |
| 22:56 | <TabAtkins> | I'm with annevk, fwiw. getContext() doesn't normally return something that you can further call getContext() on. |
| 22:57 | <annevk> | could even do new WorkerCanvas(HTMLCanvasElement) |
| 22:58 | <Hixie> | TabAtkins: getContext() returns one of two objects, that have basically nothing in common with each other. I'm not sure one can draw conclusions from that. |
| 22:58 | <Hixie> | annevk: constructors with side-effects on the arguments are weird. |
| 22:58 | <Hixie> | also, it's not just a worker canvas. |
| 22:58 | <Hixie> | you can use this in the main thread too. |
| 22:58 | <Hixie> | it's just a disconnected context. |
| 22:58 | <TabAtkins> | Hixie: They have plenty in common! They're both objects that represent how you can push pixels onto the canvas. |
| 22:58 | <Hixie> | (for some definition of "disconnected") |
| 22:59 | <Hixie> | TabAtkins: gl's doesn't really push pixels, it pushes scenes that then turn into pixels. :-) |
| 23:00 | <TabAtkins> | Same difference. |
| 23:00 | <Hixie> | it's not that far from this new object, either |
| 23:05 | <TabAtkins> | The new object exists solely to link up the canvas with the eventual context that will be created from it. It's like a deferred context or something. |
| 23:05 | <Hixie> | a proxy of sorts |
| 23:05 | <TabAtkins> | Yup. |
| 23:05 | <Hixie> | except it's not even that |
| 23:05 | <Hixie> | it's a representation of the canvas |
| 23:06 | <Hixie> | a context factory proxy context |
| 23:06 | <TabAtkins> | It's like "var proxy = canvas.getContext.bind(canvas);" or something - just yanking the getContext method out of the canvas, so that you'll still get the right link-up when it's eventually called. |
| 23:06 | <Hixie> | yeah, more or less |
| 23:07 | <Hixie> | creating it also makes height and width no longer work on the canvas |
| 23:07 | <Hixie> | and prevents getContext() from working again |
| 23:08 | <TabAtkins> | Yeah, the various fiddly necessary details. |
| 23:08 | <TabAtkins> | Anyway, I emailed Greg so I wouldn't have to wait for him to come in. |
| 23:08 | <TabAtkins> | He only gets into the office once or twice a week. |
| 23:11 | <Hixie> | another question: |
| 23:11 | <Hixie> | if i do: var img = new Image(); img.src = 'a'; var bitmap = createImageBitmap(img, cb); img.src='b'; |
| 23:12 | <Hixie> | should cb be invoked with null, an ImageBitmap for 'a', or an ImageBitmap for 'b'? |
| 23:12 | <TabAtkins> | Why you gotta bug me with race conditions. |
| 23:12 | <Hixie> | what if the setting of src to 'b' happens in a 0ms setTimeout? |
| 23:12 | <Hixie> | this isn't really a race condition, the timing is all defined |
| 23:12 | <Hixie> | i just need to know what we want to have happen |
| 23:13 | <TabAtkins> | Ideally, with 'a'. Setting src is synchronous already. It would be confusing if you could ask it to create an imageBitmap and then set what image for it to use *afterwards*. |
| 23:13 | <TabAtkins> | Also, it would be pretty cool if createImageBitmap took a string, and acted as if an <img> was loaded with that as its src. |
| 23:13 | <Hixie> | right now if you do var img = new Image(); img.src = 'a'; img.src='b';, per spec, only one HTTP request is made, and it's for 'a'. |
| 23:13 | <Hixie> | er |
| 23:14 | <Hixie> | for 'b', not 'a' |
| 23:14 | <TabAtkins> | Because you dont' start the load until the next microtask or whatever? |
| 23:14 | <Hixie> | and if you do a timeout to set 'b', and getting 'a' required a DNS lookup, then you'll probably still only get one request, for 'b' |
| 23:15 | <Hixie> | every time you set src or srcset it resets the img element and starts the fetch afresh, and the fetch itself isn't started until the event loop spins. |
| 23:15 | <Hixie> | (stable state) |
| 23:16 | <TabAtkins> | Hmm. Personally, I still stick with my answer - I think it should snapshot the image that you pass to it at that moment. |
| 23:16 | <Hixie> | i'm thinking maybe the way to go is to just get the URL out of the <img> and fetch that independent of the <img> |
| 23:17 | <TabAtkins> | Yeah, that's what I'm saying. |
| 23:17 | <TabAtkins> | Though if the bitmap is already loaded, you can of course skip the fetch itself. |
| 23:17 | <TabAtkins> | But that can be an impl detail. |
| 23:17 | <Hixie> | yeah |
| 23:17 | <Hixie> | well, it's a detectable detail |
| 23:17 | <Hixie> | but yeah |
| 23:17 | <Hixie> | that's a lot of functionality to duplicate in the spec, but it does mean we can support createImageBitmap(url) |
| 23:18 | <TabAtkins> | Only insofar as caches are detectable, right? |
| 23:18 | <TabAtkins> | Well, if the same url would result in different images at different times, it would be different. |
| 23:18 | <TabAtkins> | But again, caching. |
| 23:19 | <Hixie> | similar to caching, yes |
| 23:19 | <Hixie> | <img> elements have their own special cache though |
| 23:19 | <TabAtkins> | Ah, weird. |
| 23:19 | <Hixie> | yeah |
| 23:19 | <Hixie> | hmmmm |
| 23:19 | <Hixie> | also, some UAs don't fetch images immediately |
| 23:20 | <Hixie> | so we'd have to decide, in those UAs, whether calling createImageBitmap(img) would fire img.onload |
| 23:20 | <Hixie> | or if the img would remain not loaded |
| 23:20 | <Hixie> | with the fetch being done independently |
| 23:20 | <Hixie> | hmmmmmmmm. |
| 23:20 | <TabAtkins> | Interesting question! I lean toward loading it. |
| 23:21 | <Hixie> | another problem is crossorigin="" |
| 23:21 | <TabAtkins> | Ah, yeah. |
| 23:21 | <Hixie> | if we did createImageBitmap(url) we'd have to provide a separate argument for that |
| 23:21 | <Hixie> | and then duplicate all that work |
| 23:21 | <Hixie> | or factor it out |
| 23:21 | <Hixie> | anne's suggestion earlier is sounding better and better |
| 23:21 | <Hixie> | (just bail if the img isn't loaded yet) |
| 23:22 | <TabAtkins> | Hah. |
| 23:22 | <TabAtkins> | Would be nice to be able to load an image directly in the worker. |
| 23:22 | <Hixie> | well you can do that with XHR |
| 23:22 | <Hixie> | XHR the image as a blob, then createImageBitmap(blob) |
| 23:22 | <TabAtkins> | Ah, indeed. |
| 23:23 | <TabAtkins> | That would be why you were asking Anne earlier about adding 'image' as an XHR type. |
| 23:23 | <Hixie> | you know, if we send <img> packing and require that the data be fetched, we wouldn't really need to do anything asynchronously |
| 23:23 | <Hixie> | and we could make slightlyoff happy and have a constructor instead |
| 23:23 | <TabAtkins> | The blob case still needs asynchrony, no? |
| 23:24 | <Hixie> | can you get a blob before you have its data? |
| 23:24 | <TabAtkins> | I dunno. Haven't worked with blobs yet. |
| 23:24 | <Hixie> | what's the maximum latency on getting Blob's data? wider web? NFS? disk i/o? ram? |
| 23:25 | <Hixie> | if it's disk i/o or worse, that's a problem, indeed |
| 23:26 | <Hixie> | based on FileReader, i guess it's disk i/o or worse |
| 23:27 | <TabAtkins> | Yeha, I think it's disk i/o. |
| 23:27 | <TabAtkins> | The blob is like imagebitmap - it represents, abstractly, a bunch of data that might be expensive to fetch/transfer eagerly. |
| 23:27 | <TabAtkins> | No reason why its latency couldn't be wider web, either. |
| 23:27 | <Hixie> | yeah but imagebitmap is intended to have max latency O(GPU) |
| 23:28 | <Hixie> | Blobs know their length with latency O(RAM) |
| 23:28 | <Hixie> | but presumably not their data, yeah |
| 23:28 | <TabAtkins> | Actually, blob.size was a mistake in the API that we can't take back now. |
| 23:28 | <TabAtkins> | It should have been asynchronous too. |
| 23:28 | <Hixie> | indeed |
| 23:28 | <dgorbik> | Hello everybody! Which pseudo-elements use property whitelists? I would like to see examples of the implementation in the code for those. |
| 23:29 | <TabAtkins> | ::first-line and ::first-letter. |
| 23:29 | <TabAtkins> | Implementations are... varied and tricky. |
| 23:31 | <TabAtkins> | dgorbik: The rule of thumb is that, if the pseudo-element is a normal, independent box, it can take all properties. If it wraps existing content (particularly, in ways that might violate the tree structure of HTML), it has a whitelist. |
| 23:31 | <Hixie> | blob is easier than img because once created, it can't change identity |
| 23:31 | <TabAtkins> | Right. |
| 23:31 | <Hixie> | i think sanity is going o require that <img> has to be loaded before it can be used here |
| 23:31 | <Hixie> | anne wins again |
| 23:31 | <TabAtkins> | That's fine with me. |
| 23:31 | <TabAtkins> | Waiting for img.onload to send the data to the worker seems okay. |
| 23:32 | <TabAtkins> | You'll have to wait for that at some point anyway. |
| 23:32 | <Hixie> | yeah, it's not that i have a problem with |
| 23:32 | <Hixie> | it's anne being right! |
| 23:32 | <Hixie> | :-P |
| 23:32 | <TabAtkins> | This is a major problem. |
| 23:32 | <TabAtkins> | We can't be seen agreeing with a terrorist. |
| 23:32 | <Hixie> | true dat |
| 23:33 | <dgorbik> | TabAtkins: thanks. Is features.usesFirstLineRules related to those? |
| 23:34 | <TabAtkins> | dgorbik: No clue! If you're talking about Firefox, I'm a WebKit hacker. |
| 23:34 | <dgorbik> | that's in webkit |
| 23:34 | <TabAtkins> | Then still, dunno. Our ::first-line implementation is crazy, and I'm never ever touching it. |
| 23:35 | <TabAtkins> | (Granted, I'm not sure how sane any implementation of ::first-line can be.) |
| 23:35 | <dgorbik> | Thanks, I will look closer at this |
| 23:37 | <Hixie> | ok the object you get from canvas is no called TransferableCanvasRenderingContextFactory, which is obviously not a name I can seriously keep in the spec |
| 23:38 | <Hixie> | so painters, your input is more than ever welcome now |
| 23:38 | <Hixie> | if you don't help me get this thing down, people will start saying i hang out with java programmers |
| 23:38 | <TabAtkins> | Hahaha |
| 23:39 | <TabAtkins> | CanvasDelayedContext |
| 23:39 | <TabAtkins> | CanvasNullContext |
| 23:39 | <dglazkov> | annevk: yo |
| 23:40 | <Hixie> | if we're not returning it from getContext(), it probably shouldn't be called *Context |
| 23:40 | <Hixie> | though if we are, those are good names |
| 23:40 | <Hixie> | CanvasDelayedContext in particular |
| 23:43 | <TabAtkins> | If it's delivered from a different method, CanvasProxy. |
| 23:43 | <Hixie> | yeah, that could work |
| 23:44 | <hober> | dglazkov: he went to bed |
| 23:45 | <dglazkov> | hober: wat |
| 23:45 | <dglazkov> | okay |
| 23:45 | <dglazkov> | timezones suck |
