| 00:00 | <jacobolus> | JonathanNeal: I think you found a new full-time gig for the next 6 months! :) |
| 00:00 | <zewt> | another part is probably researching past attempts, reading www-dom, etc. threads on the topic, etc. to see what's got in the way previously |
| 00:00 | <Philip`> | It's probably quicker to work on touch APIs and wait for keyboards to become obsolete and die out |
| 00:01 | <Hixie> | so i'd say probably about 2000 hours total, maybe, 3000 hours, but spread unevenly over half a decade |
| 00:01 | <zewt> | (remind me to not say "etc." twice in the same sentence) |
| 00:01 | <Philip`> | (Also, speech- and mind-recognition APIs) |
| 00:01 | <Hixie> | that includes ramp-up time though |
| 00:01 | <JonathanNeal> | Philip`: because we'll be creating virtual keyboards on their touch devices and laptops where we can define the degree of textile feedback> |
| 00:02 | <Hixie> | for someone who's done this a lot before (like several people in this channel), it's probably a lot less on the front-end |
| 00:02 | <JonathanNeal> | Did they press A or did they BILLYMAYS press A. |
| 00:02 | <jacobolus> | JonathanNeal: you might have about as easy a time convincing all those silly european countries to just switch to standard QWERTY |
| 00:03 | <Hixie> | but the people who are experienced already have a lot of maintenance work ongoing, so the cost that's prohibitive is the back-end maintenance cost |
| 00:03 | <jacobolus> | JonathanNeal: while you're at it, spec out the US switch to the metric system |
| 00:03 | <jacobolus> | :) |
| 00:05 | <JonathanNeal> | Done https://petitions.whitehouse.gov/petition/make-metric-system-standard-united-states-instead-imperial-system/FndsKXLh |
| 00:06 | <JonathanNeal> | ARE YOU UNIMPRESSED? AND NOW!? |
| 00:12 | <Hixie> | heycam: yt? |
| 00:12 | <heycam> | Hixie, hi |
| 00:12 | <Hixie> | heycam: any comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=19819 ? |
| 00:13 | heycam | looks |
| 00:13 | <Hixie> | (suitable comment might be "yeah, bz is right, fix yer stuff hixie") |
| 00:13 | <heycam> | Hixie, I think bz is right |
| 00:13 | <Hixie> | k |
| 00:14 | <heycam> | the number of arguments passed is visible to the script |
| 00:14 | <Hixie> | so i just stick "optional" before the second argument and move on? |
| 00:14 | <heycam> | and the rules for how IDL values get converted when invoking a callback will pass the 4 required arguments |
| 00:14 | <heycam> | yep! |
| 00:14 | <heycam> | oh |
| 00:14 | <heycam> | hang on |
| 00:14 | Hixie | hangs on |
| 00:14 | <heycam> | you would have to stick optional before each of argument 2, 3 and 4 |
| 00:15 | <Hixie> | okie dokie |
| 00:15 | <heycam> | because of the rule that if one argument is optional then all following must be optional |
| 00:15 | <heycam> | I guess it minorly might suggest that the callback could be invoked with say 3 arguments, not just 1 or 4 |
| 00:15 | <heycam> | but there's no overloading for callbacks like there is for operations, atm |
| 00:16 | <Hixie> | well i don't really care what it's declared as, since prose always invokes it |
| 00:16 | <Hixie> | just want to keep bz and you happy :-) |
| 00:16 | <heycam> | ok |
| 00:16 | <Hixie> | btw there's an example in the spec of an optional argument where the next argument isn't marked optional |
| 00:16 | <heycam> | that'll be invalid idl then |
| 00:16 | <heycam> | afaicr |
| 00:16 | <Hixie> | oh nevermind |
| 00:16 | <Hixie> | next arg is variadic |
| 00:16 | <heycam> | ah |
| 00:16 | <heycam> | anyway, I'm happy with optional before each of those three trailing arguments |
| 00:16 | <Hixie> | roger |
| 00:41 | GPHemsley | wonders if there should be more oversight on the meta extensions |
| 05:53 | <MikeSmith> | Hixie: here now |
| 05:55 | <Hixie> | i was thinking about using the target milestone field in bugzilla to help sort things |
| 05:55 | <Hixie> | is that something you can help with? |
| 05:55 | <MikeSmith> | yeah sure |
| 05:56 | <MikeSmith> | we need to add some enumerated values there? |
| 05:56 | <Hixie> | yeah |
| 05:57 | <Hixie> | i was thinking, in the whatwg product, "2013 Q1", "2013 Q2", "2013 Q3", "2013 Q4", "2014 Q1", and so on, as high as you can be bothered to go, and then also something like "Pending Implementation Interest" |
| 06:02 | <MikeSmith> | ok lemme give it a try now |
| 06:17 | <MikeSmith> | damn they make this complicated |
| 06:18 | <MikeSmith> | bugzilla config is so unintuitive |
| 06:20 | <MikeSmith> | ...and they've arbitrarily chosen to limit the field 20 to characters |
| 06:20 | <Hixie> | weird |
| 06:21 | <Hixie> | "Needs Impl Interest" |
| 06:21 | <MikeSmith> | thanks |
| 06:32 | <MikeSmith> | Hixie: so how far out should we go? 2016? |
| 06:32 | <MikeSmith> | 2022? |
| 06:32 | <Hixie> | however far we go, we'll go further once we get there, so it's up to you :-) |
| 07:14 | <jgraham> | Hixie: Hmm, I have paged all of the 17155 stuff out. I can look for TCs I wrote though |
| 08:17 | <MikeSmith> | Glen Adams really seems to try hard to find novel ways to geet even more people to lose resect for him |
| 08:17 | <MikeSmith> | what few there may be left |
| 08:25 | <jgraham> | I propose starting public-html-religion to keep thological discussions off the technical list and the <del>political</del>admin list |
| 08:25 | <jgraham> | *theological |
| 08:28 | <jgraham> | Then I will finally have a forum to adress the important question of whether the many-into-one behaviour of the <html> element is a product of western monotheistic beliefs and therefore inappropriate for a global markup standard |
| 08:38 | <MikeSmith> | I don't see quoting something from a book in your sig as being necessary a religious thing |
| 08:38 | <MikeSmith> | it is see more so in this case I gues |
| 08:39 | <MikeSmith> | but there are a lot of shades of things that could be taken as religious |
| 08:43 | <MikeSmith> | anyway if I were going to take offense at what people put into their sigs I think the legal disclaimers that some people attach to every single message they send to a list is a lot more worthy of offense |
| 08:43 | <MikeSmith> | because those serve absolutely no purpose |
| 08:45 | <jgraham> | The problem is that it is a topic where there is a line ranging from "inoffensive" to "illegal" and everyone wants to weigh in with their exact definition of where "inappropriate" is on that line. |
| 08:52 | <jgraham> | MikeSmith: Are you allowed to ask people to take that discussion off list and to the archives, or do we have to wait for the 300+ email flame war and/or the chairs to do it? |
| 08:52 | <jgraham> | s/the archives/www-archive/ |
| 08:53 | <MikeSmith> | yeah I will ask that the discussion be moved to www-archive |
| 08:54 | <jgraham> | (I suggest pre-empting the possible response that this is an admin matter and therefore on topic for an admin list) |
| 08:59 | <MikeSmith> | jgraham: oh, already sent it before I got back to see that suggestion |
| 10:22 | <MikeSmith> | Hixie: btw we now have dates in the Target Milestone field for use with all WHATWG components |
| 10:23 | <MikeSmith> | https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG |
| 15:15 | <Yaffle> | Hello!!! |
| 15:17 | <Yaffle> | @Hixie, can you please look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=20768 ? |
| 15:21 | <jgraham> | Yaffle: That doesn't seem like a good bug report |
| 15:21 | <Yaffle> | @jgraham, why? |
| 15:21 | <jgraham> | Because it doesn't explain a problem with the spec |
| 15:22 | <jgraham> | There might *be* one |
| 15:22 | <jgraham> | But it isn't obvious what it is |
| 15:22 | <jgraham> | For example it isn't clear whether the "problem" is a QoI issue |
| 15:23 | <jgraham> | Well, it's not even that obviosu what the problem is |
| 15:23 | <Yaffle> | spec is correct, but EventSource is not so good |
| 15:23 | <jgraham> | Right |
| 15:23 | <jgraham> | So is spec action needed? |
| 15:24 | <jgraham> | Is it something that can be fixed by browsers changing their implementation? |
| 15:24 | <Yaffle> | yes, i want to see "heartbeat timeout" in the spec |
| 15:24 | <jgraham> | If browsers can change their implementation, will they? If not why not? |
| 15:25 | <jgraham> | If it can be solved with a browser change (which it seems like maybe it can, since you say Chrome isn't affected), why wouldn't they just do that instead of implemented some as-yet unspeced feature |
| 15:26 | <jgraham> | If it *can't* be, you need a clear statement of the problem |
| 15:26 | <Yaffle> | because Chrome uses TCP-level keepalives |
| 15:26 | <jgraham> | A clear statement of why a spec change is needed |
| 15:26 | <jgraham> | And finally a suggestion for the possible form of that change |
| 15:26 | <jgraham> | Right so why can't everyone else do that too? |
| 15:31 | <Yaffle> | they fear |
| 15:32 | <jgraham> | Right, if there are good technical reasons that what Chrome does is bad, that needs to be in the bug |
| 15:32 | <Yaffle> | and the tcp keepalives interval is 45 seconds, which may be too big for some EventSource applications |
| 15:33 | <jgraham> | Right, well this all needs to be explained to make it a good bug report |
| 15:33 | <Yaffle> | this is all needs a discussion |
| 15:34 | <jgraham> | Like "You might think that just doing what Chrome does would solve this without any spec changes but that doesn't really solve the whole problem because (reasons)" |
| 15:36 | <Yaffle> | ok |
| 15:38 | <jgraham> | So the basic structure should be: description of a problem that the current spec doesn't address, reason why any trivial solution is insufficient to addresss the problem, suggestions for possible solutions |
| 15:38 | <jgraham> | The last one is optional |
| 16:06 | <zewt> | oh cool, didn't know img.complete was in ios 6 safari |
| 16:46 | <dglazkov> | good morning, Whatwg! |
| 17:03 | <tantek> | good morning dglazkov! |
| 17:18 | <KyleBarnhart> | Hi. Is there someone of authority how can definitively answer a question regarding the implementation of the WebVTT text track specification? |
| 17:18 | <KyleBarnhart> | Specifically... |
| 17:20 | <KyleBarnhart> | I am part of a team who is trying to implement the standard. Whereas I take the view that the parser section of the specification is to be adhered to when writing an implementation, they take the view that the implementation is should be written to the syntax rules and the parser section can be ignored. |
| 17:21 | <Ms2ger> | The parser section is the only relevant one for an implementation |
| 17:22 | <KyleBarnhart> | It is one. Not a validator. It is parsing the format for the eventual use in Mozilla. |
| 17:22 | <Ms2ger> | Right |
| 17:22 | <Ms2ger> | Then you want to follow the parsing section |
| 17:22 | <Ms2ger> | I understand your first patches are due today? |
| 17:23 | <KyleBarnhart> | I believe. |
| 17:24 | <KyleBarnhart> | I'm not responsible for that. I'm handling testing at the moment. |
| 17:25 | <Ms2ger> | Great, we'll need quite a few of those :) |
| 17:30 | <KyleBarnhart> | Is it okay if the parser (and I mean in the final future version) differs in some significant ways from the specification? Such as when to and not to discard a cue, and accepting input that the specification would not allow. |
| 17:39 | <Ms2ger> | If the code is to end up in Gecko, it had better follow the specification to the letter |
| 17:40 | <Hixie> | KyleBarnhart: what do they think the spec is for, if not following? |
| 17:41 | <MikeSmith> | inspiration |
| 17:41 | <Ms2ger> | Suggestions |
| 17:42 | <Hixie> | MikeSmith: awesome, thanks! One last thing on the milestones, looks like we have to explicitly give the "no milestone" milestone, so all the bugs have ended up in "Needs Impl Interest". Is there any chance you could rename that one to "Unsorted", and then add one to the other end of the list (after the quarterly milestones) called "Needs Impl Interest"? |
| 17:43 | <MikeSmith> | sure |
| 17:43 | <MikeSmith> | gimme a minute |
| 17:43 | <Hixie> | sure, no rush |
| 17:45 | <MikeSmith> | well it's quick to do |
| 17:45 | <MikeSmith> | in fact so quick that's it already done! |
| 17:45 | <MikeSmith> | I have become one with bugzilla |
| 17:45 | <Hixie> | :-D |
| 17:46 | <Hixie> | thanks dude |
| 17:49 | <Hixie> | hsivonen, abarth, jgraham: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924 (same as one I sent yesterday, in case you already looked and don't care) |
| 17:50 | <Ms2ger> | SVG fragment parsing? |
| 17:50 | <Hixie> | yeah |
| 17:51 | <Ms2ger> | Sounds like it would be good to fix, but I'll leave it to hsivonen to tell you how :) |
| 17:52 | <KyleBarnhart> | Thank you very much for your answer. I'm going to go now and discuss this with our team. |
| 17:52 | <Hixie> | KyleBarnhart: please don't hesitate to ask any other questions |
| 17:52 | <KyleBarnhart> | Thank you :) |
| 17:53 | <Velmont> | KyleBarnhart: What's also good to know is that specs are never really set in stone. |
| 17:53 | <Hixie> | MikeSmith: when you have a moment and happen to be at bugzilla's admin page again, if you could add a "Needs Research" between "2022 Q4" and "Needs Impl Interest", that'd be great |
| 17:54 | <Velmont> | KyleBarnhart: It should follow what implementations do as well. So if there's something strange there it might be a bug in the spec. |
| 17:54 | <Hixie> | KyleBarnhart: yeah, what Velmont said. If there's a reason to implement something other than the spec, we should change the spec. |
| 17:54 | <Hixie> | KyleBarnhart: the reason to have a spec is to make sure everyone does the same thing, but so long as they all do the same thing, it doesn't really matter what that thing is exactly |
| 17:54 | <Velmont> | KyleBarnhart: Although there is already implementions of that one, so hopefully there shouldn't be too much :-) |
| 17:58 | <MikeSmith> | Hixie: I have communicated your request to bugzilla |
| 17:58 | <MikeSmith> | Flight looks extremely cool https://github.com/twitter/flight/tree/gh-pages/demo |
| 17:58 | <Hixie> | MikeSmith: you are teh awesomest |
| 17:58 | <MikeSmith> | https://github.com/twitter/flight/blob/master/README.md |
| 18:20 | <hsivonen> | Hixie: ping ack but can't review today |
| 18:21 | <Hixie> | hsivonen: roger |
| 19:18 | <jgraham> | KyleBarnhart: I'm pretty sure Opera have written some WebVTT tests that might help you get started |
| 19:18 | <jgraham> | I'm not sure if they are public yet. zcorpan would know, but he's not around |
| 19:19 | <jgraham> | http://w3c-test.org/html/tests/submission/Opera/media/track/webvtt/ |
| 19:19 | <jgraham> | I love it when a plan comes together |
| 19:20 | <jgraham> | Although I guess it hasn't come together until everyone passes the tests |
| 19:23 | <jgraham> | KyleBarnhart: Also, Ms2ger should be able to help you get those tests running as MochiTests |
| 19:24 | <jgraham> | 'cause y'know until a test is in an automated regression framework it as good as doesn't exist |
| 19:45 | <Ms2ger> | Suppose you have a form element |
| 19:46 | <Ms2ger> | And you do for (var p in form) { w(p); } |
| 19:46 | <Ms2ger> | What do you get logged? |
| 19:46 | <Hixie> | all kinds of random stuff |
| 19:47 | <Ms2ger> | Alright, let's ignore the random stuff, and focus on the stuff in form.elements |
| 19:49 | <Hixie> | everything except image inputs, i think |
| 19:49 | <Hixie> | but i'm saying that from memory |
| 19:49 | <Ms2ger> | Any numbers? |
| 20:04 | <Hixie> | Ms2ger: numbers? |
| 20:04 | <Hixie> | Ms2ger: oh, numbers |
| 20:04 | <Hixie> | Ms2ger: dunno off hand |
| 20:05 | <Hixie> | Ms2ger: i assume this is well-defined, but of course the definition might not match reality |
| 20:06 | <Ms2ger> | Exactly :) |
| 20:12 | <abarth> | Hixie: makes sense |
| 20:12 | <gsnedders> | Ms2ger: 25. |
| 20:14 | <Hixie> | abarth: the parsing thing? |
| 20:14 | <Hixie> | ah, saw your comment. thanks! |
| 21:01 | <Hixie> | Ms2ger: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=17844 |
| 21:01 | <Ms2ger> | I have no idea what those do |
| 21:01 | <Ms2ger> | I was hoping someone who isn't me could do the reverse engineering :) |
| 21:02 | <Hixie> | heh |
| 21:05 | <jgraham> | So whoever won't do reverse engineering for that is a good candidate to be the real Ms2ger? |
| 21:05 | <Ms2ger> | Either that or just lazy |
| 21:06 | <jgraham> | Hmm, that's a problematically large group of people :( |
| 21:08 | <Hixie> | smaug____: you around? |
| 21:08 | <smaug____> | Hixie: pong |
| 21:09 | <Hixie> | smaug____: you asked for [LenientThis] on onmouseenter and onmouseleave in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18836, referencing https://bugzilla.mozilla.org/show_bug.cgi?id=691059 |
| 21:09 | <Hixie> | smaug____: can you elaborate on why we need LenientThis? I forget what it does and how to test for it :-( |
| 21:09 | <Hixie> | right now only one event handler has it |
| 21:10 | <Hixie> | (onreadystatechange, which is magical for other reasons too) |
| 21:10 | <Ms2ger> | Hixie, so, Interface.prototype.onmouseenter |
| 21:10 | <smaug____> | Hixie: bz asked for LenientThis ;) |
| 21:10 | <Ms2ger> | Hixie, that's a getter, and when you access it like that... |
| 21:10 | <Hixie> | oh, so he did |
| 21:10 | <Ms2ger> | Hixie, 'this' isn't a concrete object of the right type, so we throw |
| 21:10 | <Hixie> | looks like Ms2ger is going to do a bz impression and answer my questiosn though |
| 21:11 | <Hixie> | Ms2ger: ah, right. so there's pages doing that, huh |
| 21:11 | <Ms2ger> | Actually, pages call the setter, not the getter, but same thing |
| 21:11 | smaug____ | would need to re-read the bug |
| 21:12 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=691059#c5 fwiw |
| 21:12 | <Hixie> | yeah i'm reading that |
| 21:12 | <Hixie> | ok |
| 21:12 | <Hixie> | i guess we'll just add [LenientThis] |
| 21:13 | <Ms2ger> | Please do :) |
| 21:13 | <Hixie> | should it be that way just on everything? |
| 21:13 | <Hixie> | including Window? |
| 21:13 | <Ms2ger> | Just on the ones where it's required by compat ): |
| 21:13 | <Ms2ger> | :)* |
| 21:14 | <Hixie> | well right now there's one interface for all of the above |
| 21:14 | <Hixie> | by bz's request :-) |
| 21:14 | <Hixie> | so it's just gonna be [LenientThis] everywhere |
| 21:15 | Ms2ger | looks |
| 21:15 | <Ms2ger> | Element/Document/Window all get it in Gecko |
| 21:15 | <Ms2ger> | And then Document.onreadystatechange |
| 21:16 | <Hixie> | k |
| 21:16 | <Hixie> | will do this after lunch |
| 21:16 | <Hixie> | bbiab |
| 21:16 | <Ms2ger> | Thanks :) |
| 21:25 | <smaug____> | thanks Ms2ger |
| 21:25 | <Ms2ger> | Np |
| 22:07 | <caitp> | If anyone is around, I just wanted to follow up on some logs that Kyle Barnhart left from here in a blog post http://kyle.barnhart.ca/2013/01/webvtt-parser-specification-irc-chat.html, because I get the impression that some important information had been left out |
| 22:08 | <caitp> | he's doing this whole appeal to authority thing (and is rightfully doing so in some cases), but is using it to make huge adjustments to a number of unit tests, which those of us who are implementing the library agree are not technically correct |
| 22:08 | <Ms2ger> | Well |
| 22:08 | <Ms2ger> | AFAICT, he's suggesting you implement the normative part of the spec, instead of the authoring recommendation |
| 22:09 | <caitp> | so these are unit tests which are checking pathways through the parser code, and is completely independent of business rules such as "throw away cue X under these circumstances" |
| 22:10 | <TabAtkins> | As long as you always come up with the exact same structure as what the spec's parser has, you can do it however you want. |
| 22:10 | <Ms2ger> | Not sure what you're saying, exactly |
| 22:10 | <TabAtkins> | But it sounded a lot like you might not always come up with the same structure. |
| 22:10 | <TabAtkins> | s/the spec's parser has/the spec's parser produces/ |
| 22:10 | <caitp> | we have a design such that we can ensure that those rules are followed accordingly in the browser, but doing so during the unit tests seems to actually restrict our ability to test different issues and ensure that we can get through them without problems |
| 22:10 | <caitp> | apparently a portion of my text was cut off there :) |
| 22:11 | <caitp> | anyways, the point is that, while we are well aware that the browser is expected to behave a certain way with these files, not all applications will work that way, and being a general purpose library we kind of need to test what the code actually does rather than what a single application of it will be doing |
| 22:12 | <Ms2ger> | Your unit tests can tell apart states that are exposed the same way to the browser? |
| 22:13 | <TabAtkins> | If applications intended to interoperate with the web do different things with the same input, you're probably gonna have a bad time. For example, anything which parses WebVTT but which sometimes comes up with a different set of cues than a browser would is probably wrong. |
| 22:13 | <caitp> | what we can do in unit tests is ensure that we get expected output from the parser/scanner to ensure that it works correctly (reports syntax errors correctly, appropriately assigns cue data) |
| 22:13 | <TabAtkins> | As in - it will make people annoyed that the file they authored doesn't work the same. |
| 22:13 | <caitp> | in the browser we can say "okay, we're not going to ignore these errors, we're going to not display this cue to the browser" |
| 22:14 | <Ms2ger> | Anyway, I'm sure I'll be looking at the patches soon enough :) |
| 22:15 | <caitp> | we have a pile of work to do on those after the last few big refactors landed :( |
| 22:15 | <TabAtkins> | The only reason to not do the same thing as the browser would is in special cases like an editor, where you want to show the invalid things so the author can fix it. |
| 22:15 | <caitp> | TabAtkins, that's exactly correct, or if a browser ever decides to be more lenient on marginally malformed data |
| 22:16 | <caitp> | which i'm sure you'd frown upon, but it's known to happen |
| 22:16 | <TabAtkins> | caitp: If the latter ever happens, the correct answer is to fix the spec. No need to anticipate it ahead of time. |
| 22:17 | <Ms2ger> | We won't need to be more lenient, if all browsers implement the spec in the first place, because then authoring mistakes will be obvious immediately |
| 22:18 | <caitp> | while I agree with that, I think that's probably pretty unlikely, since even now you already have incomplete implementations in webkit and probably elsewhere |
| 22:18 | <caitp> | so quirks mode is probably already a thing destined to happen |
| 22:19 | <TabAtkins> | Seems unlikely, unless we get a large body of incompatible content. We'll more likely just slightly break some small amount of content and deal with it. |
| 22:20 | <caitp> | could go either way I think, it's hard to predict how much it will take off |
| 22:20 | <caitp> | it might have other uses apart from just accessibility features |
| 22:24 | <caitp> | anyways, these unit tests aren't worrying about business rules like "skip a cue if the timestamp is marginally wrong but can still be identified as a timestamp", and he keeps rewriting piles of tests to expect behaviour that isn't going to happen under the configuration that he's working with. it might be good to suggest writing a separate set of tests where the constraints are in line with those of the browser. I' |
| 22:24 | <caitp> | ve tried to communicate this, but he will continually exclaim that there is no other option than to do exactly what the spec says -- But of course that's not true, as already pointed out, there are other uses for the library, such as authoring and validating, and we need to ensure that we can do those things |
| 22:24 | <caitp> | I'll stop blabbing now, cheers =) |
| 22:24 | <TabAtkins> | I think it's weird to call those "business rules" when they're reasonably part of the parsing process, but whatever. ^_^ |
| 22:25 | <TabAtkins> | But yes, as I've said, all that matters is that you end up in the same structure as what the spec dictates. How you get there is unimportant. (However, sticking close to the spec is a good way to be more certain that you're doing it right.) |
| 22:49 | <gsnedders> | woo optimization! |
| 22:52 | <gsnedders> | For a month old copy of the complete, Web Apps 1.0 spec, consumeEntity is down to 0.625s from 2.132s. |
| 22:53 | <gsnedders> | Oh, and a reduction in memory usage. |
| 23:02 | <Philip`> | gsnedders: That sounds pretty slow given that the spec only uses about four different entities and they can be recognised from their first character :-p |
| 23:08 | <gsnedders> | Philip`: Well, entity lookup is no longer the bottleneck |
| 23:08 | <JonathanNeal> | Hello |
| 23:08 | <JonathanNeal> | Anyone have IE7-9 running? |
| 23:35 | <Hixie> | can anyone work out what the order is that i used for attributes in the attribute index? |
| 23:36 | <Hixie> | i think it's alphabetical by attribute name then by element names, with the element names being ordered alphabetically too |
| 23:36 | <Hixie> | and that i just screwed up type="" |
| 23:46 | <jwalden> | esprehn: regarding "overly optimistic about what happens inside the JS VMs" and "we'll catch up with lisp eventually", I think it's at least unclear, as doing all the bits of analysis lisp does may impose unacceptable runtime overhead (or may not); but it is the case that SpiderMonkey has had to be selective about analysis it does due to that analysis not paying off well enough in the common cases |
| 23:47 | TabAtkins | thinks some optional typing would help, but is willing to wait for a good PLT weenie to introduce a really nice type system first. |
| 23:50 | <Hixie> | jwalden: yeah, certainly up-front analysis is a trade-off |
| 23:51 | <Hixie> | jwalden: i think long-term it's certainly plausible that a browser could notice some JS being used a lot and start doing more detailed analysis in the background |
| 23:51 | <jwalden> | Hixie: indeed |
| 23:51 | <Hixie> | jwalden: maybe even aggregating such analysis across many users |
| 23:51 | jwalden | imagines privacy timing attacks on that ;-) |
| 23:51 | <jwalden> | but sure |
| 23:51 | <Hixie> | heh |
| 23:52 | <jwalden> | I just felt compelled to push back against the "Ope^H^H^HLisp did it first thing", when it's different requirements being solved :-) |
| 23:52 | <Hixie> | hehhah |
| 23:52 | <Hixie> | er |
| 23:53 | <Hixie> | heh was to the timing attacks, hah was to the different requireemnts |
| 23:53 | <Hixie> | we get that a lot. people are always telling me that this and that platform has solved some problem, so the web should do it too |
| 23:54 | <jwalden> | :-) |
| 23:54 | <Hixie> | and it's like, "yeah but they don't assume every application is a hostile attacker" or whatever |
| 23:54 | <Hixie> | always something different |
| 23:54 | <Hixie> | "yeah but they can assume you have a keyboard" |
| 23:54 | <Hixie> | or "yeah but they can assume the user isn't blind" |