| 09:34 | <zcorpan> | is http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2433 an improvement on the readability of the diff? (click "rendered view", compare with http://html5.org/tools/web-apps-tracker?from=8035&to=8036 ) |
| 09:36 | <Ms2ger> | Interesting |
| 09:37 | <hasather> | zcorpan: yea, that's a big improvement |
| 09:38 | <zcorpan> | now i wonder if it's good enough to implement it with a simple regex |
| 09:39 | <zcorpan> | simple regex will break with e.g. commented out tags |
| 09:39 | <zcorpan> | more complex regex can deal with that case but will still break with something else |
| 09:43 | <zcorpan> | tags wrapping lines probably just won't work |
| 09:44 | <zcorpan> | unless somebody comes up with something clever |
| 09:47 | <zcorpan> | consider e.g. a diff like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2434 |
| 09:50 | <annevk> | zcorpan: could you add a button to remove the elements for highlighting? |
| 09:50 | <annevk> | zcorpan: writing a simple tokenizer might be better |
| 09:51 | <zcorpan> | annevk: yeah. and forget the state when switching from a removed line to another type of line |
| 09:51 | <annevk> | zcorpan: and then we could remove the tags by default, maybe, that might look best |
| 09:52 | <annevk> | people have been asking for a no-tags-view |
| 09:52 | <zcorpan> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2435 |
| 09:53 | <annevk> | pretty cool |
| 09:53 | <annevk> | tokenizer would fix the <code \n title= issues |
| 10:29 | <MikeSmith> | zcorpan: nice |
| 10:39 | <MikeSmith> | Ms2ger: do you have an instance of https://bitbucket.org/ms2ger/test-runner on the Web somewhere? |
| 10:39 | <MikeSmith> | or does anybody else |
| 10:43 | <Ms2ger> | I think the webappsec people have a fork |
| 10:55 | <MikeSmith> | ok |
| 11:09 | <annevk> | So ArrayBuffer() and new ArrayBuffer() are identical. |
| 11:09 | <annevk> | I wonder if they did that because of compatibility or some other reason. |
| 11:11 | <gsnedders> | Even setting [[Prototype]]? |
| 11:14 | <zcorpan> | annevk: isn't it usual for constructors to have identical result when called without new? |
| 11:14 | <annevk> | zcorpan: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=22808 (I just emailed es-discuss about it) |
| 11:15 | <gsnedders> | zcorpan: If the [[Call]] returns an object, yes. |
| 11:16 | <zcorpan> | XMLHttpRequest() is the same as new XMLHttpRequest() |
| 11:16 | <annevk> | zcorpan: not in Chrome |
| 11:17 | <zcorpan> | oh. interesting. i thought everyone did that |
| 11:27 | <matjas> | https://media.blackhat.com/us-13/US-13-Stone-Pixel-Perfect-Timing-Attacks-with-HTML5-WP.pdf |
| 11:36 | <Ms2ger> | annevk, Chrome bug :) |
| 11:37 | <annevk> | Ms2ger: that depends on what we think is best |
| 11:37 | <Ms2ger> | Making them equivalent :) |
| 11:39 | <annevk> | false |
| 12:00 | <JakeA> | annevk: Where is XmlHttpRequest defined for worker scopes? |
| 12:01 | <annevk> | JakeA: http://xhr.spec.whatwg.org/ defines it for both simultaneously |
| 12:02 | <annevk> | JakeA: see http://lists.w3.org/Archives/Public/www-dom/2013JulSep/0101.html for some general issues about making it clearer what happens in workers (though for XMLHttpRequest I think it's pretty clearly outlined in the specification already, although not in the best possible way yet) |
| 12:03 | <JakeA> | hah, that answers my second question |
| 12:05 | <JakeA> | annevk: I can't actually find the definition, was expecting to see "partial interface WorkerGlobalScope" somewhere |
| 12:05 | <JakeA> | the xhr spec talks about workers, but can't find the bit where the interface is defined |
| 12:06 | <annevk> | JakeA: the interface is shared basically |
| 12:06 | <annevk> | JakeA: IDL puts them on the global |
| 12:12 | <JakeA> | I think my inexperience with IDL is showing. I see the definition of the XMLHttpRequest constructor, but I don't see the bit that says this constructor should be a property of Window instances (or WorkerGlobalScope instances) |
| 12:18 | <JakeA> | annevk: I see "If the JavaScript global environment is a worker environment, implementations must act as if Document and Document? in the above IDL were not exposed." - is that implicitly mandating that XMLHttpRequest should exist on WorkerGlobalScope? |
| 12:43 | <annevk> | JakeA: no, that bit is defined by IDL |
| 12:44 | <annevk> | JakeA: see http://dev.w3.org/2006/webapi/WebIDL/#es-platform-objects |
| 12:45 | <annevk> | JakeA: the bit that's currently missing is being explicit about the globals, hopefully that'll get fixed soonish |
| 13:10 | <JakeA> | annevk: got ya |
| 13:12 | <JakeA> | annevk: does that mean that HTMLDivElement should exist in a worker? |
| 13:12 | <annevk> | JakeA: everything Node is banned |
| 13:13 | <annevk> | JakeA: but again that's currently not as crystal clear as it could be |
| 13:13 | <annevk> | JakeA: see the email I pointed to and the bug report, once that's fixed the specifications will be better |
| 13:13 | <JakeA> | ahh ok |
| 13:14 | <JakeA> | annevk: So, it looks like Promise doesn't currently exist in workers in Chrome, how would I explain in a ticket that it should be there? |
| 13:14 | <JakeA> | Trying to work out how this stuff is defined |
| 13:15 | <annevk> | JakeA: it sounds like you haven't read that email yet ;) |
| 13:15 | <annevk> | JakeA: note also that it was in reply to a guy from Google who is probably implementing promises in Chrome at the moment |
| 13:16 | <JakeA> | annevk: I wasn't clear if there was nothing in the spec to say they should be in workers, or whether _something_ is there but it isn't clear |
| 13:16 | <annevk> | JakeA: fair |
| 13:17 | <JakeA> | annevk: Is it simply undefined at the moment, aside from that email? |
| 13:17 | <annevk> | JakeA: yes |
| 13:18 | <annevk> | I think we'll end up with something like [Global=Window|Workers] or some such annotation |
| 13:23 | <JakeA> | annevk: makes sense, cheers! |
| 13:50 | <annevk> | I tried to figure out a way to make zip URLs work after yet more private requests, but I couldn't: https://gist.github.com/annevk/6174119 |
| 13:51 | Ms2ger | wonders why people would want to break new-less constructors |
| 13:52 | <annevk> | Ms2ger: some type of subclassing I don't fully grok yet |
| 14:16 | <Domenic_> | annevk: Ms2ger: I found https://github.com/slightlyoff/Promises/issues/71. It assumes you understand the @@create/constructor separation though and why that's necessary for subclassing. |
| 14:17 | <Domenic_> | annevk: very curious to hear a response to your thread though, I do wonder why ArrayBuffer behaves as it does. |
| 14:18 | <annevk> | Maybe because Array does the same. It seems quite a few built-ins have already spoiled the non-new well... |
| 14:18 | <Domenic_> | yeah, i would have preferred a consistent story there |
| 14:19 | <Domenic_> | if they end up saying "oh it's OK for ArrayBuffer because X," I look forward to finding out why X doesn't apply to everything else. |
| 14:19 | <Ms2ger> | You're about a decade late, I guess |
| 14:20 | <annevk> | Domenic_: yup |
| 14:20 | <zewt> | the tagline of web api development |
| 14:22 | <Ms2ger> | All too true :/ |
| 14:31 | <annevk> | Domenic_: so playing with jQuery, it seems collection.find() basically runs the selector against each element in collection and returns the union of matched elements, in tree order |
| 14:32 | <annevk> | Domenic_: seems reasonable for find/findAll |
| 14:32 | <Domenic_> | annevk: yeah. I think that is what Elements#findAll does right now? |
| 14:32 | <annevk> | Domenic_: there's no Elements and there's no definition of that anywhere |
| 14:33 | <annevk> | Domenic_: there's only your gist, and I don't think it defines behavior |
| 14:33 | <Domenic_> | annevk: what does it not define? |
| 14:33 | <annevk> | Domenic_: oh wait |
| 14:34 | <annevk> | Domenic_: so your thing will fail on HTMLElement.prototype :/ |
| 14:35 | <annevk> | Domenic_: can fix that in prose of course, but having no proper branding for elements sucks |
| 14:36 | <Domenic_> | annevk: I'm not sure it will *fail* exactly... what does calling HTMLElement.prototype.querySelectorAll(...) return? |
| 14:36 | <Domenic_> | yeah ok that doesn't work |
| 14:37 | <Domenic_> | (in Firefox at least) |
| 14:37 | <zewt> | annevk: does it not work to just pass through the base URL and origin to the "nested" URL? eg. so <img src=zip:/i!pony.gif> would parse out "/i" and "!pony.gif", then parse "/i" as a URL with the same base as the zip: was given |
| 14:37 | <zewt> | (guessing you've thought of this, trying to understand the problem) |
| 14:38 | darobin | finds out about peer dependencies, kiss Domenic_ |
| 14:38 | <annevk> | zewt: that's the processing model proposed |
| 14:39 | <Domenic_> | darobin: :) |
| 14:40 | <zewt> | i guess the trickiness in the iframe case is if you expect to be able to serve a whole iframe and its resources from a ZIP, where the relative urls inside the iframe would be relative to the zip |
| 14:40 | <zewt> | allowing that sort of seems nasty |
| 14:41 | <Domenic_> | annevk: yeah this branding stuff is annoying, hmm. I guess Allen's answer here would be to just check for the existence of querySelectorAll. But that creates more issues. Still, I'd hate to add X.isX to everything just to avoid the X.prototype case. |
| 14:41 | <zewt> | i guess the same thing would happen if you expect to be able to enter a ZIP URL into the address bar and load a whole website out of it |
| 14:43 | <zewt> | don't know if that's something people really want (most cases that come to mine for me are zips of icons to get rid of sprite sheets, or zips of JS to avoid having to coalesce scripts) |
| 14:43 | <zewt> | (... mind) |
| 14:44 | <annevk> | Even in the case of only allowing fetching you have to special case zip to extract the correct origin out of the URL. |
| 14:45 | <annevk> | We could definitely make it fetch-only and the navigate algorithm would simply do something else. |
| 14:47 | <annevk> | Domenic_: that's not an answer actually |
| 14:47 | <annevk> | Domenic_: not if you want to explain the whole platform in terms of JavaScript |
| 14:47 | <zewt> | this really wants to be something like http://foo/bar!path; curse you, web-compatibility (another tagline) |
| 14:47 | <Domenic_> | annevk: it's not a good answer, but why wouldn't it be an answer? |
| 14:47 | <annevk> | Domenic_: the amount of instance checks the platform makes is enormous |
| 14:48 | <Domenic_> | annevk: ah i see what you mean |
| 14:48 | <annevk> | You want to solve this for the general case, not this specific case |
| 14:48 | <Domenic_> | annevk: that's a pretty compelling argument I guess. |
| 14:49 | <annevk> | Also, it seems querySelector is on HTMLElement.prototype |
| 14:49 | <annevk> | And it'll give you "TypeError: 'querySelector' called on an object that does not implement interface Element." of course. |
| 14:50 | <Domenic_> | Oh interesting, it's on Element.prototype in Firefox |
| 14:50 | <Domenic_> | oh but yes that's not the point you were making, i get it |
| 14:51 | <annevk> | Oh right. I meant you can invoke it from there. |
| 14:51 | <annevk> | Well, try to. |
| 14:59 | <annevk> | Domenic_: duck-typing btw also seems very bad |
| 15:02 | <Domenic_> | annevk: i am unsure either way on that. |
| 15:19 | <annevk> | zewt: yeah, if only we didn't allow everything single code point in paths... |
| 15:20 | <zewt> | tried to think of some weird codepoint that nobody is actually using, but hard to prove and would be a really nasty hack anyway... |
| 15:21 | <zewt> | i just thought of perhaps the nastiest hack in a while: use an unpaired surrogate! D: |
| 15:21 | <annevk> | U+0000 ... |
| 15:21 | <annevk> | that'd only work through script |
| 15:26 | <Ms2ger> | TabAtkins, yeah, if you could just convince Allen... |
| 15:28 | <annevk> | Ms2ger: context? |
| 15:29 | <Ms2ger> | The Word tweet |
| 15:31 | <Domenic_> | it's an Ecma requirement actually |
| 15:31 | <Domenic_> | Allen hates it quite a lot too |
| 15:32 | <Ms2ger> | That's FUD, afaict |
| 15:32 | <Domenic_> | (Although this Anolis HTML format thing seems kinda crazy to me, personally.) |
| 15:32 | <Ms2ger> | Why's thatN |
| 15:32 | <Ms2ger> | ? |
| 15:33 | <Ms2ger> | Of course, any crazy parts are Bert's fault |
| 15:37 | darobin | smiles |
| 15:38 | <Domenic_> | I dunno, I'm sure it's all there for a good reason. But from the outside all these different random wrapper tags seem strange. <var title> vs. <code> vs. <a> vs. <span>, and they get translated between each other during a translation process... And, it's hard to see what it gains vs. markdown, in terms of real tangible gains. It loses readability and |
| 15:38 | <Domenic_> | authorability of the source pretty hard (having to know which esoteric wrapper tag you need for which type of term). |
| 15:39 | <Domenic_> | The only way I was able to submit pull requests was by copying and pasting similar paragraphs and tweaking wording. |
| 15:39 | <Domenic_> | (pull requests to the DOM spec) |
| 15:46 | <annevk> | Hold on. Hold on. HTML is an order of magnitude better than Word. Period. |
| 15:47 | <annevk> | If we can make Anolis better, I'm all for it, but lets not try to compare the two. |
| 15:47 | <annevk> | (AFAICT ECMA will do whatever TC39 wants so if Allen actually hates it (and I've anecdotal evidence to the contrary) it'd have changed I think.) |
| 15:52 | <Domenic_> | haha yes, HTML >>> Word definitely, Anolis comments were just an aside. |
| 15:53 | <Domenic_> | Didn't know that about Ecma, interesting. |
| 15:56 | <annevk> | Ecma seems to exist mostly around TC39. It's kinda weird. |
| 15:59 | <Ms2ger> | Domenic_, so var/code/a/span get linked, and then spans are dropped, because they're pointless |
| 16:00 | <Ms2ger> | get linked, that is, unless there's nothing to link to, which you can make explicit with title="" |
| 16:08 | <GPHemsley> | document.write() is frowned upon, right? |
| 16:08 | <Ms2ger> | Yeah |
| 16:15 | <annevk> | Hmm, should the signature of .find() be changed to find(relativeSelectors, referenceElements...)? |
| 16:17 | <Domenic_> | why wouldn't you just do referenceElements.find(relativeSelectors) |
| 16:18 | <Domenic_> | in jQuery you generally either do $(relativeSelector, referenceElement) or $(referenceElement).find(relativeSelector) |
| 16:19 | <annevk> | So shouldn't we provide both? |
| 16:19 | <Domenic_> | so you mean like window.find(relativeSelector, referenceElement)? |
| 16:19 | <annevk> | parentNode.find() |
| 16:20 | <Domenic_> | i don't see the utility. the reason jQuery has the two-argument form is because it's global and short |
| 16:20 | <Domenic_> | having to select a parent node and then use two arguments (for a total of three entities involved) is not a savings |
| 16:21 | <annevk> | well parent can be document |
| 16:21 | <annevk> | or a document fragment |
| 16:21 | <Domenic_> | i think it's easier to just do referenceElement.find(relativeSelector) |
| 16:22 | <Domenic_> | i am missing the use case that this does not cover |
| 16:24 | <annevk> | Yeah so I was reading this based on Selectors API 2, but that does seem kind of weird |
| 16:25 | <Domenic_> | ah right |
| 16:25 | <annevk> | ? |
| 16:26 | <Domenic_> | as in, i forgot about selectors 2, but now i see where you're coming from |
| 16:26 | <Domenic_> | it is weird though, i don't see any reason why selectors 2 does that |
| 16:31 | <TabAtkins> | zcorpan: I dunno, but I'm willing to support that. |
| 16:32 | <TabAtkins> | zcorpan: (Read "I dunno" as "no".) |
| 16:36 | <annevk> | Domenic_: sounds good to me |
| 16:36 | <annevk> | Now I just need to figure out how to write down "Elements" |
| 16:42 | <Domenic_> | annevk: how will these things be created anyway? Element.find() returns an Element, but Element.findAll() returns an Elements? |
| 16:42 | <annevk> | well instances of Element would, yes, also instances of Document / DocumentFragment |
| 16:43 | <Domenic_> | right ok. so basically what selectors level 2 does, but a bit better. |
| 16:44 | <Domenic_> | and the reason for document having this is because document.documentElement.find is too long to type compared to document.find? |
| 16:44 | <Domenic_> | i guess the former wouldn't find "html", nevermind |
| 16:48 | <TabAtkins> | Hixie: I'm rewriting some of the font-load-events stuff this week, since jdaggett doesn't have time to rewrite to reflect the consensus from last f2f. |
| 16:51 | <annevk> | Also need to have @@unscopeable for find/findAll |
| 16:51 | <Domenic_> | because of the inline-event-handlers-implicitly-do-`with` thing? |
| 16:52 | <annevk> | No they do something weirder than that |
| 17:01 | <TabAtkins> | No, they're explainable with `with`, just three (I think) nested `with`s. |
| 17:03 | <jgraham> | ... |
| 17:03 | <Domenic_> | :O |
| 17:04 | <TabAtkins> | Yes. |
| 17:06 | <annevk> | TabAtkins: that's weirder than implicit-with dude :p |
| 17:07 | <TabAtkins> | Bah, only by a linear factor. |
| 17:08 | <annevk> | Domenic_: http://www.whatwg.org/specs/web-apps/current-work/#event-handler-content-attributes step 6 |
| 17:14 | <Domenic_> | annevk: cool thanks. different topic: what do you think of "modular" specs? whatwg has a lot, and it seems cool, but slightlyoff expressed skepticism on twitter the other day and i can see both sides. |
| 17:15 | <annevk> | Domenic_: It doesn't make much sense to me to put URL and Encoding in the same document. I'd love to hear the argument for that. |
| 17:15 | <Ms2ger> | "It's all part of the web" |
| 17:15 | <annevk> | Domenic_: HTML has a lot in the same document though, so not all of our stuff is modular. |
| 17:16 | <Domenic_> | sure, but pieces of html seem to keep breaking off. |
| 17:16 | <smaug____> | whatwg has a lot ? |
| 17:16 | <smaug____> | whatwg doesn't have too many specs |
| 17:16 | <Domenic_> | smaug____: https://github.com/whatwg/ seems like a lot to me |
| 17:16 | <Ms2ger> | Do you know how many the CSSWG publishes? |
| 17:16 | <annevk> | Domenic_: http://the-pastry-box-project.net/anne-van-kesteren/2013-may-7/ seems still relevant. |
| 17:17 | <Ms2ger> | And they cover a lot less |
| 17:17 | <annevk> | Domenic_: if that's a lot you haven't seen many W3C drafts I'm afraid. :/ |
| 17:17 | <Domenic_> | hmm i guess so |
| 17:17 | <Ms2ger> | But I think HTML could benefit from being split up somewhat |
| 17:18 | <Ms2ger> | Though it's all intertwined, unfortunately |
| 17:18 | <smaug____> | yes, splitting HTML might improve readability |
| 17:19 | <Domenic_> | annevk: oh cool hadn't seen that link |
| 17:19 | <annevk> | Domenic_: I think the way to address slightlyoff's concern is by ensuring you know most of what's going on and ensuring some kind of consistency. |
| 17:23 | <annevk> | Hixie would prefer having most things in one document. But then taking over editing of the DOM specification is something he's not interested in, so... |
| 17:24 | <Ms2ger> | It would be interesting to generate a merged document, perhaps |
| 17:24 | Ms2ger | doesn't volunteer |
| 17:25 | <TabAtkins> | Hah, that spec list is *nothing* before the might of the CSSWG! |
| 17:25 | <annevk> | But to properly merge it you want to do more than just having it as a chapter. |
| 17:25 | <Ms2ger> | Right |
| 17:25 | <Ms2ger> | Hixie's build system doesn't help :) |
| 17:28 | <annevk> | Domenic_: also, I'll take slightlyoff's arguments here more seriously once he writes a couple of specs |
| 17:28 | <Domenic_> | oooh burnnn |
| 17:32 | <MikeSmith> | ./topic I'll take slightlyoff's arguments here more seriously once he writes a couple of specs |
| 17:33 | <TabAtkins> | Hm, what's the special meaning of span/code/i/abbr/var in Anolis xrefs? |
| 17:33 | <Ms2ger> | TabAtkins, they're xreffed |
| 17:34 | <TabAtkins> | Well, yeah, but Domenic said that they have particular uses? It's not recorded in the docs. |
| 17:34 | <Ms2ger> | Not really, no |
| 19:00 | <Domenic_> | annevk: ah damn, conflicting with Array.prototype.find, how did we miss that. |
| 19:15 | <annevk> | Domenic_: when was Array.prototype.find added? |
| 19:15 | <annevk> | https://gist.github.com/rwldrn/5079436 is from five months ago |
| 19:16 | <annevk> | Yours is about a month old and Selectors API 2 is way older... And jQuery uses find(). Seems pretty obvious why that was missed :) |
| 19:16 | <Domenic_> | annevk: yeah i think it was around then, es-discuss email maybe a month prior => TC39 meeting agreement => that gist |
| 19:17 | <Domenic_> | well, can't believe *I* missed that, I guess. |
| 19:18 | <Domenic_> | maybe query() |
| 19:18 | <annevk> | So Allen's position makes sense, but is completely out-of-sync with most of the platform. It might still work though. |
| 19:18 | <Domenic_> | right, yeah. |
| 19:18 | <Domenic_> | i think my followup email outlines something more concrete |
| 19:18 | <annevk> | select/selectAll |
| 19:19 | <Domenic_> | oh duh that's very nice |
| 19:19 | <Domenic_> | changing gist |
| 19:19 | <annevk> | The names might be taken unfortunately. |
| 19:19 | <Domenic_> | but yeah we still want to use native QSA, probably not triggering any old querySelectorAll method, for optimization reasons if nothing else. |
| 19:20 | <annevk> | Also, querySelector takes selectorList whereas this would take relativeSelectorList |
| 19:20 | <Domenic_> | selectorList? |
| 19:20 | <gsnedders> | What's the justification for the noscript parsing depending on the scripting enabled flag? It seems like it could easily result in different parse trees. |
| 19:21 | <annevk> | Domenic_: "img, p" |
| 19:21 | <annevk> | gsnedders: that's how <noscript> works |
| 19:21 | <Domenic_> | annevk: hmm ok. So you're saying just prepending `":scope "` doesn't do the trick. |
| 19:21 | <jgraham> | fwiw I think "select" is a better name than "find" |
| 19:22 | <Ms2ger> | gsnedders, isn't that the point? |
| 19:22 | <Domenic_> | jgraham: agreed, `select` is excellent. |
| 19:22 | <annevk> | Domenic_: you need to absolutize: http://dev.w3.org/csswg/selectors/#absolutizing |
| 19:23 | <gsnedders> | Ms2ger: I dunno. It just seems evil. |
| 19:23 | <annevk> | For once CSS has defined all the primitives we need. |
| 19:23 | <annevk> | Oh wait, it's not CSS, it's Selectors! |
| 19:23 | <gsnedders> | jgraham, annevk: why does html5lib impl the scripting enabled case? |
| 19:23 | <Domenic_> | what am i doing looking at selectors level 2 when we've got a level 4 hanging around!?! |
| 19:23 | <zcorpan> | anyone feel like implementing the hide-tags thing in web-apps-tracker? |
| 19:23 | <Domenic_> | :P |
| 19:23 | <annevk> | gsnedders: I think we wanted to closely align with browsers |
| 19:23 | <Ms2ger> | Domenic_, selectors level 4, selectors api level 2 |
| 19:24 | <Ms2ger> | Domenic_, in case that was serious |
| 19:24 | <Domenic_> | Ms2ger: hah ok, yeah assumed it was something like that |
| 19:24 | <gsnedders> | annevk: Except it doesn't, because if they parse with scripting enabled they'll do stuff with document.write, and if they parse with it disabled they again won't match us. |
| 19:25 | <annevk> | gsnedders: sure sure, more closely |
| 19:25 | <annevk> | Selectors API 2 will be eaten by DOM. Then there'll be one Selectors left. |
| 19:25 | <zcorpan> | gsnedders: maybe html5lib should have it configurable |
| 19:25 | <annevk> | gsnedders: I'm not saying I still agree with that btw |
| 19:25 | <gsnedders> | zcorpan: Oh, it should. |
| 19:26 | <jgraham> | gsnedders: Because realistically people scraping websites expect that |
| 19:26 | <gsnedders> | zcorpan: Just nobody has bothered to do it. :) |
| 19:26 | <Domenic_> | i wonder if prototyping this in jsdom would be useful. |
| 19:26 | <TabAtkins> | Domenic_: The algorithm to absolutize a relative selector is in Selectors 4. |
| 19:26 | <gsnedders> | jgraham: Do they really get better resulting frm scripting enabled? |
| 19:27 | <jgraham> | Well it depends if you think that any websites use <noscript> in a useful way |
| 19:27 | <jgraham> | I doubt that |
| 19:27 | <Domenic_> | apparently discourse (codinghorror's new forum thing) is using it for seo |
| 19:27 | <gsnedders> | On the face of it, if we want to match browsers, we should be scripting disable. |
| 19:27 | <gsnedders> | *disabled |
| 19:27 | <Domenic_> | http://eviltrout.com/2013/06/19/adding-support-for-search-engines-to-your-javascript-applications.html |
| 19:27 | <jgraham> | Well I don't think it's that important |
| 19:28 | <Ms2ger> | So is the stuff that I didn't want in DOM in selectors? |
| 19:28 | <Ms2ger> | I guess I should rereview, then |
| 19:28 | <annevk> | TabAtkins: yeah just pointed to it. You guys are awesome for having done that already. |
| 19:28 | <Ms2ger> | And/or Lachy should rewrite his PR |
| 19:28 | <TabAtkins> | Ah, I see. |
| 19:28 | <TabAtkins> | Yeah, we defined it for Lachy, and sent him an email detailing what things he can change/remove from his spec. |
| 19:28 | <annevk> | Ms2ger: Given that he seems to be mostly MIA I'll have a go at it. |
| 19:29 | <Ms2ger> | Great |
| 19:29 | <annevk> | Ms2ger: I think I'll start with the non-controversial stuff. querySelector / querySelectorAll / matches. And then figure out how to do the other two and the new collection API. |
| 19:29 | <Ms2ger> | annevk, sounds like a sensible approach |
| 19:29 | <Lachy> | TabAtkins, yes, I need to deal with that |
| 19:30 | <Ms2ger> | Ah, there's Lachy |
| 19:30 | <annevk> | Whoa, a wild Lachy appears! |
| 19:31 | <gsnedders> | Only L3, though :( |
| 19:31 | <annevk> | Maybe Lachy is like http://en.wikipedia.org/wiki/Beetlejuice |
| 19:32 | <TabAtkins> | annevk: No, we only mentioned his name twice. |
| 19:33 | <Lachy> | TabAtkins, basicaly the reason I didn't update the selectors api spec is that Ive been intending for it to be superseded by DOM, which I need to finish incorporating it into. |
| 19:34 | <TabAtkins> | Lachy: kk, no problem |
| 19:35 | <annevk> | Ah, I just said "him" |
| 19:40 | <zcorpan> | TabAtkins: abbr/i/var aren't xreffed anymore (unless you turn on some flag) |
| 19:40 | <TabAtkins> | zcorpan: Oh, then the docs need to be updated. |
| 19:40 | <zcorpan> | likely :-( |
| 19:40 | <TabAtkins> | So what's still xreffed? <a>, <span>, <code>? |
| 19:40 | <Lachy> | annevk, I can do it. Ive just been on extended holiday. But now that I have a new job, I can start getting back into spec work. |
| 19:41 | <zcorpan> | TabAtkins: <span> and <code>. <a> is TODO |
| 19:41 | <TabAtkins> | Heh. |
| 19:42 | <TabAtkins> | Do you just take any <code>/<span>, or is there some explicit flag marking it as an attempted ref? |
| 19:43 | <zcorpan> | oh i implemented <a> but Ms2ger hasn't merged yet. https://bitbucket.org/ms2ger/anolis/pull-request/11/enable-usage-of-instead-of-for-xrefs-also/diff |
| 19:43 | <Ms2ger> | Hrm, why didn't I? |
| 19:44 | <TabAtkins> | I can recognize anolis xrefs; they're not hard. |
| 19:44 | <zcorpan> | TabAtkins: any that doesn't have empty title attribute |
| 19:44 | <TabAtkins> | zcorpan: Okay. |
| 19:44 | <TabAtkins> | I'd probably want to trigger it via a command-line option, then. |
| 19:44 | <Ms2ger> | zcorpan, any reason not to merge it? |
| 19:44 | <TabAtkins> | Like --anolis-compat or something. |
| 19:45 | <zcorpan> | Ms2ger: i think i tested it, but pls look it over in case i did something utterly stupid |
| 19:45 | <Ms2ger> | On first sight, no, but the code is horrible |
| 19:46 | <zcorpan> | well yeah |
| 19:47 | <zcorpan> | TabAtkins: anolis also supports data-anolis-xref="" or some such but i think nobody uses it because it's just more verbose compared to title |
| 19:47 | <Ms2ger> | The anolis documentation uses it |
| 19:47 | <TabAtkins> | annevk: Yo, in http://example.com/foo and http://example.com/foo/, the two are identical except that the second has a second, empty path segment, right? |
| 19:48 | <annevk> | TabAtkins: yes |
| 19:48 | <TabAtkins> | annevk: Ok. |
| 19:48 | <Ms2ger> | zcorpan, anyway, merged it; I'll hear if it breaks anything |
| 19:49 | <annevk> | Lachy: where do you work now? |
| 19:49 | <zcorpan> | Ms2ger: thanks |
| 20:04 | <Lachy> | annevk, it's a company called Aspiro TV. They provide media streaming services and applications for their clients. |
| 20:05 | <Lachy> | I'm doing front end development for an application built as a hybrid web app/native app for devices |
| 20:10 | <zcorpan> | is firefox going to disallow <iframe src=viewsource:...> given the pixel perfect timing attack thing? |
| 20:10 | <JonathanNeal> | zcorpan: could always use viewsource.in :) |
| 20:11 | <zcorpan> | JonathanNeal: the user wouldn't be logged in via that service |
| 20:19 | <JonathanNeal> | gotcha |
| 20:24 | <GPHemsley> | Ms2ger: Did you ever turn on attribute sorting? |
| 20:24 | <Ms2ger> | I don't recall |
| 20:26 | <GPHemsley> | I don't think you did |
| 20:29 | <TabAtkins> | Okay, so if I add an --anolis-compat flag, that's just a matter of recognizing <code> as a maybe-link (I already recognize <i> as such), and recognizing data-anolis-xref as an alternative for title. |
| 20:29 | <TabAtkins> | And then doing the cross-spec stuff that you do differently. |
| 20:29 | <TabAtkins> | (My cross-spec stuff is based on data parsed by Shepherd.) |
| 20:29 | <TabAtkins> | Alternately, just ignoring that and getting Shepherd to parse more specs. |
| 20:30 | <TabAtkins> | Hm, Anolis doesn't type any definitions/links, right? Every definition lives in a global namespace? |
| 20:30 | <annevk> | TabAtkins: cross-spec references are per spec |
| 20:30 | <TabAtkins> | Ah, bleh. |
| 20:31 | <annevk> | There's a public database |
| 20:31 | <annevk> | TabAtkins: https://github.com/whatwg/xref/ |
| 20:32 | <TabAtkins> | Okay, so you just use PRs to amend the set of cross-refs? |
| 20:32 | <Ms2ger> | Pretty much everyone who uses it has push access, I think |
| 21:16 | <zcorpan> | funny when i file a bug and later it digs into issues that go over my head (https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 ) |
| 21:24 | <Hixie> | zcorpan: not as funny as when you file a bug on a spec i edit and it goes over _my_ head (https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242) :-P |
| 21:25 | <zcorpan> | heh |
| 21:26 | <Hixie> | in other news, i need a term that doesn't really mean anything, but expresses the property of A being something relative to B, without implying a mutual relationship, and that brings to mind the idea of control or authority |
| 21:26 | <Hixie> | to replace the term "A is friends with B" in the spec, which unfortunately does imply a mutual relationship |
| 21:26 | Hixie | hands out paint brushes and waits |
| 21:29 | jgraham | wonders what a non-mutual relationship is |
| 21:30 | <zcorpan> | jgraham: e.g. stalking maybe? |
| 21:31 | <jgraham> | Yeah, that was exactly the example I just came up with |
| 21:31 | <jgraham> | So there we go |
| 21:31 | <jgraham> | "A stalks B" |
| 21:33 | <Philip`> | "A is in unrequited love with B" |
| 21:34 | <zcorpan> | "A is boss over B" |
| 21:34 | <Philip`> | "A is secretly wiretapping B" |
| 21:37 | <zcorpan> | "A is twisting B's nipples" |
| 21:38 | <jgraham> | zcorpan: "boss over" has the inverse "employee of" |
| 21:39 | <zcorpan> | jgraham: ok, strike that one |
| 21:42 | <zcorpan> | Hixie: there, you have several to choose from :-) |
| 21:43 | <zcorpan> | "A is spying on B" |
| 21:45 | <jgraham> | "A is hiding from B" |
| 21:57 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22625 - should the bugfiler do something smart with <sub>/<sup>? (or other elements?) |
| 22:00 | <TabAtkins> | Anyone know the progress of the "async image" stuff, where some attribute on the <img> would make it not fire the request until the browser thought it was about to display? |
| 22:02 | <zcorpan> | there's a bug filed about that at least |
| 22:03 | <MikeSmith> | TabAtkins: it that not the thing that somebody in the Web Performance group was speccing out? |
| 22:04 | <MikeSmith> | after scope-creeping it into an attribute for script and other elements |
| 22:04 | <zcorpan> | ah yeah |
| 22:06 | <MikeSmith> | TabAtkins: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html |
| 22:08 | <TabAtkins> | MikeSmith: Yeah, that's what I'm looking for. Cool. |
| 22:12 | <jgraham> | I'm surprised they didn't turn it into loadpriority=integer |
| 22:12 | <jgraham> | Over-engineer all the things |
| 22:14 | <annevk> | that's what we got requested for XHR |
| 22:14 | <annevk> | it may very well return |
| 22:15 | <annevk> | although talking to our HTTP guys a couple of weeks ago it seems that'd be pretty premature optimization, though lazyload might be good |
| 22:15 | <annevk> | even better would be to load the images the user is looking at first |
| 22:16 | <jgraham> | Yeah, I don't at all trust that authors are better at resource prioritization than browsers |
| 22:16 | <jgraham> | Well there's no reason you can't prioritise images that would be visible, if you are a browser |
| 22:17 | <jgraham> | It's not architecturally pure since it couples networking and layout, but that happens already, so... |
| 22:23 | <MikeSmith> | A is a classmate of B |
| 22:24 | <MikeSmith> | B is at risk of random bullying from A |
| 22:26 | <jgraham> | Oh, I guess just "A is at risk from B" works |
| 22:27 | jgraham | doesn't think Hixie will like these suggestions :) |
| 22:27 | <MikeSmith> | annevk: slightlyoff doesn't need to write specs; he just thinks of stuff and people implement it |
| 22:27 | <miketaylr> | "A is a kidney donor for B" |
| 22:27 | <MikeSmith> | heh |
| 22:29 | <slightlyoff> | damn, y'all |
| 22:30 | <annevk> | slightlyoff, thoughts on specification modularization in long form might work ;) I might not even disagree, it's just, you know, easier said than done |
| 22:31 | <slightlyoff> | annevk: sure |
| 22:32 | <slightlyoff> | but I warn you that my long form is LOOOOONG |
| 22:34 | <annevk> | slightlyoff: you're gonna write a spec to rule them all? ;) |
| 22:37 | annevk | -> zzz |
| 22:42 | <slightlyoff> | annevk: nah, but I'll make a nuanced case for an "integration phase" |
| 22:42 | <slightlyoff> | = ) |
| 22:43 | <Hixie> | "A is in unrequited love with B" is good, but unfortunately implies a negative reverse relationship. "is boss over" is similar. "is at risk of random bullying from" is actually the best so far... |
| 22:43 | <annevk> | I can see XMLHttpRequest ending up in Fetch eventually. Dunno about URL and Encoding et al. Seem pretty unrelated. |
| 22:44 | <nimbu> | slightlyoff: WELCOME TO SFFFFFFFFFFFF |
| 22:44 | <slightlyoff> | thanks! |
| 22:45 | <annevk> | where the parties are full of minor internet celebrities and the streets full of hobos |
| 22:45 | <jgraham> | Hixie: "is scared of"? |
| 22:46 | jgraham | doesn't actually think that's a good idea but wants to know if that's the right kind of relationship |
| 22:48 | <Philip`> | "idolises"? |
| 22:48 | <annevk> | Hixie: tangentially? |
| 22:52 | <Hixie> | jgraham: yeah, that would work |
| 22:52 | <Hixie> | though it's more "is not scared of" that has the connotations i'm looking for |
| 22:52 | <Hixie> | "likes", maybe |
| 22:52 | <Hixie> | "is a fan of" |
| 22:53 | <Hixie> | "is familiar with" |
| 22:53 | <Hixie> | that one might work best so far |
| 23:11 | <Hixie> | i wish there was a "last person to touch this bug" field in bugzilla |
| 23:12 | <Hixie> | it would make a lot of my workflows easier |
| 23:51 | <TabAtkins> | "is threatened by"? |