| 04:50 | <MikeSmith> | heh https://groups.google.com/a/chromium.org/d/msg/chromium-dev/0wWoRRhTA_E/-NxrcXoqBwAJ |
| 04:54 | <MikeSmith> | some should reply with a message asking him to estimate what the costs are of making a business decision to tie your entire business model to a single-vendor proprietary runtime instead of betting on the Web instead |
| 05:16 | <Uu> | Hi when will the next htm5 specifications public? |
| 05:17 | <tantek> | Uu, today: http://html.spec.whatwg.org/ |
| 11:03 | <FND> | hi - using `fetch`, if a CORS request fails with `fetch`, that failure has to be handled via `catch` |
| 11:03 | <FND> | however, in there you don't have access to the server response - which means that you can't be certain what went wrong, exactly |
| 11:04 | <annevk> | FND: that is somewhat intentional, the developer console should give you more information though |
| 11:04 | <FND> | yeah, I know, but: |
| 11:04 | <FND> | my current scenario is accessing SharePoint with an expired access token - SharePoint does provide a `x-ms-diagnostics` header along with a 401 status code |
| 11:05 | <FND> | but I have no way to determine that programmatically, so I can't just say "oh, right, I'll just refresh my token before retrying" |
| 11:06 | <annevk> | Ideally SharePoint would have CORS on the 401 |
| 11:06 | <annevk> | Then it would be exposed to you |
| 11:06 | <annevk> | So I think if SharePoint provides a CORS access point, this is a bug in their system |
| 11:06 | <FND> | good point, actually |
| 11:06 | <FND> | (I'm not surprised, their REST API is pretty terrible) |
| 18:32 | <annevk> | https://twitter.com/simevidas/status/759080906455969792 is pretty cool |
| 18:33 | <annevk> | The word diff tweet this is response to, that is |
| 19:00 | <TabAtkins> | annevk: The term "an unclosed node of a node" is extremely confusing to work with. :/ |
| 19:02 | <TabAtkins> | I think it's because in the construction "ADJ node of a node", we expect ADJ to be a relationship between the two nodes (like "ancestor"), but "unclosed" reads as a personal property of the first node, not a relationship. |
| 19:09 | <TabAtkins> | annevk: Maybe "unclosed relative of a node"? It took me some thinking to decipher that it was capturing the notion "not trapped in a closed shadow root in a way that makes it invisible to B". |
| 19:31 | <TabAtkins> | annevk: Or a longer phrase "A is potentially reachable from B" |
| 20:05 | <jsbell> | smaug_____: It looks like your directory upload FileEntry/DirectoryEntry impl is including some of the useless bits: Entry.filesystem, DirectoryReader.removeRecursively(), FileEntry.createWriter(), FileSystemFlags dict and the DOMFileSystem interface. Have you determined that these are necessary for compat? Edge wasn't planning to implement those. I was hoping we could remove them. |
| 20:22 | <jsbell> | smaug____: https://github.com/WICG/entries-api/issues/4 for discussion. Looks like Edge will have Entry.filesystem |
| 20:57 | <annevk> | TabAtkins: file an issue? Seems fixable |
| 20:57 | <TabAtkins> | kk, will do |
| 20:57 | <annevk> | Ta |
| 21:02 | <smaug____> | jsbell: also Gecko |
| 21:04 | <smaug____> | jsbell: FWIW, we got a list from MS what they were going to implement. (but they then implemented some different set of properties and methods after all) |
| 21:04 | <smaug____> | jsbell: also, I'm planning to enable the API in Nightly today or tomorrow |
| 21:19 | <jsbell> | smaug____: thanks - as you saw in the bug, I've added the common subset between Blink/Edge/Gecko. Do let me know if anything else seems necessary and I'll happily add/fix. |
| 21:32 | <smaug____> | jsbell: FWIW, you can use my real name, Olli Pettay |
| 21:33 | <jsbell> | smaug____: Will do. |