| 00:00 | <caitp> | make kripken fix it! |
| 00:00 | <daurnimator> | caitp: I'm project owner now :P |
| 00:00 | <caitp> | furreal? |
| 00:00 | <daurnimator> | (of lua.vm.js, not emscripten) |
| 00:00 | <caitp> | oh I see |
| 00:00 | <daurnimator> | lua.vm.js was originally a kripken demo |
| 00:01 | <daurnimator> | BUT, thats just one example (thats easy for me to explain, as I'm close to it) |
| 00:01 | <daurnimator> | there's plenty of languages/frameworks/etc that live on top of js |
| 00:02 | <SamB> | (note that it is possible to do finalizers in such a way that the object being finalized is never actually revealed to the finalizer) |
| 00:02 | <daurnimator> | SamB: hmm? |
| 00:03 | <SamB> | well, I mean, the finalizer could certainly know "which one" it had been |
| 00:03 | <SamB> | but the object can be dead |
| 00:03 | <daurnimator> | which what? |
| 00:03 | <SamB> | but that's about finalizer interfaces, not about what you can do in JS now |
| 00:07 | <roc> | "that sounds like a documentation issue" hahahahahahaha. You must be new here :-) |
| 00:07 | <SamB> | yeah, indeed |
| 00:08 | <daurnimator> | roc: I didn't say documentation issues could be solved ;) |
| 00:09 | <roc> | depends on what you mean by solved |
| 00:09 | <roc> | documenting things is easy |
| 00:09 | <daurnimator> | if only |
| 00:09 | <roc> | getting people to *follow* the documentation, that's impossible. |
| 00:09 | <daurnimator> | if documentation was easy the world would be a nicer place |
| 00:09 | <caitp> | it's even more impossible when the documentation sucks |
| 00:10 | <daurnimator> | where (e.g.) undefined behaviour in C was obvious |
| 00:59 | <SamB> | daurnimator: that's *not* just a documentation issue |
| 01:00 | <SamB> | http://en.wikipedia.org/wiki/Finalizer#Resource_management mentions that using finalizers to release resources isn't really all that wise, though that obviously doesn't really apply to trying to interface two GCs ... |
| 01:01 | <SamB> | more to the file thing |
| 01:04 | <caitp> | Sam that article is essentially saying "deallocating resources during a finalizer is unwise because finalizers might be implemented wrong" |
| 01:04 | <caitp> | that's kind of a silly argument |
| 01:05 | <SamB> | caitp: not really |
| 01:06 | <SamB> | finalizers *are* tied to garbage collection; using them to free resources besides garbage collected memory is very risky, because the next GC could come much later than you expect |
| 01:07 | <SamB> | especially with some browsers taking a more aggressive approach to GC than others |
| 01:07 | <caitp> | with browsers it's a bit complicated when C++ code holds references to JS objects, BUT at the end of the day, if there are no references to an object that "matter", the object is effectively dead whether it gets collected or not |
| 01:07 | <caitp> | and can therefore be considered to be finalized |
| 01:08 | <SamB> | um, what exactly is going to be crawling the heap to detect that they aren't referenced, if not the GC? |
| 01:09 | <caitp> | it could be the same algorithm which determines that an object needs to be garbage collected, that would be fine |
| 01:10 | <caitp> | it would just mark an object as finalized and inform the script context |
| 01:10 | <caitp> | and yeah, you could do that and prevent the object from reviving itself during finalization |
| 01:11 | <caitp> | we don't do that, but there's no real reason why we can't |
| 01:11 | <caitp> | it's just the way it is |
| 01:12 | <SamB> | I think there's a lot of Python code out there expecting immediate finalization, actually, because of CPython's reference-counting |
| 01:13 | <gsnedders> | That's definitely the case. Though CPython does have some slightly wacky behaviour with finalizers. |
| 01:13 | <gsnedders> | (Python 3 at least raises a warning if a file object's finalizer closes the file) |
| 01:13 | <SamB> | caitp: as I understand it, a dry run of most any GC algorithm won't take any less time, really |
| 01:13 | <SamB> | gsnedders: ah, cool |
| 01:13 | <SamB> | wonder why not in 2.7 |
| 01:14 | <gsnedders> | Added to 3 after 2.7 shipped, I think |
| 01:14 | <SamB> | what, that's a "feature" or something? |
| 01:14 | <gsnedders> | Adding a warning where there wasn't one before? It's a behavioural change, it's not a bugfix. |
| 01:14 | <SamB> | but they should have added it back in 2.2 |
| 01:15 | <gsnedders> | Did the warnings module exist back then? |
| 01:15 | <gsnedders> | ;P |
| 01:15 | <caitp> | SamB I don't think it would necessarily be a "dry run", just "notify the script before cleaning stuff up" --- there's no guarantee that once an object is marked for collection that it will be collected immediately anyways |
| 01:15 | <SamB> | gsnedders: that's beside the point; *Jython* existed back then and was considered to be Python! |
| 01:15 | <caitp> | but it doesn't matter, this was a design decision that a certain guy made zillions of years ago, too late to do anything about it |
| 01:16 | <SamB> | I thought the *unmarked* objects were the ones that got collected |
| 01:16 | <gsnedders> | SamB: Speaking of Jython, I ought deal with the html5lib PR that adds support for it |
| 01:16 | <gsnedders> | And yes, unmarked objects get collected |
| 01:17 | <gsnedders> | Typically |
| 01:17 | <gsnedders> | You can of course reverse the flags |
| 01:17 | <caitp> | there's no real difference |
| 01:17 | <SamB> | of course, which value of the flag counts as "marked" can be flipped from pass to pass |
| 01:17 | <SamB> | but the ones you visited and marked, those were reachable |
| 01:17 | <SamB> | so you want to keep them |
| 01:18 | <caitp> | it draws the same picture no matter how you phrase it, and the pictures of cycle collection algorithms are not things I want in my brain right now :d |
| 01:18 | <gsnedders> | bah, cycle collection algorithms are really simple in their simplest forms! |
| 01:18 | <SamB> | oh, you're going back to Python territory |
| 01:19 | <SamB> | most things don't have cycle collectors, they have *garbage* collectors |
| 01:19 | <SamB> | which sometimes actually work by collecting the non-garbage and declaring whatever is left behind nonexistant |
| 01:19 | <gsnedders> | SamB: they're the same, just a "cycle" collector will never collect anything except things that have cycles because they've already been freed through refcounting |
| 01:19 | <SamB> | (obviously if there are finalizer-bearing objects involved it has to do something about those, though) |
| 01:20 | <SamB> | gsnedders: well, if someone says "cycle collector" it brings to mind that same "normal stuff gets freed immediately, right?" assumption from crufty Python code |
| 01:20 | <gsnedders> | right |
| 01:23 | <SamB> | hmm, this is the wrong kind of cycle collection: http://www.cyclemuseum.org.uk/ |
| 01:23 | <gsnedders> | hah |
| 01:23 | <gsnedders> | (interesting, pulling the power cord out of this makes it suspend, hmmm) |
| 01:25 | <SamB> | this doesn't sound much like a normal GC algorithm: https://developer.mozilla.org/en-US/docs/Interfacing_with_the_XPCOM_cycle_collector |
| 01:25 | <gsnedders> | you're touching XPCOM, anything "normal" is far away |
| 01:26 | <SamB> | it looks more like the kind of algorithm I'd expect with a name like "cycle collection" though |
| 01:26 | <caitp> | kyle huey gave a good talk about it, probably quite a few of them, it's not really unreasonable |
| 01:27 | <SamB> | the way it decides to even start looking for a cycle at any given object certainly sounds sensible (as a first impression, anyway) |
| 01:34 | <roc> | our approach to refcounting + cycle collection has actually turned out to be pretty good |
| 01:34 | <roc> | it has a lot of advantages over traditional tracing GC |
| 01:35 | <SamB> | roc: well, it's probably Hixie's worst nightmare to expose anything like it to JS |
| 01:35 | <roc> | of course we're not going to do that |
| 01:35 | <SamB> | yeah |
| 01:35 | <SamB> | just sayin! |
| 01:36 | <roc> | the main problem with refcounting+CC is that the performance of refcounting objects that are strongly referenced from multiple threads is terrible |
| 01:36 | <SamB> | yeah |
| 01:36 | <roc> | fortunately, that is very rare in a Web browsers. |
| 01:37 | <SamB> | certainly not from the PoV of content |
| 01:37 | <roc> | OTOH pretty much all academic GC research assumes that it's common. Which is why GC researchers have not explored the space that we have. |
| 01:38 | <SamB> | it sounds like what the XPCOM cycle collector requires of objects is very similar to what the CPython cycle collector requires |
| 01:39 | <roc> | hopefully one of the C++ reflection proposals will let us generate the tracing hooks automatically, without the nasty boilerplate code we currently have |
| 01:39 | <SamB> | oh, except suspicion is automatic in CPython |
| 01:40 | <SamB> | hmm, I guess you can't just use that Python plugin for GCC, can you, since you build with cl.exe on Windows |
| 01:40 | <roc> | yes |
| 01:41 | <roc> | we're working on supporting clang-cl on Windows but I suspect it will be a long time, if ever, before we can ship clang-cl builds |
| 01:41 | <SamB> | the idea being to use it to write the boilerplate to a text file, mind you, not to inject it into GCC directly |
| 01:41 | <SamB> | it sounds like the Python plugin is still read-only |
| 01:57 | <Hixie> | wow, academic GC research assumes cross-thread references? |
| 01:57 | <Hixie> | i wouldn't have guessed that |
| 01:58 | <Hixie> | i always kinda assumed that keeping cross-thread references to a minimum was basically a given |
| 01:59 | <SamB> | well, some research involves actual multithreaded programs, not just multiplexings of single-threaded programs |
| 01:59 | <roc> | Hixie: the majority is done in the context of Java |
| 02:00 | <Hixie> | ah |
| 02:00 | <roc> | Hixie: the issue isn't so much that there are lots of actual cross-thread references, but that every class is potentially referencable across threads |
| 02:00 | <roc> | so you have to make your refcount operations thread-safe |
| 02:00 | <Hixie> | fair enough |
| 02:00 | <Hixie> | that's got to be a hell of an overhead |
| 02:01 | <roc> | or do very clever optimizations to avoid that |
| 02:01 | <roc> | they don't use reference-counting. That's why. |
| 02:01 | <roc> | whereas in the browser we know statically that most classes cannot be referenced across threads so it's trivial to avoid atomic refcount ops. |
| 02:01 | <SamB> | well, that's *one* reason anyway |
| 02:02 | <Hixie> | roc: ah |
| 02:39 | <SamB> | whoa: <http://researcher.watson.ibm.com/researcher/view_group.php?id=3385>; seems to have been used in jikes despite being based on reference counting ... |
| 02:43 | <roc> | Jikes supports lots of GC algorithms. It's commonly used as a GC research testbed. |
| 02:44 | <SamB> | oh |
| 02:44 | <SamB> | so it's like "We modified GCC to do this or that" |
| 02:45 | <roc> | right |
| 04:00 | <TabAtkins> | MikeSmith: Re U+000C, mind raising that in www-style? It's probably possible to converge. |
| 04:02 | <TabAtkins> | Oh, never mind, I see you got your question answered. I didn't remember that u+000c was preprocessed away. |
| 04:33 | <TabAtkins> | Hixie, jgraham: Re: cells in a given column, we've got stuff in Selectors for that now. (Unimplemented.) |
| 05:02 | <SamB> | TabAtkins: WANT IT! |
| 06:28 | <MikeSmith> | TabAtkins: you saw my bug about making eof in comments a parse error? |
| 06:28 | <TabAtkins> | You saw my response to that bug? |
| 06:28 | <MikeSmith> | TabAtkins: ah no, not yet, just got back online now |
| 06:29 | MikeSmith | looks |
| 06:30 | <MikeSmith> | rock and roll |
| 06:30 | <TabAtkins> | D'oh, I didn't mark it RESOLVED. |
| 06:30 | <MikeSmith> | TabAtkins: thanks man |
| 06:30 | <TabAtkins> | Link me? |
| 06:30 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26270 |
| 06:51 | <MikeSmith> | TabAtkins: btw https://github.com/validator/syntax/blob/master/relaxng/datatype/java/src/org/whattf/datatype/tools/CssParser.java#L36 |
| 06:51 | <MikeSmith> | TabAtkins: uses Rhino to expose your CSS parser/tokenizer to Java |
| 07:43 | <mathiasbynens> | zcorpan (assuming you’re reading the logs): the blog post was updated when the removal was moved to M37 https://github.com/operasoftware/devopera/commit/beb0d174be24588bb9f39fc5cc301f9d081e6395 afaik this is still the current plan |
| 09:04 | <Ms2ger> | "When using letter-spacing != 0, disable ligatures through font-feature-settings." |
| 09:04 | <Ms2ger> | Who doesn't do that automatically? |
| 12:15 | <Ms2ger> | For our friends at w3cmemes: https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/21801c47ccff06fa5e6612aea5b87095/tumblr_mlqdctiGeH1rvsbh9o1_500.jpg |
| 12:20 | <MikeSmith> | Ms2ger: great photo of timeless there |
| 12:22 | <ManishCloud> | Hixie: around? |
| 12:22 | <ManishCloud> | Where, besides XHR, is the Fetch spec used for a browser? |
| 12:23 | <ManishCloud> | It seems like HTML5 has its own fetch spec, which is rather different: http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html |
| 12:23 | <Ms2ger> | Awaiting integration :) |
| 12:25 | <ManishCloud> | Ms2ger: O.o |
| 12:25 | <ManishCloud> | Not seriously? |
| 12:25 | <Ms2ger> | http://dev.w3.org/2006/webapi/FileAPI/ seems to reference Fetch |
| 12:26 | <Ms2ger> | HTML will move to referencing Fetch at some point when Hixie has time |
| 12:26 | <ManishCloud> | ah |
| 12:27 | <ManishCloud> | 'cause annvk had mentioned that <img> and all use Fetch, but I couldn't find any references |
| 12:29 | <ManishCloud> | Ms2ger: will that mean major changes to Fetch, or just the addition of a couple of flags here and there |
| 12:29 | <ManishCloud> | ? |
| 12:30 | <jgraham_> | |
| 12:30 | <Ms2ger> | I hope not too major |
| 12:30 | <Ms2ger> | Hi jgraham_ |
| 12:30 | <ManishCloud> | jgraham_: you seem to have protected yourself from lint |
| 12:31 | <jgraham_> | Turns out that facebook guest wifi sucks |
| 12:36 | <hsivonen> | MikeSmith: what do the new additions of the galimatias jar and TabAtkins's tokenizer.js and parser.js do? |
| 12:36 | <hsivonen> | MikeSmith: in the validator, that is |
| 12:39 | <hsivonen> | MikeSmith: ah. so galimatias is a new URL parsing lib |
| 12:39 | <hsivonen> | MikeSmith: there's something wrong with the build script, though. It's not getting picked up by javac |
| 12:41 | <MikeSmith> | hsivonen: the latest galimatias release addes UTS 46 to bring it into conformance with the current URL spec. It just uses ICU4J |
| 12:42 | <MikeSmith> | hsivonen: as far as TabAtkins's tokenizer.js and parser.js, I'm using them for @sizes checking via a bridge through Rhino |
| 12:43 | <MikeSmith> | hsivonen: I think we could eventually replace the current MediaQuery datatype checker -- which isn't conformant with the latest CSS specs -- with a new one written using TabAtkins's tokenizer |
| 12:45 | <MikeSmith> | hsivonen: but I'm not doing that yet. Right now, I'm only using it as an extra step to catch any outright syntax errors, before it then goes to the existing MediaQuery datatype checker |
| 12:45 | <MikeSmith> | hsivonen: if the build script is failing it may be I broke something very recently. I'll do a fresh checkout and see myself too |
| 12:46 | <hsivonen> | MikeSmith: bridge through Rhino... wow. there must be a you dawg joke in there somewhere. :-) |
| 12:47 | <hsivonen> | MikeSmith: I just pushed a build.py update for the dl URL for jsontool-core, FWIW |
| 12:47 | <MikeSmith> | hsivonen: as far as galimatias I only have it being used now for Iri and IriRef datatype checking, and DataURI checking -- but we could eventually use it to replace the other cases where we're using Jena |
| 12:47 | <MikeSmith> | ok |
| 12:47 | <hsivonen> | MikeSmith: I see |
| 12:47 | <hsivonen> | I'm pretty sure there's just a classpath problem with how build.py invokes javac |
| 12:49 | <hsivonen> | MikeSmith: at least the version of galimatas in classpath doesn't match the version on disk |
| 12:50 | <MikeSmith> | hsivonen: yeah I wasn't sure the Rhino bridge thing would have acceptable performance but it seems to be just fine. It all gets compiled just once -- static. And I guess that may costs some couple hundred milliseconds the first time, but then after that it's negligible -- a few milliseconds at most maybe |
| 12:50 | <MikeSmith> | hsivonen: OK will check right now |
| 12:50 | <hsivonen> | MikeSmith: cool |
| 12:51 | <hsivonen> | OK. I fixed this locally. I'll push. |
| 12:51 | <MikeSmith> | ok |
| 12:51 | MikeSmith | is curious to see what he was doing wrong |
| 12:51 | <darobin> | MikeSmith: I think it was that last drink Saturday night |
| 12:52 | <MikeSmith> | darobin: either that or the part where I fell off the hotel balcony |
| 12:53 | <darobin> | that would cause problems with the validator for sure |
| 12:55 | <hsivonen> | MikeSmith: https://github.com/validator/build/commit/6f429116af4820f96223de8eb60e3df653b9f567 |
| 12:55 | <MikeSmith> | jgraham: I bet it still doesn't suck as bad as Mozilla SF guest wifi |
| 12:56 | <MikeSmith> | hsivonen: ah yeah. sorry :( that's the 2nd time I maade that same mistake (I did it the previous time galimatias got updated) |
| 12:57 | <jgraham> | MikeSmith: I think you were unlucky, although I might be wrong |
| 12:57 | <MikeSmith> | hsivonen: btw I don't know what we're using jsontools for. I trust it is still actually being used somewhere |
| 12:58 | <hsivonen> | MikeSmith: used for HTML tokenizer unit tests |
| 12:58 | <MikeSmith> | hsivonen: ah OK |
| 12:59 | <hsivonen> | looks like I need to teach my deployment script about galimatias |
| 13:16 | smaug____ | wonders if keygen could be killed |
| 13:19 | <MikeSmith> | smaug____: it can't (not last I heard at least). I think Apple was one of those saying they're aware of known sites it would be break that aren't likely to change to quit using it |
| 13:20 | <MikeSmith> | smaug____: I guess it remains an evangelism issue (as far as possibility of killing it) |
| 13:20 | <smaug____> | MikeSmith: do you recall when apple said that? |
| 13:20 | <MikeSmith> | smaug____: I could try to find it. It's been a few years. I think it was on the public-html list |
| 13:21 | <MikeSmith> | hsivonen: I did a fresh checkout and build (with your build.py changes) and it all runs fine |
| 13:22 | <MikeSmith> | hsivonen: though I see that the galimatias change does cause the TestRunner build to fail. But that's not fatal. Anyway, I'll try to fix that too right now |
| 13:24 | <Ualidus> | hello |
| 13:26 | <MikeSmith> | hsivonen: hmm no I see that's not a build issue but instead seems to be a runtime problem that the TestRunner is exposing |
| 13:27 | <MikeSmith> | Ms2ger: quit trolling over on #w3c ("Can anyone recommend a good guide for making my website xhtml 2.0 compliant?") |
| 13:27 | <Ualidus> | I have a question, I don't understand the part of the warning about the InvalidAccessError : http://xhr.spec.whatwg.org/#the-open%28%29-method |
| 13:27 | <Ualidus> | I think I have this error occuring, but I'm not quite sure... |
| 13:27 | <Ualidus> | and I don't know how to fix it |
| 13:33 | <Ualidus> | according to the steps of the open method, the error should be thrown before the request is sent (I suppose), but it seems my script is used anyway... I'm completely lost. :) |
| 13:35 | <hsivonen> | MikeSmith: so the deployment script I have actually does upload galimatias to the server |
| 13:35 | <hsivonen> | MikeSmith: but it fails for some other reason... |
| 13:36 | <hsivonen> | It doesn't find the main class |
| 13:36 | <hsivonen> | I'm trying to see if there's a problem with the command line |
| 13:39 | hsivonen | sees -Dnu.validator.servlet.follow-w3c-spec=0 |
| 13:39 | hsivonen | doesn't recall noticing that before |
| 13:40 | <hsivonen> | the error I get is Error: Could not find or load main class results |
| 13:40 | <MikeSmith> | hsivonen: yeah a while back I separated out the w3c "branding" behavior from the w3c-specific schema behavior |
| 13:41 | <MikeSmith> | hsivonen: a class literally named "results"? |
| 13:43 | <Ms2ger> | jgraham, oh, you folks are at GB? |
| 13:43 | <Ms2ger> | FB* |
| 13:43 | <MikeSmith> | hsivonen: at this point I wonder if we should just back out to the previous galimatias version -- 0.0.4 I guess |
| 13:45 | <Ms2ger> | MikeSmith, I wish I could troll as well as that person |
| 13:45 | <MikeSmith> | hsivonen: because another problem is that galimatias 0.1.0 requires a newer version of ICU4J than what we have. I think it maybe it needs v4.5 at least, and we have v4.4 -- which seems to lack the getUTS46Instance method (or at least the right getUTS46Instance method that galimatias expects) |
| 13:46 | <MikeSmith> | Ms2ger: :-) |
| 14:22 | <Ualidus> | i have to go, see ya. |
| 14:50 | <Jasper> | Trying to parse something in the CSS transitions spec. |
| 14:50 | <Jasper> | "For each shadow, if one input shadow is ‘inset’ and the other is not, then the result for that shadow matches the inputs; otherwise the entire list is not interpolable." |
| 14:51 | <Jasper> | That reads to me like if the two shadows are opposing, then it's interpolable, but if they're the same, then it's not. |
| 14:51 | <Jasper> | That seems quite wrong to me. |
| 14:51 | <Jasper> | How am I supposed to read it? |
| 15:01 | <MikeSmith> | Jasper: you might have better luck pinging dino about that on #webkit, if he's around there |
| 15:02 | <TabAtkins> | Jasper: Yup, that's totally opposite. |
| 15:02 | <TabAtkins> | And also super-unclear what it's trying to talk about. |
| 15:02 | <TabAtkins> | (Looks like it's trying to define the inset-ness fo the interpolating shadow.) |
| 15:03 | <TabAtkins> | Jasper: I'll fix. |
| 15:05 | <Jasper> | TabAtkins, thanks! |
| 15:07 | <TabAtkins> | Jasper: What's your name, for the Acks? |
| 15:08 | <Jasper> | TabAtkins, Jasper St. Pierre |
| 15:08 | <TabAtkins> | Does that alphabetize as S or P? |
| 15:08 | <Jasper> | I'd go with S. |
| 15:09 | <TabAtkins> | Oh, didn't matter anyway; last name in the acks was an M. |
| 15:09 | <TabAtkins> | Anyway, fixed and pushing now. |
| 15:10 | <MikeSmith> | in the spec there's an example for the "accept" attribute for input@type that looks like <input type="file"accept=".doc,.docx,.xml,application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document"> |
| 15:10 | <MikeSmith> | that is, with extensions like ".doc" in there -- not just mime types |
| 15:11 | <MikeSmith> | Do UAs actually support that? |
| 15:11 | <Ms2ger> | TabAtkins, alphabetizes as J, clearly ;) |
| 15:13 | <TabAtkins> | Ms2ger: This spec alphabetizes by family name, so I'm just matching convention. |
| 15:21 | <MikeSmith> | hsivonen: dunno if you're still around any longer today, but if you are, please let me know if it's OK with you to downgrade galimatias do the previous version -- 0.0.4. I'd go ahead and just do it, but I don't want to further muff things up with you trying to deploy right now. |
| 15:21 | <MikeSmith> | hsivonen: anyway I don't think the 0.1.0 version of galimatias is going to work for us in production until we update our ICU4J version |
| 17:14 | <Hixie> | Manishearth: yeah, i need to update HTML to point to fetch.spec.whatwg.org |
| 19:38 | <Hixie> | jgraham: i removed omit_optional_tags=on but i'm still getting some end tags omitted, any idea what's up? |
| 19:39 | <zcorpan> | mathiasbynens: hmm. i see "The latest plan is to land the showModalDialog removal in Chromium 36. " |
| 19:50 | <timeless> | MikeSmith: where? |
| 20:07 | <montecfel> | Why is nothing outputted when I resize the window? document.addEventListener("resize", function() { console.log("a"); }); |
| 20:07 | <montecfel> | Also, is there better documentation than MozDev? I find it to suck. |
| 20:27 | <mathiasbynens> | montecfel: because you’re resizing the `window`, like you said, not the `document` |
| 20:31 | <Hixie> | gsnedders: dude in what order does anolis number IDs? |
| 20:31 | <Hixie> | gsnedders: i just noticed that id=history-0 is after id=history-1 in the HTML spec |
| 20:31 | <Hixie> | is it like dfns before headings or some such? |
| 20:35 | <Hixie> | looks like that's exactly what it is |
| 20:35 | <Hixie> | oh man |
| 23:59 | <MikeSmith> | Hixie: bugwards compatibility ftw man |
