| 09:11 | <Ms2ger> | "We're a consensus organization. We need to make the world a consensus organization." |
| 09:11 | <Ms2ger> | Spare me |
| 09:16 | <ondras> | :) |
| 10:48 | <foolip> | annevk: don't scare me :P |
| 13:17 | <marksomnian> | what a whole lot of nothing |
| 13:19 | <caitp> | someone isn't entertained :z |
| 16:05 | <zcorpan_> | <http://www.w3.org/mid/C99B14A348100349A457CD82738FB0AB1BCE0185⊙Mibc>; |
| 16:18 | <annevk_> | Domenic: at what point can Mozilla implement finally? |
| 16:18 | <Domenic> | annevk: when it makes it through a couple stages in the ES7 process would be good... right now there's no proposal |
| 16:19 | <Domenic> | annevk: would be good for the Mozilla rep to start a proposal at the next TC39 meeting |
| 16:20 | <annevk> | That seems unlikely to happen, unless someone is motivated to do that |
| 16:20 | <Domenic> | welp |
| 16:20 | <annevk> | I thought finally was pretty hashed out already? |
| 16:20 | <Domenic> | a JS polyfill has been written, basically |
| 16:20 | <Domenic> | no spec, no tests |
| 16:20 | <annevk> | Also, I've no idea who the Mozilla rep is |
| 16:20 | <Domenic> | yeah, I was going to say, the only Mozillan at hte last meeting I remember was bz |
| 16:20 | <Domenic> | oh and Dave Herman |
| 16:20 | <Domenic> | right |
| 16:21 | <annevk> | I guess he is it then |
| 16:21 | <Domenic> | Meanwhile I'm still trying to get Chrome to remove its non-standard Promise methods |
| 16:21 | <annevk> | Seems weird to not have one of the engine guys attend... I guess they all got pretty dismayed by TC39 politics... |
| 16:21 | <annevk> | Domenic: oh, I thought that happened? |
| 16:21 | <annevk> | Domenic: are they still behind a flag or some such? |
| 16:21 | <Domenic> | nope, i was told it would, and then it did not |
| 16:22 | <Domenic> | they are there shipping in public |
| 16:22 | <Domenic> | in your Chrome console you have Promise.defer, Promise.accept, and Promise.prototype.chain. |
| 16:22 | <Domenic> | Very embarassing and ridiculous. |
| 16:22 | <annevk> | In the console only? |
| 16:23 | <Domenic> | no, no, on public web pages too |
| 16:23 | <Domenic> | who knows, maybe this is why Inbox is Chrome-only. (Probably not.) |
| 16:23 | <annevk> | whoa no |
| 16:23 | <annevk> | V8's release process is broken after all |
| 16:23 | Ms2ger | mumbles something about Chrome claiming they'll remove things |
| 16:24 | <annevk> | What was the old name for Promise.resolve again? |
| 16:25 | <Domenic> | wow this is ridic https://groups.google.com/forum/#!topic/mozilla.dev.webapi/nW4KoL-6x7A |
| 16:25 | <Domenic> | Promise.cast |
| 16:25 | <annevk> | At least that is undefined |
| 16:26 | <annevk> | Domenic: don't worry about it |
| 16:26 | <annevk> | Domenic: coordination with the Taiwan people is still tricky at times, slowly improving |
| 16:26 | <Domenic> | heh, ok |
| 16:35 | <Hixie> | Domenic: so why are streams a whatwg spec and not part of the es spec? is the whatwg spec status permanent? |
| 16:36 | <Hixie> | (just trying to work out how to phrase the entry in spec.whatwg.org) |
| 16:37 | <Domenic> | Hixie: well, on a technical level they could be ES, but on a practical level they're largely about I/O, and in particular browser I/O. |
| 16:37 | <Domenic> | As for their ES status... it doesn't make much sense to me to put them in the ES spec because the ES standard library is so small and this is like jumping several steps ahead in its expansion |
| 16:37 | <Hixie> | k |
| 16:38 | <Hixie> | i don't really understand how this differs from promises, politically |
| 16:38 | <Domenic> | Now, people might create implementations of this in Node, but I think it's fine for Node to reference WHATWG specs, e.g. for URL or Fetch you could imagine the same |
| 16:38 | <Hixie> | but whatever |
| 16:38 | <Hixie> | you should drop the "status" section now btw |
| 16:38 | <Domenic> | Will do |
| 16:38 | <Hixie> | maybe move the last sentence to the header |
| 16:38 | <annevk> | Hixie: I think the difference with promises is that they are an integral part of JS and will likely get dedicated syntax |
| 16:39 | <Hixie> | why wouldn't streams? |
| 16:39 | <annevk> | Hixie: I suspect some kind of asynchronous iterable might, not sure about IO streams in particular |
| 16:40 | <Domenic> | yeah |
| 16:40 | <Domenic> | streams might become an I/O focused instance of a generic (much simpler) async iterable |
| 16:40 | <Hixie> | btw, on an unrelated note |
| 16:41 | <Hixie> | wtf is with getOwnPropertyKeys() |
| 16:41 | <Hixie> | doesn't that _entirely_ defeat the purpose of Symbols |
| 16:41 | <Domenic> | symbols were never supposed to be private |
| 16:42 | <Domenic> | they are non-colliding |
| 16:42 | <Hixie> | ... |
| 16:42 | <Domenic> | not private |
| 16:42 | <Domenic> | there was a separate private symbols proposal but it got dropped (interaction with proxies was too hard to figure out) |
| 16:42 | <Hixie> | proxies are such a mistake |
| 16:42 | <Hixie> | they're ruining everything :-P |
| 16:43 | <Domenic> | so say our JS engine folks too :P |
| 16:43 | <Hixie> | so how do you do private state on an object? |
| 16:43 | <Domenic> | WeakMaps work |
| 16:44 | <Domenic> | for now |
| 16:44 | <Domenic> | we want something better, a few proposals floating around, having perfect-is-the-enemy-of-good problems nailing one down |
| 16:44 | <Domenic> | it's a topic for next f2f |
| 16:45 | <Hixie> | so what, if you wanted to implement the DOM in JS in a way indistinguishable from a C++ implementation you'd have to have a WeakMap of every DOM node pointing to the actual state of the node? |
| 16:46 | <Domenic> | yeah. you could also do what dom.js does and wrap every node in a proxy that disallows access to properties starting with _. Might need to wrap every node in a proxy anyway for cross-origin stuff, at least IIRC that's how Mozilla does it. |
| 16:46 | <Hixie> | since browsers don't disallow access to properties starting with _, that wouldn't solve the use case i described |
| 16:47 | <Hixie> | also wrapping every node defeats the entire point of a js implementation, which is to drop the wrappers... |
| 16:47 | <Domenic> | well, it would be a bit more complicated than that. it would redirect access of properties starting with _ on the wrapped object to a different object. |
| 16:47 | <Hixie> | (i'm assuming a one-origin world here, obviously with multiple origins things get more complicated) |
| 16:48 | <Domenic> | in a one-origin world weak maps suffice yeah |
| 16:49 | <Ms2ger> | Hixie, bah, that wasn't the answer I was hoping for :) |
| 16:50 | <annevk> | So I investigated why the Twitter script failed and fixed it |
| 16:50 | <annevk> | It turns out that Twython made some meaningless API changes |
| 16:51 | <annevk> | e.g. twitter.updateStatus became twitter.update_status |
| 16:51 | <annevk> | And the Twython constructor stopped taking named arguments |
| 16:52 | <annevk> | Error log also has fun entries such as "[Thu Oct 30 05:25:43 2014] [error] Hostname annevankesteren.nl provided via SNI and hostname html5.org provided via HTTP are different" |
| 16:52 | <annevk> | I wonder if people are trying to play tricks |
| 16:52 | <Hixie> | Ms2ger: :-D |
| 16:52 | <Hixie> | Domenic: weak maps seem like a really lame solution to the problem, but ok |
| 16:53 | <Domenic> | Hixie: yeah, they're an interim until we have a nice solution. |
| 16:54 | <annevk> | Not according to Mark Miller... |
| 16:54 | <Domenic> | I think this last thread convinced him you at least need a hint as to how you're going to be using the weak map, if nothing else |
| 16:55 | <Domenic> | at which point new PrivateSymbol(obj) + a nice API is a win vs. `new WeakMap(undefined, { keysAreImportant: true })` + get/set |
| 16:57 | <zcorpan> | http://krijnhoetmer.nl/irc-logs/html-wg/20141030 - "after 5" discussion about now |
| 16:57 | <Domenic> | Ah, WordPress loves XHTML, I forgot |
| 16:58 | <Domenic> | Hmm nope, even after closing my <p> tags it still insists on stripping them. |
| 16:59 | <Domenic> | (in the preview at least) |
| 16:59 | <caitp> | who doesn't love xhtml |
| 16:59 | <Domenic> | Ah just don't switch back to "Visual" mode is the trick |
| 17:02 | <annevk> | zcorpan: DataQ? |
| 17:04 | <Ms2ger> | zcorpan, tests, tests, tests :) |
| 17:05 | <Domenic> | w00t w00t. https://blog.whatwg.org/streams |
| 17:09 | <smaug____> | Domenic: why Stream spec doesn't use webidl? |
| 17:10 | <caitp> | why would you want engines to generate bindings for your interface automagically? |
| 17:11 | <caitp> | and have a canonical source for what those bindings should look like easily laid out in a format that people can understand |
| 17:13 | <smaug____> | heh |
| 17:13 | <caitp> | but yeah it does actually read a lot more like es262 than html |
| 17:13 | <caitp> | is that intentional? |
| 17:13 | <Domenic> | it is intentional |
| 17:13 | <Ms2ger> | Also wrong |
| 17:13 | <smaug____> | but I might say that I don't expect Stream spec to be implemented in Gecko as it is written now |
| 17:14 | <MikeSmith> | smaug____: why not |
| 17:14 | <Domenic> | it might be possible to make WebIDL semantics match those of the specced (ES-like) semantics via using `any` a lot. |
| 17:16 | <smaug____> | MikeSmith: because having webidl makes the behavior of API easier to understand and makes implementing the API a lot easier, and makes the API work consistently with most of the other web APIs |
| 17:17 | <MikeSmith> | smaug____: I see. I thought you were saying the actual behavior would not match. |
| 17:18 | <smaug____> | I don't know if the behavior what the Stream spec now has maps exactly to webidl interfaces |
| 17:18 | <caitp> | well if the plan is to get it implemented alongside es262 and ecma 402, then it might be sensible |
| 17:19 | <caitp> | question is whether it's supposed to live under js/ or content/ i guess |
| 17:19 | <Domenic> | in Chrome we are investigating ways of implementing it "in V8". Not in the V8 repo, but using the same techniques. |
| 17:20 | <smaug____> | why? |
| 17:20 | <annevk> | Domenic: WebRTC trying to avoid promises again: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26939 |
| 17:21 | <annevk> | Domenic: you want to tweet that post? |
| 17:21 | <annevk> | Domenic: or have @WHATWG RT you? |
| 17:21 | <Domenic> | annevk: just tweeted from @streamsstandard |
| 17:21 | <TabAtkins> | Domenic: Hmm, good point about parsing Editors from the text. You might be right that just hiding it with CSS would help. I can pop a class on the dt/dd so it's easier to hide. |
| 17:22 | <Domenic> | TabAtkins: perfect, I was about to do some :first-child hacks and feel bad. |
| 17:22 | <TabAtkins> | Nah, just a sec, I'll do it right now. |
| 17:22 | <Domenic> | annevk: on WebRTC, their argument is consistency with other state transitions. Which seems... OK. |
| 17:23 | <annevk> | Hiding it with CSS seems bad and might lead to search engine punishment |
| 17:24 | <caitp> | do not operate webrtc while driving. |
| 17:24 | <Domenic> | We could edit the WHATWG bikeshed header to have no editor |
| 17:24 | <annevk> | I think that's better |
| 17:25 | <annevk> | Hixie: do you know when DreamHost plans to update your server? |
| 17:26 | <Ms2ger> | Domenic, you know, Gecko used to do something like the "in V8" implementation you mention before we implemented WebIDL |
| 17:26 | <Ms2ger> | Domenic, it inevitably lead to heaps of security bugs |
| 17:26 | <annevk> | Promises in V8 hit some of those issues |
| 17:27 | <Domenic> | Ms2ger: *shrug*. not sure about Gecko's architecture. Presumably do something similar to what Gecko ended up doing for promises |
| 17:27 | <annevk> | They're still not resolved I think as Allen still doesn't understand event loops... |
| 17:27 | <annevk> | Or does, but is not concerned with the differences |
| 17:29 | <TabAtkins> | Domenic: Okay, done. |
| 17:29 | <TabAtkins> | Domenic: I'll go resolve the issue. |
| 17:29 | <TabAtkins> | Just hide dt.editor, dd.editor |
| 17:29 | <Domenic> | TabAtkins: thanks :). Opinions on hiding with CSS vs. removing from the header template altogether? |
| 17:30 | <Ms2ger> | Latter seems better |
| 17:30 | <TabAtkins> | I think you're right that it should stick around in the HTML, so that things which try and parse out editor data for the purpose of bibliography compilation can still receive it. |
| 17:31 | <Ms2ger> | Why should editor names be listed in the bibliography anyway? |
| 17:31 | <TabAtkins> | Because it's standard biblio format. |
| 17:31 | <TabAtkins> | You list authors, which editors are. |
| 17:31 | <Ms2ger> | Unicode doesn't, for example |
| 17:32 | <annevk> | Is anyone else skimming the "after 5" minutes? |
| 17:33 | <Ms2ger> | Not me |
| 17:33 | <annevk> | "<tantek> +1 to darobin points about 5.1 has too much in it. Saner to work from CR branch." |
| 17:33 | <Ms2ger> | Was anyone expecting the HTMLWG to suddenly make sensible decisions? |
| 17:33 | <annevk> | There's also a bit about how they want to avoid copying from Hixie but are not sure if everything in 5.1 needs to be revisited in that light |
| 17:34 | <annevk> | And a lot of grand talk about modules (with nobody ending up doing much I suspect) |
| 17:35 | <annevk> | I don't know. It's like they don't even realize they needed 10 or so people just to copy-and-paste stuff, and even then ended up with something that's a year old |
| 17:40 | <annevk> | Why does Chrome claim mixed content on https://blog.whatwg.org/streams is that because of SHA-1? |
| 17:45 | <annevk> | Error console says nothing |
| 17:53 | <annevk> | zcorpan: ideas on how to make https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533 work for <img>? |
| 17:54 | <annevk> | I like the fetch-settings="" idea, but the existing elements seem to want something even more complicated... |
| 18:01 | <Domenic> | annevk: no mixed content in my chrome (stable or canary) |
| 18:12 | <wilhelm_> | annevk: The WebDriver spec needs to reference a JSON spec. Which one should we point to? |
| 18:12 | <Domenic> | hahahahahahaha |
| 18:13 | <Domenic> | probably http://www.ecma-international.org/publications/standards/Ecma-404.htm |
| 18:14 | <wilhelm_> | Now, that's a confusing spec name. :D |
| 18:17 | <Domenic> | annevk: looks like URL removed <hr title="Separator for the header"> (which is invisible anyway); any reason not to do so for streams too? |
| 18:23 | <TabAtkins> | Domenic: That's a weird artifact of the standard W3C style; no need for it in WHATWG, so feel free to kill it from your header file. |
| 18:23 | <Domenic> | TabAtkins: ah k, well, see my pull request |
| 18:23 | <Domenic> | was wondering if maybe it was for screenreaders or something |
| 18:24 | <TabAtkins> | Domenic: You're killing the copyright notice? |
| 18:24 | <TabAtkins> | You probably want that *somewhere*. |
| 18:24 | <TabAtkins> | Maybe in the footer. |
| 18:24 | <Hixie> | annevk: i know nothing about dreamhost updating any servers |
| 18:25 | <Domenic> | TabAtkins: yep, in the acknowledgments, see e.g. https://dom.spec.whatwg.org/#acknowledgments |
| 18:26 | <TabAtkins> | Oh, ok. |
| 18:26 | <TabAtkins> | Merged, thanks. |
| 18:26 | <zcorpan> | annevk: i don't know. would be useful to have another feature fleshed out so i better understand how it's supposed to work in simple cases |
| 18:28 | <TabAtkins> | Domenic: Do you expect copyright to be different for different WHATWG specs? If not, it should really move into the boilerplate, so people can't forget to free the document. |
| 18:29 | <Domenic> | TabAtkins: not really, but, unsure how to place it as "last sentence of acknowledgments" |
| 18:30 | <TabAtkins> | Interesting placement requirement. That is, by definition, not in the boilerplate. Why does it have to go right there? |
| 18:32 | <Domenic> | it's a nice place, talking about the rights the editor gives away right next to the editor attribution. |
| 18:35 | <TabAtkins> | I mean, okay, but it's inconvenient. :/ |
| 18:35 | <TabAtkins> | (And copyright notices are usually placed somewhere at the end of documents.) |
| 18:35 | <TabAtkins> | I just want to help other WHATWG editors avoid forgetting to release copyrights. |
| 18:35 | <Domenic> | Interestingly, acknowledgements are the very last thing in DOM |
| 18:35 | <TabAtkins> | And you, in the future, when you write more specs. |
| 18:36 | <Domenic> | and URL |
| 18:36 | <TabAtkins> | Yeah, acks are usually the very last thing, so if you just wanna put it first in the footer boilerplate, it'll generally work. |
| 18:36 | <TabAtkins> | (Acks are very nearly boilerplate, in comparison with content, so I think people naturally gravitate to placing it last.) |
| 18:36 | <Domenic> | Streams does Conventions > Acks > Conformance > References > Index |
| 18:37 | <TabAtkins> | All of those but Acks should just be in the footer boilerplate. |
| 18:37 | <Domenic> | yeah the question is ordering. (Also conventions is a bit different at least how i am using it) |
| 18:39 | <JonathanNeal> | Is there a marketplace for web apps that isn’t locked to one os or browser? |
| 18:40 | <Domenic> | yes, google.com |
| 18:40 | <Domenic> | (or bing.com if you're a hipster) |
| 18:43 | <TabAtkins> | Domenic: I mean, do what you want, but there's a limit to how much complexity I'm willing to put into Bikeshed to handle ordering preferences when it's just a matter of weak taste preferences. Every time you want to put something boilerplate-y *before* something spec-specific, you'll have to remove it from the actual boilerplate and reproduce it manually in |
| 18:43 | <TabAtkins> | each of your specs. CSSWG chose to just accept whatever ordering fell out of the spec-specific/boilerplate distinction. |
| 18:44 | <Domenic> | TabAtkins: yeah I don't feel strongly. Mostly just following annevk's lead. Which might not be great given he hasn't moved to Bikeshed yet, but at least in terms of output his edits have improved DOM and URL and so I wanted to follow along. |
| 18:45 | <JonathanNeal> | Domenic: first, hipsters don’t use bing, second, come on man. |
| 18:45 | <Domenic> | Dunno, just wanted to give an option that wasn't affiliated with my employer. DuckDuckGo? |
| 18:45 | <caitp> | hipsters microbrew their own search engines, jeeze |
| 18:46 | <TabAtkins> | Domenic: Ooh, just realized that you can use the `boilerplate` attribute for this. You can actually very easily move spec-defined things into an arbitrary position in your boilerplate. |
| 18:46 | <TabAtkins> | Domenic: Put an empty <div data-fill-with="foo"></div> in your boilerplate file, then do a <div boilerplate="foo">...</div> in your spec. |
| 18:46 | <Domenic> | Ah OK, cool. |
| 18:46 | <TabAtkins> | Bikeshed'll shuffle the contents from the `boilerplate` element into the `data-fill-with` element, and remove the now-empty `boilerplate` one from the doc. |
| 18:47 | <TabAtkins> | Just make up whatever terms you want; the boilerplate=>data-fill-with movement doesn't care what names are used. |
| 18:48 | <Domenic> | (Yay, such a nice, clean header: https://streams.spec.whatwg.org/) |
| 18:48 | <TabAtkins> | So you can just put the data-fill-with=copyright right after the data-fill-with=acks, and get the display you want. |
| 18:48 | <Ms2ger> | annevk, should hasAttribute call https://dom.spec.whatwg.org/#concept-element-attributes-get-by-name ? |
| 18:49 | TabAtkins | should add a "Making boilerplate for your spec org" doc. |
| 18:50 | <Domenic> | ^ yes, do that ^_^ |
| 18:51 | <caitp> | in the old days, boilerplate was a filing cabinet and cost 700 dollars just to set up |
| 18:53 | <caitp> | which is about what it costs now depending on how valuable your time is |
| 18:54 | <MikeSmith> | JonathanNeal: what kind of web apps are you talking about |
| 18:56 | <JonathanNeal> | The kind that becomes a home screen icon. Chrome has something like this, where any page can become its own desktop app. Android and iOS have something similar. But I haven’t seen a repo of all the web apps that can be searched, rated, etc. I might be obvious and I’m missing it |
| 18:59 | <Domenic> | you have. it is literally the entire web. that is the beauty of it. |
| 19:00 | <Domenic> | "become its own desktop app" is just "bookmark it" |
| 19:01 | <JonathanNeal> | no, the beauty of the web is that it’s bigger than just apps but built on on something intended for documents |
| 19:01 | <JonathanNeal> | google agnostically aggregates news, i’m looking for something that aggregates apps |
| 19:02 | <caitp> | you could call it appgregator! |
| 19:02 | <caitp> | new startup idea go |
| 19:03 | <SteveF__> | Element.getComputedRole() thread on PF list http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/thread.html#msg120 |
| 19:03 | <MikeSmith> | JonathanNeal: there is no special "kind that becomes a home screen icon", since you can do add-to-home-screen with literally any web site/app |
| 19:03 | <SteveF__> | ^^ wrong channel |
| 19:04 | <caitp> | can you? |
| 19:04 | <MikeSmith> | sure |
| 19:04 | <caitp> | you mean through the browser and not via a web api |
| 19:04 | <MikeSmith> | that's what JonathanNeal means afaict |
| 19:04 | <caitp> | i would be scared if we were letting javascript developers put random things on your home screen |
| 19:05 | <MikeSmith> | he's not talking about a web api for adding things to home screen |
| 19:06 | <caitp> | i think he was talking about basically a searchable list of applications |
| 19:06 | <MikeSmith> | well then, what Domenic said |
| 19:07 | <MikeSmith> | twitter.com is an application |
| 19:07 | <MikeSmith> | etc. |
| 19:07 | <caitp> | it actually wouldn't be a terrible idea, although i'm not sure where the revenue would come from |
| 19:08 | <MikeSmith> | it wouldn't be a terrible idea to have a marketplace to help you find applications like twitter.com? |
| 19:08 | <caitp> | well, more for the tinier ones |
| 19:08 | <caitp> | sort of like a way to find all of the funded and finished kickstarter projects |
| 19:08 | <caitp> | without all of the garbage in between |
| 19:08 | <caitp> | you'd hate to curate it carefully |
| 19:09 | <caitp> | would be a nice way to find new things that might be interesting |
| 19:09 | <caitp> | without having to read hacker news all day or something |
| 19:09 | <MikeSmith> | the way that the Apple App Store does that so well for you now? |
| 19:10 | <MikeSmith> | curates things without all the garbage in between? |
| 19:11 | <caitp> | without all the garbage! you know what I'm talking about --- if you were able to find apps via the dewey decimal system instead of by reading the newspaper |
| 19:11 | <caitp> | like "find what I'm looking for, avoid self-aggrandizing crap" |
| 19:12 | <Domenic> | i think cern tried that for a while |
| 19:12 | <Domenic> | then later yahoo |
| 19:12 | <Domenic> | they stopped |
| 19:12 | <MikeSmith> | yeah |
| 19:12 | <MikeSmith> | search engines happened |
| 19:13 | <caitp> | they just don't do a very good job at the whole dewey decimal system thing |
| 19:13 | <caitp> | and they're happy to show you press releases for a particular popular app of the particular type that you're looking for, rather than a comprehensive list of all entries |
| 19:13 | <caitp> | it would be hard to curate, I wouldn't want to do it |
| 19:13 | <caitp> | but it would be pretty cool if it existed |
| 19:14 | <caitp> | i don't know why i'm saying curate, that's not the word i'm looking for |
| 19:14 | <caitp> | word is not in my head right now, will find it later =) |
| 19:15 | <caitp> | lets say "collect" |
| 19:15 | <mattypants> | aggregate? |
| 19:15 | <MikeSmith> | it's kind of not super productive to talk about this in the abstract |
| 19:16 | <caitp> | yeah, I'm not claiming this to be a productive use of my time |
| 19:16 | <MikeSmith> | caitp: without talking about specific apps I mean |
| 19:17 | <caitp> | lets say you wanted to find a list of twitter-like applications |
| 19:17 | <MikeSmith> | ok |
| 19:17 | <caitp> | if you were to search on google for that, what would you find |
| 19:17 | <caitp> | you'd find a whole lot of twitter, and not much else |
| 19:17 | <MikeSmith> | you'd find twitter |
| 19:17 | <mattypants> | identica |
| 19:18 | <MikeSmith> | caitp: right, because in practice there really isn't anything else |
| 19:18 | <caitp> | is that why? |
| 19:18 | <MikeSmith> | mattypants: right, and nobody uses identica |
| 19:18 | <caitp> | in practice it's because anything ubiquitous is going to dominate the search results |
| 19:18 | <MikeSmith> | caitp: in that case of twitter, yeah |
| 19:18 | <MikeSmith> | nobody searches for twitter-like apps, or wants to |
| 19:19 | <MikeSmith> | in the real world |
| 19:19 | <mattypants> | microblogs apps |
| 19:19 | <caitp> | well sure, your'e probably going to use what your friends and cow-orkers use |
| 19:20 | <caitp> | but that might not be a good thing, is what I'm saying |
| 19:22 | <MikeSmith> | you find useful stuff on the web mostly just by typing search terms into a web browser that describe what you're looking for |
| 19:22 | <MikeSmith> | as end users I don't most of us find that broken, or find it to be a hardship |
| 19:22 | <caitp> | it works to a point, but it could be better |
| 19:24 | <caitp> | the way things are, you do have people aggregating information for their little areas, and if you find the right aggregator, you're probably good for a while when it comes to that particular area of your interests |
| 19:24 | <MikeSmith> | right |
| 19:37 | <mattypants> | why is xml based technology, i.e., xhtml less appropriate than the current spec? |
| 19:37 | <Ms2ger> | Its draconian error handling is often problematic |
| 19:37 | <Ms2ger> | But note that the current spec does include an XML serialization |
| 19:40 | <caitp> | i feel like the draconian error handling is actually less problematic than the weirdness that html parsing does ---not that you guys can change it, I know you want to--- |
| 19:42 | <ekoka> | are they any plans to empower anchors with http methods? |
| 19:43 | <mattypants> | caitp, what do you mean by html parsing weirdness |
| 19:44 | <caitp> | re-arranging content |
| 19:44 | <caitp> | rewriting your users novel |
| 19:44 | <caitp> | it's always been a terrible idea |
| 19:45 | <caitp> | not only is it more complicated to implement, but nobody actually wants it implemented in the first place |
| 19:45 | <caitp> | not a single person on earth is happier with it |
| 19:45 | <mattypants> | default formatting? |
| 20:02 | <JonathanNeal> | just catching up, thanks for making me feel not-crazy, caitp |
| 20:02 | <caitp> | do you feel not-crazy because caitp is crazier? that's how that usually works :p |
| 20:06 | <JonathanNeal> | no, i felt less crazy because you understood the usefulness of it |
| 20:14 | <wanderview> | jsbell: ping |
| 20:14 | <jsbell> | wanderview: ?? |
| 20:15 | <wanderview> | jsbell: hi! are you familiar with the blink SW cache API tests? |
| 20:15 | <jsbell> | wanderview: yes |
| 20:15 | <wanderview> | jsbell: got a minute to compare notes? I'm trying to run them against gecko |
| 20:15 | <jsbell> | wanderview: sure! |
| 20:16 | <wanderview> | jsbell: so I'm looking at the vary tests in cache-match.html |
| 20:16 | <wanderview> | :-( |
| 20:16 | <jsbell> | Whoops, sorry. |
| 20:16 | <wanderview> | jsbell: np :-) |
| 20:17 | <wanderview> | jsbell: in cache-match.html... shouldn't the second entry in vary_entries overwrite the first entry? |
| 20:17 | <wanderview> | since the request for vary_cookie_is_cookie will match the entry for no_vary_header |
| 20:19 | <wanderview> | jsbell: it seems the "ignoreVary" test expects all 5 of these entries to exist in the cache |
| 20:20 | <jsbell> | wanderview: I believe I agree with your reasoning, let me ponder a bit... |
| 20:20 | <wanderview> | jsbell: thanks... I have to run to meet a delivery... back in a bit |
| 20:33 | <wanderview> | jsbell: I also saw this issue... not sure if you saw it on blink-dev: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zNeWtU04TB4/ivBdbRIxuHEJ |
| 20:36 | <jsbell> | wanderview: yeah, saw that. I agree in theory; it wouldn't surprise me if the spec needed an addition to cover it (haven't looked in detail, though) |
| 20:36 | <jsbell> | wanderview: better test would be with a ?query |
| 20:38 | <wanderview> | jsbell: yea... that would work for the prefix test... note, though, there is another test case the explicitly checks to see if match ignores fragment |
| 20:38 | <wanderview> | weird that it expects match to ignore fragment, but then expects the fragment to be stored |
| 20:38 | <wanderview> | did the spec used to do that? |
| 20:41 | <jsbell> | wanderview: probably just an oversight in the test; we wanted to get the tests landed then iterate (fixing code and tests as appropriate); matchAll isn't implemented yet, so it hasn't shown up as test failures. |
| 20:41 | <wanderview> | jsbell: ah... I missed that |
| 20:42 | <wanderview> | jsbell: the plan is to ship with just match then? |
| 20:42 | <jsbell> | wanderview: you can look at the match-match-expected.txt file to see what our code is currently doing |
| 20:43 | <mattypants> | "The W3C spec is intended to follow the W3C process to REC." <--- Is REC short for recommendation? |
| 20:44 | <jsbell> | wanderview: it seems unlikely we'll get it done before our milestone branch point, and "you can build interesting things without it" so not having it doesn't appear to be a blocker. |
| 20:44 | <jsbell> | Wow, lots of negatives in that sentence. :P |
| 20:44 | <wanderview> | jsbell: I understood :-) no problem |
| 20:45 | <wanderview> | jsbell: if I find other problems with the tests, should I write bugs somewhere? |
| 20:46 | <wanderview> | or just ping you here |
| 20:46 | <jsbell> | wanderview: please do - crbug.com or ping me |
| 20:46 | <wanderview> | jsbell: want me to write bugs for these two issues? |
| 20:47 | <boogyman> | wanderview: yes, the url was provided. |
| 20:47 | <wanderview> | will do... just wasn't sure if he already did or something |
| 20:47 | <jsbell> | wanderview: I haven't, go right ahead :) |
| 20:52 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27185 i recall proposing this back in 2005 or so |
| 20:54 | <wanderview> | jsbell: did I do this right? https://code.google.com/p/chromium/issues/detail?id=428965 |
| 20:55 | <jsbell> | wanderview: looks fine; I'll tag it with labels (since I have permissions) |
| 20:57 | <jsbell> | wanderview: also, distracted since the cache batch operations algorithm in the spec appears to have been broken by a recent spec update; squinting to see if i'm crazy or not |
| 20:57 | <wanderview> | jsbell: hmm, where? I haven't looked closely at it recently |
| 20:59 | <zcorpan> | hmm can't find anything in the archives though |
| 21:00 | <jsbell> | hrm, maybe not... |
| 21:00 | <TabAtkins> | Hmm, I can't find that old Sam Ruby blogpost where he talks about a comment that was accidentally allowed through with a well-formedness error (killing his blog), and he couldn't remove it because it was displayed in the blog editting page (making it have a well-formedness error as well). |
| 21:02 | <zcorpan> | TabAtkins: maybe you can't find it because it's not well-formed? |
| 21:02 | <TabAtkins> | Probably, yes. |
| 21:03 | <wanderview> | jsbell: and the second one... thanks again for the help! https://code.google.com/p/chromium/issues/detail?id=428970 |
| 21:04 | <TabAtkins> | mattypants: Yes, "REC" is shorthand for Recommendation. |
| 21:05 | <mattypants> | Thanks, TabAtkins |
| 21:07 | <jsbell> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/545 last comment. But I may be crazy. |
| 21:08 | <wanderview> | jsbell: I agree... it shouldn't look at previously stored data for that check |
| 21:09 | <wanderview> | I haven't implemented addAll() yet... so I haven't hit any of this |
| 21:09 | <jsbell> | wanderview: nor have we (just a polyfill on top of fetch+put, which misses out on the batch semantics) |
| 21:09 | <mattypants> | I'm having trouble interpreting the second sentence of 'The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.' |
| 21:10 | <mattypants> | from whatwg.org's faq |
| 21:10 | <mattypants> | "The W3C spec is intended to follow the W3C process to REC"? |
| 21:10 | <Ms2ger> | Yes |
| 21:10 | <Ms2ger> | Matching reality is not a goal of the W3C spec |
| 21:11 | <mattypants> | so the W3C jut wants to get the recommendation snapshot complete |
| 21:11 | <Ms2ger> | And get good PR |
| 21:12 | <Ms2ger> | It is claimed that there are other goals as well, but actions don't appear to reflect that |
| 21:12 | <wanderview> | jsbell: of course the previous wording is also a bit bogus because it doesn't say to match against the request/response pair... it needs the response to do a "match" |
| 21:18 | <wanderview> | JakeA: annevk: currently Fetch Request.url getter ignores the fragment... should Cache therefore also ignore the fragment or are we supposed to somehow get the full URL behind the scenes? |
| 21:20 | <wanderview> | just curious what the intention is |
| 22:35 | <annevk> | wanderview: caches should ignore the fragment |
| 22:35 | <annevk> | wanderview: we could prolly remove it when you initialize a Request |
| 22:35 | <annevk> | wanderview: I wasn't sure if there was some point when we wanted to expose it |
| 22:36 | <annevk> | wanderview: so I kept it in the data model but not exposed anywhere |
| 22:36 | <annevk> | Ms2ger: might be nicer |
| 22:37 | <annevk> | zcorpan: if you could write down what's unclear in that bug I'd appreciate it |
| 22:38 | <annevk> | zcorpan: the basic idea is that given a URL and some other input the API creates a Request object that is then passed to the fetch algorithm; the Request object is also exposed through an API somehow so people can inspect what kind of request got made |
| 23:04 | <wanderview> | jsbell: ^^^ see above from annevk |
| 23:20 | <jsbell> | wanderview: thx |
| 23:28 | <zcorpan> | annevk: done |
| 23:55 | <wanderview> | jsbell: btw, thank you very much for these tests in the first place! I've found a lot of bugs in my implementation thanks to them :-) |
| 23:56 | <jsbell> | wanderview: asanka⊙co authored them, I've just been reviewing/tweaking 'em |
| 23:56 | <jsbell> | but on behalf of chromium, you're welcome! |
| 23:57 | <Domenic> | wtf document.body.baseURI is ENTIRELY DIFFERENT between Chrome and Firefox |
| 23:57 | <jsbell> | wanderview: asanka@ has some of the helpers like promise_test() submitted as changes to testharness.js but they haven't been accepted yet (and we've been a little busy to pester) |
| 23:58 | <wanderview> | jsbell: well, I pinged jgraham to help me get these tests running in gecko... as a result he said he was going to go review that PR |
| 23:58 | <jsbell> | I love it when a plan comes together! |
| 23:58 | <wanderview> | :-) |
| 23:59 | <Domenic> | aaand baseURI is just plain undefined in IE11 |