| 05:47 | <rniwa> | annevk: yt? |
| 05:53 | <dominicc> | rniwa: yt? |
| 05:53 | <rniwa> | dominicc: yeah |
| 05:53 | <rniwa> | dominicc: so there's some confusion about brand check in https://dom.spec.whatwg.org/#concept-create-element |
| 05:54 | <rniwa> | dominicc: I think the intent is to check it against any HTMLElement interface, not just the one in the same global |
| 05:54 | <dominicc> | Can I try custom elements in WebKit Nightly? I ran your LayoutTests in Chrome yesterday, they were very informative, found a few good bugs. I also found some things which, if WebKit is passing the tests, might be contrary to the spec. I made a detailed list I can share with you if you're interested. |
| 05:55 | <rniwa> | dominicc: great :) |
| 05:55 | <rniwa> | dominicc: that would be graet |
| 05:55 | <rniwa> | great* |
| 05:55 | <rniwa> | dominicc: unfortunately, there is not a good way to enable a runtime flag at the moment :( |
| 05:55 | <dominicc> | I have a link, one second... |
| 05:55 | <rniwa> | dominicc: you basically have to modify the code :( |
| 05:55 | <dominicc> | I tried building WebKit but I think I need a newer framework; I have 10.10. Guess that is old. Got some macro failure spew about CF_AVAILABLE. |
| 05:56 | <rniwa> | dominicc: hm... |
| 05:56 | <rniwa> | dominicc: so I'm going to try enabling it in STP soon-ish |
| 05:56 | <rniwa> | dominicc: my goal is to finish implementing as much as I can before TPAC |
| 05:56 | <rniwa> | dominicc: so that we can just sit down & compare impls |
| 05:56 | <dominicc> | Here's my notes: http://goo.gl/yli9Ao |
| 05:57 | <dominicc> | Great! I plan to be at TPAC every day. |
| 05:59 | <dominicc> | re: confusion about the brand check, I guess it takes digging throw WebIDL to find out what "implements" means, but I could imagine that means any HTMLElement interface. What do you think? |
| 05:59 | <dominicc> | rniwa: I assume you mean in step 6.1.3? |
| 05:59 | <rniwa> | dominicc: yeah |
| 06:00 | <dominicc> | rniwa: There's a webidl issue linked in the note, it seems that any HTMLElement is certainly the intent. |
| 06:01 | <rniwa> | dominicc: yeah |
| 06:02 | <rniwa> | dominicc: cool. thanks for the notes |
| 06:03 | <rniwa> | dominicc: they were written way back in April or something when I first implemented the new spec |
| 06:03 | <rniwa> | dominicc: so all these things are fallouts from the spec changes that have happened since then |
| 06:04 | <rniwa> | dominicc: e.g. we don't implement any of sanity checks in 6.1.: https://dom.spec.whatwg.org/#concept-create-element |
| 06:05 | <rniwa> | although I'm fixing that right now. sort of. |
| 06:16 | <annevk> | rniwa: around a bit, lack of branding is a known issue with IDL and DOM |
| 06:17 | <rniwa> | annevk, dominicc: for now, WebKit & Chrome implementations both do "the right thing". |
| 06:17 | <rniwa> | but this is a compat risk. |
| 06:21 | <annevk> | rniwa: I guess we could clarify the issue and planned fix more, file an issue? |
| 06:21 | <rniwa> | annevk: I was about to but it seems like your issue is still open |
| 06:21 | <rniwa> | annevk: so i figured i don't need another one |
| 06:21 | <rniwa> | annevk: I'll just wait 'til the definition is added and then we can argue whether we need to fix it or not |
| 06:21 | <annevk> | rniwa: IDL is on track to get maintained a bit more, but it'll take a while still I suspect |
| 06:21 | <annevk> | rniwa: if Apple could find an editor somewhere… |
| 06:21 | <rniwa> | annevk: well, we need to first implement all these specs people have produced |
| 06:21 | <rniwa> | annevk: but yeah, i wish we had more man power to contribute there. |
| 06:21 | <annevk> | rniwa: if only Apple had the money |
| 06:22 | <rniwa> | annevk: the money isn't usually issue though. finding a candidate is insanely hard :( |
| 06:22 | <rniwa> | annevk: we've had a position open for more than 12 months in our team for example |
| 06:22 | <annevk> | heh |
| 06:24 | <rniwa> | annevk: the requirement that one has to work in Cupertino isn't helping there :( |
| 06:25 | <boogyman> | why does the location matter? |
| 06:25 | <rniwa> | annevk: so we can't tap on those good european software engineers who aren't willing to relocate, etc... :( |
| 06:25 | <rniwa> | boogyman: i don't know. |
| 06:26 | <boogyman> | maybe the fact that the position has been unoccupied for so long would spur the recruiters to consider other candidates |
| 06:31 | <rniwa> | annevk: are we supposed to be creating Element in a XML document when the custom element interface isn't defined and its name is a valid custom element name? |
| 06:31 | <rniwa> | annevk: or are we still supposed to create HTMLElement |
| 06:37 | <rniwa> | dominicc: ^ |
| 06:37 | <rniwa> | I think the current spec indicates that it should be Element. |
| 06:37 | <rniwa> | implies* |
| 06:38 | <dominicc> | rniwa: What does the HTML spec say about XML documents having browsing contexts? I think if you found a definition you'd create a HTML element; what do you think about the possibility of finding a definition? |
| 06:38 | <rniwa> | dominicc: I'm not following. |
| 06:39 | <annevk> | rniwa: not sure |
| 06:39 | <rniwa> | dominicc: the existence of browsing context is independent of whether it's a XML document or a HTML docuemnt. |
| 06:39 | <dominicc> | To create a custom element you have to find a definition; to find a definition, you have to be creating an element in the HTML namespace. |
| 06:39 | <annevk> | rniwa: forgot whether XML parser is patched |
| 06:39 | <rniwa> | dominicc: that's not entirely true. |
| 06:39 | <dominicc> | That is https://html.spec.whatwg.org/multipage/scripting.html#look-up-a-custom-element-definition step 1? |
| 06:40 | <rniwa> | dominicc: you can create an element inside a XML document, which uses the same global object as the one that as a browsing context |
| 06:40 | <rniwa> | dominicc: and then adopt that element into the document with a browsing context |
| 06:40 | <dominicc> | rniwa: Are you referring to create an element step 6.2.1? |
| 06:40 | <rniwa> | dominicc: not sure |
| 06:40 | <rniwa> | dominicc: not quite* |
| 06:40 | <rniwa> | dominicc: I'm trying to create an element in a detached XML document. e.g. one created by DOMImplementation |
| 06:41 | <rniwa> | dominicc: then adopt it back into a HTML document with a browsing context both of which shares a single global object |
| 06:41 | rniwa | this is getting complicated |
| 06:41 | <dominicc> | rniwa: OK. I'm with you so far. You do those things. |
| 06:42 | <rniwa> | dominicc: so in this case, the element we're creating isn't necessary in HTML namespace. |
| 06:42 | <rniwa> | dominicc: so I think it should be using Element interface |
| 06:42 | <rniwa> | dominicc: and upgrade should subsequently fail because it doesn't match the namespace |
| 06:43 | <rniwa> | more precisely, looking up a custom element definition step should not find any interface |
| 06:43 | <dominicc> | rniwa: Right. I think every algorithm checks the namespace is HTML and bails out/no ops if it isn't HTML. |
| 06:43 | <rniwa> | dominicc: something like that |
| 06:43 | <dominicc> | Right. That is look-up-a-custom-element-definition step 1 I linked to ^^^ |
| 06:45 | <rniwa> | dominicc: ah, okay. now I follow what you were saying earlier |
| 06:45 | <dominicc> | rniwa: Sorry for the bit about browsing contexts, you're right it's not a browsing context thing. |
| 06:48 | <rniwa> | dominicc: oh, np. |
| 07:18 | <rniwa> | dominicc: i forgot to reply but i'll be at TPAC for five days so hopefully we'll have a plenty of time to sort out details of custom elements |
| 07:19 | <dominicc> | rniwa: splendid, look forward to it! |
| 07:19 | <dominicc> | rniwa: domenic is coming too. |
| 07:19 | <rniwa> | dominicc: cool |
| 07:20 | <rniwa> | dominicc: luckily, custom elements have fewer contentious points than shadow DOM still |
| 07:20 | <rniwa> | dominicc: except is= |
| 07:21 | <rniwa> | dominicc: so hopefully it'd be straight forward to sort out the remaining issues at TPAC at least for autonomous custom elements |
| 07:21 | <dominicc> | rniwa: Yep! |
| 07:22 | <dominicc> | rniwa: We're working hard to get our tests in shape by that time. We need to do some updates for recent spec changes. |
| 07:22 | <rniwa> | dominicc: yeah, i'm doing the same for webkit tests as fast as I can |
| 07:25 | <rniwa> | dominicc: it looks like you haven't added "element definition is running flag"? |
| 07:25 | <dominicc> | rniwa: not yet. We still have the older check where reentrancy is allowed, as long as it is a different name. |
| 07:26 | <rniwa> | dominicc: I see. |
| 07:26 | <dominicc> | rniwa: This will change next week. |
| 07:29 | <rniwa> | dominicc: here's a way to enable custom elements on STP. |
| 07:29 | <dominicc> | rniwa: ooh goody, what? |
| 07:29 | <rniwa> | dominicc: on macOS Sierra, there's a submenu in "Develop" menu |
| 07:30 | <dominicc> | rniwa: interesting. I will have to set up Sierra... I'm travelling next week :/ |
| 07:30 | <rniwa> | dominicc: yeah, probably not a good idea :( |
| 07:32 | <rniwa> | dominicc: but going forward, you should be able to toggle experimental features on that submenu. |
| 07:33 | <rniwa> | so hopefully this pain of not being able to toggle features without having to build webkit will go away soon |
| 07:50 | <zcorpan> | I wonder if we can start checking the MIME type for (classic) Worker()/SharedWorker() and importScripts() |
| 07:51 | <zcorpan> | although maybe that doesn't help anything if <script> still has a lax check |
| 08:11 | <annevk> | zcorpan: yeah, <script> is the main problem |
| 09:00 | <zcorpan> | apart from <script>, which requests send Accept:*/* in chrome? |
| 09:04 | <annevk> | zcorpan: is https://bugzilla.mozilla.org/show_bug.cgi?id=1299373 on your list? |
| 09:04 | <annevk> | zcorpan: XHR and fetch() should, iirc |
| 09:08 | <zcorpan> | annevk: the not-execute part is "If src is the empty string, queue a task to fire a simple event named error at the element, and abort these steps." https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model:attr-script-src-5 |
| 09:10 | <zcorpan> | annevk: as for reflect, <script src> indeed falls under that case and should return "" per spec |
| 09:14 | <zcorpan> | it can't find any browser now that returns empty string for .src for http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4429 though. |
| 09:16 | <zcorpan> | the spec issue was https://github.com/whatwg/html/issues/859 |
| 09:19 | <zcorpan> | https://github.com/w3c/web-platform-tests/pull/2663 .... looks like I've missed to follow up on this |
| 10:14 | <zcorpan> | MikeSmith: r? https://github.com/whatwg/html-build/pull/93 |
| 10:24 | <MikeSmith> | zcorpan: so yeah maybe I will just drop the IE-conditional-comment warning |
| 10:29 | <zcorpan> | MikeSmith: ok. I made a PR for that :-) |
| 10:30 | <zcorpan> | annevk: FYI https://discuss.httparchive.org/t/which-mime-types-are-used-for-accept-requests/821 |
| 10:31 | <zcorpan> | MikeSmith: if you mean comment-before-doctype warning |
| 10:41 | <mkwst> | zcorpan: Thanks for looking into this. :) |
| 10:41 | <mkwst> | `*/*` is used for just about everything, though; I think it's going to be tough to isolate `<script>` responses just from the network-level data. |
| 10:42 | <zcorpan> | mkwst: yeah :-( why is favicon */* and not together with IMAGE though? |
| 10:42 | <mkwst> | zcorpan: Oversight, probably. |
| 10:44 | <MikeSmith> | zcorpan: yeah that’s what I meant |
| 10:45 | <zcorpan> | MikeSmith: https://github.com/validator/htmlparser/pull/2 is the pr |
| 10:47 | <zcorpan> | annevk: OK if I go ahead and merge https://github.com/whatwg/html/pull/1732 and the lint check? |
| 10:48 | <annevk> | zcorpan: yeah, thanks for working on it |
| 10:48 | <annevk> | zcorpan: I'm somewhat on-off for two weeks and then TPAC, after all which I hope to get back to the WHATWG style guide stuff |
| 11:02 | <zcorpan> | annevk: ok cool |
| 11:18 | <smaug____> | mounir: re-ping |
| 11:18 | <smaug____> | or perhaps he is on vacation |
| 11:37 | <smaug____> | what is wrong with w3 drafts |
| 11:37 | <smaug____> | some server down so that css files aren't loaded? |
| 11:38 | <smaug____> | or bug in https://www.w3.org/Tools/respec/respec-w3c-common |
| 11:40 | <smaug____> | MikeSmith: do you happen to know if this is a known issue, or where should I report this? |
| 11:41 | <smaug____> | https://w3c.github.io/preload/ for example looks bad, so does http://w3c.github.io/presentation-api/ |
| 11:55 | <zcorpan> | smaug____: Uncaught ReferenceError: PARAMS_CONTAINS is not defined |
| 12:00 | <zcorpan> | maybe a bug in the minifier? https://github.com/w3c/respec/blob/e384535ab86bd0511c96e88b24902889e8a1eb07/js/deps/highlight.js#L990 doesn't have "return" there |
| 12:01 | <mkwst> | zcorpan: https://codereview.chromium.org/2303443005 |
| 12:01 | <zcorpan> | mkwst: <3 |
| 12:02 | <zcorpan> | smaug____: https://github.com/w3c/respec/issues/928 was reported already |
| 12:36 | <smaug____> | annevk: remind me, what is the current state of * settings object |
| 12:36 | <botie1> | will do |
| 12:36 | <smaug____> | which one should be used normally |
| 12:37 | <smaug____> | I assume incumbent |
| 12:38 | <smaug____> | or Domenic ^ |
| 12:47 | <annevk> | smaug____: no, use relevant, then current |
| 12:47 | <smaug____> | hmm, what is current |
| 12:48 | <smaug____> | seems like we've got even more * settings object since I last time looked at this part of the spec |
| 12:49 | <smaug____> | entry, incumbent, relevant, current, environment |
| 12:49 | <smaug____> | are there more |
| 12:49 | <annevk> | smaug____: matches JavaScript's current Realm |
| 12:49 | <smaug____> | I need to understand what current is |
| 12:49 | <smaug____> | and what is relevant |
| 12:49 | <smaug____> | and what is environment |
| 12:49 | <annevk> | smaug____: that's it; entry/incumbent are least interoperable |
| 12:50 | <annevk> | smaug____: relevant is the global object of a platform object |
| 12:50 | <smaug____> | In Gecko we don't have anything for relevant or current, I think |
| 12:50 | <annevk> | smaug____: we do for sure |
| 12:50 | <smaug____> | I see, for relevant it is implicit |
| 12:51 | <annevk> | smaug____: many features depend on those |
| 12:52 | <smaug____> | hmm, now I'm lost with current and incumbent |
| 12:52 | <smaug____> | and looks like there is a getter for current in Gecko |
| 12:55 | <smaug____> | annevk: but ok, new specs should use entry settings, right? |
| 13:04 | <annevk> | smaug____: no |
| 13:04 | <annevk> | smaug____: relevant, then current |
| 13:28 | <smaug____> | annevk: er, I said wrong. missed 'not' |
| 13:28 | <smaug____> | but ok, thanks |
| 13:28 | <annevk> | Heh |
| 13:29 | <smaug____> | annevk: filed a presentation API bug to switch using something else than entry settings |
| 13:31 | <annevk> | Ta |
| 13:43 | <tobie> | TabAtkins, others: is there a quick an easy way to include JS snippets in bikeshed source files without having to escape constructs that are mistaken for macros? |
| 13:45 | <Ms2ger> | setInterval('{', 10) |
| 13:45 | <Ms2ger> | Should that hit window.onerror once or every ten ms? |
| 13:55 | ondras | would vote for every ten ms |
| 13:59 | <smaug____> | yeah, every 10 it should be |
| 14:15 | <zcorpan> | Ms2ger: per spec it's every 10 AFAICT. note there's also event handler content attributes, and i think tests for these in wpt |
| 14:15 | <Ms2ger> | Yeah |
| 14:16 | <zcorpan> | in html/webappapis/scripting/processing-model-2/ |
| 14:17 | <zcorpan> | though maybe not checking if it's once or every time |
| 14:18 | <Ms2ger> | Yeah |
| 14:18 | <Ms2ger> | I don't think there's one for that |
| 14:20 | <zcorpan> | could change ran from a boolean to an int and increment it, then check the value being > 1 after a big enough timeout, or pass the test on the second onerror invocation... |
| 14:21 | <Ms2ger> | Yeah |
| 14:22 | <Ms2ger> | I tried that, but it was flaky in Servo |
| 14:23 | <zcorpan> | "pass the test on the second onerror invocation" shouldn't be flaky though? |
| 14:23 | <Ms2ger> | Yeah |
| 14:24 | <Ms2ger> | Anyway, for another day |
| 17:28 | <TabAtkins> | tobie: Unfortunately no. The macro recognizer's regex should ignore *most* JS array access, but not all. Specifically, it only recognizes macro names composed of uppercase characters, digits, and dashes (and excludes all-digit ones). |
| 17:28 | <TabAtkins> | So common JS practice (using foo[0] or foo[var]) is perfectly safe. |
| 17:30 | <tobie> | TabAtkins: yeah, minified code (...[N]) along with /[A-Z]/ regex constructs in modernizr snippet. |
| 17:30 | <tobie> | s/cat/sed/ and was good to go |
| 17:30 | <TabAtkins> | Ah, kk. |
| 17:31 | <TabAtkins> | I think I know how to make the text-fixer function not replace inside of opaque elements, tho. |
| 17:32 | <TabAtkins> | I run block-Markdown parsing first, which *is* smart enough to avoid opaque elements. I think I can just litter the text with escape sequences, to make it trivial for the inline text-fixer to know whether it's in an opaque thing or not, without having to redo the parsing logic on its own. |
| 17:32 | <TabAtkins> | Then remove them afterwards. |
| 17:33 | <tobie> | yeah, I can see that working. |
| 17:34 | <marti_> | Hi is there zcorpan? |
| 17:34 | <tobie> | TabAtkins: You might have backward compat issues though, if escaped stuff suddenly no longer needs escaping |
| 17:34 | <marti_> | I would like to work in https://github.com/whatwg/html/issues/507 |
| 17:34 | <TabAtkins> | Why is the world pain? |
| 17:43 | <Domenic> | marti_: how can we help you? |
| 23:20 | <jyasskin> | API design question: is the https://w3c.github.io/presentation-api/#dom-presentationrequest-getavailability pattern something we should emulate in other specs, specifically Web Bluetooth? Folks write "new PresentationRequest("...").getAvailability().then(avail => ...)", and then avail.value holds whether the resource is available, and you do |
| 23:20 | <jyasskin> | avail.addEventListener("changed") to check if availability changes. |
| 23:21 | <jyasskin> | s/changed/change/ |
| 23:22 | <jyasskin> | Exposing this through a non-Promise interface isn't ideal because it forces shipping the information to every renderer whether or not they want it, but the approach of creating a whole type for it is also ugly. |