| 07:18 | <SimonSapin> | gsnedders: yeah, that: https://github.com/html5lib/html5lib-python/issues/67 |
| 07:48 | <jgraham> | Ms2ger: Is that more significant than, say, trying to run apache on all your Windows boxes? Or whatever you do for Mobile Firefox? |
| 07:50 | <Ms2ger> | Well, it's only our IT people would hate me for that :) |
| 07:51 | <jgraham> | I'm not sure :) |
| 07:51 | <Ms2ger> | gsnedders, apparently distribute forked setuptools after a breakup with the setuptools developer, but now they're back together |
| 10:17 | <SimonSapin> | gsnedders: found another issue: https://github.com/html5lib/html5lib-python/issues/96 |
| 10:18 | <SimonSapin> | and there is no hurry for a release |
| 10:51 | <jgraham> | SimonSapin: I'm pretty sure that we only calculate the source position on demand |
| 10:51 | <jgraham> | Because it's slow |
| 10:58 | <SimonSapin> | I see |
| 10:58 | <SimonSapin> | but when I get elements from a parsed tree it’s too late |
| 10:58 | <jgraham> | Yes |
| 11:00 | <jgraham> | https://github.com/html5lib/html5lib-python/blob/master/html5lib/inputstream.py#L217 |
| 12:13 | <galant> | sorry for askign this here but why I can't do this ? if (number.style.color == "rgb(170,0,0)") |
| 12:46 | <jgraham> | Ms2ger: https://critic.hoppipolla.co.uk/r/5 :) |
| 12:50 | <Ms2ger> | That's Aryeh, isn't it? |
| 12:51 | Ms2ger | sighs |
| 12:53 | <jgraham> | Yeah, but you only need to review the few changes I made. And maybe close some of zcorpan's issues :) |
| 13:11 | <Ms2ger> | Not now :) |
| 13:45 | <SimonSapin> | If you’re using WeasyPrint: it’s about to switch to html5lib. Testing wanted: https://github.com/Kozea/WeasyPrint/pull/112 |
| 14:25 | <ondras_> | now there is this events-related stuff |
| 14:25 | <ondras_> | that I cannot see anywhere in the spec |
| 14:25 | <ondras_> | but browsers implement that in the same manner: |
| 14:26 | <ondras_> | let's add two listeners to one element |
| 14:26 | <ondras_> | capture listener that stop propagation |
| 14:26 | <ondras_> | bubble listener that does not stop |
| 14:26 | <ondras_> | when I dispatch to that element, both those listeners are called |
| 14:26 | <ondras_> | (when I dispatch to that element's child, only the first listener is obviously called) |
| 14:26 | <ondras_> | can someone please explain? |
| 14:29 | <jgraham> | ondras_: It's in the DOM spec |
| 14:29 | jgraham | afk |
| 14:30 | <ondras_> | jgraham: I would appreciate a more concrete pointer - reading http://www.w3.org/TR/DOM-Level-3-Events/ once more but still missing the relevant part :-( |
| 14:47 | <Domenic_> | ondras_: the DOM spec is http://dom.spec.whatwg.org/ |
| 14:47 | <Domenic_> | note the correlation between that URL and the name of the IRC room you're in ;) |
| 15:08 | <ondras_> | Domenic_: oops sorry, did not know that the animosity is that strong :> |
| 15:08 | <gsnedders> | SimonSapin: Is there anything apart from the BufferedStream stuff you need in 1.0b3? |
| 15:14 | <SimonSapin> | gsnedders: the current master works for me |
| 15:27 | <gsnedders> | jgraham: https://github.com/html5lib/html5lib-python/pull/98 |
| 15:33 | <SimonSapin> | gsnedders: non-seekable RawIOBase-like objects include results of urllib.urlopen(), right? |
| 15:33 | <gsnedders> | Yes. |
| 15:49 | <Ms2ger> | ondras, it's just that the originals on whatwg.org tend to be more up-to-date than the forks on w3.org |
| 16:13 | <TabAtkins> | smaug____: Re: CSSWG being on crack, you probably misunderstand. Our profiles are just a way for us to add cool things for qSA/etc without burdening CSS implementations with slow selectors. |
| 16:14 | <TabAtkins> | smaug____: It was either that, or continue to tell people "Nope, screw your qSA needs, we're tying this spec to the most perf-sensitive possible use of Selectors." |
| 16:14 | <SimonSapin> | TabAtkins: I just fixed the railroad diagram |
| 16:14 | <TabAtkins> | SimonSapin: D'oh. |
| 16:16 | <smaug____> | TabAtkins: so, on crack ;) Making selector handling inconsistent |
| 16:17 | <TabAtkins> | smaug____: Okay, shrug. I think it's an easy argument that it's good for authors to offer them more power where we can, even though that does mean some selectors are only usable in certain contexts. |
| 16:18 | <jgraham> | gsnedders: How did we end up at 1.0b4? |
| 16:18 | <smaug____> | I wouldn't give up with consistency too easily |
| 16:19 | <TabAtkins> | All I know is, I can't reasonably argue for why jQuery can do something in their selector engine but the browser can't. |
| 16:19 | <jgraham> | TabAtkins: Take the HTTPWG approach and normatively require a user-presented warning when someone uses a slow selector in CSS |
| 16:19 | <TabAtkins> | If you want consistency, sprinkle your magic performance pixie dust over everything so we can just put everything in the fast profile. ^_^ |
| 16:19 | <TabAtkins> | jgraham: Editing that in now. |
| 16:26 | <Domenic_> | moar magic pixie dust plz, i really want those selectors in my css :( |
| 16:27 | <smaug____> | (ofc jQuery can do whatever things they want in their engine. jQuery doing something isn't per se any argument.) |
| 16:28 | <TabAtkins> | smaug____: Of course not. But external libraries are a great source of inspiration for real features. |
| 16:29 | <smaug____> | sure |
| 16:29 | <TabAtkins> | smaug____: But my point is that jQuery is allowed to do certain things because they're *only* a batch processor (more or less). We have batch-processed Selectors too, but previously we've ignored their performance characteristics in favor of only honoring the perf of selectors in stylesheets. |
| 17:54 | <Stemby> | hi |
| 17:54 | <Stemby> | this morning I asked for an account on your wiki by e-mail |
| 17:54 | <Stemby> | I haven't received a reply yet... |
| 17:55 | <Stemby> | can you help me? |
| 18:00 | <gsnedders> | jgraham: How? By the previous commit being the intended 1.0b3 release. |
| 18:00 | <jgraham> | gsnedders: That's two reviews, surely? |
| 18:01 | <gsnedders> | jgraham: Well, if you want to count bumping the release number post-release as separate to the release… |
| 18:22 | <Stemby> | dglazkov, GPHemsley, Hixie, hober, jgraham, Ms2ger, ShaneHudson, TabAtkins, I found you here: http://wiki.whatwg.org/wiki/IRC |
| 18:22 | <Stemby> | can you help me? |
| 18:22 | <TabAtkins> | I *think* gphemsley is the one that maintains the wiki accounts. |
| 18:22 | <TabAtkins> | GPHemsley: ^^^ |
| 18:23 | <Hixie> | Stemby: what's up? |
| 18:23 | <Hixie> | TabAtkins: do you know if any browsers are on board with https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending ? |
| 18:23 | <Stemby> | ok, TabAtkins, tahank you! |
| 18:23 | <Stemby> | Hixie: I need an account on your wiki |
| 18:23 | <Hixie> | Stemby: e-mail address? |
| 18:24 | <Stemby> | Hixie: pm |
| 18:25 | <Hixie> | done. check e-mail for credentials. |
| 18:25 | <Stemby> | thank you very much! |
| 18:25 | <Hixie> | np |
| 18:52 | <Hixie> | i wonder what "The syntax of the property of <composite-mode> is given with" means |
| 19:11 | <ondras> | Hixie: you around? |
| 19:11 | <Hixie> | yo |
| 19:12 | <ondras> | Hixie: one more question re. events: is there an order defined for listeners on one element, or is this undefined? |
| 19:12 | <Hixie> | there is an order defined. |
| 19:12 | <Hixie> | more or less the order they were added in, though it's a bit more complicated than that when it comes to things like .onfoo handlers. |
| 19:13 | <ondras> | Hixie: okay; I guess the fixed ordering is something added relatively recently? |
| 19:13 | <ondras> | (IE firing them in the inverted order, even in recent versions iirc) |
| 19:13 | <Ms2ger> | DOM2 or so |
| 19:14 | <Hixie> | well, there's always been _an_ order |
| 19:14 | <Hixie> | sometimes the order has varied from browser to browser |
| 19:14 | <Hixie> | over the past few years, we've tried to tighten everything up in the specs |
| 19:14 | <ondras> | well, standardized "can be relied upon" order, of course |
| 19:14 | <Hixie> | well, whether it can be relied upon depends on how the browsers are doing implementing the specs |
| 19:14 | <ondras> | I am obviously completely idiotic when it comes to finding stuff in the spec |
| 19:14 | <Hixie> | and how the specs are doing matching what browsers want to implement |
| 19:15 | <ondras> | can you please point me to a good paragraph re. this order in http://dom.spec.whatwg.org/ ? |
| 19:15 | <Hixie> | dunno, let's see |
| 19:16 | <Ms2ger> | It's implicit |
| 19:16 | <ondras> | also, this statement |
| 19:16 | <ondras> | "When set to true, the capture argument ensures callback is only invoked when the event's eventPhase attribute value is CAPTURING_PHASE. " |
| 19:16 | <Ms2ger> | addEventListener says... |
| 19:16 | <Ms2ger> | *Append* an event listener to the associated list of event listeners |
| 19:16 | <ondras> | okay |
| 19:16 | <ondras> | as for the capture |
| 19:16 | <ondras> | this is not exactly true, is it? |
| 19:17 | <ondras> | the callback will be also executed in the "on target" phase |
| 19:17 | <Hixie> | http://dom.spec.whatwg.org/#concept-event-listener-invoke is where i would hope to see an explicit statement of the order in which the listeners are invoked, and i don't see it |
| 19:17 | <ondras> | if the event is dispatched at the element |
| 19:17 | <Hixie> | it just says "for each event listener" |
| 19:17 | <Hixie> | not in what order to do it |
| 19:17 | GPHemsley | notes account requests are not instantaneous. |
| 19:17 | <Hixie> | also "Let listeners be a static list of the event listeners associated with the object" doesn't seem to make any effort to maintain an order |
| 19:18 | <ondras> | Hixie: well this is some interesting news for me anyway, thanks |
| 19:18 | <ondras> | (always considered them unordered for the time being) |
| 19:18 | <Ms2ger> | Yeah, that probably could use a bug |
| 19:18 | <Hixie> | "Each EventTarget has an associated list of event listeners" doesn't seem to actually identify the list so it's not clear how to refer to it, which is clear from that text i just quoted :-) |
| 19:19 | <Ms2ger> | Hixie, easy, "the associated list of event listeners" |
| 19:19 | <Hixie> | yeah but you don't refer to them that way in the text i quoted, so... |
| 19:20 | <ondras> | Hixie: and that "capture" definition re. CAPTURING_PHASE? |
| 19:20 | <Hixie> | Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22756 |
| 19:20 | <GPHemsley> | Hixie: Psst. You forgot to mention that you created an account for Stemby ;) |
| 19:20 | <Hixie> | ondras: ? |
| 19:20 | <Ms2ger> | Hixie, thanks |
| 19:20 | <Hixie> | GPHemsley: he asked here, i answered here :-) |
| 19:21 | <GPHemsley> | GPHemsley: oh, nevermind. *I* missed reading it. As you were. |
| 19:21 | <ondras> | Hixie: so, the spec states that listeners added with capture=true will be executed only during CAPTURING_PHASE |
| 19:21 | <ondras> | Hixie: which does not seem to be the case when they are attached to the element to which the event is dispatched |
| 19:21 | <ondras> | moreover |
| 19:21 | <Hixie> | ondras: sounds right... |
| 19:22 | <ondras> | if I addEventListener(node, , false) |
| 19:22 | <ondras> | and then addEventListener(node, , true) |
| 19:22 | <ondras> | these will be called in this order, when dispatching to node |
| 19:22 | <ondras> | (!) |
| 19:22 | <ondras> | am I correct? |
| 19:22 | <Hixie> | well capture is always called first |
| 19:23 | <Hixie> | first you do all the capture handlers, from top of tree to target, then the bubbling/target handlers, from target to top of tree |
| 19:23 | <ondras> | yes, I know that |
| 19:23 | <ondras> | but this particular scenario |
| 19:23 | <ondras> | where I have both of them on the target |
| 19:23 | <Hixie> | see http://dom.spec.whatwg.org/#dispatching-events |
| 19:24 | <ondras> | yes, reading that right now |
| 19:24 | <ondras> | Then run these substeps for each event listener in listeners: |
| 19:24 | <ondras> | AT_TARGET |
| 19:24 | <ondras> | I do not see them being run "capture first" |
| 19:24 | <Hixie> | it's in teh "Dispatch" algorithm, step 6. |
| 19:24 | <Hixie> | capture handlers on the target aren't invoked, it seems |
| 19:25 | <ondras> | yes |
| 19:25 | <ondras> | because step6 covers ancestors only |
| 19:26 | <Hixie> | oh, nevermind |
| 19:26 | <Hixie> | so yeah |
| 19:26 | <Hixie> | the order on the target ignores the capture argument |
| 19:26 | <Hixie> | it seems |
| 19:26 | <ondras> | right, interesting |
| 19:26 | <Hixie> | because all the listeners are done in order, and the phase is AT_TARGET |
| 19:26 | <ondras> | thanks for acknowledging that |
| 19:26 | <Hixie> | so all the listeners fire, not just capture or bubbling |
| 19:26 | <ondras> | so only the wording at addEventListener shall be probably improved w.r.t. CAPTURING_PHASE |
| 19:27 | <Hixie> | Ms2ger: (not sure what /invoke/ 4.6 means) |
| 19:27 | <Ms2ger> | 401 annevk |
| 19:27 | <Hixie> | 401? yikes |
| 19:28 | Ms2ger | tries to recall what that was |
| 19:28 | <Ms2ger> | Payment required? Or Authorization? |
| 19:28 | <annevk> | Payment is 402 |
| 19:28 | <Hixie> | 401 is "unauthorised" |
| 19:29 | <Hixie> | i'm assuming you meant 303 |
| 19:29 | <Hixie> | anyway, https://www.w3.org/Bugs/Public/show_bug.cgi?id=22757 |
| 19:29 | <Ms2ger> | Anyway, redirect annevk |
| 19:30 | <annevk> | Hixie: initialize the callback this value? |
| 19:30 | <annevk> | Hixie: how is that unclear? |
| 19:32 | <Hixie> | the word "initialize" isn't in a[C[Catht step? |
| 19:32 | <Hixie> | woah |
| 19:32 | <Hixie> | man, when i have latency, i get all kinds of weird effects. that makes no sense. |
| 19:33 | <Hixie> | it's supposed to be tcp! |
| 19:37 | <annevk> | Hmm, shrug |
| 19:42 | <ondras> | Hixie: so, can you please confirm that stuff with addEventListener and capturing phase? |
| 19:43 | <ondras> | no need to actually file a bug right now, just a confirmation for me.. |
| 19:50 | <Hixie> | ondras: confirm which stuff? |
| 19:51 | <ondras> | 21:26 < ondras> so only the wording at addEventListener shall be probably improved w.r.t. CAPTURING_PHASE |
| 19:51 | <ondras> | 21:21 < ondras> Hixie: so, the spec states that listeners added with capture=true will be executed only during |
| 19:51 | <ondras> | CAPTURING_PHASE |
| 19:51 | <ondras> | 21:21 < ondras> Hixie: which does not seem to be the case when they are attached to the element to which the event is dispatched |
| 19:53 | <Hixie> | the non-normative text? |
| 19:54 | <ondras> | yes |
| 19:54 | <ondras> | "When set to true, the capture argument ensures" |
| 19:54 | <ondras> | this, exactly |
| 19:54 | <Hixie> | yeah, that looks to be bogus. |
| 19:54 | <Hixie> | i filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22758 |
| 19:54 | <ondras> | cool, thanks |
| 19:54 | <Hixie> | generally i ignore non-normative text |
| 19:56 | <ondras> | oh? |
| 19:57 | <Hixie> | ondras: "ain't nobody got time for that", as they say |
| 19:57 | <Hixie> | afk |
| 20:01 | <annevk> | http://www.joelonsoftware.com/items/2013/07/22.html seems pretty cool |
| 20:18 | <annevk_> | ondras: Hixie: order is registration order |
| 20:18 | <annevk> | ondras: Hixie: I'll make the spec make a copy rather than say it's a static list... |
| 20:25 | <annevk> | ondras: Hixie: thanks! |
| 20:25 | <annevk> | ondras: I'll add you as "Ondra Zara" |
| 20:32 | <galant> | why this if ( number.style.color == "rgb(170, 0, 0") is not returning true? he number.style.color is rgb(170, 0, 0) |
| 20:33 | <galant> | ok sorry for annoying I found my mistake :S |
| 20:59 | <smaug____> | rafaelw: ping |
| 21:00 | <smaug____> | rafaelw: nm, annevk_ will look into the MutationObserver issue later |
| 21:01 | <annevk_> | smaug____: so fwiw, per spec transient registered observers are just a subclass |
| 21:01 | <annevk_> | smaug____: they don't have a relationship of sorts |
| 21:01 | <smaug____> | right |
| 21:01 | <annevk_> | smaug____: they do have an observer and options associated with them |
| 21:02 | <smaug____> | 2. talks about one observer, not all |
| 21:02 | <annevk_> | so I guess we want to remove the transient registered observers for which the observer is the context object |
| 21:02 | <annevk_> | hmm yeah, is that correct? |
| 21:02 | <smaug____> | rafaelw: does that sound ok to you? |
| 21:02 | <smaug____> | that is what Gecko does |
| 21:03 | <smaug____> | and it is IMO the sanest model |
| 21:03 | <annevk_> | but the talking about one observer bit |
| 21:03 | <annevk_> | okay really have to go, will look into the logs later |
| 21:04 | <smaug____> | rafaelw: IIRC in the email you mentioned disconnect() but that is not what should happen, since it removes all the observers |
| 21:04 | <smaug____> | hmm, btw, should disconnect take an optional param, a Node, so that only some observers could be removed |
| 22:47 | <dbaron> | abarth, btw, if memory serves, the reason Opera had to implement XSLT was because Google Maps used it when Google Maps was initially released |
| 22:47 | <abarth> | dbaron: interesting |
| 22:48 | <abarth> | dbaron: I heard stories about arm-twisting by IBM |
| 22:48 | <dbaron> | abarth, which implies, perhaps, that google maps may still use it |
| 22:48 | <dbaron> | abarth, I seem to remember there being something that exposed XSLT in the maps API... |
| 22:48 | <abarth> | https://www.ibm.com/developerworks/community/blogs/HermannSW/entry/google_maps_api_and_xslt3?lang=en ? |
| 22:50 | <abarth> | that just looks like someone at IBM layering XSLT over the maps API |
| 22:51 | <abarth> | It's entirely possible we'll break some things |
| 22:51 | <abarth> | the Google C++ Style Guide uses XSLT |
| 22:51 | <abarth> | so I'm expecting angry emails from Chromium developers :)_ |
| 22:51 | <zewt> | nothing like people who use xslt writing style guides |
| 22:52 | <dbaron> | https://developers.google.com/maps/documentation/javascript/v2/reference#GXslt |
| 22:53 | <abarth> | "The Google Maps JavaScript API Version 2 was officially deprecated on May 19, 2010. The original deprecation period has been extended from May 19, 2013 until November 19, 2013. As of this date, all applications requesting v2 will be served a special, wrapped version of the v3 API instead. We expect this wrapped version of the API will work for most simple |
| 22:53 | <abarth> | maps, but we strongly encourage you to migrate your code to version 3 of the Maps JavaScript API before this date." |
| 22:54 | <dbaron> | yeah, I tried to migrate, and gave up, because what my app that uses v2 is doing can't be done in v3, it seems... :-( |
| 22:54 | <zewt> | i'm pretty leery of building anything around google apis these days |
| 22:58 | <abarth> | zewt: In this case, the API update appears to be helping us because I don't see any mention of XSLT in v3 |
| 23:38 | <rniwa> | dbaron: yt? |
| 23:38 | <dbaron> | rniwa, yes |
| 23:38 | <rniwa> | dbaron: hi |
| 23:38 | <rniwa> | dbaron: i'm reading http://www.w3.org/TR/CSS2/visudet.html#blockwidth |
| 23:39 | <rniwa> | dbaron: and it appears to me that in the over-constrained case such as http://jsfiddle.net/fezec/EVuHR/1/ |
| 23:39 | <rniwa> | dbaron: we're supposed to adjusting the right margin. |
| 23:39 | <rniwa> | dbaron: however, getComputedStyle(document.querySelector('p')).marginRight in the above case for example appear to return the specified value |
| 23:39 | <rniwa> | dbaron: on both Firefox and WebKit |
| 23:40 | <rniwa> | dbaron: does that make any sense? or am I misunderstanding something/ |
| 23:41 | <dbaron> | rniwa, it's probably technically a bug, though it's also possible we should change the spec for getComputedStyle |
| 23:41 | <rniwa> | dbaron: yeah |
| 23:41 | <rniwa> | dbaron: given that both Firefox and WebKit have been returning the specified values in those two cases |
| 23:41 | <rniwa> | dbaron: this could cause a backward compat. issues if we do change our behaviors |
| 23:41 | rniwa | wonders what IE returns |
| 23:41 | <dbaron> | rniwa, I don't think you know that -- it might be nobody will notice. |
| 23:42 | <rniwa> | dbaron: yeah, i don't have data to back it up |
| 23:42 | <rniwa> | dbaron: but for other technical reasons, i'd rather not use used values here |
| 23:43 | <rniwa> | dbaron: e.g. it'll require us to do an actual layout if we had to return the used value |
| 23:46 | <rniwa> | dbaron: i just checked. IE also returns 100px |
| 23:46 | <rniwa> | dbaron: so it's probably the spec that needs to change. |
| 23:46 | <rniwa> | dbaron: thanks for the help! |