| 02:34 | <kochi> | mmm, where beforecut, beforecopy, beforepaste events are defined? |
| 02:40 | <a-ja> | https://w3c.github.io/clipboard-apis/ |
| 02:41 | <a-ja> | there are references near the end |
| 02:43 | <a-ja> | referenced: https://msdn.microsoft.com/en-us/library/ms537658.aspx |
| 03:05 | <kochi> | a-ja: I cannot find reference in the editor's draft of clipboard api spec |
| 03:06 | <kochi> | searching "before" shows 3 candidates which are not before* events |
| 03:08 | <a-ja> | kochi: see the msdn link above |
| 03:09 | <kochi> | a-ja: yeah, it seems the MSDN doc is a historical archive. So beforecopy et al. existed since long ago? |
| 03:09 | <a-ja> | it has link to several before*'s |
| 03:10 | <a-ja> | i'm guessing the clipboard-api's are an effort at standardizing/replacing old dhtml |
| 03:11 | <kochi> | [MICROSOFT-CLIP-OP] in the clipboard API spec is just a reference, not a spec... so before* events are not formally specified in any whatwg or w3c specs, then. |
| 03:12 | <a-ja> | just a link to prior work, as best i can tell |
| 03:12 | <kochi> | yeah, looks like so. |
| 03:12 | <kochi> | even MDN has broken links to before* events : https://developer.mozilla.org/en-US/docs/Web/API/ClipboardEvent |
| 03:13 | <kochi> | the context is, that I am trying to specify these events are composed for V1 Shadow DOM, but I could not find any definition for before* events. |
| 03:14 | <kochi> | So browser vendors have to do *best guess* to make those before* events composed, then. |
| 03:17 | <a-ja> | https://bugzilla.mozilla.org/show_bug.cgi?id=1309697 |
| 03:19 | <a-ja> | https://bugzilla.mozilla.org/show_bug.cgi?id=1344410 <-- has a *little* history |
| 03:31 | <kochi> | also found some history |
| 03:31 | <kochi> | https://github.com/w3c/clipboard-apis/issues/24 |
| 03:31 | <kochi> | https://github.com/w3c/clipboard-apis/issues/25 |
| 06:56 | <hayato_> | smaug____: re: event-composed-path-with-related-target.html#L136 , let me look later. |
| 07:22 | <foolip> | tobie: thanks for looking into that, I'll let you know about any bugs I notice :) |
| 07:26 | <tobie> | foolip: if there’s a discrepancy between the diff sha you see when hovering over the links and the actual content, then it’s the same issue hitting again. |
| 09:10 | <aliray> | hi, I'm having a small coding issue: this code downloads a URL and saves it to file: http://dpaste.com/13GJCH6 |
| 09:11 | <aliray> | But I get this result: http://dpaste.com/1DV1XRG |
| 09:11 | <aliray> | (this is just the head of the doc) |
| 09:12 | <aliray> | The issue is with the namespaced xml attributes |
| 09:12 | <aliray> | It reads "xmlnsU0003Aaa" instead of "xmlns:aa" |
| 09:12 | <aliray> | what's wrong with my code? |
| 09:27 | <zcorpan> | aliray: something in your code implements https://html.spec.whatwg.org/#coercing-an-html-dom-into-an-infoset (which is not necessarily wrong) |
| 09:34 | <aliray> | zcorpan, thanks. Related: https://stackoverflow.com/questions/12253791/html5lib-with-lxml-treebuilder-doesnt-parse-namespaces-correctly#12254291 |
| 09:38 | <smaug____> | hayato_: FYI, I have fix for that test locally, so you don't need to change that, unless you get to it first when fixing blink's implementation. |
| 09:39 | <aliray> | zcorpan, this is my problem I guesshttps://www.w3.org/TR/html-rdfa/#backwards-compatibility |
| 09:39 | <aliray> | https://www.w3.org/TR/html-rdfa/#backwards-compatibility |
| 09:46 | <kochi> | smaug____ I haven't looked at it yet, looking. |
| 10:25 | <kochi> | smaug____: looks like you are correct, but I am trying to understand why we did this at first. |
| 10:26 | <smaug____> | spec change after implementation perhaps? |
| 10:26 | <smaug____> | or implementation has some left over from v0 era? |
| 10:26 | <smaug____> | or just a bug :) |
| 10:27 | <kochi> | it smells just a bug, but I haven't figured it out. |
| 10:28 | <kochi> | smaug____: so you meant the spec is correct, test should be fixed, and Blink implemnetation should be fixed as well, right? |
| 10:28 | <smaug____> | right |
| 10:29 | <smaug____> | at least to me the spec does look sane |
| 10:29 | <kochi> | yeah, so if target is a shadow-including ancestor of related target, then the event dispatch is suppressed at all. |
| 11:10 | <hayato_> | smaug____: I've taken look |
| 11:11 | <hayato_> | I think the test and Blink's behavior are correct. |
| 11:11 | <hayato_> | That was intentionally done for backward compatibility of synthetic events. |
| 11:11 | <hayato_> | See the context: https://github.com/w3c/webcomponents/issues/577 |
| 11:11 | <hayato_> | https://github.com/whatwg/dom/issues/337 |
| 11:12 | <annevk> | foolip: so what do you think we should research with the validator? |
| 11:12 | <hayato_> | We should have different behavior here between synthetic events and user-agent events. That is a confusing point, but we agreed taht we had to accept. |
| 11:12 | <annevk> | foolip: how many additional warnings we'd trigger? |
| 11:12 | <annevk> | foolip: for <main> |
| 11:16 | <foolip> | annevk: for all of the contexts you're proposing that <main> become invalid, which happen most often, and then to look at what those pages are doing |
| 11:17 | <foolip> | I'm actually doing some grepping/parsing in httparchive data now to see what the parent chains look like most frequently |
| 11:18 | <MikeSmith> | so I think I can actually add use counters for each case to the checker |
| 11:19 | <annevk> | foolip: I'm happy to help analyzing URLs to some extent |
| 11:51 | <annevk> | MikeSmith: sounds great, if it's not actually common I think we should just proceed so that'd be good to know |
| 11:52 | <MikeSmith> | will try to get those added tonight |
| 11:52 | <MikeSmith> | bath time for the kids first |
| 12:28 | <hsivonen> | gsnedders: subject to plh's license approval, is it OK if I add a noto directory under WPT's tests/fonts/ and put the unzipped directories of the Noto Sans Adlam and Noto Sans Cypriot fonts there? (both are relatively small as far as fonts go) |
| 12:30 | <hsivonen> | (that is, I don't have a license approval from plh yet) |
| 12:32 | <hsivonen> | oops. there is precedent to having OFL fonts in WPT already. Just not in the directory I examined. |
| 12:37 | <hsivonen> | hmm. maybe I should put the fonts under css/fonts/ instead if I put my tests under css |
| 12:38 | <hsivonen> | gsnedders: I want to add https://hsivonen.com/test/moz/astral-bidi/ to WPT. Where in the WPT hierarchy should I put these |
| 12:39 | <annevk> | hsivonen: https://github.com/w3c/web-platform-tests/tree/master/css/css-fonts? |
| 12:40 | <hsivonen> | it's possible that these tests are redundant, but I failed to find existing tests for the two astral rtl ranges |
| 12:41 | <hsivonen> | annevk: that directory is for testing CSS font features |
| 12:41 | <hsivonen> | annevk: https://github.com/w3c/web-platform-tests/tree/master/css/fonts and https://github.com/w3c/web-platform-tests/tree/master/fonts are for font files |
| 12:41 | <hsivonen> | annevk: in my tests, the fonts are incidental and what's being tested is rtl treatement of astral code points |
| 12:42 | <hsivonen> | (my interest is testing that DOM-level optimizations don't prevent rtl behavior on the layout layer) |
| 12:43 | <annevk> | Maybe css-text then? The hierarchy of directories can make it very hard to determine where to place tests at times |
| 12:43 | <annevk> | A tagging system would be better, but doesn't really match file systems that well |
| 12:45 | <hsivonen> | nox: you in the OWNERS for the directory that annevk suggested. does it look like the right directory? |
| 12:45 | <nox> | What? |
| 12:46 | <hsivonen> | nox: If I put https://hsivonen.com/test/moz/astral-bidi/ in WPT, is it OK to put the directory under https://github.com/w3c/web-platform-tests/tree/master/css/css-text ? |
| 12:46 | <nox> | Seems like the right place yes. |
| 12:46 | <hsivonen> | nox: thanks |
| 13:06 | <hayato_> | smaug____: Ah, my previous comments about event path were wrong. |
| 13:07 | <hayato_> | I've finally found this PR and the discussion there. https://github.com/whatwg/dom/pull/336 |
| 13:07 | <hayato_> | It looks isTrusted guard was removed from the commit, as per https://github.com/whatwg/dom/pull/336#issuecomment-254416132. |
| 13:11 | <hayato_> | Your comment there, https://github.com/whatwg/dom/pull/336#issuecomment-251400264, really makes sense. :) |
| 13:11 | <hayato_> | We shouldn't use PRs for discussing spec issues. Because of that, I couldn't find the discussion and couldn't notice why isTrusted guard was removed easily. |
| 13:34 | <gsnedders> | bah, missed hsivonen |
| 13:45 | <nox> | Window features (third argument of window.open) are almost not specified, right? |
| 13:50 | <annevk> | nox: there's a couple open issues against HTML and CSSOM |
| 13:51 | <gsnedders> | nox: the parsing is, but IIRC that's most of what is |
| 13:55 | <nox> | gsnedders: Yeah. |
| 13:55 | <nox> | gsnedders: Asking because I'm looking at the C++ code to do that in Gecko, |
| 13:56 | <nox> | and it looks pretty bad and it just strips whitespace everywhere, |
| 13:56 | <nox> | so setting "left" is the same as setting "l e f t". |
| 13:56 | <nox> | And then I realised it has a dozen non standard features too. |
| 13:59 | <smaug____> | hayato_: yeah, discussing spec issues in prs is horrible |
| 14:05 | <nox> | I don't even understand why it strips spaces. |
| 14:05 | <gsnedders> | hsivonen: yeah, fonts are clearly okay (we have other Noto Sans fonts in various places, which we should probably move up to /fonts) |
| 14:06 | <gsnedders> | hsivonen: and yeah css/css-text is probably right |
| 14:07 | <nox> | How do I make Chrome listen to the window features I pass to it? |
| 14:09 | <hsivonen> | gsnedders: thanks |
| 14:10 | <gsnedders> | hsivonen: (maybe just create a css/css-text/bidi or something?) |
| 14:15 | <nox> | I think the feature parsing code is incorrect. |
| 14:16 | <nox> | Never mind, can't read. |
| 23:03 | <othermaciej> | Domenic: I notice HTML hasn't had its copyright notice updated or a LICENSE file added, should I file an issue? (Would it go in the html issue tracker?) |
| 23:03 | <othermaciej> | (Asking first in case it is already tracked or there is some reason for delay or something) |
| 23:04 | <Domenic> | othermaciej: It's https://github.com/whatwg/html/pull/3349, blocked on someone reviewing my build tooling patch in https://github.com/whatwg/wattsi/pull/67 |
| 23:04 | <Domenic> | Maybe I should just merge it |