| 00:15 | <Hixie> | SamB: the other files aren't mind as far as i know |
| 00:15 | <Hixie> | smaug____: recently? |
| 00:16 | SamB | wonders if annevk mader them? |
| 00:16 | <Hixie> | probably |
| 00:16 | <Hixie> | smaug____: i don't recall anything on this one way or the other, but looking... |
| 00:17 | <smaug____> | not very recently |
| 00:17 | <smaug____> | after Aug 18 20:30:41 2010 |
| 00:21 | <Hixie> | i can't find anything that would affect that that is different between then and now |
| 00:21 | <smaug____> | ok, thanks |
| 00:21 | <Hixie> | (looked through today's spec, and r5372) |
| 00:22 | <Hixie> | i could well be missing something though |
| 00:22 | <Hixie> | my apologies in advance if so! |
| 01:22 | <MikeSmith> | Hixie: here now |
| 01:26 | <MikeSmith> | Hixie: btw http://zzyzwicz.w3.org/ is the old w3c-test.org host |
| 01:36 | <MikeSmith> | krit_: http://dev.w3.org/FXTF/ is working again |
| 01:37 | <MikeSmith> | for now |
| 01:38 | <MikeSmith> | due to http://dev.w3.org/cvsweb/FXTF/.htaccess.diff?r1=1.1;r2=1.2;f=h |
| 01:38 | <MikeSmith> | but I'm not going to be able to get that there forever |
| 01:39 | <MikeSmith> | that host is slated for retirement |
| 01:40 | <MikeSmith> | but anyway it should be enough until Peter gets it set up at drafts.csswg.org somewhere |
| 07:26 | <foolip_> | TabAtkins, jgraham, if I get to pick I just drop the two dots in my last name to make it Jagenstedt |
| 07:27 | <foolip_> | TabAtkins, jgraham, however, I don't think รค to ae is actually wrong per any official rules |
| 07:28 | <foolip_> | just not mangling names seems like a good option :) |
| 15:33 | <qFox> | is there any safe way to detect whether document.write is currently "blocked"? (like when you write a blocking tag with external resource, the next writes are blocked) |
| 15:34 | <qFox> | i was thinking of writing a proxy script tag to invoke an actual docwrite, but that would break partial docwrites :/ |
| 15:38 | <krijn> | Rtfm! |
| 16:34 | <SamB> | qFox: document.write? really? |
| 16:35 | <qFox> | i hope krijn is still logging this channel |
| 16:35 | <qFox> | can we pleaaaase get over the whole "really" thing quick? i'm not using it, i have to emulate it. |
| 16:36 | <SamB> | qFox: oh, that's okay then |
| 16:36 | <SamB> | I mean, it still sucks, but it seems a decent excuse |
| 16:37 | <qFox> | :) |
| 16:38 | <qFox> | it's really bad because there's no way to cleanly determine insertion point, and there's this blocking thing which is really fubar. and then there are partial docwrites. and ugh. |
| 16:38 | <qFox> | we've come a long way in our support, but some of the ad network edge cases are slowly catching up to us. this partial thread blocking is one of them. |
| 16:39 | <qFox> | just for context; if you do a docwrite that writes a blocking tag that's loading something external, it will _only_ block future docwrites but not the main thread |
| 16:39 | <qFox> | i kind of need to know whether document.write is blocked or not. explaining why will take a long monologue so i'm hoping to skip that :) |
| 16:41 | <jgraham> | qFox: I have literally no idea what you are trying to achieve, but have you read http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#document.write%28%29 ? |
| 16:41 | <odinho> | finn.no also seem to be doing some ad cleaning these days. |
| 16:42 | <jgraham> | There isn't an easy web-exposed way to do what you want, I don't think, but perhaps you can reverse-engineer what you need from the algorithm |
| 16:43 | <jgraham> | (note that most of the state is set elsewhere, notably in the HTML parser and script loader) |
| 16:43 | SamB | would go for something like "block adscripts that use document.write" ... |
| 16:44 | <jgraham> | Well fundementally you either put ads in an iframe on a seperate domain or you entirely trust them |
| 16:45 | <jgraham> | The fact that people don't trust them, but place them inline in their markup is upsetting |
| 16:47 | <qFox> | i think they dont have a choice right now |
| 16:48 | <qFox> | but tbh my requirement is more generic. I'd say it's slightly below that of a browser vendor. |
| 17:36 | <qFox> | fwiw, this is my problem: http://jsbin.com/coviyuyo/2 (convoluted example of a real world case). and to repeat, i dont write this crap myself, i need to support it. |
| 17:38 | <qFox> | i'm going to solve it by checking the written content (we already parse it anyways) for such blocking tags. if so, mark entire docwrite as "blocked" for the remainder of the page load. defer any write calls and execute them "onload". or well, that's what i'm going to try. |
| 17:38 | <qFox> | the only thing i need to check is whether writing an external script will block the html parser _after_ the current script finishes. if that's not the case, the above should be sound generically. otherwise there is still an edge case left, but we'll cross that bridge... |
| 19:00 | SamB | pokes around looking for an op ... |
| 19:00 | <Ms2ger> | You called? |
| 19:02 | <SamB> | what's the channel policy for cases like taijeen, who is getting "ping timeout" every few minutes or so? |
| 19:02 | <SamB> | though maybe his connection is better now? |
| 19:03 | <Ms2ger> | Yeah, it was <1 minute before |
| 19:06 | SamB | had such a thing happen to him not so many months ago, and he got banned from a number of channels just as a practical matter |
| 19:09 | <Ms2ger> | I'm happy to do temporary bans if need be, fwiw |
| 19:10 | SamB | toys with the idea of a new IRC connection protocol that could avoid all that join/part noise by smoothing over short disconnections somehow for a few minutes |
| 19:16 | <TabAtkins> | SamB: That already exists; it's called "IRCCloud". |
| 19:19 | <SamB> | The fact that I'm not familiar with, or using, that would seem to indicate that I was right in thinking to myself that it would be at the very least a LOONG time before it would replace the old protocol |
| 19:21 | SamB | wishes there was something like the CSS "snapshots" for IRC ... |
| 19:29 | <TabAtkins> | SamB: IRCCloud is just a webapp that does IRC for you. It keeps you in the room all the time and maintains history across windows. |
| 19:29 | <TabAtkins> | My response was somewhat snarky. |
| 19:29 | <SamB> | ah |
| 19:30 | <jgraham> | It's also very funny |
| 19:30 | <SamB> | so it's sort of like mibbit |
| 19:30 | <jgraham> | When IRCCloud loses connectivity |
| 19:30 | <jgraham> | and all of Google disappear |
| 19:31 | <SamB> | I was thinking some sort of protocol that the actual IRC servers would speak. Of course, this wouldn't help with netsplits, and you'd probably need to reconnect to the same server as last time ... |
| 19:36 | <Hixie> | Ms2ger, SamB: unless it's actually interrupting conversations, we should just let them be |
| 19:41 | <SamB> | Hixie: Yes, obviously only ban people if it's actually causing trouble. (Which gets a bit trickier to define in a publicly-logged channel, I guess.) I was thinking about saying something to qFox when I mentioned it, and it wasn't clear that the problem was gone yet ... |
| 19:42 | <Hixie> | yeah |
| 19:42 | <qFox> | fwiw, the problem isn't gone. i'm just going to work around it best i can. unless somebody has a great insight :) |
| 19:43 | <qFox> | or would like to propose exposing these properties ;) |
| 19:43 | <SamB> | qFox: not that problem, the repeated "ping timeout" parts/joins |
| 19:43 | <SamB> | your problem is indeed clearly not gone :-( |
| 19:43 | <qFox> | > I was thinking about saying something to qFox <-- then i dont get that? |
| 19:43 | <SamB> | qFox: I got distracted thinking about IRC, sorry |
| 19:44 | <qFox> | haha ok |
| 19:44 | <Hixie> | qFox: fwiw, i feel your pain with respect to emulating document.write(). it's probably the most complicated aspect of the platform. not sure i have anything to help you though. |
| 19:44 | <qFox> | i think i have to agree. eval and with were a breezer compared to insertion point |
| 19:44 | <SamB> | is it important that the emulation ever use real document.write() ? |
| 19:44 | <Hixie> | (well, the AAA might be slightly worse. but only slightly, and it's more self-contained.) |
| 19:45 | <SamB> | AAA ? |
| 19:45 | <qFox> | Hixie: what's the AAA? |
| 19:45 | <TabAtkins> | Adoption Agency Algorithm. |
| 19:45 | <Hixie> | part of the parser |
| 19:45 | <SamB> | oh |
| 19:45 | <qFox> | ah |
| 19:45 | <TabAtkins> | What reparents things nested incorrectly in th emiddle of a <table> |
| 19:45 | <Hixie> | handles misnested formatting elements |
| 19:45 | <Hixie> | TabAtkins: that's foster parenting |
| 19:45 | <TabAtkins> | Oh, right, it's that one. |
| 19:45 | <Hixie> | TabAtkins: that's a lot less complicated :-) |
| 19:45 | <qFox> | actually, from our point of view, AAA is part of the docwrite problem |
| 19:45 | <qFox> | because that determines insertion point as well |
| 19:45 | <SamB> | hmm |
| 19:45 | <qFox> | though the term is different, i recognize that |
| 19:46 | <Hixie> | the AAA should be relatively self-contained, how does it affect d.w()? |
| 19:46 | <qFox> | Hixie: we have a heuristic to "guess" the insertion point of a docwrite. but if you write a <p> while inside a <p>, that affects this point |
| 19:47 | <SamB> | d.w("<table>"); d.w("<hr>"); // ? |
| 19:47 | <qFox> | so for us the problem is double; we dont know whether a tag is closed (can't just go for .lastChild) and we have to be conscious about contextual insertion |
| 19:48 | <Hixie> | qFox: why would d.w() care what the DOM is? i'm confused. the insertion point isn't in the DOM, it's in the input stream to the parser. |
| 19:48 | <qFox> | SamB: our current/old approach was to serialize and sanitize stuff using the DOM, rather than a parser. stuff like TR disappeared :/ |
| 19:48 | <qFox> | Hixie: ok I'm clearly mixing up terminology too much. |
| 19:48 | <qFox> | Hixie: we have to know exactly where new content is introduced when somebody docwrites |
| 19:49 | <qFox> | for us, that's the insertion point. how should i call it? |
| 19:49 | <Hixie> | there's no one point |
| 19:49 | <Hixie> | it depends what you're inserting |
| 19:49 | <Hixie> | but "current node" is probably the closest to what you mean |
| 19:49 | <qFox> | ok sure |
| 19:50 | <Hixie> | e.g. <table><script>document.write('<br><tr>');</script> will insert a <br> before the "table" element, in the "body" element, and a "tbody" in the "table" element, after the "script" element. |
| 19:50 | <Hixie> | (and then a "tr" inside the "tbody") |
| 19:50 | <qFox> | and the current node, for us, depends on the AAA and the insertion point. actually, i'm not sure if there's any other big things that might affect it. |
| 19:51 | <SamB> | qFox: was the reason you have to emulate d.w() rather than using the actual thing the long story you wanted to avoid telling? |
| 19:51 | <qFox> | Hixie: do you know/remember the rationale for the "async docwrite" behavior when docwriting an external script tag? |
| 19:51 | <Hixie> | The current node shouldn't depend on the AAA or the insertion point. The current node is just the last node added to the stack of open elements. |
| 19:51 | <qFox> | SamB: kind of :) see surfly.com, see if that answers some questions |
| 19:51 | <Hixie> | qFox: "it's what browsers do" is the rationale to almost all of the d.w() stuff. |
| 19:51 | <qFox> | yeah but there's always a reason :) |
| 19:52 | <SamB> | qFox: some moron made it work that way? |
| 19:52 | <Hixie> | lost in the mists of time from back when Netscape and IE were fighting the first browser war |
| 19:52 | <qFox> | Hixie: the current node depends on AAA because of stuff like writing a p in another p, or a TR outside of a table scope. it changes where the content is put |
| 19:52 | <SamB> | or, well, someone who was merely unable to predict the consequences of their actions |
| 19:52 | <Hixie> | the AAA has nothing to do with <p> in another <p> or <tr> outside a <table>? |
| 19:52 | <qFox> | Hixie: and it depends on insertion point because, well, partial docwrites. |
| 19:52 | <Hixie> | <tr> outside a <table> just does nothing |
| 19:53 | <SamB> | qFox: so what is it that you want to do here? |
| 19:53 | <Hixie> | and <p><p> just causes a </p> to be implied |
| 19:53 | <Hixie> | it's the same as <p></p><p> |
| 19:53 | <qFox> | ah jeez. AAA is about moving nodes between docs :/ |
| 19:53 | <qFox> | ugh it's been a long day. |
| 19:54 | <qFox> | yeah |
| 19:54 | <qFox> | those rules, whatever it's named, also affect the current node for us |
| 19:54 | <SamB> | TabAtkins seems to have gotten us confused about the naming ;-) |
| 19:54 | <Hixie> | AAA is about things like <code><em></code> |
| 19:55 | <qFox> | SamB: basically, we'll still do a docwrite, but we want to know where into what node it'll be inserted because we'll sync it as an insertAdjacentHTML call. basically... |
| 19:55 | <Hixie> | foster parenting is about <table><br> and stuff |
| 19:55 | <Hixie> | qFox: i think the short answer is that you have no way to know what the parser would do without being hte parser |
| 19:55 | <Hixie> | qFox: unless you control all the script |
| 19:56 | <SamB> | so, basically there are two things that you can do |
| 19:56 | <Hixie> | qFox: because nothing stops a page from taking the current element and grafting it into another document, say, and then document.write() would actuallly be inserting nodes into that other doc. |
| 19:56 | <SamB> | (1) re-implement the HTML5 parser |
| 19:56 | <Ms2ger> | If you're interested in that... |
| 19:56 | <Ms2ger> | Want to come and work on Servo? |
| 19:56 | <SamB> | (2) picket vendors and the WHATWG to give you ways to interrogate the browser's parser |
| 19:56 | <qFox> | Hixie: ehhh. oh. meh. |
| 19:56 | <qFox> | then i suppose i dont care about it so much in this context :) |
| 19:56 | <qFox> | but just to be sure; there's no way of knowing whether a tag has been closed or not. right? |
| 19:57 | <qFox> | wow, irc the slow? |
| 19:57 | <Hixie> | there's no way i can think of, in general, to know if a particular element is on the stack of open elements (which i guess is what you mean by "has been closed or not") |
| 19:58 | <qFox> | Hixie: let's say we do control the whole page? how would it be possible then? short of xhr'ing the entire html and parsing it manually of course |
| 19:58 | <Hixie> | (you can kind of tell with some elements, e.g. <video> and <object>, maybe) |
| 19:58 | <SamB> | Hixie: that seems like a pretty reasonable way to define "closed", yes |
| 19:58 | <Hixie> | if you control the whole page, you can dramatically simplify your life by just limiting what's possible |
| 19:58 | <SamB> | i.e. as "not open" |
| 19:58 | <Hixie> | for example, by preventing anyone from ever calling document.write() |
| 19:58 | <Hixie> | :-) |
| 19:58 | <Hixie> | SamB: you'd be surprised how many definitions one could come up with |
| 19:59 | <Hixie> | SamB: (and how many are actually useful) |
| 19:59 | <Hixie> | SamB: (e.g. <div><em></div> - is the <em> open? it's not on the stack.) |
| 19:59 | <Hixie> | SamB: (but if you do <div><em></div>A, it turns into the same as <div><em></em></div><em>A</em>, so maybe it _is_ open? or its clone is? or something?) |
| 20:00 | <SamB> | Hixie: okay, yes, I see what you mean |
| 20:00 | <SamB> | what is "the element"? |
| 20:01 | <SamB> | is it the tag-soup range in the actual document, or a DOM node |
| 20:01 | <qFox> | Hixie: yeah that's what I mean. ok. |
| 20:01 | <Hixie> | yeah. the HTML parser is one of those few things that i've concluded can only be discussed in real terms, without simplification, unfortunately. |
| 20:01 | <Hixie> | most things you can abstract things out and talk about in general terms quite successfully. |
| 20:02 | <SamB> | so perhaps we need terms for each applicable idea of "element"? |
| 20:02 | <Hixie> | well, here what matters is that the <em> is no longer on the stack but is on the "list of formatting elements" |
| 20:03 | <Hixie> | list of active formatting elements? |
| 20:03 | <Hixie> | whatever i called it |
| 20:03 | <Hixie> | bbiab, lunch |
| 20:03 | <qFox> | ok, inception case here, but what if you docwrite an external script. does it block the html parser _after_ the current script completes? |
| 20:03 | <qFox> | basically, can somebody reliably do this? <script>docwrite(<script src=foo>); docwrite(important stuff);</script><script>refer to important stuff</script> |
| 20:03 | <qFox> | i'm sensing freenode will split soon :/ |
| 20:03 | <SamB> | so a "formatting element" is the tag soupy thing, then? |
| 20:04 | <SamB> | qFox: what might the nature of "important stuff" be? |
| 20:04 | <qFox> | Hixie: the thing is we want to generically render a site as original, so limiting is not an option :) |
| 20:06 | <qFox> | fwiw, I would say an element is "closed" if there's no way for me to docwrite into it anymore :) But that definition might be too closely bound to my current use case for it. |
| 20:06 | <SamB> | qFox: okay, this explains why you want to support nasty ad networks pretty well |
| 20:06 | <qFox> | If I can't docwrite into it, it can't be the future parent of the content that's being written and I won't have to care about it. |
| 20:07 | <qFox> | SamB: well. we just want to be generic. ad networks are just nasty and do pretty much anything that one might consider "edge case". so we can't really slack here. |
| 20:07 | <SamB> | qFox: so, you don't care that another element node might later arise due to a particular tag that has already produced an element node? |
| 20:08 | <qFox> | SamB: not sure what you mean there? |
| 20:08 | <SamB> | qFox: well, yes, I mean it explains why you can't just decide that ad networks have to shape up if they want to work with your thing |
| 20:08 | <SamB> | qFox: well, like that <div><em></div> example |
| 20:09 | <qFox> | ah. well no. if i docwrite, and the start of the content ends up inside the <em>, that's all i care about. |
| 20:09 | <qFox> | in the end, the insertAdjacentHTML approach will have to be fixed I guess since it can't cover node boundary breaking writes properly. but one step at a time :) |
| 20:09 | <SamB> | do you care that another <em> element might crop up later without any intervening <em> tag? it sounds like the answer is "no". |
| 20:10 | <qFox> | actually, tbh, i think it matters. |
| 20:10 | <qFox> | the whole principle is to try and sync the two doms in virtually every way |
| 20:10 | <SamB> | can't you notice the new node when it happens? |
| 20:11 | <qFox> | well there's mutation obs. but that's not reliably supported for us. how else would you? |
| 20:12 | <SamB> | well, how do you normally see what nodes d.w() has added to the DOM? |
| 20:13 | <qFox> | we hook into _everything_. all the node affecting api's, we know about them |
| 20:14 | <Ms2ger> | Anybody have a synonym for optional that doesn't sound like "option"? |
| 20:14 | <qFox> | conditional |
| 20:14 | <SamB> | Ms2ger: what's the context? |
| 20:15 | <qFox> | SamB: docwrite is one of the few where you cant really predict what's gonna happen in terms of DOM mutations. |
| 20:15 | <Ms2ger> | SamB, optional arguments in Rust, where Option is already taken for nullability |
| 20:15 | <qFox> | SamB: innerhtml is also one, but that's mainly just an expensive operation for us. it's containable otherwise. I suppose, worst case, so is a document write. but we don't really want to go that far. |
| 20:16 | <SamB> | Ms2ger: you mean like defaulted arguments? |
| 20:16 | <Domenic_> | Ms2ger: defaultable |
| 20:16 | <SamB> | or otherwise couldn't just use Option arguments |
| 20:16 | <SamB> | +you |
| 20:16 | <Ms2ger> | This is explicitly for the case where you don't have a default in IDL, though |
| 20:17 | <qFox> | NoDef |
| 20:17 | <SamB> | Ms2ger: isn't that what Option is *for*? |
| 20:18 | <Ms2ger> | SamB, sorta, but it idiomatically means "nullable", which I want to distinguish it from |
| 20:18 | <Ms2ger> | So really what I'm saying is that the language took my lunch money :) |
| 20:19 | <SamB> | so does this mean that "Option Option Foo bar" or whatever is sensless? that seems like you should have just used the word "nullable" in the first place ... |
| 20:20 | <SamB> | that's the royal "you", I guess |
| 20:20 | <SamB> | or, well, plural |
| 20:21 | <Ms2ger> | I prefer "they" :) |
| 20:21 | <Ms2ger> | Option Option works, but is not exactly obvious |
| 20:22 | <SamB> | Ms2ger: if it doesn't do the same thing as Option, I don't see why using regular Option on the Rust side would be bad here? |
| 20:22 | <Ms2ger> | Readability :) |
| 20:23 | <Ms2ger> | Anyway, I'll stick with that for now |
| 20:25 | <qFox> | <qFox> basically, can somebody reliably do this? <script>docwrite(<script src=foo>); docwrite(important stuff);</script><script>refer to important stuff</script> |
| 20:26 | <qFox> | what should be the answer here? because if it's "no", then I'm fairly safe for parsing the docwrite content, recognizing blocking content, and setting a flag that write is blocked for this doc. i'll stash all writes and defer them to onload. |
| 20:26 | <qFox> | i'm not sure about a backtoback write that causes a block yet, but one step at a time |
| 20:26 | <Ms2ger> | Hmm |
| 20:31 | <jgraham> | Ms2ger: Defined(foo) | Undefined might be nice |
| 20:31 | <jgraham> | Not sure what to call the type though |
| 20:31 | <Ms2ger> | That's the main issue :) |
| 20:31 | <jgraham> | "Maybe"? Confuse all the Haskellers ;) |
| 20:31 | <Ms2ger> | Evil... I like it: ) |
| 20:32 | <SamB> | that's what I would have called the first one ;-P |
| 20:32 | <jgraham> | Ommitable? |
| 20:44 | <GPHemsley> | globbot GPHemsley |
| 20:44 | <globbot> | GPHemsley, found more than 20 results, showing 3 |
| 20:44 | <globbot> | Mar 4 19:30 <Hixie> GPHemsley: maybe? |
| 20:44 | <globbot> | Feb 20 2014 <zcorpan> GPHemsley: http://mimesniff.spec.whatwg.org/#parse-a-mime-type compares bytes to code points |
| 20:44 | <globbot> | Feb 13 2014 <jgraham> GPHemsley: First expand it to Msmsger |
| 20:44 | <GPHemsley> | TIL |
| 20:45 | <Ms2ger> | Wat |
| 20:45 | <Hixie> | we have a bot! how long have we had a bot! |
| 20:47 | <Ms2ger> | It's glob's logbot |
| 20:47 | <Ms2ger> | It was added to the topic nearly two years ago |
| 20:49 | Hixie | pokes globbot |
| 20:49 | <Hixie> | globbot globbot |
| 20:49 | <globbot> | Hixie, found 3 results |
| 20:49 | <globbot> | Mar 6 20:49 * Hixie pokes globbot |
| 20:49 | <globbot> | Mar 6 20:44 <GPHemsley> globbot GPHemsley |
| 20:49 | <globbot> | Aug 10 2012 <krijn> The globbot thing looks handier |
| 20:50 | Hixie | feels better |
| 20:50 | <GPHemsley> | heh |
| 20:50 | <GPHemsley> | Ms2ger was pretty spot-on with that date |
| 20:51 | <Ms2ger> | Sometimes it's nice to have a static topic :) |
| 20:54 | <GPHemsley> | The topic hasn't changed in 2 years? |
| 20:54 | GPHemsley | cires |
| 20:56 | <SamB> | globbot: topic |
| 20:56 | <globbot> | SamB, found more than 20 results, showing 3 |
| 20:56 | <globbot> | Mar 6 20:54 <GPHemsley> The topic hasn't changed in 2 years? |
| 20:56 | <globbot> | Mar 6 20:51 <Ms2ger> Sometimes it's nice to have a static topic :) |
| 20:56 | <globbot> | Mar 6 20:47 <Ms2ger> It was added to the topic nearly two years ago |
| 20:56 | <GPHemsley> | globbot: 10 topic |
| 20:56 | <globbot> | GPHemsley, found 0 results |
| 20:56 | <GPHemsley> | globbot: topic 10 |
| 20:56 | <globbot> | GPHemsley, found 0 results |
| 20:56 | <GPHemsley> | hmph |
| 20:57 | <GPHemsley> | globbot: W3C |
| 20:57 | <globbot> | GPHemsley, found more than 20 results, showing 3 |
| 20:57 | <globbot> | Mar 6 01:26 <MikeSmith> Hixie: btw http://zzyzwicz.w3.org/ is the old w3c-test.org host |
| 20:57 | <globbot> | Mar 5 21:33 <Ms2ger> Hixie, I think someone scraping w3c-test? |
| 20:57 | <globbot> | Mar 5 19:51 <SamB> hmm, it never occurred to me to wonder how the w3c got w3.org before ... |
| 20:57 | <Ms2ger> | Srsly |
| 20:58 | <Ms2ger> | This is the second time today a channel has started playing with logbot |
| 20:58 | <Hixie> | heh |
| 20:58 | <GPHemsley> | Well, I just learned that it existed because we had one added to a Mozilla channel |
| 20:58 | <GPHemsley> | so they may be related |
| 20:58 | <Ms2ger> | Was it #intellego? |
| 20:58 | <GPHemsley> | Yeah |
| 20:59 | <Ms2ger> | It was the people who came looking for it the last time, yes |
| 20:59 | <GPHemsley> | What was the other channel? |
| 21:00 | <Ms2ger> | #introduction |
| 21:00 | <GPHemsley> | ah |
| 21:48 | <Domenic_> | DOMString[] in WebIDL means "JavaScript array of strings"? Or is that sequence<DOMString>? |
| 21:48 | <heycam> | Domenic_, DOMString[] will go away |
| 21:48 | <heycam> | it means "host object that behaves similarly to an array but isn't a JS Array object" |
| 21:48 | <heycam> | sequence<> is the one that means array object |
| 21:48 | <Domenic_> | Ah OK, thanks. |
| 21:49 | heycam | remembers he needs to email you and some others about sicking's array proposals |
| 21:49 | <Domenic_> | Apparently various places in Gecko that use DOMStringList are currently specced to use DOMString[] |
| 21:49 | <Domenic_> | Curious whether we can replace them with real arrays or if there's web code depending on contains() or item() |
| 21:50 | <heycam> | yeah we would like to replace them with real JS Arrays |
| 21:50 | <sicking> | Domenic_: it's somewhat unknown. The only "important" difference is that DOMStringList has a .item(number) function |
| 21:50 | <Domenic_> | well also contains() |
| 21:50 | <sicking> | Domenic_: but it might not be used enough to matter |
| 21:50 | <heycam> | the difficulty, and the reason that the DOMString[] thing was introduced, was (a) checking and throwing when you interact with the array incorrectly, and (b) having the DOM object watch for changes to the array |
| 21:50 | <Domenic_> | http://esdiscuss.org/topic/array-prototype-contains#content-69 |
| 21:51 | <sicking> | Domenic_: ooooh. I had missed that :( |
| 21:51 | <sicking> | Domenic_: i forgot that DOMStringList has .contains |
| 21:51 | <sicking> | Domenic_: so silly that Array doesn't :( |
| 21:51 | <Domenic_> | sicking: well there's talk of adding .contains(). But IMO adding .has() would be more consistent with Set, Map, etc. |
| 21:52 | <sicking> | Domenic_: makes sense |
| 21:52 | <sicking> | Domenic_: crap :( this makes me worried we can't deprecate DOMStringList :( |
| 21:53 | <Domenic_> | sicking: really? Boris's email made it sound like there was no interoperable usage of it |
| 21:53 | <sicking> | Domenic_: not even IDB? |
| 21:53 | <Domenic_> | i guess IndexedDB |
| 21:55 | <sicking> | Domenic_: how quickly do you think we could get .has added to Array? In spec that is |
| 21:56 | <sicking> | Domenic_: it *might* be easier to get rid of .contains if there's an alternative we can point people to |
| 21:56 | <Domenic_> | sicking: if there was serious DOM pressure, might be able to squeak it into ES6. If someone writes the actual spec text for Allen to copy and paste. Which I volunteer for. (rwaldron also is good at doing such things.) |
| 21:57 | <Domenic_> | Alternately it could be on the ES7 train as an accepted proposal, so as to avoid piling onto the ES6 train |
| 21:57 | <Ms2ger> | sicking, I guess we could also try to kill contains() from DOMStringList? |
| 21:57 | <sicking> | Domenic_: i'm not sure that the IDB usage amounts to "serious" pressure. |
| 21:57 | <sicking> | Domenic_: worst case we just leave DOMStringList in IDB and nowhere else |
| 21:57 | <Domenic_> | It's also not the end of the world to have contains() on array instead of has() |
| 21:58 | <Domenic_> | you can kind of make an argument that you should be consistent with String instead of with Map/Set. |
| 21:58 | <Domenic_> | since string also has zero-indexed properties |
| 21:58 | <sicking> | Domenic_: true |
| 21:59 | <sicking> | Domenic_: any idea when the first ES7 train would ship? My understanding is that there will be regular releases past ES6? (though details still being debated i'm sure) |
| 22:01 | <Domenic_> | I think either end of 2014 for spec-text complete, plus a half-year for editing before Ecma approval, or maybe it's mid-2015 with a shorter Ecma approval cycle this time. |
| 22:01 | <sicking> | ok |
| 22:02 | <sicking> | Ms2ger: we could try renaming .contains() to .has() |
| 22:02 | <Domenic_> | rafaelw I think would know the details on that plan |
| 22:02 | <sicking> | Domenic_: ok |
| 22:02 | <sicking> | Ms2ger: or have both but warn for .contains() |
| 22:02 | <sicking> | Ms2ger: if you write a patch I'll r+ |
| 22:02 | <Ms2ger> | sicking, (I'm not sure if has is really better than contains, but I don't feel like bikeshedding on this :)) |
| 22:02 | <sicking> | Ms2ger: i'll defer to Domenic_ and TC39 |
| 22:03 | <sicking> | Ms2ger: consistency with Set and Map is nice |
| 22:03 | Ms2ger | avoids snarky comments by saying nothing |
| 22:03 | <sicking> | Ms2ger: something we should deinitely do is to remove item |
| 22:04 | <Ms2ger> | You could file a bug on me and hope I get to it :) |
| 22:04 | <sicking> | Domenic_: so, "has" or "contains"? If you get to choose? |
| 22:05 | <Domenic_> | sicking: if I get to choose, "has". |
| 22:05 | <sicking> | Domenic_: cool |
| 23:28 | SamB | wonders what it means to get a 301 with "Vary: User-Agent,Accept-Language, Accept-Encoding" |
| 23:29 | <SamB> | (is it really "permanent" if it depends on those things?) |
| 23:29 | SamB | just did "curl --head www.mozilla.org" |
| 23:46 | <Hixie> | SamB: it means it's permanent for that combination of values :-) |
| 23:47 | <SamB> | hmm, so I know who I should complain to if a link checker sees that ands says "change your links" |
| 23:55 | <Hixie> | SamB: the link checker vendor? |
| 23:55 | <SamB> | precisely |