| 01:34 | <Domenic_> | annevk-cloud: why does ServiceWorker want multi-destination streams exactly? I can't quite understand it from that issue. |
| 01:45 | <TabAtkins> | zewt: While there *is* a tc39 proposal for overriding the behavior of [], it would still be bad to make that the default for Maps, because of how JS treats .foo and ['foo'] identically. As Domenic_ has said, making maps use [] by default would break a *lot* of code that is currently assuming you can do obj[v] to access a property. And without that [] |
| 01:45 | <TabAtkins> | ability, JS has no way to access a property whose name is stored in a string. |
| 01:45 | <TabAtkins> | (Python has a special function just for that - getattr() and setattr(). They're clumsy to use.) |
| 01:46 | <zewt> | they're identically clumsy to map.get() and map.set(), and that's okay because accessing a raw property on a map (rather than a key stored in the map) is rare |
| 01:47 | <TabAtkins> | It's fun to claim that, but every metaprogramming function ever uses computed properties. |
| 01:48 | <zewt> | (i was referring to leaving .foo and ["foo"] the same, but allowing properties to have non-string values, which of course wouldn't be accessible via .foo; an alternative is detaching .foo and ["foo"], but that wasn't what I was talking about) |
| 01:48 | <zewt> | i've used python extensively, and getattr() is definitely the exception (but it's not really a useful comparison, since python already treats .foo and ["foo"] as two different things) |
| 01:48 | <TabAtkins> | And Map#get() and #set() are less clumsy, because they're used consistently. Even Python's getattr() and setattr() are less clumsy than they would be in JS, because they're the *only* way to get computed property names. Your suggestion would mean that *some* objects can have their properties accessed with obj[v], but not all. |
| 01:49 | <zewt> | they're not at all used consistently, because the dictionaries everyone already uses are simple objects that don't have .get or .set at all |
| 01:49 | <TabAtkins> | You're using "consistently" in a different manner than I am. |
| 01:49 | <TabAtkins> | You're referring to I guess consistency with existing practice. |
| 01:49 | <zewt> | i have endless amounts of code passing around dictionaries as objects; making Map have .get and .set instead of using [] means *none* of that code works with Map |
| 01:49 | <TabAtkins> | Which is terrible, and the whole reason we invented Maps. |
| 01:50 | <TabAtkins> | Mixing up keys and properties is super terrible. |
| 01:50 | <TabAtkins> | But we just grin and bear it right now, because there's no other way to get O(1) maps. |
| 01:50 | <zewt> | dominic's argument was that code assumes properties are strings, so allowing foo[Object] would break lots of code with that assumption; i'm saying that might be so (can't think of any real examples), but you trade for definitely not working with tons of code, which assumes key/value stores accessed with [] |
| 01:50 | <TabAtkins> | I'm sorry that it took so long for JS to grow a Map class, but it's designed well now that it exists. |
| 01:52 | <zewt> | not being able to use simple objects and Map interchangeably for the "simple dictionary" pattern means I'm going to default to using objects, and only ever use Map when I really, specifically need to store non-string keys; that's a bad result |
| 01:53 | <TabAtkins> | Shrug, that'll definitely happen sometimes. |
| 01:53 | <zewt> | no, it'll happen all the time |
| 01:53 | <TabAtkins> | I wish {} hadn't already been claimed for object literals. :/ |
| 01:54 | <zewt> | well, it would be nice if JS was like Python and treated .foo and ["foo"] as two different things, but that's not what we're talking about |
| 01:54 | <TabAtkins> | Regardless, unless we *also* overrode the behavior of .foo, you'd *still* run into the same problems you're outlining. |
| 01:55 | <zewt> | ... but we're *talking* about overriding both ["foo"] and .foo, since they're the same thing |
| 01:55 | <TabAtkins> | Because people like doing obj.foo over obj['foo'] when the "foo" is a literal. |
| 01:55 | <TabAtkins> | No, jeez, that's so terrible. |
| 01:59 | <zewt> | nobody is suggesting making ["foo"] and .foo different |
| 01:59 | <TabAtkins> | Every Map would have a "toString" key in it automatically, or at least would *look* like it did. +"get", "set", "delete", and others. |
| 01:59 | <zewt> | just make Map have no members and have an identical interface as a simple Object, and things that act on them go elsewhere (which is also consistent with what we already have, eg. Object.keys) |
| 01:59 | <TabAtkins> | Object.keys is a hack around the problem that we don't want more properties to show up on everything. Maps are like normal objects, which have their behavior as methods on themselves. |
| 01:59 | <TabAtkins> | Having to do Map.clear(m) would be so shitty. :/ |
| 01:59 | <zewt> | trivially, inconsequentially shitty |
| 01:59 | <zewt> | at the "it would be nice" level |
| 01:59 | <TabAtkins> | It's inconsistent with how virtually every other object in the entire language works, except for Object itself, which is an exception for obvious reasons. |
| 01:59 | <zewt> | Object.keys(foo) is a bit annoying (compared to foo.keys()); having object dictionaries and Map dictionaries have different interfaces is massively annoying |
| 01:59 | <TabAtkins> | Seriously, for every argument that it would be consistent in one way, it's less consistent in another way, seemingly worse way. |
| 01:59 | <zewt> | i'd say the opposite: having Map have a different API (at least among the things discussed here so far) gives minor academic prettiness, at the expense of bigger failures |
| 02:00 | <zewt> | anyway, the result is that Map will be a type used for special-purpose scenarios, where you specifically need to stash things with objects as keys, and never a general-purpose container ... which is something the Web can live with (we've lived with string keys this far, after all), it's just sucky |
| 02:01 | <TabAtkins> | I agree that it would be *nice* for Maps and Objects-as-Maps to work the same way, but to make it happen, you have to accept several of the downsides of Objects-as-Maps (which we were trying to get away from) and having to structure the operations in a weird way that doesn't match anything else. |
| 02:02 | <zewt> | to me it seems better to match the dictionaries everyone is using, instead of a dictionary class that matches everything *except* ... you know, dictionaries |
| 02:02 | <TabAtkins> | Welp, I've explained why it's not better, or at least why I and TC39 think it's not better, so shrug. |
| 02:03 | <zewt> | i don't know much about TC39, except that every time I see that sequence of letters, it's about something I think is badly designed, heh |
| 02:04 | <TabAtkins> | Don't take this the wrong way, but most of the time when I see you complaining about it, I think you're on the wrong side. ^_^ |
| 02:04 | <zewt> | oh well |
| 02:07 | <Hixie> | zewt: if it makes you feel any better, most of the time when i see tab defending TC39, I think _he's_ on the wrong side, so... :-) |
| 02:07 | <zewt> | <TabAtkins> oh well |
| 02:07 | <Hixie> | then again, my preferences in languages are basically diametrically opposed to javascript's basic philosophies, so it's not particularly surprising |
| 02:08 | <zewt> | i wish bugzilla would post to lists in a way gmail threads properly |
| 02:08 | <zewt> | it's annoying eg. reading the set()/toggle() bug, searching through dom for a minute and seeing "oh, toggle does this", then loading the bug and seeing that was already commented, it just ended up as a separate thread |
| 02:08 | <Hixie> | don't use gmail? |
| 02:08 | <zewt> | i think it's the "new:" it adds to new bugs that screws up gmail |
| 02:09 | <zewt> | yeah "change to a different email client" is pretty much never a useful solution, heh |
| 02:09 | <Hixie> | oh actually yeah, that particular one breaks even in pine |
| 02:09 | <zewt> | don't use pine? |
| 02:09 | <zewt> | :P |
| 02:19 | <zewt> | heh, i guess that's a pattern that fundamentally disagrees with the "arguments not passed should act like they're set to undefined" idea |
| 02:19 | <zewt> | (classList.set("foo", false)) |
| 02:19 | <zewt> | actually I guess not and I'm just tired |
| 02:20 | <zewt> | maybe I should be watching TV and zoning out instead of reading specs on Sunday night |
| 02:43 | <zewt> | losing hope in humanity at still having to explicitly configure screen to utf-8 |
| 07:01 | <MikeSmith> | BOM breaks Crosswalk testing? https://github.com/w3c/web-platform-tests/pull/400 |
| 07:04 | <MikeSmith> | Hixie: about troubleshooting the bugzilla problem if you think it might help, I can ask somebody to look at the server logs |
| 07:04 | <MikeSmith> | (I'd do it myself but I don't have shell access to the server) |
| 07:17 | <MikeSmith> | 笑 serious discussion about now adding a usemap-N attribute |
| 07:17 | <MikeSmith> | good times |
| 07:59 | <zcorpan> | hmm, problem with usemap i hadn't seen mentioned before |
| 08:11 | <zcorpan> | Hixie: the login thing in the spec is gone? |
| 08:22 | <MikeSmith> | zcorpan: the usemap thing shows another reason why an attribute-based solution is suboptimal here. Along with the specific existing problem of making it work with usemap, it come with the same problem for any new attributes we might want to add to img later (attributes whose values might need to vary based on the properites of the image) |
| 08:25 | <zcorpan> | MikeSmith: i don't think it shows that it's suboptimal. you either want an existing feature of img to work, and you have to provide it, or you don't and don't, regardless of img vs picture |
| 08:25 | <MikeSmith> | of course |
| 08:27 | <MikeSmith> | but with picture it doesn't require anything more than adding a usemap analog to source |
| 08:27 | <MikeSmith> | or just usemap |
| 08:28 | <MikeSmith> | whereas with src-N it requires introducing further mess |
| 08:28 | <MikeSmith> | from an authoring point of view |
| 08:28 | <zcorpan> | well first we need to consider whether we need to have the usemap feature available at all together with image switching |
| 08:28 | <MikeSmith> | true |
| 08:30 | <zcorpan> | most features of img we actually want to work the same, i think |
| 08:31 | <MikeSmith> | yeah I would think so |
| 08:32 | <zcorpan> | so that argues for using <img>, but doesn't argue for attributes for the sources - it *could* do what <input list> does |
| 08:33 | <zcorpan> | i'm not sure that's an awesome solution either though; it requires the author to mint IDs for all images |
| 08:35 | <zcorpan> | or it could check the next element sibling, like <img usesourcelist alt ...><sourcelist>... |
| 08:36 | <MikeSmith> | still seems better than minting yet another attribute |
| 08:37 | <zcorpan> | what attribute? |
| 08:38 | <MikeSmith> | I meant yet another attribute like src-N |
| 08:38 | <MikeSmith> | with some complex microsyntax |
| 08:39 | <zcorpan> | for usemap you mean? |
| 08:39 | <MikeSmith> | just for the usemap case |
| 08:39 | <MikeSmith> | yeah |
| 08:39 | <zcorpan> | ok. yeah i don't disagree. but i'm not convinced we need usemap |
| 08:41 | <MikeSmith> | yeah, me neither |
| 08:41 | <MikeSmith> | but I think others are likely to say it needs to be supported for the src-N case |
| 08:43 | <zcorpan> | that doesn't make it a good idea to do it |
| 08:43 | <Ms2ger> | Like src-N? ;) |
| 08:44 | <zcorpan> | like anything, just people saying "this is needed" by itself doesn't mean much |
| 08:46 | <zcorpan> | as for usemap, if it needs anything, the first step would be to explore real cases where you'd use it and see what is actually needed. maybe what we really need is an event when there's a breakpoint switch |
| 09:05 | <MikeSmith> | hsivonen: when I take a document with an HTML4 doctype and feed it to validator.nu, and I manually choose an HTML5 preset, I'd expect to see an "obsolete doctype" warning. But I don't. |
| 09:06 | <Ms2ger> | Is it an allowed one? |
| 09:06 | <MikeSmith> | http://validator.nu/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C%2521DOCTYPE%2520HTML%2520PUBLIC%2520%22-%252F%252FW3C%252F%252FDTD%2520HTML%25204.01%252F%252FEN%22%2520%2520%22http%253A%252F%252Fwww.w3.org%252FTR%252Fhtml4%252Fstrict.dtd%22%3E%3Ctitle%3Etest%3C%252Ftitle%3E%3Cp%3Etest%250D%250A&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F |
| 09:06 | <MikeSmith> | Ms2ger: yeah |
| 09:06 | <MikeSmith> | and from code inspection I know why it's not emitting the warning |
| 09:07 | <MikeSmith> | the reason is it only emits the warning if the parser mode is set to HTML5 parsing |
| 09:08 | <MikeSmith> | which you can do in the validator.nu UI by manually setting the Parser option to HTML5 |
| 09:08 | <MikeSmith> | http://validator.nu/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C%2521DOCTYPE%2520HTML%2520PUBLIC%2520%22-%252F%252FW3C%252F%252FDTD%2520HTML%25204.01%252F%252FEN%22%2520%2520%22http%253A%252F%252Fwww.w3.org%252FTR%252Fhtml4%252Fstrict.dtd%22%3E%3Ctitle%3Etest%3C%252Ftitle%3E%3Cp%3Etest%250D%250A&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=html5 |
| 09:08 | <MikeSmith> | but I don't think users should be expected to do that manually |
| 09:12 | <MikeSmith> | I guess the best way to deal with it would be to be automatically set the parser mode to HTML5 if a user chooses an HTML5 preset |
| 09:14 | <JakeA> | Domenic_: annevk-cloud: Was there any discussion for an "always" method on Promises? |
| 09:14 | <Domenic_> | JakeA: yes, https://github.com/domenic/promises-unwrapping/issues/18 |
| 09:14 | <Domenic_> | it may be possible to get it in now that the fate of promises themselves is less up in the air. but we'll see. |
| 09:15 | <JakeA> | I'm playing around with them, but find myself doing .then(func, func) a lot |
| 09:15 | <JakeA> | or .catch(function(){}) |
| 09:16 | <annevk-cloud> | Domenic_, ask JakeA the streams thing |
| 09:17 | <JakeA> | Domenic_: Ended up with this for displaying cached data then attempting a live update https://gist.github.com/jakearchibald/481ae9e5e72d83147585 |
| 09:17 | <Domenic_> | .then(func, func) has pretty bad semantics, not as good as finally. |
| 09:18 | <Domenic_> | JakeA: what was the service worker use case for piping a stream to multiple destinations? |
| 09:19 | <JakeA> | Domenic_: What you mentioned in your doc. Getting a network response and sending it to the browser and cache at the same time |
| 09:19 | <Domenic_> | JakeA: ah excellent, I guessed right! :D |
| 09:20 | <JakeA> | There's potential for a transformation in between too. Eg, the copy from the network could have state info that you don't want in the cache, eg "Logged in a Jake" which may not be true later |
| 09:21 | <JakeA> | So network stream goes to the browser, but also to a transform to strip bits out, then the cache |
| 09:21 | <JakeA> | That would probably be messy and regexy though, but possibly the best solution for server-constructed sites that want to hack in offline support |
| 09:23 | <JakeA> | Domenic_: Looking at finally… that doesn't recover from the error right? It passes the error along? |
| 09:23 | <JakeA> | If so, I don't think it fits my usecase |
| 09:23 | <Domenic_> | JakeA: right, just like sync try { } finally { } |
| 09:23 | <Domenic_> | yeah, I think you really want an empty catch block |
| 09:24 | <JakeA> | What if .catch() desugared to .catch(function(reason) { return reason })? |
| 09:24 | <JakeA> | That'd work |
| 09:24 | <Domenic_> | seems weird |
| 09:25 | <Domenic_> | arrow functions make it nicer .catch(r => r) |
| 09:27 | <zcorpan> | MikeSmith: why should it warn about the html4 doctype when validating as html5? |
| 09:27 | <JakeA> | showSpinner().then(fetchStuff).catch().then(hideSpinner) |
| 09:27 | <MikeSmith> | zcorpan: because the spec says it's an obsolete doctype |
| 09:27 | <JakeA> | reads well to me as in "catch errors and continue" |
| 09:27 | <Domenic_> | hmm yeah it kind of does |
| 09:28 | <MikeSmith> | zcorpan: and authors should change it to just <!doctype html> |
| 09:28 | <JakeA> | maybe desugaring to .catch(function() {}) would be safer, because you're sure of the value afterwards |
| 09:28 | <Domenic_> | agreed, seems weird to have an error for a value. |
| 09:28 | <zcorpan> | MikeSmith: ok i see it in the spec now. i thought it was supposed to be silently permitted |
| 09:29 | <JakeA> | Domenic_: Shall I make an issue for this, or has the discussion moved elsewhere? |
| 09:29 | <JakeA> | Or are changes to .catch() with no args set in stone now? |
| 09:29 | <Domenic_> | JakeA: issue is great. We'll see what people think. I gotta sleep now though :) |
| 09:29 | <JakeA> | G'night! |
| 09:29 | <MikeSmith> | zcorpan: well I'm not sure the spec explicitly states what conformance checkers should do |
| 09:29 | <MikeSmith> | for this case |
| 09:30 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#warnings-for-obsolete-but-conforming-features |
| 09:30 | <MikeSmith> | ah |
| 09:31 | <MikeSmith> | thanks |
| 09:38 | <MikeSmith> | zcorpan: btw I notice that for HTML4 documents, validator.nu also emits a warning if the doctype lacks a system ID. "Warning: The doctype did not contain the system identifier prescribed by the HTML 4.01 specification." |
| 09:38 | <zcorpan> | MikeSmith: yeah |
| 09:39 | <MikeSmith> | http://validator.nu/?doc=http://qa-dev.w3.org/wmvs/HEAD/dev/tests/html401-strict.html |
| 09:39 | <MikeSmith> | zcorpan: does the HTML4 spec actually say the doctype should have a system ID? |
| 09:43 | <zcorpan> | MikeSmith: " HTML 4.01 specifies three DTDs, so authors must include one of the following document type declarations in their documents." |
| 09:44 | <zcorpan> | you could choose to read it as you must use those exact strings, or must use a doctype that refers to those DTDs, or something in between |
| 09:45 | <zcorpan> | hsivonen read it as FPI+SI, and on a practical matter IE5 Mac uses quirks mode for HTML 4.01 strict without SI |
| 09:45 | <zcorpan> | but it doesn't really matter either way now |
| 09:46 | <MikeSmith> | ok |
| 09:47 | <MikeSmith> | zcorpan: it matters somewhat for me, because I want to replace the legacy W3C validator |
| 09:48 | <zcorpan> | MikeSmith: ok, so what's the goal there? avoid new warnings? be spec-correct? be useful? |
| 09:50 | <MikeSmith> | first, be useful |
| 09:50 | <MikeSmith> | I don't care about avoiding new warnings, as long as they are useful |
| 09:51 | <zcorpan> | so the usefulness here is whether the author cares about quirks mode in ie5 mac |
| 09:52 | <zcorpan> | which is to say that warning about it isn't useful |
| 09:53 | <MikeSmith> | yeah |
| 09:54 | <MikeSmith> | I think it's not a message that any author would find useful at this point |
| 09:54 | <zcorpan> | also see the 4.0 doctype |
| 09:54 | <MikeSmith> | what about it? you mean, no system ID? |
| 09:55 | <zcorpan> | v.nu treats it differently to 4.01 |
| 09:57 | <zcorpan> | but i guess that's ok if you validate as html4 -- the html4 spec says you must use 4.01 after all |
| 09:57 | <MikeSmith> | right |
| 10:36 | <jgraham> | TabAtkins: Having Object.getProperty to do the same as the current behaviour of [], and map behave like you would expect with [] seems like a much better design than what TC39 has. Doing proper introspection in JS already requires the extremely-verbose Object.getOwnPropertyDescriptor to do well so I don't think "introspection should be favoured over API usage" is a good argument |
| 10:46 | <matjas> | if a parent page has <base name=foo>, is it possible to get the `name` from within an iframe in that page? |
| 10:47 | <Ms2ger> | window.parent.document.get...? |
| 10:48 | <matjas> | http://ruxcon.org.au/assets/slides/CSP-kuza55.pptx says <base name=foo> leaks cross-domain |
| 10:48 | <matjas> | i’m trying to understand what the author meant exactly |
| 10:49 | <JakeA> | Anyone feel they know their way around Promises? Would be good to get some thoughts on https://gist.github.com/jakearchibald/785f79b0dea5bfe0c448 |
| 10:49 | <matjas> | IIUC `window.parent.document.get...` would fail if the iframe is on a different origin, right? |
| 10:58 | <Ms2ger> | I'd hope so |
| 10:59 | matjas | asks @kuza55 |
| 11:05 | <jgraham> | What's the name attribute on base? |
| 11:07 | <Ms2ger> | Gives the base name, clearly |
| 11:32 | <annevk> | JakeA: for the XHR code you are not catching all errors... |
| 11:32 | <annevk> | JakeA: e.g. abort |
| 11:33 | <JakeA> | Good point |
| 11:34 | <annevk> | JakeA: why don't you do Promise.race on the cached vs live and use the first result to run updateGallery? |
| 11:35 | <JakeA> | annevk: It's not just first-wins. If cached comes in first, I still want to do a live update. But if live comes in first I don't want to do a cached update |
| 11:35 | <annevk> | Ah |
| 11:36 | <JakeA> | Race would work if I could do if (networkWon) { abortCachedUpdate(); } |
| 11:39 | <annevk> | JakeA: it seems "react to network fetch" doesn't have to be a separate line |
| 11:39 | <annevk> | JakeA: that could be part of liveFetch's callback |
| 11:39 | <annevk> | JakeA: where you set liveFetchResolved |
| 11:40 | <JakeA> | Ah yes, I'd only need it if liveFetch.isResolved were a thing, and updateGallery were async |
| 11:41 | <JakeA> | I *think* I was separating the two fetches & updates, but yeah, not needed |
| 11:41 | <annevk> | and the .race could be refactored by just having then and have showNoDataError hide the spinner |
| 11:42 | <annevk> | not sure what is better |
| 11:42 | <annevk> | it kinda seems you want to hide the spinner when updateGallery is invoked |
| 11:42 | <annevk> | so maybe the .race thing isn't really needed |
| 11:43 | <JakeA> | Nah, I only want to hide the spinner when the gallery is updated as a result of the network fetch, or if it fails, but yeah, it could go there |
| 11:44 | <JakeA> | But I still need the race to show the error if both updates fail |
| 11:45 | <JakeA> | I either call hideSpinner where I do now, or at the end of liveUpdate as .then(hideSpinner, hideSpinner) |
| 11:46 | <JakeA> | Actually, hideSpinner is in the wrong place now |
| 11:46 | <JakeA> | As it'll hide on cachedUpdate, which is shouldn't |
| 11:48 | <JakeA> | It feels like promises haven't really helped write this code |
| 11:48 | <annevk> | JakeA: wait, if you care about both updating failing you should not use .race but .all |
| 11:49 | <JakeA> | .all rejects if one fails but the other succeeds. I only want to catch both failing, which race does right? |
| 11:49 | <JakeA> | It's like array's .some? |
| 11:50 | <JakeA> | (both failing means I have no data to show, which is the only case I want to show an error) |
| 11:51 | <annevk> | Ah yeah, I still don't get why updateGallery needs to be wrapped in a promise though |
| 11:52 | <JakeA> | Yeah, it doesn't. Updated. |
| 11:53 | <JakeA> | annevk: I was returning the result of updateGallery (which is void) so it could be async in future, but I've removed that bit now |
| 11:54 | <annevk> | So yeah, you want finally |
| 11:55 | <annevk> | JakeA: even if updateGallery was async you could return it where you have it now |
| 11:55 | <JakeA> | yeah |
| 11:57 | <JakeA> | So, my conclusions are: "finally" is great. liveFetchResolved is nasty, getting state from the promise would be better. "race" is an unintuitive method name if you're using it to detect all-reject. |
| 11:57 | <jgraham> | \/window 28 |
| 12:06 | <JakeA> | annevk: Thanks for reviewing. I thought this use case would play to Promises strengths, but it's not much cleaner & readable than it'd have been without them |
| 12:12 | <annevk> | JakeA: it might be that Domenic_ has some insights in how to structure that better |
| 12:13 | <JakeA> | annevk: Yeah, that's why I posted it here. I've gone through loads of revisions but it feels like I'm missing a trick |
| 12:15 | <annevk> | JakeA: what you really want I think is to cancel the cached operation if the live succeeds |
| 12:15 | <annevk> | JakeA: we don't have cancellation yet however |
| 12:16 | <JakeA> | Yeah, which I could do with the xhr directly. But I'd only want to call abort if it was in a pending state, so I'd still want to access state from the promise. |
| 12:16 | <JakeA> | I guess I'd get this state from xhr directly |
| 12:31 | <matjas> | jgraham, Ms2ger, re: <base name> according to this document, you can define an element’s (window) name using <base>: http://help.dottoro.com/lhewchgl.php |
| 12:32 | <matjas> | so once you can get data into <base name="…">, you can leak it cross-domain. that’s what the author meant apparently |
| 12:37 | <zcorpan> | matjas: test case showing <base name> doing something, pls :-) |
| 12:39 | <annevk> | Did he mean window.name? |
| 12:39 | <annevk> | And <base target=name>? |
| 12:39 | <annevk> | Because I think that is a long well known leak |
| 12:54 | <zcorpan> | so what's the attack scenario with window.name? |
| 13:00 | <matjas> | annevk, zcorpan: nah, <base name> |
| 13:00 | <matjas> | zcorpan: i’m wondering the same thing |
| 13:01 | <matjas> | zcorpan: ah, the window.name thing i can explain |
| 13:02 | <matjas> | zcorpan: a page without X-Frame-Options can be framed in a document that sets the frame name |
| 13:05 | <MikeSmith> | hsivonen: I have a validator patch and a related htmlparser patch I hope you can take a look at this week |
| 13:05 | <MikeSmith> | https://bitbucket.org/sideshowbarker/validator/commits/43e40934e7573aa44e8d8f0b6364bb4210d394d3/raw/ |
| 13:06 | <MikeSmith> | https://bitbucket.org/sideshowbarker/htmlparser-fork/commits/0c8df2fbb5ed46837954cf1d8ae338ae740848a5/raw/ |
| 13:07 | <zcorpan> | matjas: then navigates to _parent and it gets the name? |
| 13:07 | <matjas> | well, the rest is basically https://bugzilla.mozilla.org/show_bug.cgi?id=444222 |
| 13:10 | <zcorpan> | i think the spec doesn't have that problem. http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-name |
| 13:11 | <zcorpan> | only for top-level |
| 13:20 | <zcorpan> | TabAtkins: moved to http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-name |
| 13:20 | <zcorpan> | er |
| 13:20 | <zcorpan> | http://dev.w3.org/fxtf/geometry/ |
| 13:21 | <hsivonen> | MikeSmith: does the tree builder patch downgrade some errors to warnings? |
| 13:23 | <hsivonen> | MikeSmith: what's the goal of this change? |
| 13:30 | <MikeSmith> | hsivonen: the goal of the TreeBuilder patch is to nu |
| 13:31 | <hsivonen> | MikeSmith: parse error :-( |
| 13:31 | <hsivonen> | anyway, looking at the tree builder patch more closely, it indeed seems to fix a bug, so r+ |
| 13:32 | <MikeSmith> | *not emit an sorry, typing on my mobile |
| 13:32 | <hsivonen> | MikeSmith: what problem does the validator patch solve? |
| 13:34 | <MikeSmith> | hsivonen: validator patch causes a warning to be emitted if the user has manually chosen html5 checking, but the doctype is a html5 or XHTML1 doctype |
| 13:35 | <MikeSmith> | currently we do not emit a warning for that case |
| 13:37 | <MikeSmith> | that is, the case where the user selects an html5 preset without also manually selecting the html5 parser iron |
| 13:37 | <MikeSmith> | *option |
| 13:39 | <MikeSmith> | *but the doctype is an html4 or XHTML1 doctype |
| 13:44 | <MikeSmith> | hsivonen: about the TreeBuilder patch, do I need to open a bugzilla.mozilla bug to have it landed, or you can just land it from that changeset, or...? |
| 13:45 | <hsivonen> | MikeSmith: I can land it. |
| 13:45 | <MikeSmith> | ok |
| 13:45 | <hsivonen> | MikeSmith: r+ on the validator patch, too, I guess |
| 13:45 | <MikeSmith> | thanks |
| 13:46 | <annevk> | zcorpan: ah, I guess today window.name might no longer be reachable |
| 13:58 | <hsivonen> | MikeSmith: does the parser patch have a bug number in *some* Bugzilla? |
| 14:10 | <annevk> | Hixie: https://github.com/search/advanced seems to exist |
| 14:11 | <hsivonen> | MikeSmith: https://hg.mozilla.org/projects/htmlparser/rev/2a1a57b4c8ff |
| 14:16 | <annevk> | jgraham: I recommend setting whatwg/streams to Watch |
| 14:17 | <jgraham> | annevk: What does that do? |
| 14:18 | <jgraham> | (mostly I need to fix my email filters so that not all email from github ends up in the same folder) |
| 14:19 | <annevk> | jgraham: only gives you notifications when mentioned |
| 14:20 | <annevk> | jgraham: oh, "Not watching" is what I meant |
| 14:20 | <annevk> | jgraham: confusingly the label says "Watch" but I guess that's what happens if I press it now |
| 14:20 | <jgraham> | annevk: That seems pretty useless? What I think I want is "one email per new issue, and the ability to subscribe to the issue if I am interested" |
| 14:22 | <jgraham> | (Which isn't possible from github afaik) |
| 14:22 | <jgraham> | Because (insert github rant here) |
| 14:43 | <Ms2ger> | (Second github rant here) |
| 14:48 | <annevk> | arv: so nextElementSibling on DocumentType is not in stable Chrome yet it seems |
| 14:49 | <arv> | annevk: It is not? Let me check. This was changed several months ago (but I only have dev channel here) |
| 14:49 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-style/2013Nov/0016.html |
| 14:52 | <annevk> | Ms2ger: o_O |
| 14:53 | <annevk> | There's only one sensible reply there |
| 14:53 | <arv> | annevk: I just verified that it is in M31 (current stable) |
| 14:54 | <annevk> | arv: oh! |
| 14:54 | <Ms2ger> | annevk, and that's not to reply? :) |
| 14:54 | <annevk> | arv: so <!DOCTYPE html><script>w(document.firstChild.nextElementSibling)</script> in http://software.hixie.ch/utilities/js/live-dom-viewer/ yields <html>? |
| 14:55 | <annevk> | seems like yes |
| 14:55 | <MikeSmith> | hsivonen: thanks |
| 14:55 | <arv> | annevk: yup |
| 14:57 | <MikeSmith> | hsivonen: and no, I hadn't raised a bug for it anywhere, so there anyway wouldn't have been any bug number to mention in the changeset |
| 14:57 | <hsivonen> | MikeSmith: ok |
| 15:01 | <Domenic_> | JakeA: my initial question would be, assume all your functions are sync. How would you write the code then? |
| 15:06 | <JakeA> | Domenic_: https://gist.github.com/jakearchibald/785f79b0dea5bfe0c448#comment-943356 |
| 15:11 | <Domenic_> | JakeA: in that case, https://gist.github.com/jakearchibald/785f79b0dea5bfe0c448#comment-943359 |
| 15:11 | <annevk> | Domenic_: that doesn't allow racing between the cache and network though |
| 15:12 | <annevk> | Domenic_: which would be an advantage of having this async |
| 15:12 | <Domenic_> | annevk: ah, it wasn't clear that was desired, i will revisit in a bit |
| 15:12 | <annevk> | Domenic_: it seems you want to race between them, cancel cache if network is done, but not cancel network if cache is done |
| 15:13 | <annevk> | Domenic_: and then keep the spinner and content up to date while you do all that |
| 15:18 | <JakeA> | Domenic_: The desired process is https://gist.github.com/jakearchibald/785f79b0dea5bfe0c448#comment-943260 |
| 15:51 | <annevk> | Does anyone have opinions on where XMLHttpRequest's restrictions on Request objects go? |
| 15:52 | <Domenic_> | JakeA: just to confirm, what if: 1) fetch from cache fails, but fresh fetch succeeds; and 2) cache data arrives before fresh data. |
| 15:52 | <annevk> | In particular XMLHttpRequest restricts methods and headers. |
| 15:52 | <annevk> | Domenic_: ignore cache |
| 15:52 | <Domenic_> | JakeA: not "and" as in "what happens if both", I meant more, those are two not-yet-specified cases by your desired process. |
| 15:52 | <annevk> | only if both fail do you do shownoupdate |
| 15:53 | <Domenic_> | and if cache arrives before fresh? |
| 15:53 | <JakeA> | Domenic_: If cache fails, but fresh succeeds, page is updated with fresh data & spinner stops |
| 15:53 | <annevk> | you first update with cache, then with fetch |
| 15:53 | <Domenic_> | ah, that breaks the symmetry, making it annoying. ok. |
| 15:54 | <JakeA> | Domenic_: If cached data arrives first, page is updated with cached data. Network fetch continues and page will be updated again if/when it succeeds |
| 15:54 | <annevk> | it seems somewhat common to have this code in the SW |
| 15:54 | <annevk> | though I don't think it should leak outside the SW as JakeA's code suggests |
| 15:55 | <JakeA> | Actually, I saw this code living in the page. The service worker would handle serving the data & populating the cache on a fresh update |
| 15:56 | <annevk> | If I had an SW I would want that to handle all the cache complexity for me |
| 15:56 | <annevk> | And just deal with URLs myself |
| 15:56 | <JakeA> | The service worker would only be able to handle the initial page serve, not the second request for fresh data & update |
| 15:57 | <JakeA> | eg, the page would want to do stuff like "Don't update with fresh data if old data has been interacted with", eg like writing a tweet reply |
| 15:57 | <annevk> | Ah yeah, fair. Although SW could ping the page but then you would indeed no longer be dealing with just a URL... |
| 15:58 | <annevk> | Sad. |
| 15:58 | <Domenic_> | if cache comes back successfully then fresh comes back successfully one second later, at which point do you hide the spinner? |
| 15:59 | <JakeA> | annevk: I'll get this full "gallery" example into the repo later in the month. It could be that we could make this stuff easier |
| 15:59 | <annevk> | Domenic_: spinner is for network I'd assume |
| 15:59 | <JakeA> | Domenic_: Spinner only hides once the fresh data request ends, whether it fails or succeeds |
| 16:00 | <Domenic_> | ah so i should think of this as a non-modal spinner. |
| 16:00 | <JakeA> | I guess, technically, you'd hide the spinner when both requests have completed (fail or succeed). But linking it to the network request is good enough |
| 16:01 | <JakeA> | If the network request fails, but the cache fetch is still happening (likely if there's zero connectivity), it might be nice to still show a spinner |
| 16:01 | <JakeA> | But my code at the top of the gist doesn't do that |
| 16:01 | <JakeA> | Surprising amount of edge cases to this |
| 16:02 | <annevk> | Isn't that what UI is? |
| 16:03 | <Domenic_> | Using .finally: https://gist.github.com/jakearchibald/785f79b0dea5bfe0c448#comment-943394 |
| 16:06 | <JakeA> | annevk: Hah! |
| 16:08 | <JakeA> | Domenic_: annevk suggested Promise.all([cacheUpdate, freshUpdate]).catch(showNoDataError) too, either you're both wrong or I don't understand the API… |
| 16:08 | <JakeA> | I thought Promise.all(...) would reject if any of the promises rejected |
| 16:09 | <JakeA> | and only resolve if all of the promises resolved |
| 16:09 | <Domenic_> | hmm yes, i think i am wrong, why did i do that |
| 16:09 | <JakeA> | .race only rejects if all the promises reject, yeah? |
| 16:10 | <JakeA> | I'd have placed bets on me being wrong there |
| 16:10 | <Domenic_> | no it rejects if any of the promises reject before any of the promises fulfills |
| 16:10 | <Domenic_> | what we really want is .any |
| 16:10 | <JakeA> | Ohhhhhhh |
| 16:10 | <Domenic_> | the problem with speccing .any is figuring out what the aggregate error should look like if all reject |
| 16:11 | <JakeA> | array of responses, right? |
| 16:12 | <annevk> | JakeA: you need both response and fulfilled/reject state |
| 16:13 | <JakeA> | Yeah. I thought race resolved on first to resolve, and rejected on all-rejected. Hah |
| 16:14 | <JakeA> | My code in the original gist is broken then |
| 16:17 | <JakeA> | Domenic_: So, need something like finally. & it'd be nice to have freshUpdate.isResolved to remove the need for updatedFromFresh. Is that fair? |
| 16:26 | <Domenic_> | JakeA: isResolved isn't really useful, since you could be resolved to a pending promise |
| 16:27 | <annevk> | freshUpdate.hasThenBeenInvoked |
| 16:27 | <JakeA> | I guess I'm looking for isComplete |
| 16:27 | <Domenic_> | .race is pretty useless ... its existence stems from its counterpart being included in DOM promises, and MarkM liking it, and it having very straightforward/easy to spec semantics. If any of those were false it would probably have died along with what we are now calling .any---which is more useful, but harder to spec. |
| 16:28 | <JakeA> | annevk: Hah, yeah |
| 16:28 | <Domenic_> | sounds like you are looking for isFulfilled, but that is not determinable without possible side effects, e.g. collapsing any lazy promises |
| 16:29 | <Domenic_> | well, maybe i am lying, if you can do it in user space, you should be able to do it in spec space. |
| 16:30 | <JakeA> | Does feel like there should be a more promisey way to handle updatedFromFresh |
| 16:30 | <Domenic_> | no, i am not lying, the user-space solution explicitly triggers .then. |
| 16:30 | <Domenic_> | I dunno, seems fine to me. |
| 16:30 | <Domenic_> | Remembering the sync/async parallel, i.e. you would do the exact same thing for sync-ish code. |
| 16:30 | <annevk> | JakeA: would it be much better with callbacks? |
| 16:31 | <JakeA> | Fair enough, I'm probably just trying to cram everything into the model of the new thing. Like when people ask how to do setTimeout in jQuery |
| 16:31 | <annevk> | JakeA: alternatively, how would you ideally have done it? |
| 16:31 | <Domenic_> | haha |
| 16:32 | <JakeA> | annevk: Oh, yeah, I don't have any better solutions. And I'm not being down on promises, just felt like I wasn't doing it as well as it could be done |
| 16:32 | <annevk> | I'm also just wondering :) |
| 16:33 | <JakeA> | But yeah, it sounds like there's a finally() and a Promises.any() missing |
| 16:33 | <Domenic_> | .any is weird because if you reject with an array of reasons you are breaking the rule that rejections should be Errors. |
| 16:34 | <JakeA> | Didn't realise that was a rule, but makes sense |
| 16:35 | <JakeA> | I'm glad we had this chat before I finished my html5rocks article on Promises :D |
| 16:35 | <Domenic_> | e.g. would you write a sync function that does `func(funcs) { var errors = []; funcs.forEach(f => try { f() } catch (e) { errors.push(e); } if (errors.length) { throw errors; } }`? maybe you would, but seems a bit weird. |
| 16:35 | <Domenic_> | haha awesome i love html5rocks |
| 16:36 | <JakeA> | Domenic_: I'll send you the draft when it's done, sounds like it'll benefit from a proof read |
| 17:05 | <Ms2ger> | "What makes @w3c a leader in global innovation?" |
| 17:05 | <Ms2ger> | I'd love to hear |
| 17:06 | <annevk> | Too bad @w3cdrm broke |
| 17:08 | <dglazkov> | good morning, Whatwg! |
| 18:41 | <TabAtkins> | jgraham: Normal people don't need to do full-power property introspection; for most uses, just doing foo.bar or ("bar" in foo) is just fine. So gOPD isn't a valid criticism, as it's something you use only in rare metaprogramming cases. |
| 18:42 | <Ms2ger> | TabAtkins, right, so why not support foo.bar? |
| 18:43 | <TabAtkins> | Because of everything I've already said when discussing this with zewt. You have all Maps appearing to have a "toString" key, and have to either swallow that all Maps appear to have "get"/"set"/"clear"/etc keys as well, or push them off onto the Map object in a fashion that isn't done anywhere else (except Object). |
| 18:45 | <jgraham> | FWIW it is less clear to me why . and [] have to do the same thing |
| 18:46 | <TabAtkins> | Because JS has always done that, changing it now would be impossible, and changing it for a *single object* is just silly. |
| 18:47 | <jgraham> | It's only silly if you don't introduce a general mechanism for doing it |
| 18:47 | <TabAtkins> | And having one object act differently, and in a way that'll break lots of naive scripts, directly counters the "consistency" argument used to try and argue for using [] with Maps. |
| 18:47 | <TabAtkins> | Indeed, and there's a proposal for doing that (which isn't making it into ES6). |
| 18:47 | <jgraham> | The argument I used isn't "consistency" |
| 18:47 | <jgraham> | It's "usability" |
| 18:47 | <TabAtkins> | But it's still something that breaks naive scripts, and so you don't want to turn it on for an object by default. |
| 18:48 | <TabAtkins> | Yes, I had this same argument with zewt last night. |
| 18:48 | <jgraham> | It only breaks those scripts if people start throwing sets at them without updating them. Which is possible of course, but not obviously a deal breaker |
| 18:48 | <jgraham> | The same is true of lots of new features |
| 18:49 | <TabAtkins> | I acknowledge that [] is slightly more usable, and in line with how you access object-maps. But we can't make Maps do that without accepting a lot of bad things, which hurt the usability as well. So it's definitely not a clear-cut right or wrong decision. |
| 18:49 | <jgraham> | (for example the generic not-in-ES6 mechanism for doing this that you just alluded to) |
| 18:50 | <TabAtkins> | (The generic mechanism is just assigning a function to some Symbol-valued get/set properties on the object, which are then used for gets/sets using [] instead of the default behavior.) |
| 18:51 | <jgraham> | Right, more or less what you would expect. No reason that couldn't work for set. And if it does go in, it will be confusing in the future when user objects overload [] but built-in sets don't |
| 18:52 | <TabAtkins> | Of course there's no reason why it wouldn't work. I'm saying you don't want it to work that way *by default*, because doing so is inconsistent with the rest of the language and will break lots of things doing simple metaprogramming. |
| 18:52 | <TabAtkins> | I'm sorry there's no perfect answer. Perhaps JS messed up from the beginning by having .foo and ['foo'] do the same thing. But we can't get away from that. |
| 18:53 | <jgraham> | I don't think I can blame you *personally* for that |
| 18:53 | <gsnedders> | BLAME HIM! |
| 18:53 | <gsnedders> | BURN HIM! |
| 18:54 | <jgraham> | Unless you go on to invent a time machine and threaten Brendan with death unless he consents to your will |
| 18:54 | <TabAtkins> | If I had a time machine, there's several people I would be threatening with death unless they consented to my will. |
| 18:54 | <jgraham> | Hmm, my estimate of the probability of that being the case just went up |
| 18:54 | <jgraham> | *cause |
| 19:10 | <Domenic_> | TabAtkins: I'm confused, is a promise for itself required (since monads don't care what's inside them) or disallowed? |
| 19:11 | <TabAtkins> | Domenic_: Irrelevant question. The monad contract doesn't care what inside the context. Resolve it however you want. |
| 19:11 | <TabAtkins> | You need to *allow* a monad to be put inside of itself, but it's fine to make that cause rejection. You just shouldn't, for example, throw. |
| 19:12 | <Domenic_> | hmm |
| 19:12 | <TabAtkins> | Just note Mark's comments about remote promises not being able to eagerly reject. |
| 19:12 | <Domenic_> | right yeah |
| 19:12 | <Domenic_> | that'll be tricky |
| 20:01 | <jpwhiting> | MikeSmith: ping |
| 22:05 | <Hixie> | anyone got an idea of what the event we fire on <details> should be called? fired when it opens or closes |
| 22:05 | <Hixie> | best current suggestion is "ontoggle" |
| 22:06 | <Hixie> | where's a good bikeshed when you need one |
| 22:10 | <jgraham> | That seems like a perfectly good name |
| 22:10 | GPHemsley | concurs |
| 22:14 | <hober> | yeah, +1 |
| 22:17 | <jgraham> | Hixie: Quick, ship an implementation before anyone disagrees |
| 22:17 | <miketaylr> | i dunno onopenorclosestatechange seems pretty good too |
| 22:17 | miketaylr | hides |
| 22:19 | <Hixie> | ontoggle it is |
| 22:19 | nimbu | kills miketaylr |
| 23:33 | <Hixie> | anyone have a link to that htmlwg post where the chairs said we didn't have to test everything because some things had "proven interoperability"? |
| 23:34 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2012Sep/0243.html looks to be it |
| 23:41 | <jgraham> | Hixie: FWIW I don't think anyone intends to not test everything |
| 23:41 | <jgraham> | It just means that they won't require testing everything for Process reasons |
| 23:42 | <jgraham> | But that's fine, testing for Process doesn't really work anyway |
| 23:43 | <jgraham> | Actually I take that back |
| 23:43 | <jgraham> | testing for Process really doesn't work |
| 23:44 | <jgraham> | It just leads to confusion like people asking if it's OK to submit tests for the interaction between different features |
| 23:45 | <jgraham> | Or people submitting tests carefully chosen to demonstrate interop, rather than to find bugs |
| 23:46 | <jgraham> | The only real good thing about having testing be part of the Process is that it encourages some people who care about Process to write tests |
| 23:46 | <jgraham> | However it doesn't guarantee the quality of those tests, for the reasons already stated |
| 23:47 | <Hixie> | yeah, it was in the context of process reasons that i was asking |
| 23:49 | <jgraham> | Oh, OK, if you are discussing Process then this clearly violates the intent of the Process. But also the Process shoudl change. |
| 23:49 | <Hixie> | or, you know, not exist |
| 23:49 | <Hixie> | i was discussing values of the whatwg and w3c with someone. these are what i came up with, but i'm worried they're biased -- anyone got a less subjective list?: |
| 23:50 | <Hixie> | WHATWG values: |
| 23:50 | <Hixie> | - technical correctness above all |
| 23:50 | <Hixie> | - openness and freedom |
| 23:50 | <Hixie> | - responding to all feedback |
| 23:50 | <Hixie> | - meritocracy |
| 23:50 | <Hixie> | W3C values: |
| 23:50 | <Hixie> | - consensus above all |
| 23:50 | <Hixie> | - making the AC happy |
| 23:50 | <Hixie> | - following processes |
| 23:50 | <Hixie> | - publishing "stable references" |
| 23:51 | <Hixie> | (i mean, actual values as demonstrated by actions, not claimed values. also, let me know if you see any contradictions of the whatwg values.) |
| 23:55 | <astearns> | Hixie: I think you missed one. WHATWG values: - making fun of W3C process |
| 23:55 | <Hixie> | i actually later in the discussion listed some values that neither group has, and one i had in that list was "politeness" |
| 23:56 | <Hixie> | which i think is much the same as what you said :-) |
| 23:56 | <jgraham> | I don't know if it's technically a value, but WHATWG tends to value browser vendors above other entities (discounting "authors" and "end users") whereas the W3C has a different set of constituents including media companies, large corps and whoever else will pay the membership fees |
| 23:56 | <Hixie> | i think that falls into "making the AC happy", but yeah, interesting way of looking at it |
| 23:58 | <jgraham> | Sure, if you know who the AC are and the fact that the W3C actively tries to recruit new Members irrespective of whether they have interests aligned with the Open Web |
| 23:58 | <astearns> | I think WHATWG valuing meritocracy might be a subjective call. I've seen opinions I value getting short shrift in discussions here |
| 23:59 | <Hixie> | i meant that more along the lines of you get responsibility if you do the work |
| 23:59 | <Hixie> | as in, the person who works on the wiki gets to decide when the wiki software is updated |
| 23:59 | <Hixie> | or the person who writes the spec, gets to decide what the spec says |