| 07:20 | <annevk> | jyasskin: I guess it might be |
| 07:20 | <annevk> | jyasskin: should probably open an issue against IDL |
| 09:56 | <annevk> | zcorpan: "rebase and merge" is useful if you have multiple commits that don't need to be squashed, just fast-forwarded? |
| 09:56 | <zcorpan> | annevk: yep |
| 09:58 | <zcorpan> | next on my wishlist is ability to move an issue to another repo :-) |
| 10:25 | <MikeSmith> | mkwst: FYI the plan for the Workers spec appears to be to assign a new editor to it |
| 10:26 | <MikeSmith> | rather than, say, just making it a Note or folding referencing the Workers section of HTML |
| 10:26 | <MikeSmith> | I think there was an announcement at the TPAC f2f about it |
| 10:35 | <annevk> | 😟 |
| 10:59 | <mkwst> | MikeSmith: The plan is dumb. |
| 11:02 | <Ms2ger> | mkwst, you realize which WG you're talking about? |
| 11:41 | <ondras> | so, when using the html5 dragdrop api, is there any way to influence the visual representation that is being dragged? |
| 11:42 | <ondras> | (preferrably via css) |
| 11:46 | <zcorpan> | ondras: https://drafts.csswg.org/selectors-4/#drag-pseudos ? |
| 11:46 | <zcorpan> | i suppose that's for the drop target |
| 11:47 | <annevk> | zcorpan: should we update HTML to account for that pseudo-class? |
| 11:47 | <annevk> | zcorpan: I think HTML might also have some source comments about drag-and-drop pseudo-classes |
| 11:49 | <annevk> | <hyatt> :droptarget |
| 11:49 | <annevk> | <hyatt> or something |
| 11:49 | <annevk> | <hyatt> we don't support a pseudo-class for the drop target but that's a great idea |
| 11:49 | <annevk> | <Hixie_> yeah, thinking about that too |
| 11:49 | <annevk> | <Hixie_> :drop-target, :drop-target(above), :drop-target(below) and having ondragover be able to say "not on me, but next to me maybe" |
| 11:49 | <zcorpan> | annevk: i don't think anything in particular is needed in HTML, other than dropping the comment |
| 11:49 | <annevk> | seems Selectors went into a slightly different direction |
| 11:49 | <annevk> | zcorpan: HTML needs to say when it applies |
| 11:50 | <annevk> | zcorpan: and at some point we need to expose an API so custom elements can also let it apply and such |
| 11:50 | <zcorpan> | ah yes |
| 11:50 | <annevk> | zcorpan: same for :disabled etc. |
| 11:50 | <zcorpan> | ok |
| 11:51 | <zcorpan> | i can file an issue |
| 11:51 | <annevk> | ta |
| 11:52 | <ondras> | zcorpan: I would like to style the semi-transparent clone of the element being dragged |
| 11:55 | <zcorpan> | ondras: i'm not aware of a way to do that |
| 11:58 | <ondras> | zcorpan: ok :/ |
| 12:16 | <smaug> | ondras: so you don't want setDragImage but something else? |
| 12:16 | <ondras> | smaug: well I want to drag the html element in question |
| 12:17 | <ondras> | smaug: but for <a> elements, the browser (ff?) adds its href |
| 12:17 | <ondras> | to the dragged visual |
| 12:17 | <ondras> | or I want to change its background color to outline the box being dragged |
| 12:17 | <ondras> | etc |
| 12:17 | <ondras> | the kind of stuff you do with css, generally speaking |
| 12:18 | <smaug> | hmm, I wonder if you could have some hidden element and use that as drag image |
| 12:18 | <smaug> | style that element whatever way you want |
| 12:18 | <ondras> | *chrome adds @href value to the element, not ff |
| 12:19 | <ondras> | smaug: yeah, that would be cool. status quo makes me re-implement the whole d'n'd machinery in custom js |
| 12:21 | <smaug> | oh, interesting |
| 12:21 | <smaug> | didn't know that |
| 12:21 | <smaug> | and looks like Chrome's dnd UI is rather busted on linux |
| 12:21 | <smaug> | the link title and href overlap, so one can't really read either one |
| 12:22 | <smaug> | ondras: and Chrome uses title+href even if you explicitly call setDragImage? |
| 12:23 | <ondras> | smaug: will try |
| 12:23 | <ondras> | smaug: as in, .setDragImage(someNonImageElement) ? |
| 12:23 | <ondras> | weird |
| 12:24 | <smaug> | ondras: that is what the spec is yes. weird indeed |
| 12:24 | <smaug> | https://html.spec.whatwg.org/multipage/interaction.html#dom-datatransfer-setdragimage |
| 12:25 | <ondras> | smaug: confirming that setDragImage fixes the @href issue in Chrome. |
| 12:25 | <smaug> | Gecko seems to take data from <canvas> and <img>, but if something else is used, that element is explicitly painted |
| 12:26 | <ondras> | well that would be optimal for my case |
| 12:27 | <ondras> | also, for larger elements, firefox makes the "ghost" a bit scaled |
| 12:27 | <ondras> | about .7 I would guess |
| 12:29 | <ondras> | smaug: the setDragImage fix has the disadvantage of specifying some anchor point |
| 12:29 | <ondras> | but I can probably compute that, hmm. |
| 12:49 | <MikeSmith> | TabAtkins: about vector-effect="non-scaling-stroke" see https://github.com/validator/validator/issues/373#issuecomment-249838095 and http://codepen.io/thebabydino/pen/oXpWjd It seems Blink, Gecko, and WebKit to actually support it |
| 12:50 | <MikeSmith> | *do actually support it |
| 12:58 | <zcorpan> | MikeSmith: i discussed with i think it was bz about a problem with w3c-test.org, that it uses port 80 breaks some tests |
| 12:58 | <zcorpan> | MikeSmith: can it use 8000 and redirect 80 to 8000? |
| 13:00 | <MikeSmith> | sure |
| 13:00 | <MikeSmith> | I think |
| 13:00 | <MikeSmith> | hmm well actually I do not know how to configure that |
| 13:01 | <MikeSmith> | without installing an additional web server |
| 13:01 | <MikeSmith> | right now w3c-test.org is just running wptserve |
| 13:01 | <MikeSmith> | not apache nor nginx or anything |
| 13:03 | <MikeSmith> | to do what you describe I think I would need to install nginx and run in on port 80 but just have it proxy port 8000 |
| 13:03 | <MikeSmith> | or could I just do it through DNS? |
| 13:04 | <MikeSmith> | anyway that would not help much since I don’t actually have admin access to the DNS for it |
| 13:04 | <MikeSmith> | anyway I guess I also wonder why we don’t just fix the text that break if the port is 80 (or is not 8000) |
| 13:05 | <MikeSmith> | that seems like a bug in the test suite |
| 13:05 | <MikeSmith> | unless we want to document somewhere that the port must be 8000 |
| 13:05 | <MikeSmith> | or just hardcode it |
| 13:06 | <MikeSmith> | because otherwise other people are also going to run into the same problem if they try to run the test suite on a different port |
| 13:07 | <zcorpan> | well 80 is special since it changes the serialization of e.g. location.href from including the port to not including it |
| 13:07 | <zcorpan> | it is a bug in the test so long as anyone is using port 80 to run the tests |
| 13:08 | <zcorpan> | which right now is only w3c-test.org AFAIK |
| 13:09 | <zcorpan> | wptserve has a thing to rewrite URLs but it can only do path rewrites, looks like? http://wptserve.readthedocs.io/en/latest/_modules/wptserve/server.html?highlight=rewriter |
| 13:09 | <zcorpan> | jgraham: ^ |
| 13:10 | <jgraham> | (will look later going afk for a bit) |
| 13:10 | <MikeSmith> | ah OK if I could just use wptserve with that rewrite thing that would be great |
| 13:11 | <MikeSmith> | I also am about to step out for 90 minutes or so |
| 13:12 | <zcorpan> | hmm i suppose rewrite doesn't help. we need to serve a redirect response to switch ports |
| 13:13 | <MikeSmith> | OK well I’m fine with doing it however we need to, even if it requires installing and configuring nginx |
| 13:13 | <zcorpan> | alternatives: 2: fix the broken tests, try to come up with a lint check. 3: break existing links to w3c-test.org |
| 13:13 | <MikeSmith> | I still prefer 2 |
| 13:13 | <zcorpan> | ok |
| 13:14 | <MikeSmith> | but if it turns out to be too big of a deal to fix the tests I am fine with changing the w3c-test.org setup to add the redirect |
| 13:15 | <annevk> | miketaylr: I think I'll try to create that issue for srcElement / window.event today |
| 13:15 | <annevk> | miketaylr: because if we are having them I'd like the shadow tree angle to be sorted sooner than end-of-year |
| 13:20 | <zcorpan> | MikeSmith: 246 files include "{{ports", i'd need to check all of those and any files referencing those (in case of shared scripts) to do (2) |
| 13:20 | <MikeSmith> | hmm that is a lot I guess |
| 13:21 | <MikeSmith> | would be good to know what jgraham and Ms2ger prefer to do |
| 13:21 | <zcorpan> | or maybe that many instances, not that many files |
| 13:23 | <Ms2ger> | Breaking all links to w3c-test.org kinda sucks |
| 13:23 | <Ms2ger> | No strong opinion otherwise |
| 13:25 | <MikeSmith> | anyway I am gonna step out now and be back in 90 minutes or so |
| 13:32 | <zcorpan> | http://w3c-test.org/html/browsers/origin/cross-origin-objects/cross-origin-objects.html is broken... maybe it's just that file, who knows. can fix it though |
| 13:48 | <zcorpan> | hmmmm. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4519 returns empty string, not "80". i don't see that specced in https://html.spec.whatwg.org/multipage/browsers.html#dom-location-port - annevk? |
| 13:49 | <annevk> | zcorpan: a URL's port is null when it's the default |
| 13:49 | <zcorpan> | ah |
| 13:49 | <annevk> | zcorpan: https://url.spec.whatwg.org/#port-state 2.1.3 |
| 13:50 | <zcorpan> | thanks |
| 14:33 | <zcorpan> | https://github.com/w3c/web-platform-tests/pull/3831 MikeSmith |
| 14:38 | <jgraham> | zcorpan: Yeah, we should move w3c-test.org off port 80 |
| 14:38 | <jgraham> | bz was also complaining about that |
| 14:39 | <gsnedders> | Why is that a problem? |
| 14:40 | <zcorpan> | gsnedders: see above. location.port returns "" for default ports, and location.host is different |
| 14:40 | <gsnedders> | yeah, but most of the web runs on port 80, so we probably want to run at least some tests on port 80! |
| 14:41 | <zcorpan> | isn't it most 443 nowadays? :-P |
| 14:42 | <jgraham> | In practice binding to port 80 in automation is tough because root |
| 14:53 | <gsnedders> | https://github.com/w3c/XMLHttpRequest/issues/2 |
| 14:53 | <annevk> | mkwst: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25529#c12 is waiting for input from you I think |
| 14:53 | <annevk> | mkwst: not sure who else can help out |
| 14:53 | <annevk> | gsnedders: I guess they only found a victim for workers? |
| 14:53 | <gsnedders> | annevk: yeah |
| 14:53 | <annevk> | gsnedders: curious that they only stop on "v1" |
| 14:54 | <annevk> | gsnedders: wonder if that means they keep the other snapshot from 2014 around to confuse everyone |
| 14:54 | <gsnedders> | I think someone in theory is working on that. |
| 14:54 | <gsnedders> | Unlike v1. |
| 14:54 | <gsnedders> | But, y'know, every little helps. |
| 14:54 | <annevk> | Pretty sure nobody is working on that |
| 14:54 | <annevk> | I guess |
| 14:55 | <annevk> | I also don't think anyone will actually work on workers btw |
| 14:55 | <annevk> | All I've heard indicates that someone will copy-and-paste bytes |
| 14:55 | <annevk> | Well, code points |
| 14:55 | <annevk> | I've not heard that anyone will help out solve issues with workers |
| 14:56 | <Ms2ger> | As usual |
| 14:58 | <miketaylr> | annevk: cool |
| 14:58 | <miketaylr> | annevk: send a link when you get a chance (or cc me or something) |
| 14:58 | <annevk> | miketaylr: you should be copied |
| 14:59 | <miketaylr> | cool thx |
| 14:59 | <miketaylr> | (haven't looked at mail yet this morning) |
| 15:06 | miketaylr | sees DOM#334 |
| 16:13 | <JonathanNeal> | Just noticed https://dom.spec.whatwg.org/#dom-parentnode-queryall is gone. What happened to .query/.queryAll ? |
| 16:16 | <miketaylr> | JonathanNeal: see https://github.com/whatwg/dom/commit/10b6cf1ba02806220d5461a3bdb7939728b73635 and comments |
| 16:16 | <miketaylr> | basically, waiting on subclassing to work |
| 16:18 | <JonathanNeal> | Is the underlying subclassing being actively worked on? Does this increase or decrease the need to add subclassing? |
| 16:19 | <annevk> | JonathanNeal: I'm not entirely sure what the status is, I think we can subclass builtins in engines now, but I haven't tested it |
| 16:19 | <annevk> | JonathanNeal: what would remain after that is bringing subclassing of builtins to IDL, which might be quite a bit of effort, but not sure |
| 16:22 | <JonathanNeal> | I mostly follow about the subclassing; I remember a conversation about subclassing versus extending. So, what improved as a result of this being removed? |
| 16:23 | <annevk> | JonathanNeal: some folks got confused because the IDL bits were not defined |
| 16:23 | <annevk> | JonathanNeal: so I decided to comment out the feature until that got resolved |
| 16:24 | <annevk> | JonathanNeal: it seems that either way there's confusion |
| 16:26 | <JonathanNeal> | How do you recommend packages like dom-elements, polyfill.io, or my own polyfills address this? It seems dangerous pointing to an imaginary spec, because (maybe only from my point of view) it would seem easier to radically change how relative queries behave. To put a little meat on that last statement, I imagine it could mean a name change to .find/.findAll |
| 16:26 | <JonathanNeal> | again (that was the old name for the live collection?) or a difference in behavior (something related to how scope is handled). |
| 16:29 | <annevk> | JonathanNeal: that's always a risk, right? |
| 16:30 | <annevk> | JonathanNeal: (and why I'm not sure that polyfills are that great if they mimic the API exactly) |
| 16:30 | <annevk> | JonathanNeal: as long as it's not stable (i.e., implemented by most browsers and used in the wild) it can change |
| 16:36 | <JonathanNeal> | @annevk |
| 16:37 | <JonathanNeal> | @annevk agreed it’s a gamble. sometimes is pans out like .closest and other times like .query/.queryAll |
| 16:37 | <JonathanNeal> | ^ irccloud experiencing some interesting delays, apologies if this message was duplicated |
| 16:41 | <jgraham> | Oh FWIW my opinion is that breaking all links isn't terrible |
| 16:44 | <annevk> | jgraham: which links? |
| 16:44 | <JonathanNeal> | What was the reason query/queryAll was chosen over find/findAll? Was it to avoid a conflict with another library or was the query wording just considered more accurate? |
| 17:44 | <jgraham> | annevk: All of them! |
| 17:44 | <jgraham> | OK, actually just to w3c-test.org |
| 18:21 | <jyasskin> | Domenic: Am I just polluted by C++ if I think that non-integral arguments should cause a TypeError in their coercion to IntEnforceWithin<x, y>? |
| 18:28 | <annevk> | jyasskin: hope I got all your issues connected now, sorry about the lag |
| 19:10 | <Domenic> | jyasskin: for keys I think it makes sense to throw |
| 19:11 | <jyasskin> | annevk: Yep, thanks a bunch for all the issue links. |
| 21:35 | <rniwa> | Domenic, kochi: could either one of you merge https://github.com/w3c/web-platform-tests/pull/3637 ? |
| 21:37 | <rniwa> | Domenic: thanks! |
| 21:37 | <Domenic> | \o/ |
| 21:45 | <rniwa> | Domenic: another one: https://github.com/w3c/web-platform-tests/pull/3835 |
| 21:45 | <rniwa> | kochi: ^ |
| 21:45 | <rniwa> | Domenic, kochi: Chrome Canary seems to fail some of *callback tests that involve adopting custom elements into a new document |
| 21:45 | <rniwa> | somehow the reactions aren't queued or processed |
| 21:47 | <rniwa> | oh wait, no. this is about "new Document" failing |
| 22:04 | <Domenic> | yeah :( |
| 22:05 | <Domenic> | we're trying to implement it but foolip has concerns |
| 23:05 | <rniwa> | Domenic, kochi: here are more tests for custom elements reactions: https://github.com/w3c/web-platform-tests/pull/3835 |