| 00:29 | <Igor^> | what means sandbox attribute with value of ? |
| 01:11 | <Domenic_> | man we still haven't figured out html parsing? I thought that was the grand triumph of the 00s! |
| 01:17 | <Igor^^^> | some browsers does not have user agent? |
| 04:49 | <accessPoint> | external css reduce page open time? |
| 05:05 | <TabAtkins> | Man, why are we suddenly getting so many people asking basic webdev questions lately? |
| 05:10 | <tantek> | TabAtkins - insufficiently googleable FAQs? E.g. on wikis? |
| 05:10 | <TabAtkins> | tantek: A lot of these are things you can look up or learn yourself. |
| 05:10 | <tantek> | like LMGTFY style? |
| 05:11 | <tantek> | maybe this channel is advertised as a support forum somewhere ;) |
| 05:11 | <TabAtkins> | That actually seems halfway likely - several of the people that have showed up seem to have similar varieties of poor English. |
| 06:00 | <hsivonen> | Hixie: maybe you didn't do anything special for title, but the patch that was written to bring Gecko up to spec had new code for <title> |
| 06:01 | <Hixie> | odd |
| 06:01 | <Hixie> | i wonder why |
| 06:01 | <hsivonen> | Hixie: I'm not in any way objecting to not supporting <frame>, FWIW |
| 06:01 | <Hixie> | ok good :-) |
| 06:01 | <hsivonen> | Hixie: well, <title> is special |
| 06:01 | <Hixie> | i don't recall it being particularly special for <template> purposes, though |
| 06:02 | <hsivonen> | Hixie: parses like in "in head", so you at least have to notice and do the "in head" stuff |
| 06:04 | <Hixie> | is there new code for all the other in-head elements too? |
| 07:35 | <hsivonen> | Hixie: the other "in head" elements were already covered |
| 08:20 | <zcorpan> | http://lists.w3.org/Archives/Public/www-style/2013Aug/0168.html is this something that css filters can do? |
| 08:33 | <matjas> | annevk: re: surrogates, anything in particular you’re working on? |
| 08:35 | <annevk> | matjas: we've been having some office debates about Servo and Rust, strings in CSS, how Unicode 2.0 fucked it all up, and then JavaScript some more by copying Java and not fixing it in time |
| 08:36 | <annevk> | Basically, I don't see a way out of the array of sixteen-bit integers madness... |
| 08:36 | <matjas> | :( |
| 08:36 | matjas | has horrible http://mathiasbynens.be/notes/css-escapes#other flashbacks |
| 08:38 | <annevk> | matjas: yeah, SimonSapin will fix that, presumably by not letting in surrogates via escapes, but you can still get them in CSS via JavaScript, so CSS' backend will have the sixteen-bit integers regardless |
| 08:38 | <annevk> | (And having a different backend for CSS and its DOM doesn't seem all that beneficial anyway, so just as well.) |
| 08:58 | <SimonSapin> | matjas: "Since there is currently no way to escape non-BMP symbols in a cross-browser fashion…" this is also fixed now |
| 08:59 | <SimonSapin> | now that webkit supports a single hex number above FFFF |
| 09:00 | <SimonSapin> | annevk: you can always encode codepoints (not scalar values) in whatever way |
| 09:13 | <annevk> | SimonSapin: anything else seems unlikely to have good perf |
| 09:13 | <annevk> | SimonSapin: also, code points* |
| 09:44 | <matjas> | SimonSapin: I know, I was the one who discovered and filed that bug |
| 09:44 | <matjas> | SimonSapin: point is, on mobile a lot of older WebKits are in use, which still have the issue |
| 09:54 | <annevk> | Hmm, I wonder how hard https://bugzilla.mozilla.org/show_bug.cgi?id=888093 would be to implement. They'd be extremely useful. |
| 10:03 | <jgraham> | Depends how intrinsically difficult they are, I guess. There seems to be a fair amount of accidential complexity in fromCharCode, but not an unmanageable amount |
| 10:07 | <matjas> | annevk: there are already polyfills for these written in ES5 |
| 10:08 | <annevk> | matjas: sure |
| 10:08 | <annevk> | matjas: not a fan of polyfills |
| 11:07 | <jgraham> | Ms2ger: I thought I reviewed some file api tests? |
| 11:07 | <Ms2ger> | Oh, right |
| 11:07 | <Ms2ger> | Someone needs to fix your comments |
| 11:08 | <jgraham> | Yeah |
| 11:08 | <Ms2ger> | Which I guess means me |
| 11:08 | <jgraham> | Well for the Moz. submission at least |
| 11:08 | <jgraham> | And the ms2ger submission |
| 11:09 | <jgraham> | Maybe zcorpan has time to fix https://critic.hoppipolla.co.uk/r/32 ? |
| 11:09 | <jgraham> | I don't think there's anything big there |
| 11:10 | <annevk> | hmm, writing a parser for this URL test format is more complicated than anticipated |
| 11:10 | <jgraham> | https://critic.hoppipolla.co.uk/r/238 still needs review though |
| 11:10 | <annevk> | maybe I should've taken more shortcuts |
| 11:10 | <jgraham> | annevk: Which language? |
| 11:10 | <jgraham> | Javascript? |
| 11:10 | <annevk> | yeah |
| 11:12 | <zcorpan> | annevk: what's complicating? |
| 11:12 | <jgraham> | Well if you have specific questions, I am happy to help |
| 11:13 | <annevk> | it's gonna be fine, it's just more work than I thought it'd be |
| 11:13 | <jgraham> | Not that I will necessarily be much help :) |
| 11:13 | zcorpan | was mostly curious |
| 11:14 | <annevk> | zcorpan: just the sheer number of states needed to do it on a per-character basis |
| 11:14 | <annevk> | zcorpan: and thinking of all the implications |
| 11:15 | <jgraham> | Hmm, isn't it relatively simple? |
| 11:16 | <jgraham> | You split on whitespace |
| 11:16 | <annevk> | that's cheating :) |
| 11:16 | <jgraham> | Then for each token containing a ":", split on that |
| 11:16 | <jgraham> | Then replace escapes |
| 11:17 | <annevk> | but okay, maybe I should do that |
| 11:17 | <jgraham> | Then pass the resulting tokens to a parser |
| 11:17 | <annevk> | I was trying to write something that didn't do double or triple passes |
| 11:17 | <jgraham> | Well you could do it one character at a time ofc, but I think in real life people usually reach for regexps for tokenisation |
| 11:17 | <annevk> | dude what is this? |
| 11:18 | <jgraham> | Unreal life? |
| 11:18 | <annevk> | Mario Kart? |
| 11:18 | <annevk> | I see |
| 11:18 | <hsivonen> | trololol: "XML 1.1 may have issues, but it's definitely not DOA." |
| 11:19 | <jgraham> | Well I mean your local neighborhood js engine probably has a fancy hand-written parser that works one character at a time |
| 11:19 | <zcorpan> | is it DBA? :-) |
| 11:19 | <jgraham> | and HTML requires it |
| 11:19 | <jgraham> | But lots of other things don't and don't |
| 11:19 | <annevk> | hsivonen: dude that bug... I don't even |
| 11:19 | <annevk> | Fortunately dbaron was there to save the day |
| 11:20 | <jgraham> | I think DOA might imply that it ever A |
| 11:30 | <hsivonen> | annevk: I succumbed into 386 and explained why 5th ed doesn't make sense |
| 11:57 | <annevk> | I ran across https://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/ |
| 11:57 | <annevk> | Is that still happening? |
| 11:59 | <Ms2ger> | nsid? |
| 11:59 | <Ms2ger> | Oh |
| 12:00 | <annevk> | Looks like it might obsolete the whole "return this" drive... |
| 12:00 | <Ms2ger> | Probably not harmonious |
| 12:00 | <annevk> | What is nsid? |
| 12:01 | <Ms2ger> | Nvm that :) |
| 12:34 | <zcorpan> | hsivonen: congrats on killing the old parser |
| 12:36 | <jgraham> | I thought it still did about:blank |
| 12:37 | <hsivonen> | zcorpan: thanks, but mrbkap wrote the latest patch |
| 12:37 | <hsivonen> | jgraham: it still does |
| 12:37 | <hsivonen> | jgraham: now with less code |
| 12:38 | <annevk> | jgraham: so yeah, this is not very fast |
| 12:39 | <annevk> | and I'm only splitting at this point |
| 12:42 | <zcorpan> | hsivonen: oh, so it's not completely dead yet? |
| 12:43 | <hsivonen> | zcorpan: not completely dead. like a zombie. |
| 12:44 | <hsivonen> | I don't think I like the idea of page-defined JSON.parse getting used by XHR |
| 12:51 | <annevk> | hsivonen: that's not the intent |
| 12:51 | <annevk> | hsivonen: there's an open bug on this |
| 12:51 | <hsivonen> | annevk: yeah |
| 13:05 | <annevk> | When iterating over a string in JavaScript. Is there an easier way to do this: |
| 13:05 | <annevk> | String.fromCharCode(Number.parseInt([input[++i], input[++i], input[++i], input[++i]].join(""), 16)) |
| 13:05 | <Ms2ger> | input[++i] + input[++i] + input[++i] + input[++i]? :) |
| 13:06 | Ms2ger | wonders if we should reference XML 4th ed explicitly in specs |
| 13:08 | <annevk> | XML is kinda like IDNA. Nobody really wants to make a decision... |
| 13:08 | <annevk> | Ms2ger: good point, not sure why I did the array thing |
| 13:10 | <Ms2ger> | Seems like hsivonen does want to make a decision :) |
| 13:15 | <jgraham> | Hmm, those lines look different to me |
| 13:15 | <jgraham> | What am I missing? |
| 13:15 | <jgraham> | annevk: I have a hard time imagining that str.split(" ") is slow |
| 13:23 | <accessPoint> | is it ok to put aside inside section and give it float right? |
| 13:25 | <Lachy> | accessPoint, yes. Why wouldn't it be? |
| 13:29 | <Lachy> | annevk, is the input variable in your code a string or an array? Surely, you could use input.substr(i, 4) if it's a string, or input.slice(i, i+4) if input is an array |
| 13:31 | <annevk> | fair enough |
| 13:31 | <annevk> | made it |
| 13:31 | <annevk> | String.fromCharCode(Number.parseInt(input.substr(++i, i += 3), 16)) |
| 13:32 | <Ms2ger> | But why... |
| 13:32 | <accessPoint> | thanks |
| 13:32 | <annevk> | Ms2ger: slightly shorter line and presumably faster? |
| 13:32 | <Ms2ger> | Don't presume before profiling :) |
| 13:33 | <Ms2ger> | Also somewhat less readable |
| 13:33 | <jgraham> | I wouldn't assume that's faster |
| 13:33 | <jgraham> | But I think it's more readable :p |
| 13:34 | <Ms2ger> | jgraham, compared to String.fromCharCode(Number.parseInt(input.substr(i, i + 4), 16)); i += 4? |
| 13:34 | <annevk> | that's not the same |
| 13:35 | <annevk> | it's pre-increment, not post |
| 13:35 | <Ms2ger> | Yet another reason to write it out |
| 13:35 | <annevk> | nah |
| 13:35 | <Ms2ger> | Well, it's your code, but don't expect me to read it :) |
| 13:37 | <Lachy> | using Ms2ger's method, it has to increment i, lookup the character at the index of the array, a new string and repeat 3 more times, and then finally concatenate each of the 4 strings into one. That seems far less efficient and less readable than simply using the native substr() method and incrementing i twice. |
| 13:39 | <Lachy> | also, annevk note that substr takes a (start, length) as parameters, not (indexA, indexB), so your i+=3 will grow larger depending on what i is. If you want to do it that way, use substring() |
| 13:39 | <annevk> | ooh |
| 13:40 | <annevk> | I wonder how that even worked for me then |
| 13:40 | <annevk> | ooh, because parseInt() is presumably silly |
| 13:47 | <jgraham> | Lachy: Looking up the method could be slow, or calling could be slow, depending on the implementation. Incrementing is fast, so the tradeoff is possible method call overhead vs possible extra allocations |
| 13:48 | <jgraham> | I agree the allocations might lose, but I would profile before I asserted it with confidence |
| 13:49 | <zcorpan> | heycam|away: why can't [NewObject] be used on attributes? is it bad API design? CSSOM does that for element.usedStyle et al |
| 13:50 | <annevk> | zcorpan: yes it is |
| 13:50 | <annevk> | zcorpan: you don't want obj.prop != obj.prop |
| 13:50 | <zcorpan> | ok |
| 13:53 | <annevk> | hmm, had to write |
| 13:53 | <annevk> | output += String.fromCharCode(Number.parseInt(input.substring(++i, (i += 3) + 1), 16)) |
| 13:53 | <annevk> | it becomes less readable by the minute |
| 13:54 | <annevk> | I'll go back to what I had before :) |
| 13:56 | <Ms2ger> | Clearly you need a wrapper around your strings |
| 13:56 | <Ms2ger> | String.fromCharCode(Number.parseInt(input.pop(4))) |
| 13:57 | <jgraham> | You need a wrapper around your wrapper input.pop(4).int_to_string() |
| 13:57 | <jgraham> | s/int/hex/ |
| 13:57 | <jgraham> | ;) |
| 14:06 | <annevk> | no |
| 14:07 | <zcorpan> | you need a wrapper factory factory |
| 14:17 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22939 - opinions on naming of the methods? can they be the same? element.usedStyle() |
| 14:36 | <annevk> | zcorpan: isn't CSSStyleDeclaration live? Or are you introducing a static variant? |
| 14:36 | <zcorpan> | annevk: it's not live for getComputedStyle or the GetStyleUtils variants |
| 14:36 | <zcorpan> | annevk: it's live for element.style |
| 14:37 | <annevk> | ah yeah |
| 14:37 | <annevk> | HTML typically uses get* |
| 14:39 | <zcorpan> | getRawComputedStyle is a bit long |
| 14:41 | <Ms2ger> | jgraham, want to merge https://github.com/w3c/web-platform-tests/pull/133 ? |
| 14:41 | <jgraham> | Done |
| 14:42 | <jgraham> | I always mis it when people review stuff on github |
| 14:42 | <Ms2ger> | Thanks |
| 14:50 | <matjas> | annevk: when iterating over the string, do you need UTF-16 code units, or code points? |
| 14:51 | <annevk> | matjas: former, it's input to JavaScript |
| 14:55 | <annevk> | matjas: that is, we hand these tests to <a>.href, <area>.href, new URL, etc. |
| 14:55 | <annevk> | once I've written all that out :-) |
| 15:11 | <JakeA> | Quick parsing question: When a <!-- is encountered within a <script>, are the "<!--" chars consumed as script content or does exit the script block & become an html comment? |
| 15:11 | <JakeA> | or does it exit* |
| 15:12 | <jgraham> | the behaviour of <!-- in script is... complex |
| 15:14 | <JakeA> | yeah, I couldn't get my head around the tokenizer |
| 15:16 | <jgraham> | Essentially it's not a HTML comment |
| 15:17 | <jgraham> | But <!-- acts like a line comment in ECMAScript |
| 15:17 | <annevk> | For HTML it has a special purpose in that it makes </script> not exit <script>, right? |
| 15:17 | <jgraham> | But there is some extra sublety I have apparently erased from my memory |
| 15:17 | annevk | is not sure that's up-to-date |
| 15:19 | <annevk> | JakeA: test e.g. <script><!--<script></script>--></script> in http://software.hixie.ch/utilities/js/live-dom-viewer/ |
| 15:19 | <jgraham> | Ah, right |
| 15:20 | <annevk> | The --> is not required though... I should read the parser again... |
| 15:20 | <jgraham> | iirc, the problem was that people would document.write("<!--<script></script>") or something |
| 15:21 | <JakeA> | The live DOM viewer is what the browser does though, right, not what the spec says |
| 15:21 | <JakeA> | or does it use its own parser? |
| 15:21 | <Ms2ger> | What the browser does |
| 15:21 | <Ms2ger> | But browsers are pretty close to the spec |
| 15:21 | <Ms2ger> | (If you find discrepancies, file bugs :)) |
| 15:24 | <JakeA> | Found a difference, but it looks like it's down to the resource scanner rather than the actual parser. No worries. |
| 15:24 | <annevk> | holy shit there's many script data states |
| 15:25 | <Ms2ger> | There'd better be |
| 15:27 | <annevk> | I'm not gonna study that |
| 15:50 | <annevk> | jgraham: so uh... according to my performance.now() comparison, running the URLTestParser only takes up to 7ms... |
| 15:51 | <jgraham> | Doesn't sound very slow :) |
| 15:51 | <annevk> | maybe I should test it again with substring |
| 15:51 | <annevk> | but it feels like a second |
| 15:51 | <jgraham> | Maybe the js console is slow |
| 15:51 | <annevk> | maybe it's the rest of Gecko that's lagging behind |
| 15:53 | <Hixie> | annevk: when nobody else is making a decision, just make one and see what happens :-) |
| 15:53 | <annevk> | not seeing the difference with substring(), not really surprising I guess given how fast it goes overall |
| 15:54 | <annevk> | Hixie: I've sort of made one, IDNA 2003 is the way to go I think (changing from that is not compatible), but registrars are not doing that (they are breaking compat sometimes, and sometimes just do something) |
| 15:55 | <annevk> | registrars are likely to follow the IETF, which broke compat as well (although they have various interesting ways of claiming they didn't) |
| 15:55 | <annevk> | ->FUCKED<- |
| 16:06 | <Hixie> | annevk: well people aren't going to buy names that don't work, so i wouldn't worry about the registrars so much |
| 16:13 | <annevk> | Guess I can do that after this test suite stuff is sorted |
| 16:14 | <annevk> | seems like something that'd need solving anyway for a fresh implementation (I've been thinking of writing the URL parser for Servo) |
| 16:15 | Ms2ger | would suggest getting it into rust-the-language directly |
| 16:17 | <annevk> | Ms2ger: you mean standard library? |
| 16:17 | <Ms2ger> | Yeah |
| 16:17 | <jgraham> | Sounds reasonable |
| 16:17 | <Ms2ger> | I mentioned it in passing in #rust a while back and there didn't seem strong objections at the time |
| 16:18 | <annevk> | mkay, I guess I'll try sort that out when I get to it |
| 16:18 | <annevk> | heycam|away: Hixie: hmm so yeah, should it be [Global=Window,Worker] or [Exposed=Window] |
| 16:19 | <annevk> | heycam|away: Hixie: maybe having both makes the most sense, [Global] for use by global objects and setting names you can use to refer to them and [Exposed] for non-global objects that are exposed on them |
| 16:19 | <Ms2ger> | [Global=Window,Worker] seems rather confusing with [Global] meaning "this is a global object" |
| 16:20 | <annevk> | heycam|away: Hixie: so e.g. [Global=Worker,SharedWorker] interface SharedWorkerGlobalScope {} or some such |
| 16:20 | <annevk> | heycam|away: Hixie: and [Global=Worker,DedicatedWorker] for the other one |
| 16:21 | <annevk> | Ms2ger: yeah |
| 16:21 | <TabAtkins> | annevk: Doing assignments inside of a function's arguments is the devil. |
| 16:22 | <annevk> | TabAtkins: heh, I was just toying around with the language |
| 17:17 | <Ms2ger> | "I'm working on exposing Chrome's paint events to the DOM so that sites can report visual metrics back as part of their RUM. I know there is a lot of controversy around paint events but it would be great if we could at least define how they could be exposed should a browser vendor decide to expose them." |
| 17:20 | <jgraham> | /sigh |
| 17:22 | <Hixie> | heycam|away: annevk: I'm fine with just [Global] on the global interface and naming them by interface name on the other objects, fwiw |
| 17:33 | <jwalden> | Ms2ger: is that for srs? |
| 17:34 | <jgraham> | jwalden: Yes |
| 17:34 | <jwalden> | egad |
| 17:34 | jwalden | idly wonders what RUM means |
| 17:35 | <jgraham> | http://lists.w3.org/Archives/Public/public-web-perf/2013Aug/0040.html |
| 17:35 | <jgraham> | Runtime U-something Metrics, perhaps |
| 17:35 | <jgraham> | UA? |
| 17:59 | <jsbell> | Ms2ger: With the caveat that I know nothing about that particular effort, I can sympathize. For IndexedDB there are lots of questions we want to ask about performance and behavior. We can get aggregated, anonymized stats via opt-in mechanisms, but we know site developers who use dev tools to get fine grained detail like event timing want to get that same sort of data en masse from "the field", even though it's not data we should expose via an |
| 17:59 | <jsbell> | y APIs. We're brainstorming how without exposing any web surface area (optional site-specific extension, maybe?) |
| 18:00 | <jsbell> | Ms2ger: maybe point whoever was talking about those paint events my way? |
| 18:06 | <jwalden> | seems like devtools in the browser should serve the need just as well, to me |
| 18:06 | <accessPoint> | how can I align img to center without using align attribute and without text-align center? |
| 18:07 | <Ms2ger> | Abspos? |
| 18:07 | <Ms2ger> | Flexbox? |
| 18:11 | <paul_irish> | jwalden: RUM is real user metrics.. so it's all about collecting data from the field, where things are a bit more wild than in a CI setup using some devtools APIs |
| 18:12 | <paul_irish> | that said, i don't think that exposing individual paint events may be useful for RUM. some of the metrics like what's exposed in https://twitter.com/ChromiumDev/status/357914389132746752/photo/1 may be better |
| 18:31 | <accessPoint> | where can I put html comments and where I can't - this isn't written in the w3c html spec |
| 18:54 | <Hixie> | accessPoint: in the whatwg spec, it's in the syntax section near the end |
| 18:54 | <Hixie> | accessPoint: basic answer is that you can put them between other elements |
| 18:54 | <Hixie> | accessPoint: with exceptions for elements that only accept text like <textarea>, <title>, <script>, <style> |
| 19:01 | <accessPoint> | Hixie, can I put it inside elements and before doctype and before html element and in the head element and in the title element? |
| 19:02 | <accessPoint> | wait I will check the WHATWG spec |
| 19:02 | <accessPoint> | sorry for annoying I was reading W3C nighty spec |
| 19:10 | <accessPoint> | Hixie, there isn't answer in the web dev spec edition :S |
| 19:10 | <accessPoint> | can you or someone answer me please I didn't got help elsewhere I think noone knows for sure |
| 19:13 | <zcorpan> | uh, getComputedStyle *is* live |
| 19:31 | <zcorpan> | accessPoint: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#writing |
| 19:33 | <zcorpan> | accessPoint: http://developers.whatwg.org/syntax.html#syntax has that also |
| 19:36 | <zcorpan> | accessPoint: so, inside elements: depends on the element, before doctype: yes, before html: yes, in the head: yes, in the title: no |
| 19:36 | <Hixie> | accessPoint: sorry, was out to lunch |
| 19:36 | <Hixie> | accessPoint: what zcorpan said |
| 19:43 | <accessPoint> | zcorpan, thanks Hixie no problem man thank yo utoo thank you guys keep up the good work appreciate everything! |
| 19:44 | <zcorpan> | accessPoint: <title><!----></title> isn't invalid, but it doesn't contain a comment, it just contains text. similarly to how it works in <script> |
| 19:45 | <accessPoint> | ok thanks zcorpan |
| 19:45 | <zcorpan> | np |
| 20:26 | <zcorpan> | Hixie: do we need to differentiate between dedicated and shared workers for [Exposed]? |
| 20:30 | <Hixie> | only rarely |
| 20:30 | <Hixie> | but yes |
| 20:31 | <Hixie> | e.g. you can't get a DedicatedWorkerGlobalScope in a shared worker |
| 20:46 | <zcorpan> | Hixie: but DedicatedWorkerGlobalScope is the global, so it doesn't make sense for it to use [Exposed] i think |
| 20:46 | <Ms2ger> | https://www.webkit.org/blog/2910/improved-support-for-high-resolution-displays-with-the-srcset-image-attribute/ |
| 20:47 | <Hixie> | zcorpan: oh you're saying anything with [Global] should just not be exposed unless it's the global? lgtm |
| 20:47 | <Hixie> | zcorpan: in that case yeah, we should have Global name its kind |
| 20:48 | <zcorpan> | Hixie: i didn't say that :-) i'm wondering if it makes sense for an API not defined in the Worker spec itself to expose something only in dedicated workers or only in shared workers |
| 20:49 | <Hixie> | i don't know of any so far, off-hand |
| 20:51 | <zcorpan> | ok. so then we probably don't need to provide that ability in the idl syntax |
| 20:53 | <Hixie> | i can't believe i didn't provide an event for <details> and nobody has made a case for adding one |
| 20:53 | <Hixie> | onopen/onclose event, i mean |
| 20:53 | <Hixie> | (onclick is useless since it fires before it opens, so you don't know the state) |
| 20:56 | <Hixie> | also, firefox doesn't yet support <details>?! |
| 20:57 | <zcorpan> | so if [Global] uses the name of the interface, and we put it on WorkerGlobalScope and Window, specs can use [Exposed=Window,WorkerGlobalScope]. which is longer than [Exposed=Window,Worker]. so it might be worth it to use [Global=Worker] on WorkerGlobalScope instead |
| 21:02 | <zcorpan> | Hixie: iirc, there were various things about <details> that made it hard to implement in a sane way, at least in presto, so it was punted. i'm not sure what the situation is for gecko. but maybe we should look into the issues and possibly change the spec |
| 21:02 | <zcorpan> | i wasn't involved in that myself so i'm not sure what the issues were exactly |
| 21:03 | <zcorpan> | Lachy: ^ |
| 21:04 | <zcorpan> | what's the difference between w3c-srcset and whatwg-srcset? |
| 21:07 | <zcorpan> | "This is an automated redaction of the relevant portions of that document." http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/ says |
| 21:10 | <Hixie> | whatwg-srcset is one step closer to what has been proofread. |
| 21:11 | <Hixie> | wouldn't the [Global] go on SharedWorkerGlobalScope and DedicatedWorkerGlobalScope? |
| 21:30 | <GPHemsley> | busy busy busy |
| 21:32 | <zcorpan> | Hixie: why? |
| 21:32 | <Hixie> | because they're the globals |
| 21:33 | <zcorpan> | they inherit from WorkerGlobalScope |
| 21:59 | <Hixie> | HTMLElement.prototype instanceof Node == true? o_O |
| 22:04 | <Hixie> | that entire thread is baffling |
| 22:23 | <Domenic_> | That's pretty standard... HTMLElement.prototype = Object.create(Element.prototype); Element.prototype = Object.create(Node.prototype); ... that's how JS inheritance works... |
| 22:39 | <TabAtkins> | Yeah, your prototype won't be instanceof your leaf class, but it should be instanceof any superclasses. |
| 23:11 | <Hixie> | interesting definition of "instanceof" |
| 23:13 | <TabAtkins> | The definition is "take the prototype of the RHS, then walk the prototype chain of the LHS until you either find a match or hit null/cycle" |
| 23:13 | <TabAtkins> | Prototypal inheritance is different from classical inheritance. |
| 23:22 | <Hixie> | i would expect "instanceof" to tell me if something is an instance of something, and it's not clear to me that a prototype of an element is an instance of Node |
| 23:39 | <TabAtkins> | That's because you don't intuitively understand what prototypal inheritance does. It's very natural that your prototype is an instance of your superclass. |
| 23:40 | <TabAtkins> | The two basic patterns are very similar - one's the "examplar" pattern, where the prototype is some "typical" instance of the superclass. |
| 23:40 | <TabAtkins> | The other is where the prototype chains are actually separate objects from the instances, and so don't have any per-instance state. |
| 23:40 | <TabAtkins> | But regardless, yes, you are instanceof your class, your prototype is instanceof your superclass, etc. |
| 23:42 | <TabAtkins> | (Domenic's example was the second type - using Object.create to just make fresh objects with the right prototype, rather than going through the constructor to achieve the same thing and possibly getting per-instance state added to you.) |
| 23:43 | <TabAtkins> | You really *shouldn't* be type-checking your prototypes (it doesn't make sense if you're not using examplars, and even then doesn't make very much sense), but if you do, that's the answer you get. |