| 01:47 | <Hixie> | document.all seems to be a pretty normal collection, with all the elements in it; calling it is the same as dereferencing it |
| 01:47 | <Hixie> | and in IE all collections seem to have .tags() method that returns a filtered collection with just the members of that tag name |
| 01:48 | <Hixie> | after lowercasing |
| 01:52 | <heycam> | Hixie, here now |
| 01:53 | <Hixie> | heycam: any chance we can get magic in WebIDL that defines document.all's wacko behavior? :-) |
| 01:53 | <Hixie> | i may have asked this before |
| 01:53 | <Hixie> | interesting, IE8's namedItem() method broke compatibility with earlier versions |
| 01:54 | <Hixie> | i wonder if they did that because of trying to be compatible with the specs or something |
| 01:54 | <heycam> | what's the wacko behaviour? |
| 01:57 | <Hixie> | if (document.all) { throw 0; } doesn't throw |
| 01:57 | <gavin_> | in non-IE browsers only, right? |
| 01:58 | <Hixie> | typeof document.all === undefined |
| 01:58 | <gavin_> | Mozilla had to make it "undetectable" when we implemented it, because sites used that to check for IE |
| 01:58 | <Hixie> | document.all.toString() is something like "[object HTMLCollection]" |
| 01:58 | <Hixie> | (will probably be [object HTMLAllCollection] in HTML5) |
| 01:59 | <Hixie> | document.all instanceof HTMLCollection === false |
| 01:59 | <heycam> | such wackoness seems like it shouldn't be in webidl |
| 01:59 | <Hixie> | document.all.length == document.getElementsByTagName('*').length |
| 02:00 | <Hixie> | the object returned by document.all is callable and needs WebIDL's property indexing stuff |
| 02:00 | <heycam> | ok so that bit should be supported already |
| 02:00 | <Hixie> | the main reason i was hoping you'd be ok with adding that to webidl is i have no idea what i should be saying in html5 :-) |
| 02:00 | <heycam> | aha :) |
| 02:01 | <heycam> | there's no way in ecma-262 to legally have an object that is "undetectable" like that |
| 02:02 | <Hixie> | yeah well we already violate e262 for one thing, what's one more! |
| 02:02 | <heycam> | i don't though, my hands are clean thus far =) |
| 02:03 | <Hixie> | hah |
| 02:04 | <heycam> | do people really do if (document.all instanceof HTMLCollection) to test for IE? |
| 02:04 | <Hixie> | no |
| 02:05 | <Hixie> | they probably do do typeof |
| 02:05 | <Hixie> | but most just do if (document.all) |
| 02:05 | <Hixie> | so that would probably be enough |
| 02:05 | <heycam> | so why the need for that wacko requirement? |
| 02:06 | <Hixie> | trying to be as close as possible to existing implementations |
| 02:07 | <heycam> | just wonder if it's really necessary |
| 02:08 | <heycam> | anyway |
| 02:08 | <heycam> | i'm not sure what the best way is to describe the "undetectable" requirements is |
| 02:09 | <heycam> | requirements on how certain productions from the ecmascript grammar are evaluated maybe? |
| 02:10 | heycam | goes out for some shopping |
| 02:59 | <Hixie> | heycam: i have bad news. It looks like document.all is not the only feature that uses this in webkit -- style.filter does too :-) |
| 03:00 | <jwalden> | yeah, it's something ghastly where it converts to a boolean false |
| 03:00 | <jwalden> | dunno why it's necessary, gecko doesn't have the same to not trigger MS filter-property detection tests |
| 03:00 | <jwalden> | or at least it doesn't as far as I know |
| 03:00 | <Hixie> | gecko doesn't have style.filter at all does it? |
| 03:01 | <jwalden> | via SVG maybe? |
| 03:01 | jwalden | isn't sure |
| 03:01 | <Hixie> | document.body.filter is undefined in gecko |
| 03:01 | <Hixie> | er |
| 03:01 | <Hixie> | document.body.style.filter is undefined in gecko |
| 03:01 | <jwalden> | k |
| 04:07 | <Hixie> | i really think we should number the design principles instead of naming them |
| 04:07 | <Hixie> | people are only reading their names |
| 07:03 | <ezyang> | Anyone around to answer a question about fragment processing? |
| 07:04 | <Hixie> | fragment processing? |
| 07:04 | <ezyang> | Parsing html fragments |
| 07:04 | <ezyang> | Although... it looks like I just fixed it :-) |
| 07:05 | <ezyang> | Perhaps "and set node to the context element." is a little ambiguous (step 3 of reset insertion mode algorithm) |
| 07:08 | Hixie | looks |
| 07:08 | <ezyang> | The algorithm works if I replace the actual entry in the stack of open elements |
| 07:09 | <Hixie> | i don't understand why it's ambiguous or why you would mutate the stack |
| 07:10 | <ezyang> | Ah. Then I've implemented it wrong |
| 07:10 | <Hixie> | how do you interpret it? |
| 07:11 | <ezyang> | Oh, I see where I've gone wrong. I'm assuming things actually get inserted into the context element. |
| 07:11 | <ezyang> | User error! Boink |
| 07:11 | <Hixie> | the reset the insertion mode thing does nothing but reset the insertion mode :-) |
| 07:12 | <ezyang> | Yep |
| 07:14 | <ezyang> | I always forget if the "last" node on a stack is the most recently added one or the oldest one |
| 07:15 | <hobo> | you'd think it would be the most recent one |
| 07:15 | <hobo> | as you add them it increases the stack so the last one would be the most recently added |
| 07:16 | <ezyang> | For step three, "If node is the first node in the stack of open elements, then set last to true and set node to the context element.", do I set node to the context element if there is no context element? |
| 07:16 | <Hixie> | yeah i apologise for the mess around the stack |
| 07:16 | <Hixie> | ezyang: how can there be no context element? |
| 07:17 | <ezyang> | Umm, when I'm not parsing a fragment? |
| 07:18 | <Hixie> | when you're not passing a fragment, /node/ will never be the first node in the stack |
| 07:18 | <ezyang> | OK. |
| 07:18 | <Hixie> | so you can assert(context is not null) in that condition, if you like -- you should never hit it unless you or the spec has a bug |
| 07:19 | <ezyang> | Looking at "reset insertion mode" more closely, I can see that would be the case. |
| 07:23 | <ezyang> | FIFTEEN! |
| 07:23 | <ezyang> | (failures) |
| 07:24 | <Hixie> | heycam: yt? |
| 07:31 | <ezyang> | Ugh. Now I need to incorporate a list of doctypes in the library |
| 08:46 | <ezyang> | Are there any tests in the test-suite for quirks mode specific behavior? |
| 08:49 | <ezyang> | Also, I'm pretty sure this is a bogus test: <!doctype html></html> <head> |
| 08:50 | <ezyang> | since </html> puts the mode to "After After Body", then the whitespace gets handled as if it was "In Body" and should get placed in <body> |
| 08:53 | <Hixie> | </html> doesn't do anything before head iirc |
| 08:55 | <ezyang> | "before head" causes </html> to be reprocessed as if an implicit <head> tag was seen |
| 08:55 | <ezyang> | Which further reprocesses as if an end </head> was seen |
| 08:55 | <ezyang> | and so forth |
| 08:56 | <Hixie> | really? i thought we changed that |
| 08:56 | <ezyang> | Oh I see, we're in "before html", not "before head" |
| 08:56 | <Hixie> | huh go figure, i am wrong |
| 08:56 | <Hixie> | oh well |
| 08:57 | <ezyang> | Ehh, the behavior is the same |
| 08:57 | <ezyang> | Yeah. |
| 08:57 | <ezyang> | So what's supposed to happen? |
| 08:57 | <Hixie> | what the spec says is what the rule is at the moment |
| 08:57 | <Hixie> | no idea if it'll change |
| 08:58 | <ezyang> | Ok. I guess I should hg blame the relevant test-case and yell at hsivonen if it's one of his nudge nudge things (more realistically, stick the test-case in test99) |
| 09:00 | <ezyang> | Ick. hg blame doesn't show deletions. So I *can't* find out |
| 09:01 | <ezyang> | Someone must have changed it to not result in whitespace at some point, though, so it will get punted to 99 |
| 09:05 | <ezyang> | Wow. Most of these are bogus |
| 09:06 | <ezyang> | Ok. The spec needs to be changed to handle <html></html><!-- comment --> |
| 09:10 | <Hixie> | send mail or file a bug if you need changes |
| 09:11 | <Hixie> | (i can't track irc comments so otherwise i'll just forget) |
| 09:12 | <ezyang> | Ok. |
| 09:13 | <ezyang> | It's also kind of debatable whether or not these changes are correct or not |
| 09:18 | <Hixie> | it basically boils down to "are there pages that break if we do it the other way" |
| 09:18 | <ezyang> | Since <title> isn't going into <head>, probably. |
| 09:29 | <ezyang> | For <a><div><p></a>, is the div supposed to be a child of <a>? |
| 09:31 | <ezyang> | Oh, it's a foster parented case. |
| 09:47 | <heycam> | Hixie, you were after me before? |
| 10:08 | <ezyang> | PHP implementation of html5lib has ~100% coverage (there is one error where we can't actually express a doctype with no qualified name with libxml, but whatever) |
| 10:09 | <ezyang> | Time to sleep |
| 12:06 | <annevk42> | heycam, style.filter is the same as document.all due to the SVG WG not renaming it to avoid conflicts with IE |
| 12:13 | <othermaciej> | well, WebKit does style.filter that way |
| 12:13 | <othermaciej> | though it's even weirder, since the return is normally a string |
| 12:14 | <othermaciej> | we have to make it a special string-like thing that masquerades as undefined |
| 12:14 | <othermaciej> | dunno what other browsers do |
| 12:27 | <annevk42> | I think we do something else but it is causing issues |
| 12:41 | Philip` | is saved by semicolon insertion |
| 12:42 | <Philip`> | For some inexplicable reason I was accidentally printing a date in the middle of a <script> generated by some code, so there was a spurious line saying "2009-05-31" |
| 12:43 | <Philip`> | and it must have been interpreted as a statement computing 1973 with an implicit semicolon at the end, so it didn't cause a syntax error |
| 12:43 | <Philip`> | and it's been like that for about six months |
| 13:50 | <gsnedders> | So, hmm… |
| 13:51 | gsnedders | realizes what he was going to ask |
| 13:53 | <thomaslee> | hi all -- am working with the canvas element in the firefox 3.5 beta -- is this an appropriate place to ask questions about the behaviour of the API? |
| 14:03 | <gsnedders> | thomaslee: Yes. |
| 14:03 | <thomaslee> | cool |
| 14:03 | gsnedders | can't actually answer any questions on the canvas API himself, but can say that this is the right place to ask :P |
| 14:04 | <thomaslee> | haha great :) |
| 14:04 | <thomaslee> | that's fine |
| 14:04 | <thomaslee> | question is: |
| 14:04 | <thomaslee> | ctx.moveTo(canvas.width, 0); ctx.lineTo(canvas.width, canvas.height); |
| 14:06 | <thomaslee> | once you ctx.stroke(), firefox's implementation of canvas, only draws half of the line -- the other half presumably "off-canvas". |
| 14:06 | <thomaslee> | oops, trigger happy with the commas |
| 14:06 | gsnedders | grumbles about ezyang having made php html5lib really slow |
| 14:06 | <thomaslee> | anyway, the question is -- is this expected behaviour? |
| 14:07 | <annevk42> | I think so |
| 14:07 | <thomaslee> | the other thing that's confusing me is for a lineWidth = 1.0, I'm seeing what looks like two pixel lines -- although I'm assuming this has something to do with coordinate space and firefox's internal representation of the canvas. |
| 14:08 | <Philip`> | thomaslee: Integer coordinates refer to the positions *between* pixels |
| 14:08 | <thomaslee> | annevk42: so assuming I want a line down the right hand side, I should be drawing this line for x=canvas.width-1 ? |
| 14:08 | <gsnedders> | ezyang: You've made it go from taking < 6s to tokenize the spec to taking > 131s |
| 14:09 | <thomaslee> | Philip`: come again? :) |
| 14:09 | <Philip`> | thomaslee: so if you stroke a line with integer coordinates, it goes between two columns of pixels and ends up shading pixels in both columns |
| 14:09 | <gsnedders> | Oh, wait, I ran that with XDebug on. |
| 14:09 | <thomaslee> | Philip`: oh okay, wow. why's that? |
| 14:09 | <Philip`> | thomaslee: If you want to draw a line through just a single column of pixels, you have to shift the coordinates by 0.5 |
| 14:10 | <Philip`> | thomaslee: i.e. ctx.moveTo(canvas.width-0.5, 0); ctx.lineTo(canvas.width-0.5, canvas.height) |
| 14:10 | <annevk42> | unless the line has a width of 2n, presumably? |
| 14:10 | <gsnedders> | ezyang: Let me try that again: you've made it go from < 6s to > 11s |
| 14:10 | <Philip`> | annevk42: If it has width 2n and you're trying to draw a single column of pixels, that's never going to work :-) |
| 14:11 | <annevk42> | meh |
| 14:12 | <thomaslee> | Philip`: right, so that would explain why I'm still seeing two pixel lines when reducing line width. But why on earth do integer coordinates refer to the space in between pixels? |
| 14:12 | <Philip`> | thomaslee: It's that way so that fills work like you would expect (with sharp edges), but it has the consequence that strokes don't quite work like you expect (so you have to shift them by 0.5 to the centers of pixels) |
| 14:13 | <Philip`> | thomaslee: e.g. fillRect(10, 10, 1, 1) fills between the corners of pixels, instead of filling a rectangle between the centers of four pixels |
| 14:13 | <Philip`> | (...assuming you imagine pixels as being squares) |
| 14:14 | <thomaslee> | Philip`: okay, I think I understand. Going to have to remember that one! |
| 14:16 | <Philip`> | thomaslee: It's not the most intuitive thing in the world :-) |
| 14:16 | <Philip`> | but I can't imagine any way to make it better without making other things worse |
| 14:16 | <thomaslee> | Philip`: my brain hurts already :) |
| 14:17 | <thomaslee> | fair enough ... I only started messing with canvas yesterday, maybe it'll make sense when I've got a better understanding of it all. |
| 14:17 | <thomaslee> | anyway, thanks very much for your help |
| 14:20 | <heycam> | annevk42, we did consider renaming it recently |
| 14:20 | <heycam> | not sure it's worth it |
| 14:24 | gsnedders | has a brief wish PHP did lazy evaluation |
| 14:25 | <thomaslee> | Philip`: just to be clear, the 0.5 coordinate offset is expected behaviour as per the spec, right? (as in, I'm assuming this isn't a firefox-specific thing) |
| 14:27 | <Philip`> | thomaslee: The spec doesn't really define the mapping between rendering concepts and physical pixels, e.g. it doesn't talk about antialiasing and it doesn't limit implementations to one device pixel per canvas pixel |
| 14:27 | <Philip`> | thomaslee: but all current implementations do the same as Firefox here |
| 14:27 | <Philip`> | thomaslee: so in reality it's the behaviour you should expect |
| 14:31 | <thomaslee> | Philip`: great, thanks. |
| 14:42 | <gsnedders> | Does "reconstruct the active formatting elements" step 7 need to have after it a check that it isn't a marker? |
| 15:17 | <annevk42> | someone is asking me to be added to html5lib team members so he write documentation? no need for vetting right? |
| 15:18 | <gsnedders> | annevk2: I think generally we've had at least one person agreeing to it |
| 15:19 | <annevk42> | so one in total or two? |
| 15:19 | <gsnedders> | One in total. |
| 15:20 | <annevk42> | i guess that'd be me then |
| 15:21 | <annevk42> | for reference: juguang |
| 16:54 | <ezyang> | gsnedders: Test cases pass first. Profiling (and not until that) and then optimization later. |
| 17:08 | <gsnedders> | ezyang: Peh. I was just taking the same solution as Python for this :) |
| 17:08 | <gsnedders> | ezyang: Also: parsing the spec fails. |
| 17:08 | <ezyang> | It... errors? |
| 17:08 | <ezyang> | Wow. |
| 17:09 | <ezyang> | That means our test-coverage is not good enough. |
| 17:09 | <gsnedders> | Fatal error: Call to a member function cloneNode() on a non-object in /Users/gsnedders/Documents/Stuff I'm Working On/html5lib/php/library/HTML5/TreeConstructer.php on line 3037 |
| 17:09 | <gsnedders> | The non-object is int(300) |
| 17:09 | <ezyang> | Huh. That should never happen. |
| 17:09 | <gsnedders> | Well it does. :D |
| 17:10 | <ezyang> | Oh, hey, that's the marker |
| 17:10 | <ezyang> | Ok, so we need to figure out why that algorithm is failing |
| 17:10 | <ezyang> | Do you have a minimal test-case? |
| 17:10 | <gsnedders> | No. |
| 17:10 | <Philip`> | curl http://www.whatwg.org/specs/web-apps/current-work/ -o html5lib/testdata/treeconstruction/tests13.dat |
| 17:10 | <Philip`> | That'll encourage people to optimise their implementations |
| 17:10 | <gsnedders> | ezyang: that. |
| 17:10 | <ezyang> | Heh |
| 17:10 | <ezyang> | Will do. |
| 17:11 | gsnedders | wonders if we should actually do that… |
| 17:11 | <ezyang> | I wish we had better names for our test-cases |
| 17:11 | <gsnedders> | What could be better than a number? :P |
| 17:12 | <Philip`> | I wouldn't object to regrouping and renaming the tests |
| 17:12 | <ezyang> | It's just that, some of the test-cases make assumptions about the naming of the tests |
| 17:13 | <ezyang> | gsnedders: It would be super-uber-awesome if you could find a minimal test-case that tickles the bug. |
| 17:13 | <gsnedders> | No, it would be super-über-awesome. |
| 17:13 | <gsnedders> | uber isn't a word, damnit! |
| 17:17 | <gsnedders> | Last token emitted is with stream at Line 4667, column 5 |
| 17:18 | jgraham | would positivly welcome renaming the tests but doesn't want to actually spend time doing it |
| 17:18 | <gsnedders> | <dfn title="dom-uda-protocol"> |
| 17:23 | <ezyang> | Is it conceptually clean for me to refer to elements in the SVG namespace as 'svg:foo'? I know that prefixes can change, but this is the most convenient representation |
| 17:25 | <gsnedders> | ezyang: <table><tr><td><code>protocol</code> </table> |
| 17:26 | <ezyang> | Awesome |
| 17:29 | <gsnedders> | ezyang: s/protocol// |
| 17:31 | gsnedders | has no idea which test file to put the test in |
| 17:32 | <ezyang> | There's a bunch of foster parenting tests in... erm... 7, I think |
| 17:32 | <ezyang> | (this is why we need better names) |
| 17:33 | <gsnedders> | Yeah, I think 7 is best. |
| 17:34 | gsnedders | runs it against Python to make sure something agrees with the parse tree |
| 17:35 | gsnedders | gets auth failed :\ |
| 17:35 | <gsnedders> | ezyang: Pushed |
| 17:36 | <ezyang> | Awesome |
| 17:37 | <gsnedders> | Have fun with your test suite which throws a fatal error :P |
| 17:37 | <ezyang> | I'm finishing XForeign support first |
| 17:37 | gsnedders | notes the spec is a good test document because it is so huge and does so much |
| 17:38 | Philip` | notes the spec is a bad test document because it's very repetitive and is valid |
| 17:38 | <gsnedders> | ezyang: I take it you're fixing the fact that HTML elements should go into the HTML namespace? |
| 17:38 | <gsnedders> | Philip`: But it does everything that's valid, more or less :P |
| 17:39 | <Philip`> | gsnedders: That seems unlikely :-p |
| 17:39 | <ezyang> | gsnedders: I assume that's the default behavior. I suppose I could fix that trivially though |
| 17:39 | <gsnedders> | Well, it's almost infinitely long :P |
| 17:39 | <Philip`> | gsnedders: Why is that relevant? |
| 17:40 | <Philip`> | gsnedders: I could make a document that's infinitely long and consists entirely of whitespace, and it wouldn't test much behaviour |
| 17:40 | <gsnedders> | Philip`: Indeed |
| 17:40 | <gsnedders> | Philip`: But you'd need an infinitely long document to try every possible valid character stream |
| 17:41 | <Philip`> | gsnedders: An infinitely long document could only test precisely one character stream |
| 17:41 | <gsnedders> | ezyang: It _should_ just mean changing to createElementNS |
| 17:41 | <ezyang> | Right, but because the tokenizer+parser are finite state machines |
| 17:41 | <Philip`> | gsnedders: You'd need infinitely many documents if you want to test infinitely many character streams |
| 17:41 | <ezyang> | We don't need an infinite input stream to test all state combinations |
| 17:42 | <gsnedders> | Philip`: Indeed. |
| 17:42 | <gsnedders> | ezyang: If we implement both as finite state machines exactly to spec, yes :P |
| 17:42 | <Philip`> | gsnedders: But the interesting state in an implementation is finite, so a finite set of finite test cases could test all the interesting cases |
| 17:43 | <jgraham> | Philip`: And your're going to autogenreate tests to cover them all, right? ;) |
| 17:43 | <Philip`> | (By "interesting", I mean that e.g. "<br><br>" might be interesting but "<br><br><br>" is very unlikely to be) |
| 17:43 | <gsnedders> | ezyang: Though it may well make <foo:bar> throw an error |
| 17:43 | gsnedders | sighs |
| 17:43 | <Philip`> | jgraham: That's what I did for the tokeniser :-) |
| 17:43 | <Philip`> | (or at least attempted to) |
| 17:43 | <Philip`> | jgraham: and if I ever got around to finishing my tree-constructor implementation, I suppose I could generate tests for that too |
| 17:43 | <ezyang> | I think it would be possible to programatically generate tree-constructer tests |
| 17:44 | <gsnedders> | Philip`: It's OCaml, right? |
| 17:44 | <jgraham> | Philip`: I know and I know, respectively |
| 17:44 | <Philip`> | gsnedders: Yes |
| 18:08 | <ezyang> | gsnedders: I'm looking at your new SPACECHARACTERS token type, and I'm thinking that's not actually a good idea. |
| 18:08 | <gsnedders> | ezyang: It's what Python does. |
| 18:08 | <ezyang> | It diverges from spec, and anywhere we matched just CHARACTERS, we have to match against both |
| 18:08 | <ezyang> | Sure. |
| 18:09 | <ezyang> | The way I would personally implement it, though, would be as an advisory extra flag placed in the token |
| 18:09 | <gsnedders> | ezyang: Diverging from spec is not a problem. |
| 18:09 | <ezyang> | Adding a new token type is a fairly large divergence |
| 18:12 | <Hixie> | heycam: what i was going to say is that it looks like style.filter also needs this magic (specifically it needs to return a string that masquerades as undefined) |
| 18:12 | <Hixie> | othermaciej: the way i specced document.all was to say it ToBoolean()s to false, but is otherwise a normal HTMLCollection |
| 18:13 | <Hixie> | othermaciej: is that not enough? I couldn't work out how to make it masquerade as 'undefined' for the purposes of the JS spec |
| 18:13 | <jgraham> | Hixie: So instanceof and typeof will work like any other HTMLCollection? |
| 18:13 | jgraham | has no idea if that is a problem |
| 18:14 | <Hixie> | yeh |
| 18:42 | <gsnedders> | Hmm, abath isn't around |
| 18:42 | <gsnedders> | *abarth |
| 18:58 | <Hixie> | christ i wish larry would follow the process the chairs set out and file bugs instead of sending all these e-mails where i have to carefully parse each line to see if there's a change request there |
| 19:13 | <jgraham> | Hixie: What would "masqurading as undefined" imply for document.all? |
| 19:14 | <Hixie> | doing whatever it is webkit or gecko do |
| 19:14 | <Hixie> | but i don't know how to express that in terms of the js spec |
| 19:15 | <Dashiva> | That's a tall order |
| 19:17 | <hsivonen> | Hixie: wouldn't another "willful violation" be less work for Gecko and WebKit developers? |
| 19:18 | <Hixie> | i mean i don't know how to phrase the willful violation |
| 19:18 | <jgraham> | Hixie: so document.all === undefined or more? |
| 19:18 | <Hixie> | more |
| 19:18 | <Hixie> | try it |
| 19:18 | <Hixie> | i can't describe it |
| 19:18 | <jgraham> | I am trying it. I want to know what to try :) |
| 19:18 | <Hixie> | typeof does weird things, instanceof does weird things, it matters if you're in with() or not, all kinds of weird things |
| 19:18 | <Hixie> | depends on webkit vs gecko vs opera, too |
| 19:19 | <jgraham> | typeof and instanceof seem easy to deal with, === seems hard to deal with |
| 19:19 | <Dashiva> | Yeah, I remember the bug discussion in Opera's BTS |
| 19:20 | <jgraham> | Breaking document.all in 'with' seems like it shouldn't be a big deal |
| 19:21 | <annevk2> | I recall discussions about it requiring fairly low-level changes to the ECMAScript engine |
| 19:22 | <hsivonen> | perhaps ES5 should provide a spec hook for this |
| 19:23 | <annevk2> | I don't think they're too interested in things like that |
| 19:23 | <Dashiva> | Boolean value false, typeof undefined. |
| 19:23 | <annevk2> | http://wiki.whatwg.org/wiki/Web_ECMAScript |
| 19:24 | <Hixie> | jgraham: it's actually harder to break it than not |
| 19:24 | <Hixie> | right now the html5 spec just says it ToBoolean()s to fdalse |
| 19:24 | <Hixie> | false |
| 19:25 | <Hixie> | anyway, i'm outta here |
| 19:25 | <Dashiva> | Should probably mention a typeof override too? |
| 19:27 | <jgraham> | Hixie: I meant that making it work or not in with seems like it shouldn't be too big a deal |
| 19:27 | <jgraham> | But I guess I could be wrong about that |
| 19:27 | jgraham | wishes for the death of "with" |
| 19:29 | <Dashiva> | There's that reshaping the universe to your whims thing again |
| 22:32 | annevk42 | has the feeling Larry and Roy are both making issues appear more easily than they are; maybe even intentionally |
| 22:33 | <annevk42> | e.g. Larry ignores most of the comments against having versioning for character encoding sniffing and tries to convince people to look at the general idea and Roy somehow believes the URL issue is restricted to HTML src/href attributes |
| 22:48 | <annevk42> | takkaria, <canvas> is perfectly safe |
| 22:48 | <annevk42> | takkaria, even some amount of scripting can be safe |
| 22:49 | <annevk42> | just has to be sandboxed |
| 22:50 | <takkaria> | browsers don't currently do any kind of sandboxing though |
| 22:50 | <takkaria> | and until they all do, a preparse and whitelist will be required |
| 22:52 | <annevk42> | still, canvas can be on that whitelist just fine :) |
| 22:52 | <gsnedders> | annevk2: But whitelisting script is a lot harder :) |
| 22:53 | <takkaria> | annevk42: mm, but it's in effect useless unless you happen to be able to be able to whitelist the code that paints on it, which is really what I meant |
| 22:54 | <annevk42> | gsnedders, you wanna sandbox what it executes, not whitelist what it contains, methinks |
| 22:54 | <gsnedders> | annevk42: How do you sandbox in currently shipping browsers, then? |
| 23:17 | <jgraham> | Wow is Laura really azsking for quantitative principles? |
| 23:17 | <jgraham> | That's... crazy |
| 23:19 | <jgraham> | At the very least the demand that the world be black or white seems unreasonable and unrealistic |
| 23:24 | <weinig> | Hixie: I don't see a dataunavailable event being dispatched anywhere, is that from some other spec? |
| 23:42 | <hober> | gave a talk today at our local BarCamp about extensibility & HTML http://edward.oconnor.cx/2009/BarCamp-San-Diego-5/ |
| 23:43 | <hober> | (more-or-less a YAGNI rant about namespaces & distributed extensibility) |