| 04:23 | <Hixie> | fantastic. i have a pile of code a mile high and it finds one obscure canvas performance bug in webkit and one obscure canvas clearRect(?) bug in gecko. |
| 04:23 | <Hixie> | and i basically have no way to make minimised test cases for them. |
| 04:23 | <Hixie> | sigh. |
| 04:24 | <shetech> | gotta love obscure finds. |
| 05:45 | <Hixie> | nice. webkit has a huge slowdown bug with clip() _and_ doesn't support the last argument to fillText(). |
| 05:46 | <Hixie> | so basically there's no easy way to clip user-provided text in webkit |
| 05:46 | <Hixie> | meanwhile, gecko has some crazy bug with clearRect() where it's not actually clearing the whole rect, unless i first call fillRect() on the whole canvas, then it works fine... |
| 06:35 | <Hixie> | i'm all for experimental implementations of css features getting prefixes |
| 06:35 | <Hixie> | but when EVERYONE implements the feature, can we move on already? |
| 06:35 | <Hixie> | https://developer.mozilla.org/en/CSS/-moz-linear-gradient#Cross-browser_gradients is just ridiculous. |
| 06:36 | <zewt> | on the other hand, everyone's probably afraid of being That Guy that releases something unprefixed and ends up preventing some fix or another... |
| 07:02 | <Hixie> | zewt: imho, the experimental prefixes should only be used with experimental features, not specced things. |
| 07:02 | <Hixie> | zewt: the problem is the csswg iterate for far too long instead of freezing fast like we do with the html spec |
| 07:03 | <Hixie> | they probably end up with more well-thought-out APIs eventually |
| 07:03 | <Hixie> | but in the meantime, we have to suffer through years of silliness :-) |
| 07:04 | <Hixie> | in other news, webkit has much prettier 'inset' and 'outset' border colours than firefox and opera |
| 07:04 | <zewt> | well, i've seen plenty of complaining on the lists about releasing APIs unprefixed too soon |
| 07:06 | <zewt> | with the way specs are developed these days, it might be worth clarifying somehow when the editor considers a spec stable enough for unprefixed implementations |
| 07:06 | <zewt> | seems like that's very fuzzy currently |
| 07:07 | <zewt> | the websocket thread a week ago comes to mind |
| 07:07 | <Hixie> | websocket had the worst of both worlds |
| 07:07 | <Hixie> | it didn't have prefixes, _and_ it wasn't fast-freeze |
| 07:07 | <Hixie> | the ietf really screwed that one over |
| 07:08 | <zewt> | i remember grumbling about blobs during the blob.slice thread, though to me the blob api seemed stable enough by then that it's hard to blame people for not prefixing it |
| 08:09 | <janv_> | hixie: I think textContent should be changed to text in "4.11.5.4 Using the option element to define a command" |
| 11:51 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1098 <-- anyone want to explain the behaviour of that in Gecko/WebKit to me? |
| 11:53 | <zcorpan> | jgraham: the "2" script is async? |
| 11:54 | <jgraham> | Hmm was this the big thread a while ago? |
| 11:55 | jgraham | concludes that hsivonen should not be allowed to take vacation :) |
| 11:55 | <zcorpan> | the thread with LABjs? |
| 11:56 | <jgraham> | Yeah |
| 11:57 | <zcorpan> | i think gecko had the same behavior for this case before that thread, that appendChilded scripts with src are async |
| 11:57 | <jgraham> | I thought it was the other way around, that WebKit had this behaviour first and gecko copied it. But maybe I am wrong |
| 11:57 | <zcorpan> | could be |
| 11:58 | <jgraham> | Either way it doesn't seem to match the spec afaict |
| 11:58 | <jgraham> | But I could easilly be missing something |
| 11:59 | <jgraham> | Hmm, maybe the force-async flag is relevant |
| 12:01 | <Ms2ger> | Yes, it would be |
| 12:05 | <jgraham> | So it would fall into the 5th clause of step 15 of the "prepare a script" algorithm. It's not really clear to me why there would be a big difference between the 4th and 5th clauses here though |
| 12:07 | <jgraham> | (the difference seems to be that the 4th clause ensures the relative order of appendChild inserted scripts, but the 5th does not) |
| 12:07 | <jgraham> | +external |
| 12:08 | <Ms2ger> | That's what @async means, no |
| 12:08 | <Ms2ger> | ? |
| 12:09 | <zcorpan> | it wouldn't make any difference for this case since there's only one appendChilded script, right? |
| 12:09 | <jgraham> | Right. But if one didn't have force-async set in this case, you might expect the appendChilded script to execute before the following parser-inserted script |
| 12:10 | <Ms2ger> | Expect based on what? |
| 12:10 | <Ms2ger> | Locig? See the topic :) |
| 12:10 | <Ms2ger> | Locig, really? |
| 12:11 | Ms2ger | blames his keyboard |
| 12:11 | <jgraham> | Expect based on the idea that people want a way to control the order of script execution |
| 12:12 | <matjas> | .async = false |
| 12:12 | <Ms2ger> | And not block the parser |
| 12:12 | <jgraham> | Well you can have one or the other |
| 12:13 | <jgraham> | Setting .async to false doesn't seem to have an effect |
| 12:13 | <jgraham> | Similarly clearing the force-async flag doesn't seem to have an effect in this case |
| 12:13 | <jgraham> | (it appears that setting and unsetting the async content attribute will do that) |
| 13:06 | <matjas> | jgraham: IIRC setting .async = false on a dynamically inserted script makes sure that the source order is respected as far as dynamically inserted scripts go |
| 13:07 | <jgraham> | matjas: Possibly. If that is the case I am missing the spec text that ensures it |
| 13:07 | <Ms2ger> | But not relative to parser-inserted scripts |
| 13:08 | <matjas> | Ms2ger: exactly |
| 13:08 | <matjas> | jgraham: http://hsivonen.iki.fi/script-execution/ |
| 13:09 | <jgraham> | Oh, yeah, sorry I misread you |
| 13:11 | <MikeSmith> | cool to see janv_ working on the HTML5 context-menu feature |
| 13:11 | <MikeSmith> | http://hg.mozilla.org/mozilla-central/rev/561821863607 |
| 13:14 | <jgraham> | matjas: Yeah, I have read that blog entry before, but this kind of thing is easy to not fully understand until you actually need to solve a problem |
| 13:14 | <jgraham> | At least for me |
| 13:14 | <matjas> | MikeSmith: what’s with the `data://www.mozilla.org/favicon.ico`? |
| 13:14 | <MikeSmith> | hmm |
| 13:14 | <MikeSmith> | matjas: no idea |
| 13:16 | <Ms2ger> | Just something invalid to test error handling? |
| 13:17 | <matjas> | Ms2ger: ah, duh |
| 13:23 | matjas | would’ve used data:lolwut |
| 13:23 | <MikeSmith> | heh |
| 13:24 | <Ms2ger> | lolwut |
| 13:25 | <MikeSmith> | so I wonder how well Google Swiffy works |
| 13:26 | <MikeSmith> | http://swiffy.googlelabs.com/faq.html says "Swiffy supports most of the features in Flash 5" but does that mean you can take most Flash 5 content and generate usable output from it? |
| 13:27 | <MikeSmith> | being able to author with Flash dev tools and generate Web-platform output is a pretty powerful thing, if it actually works |
| 13:29 | <robman> | wouldn't being able to author using the Web-platform to generate Web-platform be even betterer MikeSmith? 8) |
| 13:30 | <MikeSmith> | robman: no, not necessarily |
| 13:30 | <MikeSmith> | not at all, really |
| 13:31 | <robman> | really...i hate having to run windows/macosx to run adobe tools |
| 13:31 | <MikeSmith> | I hate using windows/macosx to do anything |
| 13:31 | <MikeSmith> | linux too |
| 13:32 | <MikeSmith> | OSes suck |
| 13:32 | <MikeSmith> | all of them |
| 13:32 | <jgraham> | MikeSmith: Presumably the flash tools will produce output that is no better than flash in many ways |
| 13:32 | <robman> | 8) |
| 13:32 | <robman> | MikeSmith - well you got me there |
| 13:33 | <MikeSmith> | jgraham: well, the point is the tools make things much easier for devs, they are very good tools in terms of the usability, user-friendliness, ease-of-use or however you want to term it |
| 13:34 | <jgraham> | Having nice tools is of course good |
| 13:34 | <jgraham> | But I imagine it will be easy to produce content that is inaccessible to search engines, screenreaders, etc. and hard to do the reverse |
| 13:34 | <MikeSmith> | in comparison as far as similar tools for producing Web-platform output natively, we are at the level of caveman rubbing sticks together to make fire |
| 13:35 | <MikeSmith> | jgraham: yeah, point taken |
| 13:35 | <MikeSmith> | the platform is full of tradeoffs |
| 13:35 | robman | like fire |
| 13:35 | robman | grunts |
| 13:35 | <MikeSmith> | heh |
| 13:36 | MikeSmith | is reminded of the "Fire bad!" scene in Young Frankenstein |
| 13:36 | <robman> | 8) |
| 13:38 | <MikeSmith> | "Ladies and gentlemen of the jury, I'm just a caveman. I fell on some ice and later got thawed out by some of your scientists. Your platform frightens and confuses me" |
| 16:07 | <zcorpan> | Ms2ger: you read www-archive? |
| 16:07 | <Ms2ger> | I skim it sometimes |
| 16:07 | <zcorpan> | i saw an email from björn with tests for XMLSerializer/DOMParser |
| 16:09 | <Ms2ger> | Saw those |
| 16:10 | <Ms2ger> | Those are somewhere near the bottom of my todo list |
| 16:10 | <zcorpan> | k |
| 16:50 | <cryptopsy> | is there a printable reference for html5 on whatwg.org ? |
| 16:51 | <Ms2ger> | cryptopsy, whatwg.org/html has a link hidden in the header, IIRC |
| 16:52 | <cryptopsy> | news, specs, demo, charter ... |
| 16:53 | <Ms2ger> | Did you miss the /html? |
| 16:54 | <Ms2ger> | PDF print versions: |
| 16:54 | <Ms2ger> | A4: http://www.whatwg.org/specs/web-apps/current-work/html-a4.pdf |
| 16:54 | <Ms2ger> | Letter: http://www.whatwg.org/specs/web-apps/current-work/html-letter.pdf |
| 16:55 | <cryptopsy> | how did you find that? |
| 16:56 | <Philip`> | By going to http://whatwg.org/html then reading it, I expect :-) |
| 16:56 | <Ms2ger> | And knowing where it was |
| 16:56 | <Philip`> | I suppose that helps too |
| 16:59 | <jgraham> | cryptopsy: Basically there are three stages: 1) Become a Hixie fanboi and hang on his every edit b) Get asked question about the spec c) Use knowledge gained from a) to answer b) and so impress girls/boys (depending on preference) |
| 16:59 | <cryptopsy> | i looked at the header for whatwg.org |
| 17:00 | <cryptopsy> | jgraham: i'm new to webdev, don't the html people publish a reference or spec for people to base on? |
| 17:00 | <cryptopsy> | thanks |
| 17:00 | <cryptopsy> | Ms2ger: ^ |
| 17:00 | <jgraham> | cryptopsy: Base what on? |
| 17:01 | <Ms2ger> | whatwg.org/html |
| 17:01 | <cryptopsy> | some sort of document that lists all the possible tags and their usage, like how LaTeX has? |
| 17:01 | <jgraham> | The spec is big and complex and user unfriendly because browsers are big and complex and their codebases are unfriendly |
| 17:01 | <cryptopsy> | jgraham: where is this spec? i need those additional details |
| 17:01 | <zewt> | friendly enough to me |
| 17:01 | <cryptopsy> | zewt: now you're just teasing me .. |
| 17:01 | <zewt> | perhaps in part due to years of reading specs from ietf and friends |
| 17:01 | <jgraham> | And the spec is designed to allow different big unfriendly browsers to get on without having an all out war and destroying all the little people |
| 17:02 | <jgraham> | cryptopsy: But for authors all the complexity isn't usually needed |
| 17:02 | <zewt> | jgraham: depends heavily on what part of the system you're looking at, though |
| 17:02 | <zewt> | some parts are easier to understand clearly from the spec than other docs |
| 17:02 | <jgraham> | There is a stylesheet you can apply that will remove implementation requirments from the spec |
| 17:03 | <dglazkov> | good morning, Whatwg! |
| 17:03 | <jgraham> | Or you can look at http://dev.w3.org/html5/markup/ |
| 17:03 | <zewt> | in one limited slice of the planet, i suppose |
| 17:04 | <cryptopsy> | jgraham: true |
| 17:04 | <jgraham> | zewt: "i'm new to webdev" does suggest that the finer points of how to schedule scripts might be a few orders of magnitude too complex at this stage |
| 17:05 | <cryptopsy> | not new to browsers and encoding though |
| 17:05 | <zewt> | someone new to web development probably wants any 101 documentation and some code to squint at, anyway |
| 17:05 | <cryptopsy> | im not using this to make a blog or post pictures of cats and my 95 year old grandmother |
| 17:05 | <zewt> | poor cats/grandmothers |
| 17:06 | <cryptopsy> | so where's this super detailed doc at? |
| 17:07 | <zewt> | i'm not sure we know what you're asking for |
| 17:08 | <zewt> | if you want a list of tags, jgraham's link gives that |
| 17:11 | <zewt> | the actual spec for html elements is at http://www.whatwg.org/specs/web-apps/current-work/complete/#auto-toc-4 |
| 17:13 | <zewt> | the stuff in there is really not all that scary, IMO |
| 17:13 | <Ms2ger> | zewt, that section does include many of the finer points of script timing ;) |
| 17:14 | <zewt> | as with any detailed documentation, you do have to recognize when to skip a section you don't care about :) |
| 18:06 | <TabAtkins> | telnet towel.blinkenlights.nl |
| 18:06 | <TabAtkins> | do it now |
| 18:06 | <TabAtkins> | NOW |
| 18:37 | <hober> | classic |
| 20:12 | <Hixie> | janv_: agreed; can you file a bug or send e-mail? (filing a bug is really easy; just use the little text field in the bottom right of the spec) |
| 20:27 | <jarek> | Hi |
| 20:28 | <Ms2ger> | Evening |
| 20:28 | <jarek> | Let's say there is an iframe that is 1000px wide and that was scaled down with CSS3 transforms by half with '-webkit-transform: scale(0.5)' |
| 20:28 | <jarek> | should the media queries inside the iframe assume that its width is 1000px or 500px? |
| 20:29 | <jarek> | on Safari they assume that the width is 500px, on Chrome they assume 500px |
| 20:29 | <jarek> | no, I mean the opposite |
| 20:30 | <jarek> | On Chrome scalling an iframe does not change the behavior of media queries |
| 20:30 | <jarek> | is this a bug? |
| 20:31 | <jarek> | s/ on Safari they assume that the width is 500px, on Chrome they assume 500px/ on Safari they assume that the width is 500px, on Chrome they assume 1000px |
| 20:32 | <espadrine> | The spec states that in a <script> with a src="", the content of <script>...</script> can only be comments. |
| 20:32 | <espadrine> | Is this implemented in major browsers? |
| 20:32 | <Philip`> | espadrine: That is purely an authoring conformance requirement, it doesn't affect browsers |
| 20:33 | <Philip`> | (Browsers don't run the content of the script element at all, regardless of what's in there, if it has a src attribute) |
| 20:34 | <espadrine> | Philip`: ok. Makes sense. |
| 20:34 | <Philip`> | (The requirement is there as a way of warning authors when they think they've written script code that will get executed but won't) |
| 20:34 | <espadrine> | Do you still get it through script.text though? |
| 20:34 | <Philip`> | (without making loads of existing pages that put comments inside scripts non-conforming) |
| 20:34 | <Ms2ger> | Yep |
| 20:35 | <smaug____> | hmm, probably too late to change message channels :( |
| 20:36 | <espadrine> | ok |
| 20:36 | <smaug____> | though, they are not yet implemented everywhere, so web doesn't really depend on them |
| 21:06 | <zcorpan> | smaug____: what would you want to change with message channels? |
| 21:08 | <smaug____> | still reviewing all the stuff, but I think I'd like to remove MessageChannel :) |
| 21:09 | <smaug____> | I guess it would be quite hard to convince others to do that. |
| 21:10 | <zcorpan> | why remove? |
| 21:10 | <smaug____> | there is no real use for it |
| 21:12 | <zcorpan> | hmm |
| 21:12 | <smaug____> | I'd rather do something like var newPort = otherWindow.createPort("portName"); newPort.postMessage("foobardata"); |
| 21:18 | <smaug____> | the whole port transfer is quite awkward |
| 21:18 | <zcorpan> | yeah i must say i get confused by the ports thingies |
| 21:19 | <zcorpan> | but i don't know what a better api would be |
| 21:19 | <zcorpan> | i look forward to your conclusions and proposals |
| 21:19 | <smaug____> | well, just create a new port and the other end could get "connect" event which had .port as a property |
| 21:31 | <smaug____> | Hixie: ping |
| 21:54 | <Hixie> | smaug____: pong |
| 21:55 | <smaug____> | Hixie: what is the use case for MessageChannel? |
| 21:55 | <smaug____> | why not just create ports on both sides |
| 21:55 | <Hixie> | both sides of what? |
| 21:55 | <Hixie> | the use case is the capabilities model. bascially the ability to send someone an API endpoint. |
| 21:55 | <smaug____> | but why? |
| 21:56 | <Hixie> | why what? |
| 21:56 | <smaug____> | why you need the ability to send API endpoint |
| 21:56 | <smaug____> | why couldn't you just create end point on both sides |
| 21:56 | <Hixie> | both sides of what?? |
| 21:56 | <smaug____> | say, you have two windows... |
| 21:57 | <smaug____> | var port = otherWindow.createPort("name-of-the-port"); // this would cause "connect" event in the otherWindow |
| 21:57 | <smaug____> | similar could work with workers |
| 21:57 | <Hixie> | you don't know how you've got on the other end, that's the whole point |
| 21:57 | <Hixie> | say you are providing an API to, I dunno, add someone to a contact list |
| 21:58 | <Hixie> | say you're a webmail app |
| 21:58 | <Hixie> | and you have a contact list |
| 21:58 | <Hixie> | and the contact list has an API, and one of the operations is "add someone to the contact list" |
| 21:58 | <smaug____> | and? |
| 21:58 | <Hixie> | if another part of the app wants to add someone to the contact list, they could get the local contacts API object, and then ask it to add to the contac tlist |
| 21:59 | <Hixie> | but what if the contact list wants to be implemented in another thread? |
| 21:59 | <Hixie> | now the contact API has to proxy everything though |
| 21:59 | <Hixie> | what if it's in another domain? now you have to proxy through to an iframe and then from there to the worker, etc |
| 22:00 | <Hixie> | now say that the contact list wants to grant the original user of this API the right to delete the user they added, but no other |
| 22:00 | <Hixie> | how would you do it? |
| 22:00 | <Hixie> | with message channels, you can do all this trivially. |
| 22:00 | <Hixie> | there's no need to proxy anything -- the messages just end up at the right end point |
| 22:00 | <smaug____> | ah, you want to move the port first via window level postMessage and then post it to a worker? |
| 22:01 | <Hixie> | there's no need to worry about permissions, you just give back a port and then whoever has that port can just delete that one contact. |
| 22:01 | <Hixie> | etc. |
| 22:01 | <Hixie> | for example, yeah |
| 22:01 | <Hixie> | this is just a specific example of the capabilities programming model |
| 22:01 | <Hixie> | it's like functional programming, it's just a style |
| 22:01 | <Hixie> | i mean it's like saying "what's the use case for functions being first-class objects" |
| 22:01 | <Hixie> | or "what's the use case for object-orientated programming" |
| 22:02 | <smaug____> | it is just quite awkward |
| 22:02 | <Hixie> | it's just another tool |
| 22:03 | <Hixie> | (a very powerful one, much like oop and lambdas) |
| 22:03 | <Hixie> | how is it awkward? |
| 22:03 | <smaug____> | when for common cases creating ports could be enough |
| 22:03 | <smaug____> | no need to transfer anything |
| 22:03 | <Hixie> | ? |
| 22:03 | <smaug____> | but ok, what you explained is something which isn't clear when reading the drafts |
| 22:04 | <Hixie> | yeah the drafts assume you know this programming style and that you'll recognise it :-) |
| 22:04 | <Hixie> | i should probably have an intro section that explains it or something |
| 22:04 | <Hixie> | but i'm not good at explaining it |
| 22:04 | <smaug____> | Also, "objects listed in transfer have already been transfered once before, then throw a DATA_CLONE_ERR exception and abort these steps" is easy to misread |
| 22:05 | <smaug____> | since I wasn't sure whether one can re-transfer a port |
| 22:05 | <Hixie> | that refers to the objects, not the underlying port, but yeah, i see what you mean |
| 22:06 | <smaug____> | I still don't see the need to MessageChannel |
| 22:06 | <smaug____> | for |
| 22:06 | <smaug____> | If one could create ports using createPort or such |
| 22:06 | <Hixie> | createPort === MessageChannel |
| 22:06 | <smaug____> | very much so |
| 22:06 | <Hixie> | MessageChannel is nothing but a port constructor |
| 22:07 | <smaug____> | and a bit strange one |
| 22:07 | <smaug____> | since I the idea is that the other port is sent to somewhere |
| 22:07 | <Hixie> | are you familiar with unix socket programming? |
| 22:07 | <smaug____> | yes |
| 22:07 | <Hixie> | think of ports as pipes. |
| 22:07 | <Hixie> | or rather, sockets |
| 22:08 | <Hixie> | when you create a pipe (two sockets) you get both end points |
| 22:08 | <smaug____> | sure |
| 22:08 | <Hixie> | in exactly the way MessageChannel gives you two ports |
| 22:08 | <Hixie> | this is just trying to bring that programming model to JS authors |
| 22:08 | <smaug____> | but why do you need both ends |
| 22:08 | <smaug____> | when you're going to use one end in one context and the other some other context |
| 22:11 | <Hixie> | i don't understand the question |
| 22:11 | <smaug____> | MessageChannel creates two ports in the same context |
| 22:11 | <smaug____> | and then usually, I assume, the other port is sent to otherWindow or worker or whatever |
| 22:11 | <smaug____> | right? |
| 22:11 | <Hixie> | it can be, doesn't have to be |
| 22:11 | <smaug____> | but that is the basic use case, right? |
| 22:11 | <Hixie> | just like when you create a pipe you often pass one socket to somewhere else |
| 22:12 | <smaug____> | Why couldn't you just call otherWindow.createPort() which would create one end in the executing context and one port in otherWindow |
| 22:12 | <smaug____> | if you really want to, you could call window.createPort() |
| 22:12 | <Hixie> | so you'd have otherWindow.createPort, worker.createPort, port.createPort, etc? |
| 22:12 | <smaug____> | yes |
| 22:13 | <Hixie> | that would be like having Object.addFunction, Array.addFunction, String.addFunction, etc, instead of having a Function constructor |
| 22:13 | <Hixie> | i mean i guess it's fine, but it's certainly not what i would describe as neat orthogonal api design |
| 22:13 | <smaug____> | that would be like having addEventListener in all the EventTarget objects |
| 22:14 | <Hixie> | no, addEventListener() doesn't create anything |
| 22:15 | <smaug____> | actually, window, worker and port should all inherit, if possible, some comment base interface |
| 22:15 | <smaug____> | s/comment/common/ |
| 22:15 | <Hixie> | well they all inherit from EventTarget now so that's not an option anymore |
| 22:15 | <smaug____> | you could add something between eventtarget and the current interface :) |
| 22:15 | <Hixie> | anyway sometimes you just want a standalone message channel because you're goign to be passing it to a callback |
| 22:16 | <Hixie> | the fact that you're going to send the port to someone else is not something you should need to care about when you're creating the port |
| 22:16 | <Hixie> | the port itself is just a capability endpoint |
| 22:16 | <Hixie> | you might keep it in your context, or you might not |
| 22:16 | <Hixie> | that's besides the point |
| 22:17 | <zewt> | passing them around with structured clone also means you're passing them around with an existing communications interface, rather than defining a separate event |
| 22:18 | <smaug____> | I thought the point is to create communication channels between different "contexts" |
| 22:18 | <zewt> | eg. so you can receive a message { type: "email", target: "user⊙ec", portForThisInterface: aMessagePort } |
| 22:19 | <Hixie> | smaug____: no, the point is to create a capability token. |
| 22:19 | <smaug____> | huh |
| 22:19 | <Hixie> | smaug____: it just so happens that many times, this will be used in a different context, because in the same context you could get the same effect with a simple function reference |
| 22:19 | <smaug____> | anyway, as of now, I don't think we have plans to implement MessageChannels |
| 22:20 | <Hixie> | the capability programming people will be sad |
| 22:23 | <smaug____> | and, for the common case createPort would make more sense |
| 22:23 | <Hixie> | common case of what? |
| 22:23 | <zewt> | smaug: not really |
| 22:23 | <smaug____> | that you want to enable communication between two different contexts |
| 22:23 | <Hixie> | no |
| 22:23 | <Hixie> | capability tokens aren't about communicating between different contexts |
| 22:24 | <zewt> | it'd separate port creation from other messages, so if you want to create a port with other information attached to it (a description of the port so the other side knows what to do with it), you'd end up duplicating messaging functionality |
| 22:24 | <Hixie> | any more than object orientated programming is about, say, allocating memory. or function dispatch. |
| 22:24 | <Hixie> | they're related, but that's no the point of the feature. |
| 22:24 | <smaug____> | in practice port is all about communication, like sockets |
| 22:25 | <Hixie> | i would imagine that most people writing code that creates capability tokens have the code creating the token quite separate from the communication bootstrapping code |
| 22:29 | smaug____ | disagrees, but knew that trying get rid of MessageChannel would be hard :) |
| 22:29 | <Hixie> | you didn't even know what capability tokens were an hour ago, i don't think you have much credibility in terms of opinions on how caps programming is done :-P |
| 22:30 | <smaug____> | that is not the point |
| 22:30 | <smaug____> | the point is to have easy to use APIs for web devs |
| 22:33 | <Hixie> | i'm sure we can all agree on that point |
| 22:39 | <Hixie> | if anyone has opinions on http://www.w3.org/Bugs/Public/show_bug.cgi?id=12306 it would be helpful if you could put them in the bug. Right now I'm leaning towards leaving the MUST in, which makes a lot of <canvas>-based apps non-conforming currently (especially games). |
| 22:41 | <Hixie> | hober: any chance we can get the csswg to use bugzilla? |
| 22:43 | <jgraham> | Hixie: I think that bug is angels on the head os a pin stuff that will have no effect on any part of the real world. So I wouldn't spend any time on it |
| 22:43 | <jgraham> | I also agree that having to pass around message ports seems weirdly cumbersome, but it does sound quite powerful |
| 22:46 | <Hixie> | unless you're using their power, you're really not going to need to send them over at all, as far as i can tell. for example workers create them implicitly. |
| 22:46 | <jgraham> | (it might alos be nice if the spec used the word "connected" rather than "entangled" since afaict that is the concept that you are expressing) |
| 22:46 | <Hixie> | i try to use different words so that you can more easily search for them |
| 22:46 | <Hixie> | "connect" is used for far too many concepts already |
| 22:47 | <jgraham> | In this case it sounds like you chose a difficult sounding word at random from a physcs textbook :) |
| 22:47 | <jgraham> | "Coupled" would have worked too |
| 22:47 | <jgraham> | Anyway it is not important |
| 22:48 | <jgraham> | There was already some big debate about the order of arguments in 3 argument postMessage wasn't there? |
| 22:49 | <Hixie> | well "entangled" in the quantum sense does rather describe what's going on here |
| 22:49 | <jgraham> | So it would be unwise of me to say that the current spec seems very strange |
| 22:49 | <Hixie> | i do not recall one way or the other |
| 22:49 | <Hixie> | if it's implemented i don't intend to change it |
| 22:50 | <jgraham> | Sure. |
| 22:50 | <jgraham> | I have no idea if this is implemented |
| 22:50 | <jgraham> | Presumably it is webkit-only if it is |
| 22:51 | <Hixie> | what's the order and what do you want it to do? |
| 22:52 | <jgraham> | (quantum entanglement seems rather different because the entangled parts resolve into different states as needed to preserve physical invariants. Whereas here the ports presumably have the same information on both ends) |
| 22:53 | <jgraham> | I just mean taht postMessage(message, ports, targetOrigin) seems inconsistent with postMessage(message, targetOrigin) |
| 22:53 | <jgraham> | I would expect the additional argument to be last |
| 22:54 | <Hixie> | ah well the other way to look at it is postMessage() has two forms, (message) and (message, transferrables), and Window just adds an argument on the end of those |
| 22:54 | <jgraham> | (also entanglement suggests there is some kind of randomness which I assume there is not) |
| 22:54 | <Hixie> | depends which postMessage() you think of as canonical :-) |
| 22:54 | <Hixie> | yeah entanglement certainly isn't an exact metaphor |
| 22:56 | <zcorpan> | jgraham: we implement all arguments to postMessage |
| 22:56 | <jgraham> | Well I don't find it as easy to view so the current spec makes sense and I would expect people to get it wrong more often this way around. But I don't feel strongly enough to dpend time advocating changing it or anything |
| 22:57 | <jgraham> | zcorpan: Oh, we implement the message channels stuff? |
| 22:57 | <zcorpan> | yes |
| 22:57 | <jgraham> | Well I guess I should stop complaining about it now then ;) |
| 22:57 | <Philip`> | Hixie: About the canvas bug: I guess it depends on whether you think training authors to ignore non-machine-checkable conformance requirements is a problem, or if that's already a lost cause and so the spec might as well give some idealistic vision instead |
| 22:57 | <zcorpan> | since 10.60 |
| 22:57 | <jgraham> | Ah, I thought we had just got workers, not the other stuff too |
| 22:58 | <zewt> | (i already pretty much ignore those "requirements"; they frankly seem rather nonsense to me) |
| 22:58 | <zewt> | (that one being a solid example of why) |
| 22:58 | <zcorpan> | it was implemented at the same time as workers |
| 22:58 | <jgraham> | Yeah, makes sense |
| 22:58 | <Hixie> | Philip`: yeah |
| 22:58 | <zewt> | (speaking as a random author :) |
| 22:58 | <jgraham> | (it still wouldn't be a big pain to change the argument order if it really helped. I can't image much depends on this yet) |
| 22:59 | <jgraham> | *imagine |
| 22:59 | <jgraham> | (But liek I say I really don't care all that much) |
| 22:59 | <zcorpan> | jgraham: we asked for the spec to change to the order it has now :) |
| 23:00 | <jgraham> | zcorpan: Well that was silly :p |
| 23:00 | <jgraham> | zcorpan: You mean you did? Why? |
| 23:00 | <zcorpan> | jgraham: makes sense to have the optional argument last |
| 23:01 | <Hixie> | hey, wait, yeah, what are you saying jgraham |
| 23:01 | <Hixie> | the order isn't what you said it was |
| 23:01 | <Hixie> | the order you described is what i would expect |
| 23:01 | <Hixie> | but yeah, we changed it |
| 23:02 | smaug____ | needs to tests message channels and ports in Opera, since Webkit is too buggy |
| 23:02 | <Hixie> | smaug____: file bugs :-) |
| 23:02 | <jgraham> | Oh, in that case obviously zcorpan is an eminently sensible individual with good taste |
| 23:02 | <smaug____> | I'll file a bug to remove MessageChannel :p |
| 23:02 | <jgraham> | and I am probably tired enough to not notice when I am reading an old draft |
| 23:02 | <jgraham> | :) |
| 23:02 | <jgraham> | I think this suggests that sleep might be a good thing |
| 23:03 | <Hixie> | in oher news, what is with chrome stripping off a leading "javascript:" when i post a url into the url bar |
| 23:03 | <Hixie> | damn silly computers trying to stop me hurting myself |
| 23:03 | <zewt> | your browser knows best! |
| 23:03 | <zcorpan> | jgraham: actually it was sof and tarquin who pushed for changing the order, but i guess i did the emailing to public lists |
| 23:04 | <zcorpan> | smaug____: opera should be compliant as far as i know |
| 23:04 | <smaug____> | Hixie: I think other browsers are doing similar silly things. In FF there is at least some hidden pref to get back reasonable javascript: handling |
| 23:04 | <zcorpan> | lemme know if you find bugs :) |
| 23:04 | <jgraham> | zcorpan: Ah, well obviously Opera is full of people with good taste (as long as you define good taste as "agree with me" :) ) |
| 23:05 | <zewt> | doesn't everyone? |
| 23:05 | <jgraham> | Hixie: A few scams on facebook and this is what happens :( |
| 23:07 | <zewt> | if they turn into "open the javascript console and paste this", will browsers start removing javascript consoles? heh |
| 23:08 | <Hixie> | "type in the following C code and compile it, then run it with sudo" |
| 23:08 | <zcorpan> | yeah try that on facebook |
| 23:09 | <Hixie> | (i guess that explains the way iOS prevents the user from having access to the machine) |
| 23:09 | <zewt> | well, mobile devices are as interested in protecting the carrier from the user than the user from the internet |
| 23:14 | <zcorpan> | maybe webidl can add a way to annotate an attribute so that it gets enumberable:false |
| 23:16 | <smaug____> | zcorpan: Opera seems to work well. The API is still bizarre |
| 23:16 | <zcorpan> | http://dev.w3.org/2006/webapi/WebIDL/ needs more google juice (compared to TR/) |
| 23:17 | <zcorpan> | smaug____: agree it's a bit confusing |
| 23:17 | <zcorpan> | smaug____: not convinced we should change it |
| 23:24 | zcorpan | -> sleep |