| 01:05 | <MikeSmith> | Hixie: about workers changes just checked -- are they based on an particular feedback, or just refinements? |
| 01:06 | <Hixie> | they're knock-on effects of all the work on scripts i did last week |
| 01:32 | Hixie | ponders how to define the structured-data-over-postMessage() stuff |
| 01:34 | <rubys> | jacobolus: I can't honestly speculate as to the reasons... to be clear: I initiated the conversation, this was not something that they initiated. |
| 01:35 | Hixie | wonders if that conversation is archived anywhere |
| 01:45 | <rubys> | nope, that was email from me to the two individuals I mentioned, and I'm sharing the response. |
| 01:45 | <Hixie> | ah ok |
| 01:58 | <sicking_> | Hixie, fwiw, what we implemented is slightly different from what my mail says |
| 01:58 | <sicking_> | Hixie, due to weirdness in the JSON format |
| 01:58 | <sicking> | Hixie, what we do is this: |
| 01:59 | <sicking> | Hixie, create a JS object with the following value: { para: X } (where X was the value passed to postMessage) |
| 01:59 | <sicking> | Hixie, serialize using JSON.stringify |
| 01:59 | <sicking> | Hixie, send to destination |
| 02:00 | <sicking> | Hixie, create Y = JSON.parse(str) |
| 02:00 | <sicking> | Hixie, set event.data to Y.para |
| 02:00 | <jcranmer> | sicking: Hixie is not a robot! |
| 02:00 | <sicking> | jcranmer, or so you think |
| 02:01 | <jcranmer> | sicking: it's obvious... Hixie has no big red button saying "Self Destruct DO NOT PUSH" |
| 02:02 | <sicking> | Hixie, or to put it short: event.data = JSON.parse(JSON.stringify({para: X})).para; |
| 02:02 | <Hixie> | sicking: what i'm planning on speccing doesn't mention JSON at all, it'll just check to see if the message is safe, then clone it and pass that into the event.data |
| 02:02 | <Hixie> | sicking: which should be equivalent |
| 02:03 | <sicking> | Hixie, no, such a thing can include cycles, no? |
| 02:03 | <sicking> | Hixie, there is also the issue of infinite and NaN values |
| 02:03 | <Hixie> | i will throw an exception if a cycle is detected |
| 02:03 | <Hixie> | i plan to support JS types natively |
| 02:03 | Philip` | wonders about the effects on property ordering |
| 02:03 | <Hixie> | booleans, Numbers, etc |
| 02:04 | <sicking> | Hixie, ugh, that means that we can't use the JSON serializer to send cross processes :( |
| 02:04 | <Hixie> | sicking: well i can always do something else |
| 02:04 | <Hixie> | sicking: what should i do with Infinity and NaN? |
| 02:04 | <Hixie> | JSON sucks |
| 02:04 | <Hixie> | it's worse than XML :-) |
| 02:04 | <sicking> | indeed |
| 02:04 | <sicking> | well.. |
| 02:05 | <sicking> | it errs in the wrong direction |
| 02:05 | <sicking> | it sucks less than XML, but it sucks nontheless |
| 02:05 | <Hixie> | it would suck less than XML if it defined comment syntax and defined error handling syntax |
| 02:05 | <Hixie> | er, error handling rules |
| 02:06 | <sicking> | ah |
| 02:06 | <Hixie> | anyway |
| 02:06 | <Hixie> | the syntax doesn't matter here |
| 02:06 | <sicking> | true |
| 02:06 | <Hixie> | what should i do for NaN an company? |
| 02:06 | <Hixie> | and for property ordering, as Philip` mentions? |
| 02:07 | <sicking> | so i don't care super much, but if you want JSON parity you want this: |
| 02:07 | <sicking> | 1. non-finite numbers are turned into null |
| 02:07 | <sicking> | 2. properties with the value 'undefined' are removed |
| 02:08 | <Hixie> | is that the value |undefined| or the value |"undefined"|? |
| 02:08 | Hixie | wonders how to do this in a language-agnostic manner |
| 02:09 | <sicking> | |undefined| |
| 02:09 | <jcranmer> | Hixie: series of octets with undefined contents? |
| 02:09 | <jcranmer> | s/undefined/unspecified/ |
| 02:09 | <Philip`> | I hope I'll be able to use VBScript to post structured data objects to a JavaScript worker |
| 02:10 | <jcranmer> | pth, use Malebolge to post to a Brainfuck worker :-) |
| 02:11 | <Philip`> | jcranmer: I don't think they have the concept of structured data :-p |
| 02:12 | <sicking> | Hixie, i don't feel strongly regarding if NaN/Inf/Undefined should survive across postMessage though, but i'd imagine the JS people might have more of an opinion |
| 02:12 | Hixie | wonders what happens when you call .stringify() on some of our more esoteric native objects |
| 02:12 | <Hixie> | s/on/with/ |
| 02:13 | <sicking> | Hixie, good question. I *think* that it tries to enumerate all properties and stringify those, but i haven't tried. And for most DOM objects you end up with cyclic graphs |
| 02:13 | <roc> | it would be surprising if non-finite numbers were nuked going through postMessage |
| 02:14 | <sicking> | roc, agree. i was surprised they were nuked going through JSON |
| 02:14 | <Hixie> | sicking: it seems to call [[Get]], but it strikes me that we might well have [[Get]]ers somewhere that do pretty crazy things |
| 02:14 | Hixie | is thinking he'll just do this for JS for now and screw JSON and screw VB |
| 02:14 | <Hixie> | and then we'll see what feedback is like |
| 02:15 | <Hixie> | if implementors want JSON, then I can always change it back -- but since both of you so far have said it's surprising, i'm reluctant to do it |
| 02:15 | <sicking> | Hixie, don't quote me as having an opinion either way. I'm really undecided at this point |
| 02:16 | <Hixie> | well i wasn't really basing it on your opinion so much as your experience (that you were surprised, as i was for that matter, when learning of JSON's quirks) |
| 02:17 | <sicking> | cool |
| 02:17 | <dave_levin> | hixie: If someone implemented this who supported VB, would it even be possible to create a VB worker? |
| 02:17 | <sicking> | the funny thing is that with our definition (pass {para: X} through JSON) is that |undefined| comes out correctly on the other end |
| 02:17 | <Hixie> | dave_levin: right now, no, but postMessage() isn't just for workers |
| 02:18 | <dave_levin> | The spec says that it is always Javascript. |
| 02:18 | <dave_levin> | oh ok |
| 02:18 | <sicking> | however { foo: undefined } comes out as {} |
| 02:18 | <dave_levin> | right, thx. |
| 02:18 | <Hixie> | sicking: heh |
| 02:18 | <Hixie> | dave_levin: also i expect we'll change that eventually. i'm just not sure how to do it (arguments to new Worker(), MIME types, something else). |
| 02:20 | <dave_levin> | hixie: That would be nice eventually.... |
| 02:21 | <dave_levin> | hixie: but no desire for it anytime soon from me at least :). |
| 02:21 | <Hixie> | yeah well if the js group go along their current path we might be stuck with this problem sooner than either you or i like |
| 02:22 | <Hixie> | because apparently they want future versions of js to not be the same language as current js |
| 02:26 | <blooberry> | hixie: I thought the internal factions made all nice and have backed off the major ecma facelift/overhaul plans. Or is that something else? |
| 02:27 | <sicking> | define "not be the same language" and "major facelife/overhaul" :) |
| 02:27 | <Hixie> | as far as i know the plan, long term, and possibly short term though i really have lost track of their exact plans short term, is still to invent a new language that happens to look a lot like the current language but needs out-of-band signaling to be enabled. |
| 02:27 | <Hixie> | much like VB vs JS in IE today, except more similar in syntax |
| 02:28 | <Hixie> | much like E4X did, for that matter. |
| 02:28 | <Hixie> | (which was a disaster btw) |
| 02:28 | <sicking> | there are new keywords introduced yes, which would require some sort of signaling |
| 02:28 | <Hixie> | such a bad idea |
| 02:28 | <sicking> | not sure it's a big deal |
| 02:29 | <Hixie> | requiring out-of-band signaling for the web's scripting language is a losing proposition, imho. |
| 02:29 | <Hixie> | if it's in-band, then that's fine |
| 02:30 | <sicking> | note that i didn't say out-of-band or in-band |
| 02:30 | <Hixie> | as i understand it, the js group wants it out-of-band |
| 02:30 | <sicking> | did maciej propose the |use| syntax? |
| 02:31 | <Hixie> | i haven't followed recent developments |
| 02:31 | <sicking> | ok |
| 02:31 | <Hixie> | are arrays in JS ever sparse? |
| 02:31 | <Hixie> | or are they always [0..n] ? |
| 02:32 | <sicking> | mrbkap says yes |
| 02:32 | <sicking> | they are sparse |
| 02:33 | <sicking> | they basically work just like any other object |
| 02:33 | <sicking> | if you set "1" and "10" then those are the properties that exist |
| 02:33 | <sicking> | the exception is a magical "length" property |
| 02:33 | <Hixie> | i wonder how JSON.stringify() handles that |
| 02:33 | Hixie | looks |
| 02:34 | <sicking> | ['foo', null, null, null...., "bar"] |
| 02:34 | <sicking> | did I mention that JSON rocks? |
| 02:35 | <Hixie> | as far as i can tell that is incorrect |
| 02:35 | <Hixie> | it seems it returns ['foo', 'bar'] and the indicies change |
| 02:35 | <sicking> | i don't think that was the intent, unless things recently changed |
| 02:38 | <sicking> | the moz implementation inserts null |
| 02:39 | <Hixie> | it says "For each index in value" |
| 02:40 | <Hixie> | doesn't say anything about inventing new indicies or looking at the length as far as i can tell |
| 02:40 | <sicking> | looking at http://wiki.ecmascript.org/doku.php?id=es3.1:json_support |
| 02:40 | <sicking> | it first creates a |partial| array that contains all indexes |
| 02:41 | <Hixie> | you're looking at JA() right? |
| 02:42 | <Hixie> | JA(value)? |
| 02:42 | <sicking> | uh? |
| 02:47 | <sicking> | ah |
| 02:48 | <sicking> | yeah that doc looks different |
| 02:48 | <sicking> | not sure where i got the reference to looking at http://wiki.ecmascript.org/doku.php?id=es3.1:json_support |
| 02:48 | <sicking> | err s/looking at// |
| 02:48 | <olliej> | Hixie: sicking: I think sparse array syntax is [a,,,,,,b] |
| 02:49 | <Hixie> | that's not what i meant by sparse |
| 02:49 | <sicking> | olliej, that's not what we currently output |
| 02:49 | <olliej> | Hixie: what's an example of what you meant? |
| 02:49 | <sicking> | olliej, we == firefox3.1 |
| 02:49 | <olliej> | sicking: oh well, js can parse that ;D |
| 02:49 | <olliej> | sicking: yup |
| 02:50 | <sicking> | olliej, apparently JSON is supposed to not be JS specific |
| 02:50 | <olliej> | sicking: incidentally i have drawImage(video,..) implemented in my local build of webkit :D |
| 02:50 | <olliej> | on canvas |
| 02:50 | <sicking> | olliej, hey, cool |
| 02:50 | <olliej> | sicking: just have some tidying to do |
| 02:50 | <Hixie> | olliej: can an Array object have properties '0' and '8' and nothing else? |
| 02:50 | <Hixie> | (well, other than 'length') |
| 02:50 | <olliej> | Hixie: yes |
| 02:52 | <sicking> | Hixie, ["foo",,,,,"bar"] creates such an array |
| 02:52 | <sicking> | Hixie, (in FF, dunno about specs) |
| 02:52 | <olliej> | Hixie: 2 in ['zero',,,,,,,,'eight'] |
| 02:53 | <olliej> | is false, but the length is 9 |
| 02:53 | <olliej> | sicking: that's what i was saying earlier |
| 02:53 | <sicking> | olliej, you have to forgive us JS noobs |
| 02:53 | <olliej> | sicking: [1,,3] the double , results in an empty slot |
| 02:53 | <olliej> | sicking: hehe |
| 02:54 | <olliej> | sicking: i just know this because i did the code gen for arrays in squirrelfish :D |
| 02:54 | <olliej> | array initialisers i mean |
| 02:54 | <olliej> | sicking: it gets better |
| 02:54 | <olliej> | sicking: [1,,3] results in an extra slot |
| 02:54 | <olliej> | sicking: but [1,2,,] does not |
| 02:54 | <sicking> | nice |
| 02:55 | <Hixie> | olliej: oh, interesting |
| 02:55 | <sicking> | that actually makes sense though |
| 02:55 | <Hixie> | olliej: i misunderstood |
| 02:55 | <olliej> | Hixie: np |
| 02:55 | <Hixie> | how about 'a', can that be in an array? |
| 02:55 | <olliej> | Hixie: ? as a property? |
| 02:56 | <Hixie> | yeah |
| 02:56 | <Hixie> | 'a' in foo |
| 02:56 | <Hixie> | where foo is an Array |
| 02:56 | <olliej> | Hixie: yup |
| 02:56 | <Hixie> | so the json serialiser just drops that one on the floor? |
| 02:56 | <sicking> | olliej, JSON.stringify([1,,2]) returns "[1, null, 2]" though, in firefox 3.1 |
| 02:56 | <olliej> | sicking: i suspect that's actually wrong |
| 02:57 | <sicking> | olliej, what do you think it should be? |
| 02:57 | <olliej> | sicking: inasmuch as such a thing can be wrong |
| 02:57 | <olliej> | sicking: ooh |
| 02:57 | <olliej> | sicking: does json have undefined? |
| 02:57 | <sicking> | no |
| 02:57 | <olliej> | yeah |
| 02:57 | olliej | just remembered undefined is actually just a global objedct property |
| 02:57 | <sicking> | that's a problem too |
| 02:58 | <olliej> | sicking: my guess is that the problem is |
| 02:58 | <olliej> | sicking: say JSON did produce [1,2,undefined,3] |
| 02:58 | <olliej> | or whatever |
| 02:59 | <olliej> | a person could do undefined="foo!" |
| 02:59 | <sicking> | for the record, i've stopped guessing on this stuff. Because i tend to guess on what I think makes sense. And JSON rarely agrees with me |
| 03:00 | <olliej> | maybe a malicious person could take advantage of that |
| 03:00 | <olliej> | sicking: heheh |
| 03:00 | <Hixie> | in firefox |
| 03:00 | <Hixie> | var a = new Array(); a.b = 2; a[9] = 3; JSON.stringify(a); |
| 03:00 | <Hixie> | returns [null,null,null,null,null,null,null,null,null,3] |
| 03:00 | <sicking> | olliej, only in a poor implementation |
| 03:00 | <olliej> | sicking: yes |
| 03:01 | <olliej> | sicking: i know, i'm just saying maybe that's why json doesn't produce undefined |
| 03:01 | <sicking> | olliej, a decent JSON implementation (even one written in JS) would not be affected by what global.undefined is set to |
| 03:01 | <olliej> | ah right |
| 03:01 | <Hixie> | well anyway |
| 03:01 | <Hixie> | if any of you are JS guys |
| 03:01 | <olliej> | because it could just do |
| 03:01 | <Hixie> | step 8 of JA() is underdefined |
| 03:01 | <Hixie> | because i've no idea what it means: |
| 03:01 | <Hixie> | 8. For each index in value. |
| 03:01 | <sicking> | Hixie, i'm not |
| 03:01 | <olliej> | var myLocalUndefined; if (token == "undefined") return myLocalUndefined; or some such |
| 03:02 | <olliej> | Hixie: url? |
| 03:02 | <olliej> | sicking: weee! i'm currently doing edge detection on the startrek trailer in js :D |
| 03:02 | <sicking> | hehe |
| 03:03 | <Hixie> | http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft |
| 03:03 | <sicking> | olliej, frame rate? |
| 03:03 | <olliej> | <20 would be my guess |
| 03:03 | olliej | annotates code |
| 03:05 | <Hixie> | bbl food |
| 03:09 | <olliej> | sicking: aieeee, at 640x272 == 7-8fps on my mbp |
| 03:09 | <sicking> | olliej, cool |
| 03:10 | <olliej> | sicking: thankfully there are some real performance issues with SFX in this case |
| 03:10 | <sicking> | olliej, so do you need to first paint it to the canvas, then export from canvas as a dataImage (or whatever its called) |
| 03:10 | <olliej> | sicking: yup |
| 03:10 | <sicking> | ugh |
| 03:10 | <olliej> | then do a 3x3 sobel filter |
| 03:10 | <olliej> | then into a separate buffer |
| 03:11 | <sicking> | would be nice if you didn't have to do that extra roundtrip |
| 03:11 | <olliej> | then copy it back |
| 03:11 | <olliej> | weeee |
| 03:12 | sicking | heads to dinner |
| 03:14 | <olliej> | Hixie: ping me when you return |
| 03:42 | <Hixie> | olliej: returned |
| 03:42 | <olliej> | Hixie: i realised a problem with imagedata + createimagedata, etc |
| 03:42 | <olliej> | Hixie: to make something that works safely with high dpi |
| 03:43 | <olliej> | Hixie: i want to do all my work in terms of the width/height of the image data object |
| 03:44 | <olliej> | Hixie: but many filters require a buffer (convolution, etc) |
| 03:44 | <olliej> | Hixie: so i might be tempted (in fact i realised this after noticing i already had) to create a buffer with context.createImageData(inData.width, inData.height) |
| 03:45 | <olliej> | Hixie: but those are device pixels, which will now be treated as css pixels |
| 03:45 | <olliej> | leading to badness |
| 03:46 | <olliej> | Hixie: so i think we need something akin to cloneImageData or some such |
| 03:46 | <olliej> | although i'm not entirely sure |
| 03:46 | <olliej> | Hixie: because that rules out subregions |
| 03:46 | <olliej> | etc |
| 03:52 | <roc> | I think I predicted that would be confusing :-) |
| 03:58 | <Hixie> | olliej: yeah, maybe. send mail. |
| 03:58 | <olliej> | roc: heh |
| 03:59 | olliej | has just realised he can vectorise his edge detection code |
| 03:59 | <olliej> | in js |
| 03:59 | <olliej> | :-D |
| 03:59 | <olliej> | it will be *awesome* |
| 06:16 | <eric_carlson> | Hixie: ping? |
| 06:19 | <Hixie> | hey |
| 06:21 | <eric_carlson> | Hixie: what should currentSrc return when src is a url that redirects to another file? |
| 06:23 | <Hixie> | per spec, it should return the resolved url from the attribute, before hitting the network |
| 06:23 | <eric_carlson> | Hixie: OK, that's what I though but wanted to make sure |
| 06:23 | <eric_carlson> | thanks! |
| 12:13 | <yecril71> | A Javascript plugin is user-specified code that is executed by the browser for each page that the user visits. |
| 12:13 | <yecril71> | It is an equivalent of client-side stylesheet. |
| 12:13 | <yecril71> | Internet Explorer does not provide for this by default, but perhaps other browsers do. |
| 13:23 | <yecril71> | I would object to using attr(data-*) for CSS. |
| 13:26 | <yecril71> | Seems like a backdoor for presentational attributes. |
| 13:26 | <takkaria> | it's really unlikely anyone woud do that, though, given that there are classes and ids for that sort of thing |
| 13:27 | <zcorpan> | <span data-color="red"> span { color:attr(data-color, color) } |
| 13:27 | <yecril71> | I hope so; Giovanni�s idea got me horrified. |
| 13:27 | <Dashiva> | It's more work than using @style |
| 13:28 | <yecril71> | Evidently. |
| 13:28 | <yecril71> | Except that style is insensitive to media. |
| 13:29 | <yecril71> | (and to conditional processing) |
| 13:31 | <yecril71> | And now Giovanni active promotes that quirk. |
| 13:31 | <yecril71> | actively |
| 13:32 | <zcorpan> | @media print { [style='color: red;'] { color: blue } } |
| 13:32 | <zcorpan> | with !important probably |
| 13:33 | <yecril71> | That would not hit style='color: red; background: green'. |
| 13:34 | <yecril71> | style is a parsed attribute and the parse rules cannot be reinterpreted by CSS selectors. |
| 13:34 | <takkaria> | you could do a substring match with CSS selectors, but I can't remember the syntax |
| 13:35 | <zcorpan> | [style*="..."] |
| 13:35 | <yecril71> | That would not hit style='color: #FF0000' |
| 13:35 | <zcorpan> | right |
| 13:36 | <yecril71> | but it would hit style='background-color: red' |
| 13:38 | <yecril71> | Giovanni says metadata are not displayed and immediately thereafter |
| 13:38 | <yecril71> | he wants to display it with CSS content attribute. |
| 13:39 | <yecril71> | What a mess. |
| 13:53 | <zcorpan> | should eval() do pre-lexer removal of Cf characters? |
| 13:55 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0D%0Avar%20Cf%20%3D%20%5B'%5Cu00AD'%2C%20'%5Cu0600'%2C%20'%5Cu0601'%2C%20'%5Cu0602'%2C%20'%5Cu0603'%2C%20'%5Cu06DD'%2C%20'%5Cu070F'%2C%20'%5Cu17B4'%2C%20'%5Cu17B5'%2C%20'%5Cu200B'%2C%20'%5Cu200C'%2C%20'%5Cu200D'%2C%20'%5Cu200E'%2C%20'%5Cu200F'%2C%20'%5Cu202A'%2C%20'%5Cu202B'%2C%20'%5Cu202C'%2C%20'%5Cu202D'%2C%20'%5Cu202E'%2C%20'%5Cu2060'%2C%20'%5Cu2061'%2C%20'%5Cu2062'%2C%20'%5Cu |
| 13:55 | <zcorpan> | 2063'%2C%20'%5Cu2064'%2C%20'%5Cu206A'%2C%20'%5Cu206B'%2C%20'%5Cu206C'%2C%20'%5Cu206D'%2C%20'%5Cu206E'%2C%20'%5Cu206F'%2C%20'%5CuFEFF'%2C%20'%5CuFFF9'%2C%20'%5CuFFFA'%2C%20'%5CuFFFB'%2C%20'%5CuD834%5CuDD73'%2C%20'%5CuD834%5CuDD74'%2C%20'%5CuD834%5CuDD75'%2C%20'%5CuD834%5CuDD76'%2C%20'%5CuD834%5CuDD77'%2C%20'%5CuD834%5CuDD78'%2C%20'%5CuD834%5CuDD79'%2C%20'%5CuD834%5CuDD7A'%2C%20'%5CuDB40%5CuDC01'%2C%20'%5CuDB40%5CuDC20'%2C%20'%5CuDB40%5CuDC21'%2C%2 |
| 13:55 | <zcorpan> | 0'%5CuDB40%5CuDC22'%2C%20'%5CuDB40%5CuDC23'%2C%20'%5CuDB40%5CuDC24'%2C%20'%5CuDB40%5CuDC25'%2C%20'%5CuDB40%5CuDC26'%2C%20'%5CuDB40%5CuDC27'%2C%20'%5CuDB40%5CuDC28'%2C%20'%5CuDB40%5CuDC29'%2C%20'%5CuDB40%5CuDC2A'%2C%20'%5CuDB40%5CuDC2B'%2C%20'%5CuDB40%5CuDC2C'%2C%20'%5CuDB40%5CuDC2D'%2C%20'%5CuDB40%5CuDC2E'%2C%20'%5CuDB40%5CuDC2F'%2C%20'%5CuDB40%5CuDC30'%2C%20'%5CuDB40%5CuDC31'%2C%20'%5CuDB40%5CuDC32'%2C%20'%5CuDB40%5CuDC33'%2C%20'%5CuDB40%5CuDC34 |
| 13:56 | <zcorpan> | '%2C%20'%5CuDB40%5CuDC35'%2C%20'%5CuDB40%5CuDC36'%2C%20'%5CuDB40%5CuDC37'%2C%20'%5CuDB40%5CuDC38'%2C%20'%5CuDB40%5CuDC39'%2C%20'%5CuDB40%5CuDC3A'%2C%20'%5CuDB40%5CuDC3B'%2C%20'%5CuDB40%5CuDC3C'%2C%20'%5CuDB40%5CuDC3D'%2C%20'%5CuDB40%5CuDC3E'%2C%20'%5CuDB40%5CuDC3F'%2C%20'%5CuDB40%5CuDC40'%2C%20'%5CuDB40%5CuDC41'%2C%20'%5CuDB40%5CuDC42'%2C%20'%5CuDB40%5CuDC43'%2C%20'%5CuDB40%5CuDC44'%2C%20'%5CuDB40%5CuDC45'%2C%20'%5CuDB40%5CuDC46'%2C%20'%5CuDB40%5 |
| 13:56 | <zcorpan> | CuDC47'%2C%20'%5CuDB40%5CuDC48'%2C%20'%5CuDB40%5CuDC49'%2C%20'%5CuDB40%5CuDC4A'%2C%20'%5CuDB40%5CuDC4B'%2C%20'%5CuDB40%5CuDC4C'%2C%20'%5CuDB40%5CuDC4D'%2C%20'%5CuDB40%5CuDC4E'%2C%20'%5CuDB40%5CuDC4F'%2C%20'%5CuDB40%5CuDC50'%2C%20'%5CuDB40%5CuDC51'%2C%20'%5CuDB40%5CuDC52'%2C%20'%5CuDB40%5CuDC53'%2C%20'%5CuDB40%5CuDC54'%2C%20'%5CuDB40%5CuDC55'%2C%20'%5CuDB40%5CuDC56'%2C%20'%5CuDB40%5CuDC57'%2C%20'%5CuDB40%5CuDC58'%2C%20'%5CuDB40%5CuDC59'%2C%20'%5Cu |
| 13:56 | <zcorpan> | DB40%5CuDC5A'%2C%20'%5CuDB40%5CuDC5B'%2C%20'%5CuDB40%5CuDC5C'%2C%20'%5CuDB40%5CuDC5D'%2C%20'%5CuDB40%5CuDC5E'%2C%20'%5CuDB40%5CuDC5F'%2C%20'%5CuDB40%5CuDC60'%2C%20'%5CuDB40%5CuDC61'%2C%20'%5CuDB40%5CuDC62'%2C%20'%5CuDB40%5CuDC63'%2C%20'%5CuDB40%5CuDC64'%2C%20'%5CuDB40%5CuDC65'%2C%20'%5CuDB40%5CuDC66'%2C%20'%5CuDB40%5CuDC67'%2C%20'%5CuDB40%5CuDC68'%2C%20'%5CuDB40%5CuDC69'%2C%20'%5CuDB40%5CuDC6A'%2C%20'%5CuDB40%5CuDC6B'%2C%20'%5CuDB40%5CuDC6C'%2C%2 |
| 13:56 | <zcorpan> | 0'%5CuDB40%5CuDC6D'%2C%20'%5CuDB40%5CuDC6E'%2C%20'%5CuDB40%5CuDC6F'%2C%20'%5CuDB40%5CuDC70'%2C%20'%5CuDB40%5CuDC71'%2C%20'%5CuDB40%5CuDC72'%2C%20'%5CuDB40%5CuDC73'%2C%20'%5CuDB40%5CuDC74'%2C%20'%5CuDB40%5CuDC75'%2C%20'%5CuDB40%5CuDC76'%2C%20'%5CuDB40%5CuDC77'%2C%20'%5CuDB40%5CuDC78'%2C%20'%5CuDB40%5CuDC79'%2C%20'%5CuDB40%5CuDC7A'%2C%20'%5CuDB40%5CuDC7B'%2C%20'%5CuDB40%5CuDC7C'%2C%20'%5CuDB40%5CuDC7D'%2C%20'%5CuDB40%5CuDC7E'%2C%20'%5CuDB40%5CuDC7F |
| 13:56 | <zcorpan> | '%5D%3B%0D%0Avar%20test%3B%0D%0Avar%20log%20%3D%20%5B%5D%3B%0D%0Afor%20(var%20i%20%3D%200%3B%20i%20%3C%20Cf.length%3B%20%2B%2Bi)%20%7B%0D%0A%20%20try%20%7B%0D%0A%20%20%20%20eval('te'%20%2B%20Cf%5Bi%5D%20%2B%20'st%20%3D%20%22%22%3B')%3B%0D%0A%20%20%7D%20catch(e)%20%7B%0D%0A%20%20%20%20log.push(i)%3B%0D%0A%20%20%7D%0D%0A%7D%0D%0Avar%20passed%20%3D%20log.length%20%3D%3D%200%3B%0D%0Aw(passed%20%3F%20'PASS'%20%3A%20'FAIL%3A%20'%20%2B%20log)%3B%0D%0A%3 |
| 13:56 | <zcorpan> | C%2Fscript%3E |
| 13:56 | <zcorpan> | oops |
| 13:56 | <zcorpan> | uploaded |
| 13:59 | <yecril71> | Mixed content Web pages have to worry about much more than just malformed input. |
| 14:09 | <Philip`> | Uh oh, the mailing list is getting dangerously close to a discussion of why well-formedness is harder than it seems |
| 14:10 | <Philip`> | http://blog.dieweltistgarnichtso.net/?s=%ef%bf%bf - gosh, that was unexpected |
| 14:11 | <MikeSmith> | oophs |
| 14:20 | <Philip`> | "It might be more accurate to say that HTML5 is a significantly extended subset of HTML4." - that seems almost an information-free thing to say, since any set can be seen as an extension of a subset of any other set, particularly if you take the zero-sized subset and then extend it to contain everything in the first set |
| 14:21 | <takkaria> | where's that from? |
| 14:21 | <MikeSmith> | chaals posting |
| 14:21 | <Philip`> | "[whatwg] Stability of tokenizing/dom algorithms" |
| 14:21 | Philip` | is probably being too pedantic :-) |
| 14:22 | <MikeSmith> | Philip`: yeah, "significantly extended subset" is a phrase I plan to appropriate for my own use later |
| 14:22 | <MikeSmith> | very handy |
| 14:22 | <takkaria> | ta |
| 14:22 | <jgraham> | Philip`: I did wonder what he meant |
| 14:22 | <MikeSmith> | plus, its abbreviation is SES |
| 14:23 | <jgraham> | Since an "extended subset" at best means "a non-disjoint set" |
| 14:23 | <MikeSmith> | or make that, <acronym> |
| 14:23 | <Philip`> | jgraham: Why would it mean non-disjoint? |
| 14:25 | <jgraham> | Because presumably "extended subset" implies that they have some elements in common |
| 14:25 | <jgraham> | Unless the null set is considered a subset of all sets |
| 14:25 | <hsivonen> | jgraham: the subset can be the empty set |
| 14:26 | <jgraham> | hsivonen: Oh. Well that is just silly :) |
| 14:26 | <hsivonen> | at least, humorous usage of "extended subset" is based on the possibility of the empty set being the subset |
| 14:28 | <takkaria> | Atom is thus a significantly extended subset of HTML4 too, I like it |
| 14:28 | <rubys> | me two |
| 14:29 | zcorpan | is an extended subset of html4 |
| 14:30 | <Philip`> | I'd define subsets as being something like S ⊆ T ⇔ (x ∊ S ⇒ x ∊ T) and so clearly S = ∅ is a subset of anything |
| 14:32 | <jgraham> | Philip`: Can you rewite that in english for people ho can't be bothered to look up formal logic symbols? |
| 14:34 | <Philip`> | S is a subset T if and only if (if x is a member of S, then x is a member of T) |
| 14:35 | <jcranmer> | Philip`: you need quantifiers |
| 14:35 | <jcranmer> | if and only if (for all x, ...) |
| 14:36 | <Philip`> | jcranmer: I'm, uh, leaving it implicitly quantified on purpose |
| 14:37 | <rubys> | jcranmer: I don't think so, a better translation would be: "S is a subset of T" is equivalent to saying "x is a member of S implies x is a member of T" |
| 14:37 | <Philip`> | Okay, so maybe I should have said something more like S ⊆ T ⇔ (∀ x ∊ S. x ∊ T) |
| 14:37 | <Philip`> | (It's hard writing this when my IRC font displays all these symbols as squares) |
| 14:40 | <yecril71> | That was cute, Mirc got it right :-) |
| 14:41 | <Philip`> | rubys: That's a bit too imprecise, because I could take S={1,2} and T={1,3} and x=1 and say that ""{1,2} is a subset of {1,3}" is equivalent to saying "1 is a member of {1,2}"" (and could repeat that for all values of x), which is not right |
| 14:41 | <yecril71> | Browsers do not assume that the author knows the language the document is written in. |
| 14:42 | <Philip`> | Oops, I forgot the "implies ..." bit, but that doesn't make a difference |
| 14:42 | <yecril71> | Just the opposite, they assume she does not. |
| 14:42 | <jcranmer> | my tt font has all these nice symbols |
| 14:43 | <yecril71> | Was that a sexist comment? Perhaps I should use "he" with pejorative statements? |
| 14:43 | <jcranmer> | it even has Japanese hiragana and katakana, although it's missing a fair amouint of kanji |
| 14:43 | <jcranmer> | yecril71: just dehumanize them with "it" |
| 14:44 | <yecril71> | That would be too ambiguous. |
| 14:46 | <rubys> | Philip` I think the word "implies" means more than you give it credit. |
| 14:46 | <rubys> | saying "x is a member of S implies x is a member of T" is a strong statement. |
| 14:47 | <yecril71> | Upon encountering a malformed entry, a shared content server can do one of two things: |
| 14:47 | <yecril71> | It can fix it or it can reject it. |
| 14:47 | <yecril71> | If it rejects, it can return the entry to the author for further processing. |
| 14:47 | <Philip`> | rubys: The problem is that it's ambiguous what "x" means when it's not explicitly quantified |
| 14:49 | <Philip`> | (at least when it's nested in more complex logical statements) |
| 14:49 | <rubys> | OK, I'll grant you that. An "∀ x" in front would help, or in words: "S is a subset of T" is equivalent to saying "for all x, x is a member of S implies x is a member of T" |
| 14:50 | <Philip`> | That sounds about right to me |
| 14:51 | <Philip`> | Now S and T are implicitly quantified, but I suppose that's okay since they're at the outermost level |
| 14:52 | <yecril71> | If the users cannot embed SCRIPT elements, how can they use jQuery.Validate in the first place? |
| 14:52 | <yecril71> | And if ID is not supported, why should CLASS be? |
| 14:58 | <yecril71> | I cannot imagine how submitting invalid HTML content could crash the server. |
| 14:58 | <yecril71> | And in the corporate environment. |
| 15:02 | <Philip`> | yecril71: You can bring the site down by posting ill-formed XML content, if the site is served as XHTML and displays your content to all other users, even though the server is unaffected |
| 15:10 | <yecril71> | A corporate site that would allow such unsupervised arbitrary manipulation of key elements would be pretty insane. |
| 15:10 | <Philip`> | Not really - it's what happens whenever a site lets a user post comments |
| 15:11 | <yecril71> | That affects only one page, not the whole site. |
| 15:11 | <Philip`> | and even if it's plain text, they'll forget to deal will illegal characters that mean the output will be ill-formed when the text is inserted into their page |
| 15:11 | <Philip`> | The user can post a comment to every page on the site :-) |
| 15:12 | <yecril71> | Not really; key pages should be protected anyway. |
| 15:55 | <gsnedders> | How's y'all? |
| 17:13 | <Dashiva> | "Pointing out the smallest invalid subtree" |
| 17:13 | <Dashiva> | Assuming more than one XML error, is that technically possible? |
| 17:15 | <Philip`> | It's technically vague, so you can't tell - "subtree" only makes sense after you've parsed the document, and you can't parse the document if it's ill-formed, so you can't point out an ill-formed subtree |
| 17:15 | <Philip`> | (and "ill-formed" seems to be what was meant by "invalid", if I remember correctly) |
| 17:16 | <Dashiva> | Ah, there's that angle too |
| 17:16 | <Dashiva> | Then it's even less possible :) |
| 17:19 | <gsnedders> | Philip`: A subtree of the b element exists in the character-stream: <a><b><c/></b><d></a> |
| 17:19 | <gsnedders> | Philip`: Despite that not being well-formed, the XML parser doesn't need to throw a fatal error until the </a> |
| 17:21 | <Dashiva> | gsnedders: Yeah, but we're talking about subtree containing the invalid part |
| 17:21 | <gsnedders> | Dashiva: True |
| 17:21 | <gsnedders> | Dashiva: Which is impossible |
| 17:21 | gsnedders | is half asleep |
| 17:21 | gsnedders | has been awake for five hours! |
| 17:22 | <Dashiva> | That's a long time to be half asleep! |
| 17:26 | <Dashiva> | I suppose you could parse it as HTML and keep track of where the ill-formed token ends up, but that seems awfully complicated compared to just using HTML :) |
| 17:38 | <Philip`> | Dashiva: And awfully user-hostile, if you're going to pop up a dialog box with several options for every error they made |
| 17:39 | <yecril71> | A subtree containing the invalid part is possible: <d/> |
| 17:39 | <yecril71> | This would always be a one-node subtree. |
| 17:40 | <yecril71> | Internet Explorer indicates the error by quoting the text stream. |
| 17:41 | <yecril71> | Are scripts executed in a detached document? |
| 17:41 | <yecril71> | I think they should not be, because there is no window. |
| 17:43 | <yecril71> | InnerHTML is a poor way to insert a script, DOM manipulation is better. |
| 17:49 | <yecril71> | A document cannot be backward-compliant. |
| 17:50 | <yecril71> | HTML5 does not deprecate. |
| 17:57 | <yecril71> | Custom scripting engines are out of scope. |
| 17:57 | <yecril71> | CORBA and the like are served by the OBJECT element. |
| 18:07 | <yecril71> | An ECMAScript array object, being an ECMAScript array object, must carry all properties and methods of an ECMAScript array object. |
| 18:09 | <yecril71> | The way to serialise complex data structures is XML and perhaps JSON. |
| 18:09 | <yecril71> | XML has an advantage of being programming-language-neutral. |
| 18:10 | <takkaria> | JSON is pretty programming-language neutral as well, really |
| 18:11 | <yecril71> | Will you be so kind and point be to a JSON reader implemented in Microsoft Visual Basic Scripting Edition? |
| 18:11 | <yecril71> | (I am not saying it cannot be done) |
| 18:16 | <yecril71> | Digit-labelled items are not positional properties. |
| 18:18 | <yecril71> | OK, the lynching started. |
| 18:21 | <yecril71> | Communicating with remote server is done via cross-domain network requests, not by passing window messages. |
| 18:26 | <takkaria> | those four posts are far too long for me to read :) |
| 18:26 | <yecril71> | Do not worry, I shall do it for you :-) |
| 18:27 | <yecril71> | Tunnelling through one dedicated window to save on HTTP connections is utter nonsense. |
| 18:29 | <yecril71> | A Web application should not use more than one window. |
| 18:45 | <yecril71> | defaultscript is called language in HTML. |
| 18:46 | <yecril71> | Voiding an unsupported script would be harmful for other scripts. |
| 18:48 | <yecril71> | Dynamic attributes and declared attributes should obey the same semantic rules. |
| 18:50 | <yecril71> | Stranger scripts should be able to access all event handlers as defined. |
| 18:53 | <yecril71> | Since classic event handler attributes are just strings, no harm is done by providing access to them. |
| 18:58 | <yecril71> | Detection whether a particular scripting language is easy: just include a script in that language setting some global property. |
| 18:59 | <yecril71> | If it is not set, other scripts can infer that it is not supported. |
| 19:00 | <yecril71> | That way, the scripts can negotiate the preference order themselves, and with a better granularity than the host. |
| 19:02 | <Philip`> | What if it's a pure functional language like Haskell and it's not possible to modify any state? |
| 19:02 | <yecril71> | It has nothing to do in HTML then. |
| 19:02 | <yecril71> | Because HTML DOM is about modifying states. |
| 19:03 | <yecril71> | You could have an analogue of document.write in Haskell, but that is all. |
| 19:08 | <yecril71> | Event handlers are synchronous. |
| 19:48 | <Dashiva> | Hixie: Did you see Philip`'s comment about the structured cloning and multiple references to the same object? |
| 19:50 | <Hixie> | no? |
| 19:51 | <Dashiva> | If you have an object a and send [a, a] through the algorithm, you get [a', a"] out |
| 19:52 | <Hixie> | yes, that's intentional |
| 19:54 | <Dashiva> | It seems that since there's no serialization going on, the relationship could be maintained (which would also save work on those cases) |
| 19:55 | <Hixie> | i guess |
| 20:08 | <Philip`> | http://krijnhoetmer.nl/irc-logs/html-wg/20081216#l-134 is the aforementioned comment |
| 20:09 | <Philip`> | But I don't see any real value in trying to 'fix' it - UAs will presumably already have to handle out-of-memory conditions when cloning, and this just provides an easier way to trigger that |
| 20:10 | <Dashiva> | I see value in less work while still maintaining the assocations |
| 20:11 | <Philip`> | Is it a pattern that's likely to be common in practice (and not just in malicious cases)? |
| 20:12 | <Hixie> | oh if we did this OOM protection wouldn't be the reason |
| 20:13 | <Dashiva> | Philip`: That's a hard question to ask about a brand new feature :) |
| 20:13 | <Hixie> | we could trivially make loops and non-loop duplicates get preserved |
| 20:13 | <Hixie> | the question is whether we want to |
| 20:14 | <Hixie> | it makes it much harder for UAs to use serialisation mechanisms to do it |
| 20:14 | <Hixie> | e.g. JSON |
| 20:14 | <Hixie> | since they'd have to extend JSON to not only support things like NaN (not hard to do) but also to support labels and references. |
| 20:14 | <Philip`> | Firefox can already serialise cyclic and duplicative data structures in uneval(), using the #1# property syntax or whatever it is |
| 20:15 | <gavin> | "sharp variables" |
| 20:15 | <Dashiva> | Gavin Sharp variables? :) |
| 20:16 | <gavin> | unfortunately not :) |
| 20:16 | <yecril71> | labels and references can be handled by host application. |
| 20:17 | <Hixie> | i don't understand http://www.w3.org/mid/1229450642.7182.401.camel⊙pl |
| 20:17 | <Philip`> | I nearly poked my eye out on a sharp variable once |
| 20:37 | <gsnedders> | hmm… |
| 20:37 | <gsnedders> | do I go to christmas dance or not? |
| 20:46 | <gsnedders> | I've been getting more spam in my moderation queue on my blog. Seems spammers are getting less dumb. |
| 20:53 | <hober> | that reminds me, I've been meaning to ask DanC about the origins of his [[...]] quoting style. |
| 21:00 | jwalden | doesn't like sharp variables |
| 21:00 | <jwalden> | !summon abarth |
| 21:02 | <Hixie> | sicking: how do you feel about preserving cycles? |
| 21:28 | <jwalden> | when did we decide just using JSON to convert to and from strings passed through these APIs wasn't good enough? I'd thought that was what the plan was going to be |
| 21:29 | <Hixie> | roughly when we looked at JSON |
| 21:29 | <jwalden> | when was this? some thread in whatwg@ I missed? |
| 21:29 | jwalden | is about six months out of the loop, mind |
| 21:30 | <Hixie> | it was discussed last night on IRC, primarily |
| 21:30 | <jwalden> | oh, just then? |
| 21:30 | <Hixie> | (it can't preserve things like undefined, NaN, Infinity, it screws up arrays, etc) |
| 21:30 | <Hixie> | (it stringifies host objects, which seems dangerous) |
| 21:30 | <jwalden> | holey arrays, not especially common I suspect |
| 21:30 | <jwalden> | host objects are an author error, no? |
| 21:30 | <Hixie> | well the point is why would we _want_ to break these things if we didn't have to |
| 21:31 | <Hixie> | i mean, the api here isn't JSON, the JSON would be just an implementation detail |
| 21:31 | <jwalden> | keep things simple to understand |
| 21:31 | <Hixie> | might as well use XML or something else |
| 21:31 | <Hixie> | simple for whom? |
| 21:31 | <jwalden> | authors |
| 21:31 | <jwalden> | you use JSON to push it through, you use JSON to get it out |
| 21:31 | <jwalden> | and I think authors are familiar with JSON nowadays |
| 21:31 | <Hixie> | oh you mean just not supporting it natively? |
| 21:32 | <Hixie> | and only doing strings in the API? |
| 21:32 | <jwalden> | basically |
| 21:32 | <Hixie> | oh |
| 21:32 | <Hixie> | sorry, my bad |
| 21:32 | <Hixie> | different discussion |
| 21:32 | <Hixie> | i added structured data passing because mozilla implemented it |
| 21:32 | <jwalden> | we did? another thing I'm six months behind on, I guess |
| 21:33 | <Hixie> | heh |
| 21:33 | <Hixie> | i was trying to delay it as much as possible, so that implementations would focus on what was in the spec, but no point not speccing it if implementations are doing it anyway |
| 21:33 | <Hixie> | heycam: yt? |
| 21:33 | <jwalden> | sicking: pass me a bug number when you get back? |
| 21:34 | <jwalden> | that changes things somewhat |
| 21:37 | <Hixie> | gsnedders: ou have no idea how much i want support for cross-spec xrefs :-) |
| 21:37 | <Hixie> | maybe i should just code it up myself |
| 21:37 | <gsnedders> | Hixie: :) |
| 21:37 | <Hixie> | i wonder how hard it is to write anolis plugins |
| 21:37 | <gsnedders> | Hixie: The whole design of anolis is based around a single doc, |
| 21:40 | <Hixie> | gsnedders: well this would just be a fallback for things that couldn't be xreffed already -- so it would just need a separate bit before to set up fallback references in a separate list |
| 21:41 | <Hixie> | not sure exactly how it would work |
| 21:41 | <gsnedders> | :) |
| 21:47 | <Philip`> | Does it need to be automatic crossreferencing, rather than something explicit like <a href="workers#some-id-value">? |
| 21:49 | <gsnedders> | Hixie: How urgently do you need xdoc xref? |
| 21:49 | <Hixie> | i don't really "need" it, but it would make my life simpler instantly as soon as i could use it |
| 21:49 | <Hixie> | mostly right now i'd use it for web workers -> html5, and for html5 -> webidl |
| 21:50 | <Hixie> | please don't put it ahead of your schoolwork or anything :-) |
| 21:50 | gsnedders | has the issue of having an English dissertation and computing project to do by the 8th of Jan |
| 21:50 | <gsnedders> | I can't really put much ahead of that :) |
| 21:50 | <gsnedders> | Apart from procrastination, obviously :) |
| 21:51 | <Hixie> | well feel free to use this as procastrination :-) |
| 21:51 | <gsnedders> | I need to ship 1.0 first |
| 21:51 | <gsnedders> | Though I don't foresee anything changing |
| 21:51 | <gsnedders> | Apart from making it possible to install with easy_install |
| 21:52 | <gsnedders> | (i.e., easy_install anolis would install anolis and all dependancies) |
| 21:52 | <sicking> | Hixie, preserving cycles? |
| 21:52 | <sicking> | jwalden, bug# for what? |
| 21:53 | <jwalden> | sicking: this structured-data passing mechanism Hixie says we implemented |
| 21:53 | <sicking> | jwalden, ah |
| 21:53 | <gsnedders> | For either 1.1 or 2.0 (if you nag my enough into doing xdoc xref soon) I want to re-evaluate depending on html5lib at all |
| 21:53 | <Hixie> | sicking: in postMessage(), what do you think of preserving [a, a] as an array referencing the saem object twice? (also lets us preserve cycles) |
| 21:53 | <Hixie> | gsnedders: ah |
| 21:54 | <Hixie> | gsnedders: well html5lib will get faster in time, i expect (and hope!) |
| 21:54 | <sicking> | Hixie, i'm not really the person to ask. I think we need to solve the to JSON-or-not-to-JSON question first |
| 21:54 | <gsnedders> | Hixie: Yeah, but if you're using the libxml HTML parser, should I really require html5lib to be installed? |
| 21:54 | <Hixie> | sicking: do you know who is? |
| 21:55 | <Philip`> | I hope html5lib won't get too much faster, because it should remain pure Python (since there are situations where you can't use C modules) |
| 21:55 | <sicking> | Hixie, brendan, sayrer, and/or maciej |
| 21:55 | <Hixie> | gsnedders: given that the people actually hosting it are also the html5lib implementors, it seems not a problem to rely on it :-) |
| 21:55 | <gsnedders> | Hixie: But for those of us who want our own local copies? :) |
| 21:55 | <Hixie> | Philip`: i hope html5lib will also have a C module implementation if that is the only way to make it faster |
| 21:55 | <Philip`> | html5lib isn't exactly hard to install |
| 21:55 | <sicking> | Hixie, IMHO it comes down to: is JSON a native data-interchange-format for javascript? Or is it just specific to the JSON object |
| 21:56 | <Hixie> | sicking: k, thanks |
| 21:57 | <gsnedders> | Hixie: I think we've more or less reached the limit of pure Python without massively redesigning the codebase and making it less powerful :) |
| 21:58 | <Philip`> | Is there any reason why html5lib should be slower than sgmllib? |
| 21:58 | <gsnedders> | Because HTML5 is simpler than SGML? |
| 21:58 | <Philip`> | (I'm not actually sure if it is slower or not - maybe I should test that...) |
| 21:58 | <gsnedders> | Or more likely sgmllib is an incomplete implementation of SGML. |
| 21:59 | <Philip`> | Most of the cost is just reading characters while tokenising, which should be pretty much the same in html5lib and sgmllib |
| 22:00 | <Hixie> | any software being slower than instantaneous is a bug almost by definition, not counting time spent waiting for other software, hardware, or user interaction. |
| 22:00 | gsnedders | blames jgraham for getting him to keep trying to write it in Python and not learning C++ and trying to write Anolis in that |
| 22:01 | <Philip`> | gsnedders: But you wrote it in Python and you have something that works, whereas if you wrote it while learning C++ then you probably wouldn't :-) |
| 22:01 | <gsnedders> | :) |
| 22:01 | <gsnedders> | Philip`: If I tried to write it while learning C++ I'd probably give up trying to learn C++ |
| 22:01 | <gsnedders> | Philip`: And thus would have nothing |
| 22:01 | <Philip`> | and even if it did work in C++, you'd think it was ugly since it was the first program you ever wrote in that language and so you'd want to rewrite it immediately |
| 22:02 | <gsnedders> | Philip`: It's the first program I wrote in Python! |
| 22:02 | <Philip`> | Oh |
| 22:02 | <Philip`> | But Python is much more forgiving of first-time programmers than C++ :-) |
| 22:02 | <gsnedders> | :) |
| 22:09 | <yecril71> | Except that it requires an indentation-aware editor and a wide screen. |
| 22:09 | <yecril71> | So it has some serious hardware/software requirements :=) |
| 22:10 | <yecril71> | I was on the verge on writing an indenting preprocessor when I wrote in Python. |
| 22:10 | <yecril71> | verge of |
| 22:11 | <jruderman> | writing C++ pretty much requires an indentation-aware editor ... even more than python, i'd argue, since you end up writing 3 times as many lines of code |
| 22:12 | <yecril71> | I do not use indentation when I code over Telnet. |
| 22:12 | <yecril71> | In C++, that is. |
| 22:13 | <yecril71> | 80 columns are hardly enough to hold an expression, I cannot afford any indentation. |
| 22:18 | <Philip`> | sgmllib tokenises the HTML5 spec in 2.7 seconds, html5lib takes 10.5 seconds |
| 22:18 | <Philip`> | (Both give the same output when I use them to count the number of start tags) |
| 22:18 | <Philip`> | (The input is a string in both cases) |
| 22:18 | <Hixie> | i wonder what the difference is |
| 22:18 | <Hixie> | and don't say 7.8 |
| 22:19 | <Philip`> | sgmllib is pure Python, as far as I can see |
| 22:19 | <Dashiva> | Maybe sgmllib uses byte strings? |
| 22:23 | <Philip`> | html5lib does almost four times as many function calls as sgmllib |
| 22:23 | <Philip`> | Are function calls really expensive in Python? |
| 22:24 | <Philip`> | where "really expensive" means "about a thousand clock cycles" |
| 22:24 | <Philip`> | I can imagine that they possibly are |
| 22:29 | <gsnedders> | Philip`: They are fairly expensive |
| 22:29 | <gsnedders> | Hixie: 7.8 seconds. |
| 22:29 | <gsnedders> | :) |
| 22:30 | <gsnedders> | Philip`: I concluded on my laptop, IIRC, that a function call cost 1µs |
| 22:31 | <karlcow> | http://wiki.python.org/moin/PythonSpeed/PerformanceTips |
| 22:31 | <Philip`> | gsnedders: I conclude that your laptop is a bit slow, since mine does about 2.5e6 function calls (plus some non-trivial work doing all the tokenisation) in about 1.6 seconds |
| 22:32 | <gsnedders> | Philip`: This was an IIRC case |
| 22:32 | <gsnedders> | karlcow: I think we've got beyond that document, really :) |
| 22:37 | karlcow | should take a look again at html5lib |
| 22:37 | <karlcow> | it has been a super long time I have done so |
| 22:37 | <Philip`> | Hmm |
| 22:38 | <Philip`> | I can save about 10% just by replacing "class X(object):" with "class X:", for X in ('HTMLInputStream', 'HTMLTokenizer') |
| 22:38 | <gsnedders> | New style classes are slow? |
| 22:40 | <Philip`> | Apparently so |
| 22:40 | <Philip`> | (at least in Python 2.5 on x86) |
| 22:41 | <Philip`> | (on classes that aren't doing any inheritance) |
| 22:58 | Hixie | comes across webkit's LayoutTests/fast/forms/old-names.html |
| 22:58 | <Hixie> | you have GOT to be kidding me |
| 22:58 | <Hixie> | jesus |
| 23:00 | <Hixie> | http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/old-names.html |
| 23:01 | <gavin> | ugh |
| 23:01 | <Lachy> | what's so bad about it? |
| 23:02 | <Hixie> | well the most crazy part is the "third" part |
| 23:02 | <gavin> | emulating a Firefox bug because one site depended on it is pretty gross |
| 23:02 | <Hixie> | but the whole thing is insane |
| 23:02 | <Hixie> | it's not just emulating a Firefox bug |
| 23:02 | <Hixie> | Firefox is emulating an IE bug |
| 23:03 | <Hixie> | IE doesn't update the array at all when names change |
| 23:03 | <Hixie> | which is clearly wrong, but sites rely on it it seems |
| 23:03 | <gavin> | oh |
| 23:03 | <Lachy> | oh crap |
| 23:03 | <gavin> | so Firefox explicitly chose that behavior |
| 23:04 | <gavin> | presumably |
| 23:04 | <gavin> | to both be compatible, and try to Do The Right Thing |
| 23:04 | <Hixie> | yeah |
| 23:04 | <Hixie> | i'm most amused and horrified that form.x and form.elements.x are different |
| 23:04 | <gavin> | I feel better about it now |
| 23:05 | <hallvors> | I know that issue. We had to do it too. |
| 23:05 | Hixie | wonders how to spec it |
| 23:05 | <Lachy> | Opera fails this test, but I don't see why based on the result: FAIL form.third should be [object HTMLInputElement]. Was [object HTMLInputElement]. |
| 23:05 | <Hixie> | opera probably remembers the last settign isntead of the first |
| 23:06 | <Hixie> | which does firefox do? |
| 23:06 | <Lachy> | possibly, but I mean it's telling me the expected result is the same as the actual result, but still fails |
| 23:06 | <hallvors> | (some years ago some software vendor who apparently sold web backends to banks relied on this IE bug. Several banks had login forms doing excactly nothing if you behaved per the spec) |
| 23:06 | <Lachy> | Firefox 3 passes everything |
| 23:07 | <Hixie> | the expected result is 'a' and you're getting (i guess) 'b'. But they are both HTMLInputElement objects, so the output isn't very helpful |
| 23:07 | <Hixie> | hallvors: good times |
| 23:07 | <Lachy> | webkit does too |
| 23:07 | <Hixie> | makes sense that webkit passes it :-) |
| 23:07 | Lachy | fires up VMWare to test IE8 |
| 23:08 | <Hixie> | i guess i'll have a list of objects to remember |
| 23:08 | <Hixie> | this is going to be Fun! |
| 23:08 | hallvors | crosses fingers and toes that no page depends on the stuff Firefox does |
| 23:09 | <Hixie> | ok i'll do this after heycam reviews my last checkin |
| 23:09 | <Lachy> | I wonder why VMWare is taking an extra long time to start up this time? |
| 23:14 | <Lachy> | my iMac desperately needs more RAM |
| 23:14 | <Philip`> | Lachy: Do you have IE8b2, or the newer release? |
| 23:15 | <Lachy> | I installed the newest release a couple of days ago |
| 23:15 | <Philip`> | The non-public newest one? |
| 23:16 | <Lachy> | yes |
| 23:16 | <Philip`> | Okay |
| 23:16 | <Philip`> | That version says "FAIL successfullyParsed should be true. Threw exception [object Error] / TEST COMPLETE" |
| 23:17 | <Lachy> | it's version 8.0.6001.18343, Release Candidate 1 |
| 23:17 | <Philip`> | There's a script error "Object doesn't support this property or method" on "line 14, char 5" |
| 23:20 | <Lachy> | That doesn't make any sense. Line 14 is: form = document.getElementById('form'); |
| 23:22 | <Lachy> | oh, IE's developer tools are broken. It's says the error is line 14 of the script, but points to line 14 of the file, without taking into account the lines before the script. |
| 23:23 | <Philip`> | It is actually the getElementById line that's failing, as far as I can tell |
| 23:23 | <Philip`> | (if I make a local copy and then insert alerts everywhere) |
| 23:23 | <ghostbyte> | Anyone know where the PDF version for WCAG2 guides are? They talk about them but don't link to it |
| 23:24 | <Philip`> | Actually, no, it's the "form = ..." that's failing |
| 23:24 | <Philip`> | "var form" works much better |
| 23:24 | <Lachy> | ah |
| 23:25 | <Dashiva> | Is there an id="form" perhaps? |
| 23:25 | <Lachy> | wow, IE8 fails most of those tests after fixing that line |
| 23:25 | <Lachy> | Dashiva, yes |
| 23:26 | <Philip`> | http://paste.lisp.org/display/72262 |
| 23:59 | Philip` | commits trivial fixes to make html5lib ~20% faster |