| 02:06 | <annevk> | TabAtkins: CSS needs to define somewhere "origin of style sheet" (which is the origin of the document that included the style sheet) |
| 02:06 | <annevk> | TabAtkins: then CSS Fonts and such can just use that |
| 02:16 | <annevk> | zcorpan: your "Sync cssom specs" commit to xref broke stuff |
| 02:16 | <annevk> | zcorpan: e.g. it doesn't seem like there's separate references for the getclientrects methods anymore |
| 06:16 | <TabAtkins> | annevk: kk, can do. Looks like Cascade might be the best place to put it. |
| 06:16 | <TabAtkins> | Since it defined @import |
| 06:19 | <hsivonen> | what are the normal working hours for #sysreq? Boston office hours on weekdays? |
| 06:23 | <TabAtkins> | Likely. |
| 06:34 | <annevk> | hsivonen: also France |
| 06:52 | <TabAtkins> | annevk: Thoughts on issue 2 at <http://dev.w3.org/csswg/css-syntax/#the-input-byte-stream>;? |
| 07:03 | <annevk> | TabAtkins: fwiw, TC39 crowd dislikes CSSVariablesDeclaration-type interfaces |
| 07:04 | <annevk> | TabAtkins: because of Object.prototype |
| 07:04 | annevk | looks at issue 2 |
| 07:05 | <annevk> | TabAtkins: I think hsivonen might have a better informed opinion on that |
| 07:06 | <annevk> | TabAtkins: it's not entirely clear to me that restriction would make things safer |
| 07:28 | <annevk> | Hmm, serialization of arbitrary CSS token streams as required by CSS Variables also seems interesting |
| 07:47 | <Ms2ger> | annevk, I think that's all, then. Want to fix the other bug too? :) |
| 08:09 | <annevk> | Ms2ger: that one requires more thinking from what I remember |
| 08:09 | <jgraham> | heycam seems to be suck in some superposition of states |
| 08:10 | <annevk> | In other news, http://lists.w3.org/Archives/Public/public-texttracks/2013May/0016.html makes me sad. "it might inform a discussion of TTML profiles" is like a double red flag. |
| 08:10 | <annevk> | TTML is bad. Profiles also bad. Combined, ... |
| 08:13 | <annevk> | jgraham: he's here |
| 08:14 | <jgraham> | Wavefunction must have collapsed |
| 08:24 | <ambv> | jgraham: I got some feedback during the conference. First of all, it seems people expect html5lib to provide a custom tree format. I directed them towards bs4 for a straightforward querying API. |
| 08:24 | <annevk> | Ms2ger: so yeah, the idea was that HTML would invoke the "set parser" |
| 08:24 | <annevk> | Ms2ger: e.g. "Either when an element is created that has a class attribute or when an element's class attribute is set to a value other than the empty string, set the element's classes to the new value, parsed." is what DOM uses itself |
| 08:25 | <annevk> | Ms2ger: if that is missing anything or is not convenient enough, that'd be good to know |
| 08:27 | <jgraham> | ambv: Interesting. I mean that doesn't make much sense, but I see why people would think that |
| 08:27 | <jgraham> | Because it's traditional for libs to tightly couple parsing and representation |
| 08:28 | <ambv> | yes, I share your view that it's great to have those decoupled. |
| 08:28 | <ambv> | jgraham: Another thing, it seems we're currently very slow compared to other parsers and this makes for some poor PR, aka FUD. |
| 08:28 | <ambv> | So increasing performance would be a good target for post-1.0 releases. |
| 08:54 | <jgraham> | ambv: Well it's no secret that we're slow. Not sure it's possible to squeeze that much more performance out of pure python |
| 08:54 | <jgraham> | Or at least, we have spent non-trivial effort benchmarking it in the past |
| 08:55 | <jgraham> | Reading through one character at a time just isn't very efficient. But that's needed for a compliant implementation. |
| 08:56 | <jgraham> | Really I think the effort would be better spent on writing a C implementation in libxml2 |
| 08:56 | <jgraham> | Then lxml.html would be fast and non-sucky |
| 08:56 | <ambv> | We can at least work with the PyPy guys to make it JIT compile better. |
| 08:56 | <jgraham> | Yeah, that makes sense |
| 08:57 | <jgraham> | Especially since lxml on PyPy doesn't seem to work so well |
| 08:57 | <ambv> | Currently for huge documents it's 5x faster than CPython but for typical documents it's 2x … slower. |
| 08:58 | <ambv> | jgraham: lxml still is 30x faster than html5lib on PyPy ;) but I guess there's much potential in improving html5lib performance. it would be big news for both html5lib and PyPy if we got the performance on par with lxml. |
| 08:58 | <ambv> | jgraham: https://github.com/ambv/html5lib-microbench |
| 08:58 | <SimonSapin> | jgraham: in libxml2, do you mean incremental conformance improvements on the existing parser, or a brand new implementation? |
| 09:00 | <jgraham> | SimonSapin: Yes :p |
| 09:00 | <SimonSapin> | jgraham: yes to which? |
| 09:01 | <jgraham> | One of those. It was a non-exclusive or, right? ;) |
| 09:01 | <jgraham> | I haven't looked at the existing parser well enough to know if "incremental improvements" are likely to end up with something conformant |
| 09:02 | <SimonSapin> | I had in mind, which do you think would be the way to go? |
| 09:02 | <jgraham> | If they would, that would be the low risk option, but my general feeling is that unless you started with the right architecture you won't end up with something conformant |
| 09:03 | <jgraham> | And so far only WebKit were close to having the right architecture |
| 09:03 | <jgraham> | and taht was because the spec was based on more on webkit than on anyone else |
| 09:09 | Ms2ger | kicks his connection |
| 09:10 | <Ms2ger> | annevk, do we have a bug on Hixie to invoke the set parser, then? |
| 09:52 | <annevk> | marcosc: you don't want "Call resolver's reject(value) method with error as value argument."; you want to call the internal resolve algorithm |
| 09:53 | <annevk> | Ms2ger: that could be that bug I suppose |
| 09:53 | <Ms2ger> | wfm |
| 09:53 | <annevk> | Ms2ger: bit slow today |
| 09:54 | <marcosc> | annevk: makes sense |
| 09:54 | <marcosc> | (I din't write the text, fwiw) |
| 09:54 | <annevk> | marcosc: k |
| 09:55 | <annevk> | marcosc: also needs to say something about running the remaining steps asynchronously and not terminating when you return |
| 09:55 | <annevk> | marcosc: looks okay otherwise |
| 09:55 | <marcosc> | annevk: thanks :) |
| 09:56 | <marcosc> | annevk: will update the corresponding bug on the sysapps repo |
| 10:41 | <zcorpan> | TabAtkins: "When errors occur in CSS, the parser attempts to recover gracefully, throwing away only the minimum amount of content before returning to parsing as normal." isn't quite true. for instance, a broken selector throws away the entire ruleset rather than just the selector |
| 10:43 | <zcorpan> | or maybe i misunderstood. it talks about the parser, while throwing away rulesets happens later |
| 10:44 | <ambv> | jgraham: http://pypi-externals.caremad.io/help/what/ |
| 10:48 | <jgraham> | ambv: Context? |
| 10:49 | <ambv> | jgraham: distutils is very very very slow when it scrapes websites to find downloadable links. Disable this functionality by explicitly listing that we only publish packages on PyPI |
| 10:49 | <ambv> | this makes downloading packages significantly faster |
| 10:53 | <gsnedders> | ambv: Yeah, I saw that a few days ago. |
| 10:53 | <gsnedders> | ambv: But I thought it was in setup.py that changed the metadata, not just on PyPI |
| 10:54 | <ambv> | gsnedders: the newest distribute and setuptools are smarter than that but the default is still spurious scraping unless you opt-in on PyPI to the faster method |
| 10:56 | <gsnedders> | ambv: Does this have to be done per-version? |
| 10:56 | <gsnedders> | Le sigh. |
| 10:57 | <gsnedders> | No, doing it once seems enough. |
| 10:57 | <gsnedders> | Well, okay. |
| 11:08 | <ambv> | :-) |
| 13:20 | <zcorpan> | TabAtkins: isn't the specced bad-url behavior bad for future compat if we want to add expressions in url()? |
| 15:40 | <TabAtkins> | zcorpan: I don't think we ever can. |
| 15:40 | <Ms2ger> | Apparently document.all.tags has been broken in Gecko since Fx3.0 |
| 15:41 | <miketaylr> | :'( |
| 15:41 | <miketaylr> | quit breaking my sweet dhtml site guys |
| 15:42 | <Ms2ger> | Should tell sicking :) |
| 16:09 | <TabAtkins> | annevk: Can you explain what the Object.prototype problem is? Keys set on Object.prototype showing up as non-own properties on all objects? I don't know why that's a problem for this kind of interface, or what I could do about it. |
| 16:09 | <TabAtkins> | annevk: Maybe expose it as a JS Map? |
| 16:10 | <TabAtkins> | annevk: Also, Syntax + CSSOM mandate how to serialize arbitrary token streams. |
| 16:10 | <TabAtkins> | (Or rather, will, once CSSOM finishes serialization stuff.) |
| 16:12 | <TabAtkins> | zcorpan: Text about error-recovery is of course approximate and non-normative. But throwing away "just the selector" on a ruleset wouldn't help much - you'd be left with a ruleset with no selector, which doesn't match anything. |
| 16:13 | <TabAtkins> | But anyway, I have compat constraints to operate under with error recovery. |
| 16:14 | <Ms2ger> | TabAtkins, I think the point was about |foo, #broken# { ... }| not applying anything to foo |
| 16:15 | <TabAtkins> | Hm, exposing Variables as a JS Map seems like a much better idea anyway. Wonder why I didn't think about that? |
| 16:15 | <TabAtkins> | Ms2ger: Ah, perhaps. That was unclear. Regardless, we know that was a mistake, but not one we can fix. |
| 16:15 | <TabAtkins> | ;_; |
| 16:16 | <TabAtkins> | heycam|away|away: Your username is weird. Also, there any IDL magic necessary to make something be a JS Map? |
| 16:17 | <Ms2ger> | TabAtkins, you guys might want to drop document.all.tags too |
| 16:51 | <dglazkov> | good morning, Whatwg! |
| 16:51 | <TabAtkins> | Ms2ger: I'll send an email. |
| 16:51 | <Ms2ger> | Ta |
| 16:52 | <TabAtkins> | Ms2ger: Got a bug or something I can ref? |
| 17:55 | <GPHemsley> | ICYMI: The Open Source (read: GitHub) Report Card: http://osrc.dfm.io/ |
| 17:58 | <jgraham> | "It seems—from their activity streams—that jgraham and w3c are probably friends" |
| 17:58 | <jgraham> | Hmm |
| 17:58 | <Ms2ger> | Ha |
| 17:59 | <Ms2ger> | TabAtkins, er, thought I'd replied: https://bugzilla.mozilla.org/show_bug.cgi?id=874084 |
| 18:00 | <Ms2ger> | "Ms2ger is a trend setting Javascripter" |
| 18:00 | <Ms2ger> | Well, that sure is news to me |
| 18:01 | <jgraham> | Maybe writing testharness.js is a trend? |
| 18:01 | <jgraham> | +tests |
| 18:01 | <Ms2ger> | Still one you set, then |
| 18:02 | <Ms2ger> | Also, apparently I do my work at 3am |
| 18:02 | <jgraham> | Yeah, I'm not convinced by its timezone corrections (and neither is it, to be fair) |
| 18:03 | <GPHemsley> | It's kinda revealing about how much work one does on GitHub vs. off it |
| 18:04 | <GPHemsley> | like, GitHub has no idea about my PHP stuff because it's not really on GitHub |
| 18:04 | <GPHemsley> | (and GitHub thinks mimesniff is Tcl, for some reason) |
| 18:07 | Ms2ger | kicks document.all some more |
| 18:08 | <jgraham> | Violence is the last refuge of the incompetent |
| 18:08 | <jgraham> | On the other hand document.all deserves it |
| 18:08 | <jgraham> | So please continue |
| 18:09 | <Ms2ger> | document.all["2"] |
| 18:09 | <Ms2ger> | What gives? |
| 18:09 | <Ms2ger> | How about ("2"), item("2"), namedItem("2")? |
| 18:12 | <Ms2ger> | The answer is obvious |
| 18:12 | <Ms2ger> | "depends on the browser" |
| 18:14 | <jgraham> | wwied? |
| 18:14 | <jgraham> | Or really wdied? |
| 18:15 | <Ms2ger> | ? |
| 18:15 | <jgraham> | what does IE do? |
| 18:16 | <Ms2ger> | Ah |
| 18:17 | <Ms2ger> | getElementsByTagName("*")[2] for [], () and item(), and the thing with name "2" for namedItem() |
| 18:19 | <Ms2ger> | Oh wait |
| 18:19 | Ms2ger | should look at the right lines |
| 18:20 | <Ms2ger> | getElementsByTagName("*")[2] for [] and (), and the thing with name "2" for item() and namedItem() |
| 18:24 | <jgraham> | Ah, so presto got it "right" then |
| 18:24 | <jgraham> | No surprise there :) |