| 07:26 | <alwu> | zcorpan : hi! |
| 07:27 | <zcorpan> | alwu: hi |
| 07:27 | <botie> | privet, zcorpan |
| 07:27 | <zcorpan> | botie, go away |
| 07:27 | <botie> | zcorpan: sorry... |
| 07:28 | <alwu> | zcorpan, morning! could you help me to check this issue :) ? https://github.com/w3c/webvtt/issues/310 |
| 07:29 | <zcorpan> | alwu: argh, i had written a detailed reply to that, apparently it didn't come through :'( |
| 07:29 | <zcorpan> | thx for heads-up |
| 07:32 | <alwu> | thanks you too! I think I need to figure how to parsing cue identifier more clearly before committing a PR :) |
| 07:38 | <zcorpan> | commented |
| 07:44 | <alwu> | since the position is pointing to the timestamp, the cue can be parsed correctly, but the cue identifier can't be parsed correctly. |
| 07:44 | <alwu> | that means all identifiers wouldn't be parsed correctly in that file because they contains "-->" ? |
| 07:45 | <alwu> | zcorpan ^ |
| 07:45 | <zcorpan> | alwu: right, they would all have empty string as identifiers |
| 07:46 | <alwu> | zcorpan : cool! thanks for explanation! and I have another question |
| 07:46 | <zcorpan> | that's intentional :-) |
| 07:46 | <zcorpan> | ok |
| 07:48 | <alwu> | in "Cue creation", the buffer is still empty. |
| 07:48 | <zcorpan> | for this file, yes |
| 07:48 | <alwu> | that means even we set the cue identifier to buffer, the identifier is still wrong value |
| 07:49 | <alwu> | oh |
| 07:49 | <zcorpan> | not if there are blank lines between cues |
| 07:51 | <alwu> | so, for the valid identifier, there would have run the "Loop" twice. In first time, it sets the 'line' to 'buffer'. In second time, we create the cue, and then set the 'buffer' to identifer. |
| 07:51 | <alwu> | is that right? |
| 07:54 | <zcorpan> | ...set the identifier to 'buffer' :-) |
| 07:55 | <zcorpan> | but yes |
| 07:57 | <alwu> | ok thanks :) |
| 09:26 | <annevk> | zcorpan: <caption> stuff LGTM |
| 09:26 | <annevk> | zcorpan: dunno if you want someone else to sign off too |
| 09:27 | <zcorpan> | annevk: thx. probably ok to merge it |
| 09:28 | <annevk> | zcorpan: actually... |
| 09:28 | <annevk> | zcorpan: should the caption thing be put together with the other stuff that is text-align: center? |
| 09:29 | <annevk> | zcorpan: thead[align=absmiddle i] et al |
| 09:29 | <zcorpan> | annevk: since there's no attribute to control it i think it shouldn't be a preshint |
| 09:29 | <zcorpan> | not that people care much about the distinction |
| 09:30 | <annevk> | I see |
| 09:30 | <annevk> | We should start testing the difference at some point maybe |
| 09:30 | <annevk> | Or just remove the concept |
| 09:30 | <annevk> | zcorpan: anyway, LGTM |
| 09:34 | <zcorpan> | i started writing tests for the rendering section a while back (ignoring UA style vs preshint), but it got too clumsy. need to go back and think of a better way to test |
| 11:52 | <annevk> | Whoa, issue 52 is almost fixed |
| 11:53 | <annevk> | Good times |
| 12:26 | <zcorpan> | heh yeah that one has taken a while :-) then i need to structure up that section with subsections etc |
| 12:26 | <zcorpan> | live dom viewer doesn't work in Servo :-| |
| 12:28 | <Ms2ger> | It uses doc.write, does it not? |
| 12:30 | <zcorpan> | yep |
| 12:32 | <Ms2ger> | Patches welcome ;) |
| 12:34 | <zcorpan> | can't be much harder than about:blank? |
| 12:34 | <nox> | document.write is hard. |
| 12:37 | <zcorpan> | nox: i know, i was trolling. :-) about:blank is also hard |
| 12:58 | <howdoi> | var p1 = Promise.resolve(); p1; //must be in fulfilled state, right? |
| 13:02 | <annevk> | howdoi: yeah, though you can't observe it until some microtask |
| 13:03 | <howdoi> | var p1 = Promise.resolve(); |
| 13:03 | <howdoi> | var p2 = Promise.reject(); |
| 13:03 | <howdoi> | var p3 = new Promise(() => {}); |
| 13:03 | <howdoi> | annevk: P1; says Promise { undefined } |
| 13:04 | <howdoi> | why not Promise { <fulfilled> }? |
| 13:10 | <gsnedders> | zcorpan: what's so hard about the rendering section? |
| 13:10 | <annevk> | dunno, prolly depends on internals |
| 13:11 | <zcorpan> | gsnedders: the approach i tried was to include all relevant elements and then check everything in getComputedStyle for each element, but it quickly became messy and didn't work |
| 13:56 | <annevk> | Ms2ger: https://github.com/whatwg/html/issues/928 ping |
| 13:57 | <Ms2ger> | annevk, ? |
| 13:57 | <annevk> | Ms2ger: it's not clear to me there's an issue |
| 13:58 | <Ms2ger> | If you navigate a page, does the former document not still have a browsing context? |
| 14:03 | <annevk> | hmm |
| 14:04 | <annevk> | ta |
| 14:08 | <Ms2ger> | Np :) |
| 15:13 | <howdoi> | programmatically identifying the state of a promise is a pain! |
| 15:13 | <howdoi> | why not we have Promise.inspect? |
| 15:13 | <nox> | What would that do? |
| 15:14 | <howdoi> | Tell us the state of the promise |
| 15:14 | <botie> | will do |
| 15:14 | <howdoi> | may it be sync API, or may it return a promise |
| 15:14 | <howdoi> | pending, rejected, resolved, canceled ... |
| 15:15 | <howdoi> | makes sense? |
| 15:15 | <nox> | Why would I need to know in which state a promise, though? |
| 15:15 | <nox> | a promise is* |
| 15:16 | <annevk> | That's been proposed long ago, but I don't think anyone is trying to get it through TC39 |
| 15:16 | <annevk> | You could give it a go |
| 15:20 | <Domenic> | It doesn't appear to have any use cases we can find |
| 15:21 | <nox> | howdoi: Why do you need this? |
| 16:28 | <TabAtkins> | howdoi: "Promise { undefined }" (I presume this is DevTools telling you about the promise?) is because it's fulfilled with the value `undefined`. |
| 19:26 | <rniwa> | annevk: yt? |
| 19:26 | <rniwa> | Domenic: yt? |
| 19:26 | <Domenic> | rniwa: yep |
| 19:26 | <rniwa> | Domenic: do you recall where assignedSlot is supposed to be defined? |
| 19:27 | <rniwa> | Domenic, annevk: I thought we had agreed to add it on Element & CharacterData? |
| 19:27 | <rniwa> | the spec says it's defined on Text & Element: https://dom.spec.whatwg.org/#mixin-slotable |
| 19:27 | <Domenic> | Hmm yeah I haven't been much involved in those discussions |
| 19:28 | <rniwa> | oh maybe it got updated as a result of https://github.com/w3c/webcomponents/issues/351 |
| 19:28 | <Domenic> | https://github.com/w3c/webcomponents/issues/411 |
| 19:29 | <rniwa> | Domenic: oh thanks |
| 19:31 | <annevk> | CharacterData would make more sense... but WebKit didn't like it |
| 19:31 | <rniwa> | annevk: well, in terms of assigning yes, |
| 19:31 | <rniwa> | annevk: but there's no harm in having a property there |
| 19:32 | <annevk> | Hmm, if it's always going to return null I'd rather add it when it might no longer return null |
| 19:33 | <rniwa> | annevk: yeah, that argument makes sense to me |
| 19:33 | <rniwa> | annevk: I just didn't realize that this change was made in conjunction with the types of nodes that could be assigned |
| 19:33 | <rniwa> | annevk: to be fair, we could support assigning CharacterData in general if we tried. It was just not trivial for us to support |
| 19:34 | <rniwa> | since they aren't rendered anyway |
| 20:47 | <Domenic> | TabAtkins: [CEReactions] doesn't seem to be auto-linking in DOM IDL blocks even when using bikeshed web service (i.e. latest updates) :( |
| 22:36 | <jrenner_> | Hey all, I had a quick question about CORS & CORS headers. I understand the need for Access-Control-Allow-Origin as it relates to sending/receiving cookies. But I don't understand why there isn't a client configurable option to just say "I don't want to access the cookie state the browser is maintaining for this site" and skip all the header validation. At that point it's the same as an HTTP request from any random client right? |
| 22:36 | <Domenic> | jrenner_: sadly no, because e.g. my computer can access Google's intranet |
| 22:37 | <Domenic> | jrenner_: I don't want any website I visit to be able to make requests to trigger actions (or even just discover the existence of certain pages on) Google's intranet |
| 22:37 | <Domenic> | Similarly your computer likely has access to an "intranet" which includes a router configuration page |
| 22:37 | <Domenic> | (If it's anything like my home computer) |
| 22:38 | <jrenner_> | ah right :/ yeah that makes sense. Has there been any looking into a permissions-based system like camera usage for making requests to other domains? |
| 22:38 | <Domenic> | The problem is coming up with a permission prompt that makes any sense to users |
| 22:39 | <jrenner_> | ah yeah, sounds nice to me but my mom would have no idea what to do |
| 22:39 | <Domenic> | I guess it doesn't sound impossible now that I think harder |
| 22:39 | <jrenner_> | Like it could just be "My newsreader app would like to be able to communicate with facebook.com" |
| 22:40 | <Domenic> | Yeah |
| 22:40 | <Domenic> | And I guess you just hope users don't get used to auto-granting those? And click "yes" even when it says "192.168.0.1"? |
| 22:40 | <Domenic> | Maybe annevk remembers these discussions more. (It's getting on to his bedtime though.) |
| 22:41 | <jrenner_> | hmmm I'm inclined to write it off and say people are already running random code on their phones and laptops, but that's not really a good excuse |
| 22:43 | <Domenic> | Right, they have implicitly granted trust to that code by installing them, and also app stores can revoke apps that misbehave |
| 22:43 | <Domenic> | https://annevankesteren.nl/2016/07/web-computing was just posted today and touches on that contrast |
| 22:48 | <jrenner_> | hmmm if only there was a semantically understandable way to "upgrade" a web app into being something more local. |
| 22:49 | <Domenic> | I mean we're seeing some experimentation there |
| 22:49 | <Domenic> | But that still doesn't help much with the review and revocation issues |
| 22:49 | <Domenic> | And there's XSRF and XSS |
| 22:54 | <jrenner_> | I mean, presumably XSRF and XSS wouldn't be affected by an extra set of trust semantics. I think... supposing you limit the permissions to scripts from the host that requested them |
| 22:56 | <Domenic> | sure but the point of XSRF and XSS is to get the host to execute code on your behalf :) |
| 22:59 | <jrenner_> | well XSRF can be covered by simply not re-using the cookie when these requests are made, and XSS is... I guess still a problem if someone managed to embed some JS as the host in a trusted environment... |
| 23:01 | <Domenic> | I don't think these problems are unsolvable |
| 23:01 | <Domenic> | I think you'd want some kind of mega isolation mode (with lots of CSP headers and stuff) |
| 23:01 | <Domenic> | and you'd want to build remote revocation infrastructure in, kind of like the safe browsing list |
| 23:02 | <Domenic> | with those in place, a permissions prompt asking for permission to access the third-party origin might work |
| 23:03 | <Domenic> | mega-isolation mode is where most the handwaving is |
| 23:04 | <jrenner_> | hehe yeah... and there's a lot of question of how much we would could/need to protect the user from the trusted host being vulnerable |