/irc-logs / freenode / #whatwg / 2014-01-29 / end

Options:

# Session Start: Wed Jan 29 00:00:00 2014
# Session Ident: #whatwg
# [00:00] * Joins: bholley (~bholley@corp-nat.p2p.sfo1.mozilla.com)
# [00:01] * Joins: rniwa (~rniwa@17.202.43.222)
# [00:03] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [00:03] <dglazkov> these are neither nanotasks, nor microtask checkpoints
# [00:03] <dglazkov> they are simply an auto-release pool-like barrier between UA code and user code
# [00:04] <annevk> dglazkov: given mutation events you'll have to define that a lot better
# [00:04] <Hixie> so if you call an array's "sort" method with a user-code function that manipulates the DOM, do they run between each call to the sort function?
# [00:04] <Hixie> sorter function, rather?
# [00:05] * Quits: encryptd_fracta1 (~mfrawley@66-188-99-174.static.ftbg.wi.charter.com) (Quit: Leaving.)
# [00:05] <dglazkov> theoretically yes, but in practice no, because sort function itself is incapable of introducing the relevant DOM changes
# [00:06] <Hixie> why not?
# [00:06] <dglazkov> how? :)
# [00:06] <Hixie> the sort function can do anything, even opening new browsing contexts and creating new documents
# [00:06] <Hixie> it's just user code
# [00:06] * Joins: othermaciej (~mjs@17.114.216.203)
# [00:06] <Hixie> array.sort(function (a, b) { ...do whatever you want... });
# [00:06] <dglazkov> by sort function I meant Array.sort
# [00:06] <annevk> Hixie did too
# [00:07] <dglazkov> Array.sort in itself does not do any dom changes.
# [00:07] <annevk> oh I see
# [00:07] <Hixie> even if you apply it to an Element? it's a generic function, no?
# [00:07] <annevk> dglazkov: so what you're saying is that you are monkey patching methods and properties that do changes to the DOM
# [00:07] * Quits: bholley (~bholley@corp-nat.p2p.sfo1.mozilla.com) (Quit: bholley)
# [00:07] <annevk> dglazkov: to process your nanotasks or whatever you want to call them
# [00:07] <annevk> dglazkov: without defining that in detail
# [00:08] <dglazkov> in practice, there are actually only a few methods need that. See CustomElementCallbacks tag on the Blink idls: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Document.idl&q=Document.idl&sq=package:chromium&type=cs
# [00:08] <Hixie> surely if you apply JS Array.sort() to a proxy object whose user-specified internal methods ([[Get]], etc) manipulate the DOM...
# [00:09] <gsnedders> You don't even need proxies. ES5's getters/setters are enough even with the default comparator
# [00:10] <dglazkov> Hixie: it's not at all about what the proxy object does. It's what the Array.sort itself does internally. If it's applied to another object, that object will have the barriers around the things that trigger changes.
# [00:10] <Hixie> ah
# [00:10] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [00:10] <Hixie> sounds like it'd be better to define it in terms of those barriers then
# [00:10] <Hixie> rather than all user->ua code transitions
# [00:10] <dglazkov> I was actually thinking of moving this barrier thing into a separate abstraction. It's very primitively defined in the custom elements spec
# [00:10] <dglazkov> yup
# [00:11] <annevk> Yeah, you want to just define this in the relevant methods I think
# [00:11] <dglazkov> because all rendering engines actually have these types of things.
# [00:11] <annevk> We do have it, but not exposed to web content
# [00:11] <annevk> And the way it works in Gecko is similar to mutation events, which we just tried to remove
# [00:11] <dglazkov> right. And I avoided it as an exposed API in custom elements
# [00:12] <annevk> Well these callbacks are certainly exposed
# [00:12] <dglazkov> annevk: it's different from mutation events, because the callbacks are actually only invoked at a safe point
# [00:12] <dglazkov> that's the whole point of the barrier
# [00:12] <annevk> Well, you're saying they are the same as what engines have, but you saying that means they are not
# [00:13] <annevk> E.g. appendChild(node) will remove node from its parent first and then run adopt; we'd run code after the removal
# [00:13] <annevk> That would be problematic
# [00:13] <dglazkov> we
# [00:13] <annevk> I meant Gecko there
# [00:13] <dglazkov> will run the code just before appendChild method returns
# [00:13] * Quits: tantek (~tantek@192.150.22.55) (Quit: tantek)
# [00:13] <dglazkov> no problems :)
# [00:13] <annevk> Well the way this is defined is problems imo
# [00:14] <annevk> We should just patch the methods this affects to make it way more transparent
# [00:14] <dglazkov> annevk: that's not necessarily the best strategy. Every time you add a new DOM API, you'd have to patch up the spec.
# [00:15] <dglazkov> annevk: the easiest thing to do is to say -- do this for all UA code and leave UA vendors opportunities to optimize when it's certain that the callbacks won't be queued.
# [00:15] <annevk> Not if we move to a world where more is self-hosted
# [00:15] <annevk> And the lines become blurry
# [00:16] <dglazkov> sure. Then we will need this abstraction as a separate API
# [00:16] <dglazkov> it's not like the current solution closes this path
# [00:16] <annevk> Also having to know that a callback can run at the end of a method and not having it defined there is a pretty bad way to write a specification imo
# [00:17] <annevk> You have effectively changed a large set of the default library methods, without telling the people who define those methods
# [00:17] <dglazkov> how so?
# [00:18] <dglazkov> what's a default library?
# [00:20] <dglazkov> as I said before, the alternative is to create a strict dependency on all possible things that could cause DOM changes. I don't think that's much better either.
# [00:20] <Hixie> why is that not better?
# [00:20] <Hixie> i mean, ideally, this would just be in the DOM spec, no? presumably that's what we're going to do eventually
# [00:20] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [00:20] <dglazkov> because that's not an easily bound set
# [00:21] <dglazkov> what about CSSOM, Editing, Selection, etc?
# [00:21] <Hixie> what about them?
# [00:21] <Hixie> wouldn't they be defined in terms of the DOM algorithms?
# [00:21] <dglazkov> why would that matter?
# [00:22] <Hixie> well if the logic is in the DOM algorithms, that would just trigger them, i guess
# [00:22] <Hixie> i don't really understand what we're trying to do here, so my advice may not be useful
# [00:22] <dglazkov> what matters is that anytime anyone decides to invent a supplemental IDL, I'd have to be on the lookout for that spec and evaluate whether their methods need to be explicitly mentioned in the spec
# [00:22] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [00:23] <Hixie> well, they have to be on the lookout for whether they need to worry about the DOM spec, rather, but yeah
# [00:23] <Hixie> we all have to make sure we're aware of each other's work
# [00:23] * Quits: othermaciej (~mjs@17.114.216.203) (Quit: othermaciej)
# [00:24] <dglazkov> Hixie: there maybe something to that. The spec has a well-defined set of DOM manipulations that causes callbacks to enqueue
# [00:24] <Hixie> all DOM manipulations go through the DOM spec
# [00:24] <dglazkov> yup
# [00:25] <dglazkov> the only issue is when the callbacks are invoked.
# [00:25] <Hixie> so if you monkeypatch the DOM spec, any other new spec that does DOM manipulations is supported for free, right?
# [00:25] <Hixie> wait, you're calling user code here?
# [00:25] <dglazkov> the queueing, right. I already did that
# [00:25] <Hixie> in the middle of other user code?
# [00:25] <dglazkov> no
# [00:25] <annevk> dglazkov: you need to be on the lookout anyway, because you implemented this with an IDL extension
# [00:25] <Hixie> i guess i don't understand the issue here
# [00:26] <dglazkov> me neither :)
# [00:26] <annevk> dglazkov: it's better if we centralize that lookout, than do it on a per engine level
# [00:27] <annevk> Hixie: the idea is to call user code just before you return from certain method calls
# [00:27] <annevk> dglazkov: bz pointed out that you pass the mutation events problem on to JS implemented libraries
# [00:27] <Hixie> annevk: dglazkov just said that it wasn't that
# [00:27] * icaaq is now known as icaaq|afk
# [00:28] <dglazkov> annevk: I guess I want to understand what is the "mutation events problem", then. It doesn't fit my understanding of what I thought it was.
# [00:28] <annevk> dglazkov: e.g. if you appendChild() a node and then its leftView callback calls remove child and then its enteredView callback will be confused
# [00:28] <dglazkov> annevk: no, it's not
# [00:28] <dglazkov> please read the spec
# [00:29] <annevk> dglazkov: from the perspective of the JS library
# [00:29] <dglazkov> the whole notion of the queues is to ensure the consistent sequence of callbacks
# [00:29] <annevk> dglazkov: not the browser
# [00:29] <dglazkov> annevk: yes, that's exactly what I am talking about, too
# [00:29] <Hixie> why aren't we just using the mutation observers here?
# [00:29] <Hixie> it sounds rather similar...
# [00:30] <dglazkov> mutation observers are too late
# [00:30] <Hixie> too late for what?
# [00:30] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [00:30] * Quits: CYMOC (~wolfcub@77-59-135-124.dclient.hispeed.ch)
# [00:30] <dglazkov> for developers: var foobar= document.createElement("foo-bar"); foobar.doStuff();
# [00:31] <dglazkov> if you use mutation observers, doStuff will be operating on an uninitialized object.
# [00:31] <dglazkov> because createdCallback will be called at a microtask checkpoint
# [00:31] * Joins: ^esc_ (~esc-ape@77.119.132.187.wireless.dyn.drei.com)
# [00:31] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [00:31] <Hixie> sure, when you _create_ an element that's bound you need to run its constructor
# [00:31] <dglazkov> annevk: I am happy to explain the element/callback queues and how they help the JS developer keep a consistent view of the world.
# [00:32] * Quits: icaaq|afk (~icaaq@c-a19ee455.68-1076-74657210.cust.bredbandsbolaget.se) (Ping timeout: 252 seconds)
# [00:32] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [00:33] <dglazkov> annevk: the key here is that as long as JS developer listens to callbacks, their sequence is always correct. There is no inconsistent state.
# [00:33] <Hixie> well an element is only created once, right?
# [00:33] <Hixie> why is there a queue?
# [00:33] * Quits: ^esc (~esc-ape@091-141-002-135.dyn.orange.at) (Ping timeout: 252 seconds)
# [00:33] <Hixie> surely it should just be synchronous with element creation
# [00:34] <annevk> dglazkov: so I have a custom element X that has all the lifecycle callbacks
# [00:34] <dglazkov> Hixie: expand this example to when I innerHTML "<foo-bar>" and then try to query for it with querySelector
# [00:35] <Hixie> dglazkov: how is that different?
# [00:35] <annevk> dglazkov: I have two globals each with a document (A, B), X is part of B
# [00:35] <annevk> dglazkov: I then do appendChild(X) in A
# [00:35] <dglazkov> what's two globals? can you explain a bit?
# [00:36] <annevk> dglazkov: A is a document and B is <iframe>.contentDocument nested in A
# [00:36] <dglazkov> okay
# [00:37] <annevk> dglazkov: I was assuming the callbacks leftView and enteredView would invoke at that point
# [00:37] <dglazkov> it depends on where A is registered
# [00:38] <dglazkov> where X is registered, sorry :)
# [00:38] <annevk> In B
# [00:40] <annevk> If it's simpler we could first consider A and B being in the same global
# [00:41] <dglazkov> sure, let's do it
# [00:41] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 252 seconds)
# [00:43] <annevk> Okay, I figured you would take it from here, but am I correct that leftView and enteredView would be called before appendChild(X) returns?
# [00:43] <annevk> In that order?
# [00:43] * annevk has to go for a bit in 10 minutes unfortunately
# [00:44] <annevk> And then the question is if the leftView callback removes X again, how will enteredView not be confused? Will it be removed from the callback queue?
# [00:44] <annevk> dglazkov: ^
# [00:45] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
# [00:45] * Joins: karlcow (~karl@nerval.la-grange.net)
# [00:46] <dglazkov> it won't be confused, because there is an element queue, which drains all callbacks per element at the time of invocation. This ensures a consistent sequence of callbacks.
# [00:46] * Joins: tantek (~tantek@192.150.22.55)
# [00:46] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [00:47] * Joins: jeremyj (~jeremyj@17.202.51.51)
# [00:47] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [00:48] <dglazkov> so yes, just before appendChild(X) returns, X will see a sequence of callbacks. If a callback code itself enqueues another callback, that callback goes to the end of the callback queue for this element
# [00:48] <dglazkov> if you'd like, we can VC/Skype/whatevs
# [00:49] * Hixie encourages the use of archived communication methods so that other people can learn from the discussion
# [00:50] * Joins: othermaciej (~mjs@17.114.216.203)
# [00:51] <dglazkov> we can do hangout on air and post a youtube video of me struggling with a felt marker
# [00:51] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [00:51] <gsnedders> +1 for this if it involves making fun of dglazkov
# [00:55] <Hixie> well a hangout on air isn't as convenient as an irc conversation, but it's a step up from a private vc :-)
# [00:55] <annevk> dglazkov: I'll get back to you on this I guess
# [00:55] <annevk> dglazkov: I have to do something now
# [00:55] <dglazkov> annevk: no worries. I have to run, too
# [00:55] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [00:55] * Quits: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [00:56] * Joins: hoobdeebla (~hoobdeebl@ip70-190-42-239.ph.ph.cox.net)
# [00:58] * Joins: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [00:58] * Quits: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [00:59] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [00:59] * jonlee_|afk is now known as jonlee_
# [01:01] * Joins: weinig (~weinig@17.114.217.103)
# [01:02] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [01:05] * Joins: mpt (~mpt@nat/canonical/x-eoiptttgpkxsjdvn)
# [01:05] * Quits: mpt (~mpt@nat/canonical/x-eoiptttgpkxsjdvn) (Changing host)
# [01:05] * Joins: mpt (~mpt@canonical/mpt)
# [01:05] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [01:06] * heycam is now known as heycam|away
# [01:07] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [01:09] * Joins: satazor (~satazor@a213-22-1-7.cpe.netcabo.pt)
# [01:12] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Ping timeout: 248 seconds)
# [01:14] <aklein> TabAtkins: you about?
# [01:14] <aklein> TabAtkins: I've got a CSS parsing question you might know the answer to (or know if there's no answer)
# [01:14] <TabAtkins> In a bit.
# [01:16] <SimonSapin> aklein: just ask, and wait around a bit as someone may answer later
# [01:16] <TabAtkins> Also that, yes.
# [01:16] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [01:17] * Quits: othermaciej (~mjs@17.114.216.203) (Quit: othermaciej)
# [01:18] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [01:18] * gsnedders wonders if he can construct any reasonable way to get profile number of calls per JS function in his browser
# [01:19] * Joins: hasather (~hasather@80.91.33.141)
# [01:19] <gsnedders> Probably nothing short of hacking on the browser, probably without JIT for simplicity.
# [01:20] * Joins: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [01:22] * Joins: annevk_ (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [01:22] * Quits: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
# [01:24] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 252 seconds)
# [01:24] <aklein> the question is about url-resolution for url() CSS values
# [01:25] <aklein> and about when it occurs, in various cases (<style>, <link rel=stylesheet>, <div style="...">)
# [01:25] <aklein> that is, when does it occur (and where is that written down in a spec?)
# [01:27] <aklein> (Blink and WebKit seem to do very eager url resolution, while Gecko is lazier)
# [01:28] <Hixie> gsnedders: you can just instrument those methods by replacing them in script, no?
# [01:28] <Hixie> aklein: the HTML spec says for <style> that you should do it ASAP, so that if the base URL changes later, it doesn't affect the <style>'s URLs.
# [01:28] <gsnedders> Hixie: All functions, including those defined in JS.
# [01:28] <Hixie> gsnedders: well, those defined in JS you can find from any profiler, probably
# [01:29] <Hixie> most browsers have those these days, i think
# [01:29] <gsnedders> Not sure how well they cope with short-lived functions, though
# [01:29] <Hixie> "short lived"?
# [01:29] <Hixie> oh you mean you don't want a sample, you want a strict count?
# [01:29] <gsnedders> Yeah.
# [01:30] <Hixie> yeah short of instrumenting the code explicitly (which should be easy enough) i dunno how you'd do that
# [01:30] * Joins: kevin_lozandier (~KevinLoza@wireless-plus-034-046.usc.edu)
# [01:30] <Hixie> (the js code, i mean)
# [01:30] <gsnedders> Like, a set of values N_i = x where i is the number of calls the function has and x is the number of functions with that number of calls.
# [01:32] <gsnedders> Also not clear if I want things to be like V8's FunctionCode class (i.e., a FunctionExpression/FunctionDeclaration in the script) or Function class (i.e., a Function object).
# [01:32] <Hixie> what's your actual goal?
# [01:33] * Quits: hoobdeebla (~hoobdeebl@ip70-190-42-239.ph.ph.cox.net)
# [01:35] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [01:35] * Quits: kevin_lozandier (~KevinLoza@wireless-plus-034-046.usc.edu) (Quit: Leaving)
# [01:35] <gsnedders> Hypothesis: most functions are called zero times, then a lot are called one time (exactly); the remainder is roughly linear, with N_i going down as i increases.
# [01:36] <Hixie> most of which functions? any function on any site?
# [01:36] <Hixie> in what situations? page load? deep interaction?
# [01:37] <gsnedders> "In general". Per page load, obviously.
# [01:37] <Hixie> well i mean the functions that are handlers for 'onclick' handlers presumbaly only get called when you click
# [01:37] <gsnedders> All functions that the JS VM sees.
# [01:37] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Quit: Leaving...)
# [01:38] <Hixie> so is the test protocol "click everything once"?
# [01:38] <Hixie> "use the application like a noob for 5 minutes"?
# [01:38] <gsnedders> I mean, really want everything from something like "load FB, notice nothing of interest, close immediately" to "load FB, spend the next four hours talking to people on FB chat".
# [01:39] <Hixie> i would imagine they'd have rather different profiles
# [01:39] <gsnedders> I dunno. It makes me wonder if it's going to be a bell curve or something.
# [01:40] <gsnedders> But, yeah, kinda tempted to just instrument browser and use it for a few weeks. Probably get useful data.
# [01:40] <gsnedders> Though "how gsnedders uses his browser" isn't necessarily representative. :)
# [01:41] * Joins: plutoniix (~plutoniix@210.213.57.70)
# [01:43] <gsnedders> Ultimately I'm interested in the probability of the function being called a certain number of times.
# [01:44] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
# [01:46] <aklein> Hixie: can you give me a link for that behavior, I'm having trouble finding it; I wonder if some of it's in the parts delegated to the CSS OM spec
# [01:46] <aklein> (e.g., to "create a css style sheet")
# [01:46] <Hixie> aklein: it's in the <style> section, i think... let me check
# [01:48] <Hixie> aklein: ah, looks like i commented it out, expecting it to be handled by SimonSapin's CSS parsing spec
# [01:49] <Hixie> aklein: (search for "found by the styling language's processor" in the spec source)
# [01:50] <aklein> Hixie: heh, yes, that's very clear
# [01:50] * Quits: decotii (~decotii@hq.croscon.com) (Quit: Leaving)
# [01:52] <SimonSapin> aklein: http://dev.w3.org/csswg/css-values/#urls says " Relative URIs are resolved to full URIs using a base URI. For CSS style sheets, the base URI is that of the style sheet, not that of the source document."
# [01:52] <aklein> Hixie: and it looks like style attributes defer to http://dev.w3.org/csswg/css-style-attr/, which also says that urls are resolved when the attribute is parsed
# [01:52] <SimonSapin> but I’m not sure what your question is…
# [01:52] <Hixie> SimonSapin: that doesn't help for <style> style sheets
# [01:52] * Joins: othermaciej (~mjs@17.114.216.203)
# [01:53] <Hixie> aklein: yeah, but when is it parsed?
# [01:53] <Hixie> aklein: imho it should be parsed very eagerly, fwiw
# [01:53] * Joins: llkats (~llkats@206.169.83.230)
# [01:53] <aklein> Hixie: "In user agents that support CSS, the attribute's value must be parsed when the attribute is added or has its value changed"
# [01:53] <aklein> so the spec says what you want already
# [01:53] <aklein> which is good :)
# [01:53] <Hixie> k, excellent
# [01:53] <SimonSapin> Hixie: I though it obvious that the based URL was the same as for any <a href> in the document, but indeed it’s not specified
# [01:54] <Hixie> SimonSapin: the problem is that the base url in html docs can change dynamically
# [01:54] <aklein> Hixie: fwiw, Firefox seems to re-resolve URLs in style attributes when the hosting element switches documents
# [01:54] <aklein> sounds like you think that's a Firefox bug?
# [01:54] <Hixie> SimonSapin: so is it the base url when the <style> element is created? when it's parsed? later?
# [01:55] <Hixie> aklein: there was some chatter in the bug you filed on this abotu imgs talking about whether we should do that on insertion or on adoption
# [01:55] <aklein> SimonSapin: thanks for the link to that spec, I wasn't sure of the name
# [01:55] <SimonSapin> good point. Looks like a spec bug
# [01:55] <Hixie> aklein: i don't recall the conclusion, but obviously we should be consistent
# [01:55] * Quits: beowulf (~sstewart@pdpc/supporter/professional/beowulf) (Ping timeout: 245 seconds)
# [01:55] <Hixie> aklein: (assuming there's no compat constraints)
# [01:55] * jonlee_ is now known as jonlee_|afk
# [01:55] <aklein> Hixie: I'll dig up the bug again, I didn't recall whether that had mentioned style
# [01:55] <Hixie> i don't htink it mentioned style explicitly
# [01:55] <SimonSapin> Hixie: what do you think it should be?
# [01:56] <Hixie> aklein: i'm just saying that if possible, we should be consistent
# [01:56] * Quits: othermaciej (~mjs@17.114.216.203) (Client Quit)
# [01:56] <Hixie> SimonSapin: what do browsers do?
# [01:56] <aklein> Hixie: seems reasonable. would you say that <style> should also re-resolve if it switches documents?
# [01:56] <Hixie> SimonSapin: i imagine they just use the current one at parse time
# [01:56] <aklein> it's a little different in that case...
# [01:56] <aklein> because it's non-local
# [01:56] <Hixie> aklein: i think we should be consistent throughout. but for <style> i dunno if i'd say "reparse" or "reresolve"
# [01:57] <SimonSapin> TabAtkins: ^
# [01:57] <aklein> eww
# [01:57] <Hixie> aklein: do we reparse if you insert/remove/insert in the same doc?
# [01:57] * Joins: beowulf (~sstewart@host81-155-26-209.range81-155.btcentralplus.com)
# [01:57] <SimonSapin> no need to reparse even if we want to reresolve
# [01:57] <aklein> Hixie: is parsing observable?
# [01:57] <Hixie> aklein: it is if you changed the OM
# [01:57] <aklein> Hixie: right, if you hold onto the OM...whee
# [01:58] <aklein> hmm
# [01:58] <aklein> requiring reparsing seems bad
# [01:58] * Joins: decotii (~decotii@hq.croscon.com)
# [01:58] <Hixie> sure, but requirin that you hold on to the OM when the <style> is taken out of a doc might be bad too
# [01:58] <Hixie> so i could argue this either way
# [01:58] <aklein> the resolving difference between Firefox and Blink is visible via the OM, too, which is unfortunate
# [01:59] <aklein> Firefox says the value is 'url("relative/url.png")' while Blink says it's 'url("http://foo.bar/relative/url.png")'
# [01:59] <aklein> maybe that just means we have more webcompat leeway?
# [02:01] * Quits: jernoble|laptop (~jernoble@17.202.45.163) (Ping timeout: 240 seconds)
# [02:01] * Quits: decotii (~decotii@hq.croscon.com) (Client Quit)
# [02:01] * Quits: weinig (~weinig@17.114.217.103) (Quit: weinig)
# [02:01] <aklein> SimonSapin: looks like CSS Values and Units doesn't speak to the CSS OM?
# [02:02] * Quits: ap (~ap@2620:149:4:304:c1a5:887b:d1d4:164a) (Quit: ap)
# [02:02] <SimonSapin> aklein: not directly, but it talks about computed value
# [02:03] <SimonSapin> so with different API you may get specified or computed values which may differ
# [02:03] <SimonSapin> "When a <url> appears in the computed value of a property, it is resolved to an absolute URL"
# [02:05] * Joins: mven (~mven@ip72-193-85-64.lv.lv.cox.net)
# [02:05] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [02:06] * Quits: satazor (~satazor@a213-22-1-7.cpe.netcabo.pt) (Remote host closed the connection)
# [02:07] * Quits: ambv (~ambv@206.108.217.134) (Quit: sys.exit(0) # app closed)
# [02:07] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [02:08] * Joins: jernoble|laptop (~jernoble@76.74.153.49)
# [02:09] <TabAtkins> OMG DONE MINUTING
# [02:10] <TabAtkins> Okay, so anyway, I talked about this with Anne.
# [02:10] <TabAtkins> URL canonicalization (turning to absolute) needs to happen during parsing.
# [02:10] * Quits: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com) (Remote host closed the connection)
# [02:10] <TabAtkins> Absolutizing is, in fact, part of URL parsing itself.
# [02:10] <aklein> TabAtkins: so is the relative URL dropped on the floor?
# [02:11] <TabAtkins> Moving documents around to new base URLs need to be dealt with.
# [02:11] <aklein> will let you finish :)
# [02:11] <TabAtkins> aklein: Yes. You enter "url(/foo)", you immediately get back "url(http://example.com/foo)".
# [02:11] <TabAtkins> There's no way to observe it being relative.
# [02:11] <TabAtkins> Besides, maybe, .cssText, if we keep that as literal stylesheet bytes.
# [02:11] <TabAtkins> That's pre-parsing then.
# [02:12] <aklein> it sounds like you're in the "you have to re-parse if you want to re-resolve" camp
# [02:13] <TabAtkins> Not... necessarily. Parsing *the url itself* requires absolutizing; the two concepts are part and parcel.
# [02:13] <TabAtkins> Parsing *the url() function* doesn't necessarily.
# [02:13] <SimonSapin> TabAtkins: CSS parsing does not need to parse URLs immediately
# [02:13] <TabAtkins> But we all do so.
# [02:13] <SimonSapin> (maybe it should)
# [02:13] <TabAtkins> But we can certainly keep around the unparsed url and absolutize it on demand.
# [02:14] <aklein> TabAtkins: not sure who "we" is, note that I pointed out above that Firefox seems to only absolutize lazily
# [02:14] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [02:14] <TabAtkins> But "on demand" should include "when you serialize a declared value", which is the lowest-level way to observe a CSS value short of grabbing network bytes.
# [02:14] <TabAtkins> "we" there means the browser.
# [02:14] <aklein> TabAtkins: in my testing they don't do that. div.style.backgroundImage returns 'urlI("relative/img.png")'
# [02:14] <aklein> but with fewer l's
# [02:16] * Joins: ehsan (~ehsan@guest-nat.p2p.sfo1.mozilla.com)
# [02:16] <TabAtkins> We definitely absolutize early.
# [02:17] <aklein> Blink and WebKit do, yes
# [02:17] * Quits: ehsan (~ehsan@guest-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [02:17] <aklein> but it's not true that "we all do so" (not at the moment, anyway)
# [02:17] <TabAtkins> Okay, true.
# [02:18] <TabAtkins> aklein: What's the context of your question?
# [02:19] <aklein> TabAtkins: the specific case I'd like to fix is that <template><div style="background-image: url('foo/bar.png')"></div></template> is busted in Blink
# [02:19] <aklein> it ends up as url()
# [02:19] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [02:19] <TabAtkins> That's weird. Because there's nothing to absolutize it against, so it just punts?
# [02:20] <aklein> yeah
# [02:20] <aklein> my reading of the CSS Values thingy suggests that perhaps the punting is the bug
# [02:20] <aklein> and it should actually leave the relative URL there if it can't complete the URL
# [02:20] <TabAtkins> The punting is definitely the bug.
# [02:20] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [02:20] <TabAtkins> Are you talking about my blog post? Or the CSSOM Values spec?
# [02:20] * Joins: smaug_____ (~chatzilla@nat/mozilla/x-pwzzoujcxruvlcwk)
# [02:21] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [02:21] * Quits: smaug_____ (~chatzilla@nat/mozilla/x-pwzzoujcxruvlcwk) (Client Quit)
# [02:21] <aklein> TabAtkins: http://dev.w3.org/csswg/css-values/#urls
# [02:22] * Joins: smaug_____ (~chatzilla@nat/mozilla/x-mlfpbsqlbohojlxr)
# [02:22] <aklein> hmm, or maybe it was cssom, I don't see this now
# [02:22] <TabAtkins> Don't read much into that. >_< I haven't written it well yet.
# [02:22] <TabAtkins> Gonna fix.
# [02:22] <TabAtkins> It's reffing an RFC, for example.
# [02:22] <TabAtkins> Should be the URL spec.
# [02:22] <aklein> hehe
# [02:22] <aklein> ok
# [02:23] <SimonSapin> TabAtkins: both provide "absolutize an URL", and it’s up to CSS when to call it
# [02:23] * Quits: jsbell (jsbell@nat/google/x-ogrvbrbhbvgtifuw) (Quit: There's no place like home...)
# [02:23] <aklein> TabAtkins: but your considered opinion is that url() in a document with no base URL should do what?
# [02:23] <TabAtkins> But hm, so far I'm planning that "declared value" http://dev.w3.org/csswg/css-cascade/#declared gives an absolute url.
# [02:23] <TabAtkins> A document with no base URL is not something I've considered yet.
# [02:23] <TabAtkins> Is the template document the only one so far?
# [02:24] * Quits: smaug____ (~chatzilla@nat/mozilla/x-zbxgrugkwueocsqi) (Ping timeout: 252 seconds)
# [02:24] * smaug_____ is now known as smaug____
# [02:24] <SimonSapin> annevk-cloud says all documents have an URL, even if it’s one with a non-relative scheme that can not be used as a base
# [02:24] <TabAtkins> I wonder what that means?
# [02:25] <TabAtkins> What is the result of absolutizing something with a not-base URL?
# [02:25] <SimonSapin> absolutizing can fail
# [02:25] <TabAtkins> Hrm. Lemme go check his spec.
# [02:25] <aklein> TabAtkins: document.implementation.createHTMLDocument('')
# [02:26] <SimonSapin> data:text/html,<a href=foo>Test
# [02:26] <SimonSapin> anyway, the result is the same as if you didn’t have a base
# [02:27] * Quits: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net) (Ping timeout: 248 seconds)
# [02:28] <TabAtkins> Ah, and it looks like the result (at least in Chrome) is that the url is ""
# [02:29] <TabAtkins> Problem is that the URL spec has no such concept as "relative URL".
# [02:29] <TabAtkins> It's absolute, or it's nothing, or it's "a string that we haven't yet tried to parse".
# [02:30] <TabAtkins> Problem with the concept of "just hang the relative url off of it", that is. Maybe not a problem with the URL spec.
# [02:30] * heycam|away is now known as heycam
# [02:31] <TabAtkins> aklein: So it looks like Blink's current behavior of returning url() is correct.
# [02:32] <TabAtkins> aklein: And there's no way for us to do anything else.
# [02:32] <TabAtkins> aklein: Without inventing stuff.
# [02:32] <SimonSapin> TabAtkins: possibly-relative URL == string from url() or href, etc
# [02:32] <SimonSapin> absolute URL == parsed URL
# [02:33] <SimonSapin> an object, which can be serialized back to a string
# [02:33] <TabAtkins> Yeah.
# [02:33] <TabAtkins> Hm.
# [02:33] * Quits: lmclister (~lmclister@sjfw1-b.adobe.com)
# [02:33] <TabAtkins> Maybe we can define serialization of URL as "serialization of the url, or else the unparsed string if it can't be parsed".
# [02:34] <TabAtkins> That would also let us preserve nonsense urls that can't be parsed.
# [02:34] <SimonSapin> I’d say specified values should be unparsed URL, as from the stylesheet
# [02:35] <SimonSapin> for computed values serialize, but do we really need to preserve nonsense input?
# [02:37] <TabAtkins> SimonSapin: I think we should return an absolute url if we can.
# [02:37] <TabAtkins> No reason not to.
# [02:37] <TabAtkins> But we shouldn't throw away info if we can't absolutize it yet.
# [02:37] <SimonSapin> If absolutization (aka URL parsing) fails, we can’t
# [02:37] <SimonSapin> the info is still available in the specified value
# [02:38] <TabAtkins> Yes, that's what I'm saying.
# [02:38] <TabAtkins> ...I think.
# [02:39] <SimonSapin> element.style is computed values, right?
# [02:39] <TabAtkins> Nope, declared values.
# [02:39] <TabAtkins> What you smokin', bro?
# [02:39] <TabAtkins> .style is just access to the style='' stylesheet.
# [02:41] <TabAtkins> I agree that a computed url() value should take a stand on non-absolutizable urls.
# [02:41] <TabAtkins> Returning url(about:invalid).
# [02:41] <TabAtkins> (As currently defined in V&U.)
# [02:41] <SimonSapin> No interop :/ data:text/html,<body id=foo style="background:url(bar)"><script>document.write(document.getElementById('foo').style.backgroundImage)</script>
# [02:41] * Quits: jernoble|laptop (~jernoble@76.74.153.49) (Quit: Textual IRC Client: www.textualapp.com)
# [02:43] <TabAtkins> Yeah, I know that BlinKit right now absolutizes right away. (And indicates an invalid url as "url()".)
# [02:43] <TabAtkins> And FF does something different.
# [02:44] * heycam is now known as heycam|away
# [02:46] <TabAtkins> aklein: So does something like what I said sound okay? I can restate it compactly, if you want.
# [02:46] <aklein> TabAtkins: sorry, got pulled away, a compact suggestion would be great (reading scrollback now...)
# [02:47] <TabAtkins> kk, coming:
# [02:47] <TabAtkins> CSS parsing does not immediately absolutize a url.
# [02:47] <TabAtkins> At declared-value time, we try to absolutize it. If it can be absolutized, great.
# [02:47] <TabAtkins> When serializing a declared value, if it's a URL, serialize that. Otherwise, serialize the string.
# [02:48] <SimonSapin> declared, as in http://dev.w3.org/csswg/css-cascade/#declared ?
# [02:48] <TabAtkins> At computed-value time, we *need* a valid url. If it can't be absolutized, use the guaranteed-invalid url "about:invalid".
# [02:48] <TabAtkins> SimonSapin: Yes.
# [02:48] <TabAtkins> Right now we can only observe "declared", "computed", and "used" (in some cases).
# [02:48] <SimonSapin> isn’t that as soon as parsing?
# [02:49] <TabAtkins> Not... quite. Or if you think it's simpler to consider it "as soon as parsing", then make the necessary edits to what I said.
# [02:49] <TabAtkins> A <url> declared value contains either a URL or a string, depending on whether it can be absolutized or not.
# [02:50] <annevk_> So what would the specified value be?
# [02:50] * annevk_ is now known as annevk
# [02:50] <annevk> If the URL parser returns failure, using a URL that is about:invalid makes sense
# [02:50] <TabAtkins> Not sure when we go from "string or URL" to "URL". Sometime between declared and computed. The exact time is currently unobservable.
# [02:51] <SimonSapin> I don’t really want to have a thing that can be either
# [02:51] <SimonSapin> (unless we have to for web compat)
# [02:51] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [02:51] <annevk> When would you have a string?
# [02:51] <TabAtkins> annevk: aklein gave an example where we don't want to lose information (in the form of returning "url(about:invalid)") when serialziing declared values.
# [02:52] <TabAtkins> I still want to observe the given value even if the document doesn't have a base url.
# [02:52] <SimonSapin> so, counter-proposal: declared/cascaded/specified value is a string as in the input, unparsed
# [02:52] <SimonSapin> computed values is always a parsed URL, possibly about:invalid
# [02:53] <TabAtkins> That's acceptable to me too, I guess. Requires changing BlinKit.
# [02:53] <annevk> You could preserve the specified value, but also have a parsed/declared value alongside that's a URL?
# [02:53] <TabAtkins> annevk: You're mixing up terms. ^_^
# [02:53] <annevk> The terms have changed :/
# [02:53] <TabAtkins> declared -> cascaded -> specified -> computed
# [02:54] <TabAtkins> annevk: We just moved what we call "the value that you pull directly from a stylesheet". "specified" was overused for incompatible things.
# [02:55] <annevk> Oh man. Specified in my head is "the value I wrote down"
# [02:55] <TabAtkins> In the specs it's not. ^_^
# [02:55] <TabAtkins> There's stuff mixed up with inherit/initial, and the cascade.
# [02:55] <TabAtkins> I didn't want to throw away the term "specified", so I left it with one of the existing meanings.
# [02:56] <annevk> So during parsing I think for URL values you want to preserve the value the author wrote down, but also run it through the URL parser.
# [02:56] * Quits: plutoniix (~plutoniix@210.213.57.70) (Ping timeout: 265 seconds)
# [02:56] <annevk> So maybe declared needs to be a tuple
# [02:56] <TabAtkins> Do we need that?
# [02:57] <TabAtkins> Rather, why do we want a parsed URL during declared time?
# [02:57] <annevk> You need to run it through the URL parser to not be tripped by changing base URLs in HTML documents
# [02:57] <annevk> You want to keep the original value for <template>
# [02:57] <TabAtkins> Elaborate on that first one?
# [02:57] <annevk> <style> ... </style> <script> changeBaseURL() </script>
# [02:58] <annevk> Hixie's example, basically
# [02:59] <TabAtkins> Right, but what's the observable effect of resolving it in the declared value?
# [02:59] * Quits: sgalineau (~sylvaing@sjfw1.adobe.com) (Read error: Connection reset by peer)
# [02:59] <TabAtkins> I don't think the absolute url can be observed until computed-value time.
# [03:00] <TabAtkins> Even through side-effects.
# [03:00] * Joins: plutoniix (~plutoniix@210.213.57.70)
# [03:00] * Quits: beowulf (~sstewart@host81-155-26-209.range81-155.btcentralplus.com) (Quit: Lost terminal)
# [03:01] * Quits: shepazu (~shepazu@192.150.22.55) (Quit: is sleepy)
# [03:01] <annevk> TabAtkins: do you want to require that we compute sync?
# [03:01] <aklein> so after you guys figure that out, my next question is, does CSS provide some hook for DOM to call upon adoption to re-resolve URLs?
# [03:02] <annevk> aklein: not at the moment
# [03:02] <aklein> annevk: rather, should it?
# [03:02] <annevk> aklein: we don't really have it on the HTML side either
# [03:03] <aklein> annevk: no, though it seems we may end up with it (should go find that bug)
# [03:03] * Quits: arunranga (~otherarun@corp-nat.p2p.sfo1.mozilla.com) (Quit: arunranga)
# [03:03] <aklein> but I guess you don't necessarily need it to fix <template>
# [03:03] <TabAtkins> annevk: What do you mean? We can't observe the difference until we compute, and that happens at some undefined time based on style flushing.
# [03:03] <aklein> as long as you clone or import
# [03:03] <annevk> aklein: so for the baseURI bug we kind of came to the conclusion that unless things got declarative we don't need anything complicated for now
# [03:04] <annevk> TabAtkins: if the script changes the base URL, isn't it observable at what point computation happens?
# [03:05] * Joins: say2joe1 (~say2joe@209-253-225-97.ip.mcleodusa.net)
# [03:05] * Quits: say2joe (~say2joe@209-253-225-97.ip.mcleodusa.net) (Ping timeout: 248 seconds)
# [03:05] <TabAtkins> Not really. You can't observe except through computed values, and *that* triggers sync behavior.
# [03:05] * Quits: ebollens (~ebollens@wifi-131-179-14-126.host.ucla.edu) (Quit: ebollens)
# [03:05] * Quits: tantek (~tantek@192.150.22.55) (Quit: tantek)
# [03:06] <TabAtkins> That is, calling getComputedStyle does sync work.
# [03:06] <annevk> TabAtkins: yes
# [03:06] <annevk> TabAtkins: <style> url("/x") </style> and then <script> getComputed(); changeBaseURL() </script> vs <script> changeBaseURL(); getComputed(); </script>
# [03:06] <annevk> TabAtkins: they should do the same
# [03:07] <TabAtkins> No, they're observably different.
# [03:07] <TabAtkins> But now I need to go to dinner and will have to continue this later.
# [03:07] <annevk> And that would be a bug
# [03:07] <annevk> That's why URL parsing needs to happen during CSS parsing
# [03:09] <annevk> I'm very happy the CSS WG is more deeply investigating lifecycle though of style sheets
# [03:09] <aklein> annevk: the trouble in the current blink impl is that the original url is gone when instantiating the template, so it's not even possible to do the url resolution "by hand". so at the least it needs to be available somewhere
# [03:09] <annevk> aklein: I argued for storing a tuple as the "declared value" above
# [03:09] <annevk> aklein: the input and the parsed URL
# [03:09] * Joins: S234567a (~S234567a@unaffiliated/s234567a)
# [03:10] <annevk> aklein: .cssText could use the input, getComputed the latter
# [03:10] * Quits: dbaron (~dbaron@nat/mozilla/x-zxgdfzkifnhrzkpi) (Ping timeout: 245 seconds)
# [03:11] <aklein> annevk: and style attribute serialization corresponds to .cssText? (my CSSOM knowledge is....developing)
# [03:11] * Quits: S234567a (~S234567a@unaffiliated/s234567a) (Client Quit)
# [03:12] * Quits: jeremyj (~jeremyj@17.202.51.51) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [03:12] <annevk> aklein: serialization of a style attribute is .style.cssText
# [03:12] <annevk> aklein: see http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface
# [03:12] <annevk> aklein: and http://dev.w3.org/csswg/cssom/#elementcssinlinestyle
# [03:13] <aklein> that's some fancy IDL
# [03:13] <aklein> that sounds fine to me
# [03:13] <aklein> (not least because it's a minimal change to Blink; I needn't hold a URL-resolver)
# [03:14] <aklein> annevk: I'm completely with you on needing to resolve eagerly
# [03:15] <annevk> A lot of legacy there in those APIs
# [03:15] <annevk> And a lot of neglect in terms of maintenance
# [03:16] <annevk> Better now because of zcorpan
# [03:17] * Quits: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [03:27] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [03:34] * Joins: annevk (~annevk@ip-64-32-189-20.dsl.sca.megapath.net)
# [03:43] * Quits: smaug____ (~chatzilla@nat/mozilla/x-mlfpbsqlbohojlxr) (Ping timeout: 264 seconds)
# [03:43] * Quits: llkats (~llkats@206.169.83.230) (Remote host closed the connection)
# [03:50] * Krinkle|detached is now known as Krinkle
# [03:52] * jorendorff is now known as jorendorff_away
# [03:52] * Quits: 16WAAIF6N (scrollback@conference/jsconf/x-impdsasxltnxrjgo) (Remote host closed the connection)
# [03:53] * Joins: 21WAB97R0 (scrollback@conference/jsconf/x-falffvyjhpcxlebj)
# [04:00] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
# [04:05] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
# [04:06] * Quits: benv (~benv@38.104.194.126) (Quit: Computer has gone to sleep.)
# [04:14] * Quits: annevk (~annevk@ip-64-32-189-20.dsl.sca.megapath.net) (Ping timeout: 252 seconds)
# [04:18] * Joins: hasather (~hasather@80.91.33.141)
# [04:22] * Quits: 21WAB97R0 (scrollback@conference/jsconf/x-falffvyjhpcxlebj) (Remote host closed the connection)
# [04:22] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 264 seconds)
# [04:23] * Joins: 16WAAILTC (scrollback@conference/jsconf/x-crufkyxwwfrliwbw)
# [04:27] * Joins: yoshiki_ (yoshiki@nat/google/x-cvymiyipaicxnpcv)
# [04:27] * Quits: dylanlindgren (~kartstar@1.150.219.251) (Ping timeout: 265 seconds)
# [04:27] * Joins: sicking (~sicking@c-98-210-154-157.hsd1.ca.comcast.net)
# [04:28] * Joins: roc (~chatzilla@60.234.66.19)
# [04:31] * Joins: llkats (~llkats@c-67-188-8-143.hsd1.ca.comcast.net)
# [04:31] * Joins: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net)
# [04:34] * Joins: roc_ (~chatzilla@60.234.66.19)
# [04:35] * Quits: roc (~chatzilla@60.234.66.19) (Ping timeout: 245 seconds)
# [04:35] * roc_ is now known as roc
# [04:40] * Quits: Snelhest45 (~Snelhest4@gateway/tor-sasl/snelhest45) (Quit: Snelhest45)
# [04:51] * Joins: nessy (~silviapf@stargate.it.nicta.com.au)
# [04:55] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [05:01] * Joins: [[zzz]] (~zz]]@node-q3a.pool-180-180.dynamic.totbb.net)
# [05:04] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [05:05] * Quits: [[zz]] (~zz]]@node-1c7s.pool-101-108.dynamic.totbb.net) (Ping timeout: 272 seconds)
# [05:05] * Joins: lmcliste_ (~lmclister@192.150.10.203)
# [05:07] * [[zzz]] is now known as [[zz]]
# [05:07] * Quits: llkats (~llkats@c-67-188-8-143.hsd1.ca.comcast.net) (Remote host closed the connection)
# [05:09] * Joins: izhak (~izhak@31.47.116.178)
# [05:09] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net) (Ping timeout: 272 seconds)
# [05:17] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [05:18] * Quits: lmcliste_ (~lmclister@192.150.10.203) (Read error: Connection reset by peer)
# [05:18] * Joins: arunranga (~otherarun@ip-64-32-189-20.dsl.sca.megapath.net)
# [05:21] * Joins: lmcliste_ (~lmclister@sjfw1-a.adobe.com)
# [05:21] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [05:24] * Joins: hoobdeebla (~hoobdeebl@ip70-190-42-239.ph.ph.cox.net)
# [05:24] * Joins: smaug____ (~chatzilla@ip-64-32-189-20.dsl.sca.megapath.net)
# [05:27] * Joins: hasather (~hasather@80.91.33.141)
# [05:32] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 252 seconds)
# [05:34] * Quits: lmcliste_ (~lmclister@sjfw1-a.adobe.com) (Read error: Connection reset by peer)
# [05:35] * Joins: karlcow (~karl@nerval.la-grange.net)
# [05:35] * Quits: 16WAAILTC (scrollback@conference/jsconf/x-crufkyxwwfrliwbw) (Remote host closed the connection)
# [05:36] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [05:36] * Joins: 17WAAYMK5 (scrollback@conference/jsconf/x-fmgcdyshnicxywvc)
# [05:37] * Quits: say2joe1 (~say2joe@209-253-225-97.ip.mcleodusa.net) (Quit: Leaving.)
# [05:41] * Quits: gavinc (~gavin@barad-dur.carothers.name) (Quit: Konversation terminated!)
# [05:44] * Joins: newbie (~kvirc@176.201.206.171)
# [05:44] * newbie is now known as Guest71065
# [05:45] <Domenic_> where are we on nanotasks?
# [05:48] <MikeSmith> oh we have nanotasks now?
# [05:48] <MikeSmith> Domenic_: your mention is the first I've heard
# [05:48] * Joins: nessy1 (~silviapf@gw-visitor.gw.nicta.net)
# [05:48] <MikeSmith> so I assume it must be something recently added
# [05:48] <Domenic_> MikeSmith: scroll up :P. custom elements seems to have a nanotask queue used (a) inside microtask checkpoints; (b) when returnign control from C++ to script
# [05:49] <Domenic_> (b) seems weird because i was pretty sure that was what the event loop was for
# [05:49] <MikeSmith> oh custom elements..
# [05:49] * Quits: nessy (~silviapf@stargate.it.nicta.com.au) (Ping timeout: 245 seconds)
# [05:49] <MikeSmith> Domenic_: right
# [05:50] <Domenic_> of course (a) is also weird because microtasks are already a queue so why have a queue inside a queue unless you really liked Inception and wanted to implement it in your specs I guess?
# [05:50] <MikeSmith> well
# [05:51] <MikeSmith> I reckon dglazkov is the only person here who knows
# [05:51] * Joins: bzalasky (~bzalasky@c-67-188-211-46.hsd1.ca.comcast.net)
# [05:51] * MikeSmith wishes Hixie was reviewing the custom-elements spec more
# [05:52] <Domenic_> yeah there was some explanation above but i couldn't understand it so thus my "where are we on nanotasks" query. annevk-cloud seemed to be following along pretty well, maybe he could translate.
# [05:55] * Joins: tantek (~tantek@mab2036d0.tmodns.net)
# [05:56] * jorendorff_away is now known as jorendorff
# [05:59] * Krinkle is now known as Krinkle|detached
# [05:59] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
# [06:00] * Quits: hoobdeebla (~hoobdeebl@ip70-190-42-239.ph.ph.cox.net)
# [06:00] * Quits: 17WAAYMK5 (scrollback@conference/jsconf/x-fmgcdyshnicxywvc) (Remote host closed the connection)
# [06:01] * Joins: 16WAAIMHA (scrollback@conference/jsconf/x-lbfygasorfyhilxe)
# [06:01] * Quits: sicking (~sicking@c-98-210-154-157.hsd1.ca.comcast.net) (Quit: sicking)
# [06:02] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [06:07] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Ping timeout: 272 seconds)
# [06:08] * Quits: 16WAAIMHA (scrollback@conference/jsconf/x-lbfygasorfyhilxe) (Remote host closed the connection)
# [06:08] * Joins: 92AAASB28 (scrollback@conference/jsconf/x-ezcvutdjltkuvgek)
# [06:13] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [06:17] * Joins: llkats (~llkats@c-67-188-8-143.hsd1.ca.comcast.net)
# [06:17] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [06:18] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 272 seconds)
# [06:19] * Krinkle|detached is now known as Krinkle
# [06:22] * Joins: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net)
# [06:22] * Quits: llkats (~llkats@c-67-188-8-143.hsd1.ca.comcast.net) (Ping timeout: 272 seconds)
# [06:25] * Quits: bzalasky (~bzalasky@c-67-188-211-46.hsd1.ca.comcast.net) (Remote host closed the connection)
# [06:28] * Joins: hasather (~hasather@80.91.33.141)
# [06:28] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [06:29] * Joins: dylanlindgren (~kartstar@110.151.218.218)
# [06:31] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [06:32] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 245 seconds)
# [06:36] * Quits: Guest71065 (~kvirc@176.201.206.171) (Ping timeout: 264 seconds)
# [06:39] * Joins: icaaq (~icaaq@c-a19ee455.68-1076-74657210.cust.bredbandsbolaget.se)
# [06:40] * icaaq is now known as icaaq|afk
# [06:41] <smaug____> oh, nanotasks
# [06:41] <smaug____> annevk-cloud, could you please explain to me tomorrow why we need such things
# [06:44] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [06:45] * Quits: icaaq|afk (~icaaq@c-a19ee455.68-1076-74657210.cust.bredbandsbolaget.se) (Ping timeout: 272 seconds)
# [06:46] * Quits: smaug____ (~chatzilla@ip-64-32-189-20.dsl.sca.megapath.net) (Ping timeout: 264 seconds)
# [06:46] * Joins: bzalasky (~bzalasky@c-67-188-211-46.hsd1.ca.comcast.net)
# [06:47] <zewt> to pave the way towards picotasks, duh
# [06:48] <zewt> no doubt followed by 2^(-n)tasks
# [06:50] * Quits: roc (~chatzilla@60.234.66.19) (Ping timeout: 252 seconds)
# [06:57] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [06:59] * Quits: tantek (~tantek@mab2036d0.tmodns.net) (Quit: tantek)
# [07:03] * Quits: dylanlindgren (~kartstar@110.151.218.218) (Quit: Textual IRC Client: www.textualapp.com)
# [07:05] * Quits: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net) (Quit: Computer has gone to sleep.)
# [07:06] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [07:07] * Quits: arunranga (~otherarun@ip-64-32-189-20.dsl.sca.megapath.net) (Ping timeout: 272 seconds)
# [07:10] * Joins: icaaq (~icaaq@c-a19ee455.68-1076-74657210.cust.bredbandsbolaget.se)
# [07:10] <hsivonen> SimonSapin: I think it makes sense to reduce the CSS @charset search buffer size, yes. How much depends mainly on whether the ban on whitespace inside the quotes sticks.
# [07:11] * icaaq is now known as icaaq|afk
# [07:13] * Quits: icaaq|afk (~icaaq@c-a19ee455.68-1076-74657210.cust.bredbandsbolaget.se) (Read error: Connection reset by peer)
# [07:14] * Joins: icaaq (~icaaq@c-a19ee455.68-1076-74657210.cust.bredbandsbolaget.se)
# [07:15] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [07:17] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [07:18] * Joins: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net)
# [07:25] * Joins: niloy (~niloy@223.239.205.220)
# [07:25] * Joins: weinig (~weinig@24.130.60.35)
# [07:28] * Joins: jeffreyatw (~jeffreyat@199-188-192-239.PUBLIC.monkeybrains.net)
# [07:29] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [07:31] * Joins: dbaron (~dbaron@nat/mozilla/x-vrqovgdtzaugsxjq)
# [07:35] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [07:37] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [07:45] <SimonSapin> hsivonen: browsers apparently do trim whitespace, and we fixed the spec
# [07:45] <SimonSapin> banning whitespace was accidental
# [07:53] <zcorpan> so when are mutation events going to be removed?
# [07:57] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
# [07:58] * Quits: nessy1 (~silviapf@gw-visitor.gw.nicta.net) (Quit: Leaving.)
# [07:59] * Quits: jeffreyatw (~jeffreyat@199-188-192-239.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
# [07:59] * Joins: tantek (~tantek@mab2036d0.tmodns.net)
# [08:01] <zcorpan> https://github.com/inverts/Data-Tamers/blob/4c8599fd293c84216f161608b08ae1c85532fc25/AppliedAnalytics/src/main/webapp/resources/cache/css/site.css#L1
# [08:02] <zcorpan> https://github.com/blazedev/simbud/blob/34412f7ba14b4fb7f3d89ac0565b4a6cde37f00d/frontend/app/bower_components/angular/angular-csp.css
# [08:04] * Quits: tantek (~tantek@mab2036d0.tmodns.net) (Ping timeout: 252 seconds)
# [08:04] * Quits: icaaq (~icaaq@c-a19ee455.68-1076-74657210.cust.bredbandsbolaget.se) (Ping timeout: 272 seconds)
# [08:05] <zcorpan> uppercase and comment first are the only mistakes in the first 10 pages of results for "charset" in css on github (sorting by recently indexed)
# [08:06] <zcorpan> does someone have a dataset of external CSS files?
# [08:10] * Quits: miketaylr (~miketaylr@192.241.222.35) (Ping timeout: 276 seconds)
# [08:13] * Quits: 92AAASB28 (scrollback@conference/jsconf/x-ezcvutdjltkuvgek) (Remote host closed the connection)
# [08:13] * Joins: 14WABYC5Y (scrollback@conference/jsconf/x-kpcqqwcbrczskoum)
# [08:18] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Quit: leaving)
# [08:18] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
# [08:19] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [08:20] * Quits: dbaron (~dbaron@nat/mozilla/x-vrqovgdtzaugsxjq) (Ping timeout: 265 seconds)
# [08:22] * Joins: icaaq (~icaaq@c-5eeaaa27-74736162.cust.telenor.se)
# [08:27] * Quits: 14WABYC5Y (scrollback@conference/jsconf/x-kpcqqwcbrczskoum) (Remote host closed the connection)
# [08:28] * Joins: 92AAASC37 (scrollback@conference/jsconf/x-nltbbhpoxwyecwrw)
# [08:29] * Joins: hasather (~hasather@80.91.33.141)
# [08:33] * Quits: plutoniix (~plutoniix@210.213.57.70) (Ping timeout: 248 seconds)
# [08:33] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [08:34] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 252 seconds)
# [08:38] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Quit: leaving)
# [08:38] * Quits: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net) (Quit: Computer has gone to sleep.)
# [08:39] * Joins: miketaylr (~miketaylr@192.241.222.35)
# [08:40] * Quits: weinig (~weinig@24.130.60.35) (Quit: weinig)
# [08:41] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
# [08:44] * Joins: plutoniix (~plutoniix@210.213.57.70)
# [08:46] * Joins: nessy (~silviapf@101.164.144.53)
# [08:48] * Quits: nessy (~silviapf@101.164.144.53) (Client Quit)
# [08:49] * Quits: dshwang_ (~dshwang@192.55.55.41) (Ping timeout: 260 seconds)
# [08:51] * Joins: dshwang_ (dshwang@nat/intel/x-njrtpsbsmwwvkexv)
# [08:59] * Quits: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net) (Quit: Computer has gone to sleep.)
# [09:02] * Joins: Martin1982 (~Martin198@cable-175-208.zeelandnet.nl)
# [09:03] * Krinkle is now known as Krinkle|detached
# [09:04] * Quits: plutoniix (~plutoniix@210.213.57.70) (Quit: จรลี จรลา)
# [09:15] * Joins: charl_ (~charl@2001:67c:2564:524:c002:7d5e:f45c:cc2f)
# [09:16] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Quit: jdaggett)
# [09:16] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [09:16] * Joins: darobin (~darobin@78.208.93.24)
# [09:16] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
# [09:16] * Joins: Ms2ger (~Ms2ger@204.250-64-87.adsl-dyn.isp.belgacom.be)
# [09:16] <hsivonen> SimonSapin: if white space trimming stays, then I have no good way of suggesting a number other than 1024 (which is intuitively rather high but at least is what Gecko already does).
# [09:18] * jorendorff is now known as jorendorff_away
# [09:20] * Joins: plutoniix (~plutoniix@210.213.57.70)
# [09:20] <Martin1982> I was wondering if there are any community people here as well who'd want to submit to http://www.mobileconference.nl to speak at the DMC14?
# [09:23] * jorendorff_away is now known as jorendorff
# [09:29] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [09:32] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
# [09:32] * jorendorff is now known as jorendorff_away
# [09:47] * Quits: icaaq (~icaaq@c-5eeaaa27-74736162.cust.telenor.se) (Ping timeout: 252 seconds)
# [09:49] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [09:53] * Joins: hasather (~hasather@80.91.33.141)
# [09:59] * Joins: icaaq (~icaaq@c-5eeaaa27-74736162.cust.telenor.se)
# [10:04] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
# [10:11] * Quits: darobin (~darobin@78.208.93.24) (Remote host closed the connection)
# [10:18] * Quits: icaaq (~icaaq@c-5eeaaa27-74736162.cust.telenor.se) (Ping timeout: 248 seconds)
# [10:19] * Joins: darobin (~darobin@2a01:e34:ed05:d180:b808:cbb8:67f5:99e0)
# [10:20] * Joins: icaaq (~icaaq@94.234.170.39)
# [10:21] * Joins: beowulf (~sstewart@host81-155-26-209.range81-155.btcentralplus.com)
# [10:23] * Joins: S234567a (~S234567a@unaffiliated/s234567a)
# [10:29] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
# [10:32] * Joins: tomasf (~tomasf@77.72.97.10.c.fiberdirekt.net)
# [10:33] * Quits: S234567a (~S234567a@unaffiliated/s234567a)
# [10:33] * Quits: tomasf (~tomasf@77.72.97.10.c.fiberdirekt.net) (Client Quit)
# [10:41] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [10:42] * Quits: marcosc (~marcosc@bl7-116-81.dsl.telepac.pt) (Remote host closed the connection)
# [10:44] * Joins: cheron (~cheron@unaffiliated/cheron)
# [10:45] * Joins: jim0thy_ (~jim0thy_@212.113.198.34)
# [10:47] * Quits: jim0thy_ (~jim0thy_@212.113.198.34) (Client Quit)
# [10:48] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [10:49] * Quits: bzalasky (~bzalasky@c-67-188-211-46.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [10:49] * Joins: bzalasky (~bzalasky@c-67-188-211-46.hsd1.ca.comcast.net)
# [10:52] * Quits: icaaq (~icaaq@94.234.170.39) (Ping timeout: 245 seconds)
# [10:52] * Joins: icaaq (~icaaq@94.234.170.39)
# [10:53] * Joins: Lachy (~Lachy@213.166.174.2)
# [10:54] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [10:56] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Client Quit)
# [10:56] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [10:57] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [11:00] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
# [11:04] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: hoot hoot)
# [11:06] * Quits: charl_ (~charl@2001:67c:2564:524:c002:7d5e:f45c:cc2f) (Quit: leaving)
# [11:16] * Quits: darobin (~darobin@2a01:e34:ed05:d180:b808:cbb8:67f5:99e0) (Remote host closed the connection)
# [11:21] * Quits: beowulf (~sstewart@host81-155-26-209.range81-155.btcentralplus.com) (Changing host)
# [11:21] * Joins: beowulf (~sstewart@pdpc/supporter/professional/beowulf)
# [11:24] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [11:26] * Joins: richt (~richt@node-cidxz8ezchgiah.20.ipv6.opera.com)
# [11:26] * Joins: Areks (~Areks@rs.gridnine.com)
# [11:30] * Joins: S234567a (~S234567a@unaffiliated/s234567a)
# [11:32] * Quits: S234567a (~S234567a@unaffiliated/s234567a) (Client Quit)
# [11:51] * Joins: felipeduardo (~felipedua@r253-pw-corumbatai.ibys.com.br)
# [11:52] * Quits: plutoniix (~plutoniix@210.213.57.70) (Quit: จรลี จรลา)
# [11:55] <jgraham> gsnedders: Pretty sure the MS paper from a few years ago looked at that kind of thing
# [12:17] * Quits: icaaq (~icaaq@94.234.170.39) (Ping timeout: 272 seconds)
# [12:20] <zcorpan> Ms2ger: this status box looks misplaced? http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#text-0
# [12:20] * Joins: darobin (~darobin@78.109.80.74)
# [12:22] <zcorpan> looking at the syntax section, i wonder if it's time to lift the ban on -- in comments
# [12:25] * zcorpan files a bug
# [12:29] * Quits: 92AAASC37 (scrollback@conference/jsconf/x-nltbbhpoxwyecwrw) (Remote host closed the connection)
# [12:29] * Joins: 17WAAYPU6 (scrollback@conference/jsconf/x-arnwqkegdvgzcfnw)
# [12:33] <Ms2ger> Heh, that's a nice old link
# [12:34] <Ms2ger> Surely it shouldn't be too hard to get the wpt tests into those boxes
# [12:39] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [12:40] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [12:41] * Joins: adactio (~adactio@212.42.170.181)
# [12:44] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [12:44] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [12:45] * Quits: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de) (Ping timeout: 260 seconds)
# [12:46] * Quits: dshwang_ (dshwang@nat/intel/x-njrtpsbsmwwvkexv) (Remote host closed the connection)
# [12:46] * Joins: dshwang_ (~dshwang@192.55.55.41)
# [12:47] * Joins: icaaq (~icaaq@94.137.124.2)
# [12:48] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [12:52] * Joins: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de)
# [12:53] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Quit: Leaving.)
# [13:17] * Quits: Lachy (~Lachy@213.166.174.2) (Read error: Connection reset by peer)
# [13:17] * Joins: Lachy (~Lachy@213.166.174.2)
# [13:18] * Joins: bhanu__ (0e8d5b14@gateway/web/freenode/ip.14.141.91.20)
# [13:25] * Joins: Smylers (~smylers@81.143.60.194)
# [13:38] * Joins: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net)
# [13:38] * Quits: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net) (Client Quit)
# [13:46] * Joins: Snelhest45 (~Snelhest4@gateway/tor-sasl/snelhest45)
# [13:50] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Quit: Ex-Chat)
# [13:54] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [14:06] * icaaq is now known as icaaq|afk
# [14:08] * icaaq|afk is now known as icaaq
# [14:12] * Joins: gavinc (~gavin@barad-dur.carothers.name)
# [14:13] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [14:14] * zcorpan brings http://html5.org/tools/web-apps-tracker?from=8432&to=8433 to MikeSmith and hsivonen's attention
# [14:18] <jgraham> Anyone got a nice example of a bug in either blink or firefox that can be demoed in a few lines of code?
# [14:19] * Quits: icaaq (~icaaq@94.137.124.2) (Ping timeout: 260 seconds)
# [14:20] * Joins: icaaq (~icaaq@94.137.124.2)
# [14:21] * Quits: 17WAAYPU6 (scrollback@conference/jsconf/x-arnwqkegdvgzcfnw) (Remote host closed the connection)
# [14:21] * Joins: 14WABYGRW (scrollback@conference/jsconf/x-imjeznkddbuaqsqb)
# [14:21] <zcorpan> what kind of bug?
# [14:22] <jgraham> Any kind
# [14:22] <jgraham> Well something you could write a test for
# [14:23] <jgraham> I can find something from the testsuite I guess
# [14:24] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [14:26] <Ms2ger> In blink?
# [14:26] <Ms2ger> Blob()
# [14:26] <Ms2ger> (throws where it shouldn't)
# [14:30] * Joins: tj_vantoll (~Adium@c-68-84-189-15.hsd1.mi.comcast.net)
# [14:35] * Joins: darobin_ (~darobin@78.109.80.74)
# [14:35] * Quits: darobin (~darobin@78.109.80.74) (Read error: Connection reset by peer)
# [14:37] <jgraham> Oh, that's quite a reasonable example
# [14:37] <jgraham> I would slightly prefer a bug in Firefox I think
# [14:38] <Ms2ger> Blob()
# [14:38] <Ms2ger> (constructs a Blob while annevk thinks it shouldn't)
# [14:39] <jgraham> heh. I can't cite annevk as a spec
# [14:40] <darobin_> jgraham: I'm sure there's precedent
# [14:40] * darobin_ is now known as darobin
# [14:40] <jgraham> (not sure why we want WebIDL to be different to half of the javascript stdlib here)
# [14:40] <Ms2ger> I had one in the FileReader stuff...
# [14:40] * Parts: FireFly (~firefly@oftn/member/FireFly) ("WeeChat 0.4.0")
# [14:42] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [14:42] <Ms2ger> (new FileReader()).abort();
# [14:42] <Ms2ger> Throws in Gecko, but shouldn't
# [14:42] <Ms2ger> jgraham, ^
# [14:43] <gsnedders> jgraham: Yeah, it did. But that data is several years out of date. Usage of JS is changing pretty quickly.
# [14:44] * Joins: jensnockert_ (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [14:44] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Ping timeout: 260 seconds)
# [14:44] <gsnedders> jgraham: Sadly, I can't remember which MSR paper it was in :)
# [14:45] * anssik_ is now known as anssik
# [14:46] * Joins: decotii (~decotii@hq.croscon.com)
# [14:48] <jgraham> gsnedders: Nor can I, but I think you should start with that paper anyway
# [14:48] * Quits: niloy (~niloy@223.239.205.220) (Quit: Leaving)
# [14:49] <zcorpan> jgraham: document.createElement('image') instanceof HTMLUnknownElement
# [14:50] <jgraham> http://research.microsoft.com/en-us/um/people/livshits/papers%5Cpdf%5Cwebapps10b.pdf
# [14:50] <jgraham> zcorpan: I think I will use the FileReader one
# [14:50] <Ms2ger> zcorpan, blink bug
# [14:51] <gsnedders> https://research.microsoft.com/pubs/115734/aitypes.pdf --- is it just me or is there nothing novel in that paper?
# [14:51] <zcorpan> Ms2ger: blink gives true for me which matches the spec afaict
# [14:51] <gsnedders> (I presume I'm just missing what makes it novel)
# [14:52] <Ms2ger> Oh?
# [14:52] * Joins: krawchyk (~krawchyk@65.220.49.251)
# [14:52] <Ms2ger> Firefox should be true too...
# [14:53] <jgraham> If only we had a testsuite to verify these things… ;)
# [14:53] <Ms2ger> I think we do
# [14:53] <zcorpan> i get HTMLElement in gecko (nightly from 2014-01-14)
# [14:54] <Ms2ger> Hrm
# [14:54] <gsnedders> jgraham: That paper only shows that 50-70% of functions are called zero times, makes no statement about functions called once.
# [14:54] <Ms2ger> But yes, html/semantics/interfaces.html and html/editing/dnd/the-draggable-attribute/draggable_attribute.html test it
# [14:55] * Quits: bhanu__ (0e8d5b14@gateway/web/freenode/ip.14.141.91.20) (Quit: Page closed)
# [14:55] <Ms2ger> Oh, the latter doesn't use it
# [14:55] <Ms2ger> Anyway
# [14:55] <jgraham> gsnedders: I thought there was a longer paper too. But anyway don't complain at me for helping you with your background reading :p
# [14:56] <gsnedders> jgraham: But I have to complain at you! It's what I do!
# [14:56] * Joins: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com)
# [14:56] <Ms2ger> You could complain at zcorpan?
# [14:57] <gsnedders> Ms2ger: Nah, I always complained at jgraham.
# [14:57] <Ms2ger> So you only glared at zcorpan?
# [14:57] <zcorpan> he still does
# [14:58] <Ms2ger> Have we removed HTMLBaseFontElement from the spec yet?
# [14:58] <Ms2ger> Apparently not
# [14:58] <gsnedders> https://research.microsoft.com/pubs/115687/paper.pdf seems to be the longer thing that the paper jgraham linked me to summarizes.
# [15:05] * Joins: TallTed (~Thud@63.119.36.36)
# [15:05] * Joins: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net)
# [15:07] * Quits: jensnockert_ (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Remote host closed the connection)
# [15:09] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [15:09] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Remote host closed the connection)
# [15:09] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [15:13] * Quits: 14WABYGRW (scrollback@conference/jsconf/x-imjeznkddbuaqsqb) (Remote host closed the connection)
# [15:14] * Joins: 45PAA8WHV (scrollback@conference/jsconf/x-asfdbtkhubomyscx)
# [15:14] * Quits: 45PAA8WHV (scrollback@conference/jsconf/x-asfdbtkhubomyscx) (Remote host closed the connection)
# [15:15] * Joins: 45PAA8WH6 (scrollback@conference/jsconf/x-uzmwpyegqmwksvmr)
# [15:16] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
# [15:20] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Remote host closed the connection)
# [15:24] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [15:24] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Remote host closed the connection)
# [15:25] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [15:45] * Joins: charl_ (~charl@2001:67c:2564:524:49dd:342:b4fe:3be7)
# [15:51] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Remote host closed the connection)
# [15:55] <jgraham> mathiasbynens: Are you planning to finish the review of https://critic.hoppipolla.co.uk/r/56 ?
# [15:58] <mathiasbynens> jgraham: new to Critic, sorry – what do I need to do? review the new changes?
# [15:58] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Quit: Leaving.)
# [15:59] <jgraham> mathiasbynens: Yes
# [15:59] <jgraham> https://critic.hoppipolla.co.uk/showcommit?review=56&filter=pending
# [15:59] <Ms2ger> "Your work here is done!"?
# [16:00] <jgraham> "Ms2ger watches workers/"
# [16:00] * Quits: Martin1982 (~Martin198@cable-175-208.zeelandnet.nl) (Ping timeout: 240 seconds)
# [16:00] <Ms2ger> "mathiasbynens watches Workers/"
# [16:00] <jgraham> Oh
# [16:00] <jgraham> But also mathiasbynens reviews /
# [16:00] * Joins: encryptd_fracta1 (~mfrawley@66-188-99-174.static.ftbg.wi.charter.com)
# [16:01] * Ms2ger unwatches
# [16:02] <jgraham> Critic seems confused
# [16:02] <jgraham> Let me kick it
# [16:04] <jgraham> mathiasbynens: You should be able to review now :)
# [16:04] <mathiasbynens> jgraham: moar work! thanks
# [16:07] * zcorpan was just about to ping mathiasbynens about that
# [16:08] <mathiasbynens> is there a way to have Critic send an email whenever someone responds to a review i made?
# [16:08] <zcorpan> doesn't it already?
# [16:09] <mathiasbynens> nope. `email.activated` is enabled, though
# [16:10] <jgraham> mathiasbynens: You didn't tell it your email address though :)
# [16:10] <jgraham> See the "home" page
# [16:10] * Joins: jensnockert (~jensnocke@dynamic.1.22.64e950153c80.e0f8471ae7fa.afb.bredband2.com)
# [16:11] <mathiasbynens> jgraham: thanks, i was looking through settings instead
# [16:12] <jgraham> mathiasbynens: A reasonable approach
# [16:12] <jgraham> But wrong ;)
# [16:14] * Joins: annevk (~annevk@ip-64-32-189-20.dsl.sca.megapath.net)
# [16:17] <zcorpan> not sure if the new File test made chrome crash
# [16:18] <jgraham> But if it did you get a badge
# [16:22] <zcorpan> mathiasbynens: refresh
# [16:27] * Quits: annevk (~annevk@ip-64-32-189-20.dsl.sca.megapath.net) (Remote host closed the connection)
# [16:31] * Quits: charl_ (~charl@2001:67c:2564:524:49dd:342:b4fe:3be7) (Quit: leaving)
# [16:31] <jgraham> mathiasbynens++
# [16:31] <jgraham> also zcorpan++ ofc
# [16:33] <zcorpan> ok merged, now fix the browsers
# [16:34] <jgraham> Hehe
# [16:35] * Joins: smaug____ (~chatzilla@guest-nat.p2p.sfo1.mozilla.com)
# [16:38] <zcorpan> sigh, the Workers directory had been renamed
# [16:38] <zcorpan> oh well
# [16:39] <jgraham> Why did it get renamed?
# [16:39] <jgraham> Oh since r/56 seems quite likely I guess
# [16:39] <zcorpan> to match TR names or some such i think
# [16:40] <zcorpan> thanks mathiasbynens
# [16:40] <zcorpan> now work time is up for today :-)
# [16:40] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [16:40] <jgraham> Yeah, that's the general naming scheme
# [16:40] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [16:41] * Joins: newtron (~newtron@69-165-159-76.dsl.teksavvy.com)
# [16:43] * Quits: smaug____ (~chatzilla@guest-nat.p2p.sfo1.mozilla.com) (Ping timeout: 252 seconds)
# [16:48] * Quits: darobin (~darobin@78.109.80.74) (Remote host closed the connection)
# [16:50] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
# [16:50] * Joins: darobin (~darobin@78.109.80.74)
# [16:50] <annevk-cloud> Blob() should throw without new
# [16:51] * Quits: darobin (~darobin@78.109.80.74) (Remote host closed the connection)
# [16:51] <annevk-cloud> See ES6
# [16:52] <jgraham> Does ES6 also make Array() throw without new?
# [16:55] <annevk-cloud> Not sure
# [16:56] <annevk-cloud> It's unclear how compatible subclassing is per Waldo, but if it is we ought to make it work on our side
# [16:56] * Joins: smaug____ (~chatzilla@nat/mozilla/x-vpfsnihiyelanwrt)
# [16:56] <jgraham> Well if it breaks Image() and Array() and Blob() and so on it is surely incompatible
# [16:57] * Quits: mven (~mven@ip72-193-85-64.lv.lv.cox.net) (Remote host closed the connection)
# [16:58] * Quits: jensnockert (~jensnocke@dynamic.1.22.64e950153c80.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [16:59] * Joins: jensnockert (~jensnocke@dynamic.1.22.64e950153c80.e0f8471ae7fa.afb.bredband2.com)
# [17:03] * Quits: jensnockert (~jensnocke@dynamic.1.22.64e950153c80.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 245 seconds)
# [17:11] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [17:14] * Joins: ebollens (~ebollens@98.159.89.142)
# [17:16] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 260 seconds)
# [17:17] * Joins: jernoble|laptop (~jernoble@76.74.153.41)
# [17:18] * Quits: 45PAA8WH6 (scrollback@conference/jsconf/x-uzmwpyegqmwksvmr) (Remote host closed the connection)
# [17:18] * Joins: 16WAAISS3 (scrollback@conference/jsconf/x-rcksfukjjguvezsv)
# [17:24] * Joins: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net)
# [17:25] * Quits: newtron (~newtron@69-165-159-76.dsl.teksavvy.com) (Remote host closed the connection)
# [17:26] * Joins: newtron (~newtron@69-165-159-76.dsl.teksavvy.com)
# [17:27] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [17:31] * Quits: newtron (~newtron@69-165-159-76.dsl.teksavvy.com) (Ping timeout: 272 seconds)
# [17:32] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Ping timeout: 260 seconds)
# [17:34] * icaaq is now known as icaaq|afk
# [17:37] * Quits: 16WAAISS3 (scrollback@conference/jsconf/x-rcksfukjjguvezsv) (Remote host closed the connection)
# [17:38] * Joins: 6JTAA32DJ (scrollback@conference/jsconf/x-uruftyczbytyqihq)
# [17:39] * Quits: icaaq|afk (~icaaq@94.137.124.2) (Ping timeout: 260 seconds)
# [17:43] * Quits: 6JTAA32DJ (scrollback@conference/jsconf/x-uruftyczbytyqihq) (Remote host closed the connection)
# [17:43] <Domenic_> ES6 legacy classes are not changed to throw
# [17:43] <Domenic_> but new classes throw
# [17:43] * Joins: scrollback1 (scrollback@conference/jsconf/x-zgayypqjdkllhhnd)
# [17:43] <Domenic_> Allen explained this on list a while back lemme find the link
# [17:44] <Ms2ger> So why should legacy DOM classes change?
# [17:44] <Domenic_> unclear
# [17:45] <Domenic_> if users can compatibly not use `new` cross browser then they probably shouldn't
# [17:45] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [17:45] <Domenic_> but if browsers disagree on this point it's an opportunity to move to the newer semantics
# [17:46] <Domenic_> it's this message http://esdiscuss.org/topic/should-the-default-constructor-return-the-return-value-of-super#content-6 although the first half of it is relevant to the post it's replying to; the second half is the more general guidance
# [17:46] * Quits: scrollback1 (scrollback@conference/jsconf/x-zgayypqjdkllhhnd) (Remote host closed the connection)
# [17:46] <jgraham> (pun intended)?
# [17:46] <jgraham> In any case this seems pretty dumb
# [17:46] <jgraham> Since it bakes inconsistency into the language
# [17:46] * Joins: 14WABYJBT (scrollback@conference/jsconf/x-sfkznwgodcnumpjx)
# [17:46] <Domenic_> i kind of agree
# [17:47] <Domenic_> the alternative though is making subclassing very hard to get right for all classes ever
# [17:47] <Domenic_> in order to preserve consistency with legacy Array, Date, RegExp
# [17:47] * Joins: Mentioum (~Mentioum@onwHAcoreFw1.2i3.net)
# [17:48] <jgraham> And all of DOM
# [17:48] * Joins: lmclister (~lmclister@sjfw1-b.adobe.com)
# [17:49] <Domenic_> cross browser?
# [17:50] <Domenic_> DOM has so few constructors anyway @_@
# [17:50] <jgraham> I'm pretty sure that there are at least some that work cross browser
# [17:52] <annevk-cloud> Chrome throws for most
# [17:52] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Remote host closed the connection)
# [17:52] <annevk-cloud> I talked with bz the other day and we have a plan
# [17:52] <Ms2ger> Plans are good
# [17:52] <Ms2ger> I guess
# [17:52] <annevk-cloud> Biggest problem is our testsuite
# [17:52] <jgraham> That sounds unlikely
# [17:53] <jgraham> I mean it makes bz's life suck because he has to fix the tests
# [17:53] <annevk-cloud> In terms of executing the plan it is
# [17:53] <jgraham> But it isn't an actual compat issue
# [17:53] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [17:54] <annevk-cloud> Domenic_: more than ES though ;)
# [17:54] * Joins: Adawerk (~ada@169.241.49.57)
# [17:57] * Joins: satazor (~satazor@bl17-129-135.dsl.telepac.pt)
# [17:57] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
# [17:57] * Joins: weinig (~weinig@17.202.49.115)
# [17:58] <TabAtkins> annevk-cloud: Back to the convo from last night. I don't see how/why you're saying that "getComputed(); changeBaseURL();" should be give the same results as "changeBaseURL(); getComputed();". Calling gCS compatibly forces a sync style flush + layout, so resolving url()s will also happen syncly.
# [17:58] * Joins: jeffreyatw (~jeffreyat@199-188-192-239.PUBLIC.monkeybrains.net)
# [17:58] * SpiritDrift is now known as pamer
# [17:58] <TabAtkins> So before/after changing the base url, you'll see different computed values for url()s.
# [17:59] * jonlee_|afk is now known as jonlee_
# [17:59] * Quits: richt (~richt@node-cidxz8ezchgiah.20.ipv6.opera.com) (Remote host closed the connection)
# [18:00] * Joins: sgalineau (~sylvaing@192.150.22.5)
# [18:01] * Joins: icaaq (~icaaq@94.234.170.47)
# [18:04] * heycam|away is now known as heycam
# [18:05] * Joins: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [18:06] <annevk> TabAtkins: because that would be incompatible with what is happening today and would make fetching images racy
# [18:06] <annevk> TabAtkins: once the style sheet is parsed the browser should be able to start fetching happens
# [18:06] <annevk> TabAtkins: so that requires the URL to be parsed
# [18:06] * Joins: scor (scor@drupal.org/user/52142/view)
# [18:07] <annevk> s/happens//
# [18:07] <TabAtkins> I don't understand what about this is "incompatibfle with what is happening today". To the best of my knowledge, I'm describing reality.
# [18:07] <TabAtkins> Ah, but yeah, allowing preloading does require you to try and parse the url immediately.
# [18:08] <TabAtkins> (But that doesn't have any effect on what I said. And yes, it is racy.)
# [18:08] * Quits: satazor (~satazor@bl17-129-135.dsl.telepac.pt) (Remote host closed the connection)
# [18:08] * Joins: satazor (~satazor@bl17-129-135.dsl.telepac.pt)
# [18:08] * Quits: hasather (~hasather@80.91.33.141) (Read error: Connection reset by peer)
# [18:09] * Joins: hasather (~hasather@80.91.33.141)
# [18:09] * Joins: hasather_ (~hasather@guest.schibsted.no)
# [18:10] <annevk> You can say things but you are wrong
# [18:10] * Quits: sgalineau (~sylvaing@192.150.22.5) (Remote host closed the connection)
# [18:10] <annevk> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2782
# [18:10] * Joins: Maurice (~copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
# [18:10] <annevk> (Sorry for that, got a bit annoyed I have to demonstrate how CSS works.)
# [18:11] * Joins: dbaron (~dbaron@nat/mozilla/x-ssalwatahtdbbjkw)
# [18:12] * Quits: hasather (~hasather@80.91.33.141) (Read error: Operation timed out)
# [18:12] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [18:12] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
# [18:12] * Quits: weinig (~weinig@17.202.49.115) (Quit: weinig)
# [18:13] * Quits: satazor (~satazor@bl17-129-135.dsl.telepac.pt) (Ping timeout: 245 seconds)
# [18:13] <TabAtkins> Jeezus, Chrome's behavior there is just idiotic.
# [18:13] * Joins: sgalineau (~sylvaing@192.150.10.203)
# [18:14] <TabAtkins> If you run that from a data: url, it'll try to parse it immediately, fail due to the lack of a base url, and set the url to "". Then it'll resolve again when the <base> gets added, and end up with "url(http://example.com)".
# [18:14] * Joins: darfia (~darfia@201.82.243.68)
# [18:14] <TabAtkins> But I think we've already established that Chrome is doing dumb things here.
# [18:14] <TabAtkins> I need to go test in another browser.
# [18:16] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 260 seconds)
# [18:16] * Joins: weinig (~weinig@17.202.49.115)
# [18:17] <annevk> TabAtkins: from the data URL I don't see Chrome loading any image
# [18:17] <annevk> TabAtkins: which makes sense
# [18:17] <annevk> TabAtkins: it ending up with http://example.com does not though
# [18:17] <TabAtkins> Exactly, but if you look at the computed style, it's because it's trying to load "http://example.com"
# [18:18] <annevk> TabAtkins: in any event, see how HTML handles this, it doesn't change the URLs of all the resources in a document when the base URL changes
# [18:18] <TabAtkins> If "example.com" returned an image, Chrome would have shown that.
# [18:18] <annevk> TabAtkins: neither should style sheets
# [18:18] <dglazkov> good morning, Whatwg!
# [18:18] <annevk> TabAtkins: oh good point
# [18:19] <TabAtkins> annevk: Right, so I think you're saying that if the url is ever parsed, it's stuck with that parsing. But if it fails to parse, then changing the base url will let it try again?
# [18:19] <annevk> TabAtkins: actually, in the Chrome console I don't see a request for http://example.com/image
# [18:19] * Joins: tantek (~tantek@192.150.22.55)
# [18:19] <annevk> TabAtkins: no, if it fails you'd store "about:invalid" as the URL
# [18:19] <TabAtkins> annevk: Exactly. Read what I said about Chrome being messed up. ^_^
# [18:19] <annevk> TabAtkins: the new base URL only takes effect on reparsing
# [18:20] <TabAtkins> Hm, that works badly for url()s in <template>. :/
# [18:20] <annevk> aklein said it would be fine
# [18:20] <annevk> You reparse those styles, no?
# [18:20] <annevk> All you need is to store the input and the parsed URL
# [18:20] * Quits: jernoble|laptop (~jernoble@76.74.153.41) (Quit: Computer has gone to sleep.)
# [18:20] <TabAtkins> I dunno. I guess we can specify that it's reparsed.
# [18:20] * Quits: hasather_ (~hasather@guest.schibsted.no) (Remote host closed the connection)
# [18:21] <annevk> And you serialize the input if you get cssText, and the parsed URL if you get the computed value
# [18:21] * Joins: hasather (~hasather@guest.schibsted.no)
# [18:21] <annevk> Can you explain the <template> scenario more clearly?
# [18:21] <TabAtkins> <template><div style="background: url(/foo);"></div></template>, and then stamp that template out in the document.
# [18:22] <TabAtkins> I think the <template> contents are shoved into a docfrag?
# [18:22] <TabAtkins> So no base url.
# [18:22] <annevk> What does <template> do with <img src=/test>?
# [18:22] <annevk> Because CSS works like HTML in this regard
# [18:23] <TabAtkins> I dunno.
# [18:23] <annevk> HTML also keeps the input and the parsed URL
# [18:23] <annevk> Any question that applies to CSS here would also apply to HTML
# [18:23] * TabAtkins will check - he's not sure he's using a version that'll make <template> work.
# [18:24] <annevk> Also, I know you're off it now, but please try to avoid obvious racy things like that in standards!
# [18:24] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
# [18:25] <annevk> We go out of our way to make GC not observable, define order of tasks, make things deterministic
# [18:25] * Quits: benv (~benv@c-67-188-10-155.hsd1.ca.comcast.net) (Quit: Computer has gone to sleep.)
# [18:25] <annevk> For sure there will be some things, but if we can avoid them we should
# [18:25] * jorendorff_away is now known as jorendorff
# [18:26] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 272 seconds)
# [18:26] <TabAtkins> Haha, obviously I avoid raciness in new things. ^_^
# [18:26] * Quits: ebollens (~ebollens@98.159.89.142) (Quit: ebollens)
# [18:27] * Joins: ebollens (~ebollens@98.159.89.142)
# [18:27] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 248 seconds)
# [18:27] * ebollens is now known as ebollens|AFK
# [18:29] * Joins: shepazu (~shepazu@192.150.22.55)
# [18:34] * Joins: llkats (~llkats@206.169.83.230)
# [18:34] * Quits: izhak (~izhak@31.47.116.178) (Ping timeout: 252 seconds)
# [18:35] <aklein> annevk, TabAtkins: good morning
# [18:35] <aklein> reading back up
# [18:37] * Joins: newtron (~newtron@69-165-159-76.dsl.teksavvy.com)
# [18:38] <aklein> <img src> is quite different from CSS
# [18:38] <aklein> the "src" attribute is never mucked with
# [18:38] <aklein> the content attribute, that is
# [18:38] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [18:39] * Quits: icaaq (~icaaq@94.234.170.47) (Ping timeout: 248 seconds)
# [18:39] <aklein> HTML says to go fetch the image whenever src is set (by resolving the URL with the <img>'s baseURI)
# [18:39] <aklein> but reading HTMLImageElement.src doesn't necessarily have any connection to whatever image is displayed by the <img>
# [18:40] <aklein> it always re-resolves whenever it's read, again against the baseURI
# [18:40] <aklein> (though the above will change a bit if we make the spec better match the adoption/insertion behavior in browsers)
# [18:41] <aklein> see the "Otherwise" note in http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#dynamic-changes-to-base-urls for discussion of img src not matching the fetched resource
# [18:41] * Quits: newtron (~newtron@69-165-159-76.dsl.teksavvy.com) (Ping timeout: 272 seconds)
# [18:42] <aklein> annevk: as to what I said last night...conceptually what you suggested last night sounds fine, though it turns out it's trickier than I thought as we're over-eager to share resolved inline style when cloning elements
# [18:42] <aklein> but that's entirely an implementation detail
# [18:43] <annevk> aklein: if you set backgroundImage it will refetch too
# [18:43] <aklein> annevk: sure, that part matches
# [18:43] <annevk> aklein: and if you keep the original value as I suggested, backgroundImage would never be mucked with either
# [18:43] <aklein> but I wanted to point out that HTML doesn't store the resolved URL anywhere
# [18:43] <annevk> aklein: yes it does
# [18:43] <annevk> aklein: if you get .src
# [18:43] <annevk> aklein: after the base URL changed, it will be the original URL
# [18:44] <annevk> iirc
# [18:44] <aklein> annevk: nope
# [18:44] <annevk> hmm
# [18:44] <aklein> see the dynamic changes section I linked above
# [18:45] * Quits: darfia (~darfia@201.82.243.68) (Quit: Leaving)
# [18:45] <aklein> hmm
# [18:45] <annevk> Oh my that is fucked
# [18:45] <annevk> So .src returns a value that is not what is being fetched
# [18:45] <annevk> Or has been fetched
# [18:46] <annevk> Surely we have the original URL around somewhere. Would be much nicer to just expose that
# [18:46] <aklein> strangely I can't find where src is specified to return an absolute url
# [18:46] <aklein> it just says "reflect" in the spec
# [18:47] <annevk> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes
# [18:47] <aklein> ah
# [18:47] <annevk> "then on getting, the IDL attribute must resolve the value of the content attribute relative to the element and return the resulting absolute URL if that was successful"
# [18:47] <annevk> bah
# [18:47] <annevk> ugly is ugly
# [18:48] * Joins: icaaq (~icaaq@h132n3-s-oev-d1.ias.bredband.telia.com)
# [18:48] <TabAtkins> Platform is fucked, news at 11.
# [18:48] * Joins: barnabywalters (~barnabywa@89.17.128.127)
# [18:48] <Ms2ger> What's <col span> for?
# [18:49] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Client Quit)
# [18:49] <TabAtkins> For making a <col> span multiple columns.
# [18:50] <Ms2ger> Why not colgroup?
# [18:50] <TabAtkins> Because.
# [18:50] <Domenic_> <col span> is from prehistory right?
# [18:50] <TabAtkins> Yup.
# [18:51] <aklein> annevk: what's awesome in Blink/WebKit is that src reflection is nearly the only place where xml:base is respected
# [18:51] <aklein> so even without a baseURI change the resource and src can have a mismatch
# [18:51] <annevk> aklein: oh, I thought you guys had no xml:base implementation at all
# [18:51] <aklein> it basically only does anything in <svg:a>
# [18:51] <annevk> http://dump.testsuite.org/xml:base/basic.xml
# [18:52] <annevk> I see
# [18:52] <aklein> but it also affects the baseURI getter
# [18:52] <annevk> Please kill it
# [18:52] <annevk> Intent to removes get LGTM pretty quickly :)
# [18:52] * Joins: ap (~ap@17.114.219.4)
# [18:53] <aklein> very true
# [18:53] <annevk> Not having xml:base around will make it easier to design the new declarative thing
# [18:53] <aklein> anyway, I guess it's not a very good argument to say "<img> is crazy, CSS should be just like that"
# [18:54] <aklein> annevk: is there a mozilla bug for removing xml:base?
# [18:54] <annevk> Yeah, it's waiting on someone to do it
# [18:54] <aklein> (or a discussion somewhere?)
# [18:54] <aklein> yeah, everytime it comes up I go test Firefox and am shocked that it fully works there
# [18:54] <annevk> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976 has all the things on baseURI and xml:base
# [18:55] * Parts: adactio (~adactio@212.42.170.181)
# [18:55] <aklein> I keep forgetting that bug has all this stuff
# [18:58] * jonlee_ is now known as jonlee_|afk
# [18:59] * Quits: ap (~ap@17.114.219.4) (Quit: ap)
# [19:00] * Joins: say2joe (~say2joe@209-253-225-97.ip.mcleodusa.net)
# [19:01] * Quits: weinig (~weinig@17.202.49.115) (Ping timeout: 240 seconds)
# [19:03] * Joins: pinage404 (~pinage404@2a01:e35:8b86:e330:260a:64ff:fe63:69ab)
# [19:05] * Quits: smaug____ (~chatzilla@nat/mozilla/x-vpfsnihiyelanwrt) (Ping timeout: 252 seconds)
# [19:06] * Joins: weinig (~weinig@17.114.17.136)
# [19:11] * Joins: ap (~ap@17.114.219.4)
# [19:11] * Quits: llkats (~llkats@206.169.83.230)
# [19:12] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [19:14] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [19:16] * Joins: annevk_ (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [19:16] * Quits: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
# [19:17] * Joins: othermaciej (~mjs@17.114.216.203)
# [19:17] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 269 seconds)
# [19:18] * Quits: othermaciej (~mjs@17.114.216.203) (Client Quit)
# [19:19] * Joins: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [19:19] * Quits: diffalot (~diffalot@unaffiliated/papyromancer) (Ping timeout: 260 seconds)
# [19:20] * Quits: annevk_ (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
# [19:21] * Joins: othermaciej (~mjs@17.114.216.203)
# [19:21] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [19:27] <jgraham> Hmm, query-encoding tests seem to be broken
# [19:27] <jgraham> And zcorpan isn't even here to complain at
# [19:28] <reyre> foolip: do you know of any webvtt demos that show the desired behaviour for the processing model step 11 ?
# [19:28] <reyre> i.e. positioning the cues to be on the appropriate lines and making sure they don't overlap
# [19:29] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [19:32] * Quits: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
# [19:32] * Joins: annevk_ (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [19:33] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [19:33] <foolip> reyre: can you quote that step for me?
# [19:33] <foolip> "If reset is false, then, for each text track cue cue in cues..."?
# [19:34] <foolip> (so many algorithms and steps)
# [19:34] * Joins: smaug____ (~chatzilla@nat/mozilla/x-atqibksfuhjryaga)
# [19:34] <reyre> foolip: yea heh
# [19:34] <jgraham> oh look, "git qseries" isn't a command
# [19:34] <reyre> foolip: i'm having a hard time getting my head around how the cues should be positioned when the snap-to-lines flag is set
# [19:34] * Joins: benv (~benv@38.104.194.126)
# [19:35] <reyre> so i was basically looking for a demo that showcases the behaviour of the end result of that algorithm
# [19:35] <reyre> foolip: for example, if i have a cue with line: 1 and another cue with line: 2
# [19:35] <reyre> will cue with line: 1 be directly on top of the cue with line: 2
# [19:36] <foolip> reyre: oh, ok, you mean "Adjust the positions of boxes according to the appropriate steps from the following list"
# [19:36] <reyre> yep
# [19:36] <foolip> sure, examples for that shouldn't be hard to find
# [19:37] <foolip> you could have a look at some of the reftests in http://w3c-test.org/web-platform-tests/master/old-tests/submission/Opera/media/track/webvtt/rendering/reftest/
# [19:37] <foolip> the overlap avoidance algorithm for snap-to-lines is actually somewhat sane
# [19:38] <reyre> foolip: great, thanks
# [19:39] <foolip> essentially, it first finds the position the cue would like to be at, and if it overlaps it just moves it up until it finds a free space (then down, and other complications)
# [19:39] <foolip> if you want an implementation to compare with, I know that Presto's (old Opera 12.16) followed these steps very closely, although for an older version of the spec
# [19:40] <foolip> and with that I'm going to bed
# [19:41] <foolip> reyre: happy hacking!
# [19:41] <reyre> foolip: okay, thanks! this helps a lot
# [19:41] <reyre> foolip: good night!
# [19:47] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [19:52] * Joins: hasather (~hasather@guest.schibsted.no)
# [19:52] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
# [19:53] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [19:53] * Joins: arunranga (~otherarun@guest-nat.p2p.sfo1.mozilla.com)
# [19:54] * Quits: weinig (~weinig@17.114.17.136) (Quit: weinig)
# [19:57] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 260 seconds)
# [19:57] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Ping timeout: 240 seconds)
# [19:58] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
# [19:59] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [20:01] * Joins: weinig (~weinig@17.114.217.103)
# [20:01] * Quits: ap (~ap@17.114.219.4) (Remote host closed the connection)
# [20:02] * Joins: ap (~ap@17.114.219.4)
# [20:02] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [20:03] * Quits: smaug____ (~chatzilla@nat/mozilla/x-atqibksfuhjryaga) (Ping timeout: 252 seconds)
# [20:03] * Quits: annevk_ (~annevk@guest-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
# [20:04] * Joins: annevk (~annevk@guest-nat.p2p.sfo1.mozilla.com)
# [20:05] * Quits: othermaciej (~mjs@17.114.216.203) (Quit: othermaciej)
# [20:06] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [20:06] * Quits: eric_carlson (~eric@17.202.43.125) (Ping timeout: 272 seconds)
# [20:06] * Joins: othermaciej (~mjs@17.114.216.203)
# [20:07] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [20:07] * Quits: jonlee_|afk (~jonlee_@17.202.46.222) (Ping timeout: 245 seconds)
# [20:09] * Joins: smaug____ (~chatzilla@nat/mozilla/x-kuqvxfdcrdnqggym)
# [20:09] * Quits: weinig (~weinig@17.114.217.103) (Quit: weinig)
# [20:11] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [20:11] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [20:13] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [20:14] * Krinkle|detached is now known as Krinkle
# [20:18] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
# [20:20] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [20:24] * Quits: Snelhest45 (~Snelhest4@gateway/tor-sasl/snelhest45) (Ping timeout: 240 seconds)
# [20:27] <Hixie> hey if anyone is writing tests for type=range, <input type=range step=50 value=25> is an interesting case that chrome gets wrong
# [20:28] <Hixie> (firefox gets it right)
# [20:28] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: Computer has gone to sleep.)
# [20:29] * Joins: Smylers (~smylers@host31-51-172-127.range31-51.btcentralplus.com)
# [20:31] * Joins: Snelhest45 (~Snelhest4@gateway/tor-sasl/snelhest45)
# [20:31] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Ping timeout: 252 seconds)
# [20:34] * Joins: weinig (~weinig@17.114.217.103)
# [20:35] * Quits: Snelhest45 (~Snelhest4@gateway/tor-sasl/snelhest45) (Max SendQ exceeded)
# [20:35] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
# [20:35] * Joins: Snelhest45 (~Snelhest4@gateway/tor-sasl/snelhest45)
# [20:39] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [20:39] * Quits: jeffreyatw (~jeffreyat@199-188-192-239.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
# [20:41] * Joins: newtron (~newtron@69-165-159-76.dsl.teksavvy.com)
# [20:43] * Quits: othermaciej (~mjs@17.114.216.203) (Quit: othermaciej)
# [20:45] * Quits: ap (~ap@17.114.219.4) (Read error: Connection reset by peer)
# [20:45] * Joins: ap_ (~ap@17.114.219.4)
# [20:45] * Quits: smaug____ (~chatzilla@nat/mozilla/x-kuqvxfdcrdnqggym) (Ping timeout: 252 seconds)
# [20:46] * Joins: smaug____ (~chatzilla@nat/mozilla/x-dlxyomiswskgryzw)
# [20:48] * Quits: pinage404 (~pinage404@2a01:e35:8b86:e330:260a:64ff:fe63:69ab) (Quit: Screw you guys i'm going home ! KMP !)
# [20:49] * Krinkle is now known as Krinkle|detached
# [20:50] * Joins: eric_carlson (~eric@17.202.43.125)
# [20:52] * Joins: hasather (~hasather@guest.schibsted.no)
# [20:56] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [20:57] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 252 seconds)
# [20:57] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [21:00] * Quits: weinig (~weinig@17.114.217.103) (Quit: weinig)
# [21:00] * Joins: S234567a (~S234567a@unaffiliated/s234567a)
# [21:02] * ebollens|AFK is now known as ebollens
# [21:02] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [21:04] * Joins: weinig (~weinig@17.114.217.103)
# [21:05] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [21:07] <Ms2ger> zcorpan, did you have a js corpus?
# [21:07] <zcorpan> Ms2ger: miketaylr does
# [21:08] * Joins: jernoble|laptop (~jernoble@17.114.219.239)
# [21:08] <Ms2ger> miketaylr, want to grep for pkcs11 at some point?
# [21:08] <miketaylr> Ms2ger: sure thing, just the string "pkcs11"?
# [21:08] <Ms2ger> Yep
# [21:09] <miketaylr> k
# [21:14] <zcorpan> jgraham: what is broken?
# [21:15] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [21:15] * zcorpan disappears again
# [21:15] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [21:15] * heycam is now known as heycam|away
# [21:16] * Quits: felipeduardo (~felipedua@r253-pw-corumbatai.ibys.com.br) (Quit: ..)
# [21:18] * ap_ is now known as ap
# [21:19] * Quits: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net) (Remote host closed the connection)
# [21:22] * Quits: jcgregorio_ (jcgregorio@nat/google/x-bptrvacvmgyxldcl) (Ping timeout: 264 seconds)
# [21:22] * Joins: othermaciej (~mjs@17.114.8.44)
# [21:23] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Remote host closed the connection)
# [21:27] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [21:30] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [21:31] * Quits: S234567a (~S234567a@unaffiliated/s234567a)
# [21:31] <miketaylr> Ms2ger: https://gist.github.com/miketaylr/8696287
# [21:31] <Ms2ger> Thanks!
# [21:31] * Quits: weinig (~weinig@17.114.217.103) (Quit: weinig)
# [21:33] * Quits: newtron (~newtron@69-165-159-76.dsl.teksavvy.com) (Remote host closed the connection)
# [21:33] * Quits: jernoble|laptop (~jernoble@17.114.219.239) (Quit: Computer has gone to sleep.)
# [21:34] * Joins: newtron (~newtron@69-165-159-76.dsl.teksavvy.com)
# [21:36] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
# [21:36] * Quits: ebollens (~ebollens@98.159.89.142) (Remote host closed the connection)
# [21:37] * Joins: ebollens (~ebollens@98.159.89.142)
# [21:39] * Quits: newtron (~newtron@69-165-159-76.dsl.teksavvy.com) (Ping timeout: 272 seconds)
# [21:39] * Joins: kuatsure (~kuatsure@cpe-184-59-100-169.cinci.res.rr.com)
# [21:39] * Joins: jcgregorio_ (jcgregorio@nat/google/x-jaynwnnrandbozlp)
# [21:40] * Hixie adds a new feature to HTML
# [21:40] <Hixie> <input type=range multiple>
# [21:40] <Hixie> enjoy.
# [21:41] <jory> Random CSS query: should I group together @media blocks that share the same features?
# [21:43] <jory> e.g. is there a noticeable difference between having two identical @media queries with different rules beneath them versus bundling all of the rules under a single instance of the @media?
# [21:44] * MikeSmith waves from Washington DC
# [21:45] <MikeSmith> hmm multiple range
# [21:45] <annevk> jory: the object model will be different
# [21:45] <annevk> jory: performance might be different, but I suspect minor
# [21:46] * Joins: weinig (~weinig@17.114.217.103)
# [21:47] <jory> annevk: Yeah, I've found that when working with most of the popular preprocessors you can often end up with multiple instances of the same MQ being repeated with a very small number of rules in each instance.
# [21:47] <jory> I'm sure there's some # where it becomes more expensive, but just wondering if it was a major no-no / easy fix to eek out some performance.
# [21:49] <annevk> data:text/html,<input type=range step=50 value=25>
# [21:49] <annevk> is weird
# [21:50] <Ms2ger> Weird how?
# [21:51] * Joins: shannonmoeller (~shannonmo@pool-98-117-166-214.bflony.fios.verizon.net)
# [21:51] <jory> Hixie: Is that a range where you can select multiple values, or multiple disconnected ranges?
# [21:51] <jory> i.e. 10-30...40-50
# [21:52] <Ms2ger> input type=range doesn't let you select ranges
# [21:52] <Ms2ger> Oh, nvm
# [21:52] * Quits: arunranga (~otherarun@guest-nat.p2p.sfo1.mozilla.com) (Quit: arunranga)
# [21:52] <jory> Meaning a range where you can select values between 10 and 30, or 40 and 50, but not between 30 and 40.
# [21:53] * Joins: jeremyj (~jeremyj@17.202.51.51)
# [21:53] * Joins: hasather (~hasather@guest.schibsted.no)
# [21:58] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 265 seconds)
# [21:59] * Joins: roc (~chatzilla@60.234.66.19)
# [21:59] <Hixie> jory: it's as in where you can select two values.
# [22:00] <jory> Neat!
# [22:00] * Joins: mven (~mven@169.241.49.192)
# [22:01] * heycam|away is now known as heycam
# [22:02] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [22:04] * Quits: othermaciej (~mjs@17.114.8.44) (Quit: othermaciej)
# [22:07] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [22:08] * Joins: othermaciej (~mjs@17.114.216.203)
# [22:08] * Quits: Ms2ger (~Ms2ger@204.250-64-87.adsl-dyn.isp.belgacom.be) (Quit: nn)
# [22:10] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 252 seconds)
# [22:14] * Joins: jeffreyatw (~jeffreyat@199-188-192-239.PUBLIC.monkeybrains.net)
# [22:17] * Quits: krawchyk (~krawchyk@65.220.49.251)
# [22:18] <annevk> http://www.unicode.org/mail-arch/unicode-ml/y2014-m01/0049.html o_O
# [22:18] <annevk> hsivonen: ^^
# [22:18] * sankha93 is now known as sankha93|sleep
# [22:18] <annevk> I have been replying to that thread, but it seems my email is not getting to the list
# [22:19] <annevk> That email is particularly crazy though
# [22:21] * Quits: jeremyj (~jeremyj@17.202.51.51) (Quit: Textual IRC Client: www.textualapp.com)
# [22:24] * Joins: rniwa (~rniwa@17.202.43.222)
# [22:24] * sankha93|sleep is now known as sankha93
# [22:30] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [22:30] * Joins: scor (~scor@drupal.org/user/52142/view)
# [22:31] <Hixie> christ, if they really do feel like the need to mint new names, i hope they don't name things "whatwg-*"
# [22:31] <Hixie> that'd be horrible
# [22:32] <Hixie> but i think that somewhat misses the point
# [22:32] <Hixie> since i have huge doubts that anyone, anne least of all, wants to invent a new encoding...
# [22:36] * heycam is now known as heycam|away
# [22:36] * heycam|away is now known as heycam
# [22:37] <annevk> So DOM is forked now? http://lists.w3.org/Archives/Public/www-dom/2014JanMar/0054.html
# [22:38] <annevk> https://github.com/whatwg/dom/pulls has no outstanding pull requests regarding this
# [22:39] * Joins: jernoble|laptop (~jernoble@17.114.219.239)
# [22:41] * Joins: llkats (~llkats@206.169.83.230)
# [22:41] <annevk> Hixie: seems they want to support multiple incompatible implementations of windows-1252 in a single implementation
# [22:41] <Hixie> there are multiple incompatible implementations of windows-1252?
# [22:45] * Joins: newtron (~newtron@69-165-159-76.dsl.teksavvy.com)
# [22:48] <annevk> Apparently
# [22:49] <annevk> My opinion is that everyone should migrate towards the Encoding Standard, including default libraries of popular languages
# [22:49] * Quits: newtron (~newtron@69-165-159-76.dsl.teksavvy.com) (Ping timeout: 272 seconds)
# [22:50] * Quits: kuatsure (~kuatsure@cpe-184-59-100-169.cinci.res.rr.com) (Quit: zzz)
# [22:51] * Quits: weinig (~weinig@17.114.217.103) (Quit: weinig)
# [22:52] * Quits: Mentioum (~Mentioum@onwHAcoreFw1.2i3.net) (Ping timeout: 264 seconds)
# [22:53] * Quits: Smylers (~smylers@host31-51-172-127.range31-51.btcentralplus.com) (Quit: Leaving.)
# [22:54] * Joins: hasather (~hasather@guest.schibsted.no)
# [22:55] * Joins: arunranga (~otherarun@guest-nat.p2p.sfo1.mozilla.com)
# [22:56] * Quits: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [22:57] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [22:58] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 240 seconds)
# [22:59] <annevk> Hah, NetworkError has worker in it
# [23:00] * Quits: othermaciej (~mjs@17.114.216.203) (Quit: othermaciej)
# [23:00] * Joins: Ir1sh (~Ir1sh@89.100.254.231)
# [23:05] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
# [23:06] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [23:07] * Quits: tj_vantoll (~Adium@c-68-84-189-15.hsd1.mi.comcast.net) (Quit: Leaving.)
# [23:08] * Quits: shannonmoeller (~shannonmo@pool-98-117-166-214.bflony.fios.verizon.net) (Remote host closed the connection)
# [23:10] * Joins: say2joe1 (~say2joe@209-253-225-97.ip.mcleodusa.net)
# [23:10] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Quit: ZNC - http://znc.in)
# [23:11] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 248 seconds)
# [23:11] * Quits: say2joe (~say2joe@209-253-225-97.ip.mcleodusa.net) (Ping timeout: 248 seconds)
# [23:12] * Joins: othermaciej (~mjs@17.114.216.203)
# [23:12] * Joins: shannonmoeller (~shannonmo@pool-98-117-166-214.bflony.fios.verizon.net)
# [23:12] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
# [23:14] * Quits: llkats (~llkats@206.169.83.230)
# [23:15] * Quits: TallTed (~Thud@63.119.36.36)
# [23:16] * Joins: weinig (~weinig@24.130.60.35)
# [23:17] * Joins: ehsan (~ehsan@corp-nat.p2p.sfo1.mozilla.com)
# [23:18] * Joins: seventh (seventh@185.29.164.132)
# [23:19] * Joins: nessy (~silviapf@101.164.144.53)
# [23:24] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Changing host)
# [23:24] * Joins: diffalot (~diffalot@unaffiliated/papyromancer)
# [23:24] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [23:24] * Quits: Maurice (~copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
# [23:25] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [23:25] * Krinkle|detached is now known as Krinkle
# [23:29] * Joins: karlcow (~karl@nerval.la-grange.net)
# [23:29] * Joins: Ambrd (~User@bl8-32-122.dsl.telepac.pt)
# [23:31] <Hixie> annevk: what are these multiple implementations? are they interoperable with public content?
# [23:31] * Quits: othermaciej (~mjs@17.114.216.203) (Quit: othermaciej)
# [23:31] * Quits: shannonmoeller (~shannonmo@pool-98-117-166-214.bflony.fios.verizon.net) (Remote host closed the connection)
# [23:34] * Krinkle is now known as Krinkle|detached
# [23:35] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [23:37] * jorendorff is now known as jorendorff_away
# [23:37] * Krinkle|detached is now known as Krinkle
# [23:39] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [23:41] * Joins: newtron (~newtron@69-165-159-76.dsl.teksavvy.com)
# [23:43] * Quits: nessy (~silviapf@101.164.144.53) (Quit: Leaving.)
# [23:51] * Joins: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com)
# [23:55] * Joins: hasather (~hasather@guest.schibsted.no)
# [23:56] * Quits: jensnockert (~jensnocke@dynamic.1.24.64e950153c80.01b11587a2c.afb.bredband2.com) (Ping timeout: 272 seconds)
# [23:58] * Krinkle is now known as Krinkle|detached
# [23:59] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 252 seconds)
# [23:59] * Joins: nessy (~silviapf@1.149.124.195)
# Session Close: Thu Jan 30 00:00:01 2014

The end :)