| 05:23 | <FND> | gsnedders: I did indeed check the logs - and yeah, I intend to file a separate bug for affected browsers, but referencing this test case should make it easier (I hope?) |
| 05:56 | <annevk> | FND: tests help a lot |
| 05:57 | <FND> | is Ms2ger the right person to help me verify and, if necessary, clean up my test case? |
| 06:03 | <annevk> | FND: yeah, one of a couple |
| 06:05 | <FND> | roger, I'll try to catch him later today then |
| 07:56 | <MikeSmith> | what spec resticts window.parent.postMessage from working cross domain? |
| 07:56 | <MikeSmith> | context is http://stackoverflow.com/questions/39157921/javascript-cross-domain-postmessage-not-working/39158132#39158132 |
| 07:56 | <annevk> | MikeSmith: hmm |
| 07:58 | <annevk> | MikeSmith: none I think |
| 07:59 | <MikeSmith> | oh |
| 08:00 | <MikeSmith> | so maybe his statement is just wrong |
| 08:00 | <annevk> | Code pasted there looks very confusing |
| 09:03 | <nox> | zcorpan: That CSS partial interface is wrong anyway, no? |
| 09:04 | <nox> | zcorpan: It defines elementSources has an instance attribute, and then the snippet does CSS.elementSources.set('fancy', bg);. |
| 09:05 | <zcorpan> | nox: yes, you're right |
| 09:06 | <nox> | zcorpan: Commented. |
| 09:06 | <zcorpan> | needs a "static" |
| 10:00 | <tobie> | Struggling with the following chunk of WebIDL which the spec says is OK, but Bikeshed parser seems to choke on: |
| 10:01 | <tobie> | https://www.irccloud.com/pastebin/0qhDcQ7K/ |
| 10:02 | <tobie> | annevk: ^ does this seem to valid WebIDL to you? |
| 10:04 | <annevk> | tobie: yeah, for custom toJSON() |
| 10:04 | <annevk> | tobie: haven't seen that used thus far though |
| 10:05 | <tobie> | OK, so it seems its a Bikeshed parser shortcoming, then. |
| 10:05 | <nox> | tobie: Wrong return type maybe? |
| 10:06 | <tobie> | nox: no the parser lenient with that. |
| 10:06 | <tobie> | *is |
| 10:06 | tobie | double-checks |
| 10:07 | <nox> | Ok. :) |
| 10:07 | <tobie> | same issue with void ... |
| 10:08 | <annevk> | tobie: oh |
| 10:08 | <annevk> | tobie: maybe serializer cannot have a return type |
| 10:08 | <annevk> | tobie: that would kinda make sense for toJSON(), since it's always any |
| 10:09 | <annevk> | tobie: and might even follow from the IDL grammar, though I'm not great at reading it |
| 10:10 | <tobie> | annevk you're absolutely right |
| 10:10 | <tobie> | annevk: you're not great at reading it, but better than I. :( |
| 10:10 | <tobie> | annevk: ty! |
| 10:11 | <tobie> | annevk: that said, I'm a littler concerned that the ability to write WebIDL in the WebIDL spec depends on Bikeshed parser being compatible with it. |
| 10:11 | <tobie> | annevk: seems like this is going to be an issue as soon as new grammar constructs are defined. |
| 10:13 | <annevk> | tobie: I guess a little bit and it'll make large grammar changes harder as all the specs depending on bikeshed will need to be updated |
| 10:13 | <tobie> | annevk: we need to either coordinate Bikeshed IDL parser with WebIDL changes, or make the parser more leninant with grammar issues (i.e. not throw fatal errors) |
| 10:13 | <annevk> | tobie: but it's also kinda nice |
| 10:14 | <annevk> | tobie: coordinating should be fine I think, there's not too many changes (we should at some point make a bunch to make it more JS-y, but that needs a whole lot of coordination anyway) |
| 10:14 | <tobie> | I might be overthinking this. :) |
| 10:15 | <tobie> | Granted I spend the better part of Wednesday and Thursday fixing syntax errors in code examples (i.e. adding cruft around WebIDL snippets to make the parser happy) |
| 10:16 | <annevk> | That seems like a positive side effect actually |
| 10:16 | <tobie> | sort of up |
| 10:16 | <annevk> | Gonna get some food over here, ttyl |
| 10:18 | <tobie> | it's turning things like: "return-type identifier(arguments…);" in http://heycam.github.io/webidl/#idl-operations |
| 10:18 | <tobie> | into: |
| 10:19 | <tobie> | https://www.irccloud.com/pastebin/96248oWO/ |
| 10:19 | <jgraham> | https://bocoup.com/weblog/test262-is-a-javascript-sideshow is good fun |
| 10:19 | <tobie> | annevk I'm not sure it's a net win. |
| 10:19 | <jgraham> | Wonder if they want to do the same for some other parts of the platform :) |
| 10:19 | <tobie> | annevk: bon appétit! |
| 10:19 | <tobie> | jgraham: they'd love to. Just want to get paid for the work, though. |
| 10:20 | <tobie> | jgraham: :) |
| 10:20 | <tobie> | jgraham: I can do intros for a 15% commission. :D |
| 10:21 | <jgraham> | tobie: Yeah, not convinced I could find anyone to pay you agent fees :p |
| 10:22 | <jgraham> | But it doesn't seem impossible to find money to pay people to write tests for specific features if we know what we actually want |
| 10:24 | <tobie> | jgraham: commission jokes aside, I'll happily discuss this offline with you. |
| 11:15 | <annevk> | tobie: https://github.com/heycam/webidl/issues/147#issuecomment-242698431 Shepherd is mostly the external usage I guess, but other specs do use those values to link IDL terms |
| 11:16 | <annevk> | tobie: and DOM relies on a number of terms being exported, etc. |
| 11:36 | <terinjokes> | for the Preload link headers, can I URL encode the URL? |
| 11:36 | <terinjokes> | i assume that should work… |
| 11:37 | <tobie> | annevk: ok, I'll double check those. I assumed the only external guaranties were IDs. |
| 11:38 | <nox> | Did we specify yet that indexed getters must be accompanied with a 'length' attribute? |
| 11:38 | <annevk> | tobie: cool |
| 11:39 | <annevk> | nox: hmm, if that's always the case we should just codegen it |
| 11:39 | <nox> | annevk: What do you mean? |
| 11:39 | <nox> | annevk: https://github.com/heycam/webidl/issues/80 |
| 11:40 | <annevk> | nox: no reason to declare a length attribute on each interface with an indexed getter |
| 11:40 | <nox> | annevk: I like that it makes it explicit. |
| 11:40 | <annevk> | nox: interface should just implement the indexed getter protocol and that's that |
| 11:40 | <annevk> | nox: a lot around indexed getters is rather implicit |
| 11:41 | <nox> | True. |
| 11:41 | <nox> | Wtf do the emoji labels mean btw? |
| 11:41 | <annevk> | easy now |
| 11:42 | <annevk> | I think tobie added those |
| 11:42 | <nox> | "easy now"? |
| 12:00 | <tobie> | nox: yeah, Marcos already complained. :) |
| 12:00 | <nox> | Oh, "easy now" because I said "wtf"? |
| 12:00 | <nox> | Yeah not angry, just was making clear I had absolutely no idea what they mean. :) |
| 12:01 | <tobie> | I need to either update the README or change those. |
| 12:01 | <tobie> | One's difficulty, the other one time. |
| 12:02 | <zcorpan> | 1. have two cups of coffee. 2. wait. 3. ??? 4. profit!!! |
| 13:32 | <SimonSapin> | "Don’t fear the yellow screen of death", they say https://twitter.com/SimonSapin/status/769165462949289984 |
| 13:42 | <annevk> | SimonSapin: http://codecino.com/2008/10/25/dont-fear-the-yellow-screen-of-death/ loads normally here |
| 13:43 | <SimonSapin> | in firefox? |
| 13:44 | <SimonSapin> | ah, it does for me too now |
| 13:44 | <SimonSapin> | still funny to me |
| 13:46 | <annevk> | SimonSapin: was it failing earlier today or some such? |
| 13:46 | <annevk> | SimonSapin: site doesn't look maintained |
| 13:46 | <SimonSapin> | yeah, this tweet has a screenshot I made a few minutes ago |
| 13:46 | <annevk> | weird then |
| 14:02 | <Guest25975> | https://github.com/rust-lang/rfcs/blob/master/text/1216-bang-type.md |
| 14:02 | <zcorpan> | SimonSapin: i got a parse error on first load. works on second load |
| 14:03 | <zcorpan> | seems on second load it's text/html ? |
| 14:16 | <FND> | Ms2ger: do you have a few minutes to discuss the WBT fetch test case? |
| 14:16 | <FND> | I wanna make sure I get it right before submitting a PR |
| 14:17 | <Ms2ger> | FND, don't have much time today; if you submit I can probably comment later |
| 14:17 | <FND> | Ms2ger: ok, no worries - will submit as WIP PR, mentioning you (@Ms2ger, I'm assuming?) |
| 14:19 | <Ms2ger> | Yep |
| 14:19 | <Ms2ger> | Thanks |
| 14:23 | <annevk> | There's no way for Travis to not email me? |
| 14:43 | <MikeSmith> | annevk: maybe only by configuring it in the .travis.yml https://docs.travis-ci.com/user/notifications/#Email-notifications |
| 15:52 | <rbyers> | smaug____: Hey, we're trying to match the spec (and almost Gecko) for firing 'click' only for the primary button |
| 15:53 | <rbyers> | But there are a few legitimate use cases for needing an event for middle-button click (overriding the browser built-in behavior) that we really can't just eliminate. So we're proposing a new niche 'auxclick' event to replace those. https://navidz.github.io/auxclick/ |
| 15:55 | <rbyers> | Seem like a reasonable idea to you? I'm sure there are details still to work out in the spec etc. |
| 15:59 | <smaug____> | rbyers: sorry, I haven't read the email thread in blink-dev yet. Kind of on vacation yesterday-today |
| 16:00 | <rbyers> | smaug____: No worries, it can wait until next week. |
| 16:01 | <smaug____> | rbyers: what are the use cases when web page needs middle-click? |
| 16:02 | <rbyers> | smaug____: We've ignored that the spec disagrees with blink, WebKit and Edge for a long time - trying to fix this, but if there's too much controversy than the pragmatic thing is probably to just undo this spec change that was made years ago and give up - saying click is for all buttons. Bad for the user experience IMHO since developers don't normally think |
| 16:02 | <rbyers> | to check buttons (or modifiers) |
| 16:03 | <smaug____> | rbyers: but what are the use cases when web page needs to access middle click? |
| 16:04 | <smaug____> | and for right click contextmenu event might be usually enough |
| 16:04 | <smaug____> | (I haven't thought too much auxclick yet, but share some same worries that Domenic had in the email thread) |
| 16:06 | smaug____ | was going to test Chrome and notices one of the biggest sites in Finland has broken layout in Chrome. perhaps some unusual setting in dev build |
| 16:06 | <smaug____> | rbyers: what does Chrome do with right clicks? |
| 16:08 | <smaug____> | I'm not getting click events for right click, nor middle click |
| 16:08 | <smaug____> | testing <a> |
| 16:32 | <smaug____> | hmm, is there any data about middle click usage |
| 16:35 | <smaug____> | rbyers: after thinking this couple of minutes, I guess auxclick should be fine. Hostile sites can already just not use anything which has default action for click or middle or such, and just manually trigger actions using click listener |
| 16:36 | <smaug____> | ( rbyers: and FYI, it is http://www.yle.fi/ which is broken in Chrome 54dev) |
| 17:25 | <hsivonen> | MikeSmith: thanks. IPv6 being the difference seems plausible. |
| 17:35 | <rbyers> | smaug____: Cool, thanks. Yeah I don't see any practical way of dealing with "hostile" sites here, but we can greatly improve the accidental case - which I think is quite prevalent. |
| 17:35 | <rbyers> | If you wouldn't mind, can you send a quick note on the blink-dev thread saying that the basic idea seems OK to you? |
| 17:37 | <rbyers> | Maybe someday in the future we could even go further and say it's "auxclick" (not "click") that fires when modifier keys are down (since developers often make the same mistake there - treating click the same regardless of any modifier) |
| 17:52 | gsnedders | sitll wants to know what the use-cases are |
| 18:21 | <rbyers> | gsnedders: for auxclick? They're pretty niche but do exist - eg. tabbed UIs often implement a "middle click on the tab to close it" UX |
| 18:23 | <rbyers> | Or we see some apps that can't (or choose not to) represent their actions with real links - eg. GMail "reply" button. In those cases they might still want to do something special on middle click (eg. reply in a new window) so they need some sort of event for middle click. |
| 19:58 | <ShakespeareFan00> | Nice while it lasted - https://discourse.wicg.io/ |
| 19:58 | <ShakespeareFan00> | Firfox won't connect :( Was going to talk about various porposals there |