| 00:14 | <aklein> | TabAtkins: you about? |
| 00:14 | <aklein> | TabAtkins: I've got a CSS parsing question you might know the answer to (or know if there's no answer) |
| 00:15 | <TabAtkins> | In a bit. |
| 00:16 | <SimonSapin> | aklein: just ask, and wait around a bit as someone may answer later |
| 00:16 | <TabAtkins> | Also that, yes. |
| 00:19 | gsnedders | wonders if he can construct any reasonable way to get profile number of calls per JS function in his browser |
| 00:19 | <gsnedders> | Probably nothing short of hacking on the browser, probably without JIT for simplicity. |
| 00:24 | <aklein> | the question is about url-resolution for url() CSS values |
| 00:25 | <aklein> | and about when it occurs, in various cases (<style>, <link rel=stylesheet>, <div style="...">) |
| 00:25 | <aklein> | that is, when does it occur (and where is that written down in a spec?) |
| 00:27 | <aklein> | (Blink and WebKit seem to do very eager url resolution, while Gecko is lazier) |
| 00:28 | <Hixie> | gsnedders: you can just instrument those methods by replacing them in script, no? |
| 00: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. |
| 00:28 | <gsnedders> | Hixie: All functions, including those defined in JS. |
| 00:28 | <Hixie> | gsnedders: well, those defined in JS you can find from any profiler, probably |
| 00:29 | <Hixie> | most browsers have those these days, i think |
| 00:29 | <gsnedders> | Not sure how well they cope with short-lived functions, though |
| 00:29 | <Hixie> | "short lived"? |
| 00:29 | <Hixie> | oh you mean you don't want a sample, you want a strict count? |
| 00:30 | <gsnedders> | Yeah. |
| 00:30 | <Hixie> | yeah short of instrumenting the code explicitly (which should be easy enough) i dunno how you'd do that |
| 00:30 | <Hixie> | (the js code, i mean) |
| 00: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. |
| 00: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). |
| 00:32 | <Hixie> | what's your actual goal? |
| 00: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. |
| 00:36 | <Hixie> | most of which functions? any function on any site? |
| 00:36 | <Hixie> | in what situations? page load? deep interaction? |
| 00:37 | <gsnedders> | "In general". Per page load, obviously. |
| 00:37 | <Hixie> | well i mean the functions that are handlers for 'onclick' handlers presumbaly only get called when you click |
| 00:37 | <gsnedders> | All functions that the JS VM sees. |
| 00:38 | <Hixie> | so is the test protocol "click everything once"? |
| 00:38 | <Hixie> | "use the application like a noob for 5 minutes"? |
| 00: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". |
| 00:39 | <Hixie> | i would imagine they'd have rather different profiles |
| 00:39 | <gsnedders> | I dunno. It makes me wonder if it's going to be a bell curve or something. |
| 00:40 | <gsnedders> | But, yeah, kinda tempted to just instrument browser and use it for a few weeks. Probably get useful data. |
| 00:40 | <gsnedders> | Though "how gsnedders uses his browser" isn't necessarily representative. :) |
| 00:43 | <gsnedders> | Ultimately I'm interested in the probability of the function being called a certain number of times. |
| 00: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 |
| 00:46 | <aklein> | (e.g., to "create a css style sheet") |
| 00:46 | <Hixie> | aklein: it's in the <style> section, i think... let me check |
| 00:49 | <Hixie> | aklein: ah, looks like i commented it out, expecting it to be handled by SimonSapin's CSS parsing spec |
| 00:49 | <Hixie> | aklein: (search for "found by the styling language's processor" in the spec source) |
| 00:50 | <aklein> | Hixie: heh, yes, that's very clear |
| 00: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." |
| 00: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 |
| 00:52 | <SimonSapin> | but I’m not sure what your question is… |
| 00:52 | <Hixie> | SimonSapin: that doesn't help for <style> style sheets |
| 00:53 | <Hixie> | aklein: yeah, but when is it parsed? |
| 00:53 | <Hixie> | aklein: imho it should be parsed very eagerly, fwiw |
| 00: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" |
| 00:53 | <aklein> | so the spec says what you want already |
| 00:53 | <aklein> | which is good :) |
| 00:53 | <Hixie> | k, excellent |
| 00:54 | <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 |
| 00:54 | <Hixie> | SimonSapin: the problem is that the base url in html docs can change dynamically |
| 00:54 | <aklein> | Hixie: fwiw, Firefox seems to re-resolve URLs in style attributes when the hosting element switches documents |
| 00:54 | <aklein> | sounds like you think that's a Firefox bug? |
| 00:54 | <Hixie> | SimonSapin: so is it the base url when the <style> element is created? when it's parsed? later? |
| 00: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 |
| 00:55 | <aklein> | SimonSapin: thanks for the link to that spec, I wasn't sure of the name |
| 00:55 | <SimonSapin> | good point. Looks like a spec bug |
| 00:55 | <Hixie> | aklein: i don't recall the conclusion, but obviously we should be consistent |
| 00:55 | <Hixie> | aklein: (assuming there's no compat constraints) |
| 00:55 | <aklein> | Hixie: I'll dig up the bug again, I didn't recall whether that had mentioned style |
| 00:55 | <Hixie> | i don't htink it mentioned style explicitly |
| 00:56 | <SimonSapin> | Hixie: what do you think it should be? |
| 00:56 | <Hixie> | aklein: i'm just saying that if possible, we should be consistent |
| 00:56 | <Hixie> | SimonSapin: what do browsers do? |
| 00:56 | <aklein> | Hixie: seems reasonable. would you say that <style> should also re-resolve if it switches documents? |
| 00:56 | <Hixie> | SimonSapin: i imagine they just use the current one at parse time |
| 00:56 | <aklein> | it's a little different in that case... |
| 00:56 | <aklein> | because it's non-local |
| 00:57 | <Hixie> | aklein: i think we should be consistent throughout. but for <style> i dunno if i'd say "reparse" or "reresolve" |
| 00:57 | <SimonSapin> | TabAtkins: ^ |
| 00:57 | <aklein> | eww |
| 00:57 | <Hixie> | aklein: do we reparse if you insert/remove/insert in the same doc? |
| 00:57 | <SimonSapin> | no need to reparse even if we want to reresolve |
| 00:57 | <aklein> | Hixie: is parsing observable? |
| 00:57 | <Hixie> | aklein: it is if you changed the OM |
| 00:58 | <aklein> | Hixie: right, if you hold onto the OM...whee |
| 00:58 | <aklein> | hmm |
| 00:58 | <aklein> | requiring reparsing seems bad |
| 00: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 |
| 00:58 | <Hixie> | so i could argue this either way |
| 00:58 | <aklein> | the resolving difference between Firefox and Blink is visible via the OM, too, which is unfortunate |
| 00:59 | <aklein> | Firefox says the value is 'url("relative/url.png")' while Blink says it's 'url("http://foo.bar/relative/url.png")'; |
| 00:59 | <aklein> | maybe that just means we have more webcompat leeway? |
| 01:01 | <aklein> | SimonSapin: looks like CSS Values and Units doesn't speak to the CSS OM? |
| 01:03 | <SimonSapin> | aklein: not directly, but it talks about computed value |
| 01:03 | <SimonSapin> | so with different API you may get specified or computed values which may differ |
| 01:04 | <SimonSapin> | "When a <url> appears in the computed value of a property, it is resolved to an absolute URL" |
| 01:10 | <TabAtkins> | OMG DONE MINUTING |
| 01:10 | <TabAtkins> | Okay, so anyway, I talked about this with Anne. |
| 01:10 | <TabAtkins> | URL canonicalization (turning to absolute) needs to happen during parsing. |
| 01:10 | <TabAtkins> | Absolutizing is, in fact, part of URL parsing itself. |
| 01:11 | <aklein> | TabAtkins: so is the relative URL dropped on the floor? |
| 01:11 | <TabAtkins> | Moving documents around to new base URLs need to be dealt with. |
| 01:11 | <aklein> | will let you finish :) |
| 01:11 | <TabAtkins> | aklein: Yes. You enter "url(/foo)", you immediately get back "url(http://example.com/foo)";. |
| 01:11 | <TabAtkins> | There's no way to observe it being relative. |
| 01:11 | <TabAtkins> | Besides, maybe, .cssText, if we keep that as literal stylesheet bytes. |
| 01:12 | <TabAtkins> | That's pre-parsing then. |
| 01:12 | <aklein> | it sounds like you're in the "you have to re-parse if you want to re-resolve" camp |
| 01:13 | <TabAtkins> | Not... necessarily. Parsing *the url itself* requires absolutizing; the two concepts are part and parcel. |
| 01:13 | <TabAtkins> | Parsing *the url() function* doesn't necessarily. |
| 01:13 | <SimonSapin> | TabAtkins: CSS parsing does not need to parse URLs immediately |
| 01:13 | <TabAtkins> | But we all do so. |
| 01:13 | <SimonSapin> | (maybe it should) |
| 01:13 | <TabAtkins> | But we can certainly keep around the unparsed url and absolutize it on demand. |
| 01:14 | <aklein> | TabAtkins: not sure who "we" is, note that I pointed out above that Firefox seems to only absolutize lazily |
| 01: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. |
| 01:14 | <TabAtkins> | "we" there means the browser. |
| 01:14 | <aklein> | TabAtkins: in my testing they don't do that. div.style.backgroundImage returns 'urlI("relative/img.png")' |
| 01:15 | <aklein> | but with fewer l's |
| 01:16 | <TabAtkins> | We definitely absolutize early. |
| 01:17 | <aklein> | Blink and WebKit do, yes |
| 01:17 | <aklein> | but it's not true that "we all do so" (not at the moment, anyway) |
| 01:17 | <TabAtkins> | Okay, true. |
| 01:18 | <TabAtkins> | aklein: What's the context of your question? |
| 01: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 |
| 01:19 | <aklein> | it ends up as url() |
| 01:20 | <TabAtkins> | That's weird. Because there's nothing to absolutize it against, so it just punts? |
| 01:20 | <aklein> | yeah |
| 01:20 | <aklein> | my reading of the CSS Values thingy suggests that perhaps the punting is the bug |
| 01:20 | <aklein> | and it should actually leave the relative URL there if it can't complete the URL |
| 01:20 | <TabAtkins> | The punting is definitely the bug. |
| 01:20 | <TabAtkins> | Are you talking about my blog post? Or the CSSOM Values spec? |
| 01:21 | <aklein> | TabAtkins: http://dev.w3.org/csswg/css-values/#urls |
| 01:22 | <aklein> | hmm, or maybe it was cssom, I don't see this now |
| 01:22 | <TabAtkins> | Don't read much into that. >_< I haven't written it well yet. |
| 01:22 | <TabAtkins> | Gonna fix. |
| 01:22 | <TabAtkins> | It's reffing an RFC, for example. |
| 01:22 | <TabAtkins> | Should be the URL spec. |
| 01:22 | <aklein> | hehe |
| 01:22 | <aklein> | ok |
| 01:23 | <SimonSapin> | TabAtkins: both provide "absolutize an URL", and it’s up to CSS when to call it |
| 01:23 | <aklein> | TabAtkins: but your considered opinion is that url() in a document with no base URL should do what? |
| 01:23 | <TabAtkins> | But hm, so far I'm planning that "declared value" http://dev.w3.org/csswg/css-cascade/#declared gives an absolute url. |
| 01:23 | <TabAtkins> | A document with no base URL is not something I've considered yet. |
| 01:24 | <TabAtkins> | Is the template document the only one so far? |
| 01: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 |
| 01:25 | <TabAtkins> | I wonder what that means? |
| 01:25 | <TabAtkins> | What is the result of absolutizing something with a not-base URL? |
| 01:25 | <SimonSapin> | absolutizing can fail |
| 01:25 | <TabAtkins> | Hrm. Lemme go check his spec. |
| 01:26 | <aklein> | TabAtkins: document.implementation.createHTMLDocument('') |
| 01:26 | <SimonSapin> | data:text/html,<a href=foo>Test |
| 01:26 | <SimonSapin> | anyway, the result is the same as if you didn’t have a base |
| 01:28 | <TabAtkins> | Ah, and it looks like the result (at least in Chrome) is that the url is "" |
| 01:29 | <TabAtkins> | Problem is that the URL spec has no such concept as "relative URL". |
| 01:30 | <TabAtkins> | It's absolute, or it's nothing, or it's "a string that we haven't yet tried to parse". |
| 01: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. |
| 01:31 | <TabAtkins> | aklein: So it looks like Blink's current behavior of returning url() is correct. |
| 01:32 | <TabAtkins> | aklein: And there's no way for us to do anything else. |
| 01:32 | <TabAtkins> | aklein: Without inventing stuff. |
| 01:32 | <SimonSapin> | TabAtkins: possibly-relative URL == string from url() or href, etc |
| 01:32 | <SimonSapin> | absolute URL == parsed URL |
| 01:33 | <SimonSapin> | an object, which can be serialized back to a string |
| 01:33 | <TabAtkins> | Yeah. |
| 01:33 | <TabAtkins> | Hm. |
| 01:34 | <TabAtkins> | Maybe we can define serialization of URL as "serialization of the url, or else the unparsed string if it can't be parsed". |
| 01:34 | <TabAtkins> | That would also let us preserve nonsense urls that can't be parsed. |
| 01:34 | <SimonSapin> | I’d say specified values should be unparsed URL, as from the stylesheet |
| 01:35 | <SimonSapin> | for computed values serialize, but do we really need to preserve nonsense input? |
| 01:37 | <TabAtkins> | SimonSapin: I think we should return an absolute url if we can. |
| 01:37 | <TabAtkins> | No reason not to. |
| 01:37 | <TabAtkins> | But we shouldn't throw away info if we can't absolutize it yet. |
| 01:37 | <SimonSapin> | If absolutization (aka URL parsing) fails, we can’t |
| 01:38 | <SimonSapin> | the info is still available in the specified value |
| 01:38 | <TabAtkins> | Yes, that's what I'm saying. |
| 01:38 | <TabAtkins> | ...I think. |
| 01:39 | <SimonSapin> | element.style is computed values, right? |
| 01:39 | <TabAtkins> | Nope, declared values. |
| 01:39 | <TabAtkins> | What you smokin', bro? |
| 01:39 | <TabAtkins> | .style is just access to the style='' stylesheet. |
| 01:41 | <TabAtkins> | I agree that a computed url() value should take a stand on non-absolutizable urls. |
| 01:41 | <TabAtkins> | Returning url(about:invalid). |
| 01:41 | <TabAtkins> | (As currently defined in V&U.) |
| 01:41 | <SimonSapin> | No interop :/ data:text/html,<body id=foo style="background:url(bar)"><script>document.write(document.getElementById('foo').style.backgroundImage)</script> |
| 01:43 | <TabAtkins> | Yeah, I know that BlinKit right now absolutizes right away. (And indicates an invalid url as "url()".) |
| 01:43 | <TabAtkins> | And FF does something different. |
| 01:46 | <TabAtkins> | aklein: So does something like what I said sound okay? I can restate it compactly, if you want. |
| 01:47 | <aklein> | TabAtkins: sorry, got pulled away, a compact suggestion would be great (reading scrollback now...) |
| 01:47 | <TabAtkins> | kk, coming: |
| 01:47 | <TabAtkins> | CSS parsing does not immediately absolutize a url. |
| 01:47 | <TabAtkins> | At declared-value time, we try to absolutize it. If it can be absolutized, great. |
| 01:48 | <TabAtkins> | When serializing a declared value, if it's a URL, serialize that. Otherwise, serialize the string. |
| 01:48 | <SimonSapin> | declared, as in http://dev.w3.org/csswg/css-cascade/#declared ? |
| 01:48 | <TabAtkins> | At computed-value time, we *need* a valid url. If it can't be absolutized, use the guaranteed-invalid url "about:invalid". |
| 01:48 | <TabAtkins> | SimonSapin: Yes. |
| 01:48 | <TabAtkins> | Right now we can only observe "declared", "computed", and "used" (in some cases). |
| 01:48 | <SimonSapin> | isn’t that as soon as parsing? |
| 01: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. |
| 01:49 | <TabAtkins> | A <url> declared value contains either a URL or a string, depending on whether it can be absolutized or not. |
| 01:50 | <annevk_> | So what would the specified value be? |
| 01:50 | <annevk> | If the URL parser returns failure, using a URL that is about:invalid makes sense |
| 01:50 | <TabAtkins> | Not sure when we go from "string or URL" to "URL". Sometime between declared and computed. The exact time is currently unobservable. |
| 01:51 | <SimonSapin> | I don’t really want to have a thing that can be either |
| 01:51 | <SimonSapin> | (unless we have to for web compat) |
| 01:51 | <annevk> | When would you have a string? |
| 01: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. |
| 01:52 | <TabAtkins> | I still want to observe the given value even if the document doesn't have a base url. |
| 01:52 | <SimonSapin> | so, counter-proposal: declared/cascaded/specified value is a string as in the input, unparsed |
| 01:53 | <SimonSapin> | computed values is always a parsed URL, possibly about:invalid |
| 01:53 | <TabAtkins> | That's acceptable to me too, I guess. Requires changing BlinKit. |
| 01:53 | <annevk> | You could preserve the specified value, but also have a parsed/declared value alongside that's a URL? |
| 01:53 | <TabAtkins> | annevk: You're mixing up terms. ^_^ |
| 01:53 | <annevk> | The terms have changed :/ |
| 01:53 | <TabAtkins> | declared -> cascaded -> specified -> computed |
| 01:54 | <TabAtkins> | annevk: We just moved what we call "the value that you pull directly from a stylesheet". "specified" was overused for incompatible things. |
| 01:55 | <annevk> | Oh man. Specified in my head is "the value I wrote down" |
| 01:55 | <TabAtkins> | In the specs it's not. ^_^ |
| 01:55 | <TabAtkins> | There's stuff mixed up with inherit/initial, and the cascade. |
| 01:56 | <TabAtkins> | I didn't want to throw away the term "specified", so I left it with one of the existing meanings. |
| 01: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. |
| 01:56 | <annevk> | So maybe declared needs to be a tuple |
| 01:56 | <TabAtkins> | Do we need that? |
| 01:57 | <TabAtkins> | Rather, why do we want a parsed URL during declared time? |
| 01:57 | <annevk> | You need to run it through the URL parser to not be tripped by changing base URLs in HTML documents |
| 01:57 | <annevk> | You want to keep the original value for <template> |
| 01:57 | <TabAtkins> | Elaborate on that first one? |
| 01:58 | <annevk> | <style> ... </style> <script> changeBaseURL() </script> |
| 01:58 | <annevk> | Hixie's example, basically |
| 01:59 | <TabAtkins> | Right, but what's the observable effect of resolving it in the declared value? |
| 02:00 | <TabAtkins> | I don't think the absolute url can be observed until computed-value time. |
| 02:00 | <TabAtkins> | Even through side-effects. |
| 02:02 | <annevk> | TabAtkins: do you want to require that we compute sync? |
| 02:02 | <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? |
| 02:02 | <annevk> | aklein: not at the moment |
| 02:02 | <aklein> | annevk: rather, should it? |
| 02:02 | <annevk> | aklein: we don't really have it on the HTML side either |
| 02:03 | <aklein> | annevk: no, though it seems we may end up with it (should go find that bug) |
| 02:03 | <aklein> | but I guess you don't necessarily need it to fix <template> |
| 02: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. |
| 02:03 | <aklein> | as long as you clone or import |
| 02: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 |
| 02:04 | <annevk> | TabAtkins: if the script changes the base URL, isn't it observable at what point computation happens? |
| 02:05 | <TabAtkins> | Not really. You can't observe except through computed values, and *that* triggers sync behavior. |
| 02:06 | <TabAtkins> | That is, calling getComputedStyle does sync work. |
| 02:06 | <annevk> | TabAtkins: yes |
| 02:06 | <annevk> | TabAtkins: <style> url("/x") </style> and then <script> getComputed(); changeBaseURL() </script> vs <script> changeBaseURL(); getComputed(); </script> |
| 02:06 | <annevk> | TabAtkins: they should do the same |
| 02:07 | <TabAtkins> | No, they're observably different. |
| 02:07 | <TabAtkins> | But now I need to go to dinner and will have to continue this later. |
| 02:07 | <annevk> | And that would be a bug |
| 02:07 | <annevk> | That's why URL parsing needs to happen during CSS parsing |
| 02:09 | <annevk> | I'm very happy the CSS WG is more deeply investigating lifecycle though of style sheets |
| 02: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 |
| 02:09 | <annevk> | aklein: I argued for storing a tuple as the "declared value" above |
| 02:09 | <annevk> | aklein: the input and the parsed URL |
| 02:10 | <annevk> | aklein: .cssText could use the input, getComputed the latter |
| 02:11 | <aklein> | annevk: and style attribute serialization corresponds to .cssText? (my CSSOM knowledge is....developing) |
| 02:12 | <annevk> | aklein: serialization of a style attribute is .style.cssText |
| 02:12 | <annevk> | aklein: see http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface |
| 02:13 | <annevk> | aklein: and http://dev.w3.org/csswg/cssom/#elementcssinlinestyle |
| 02:13 | <aklein> | that's some fancy IDL |
| 02:13 | <aklein> | that sounds fine to me |
| 02:14 | <aklein> | (not least because it's a minimal change to Blink; I needn't hold a URL-resolver) |
| 02:14 | <aklein> | annevk: I'm completely with you on needing to resolve eagerly |
| 02:15 | <annevk> | A lot of legacy there in those APIs |
| 02:16 | <annevk> | And a lot of neglect in terms of maintenance |
| 02:16 | <annevk> | Better now because of zcorpan |
| 04:45 | <Domenic_> | where are we on nanotasks? |
| 04:48 | <MikeSmith> | oh we have nanotasks now? |
| 04:48 | <MikeSmith> | Domenic_: your mention is the first I've heard |
| 04:48 | <MikeSmith> | so I assume it must be something recently added |
| 04: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 |
| 04:49 | <Domenic_> | (b) seems weird because i was pretty sure that was what the event loop was for |
| 04:49 | <MikeSmith> | oh custom elements.. |
| 04:49 | <MikeSmith> | Domenic_: right |
| 04: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? |
| 04:50 | <MikeSmith> | well |
| 04:51 | <MikeSmith> | I reckon dglazkov is the only person here who knows |
| 04:51 | MikeSmith | wishes Hixie was reviewing the custom-elements spec more |
| 04: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:41 | <smaug____> | oh, nanotasks |
| 05:41 | <smaug____> | annevk-cloud, could you please explain to me tomorrow why we need such things |
| 05:47 | <zewt> | to pave the way towards picotasks, duh |
| 05:48 | <zewt> | no doubt followed by 2^(-n)tasks |
| 06:11 | <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. |
| 06:45 | <SimonSapin> | hsivonen: browsers apparently do trim whitespace, and we fixed the spec |
| 06:45 | <SimonSapin> | banning whitespace was accidental |
| 06:53 | <zcorpan> | so when are mutation events going to be removed? |
| 07:01 | <zcorpan> | https://github.com/inverts/Data-Tamers/blob/4c8599fd293c84216f161608b08ae1c85532fc25/AppliedAnalytics/src/main/webapp/resources/cache/css/site.css#L1 |
| 07:02 | <zcorpan> | https://github.com/blazedev/simbud/blob/34412f7ba14b4fb7f3d89ac0565b4a6cde37f00d/frontend/app/bower_components/angular/angular-csp.css |
| 07: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) |
| 07:06 | <zcorpan> | does someone have a dataset of external CSS files? |
| 08: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). |
| 08:21 | <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? |
| 10:55 | <jgraham> | gsnedders: Pretty sure the MS paper from a few years ago looked at that kind of thing |
| 11:20 | <zcorpan> | Ms2ger: this status box looks misplaced? http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#text-0 |
| 11:22 | <zcorpan> | looking at the syntax section, i wonder if it's time to lift the ban on -- in comments |
| 11:25 | zcorpan | files a bug |
| 11:33 | <Ms2ger> | Heh, that's a nice old link |
| 11:34 | <Ms2ger> | Surely it shouldn't be too hard to get the wpt tests into those boxes |
| 13:14 | zcorpan | brings http://html5.org/tools/web-apps-tracker?from=8432&to=8433 to MikeSmith and hsivonen's attention |
| 13: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? |
| 13:22 | <zcorpan> | what kind of bug? |
| 13:22 | <jgraham> | Any kind |
| 13:23 | <jgraham> | Well something you could write a test for |
| 13:23 | <jgraham> | I can find something from the testsuite I guess |
| 13:26 | <Ms2ger> | In blink? |
| 13:26 | <Ms2ger> | Blob() |
| 13:26 | <Ms2ger> | (throws where it shouldn't) |
| 13:37 | <jgraham> | Oh, that's quite a reasonable example |
| 13:37 | <jgraham> | I would slightly prefer a bug in Firefox I think |
| 13:38 | <Ms2ger> | Blob() |
| 13:39 | <Ms2ger> | (constructs a Blob while annevk thinks it shouldn't) |
| 13:40 | <jgraham> | heh. I can't cite annevk as a spec |
| 13:40 | <darobin_> | jgraham: I'm sure there's precedent |
| 13:40 | <jgraham> | (not sure why we want WebIDL to be different to half of the javascript stdlib here) |
| 13:40 | <Ms2ger> | I had one in the FileReader stuff... |
| 13:42 | <Ms2ger> | (new FileReader()).abort(); |
| 13:42 | <Ms2ger> | Throws in Gecko, but shouldn't |
| 13:43 | <Ms2ger> | jgraham, ^ |
| 13:43 | <gsnedders> | jgraham: Yeah, it did. But that data is several years out of date. Usage of JS is changing pretty quickly. |
| 13:45 | <gsnedders> | jgraham: Sadly, I can't remember which MSR paper it was in :) |
| 13:48 | <jgraham> | gsnedders: Nor can I, but I think you should start with that paper anyway |
| 13:49 | <zcorpan> | jgraham: document.createElement('image') instanceof HTMLUnknownElement |
| 13:50 | <jgraham> | http://research.microsoft.com/en-us/um/people/livshits/papers%5Cpdf%5Cwebapps10b.pdf |
| 13:50 | <jgraham> | zcorpan: I think I will use the FileReader one |
| 13:50 | <Ms2ger> | zcorpan, blink bug |
| 13:51 | <gsnedders> | https://research.microsoft.com/pubs/115734/aitypes.pdf --- is it just me or is there nothing novel in that paper? |
| 13:51 | <zcorpan> | Ms2ger: blink gives true for me which matches the spec afaict |
| 13:52 | <gsnedders> | (I presume I'm just missing what makes it novel) |
| 13:52 | <Ms2ger> | Oh? |
| 13:52 | <Ms2ger> | Firefox should be true too... |
| 13:53 | <jgraham> | If only we had a testsuite to verify these things… ;) |
| 13:53 | <Ms2ger> | I think we do |
| 13:53 | <zcorpan> | i get HTMLElement in gecko (nightly from 2014-01-14) |
| 13:54 | <Ms2ger> | Hrm |
| 13:54 | <gsnedders> | jgraham: That paper only shows that 50-70% of functions are called zero times, makes no statement about functions called once. |
| 13:55 | <Ms2ger> | But yes, html/semantics/interfaces.html and html/editing/dnd/the-draggable-attribute/draggable_attribute.html test it |
| 13:55 | <Ms2ger> | Oh, the latter doesn't use it |
| 13:55 | <Ms2ger> | Anyway |
| 13: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 |
| 13:56 | <gsnedders> | jgraham: But I have to complain at you! It's what I do! |
| 13:56 | <Ms2ger> | You could complain at zcorpan? |
| 13:57 | <gsnedders> | Ms2ger: Nah, I always complained at jgraham. |
| 13:57 | <Ms2ger> | So you only glared at zcorpan? |
| 13:57 | <zcorpan> | he still does |
| 13:58 | <Ms2ger> | Have we removed HTMLBaseFontElement from the spec yet? |
| 13:58 | <Ms2ger> | Apparently not |
| 13:58 | <gsnedders> | https://research.microsoft.com/pubs/115687/paper.pdf seems to be the longer thing that the paper jgraham linked me to summarizes. |
| 14:55 | <jgraham> | mathiasbynens: Are you planning to finish the review of https://critic.hoppipolla.co.uk/r/56 ? |
| 14:58 | <mathiasbynens> | jgraham: new to Critic, sorry – what do I need to do? review the new changes? |
| 14:59 | <jgraham> | mathiasbynens: Yes |
| 14:59 | <jgraham> | https://critic.hoppipolla.co.uk/showcommit?review=56&filter=pending |
| 14:59 | <Ms2ger> | "Your work here is done!"? |
| 15:00 | <jgraham> | "Ms2ger watches workers/" |
| 15:00 | <Ms2ger> | "mathiasbynens watches Workers/" |
| 15:00 | <jgraham> | Oh |
| 15:00 | <jgraham> | But also mathiasbynens reviews / |
| 15:01 | Ms2ger | unwatches |
| 15:03 | <jgraham> | Critic seems confused |
| 15:03 | <jgraham> | Let me kick it |
| 15:04 | <jgraham> | mathiasbynens: You should be able to review now :) |
| 15:04 | <mathiasbynens> | jgraham: moar work! thanks |
| 15:07 | zcorpan | was just about to ping mathiasbynens about that |
| 15:08 | <mathiasbynens> | is there a way to have Critic send an email whenever someone responds to a review i made? |
| 15:09 | <zcorpan> | doesn't it already? |
| 15:09 | <mathiasbynens> | nope. `email.activated` is enabled, though |
| 15:10 | <jgraham> | mathiasbynens: You didn't tell it your email address though :) |
| 15:10 | <jgraham> | See the "home" page |
| 15:11 | <mathiasbynens> | jgraham: thanks, i was looking through settings instead |
| 15:12 | <jgraham> | mathiasbynens: A reasonable approach |
| 15:12 | <jgraham> | But wrong ;) |
| 15:17 | <zcorpan> | not sure if the new File test made chrome crash |
| 15:18 | <jgraham> | But if it did you get a badge |
| 15:22 | <zcorpan> | mathiasbynens: refresh |
| 15:31 | <jgraham> | mathiasbynens++ |
| 15:31 | <jgraham> | also zcorpan++ ofc |
| 15:33 | <zcorpan> | ok merged, now fix the browsers |
| 15:34 | <jgraham> | Hehe |
| 15:38 | <zcorpan> | sigh, the Workers directory had been renamed |
| 15:39 | <zcorpan> | oh well |
| 15:39 | <jgraham> | Why did it get renamed? |
| 15:39 | <jgraham> | Oh since r/56 seems quite likely I guess |
| 15:40 | <zcorpan> | to match TR names or some such i think |
| 15:40 | <zcorpan> | thanks mathiasbynens |
| 15:40 | <zcorpan> | now work time is up for today :-) |
| 15:40 | <jgraham> | Yeah, that's the general naming scheme |
| 15:51 | <annevk-cloud> | Blob() should throw without new |
| 15:51 | <annevk-cloud> | See ES6 |
| 15:52 | <jgraham> | Does ES6 also make Array() throw without new? |
| 15:55 | <annevk-cloud> | Not sure |
| 15: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 |
| 15:56 | <jgraham> | Well if it breaks Image() and Array() and Blob() and so on it is surely incompatible |
| 16:43 | <Domenic_> | ES6 legacy classes are not changed to throw |
| 16:43 | <Domenic_> | but new classes throw |
| 16:44 | <Domenic_> | Allen explained this on list a while back lemme find the link |
| 16:44 | <Ms2ger> | So why should legacy DOM classes change? |
| 16:44 | <Domenic_> | unclear |
| 16:45 | <Domenic_> | if users can compatibly not use `new` cross browser then they probably shouldn't |
| 16:45 | <Domenic_> | but if browsers disagree on this point it's an opportunity to move to the newer semantics |
| 16: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 |
| 16:46 | <jgraham> | (pun intended)? |
| 16:46 | <jgraham> | In any case this seems pretty dumb |
| 16:46 | <jgraham> | Since it bakes inconsistency into the language |
| 16:46 | <Domenic_> | i kind of agree |
| 16:47 | <Domenic_> | the alternative though is making subclassing very hard to get right for all classes ever |
| 16:47 | <Domenic_> | in order to preserve consistency with legacy Array, Date, RegExp |
| 16:48 | <jgraham> | And all of DOM |
| 16:49 | <Domenic_> | cross browser? |
| 16:50 | <Domenic_> | DOM has so few constructors anyway @_@ |
| 16:50 | <jgraham> | I'm pretty sure that there are at least some that work cross browser |
| 16:52 | <annevk-cloud> | Chrome throws for most |
| 16:52 | <annevk-cloud> | I talked with bz the other day and we have a plan |
| 16:52 | <Ms2ger> | Plans are good |
| 16:52 | <Ms2ger> | I guess |
| 16:52 | <annevk-cloud> | Biggest problem is our testsuite |
| 16:52 | <jgraham> | That sounds unlikely |
| 16:53 | <jgraham> | I mean it makes bz's life suck because he has to fix the tests |
| 16:53 | <annevk-cloud> | In terms of executing the plan it is |
| 16:53 | <jgraham> | But it isn't an actual compat issue |
| 16:54 | <annevk-cloud> | Domenic_: more than ES though ;) |
| 16: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. |
| 16:59 | <TabAtkins> | So before/after changing the base url, you'll see different computed values for url()s. |
| 17:06 | <annevk> | TabAtkins: because that would be incompatible with what is happening today and would make fetching images racy |
| 17:06 | <annevk> | TabAtkins: once the style sheet is parsed the browser should be able to start fetching happens |
| 17:06 | <annevk> | TabAtkins: so that requires the URL to be parsed |
| 17:07 | <annevk> | s/happens// |
| 17: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. |
| 17:07 | <TabAtkins> | Ah, but yeah, allowing preloading does require you to try and parse the url immediately. |
| 17:08 | <TabAtkins> | (But that doesn't have any effect on what I said. And yes, it is racy.) |
| 17:10 | <annevk> | You can say things but you are wrong |
| 17:10 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2782 |
| 17:10 | <annevk> | (Sorry for that, got a bit annoyed I have to demonstrate how CSS works.) |
| 17:13 | <TabAtkins> | Jeezus, Chrome's behavior there is just idiotic. |
| 17: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)";. |
| 17:14 | <TabAtkins> | But I think we've already established that Chrome is doing dumb things here. |
| 17:14 | <TabAtkins> | I need to go test in another browser. |
| 17:17 | <annevk> | TabAtkins: from the data URL I don't see Chrome loading any image |
| 17:17 | <annevk> | TabAtkins: which makes sense |
| 17:17 | <annevk> | TabAtkins: it ending up with http://example.com does not though |
| 17:17 | <TabAtkins> | Exactly, but if you look at the computed style, it's because it's trying to load "http://example.com"; |
| 17: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 |
| 17:18 | <TabAtkins> | If "example.com" returned an image, Chrome would have shown that. |
| 17:18 | <annevk> | TabAtkins: neither should style sheets |
| 17:18 | <dglazkov> | good morning, Whatwg! |
| 17:18 | <annevk> | TabAtkins: oh good point |
| 17: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? |
| 17:19 | <annevk> | TabAtkins: actually, in the Chrome console I don't see a request for http://example.com/image |
| 17:19 | <annevk> | TabAtkins: no, if it fails you'd store "about:invalid" as the URL |
| 17:19 | <TabAtkins> | annevk: Exactly. Read what I said about Chrome being messed up. ^_^ |
| 17:19 | <annevk> | TabAtkins: the new base URL only takes effect on reparsing |
| 17:20 | <TabAtkins> | Hm, that works badly for url()s in <template>. :/ |
| 17:20 | <annevk> | aklein said it would be fine |
| 17:20 | <annevk> | You reparse those styles, no? |
| 17:20 | <annevk> | All you need is to store the input and the parsed URL |
| 17:20 | <TabAtkins> | I dunno. I guess we can specify that it's reparsed. |
| 17:21 | <annevk> | And you serialize the input if you get cssText, and the parsed URL if you get the computed value |
| 17:21 | <annevk> | Can you explain the <template> scenario more clearly? |
| 17:21 | <TabAtkins> | <template><div style="background: url(/foo);"></div></template>, and then stamp that template out in the document. |
| 17:22 | <TabAtkins> | I think the <template> contents are shoved into a docfrag? |
| 17:22 | <TabAtkins> | So no base url. |
| 17:22 | <annevk> | What does <template> do with <img src=/test>? |
| 17:23 | <annevk> | Because CSS works like HTML in this regard |
| 17:23 | <TabAtkins> | I dunno. |
| 17:23 | <annevk> | HTML also keeps the input and the parsed URL |
| 17:23 | <annevk> | Any question that applies to CSS here would also apply to HTML |
| 17:23 | TabAtkins | will check - he's not sure he's using a version that'll make <template> work. |
| 17:24 | <annevk> | Also, I know you're off it now, but please try to avoid obvious racy things like that in standards! |
| 17:25 | <annevk> | We go out of our way to make GC not observable, define order of tasks, make things deterministic |
| 17:25 | <annevk> | For sure there will be some things, but if we can avoid them we should |
| 17:26 | <TabAtkins> | Haha, obviously I avoid raciness in new things. ^_^ |
| 17:35 | <aklein> | annevk, TabAtkins: good morning |
| 17:35 | <aklein> | reading back up |
| 17:38 | <aklein> | <img src> is quite different from CSS |
| 17:38 | <aklein> | the "src" attribute is never mucked with |
| 17:38 | <aklein> | the content attribute, that is |
| 17:39 | <aklein> | HTML says to go fetch the image whenever src is set (by resolving the URL with the <img>'s baseURI) |
| 17:40 | <aklein> | but reading HTMLImageElement.src doesn't necessarily have any connection to whatever image is displayed by the <img> |
| 17:40 | <aklein> | it always re-resolves whenever it's read, again against the baseURI |
| 17:41 | <aklein> | (though the above will change a bit if we make the spec better match the adoption/insertion behavior in browsers) |
| 17: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 |
| 17: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 |
| 17:42 | <aklein> | but that's entirely an implementation detail |
| 17:43 | <annevk> | aklein: if you set backgroundImage it will refetch too |
| 17:43 | <aklein> | annevk: sure, that part matches |
| 17:43 | <annevk> | aklein: and if you keep the original value as I suggested, backgroundImage would never be mucked with either |
| 17:43 | <aklein> | but I wanted to point out that HTML doesn't store the resolved URL anywhere |
| 17:43 | <annevk> | aklein: yes it does |
| 17:43 | <annevk> | aklein: if you get .src |
| 17:44 | <annevk> | aklein: after the base URL changed, it will be the original URL |
| 17:44 | <annevk> | iirc |
| 17:44 | <aklein> | annevk: nope |
| 17:44 | <annevk> | hmm |
| 17:44 | <aklein> | see the dynamic changes section I linked above |
| 17:45 | <aklein> | hmm |
| 17:45 | <annevk> | Oh my that is fucked |
| 17:45 | <annevk> | So .src returns a value that is not what is being fetched |
| 17:46 | <annevk> | Or has been fetched |
| 17:46 | <annevk> | Surely we have the original URL around somewhere. Would be much nicer to just expose that |
| 17:47 | <aklein> | strangely I can't find where src is specified to return an absolute url |
| 17:47 | <aklein> | it just says "reflect" in the spec |
| 17:47 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes |
| 17:47 | <aklein> | ah |
| 17: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" |
| 17:47 | <annevk> | bah |
| 17:47 | <annevk> | ugly is ugly |
| 17:48 | <TabAtkins> | Platform is fucked, news at 11. |
| 17:48 | <Ms2ger> | What's <col span> for? |
| 17:49 | <TabAtkins> | For making a <col> span multiple columns. |
| 17:50 | <Ms2ger> | Why not colgroup? |
| 17:50 | <TabAtkins> | Because. |
| 17:50 | <Domenic_> | <col span> is from prehistory right? |
| 17:50 | <TabAtkins> | Yup. |
| 17:51 | <aklein> | annevk: what's awesome in Blink/WebKit is that src reflection is nearly the only place where xml:base is respected |
| 17:51 | <aklein> | so even without a baseURI change the resource and src can have a mismatch |
| 17:51 | <annevk> | aklein: oh, I thought you guys had no xml:base implementation at all |
| 17:51 | <aklein> | it basically only does anything in <svg:a> |
| 17:52 | <annevk> | http://dump.testsuite.org/xml:base/basic.xml |
| 17:52 | <annevk> | I see |
| 17:52 | <aklein> | but it also affects the baseURI getter |
| 17:52 | <annevk> | Please kill it |
| 17:52 | <annevk> | Intent to removes get LGTM pretty quickly :) |
| 17:53 | <aklein> | very true |
| 17:53 | <annevk> | Not having xml:base around will make it easier to design the new declarative thing |
| 17:53 | <aklein> | anyway, I guess it's not a very good argument to say "<img> is crazy, CSS should be just like that" |
| 17:54 | <aklein> | annevk: is there a mozilla bug for removing xml:base? |
| 17:54 | <annevk> | Yeah, it's waiting on someone to do it |
| 17:54 | <aklein> | (or a discussion somewhere?) |
| 17:54 | <aklein> | yeah, everytime it comes up I go test Firefox and am shocked that it fully works there |
| 17:54 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976 has all the things on baseURI and xml:base |
| 17:56 | <aklein> | I keep forgetting that bug has all this stuff |
| 18:27 | <jgraham> | Hmm, query-encoding tests seem to be broken |
| 18:27 | <jgraham> | And zcorpan isn't even here to complain at |
| 18:28 | <reyre> | foolip: do you know of any webvtt demos that show the desired behaviour for the processing model step 11 ? |
| 18:28 | <reyre> | i.e. positioning the cues to be on the appropriate lines and making sure they don't overlap |
| 18:33 | <foolip> | reyre: can you quote that step for me? |
| 18:34 | <foolip> | "If reset is false, then, for each text track cue cue in cues..."? |
| 18:34 | <foolip> | (so many algorithms and steps) |
| 18:34 | <reyre> | foolip: yea heh |
| 18:34 | <jgraham> | oh look, "git qseries" isn't a command |
| 18:35 | <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 |
| 18:35 | <reyre> | so i was basically looking for a demo that showcases the behaviour of the end result of that algorithm |
| 18:35 | <reyre> | foolip: for example, if i have a cue with line: 1 and another cue with line: 2 |
| 18:35 | <reyre> | will cue with line: 1 be directly on top of the cue with line: 2 |
| 18:36 | <foolip> | reyre: oh, ok, you mean "Adjust the positions of boxes according to the appropriate steps from the following list" |
| 18:36 | <reyre> | yep |
| 18:36 | <foolip> | sure, examples for that shouldn't be hard to find |
| 18: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/ |
| 18:38 | <foolip> | the overlap avoidance algorithm for snap-to-lines is actually somewhat sane |
| 18:38 | <reyre> | foolip: great, thanks |
| 18: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) |
| 18: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 |
| 18:40 | <foolip> | and with that I'm going to bed |
| 18:41 | <foolip> | reyre: happy hacking! |
| 18:41 | <reyre> | foolip: okay, thanks! this helps a lot |
| 18:41 | <reyre> | foolip: good night! |
| 19:28 | <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 |
| 19:28 | <Hixie> | (firefox gets it right) |
| 20:07 | <Ms2ger> | zcorpan, did you have a js corpus? |
| 20:07 | <zcorpan> | Ms2ger: miketaylr does |
| 20:08 | <Ms2ger> | miketaylr, want to grep for pkcs11 at some point? |
| 20:08 | <miketaylr> | Ms2ger: sure thing, just the string "pkcs11"? |
| 20:08 | <Ms2ger> | Yep |
| 20:09 | <miketaylr> | k |
| 20:15 | <zcorpan> | jgraham: what is broken? |
| 20:15 | zcorpan | disappears again |
| 20:31 | <miketaylr> | Ms2ger: https://gist.github.com/miketaylr/8696287 |
| 20:31 | <Ms2ger> | Thanks! |
| 20:40 | Hixie | adds a new feature to HTML |
| 20:40 | <Hixie> | <input type=range multiple> |
| 20:40 | <Hixie> | enjoy. |
| 20:41 | <jory> | Random CSS query: should I group together @media blocks that share the same features? |
| 20: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? |
| 20:45 | MikeSmith | waves from Washington DC |
| 20:45 | <MikeSmith> | hmm multiple range |
| 20:45 | <annevk> | jory: the object model will be different |
| 20:45 | <annevk> | jory: performance might be different, but I suspect minor |
| 20: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. |
| 20:48 | <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. |
| 20:49 | <annevk> | data:text/html,<input type=range step=50 value=25> |
| 20:49 | <annevk> | is weird |
| 20:50 | <Ms2ger> | Weird how? |
| 20:51 | <jory> | Hixie: Is that a range where you can select multiple values, or multiple disconnected ranges? |
| 20:52 | <jory> | i.e. 10-30...40-50 |
| 20:52 | <Ms2ger> | input type=range doesn't let you select ranges |
| 20:52 | <Ms2ger> | Oh, nvm |
| 20:53 | <jory> | Meaning a range where you can select values between 10 and 30, or 40 and 50, but not between 30 and 40. |
| 21:00 | <Hixie> | jory: it's as in where you can select two values. |
| 21:00 | <jory> | Neat! |
| 21:18 | <annevk> | http://www.unicode.org/mail-arch/unicode-ml/y2014-m01/0049.html o_O |
| 21:18 | <annevk> | hsivonen: ^^ |
| 21:19 | <annevk> | I have been replying to that thread, but it seems my email is not getting to the list |
| 21:20 | <annevk> | That email is particularly crazy though |
| 21:32 | <Hixie> | christ, if they really do feel like the need to mint new names, i hope they don't name things "whatwg-*" |
| 21:32 | <Hixie> | that'd be horrible |
| 21:32 | <Hixie> | but i think that somewhat misses the point |
| 21:32 | <Hixie> | since i have huge doubts that anyone, anne least of all, wants to invent a new encoding... |
| 21:37 | <annevk> | So DOM is forked now? http://lists.w3.org/Archives/Public/www-dom/2014JanMar/0054.html |
| 21:38 | <annevk> | https://github.com/whatwg/dom/pulls has no outstanding pull requests regarding this |
| 21:41 | <annevk> | Hixie: seems they want to support multiple incompatible implementations of windows-1252 in a single implementation |
| 21:42 | <Hixie> | there are multiple incompatible implementations of windows-1252? |
| 21:48 | <annevk> | Apparently |
| 21:49 | <annevk> | My opinion is that everyone should migrate towards the Encoding Standard, including default libraries of popular languages |
| 21:59 | <annevk> | Hah, NetworkError has worker in it |
| 22:31 | <Hixie> | annevk: what are these multiple implementations? are they interoperable with public content? |
| 23:08 | <annevk> | Hixie: I think these are libraries that are incompatible with browsers |
| 23:09 | <annevk> | Hixie: e.g. browsers have mappings for code points not officially assigned (return the byte as code point rather than U+FFFD iirc) |
| 23:09 | <Hixie> | annevk: well ok but what are the files that people are reading that are incompatible with returning that? |
| 23:12 | <annevk> | Hixie: I don't know |
| 23:12 | <annevk> | Hixie: I suspect they simply don't want to change existing behavior |
| 23:12 | <Hixie> | i mean, unless there's actual content depending on those other implementations, i would argue it's not a new encoding, it's just a buggy version of the existing encoding |
| 23:13 | <Hixie> | win1252 is by definition whatever microsoft implemented, after all |
| 23:14 | <annevk> | I'm not sure they would agree with that |
| 23:32 | <Hixie> | annevk: yeah. well. maybe they should check interop more then. |
| 23:32 | <annevk> | I don't disagree |
| 23:33 | <annevk> | The only complaints I see are about us not matching some other standards body definition |
![http://foo.bar/relative/url.png")'](http://foo.bar/relative/url.png")'){kind=link}