| 09:47 | <annevk> | Does anyone here know whether Unicode NFC removes U+0000 from input? I have a hard time figuring out how Unicode defines this... |
| 09:50 | <annevk> | Context: https://github.com/w3c/web-platform-tests/commit/b9dfb676b3e67fa5cb6da2e757a5527d9c0bc0f3#commitcomment-15225993 |
| 10:17 | <annevk> | GitHub disappoints: https://github.com/whatwg/html/pull/443/files |
| 11:16 | <nox> | annevk: Not sure it does. |
| 11:19 | <nox> | annevk: https://github.com/w3c/web-platform-tests/commit/b9dfb676b3e67fa5cb6da2e757a5527d9c0bc0f3#commitcomment-15285524 |
| 11:25 | <annevk> | nox: haha |
| 11:25 | <annevk> | nox: Chrome didn't test their ICU integration properly it seems |
| 11:26 | <annevk> | Tests should continue to test U+0000 and \x00 as there's always bugs everywhere |
| 11:36 | <nox> | annevk: I know I know. :) |
| 13:41 | <Ms2ger> | TabAtkins, ping |
| 14:35 | <tobie> | if in WebIDL I have many things that inherit from the Foo interface, how can I refer to them generically? I'd like to say something like "the relevant Foo subclass" or "Foo subclasses." |
| 14:37 | <tobie> | context: https://w3c.github.io/sensors/#model |
| 14:40 | <annevk> | tobie: I'd just go with Foo's subclasses, but then also call it the Foo class etc. |
| 14:41 | <annevk> | tobie: at some point IDL needs to be updated to change interface to class and introduce mixins for the other thing |
| 14:41 | <nox> | In Servo we say Foo's derived interfaces. |
| 14:41 | <annevk> | DOM uses that terminology for Event it seems |
| 14:42 | <annevk> | but it'll go away in due course |
| 14:43 | <tobie> | annevk, nox: ty both |
| 14:44 | <nox> | annevk: Go away in favour of what? |
| 14:44 | <annevk> | nox: class/subclass |
| 14:44 | <nox> | Ok. |
| 14:45 | <annevk> | heycam wants some kind of complete plan for changing IDL syntax rather than just changing things incrementally |
| 14:45 | <nox> | annevk: So he wants class Node { … }? |
| 14:45 | <annevk> | if by mid-2016 things still haven't moved I think I'll try to push for incremental changes |
| 14:45 | <annevk> | nox: well, some of us want that |
| 14:46 | <nox> | annevk: I might have a time frame to move WebIDL to Bikeshed during Spring. |
| 14:46 | <nox> | If that's wanted. |
| 14:46 | <annevk> | not sure about Node btw, might need a distinction between abstract classes and classes |
| 14:46 | <nox> | annevk: Nice, Ms2ger and I are upstreaming [Abstract] in Gecko. |
| 14:46 | <annevk> | nox: you should ask heycam to be sure |
| 14:47 | <annevk> | nox: I think IDL might actually want to use the same tools that ECMAScript uses, since everything should be pretty similar |
| 14:48 | <Ms2ger> | I just started converting to bs |
| 14:48 | <nox> | Ms2ger: Oh nice. |
| 14:48 | <Ms2ger> | I really don't want to deal with yet another tool |
| 14:52 | <nox> | Same. |
| 15:06 | <tobie> | annevk: what's the practical distinction between abstract classes and classes in the context of the Web? |
| 15:07 | <tobie> | annevk: the constructor of the abstract class throws? |
| 15:07 | <Ms2ger> | No |
| 15:07 | <nox> | Most throws whether they are abstract or not. |
| 15:07 | <nox> | But you never have an instance of Node that is just an instance of Node. |
| 15:08 | <nox> | I'm not sure how that is important, spec-wise. |
| 15:10 | <tobie> | Ms2ger: ? |
| 15:10 | <Ms2ger> | An abstract class is one that cannot be instantiated directly |
| 15:11 | <Ms2ger> | Web-exposed constructors are unrelated |
| 15:11 | <nox> | Ms2ger: Is it important for Web exposure to know that they aren't instantiated directly? |
| 15:12 | <Ms2ger> | Not really |
| 15:13 | <tobie> | Ms2ger: yeah--I'm aware of this. My question was more akin to nox's. How does that manifest itself differently than the absence of a constructor extended attribute? |
| 15:13 | <Ms2ger> | It doesn't |
| 15:13 | <nox> | tobie: Even if you don't have a constructor, |
| 15:13 | <nox> | you could have a Document.createNode. |
| 15:14 | <nox> | Or whatever else that would be defined to instantiate Node objects. |
| 15:14 | <nox> | Ms2ger: Should we make a new release of rust-mozjs, or shrug? |
| 15:14 | <nox> | Wrong channel. |
| 15:15 | <tobie> | nox: I guess |
| 15:19 | <annevk> | tobie: I guess I was thinking that a class would always have a constructor |
| 15:19 | <tobie> | annevk: I see |
| 15:21 | <yoav> | annevk: hey! I want to add a usage example for supports() as a feature detection mechanism |
| 15:21 | <yoav> | PRed it to https://github.com/w3c/preload/pull/39 but Ilya suggested that it may be better off at a generic location |
| 15:21 | <yoav> | Do you think it'd fit in DOM? |
| 15:24 | <annevk> | yoav: yeah, with some rewording |
| 15:24 | <yoav> | sure |
| 15:27 | <nox> | annevk: What would happen of ParentNode and things like that? |
| 15:27 | <annevk> | nox: mixins |
| 15:28 | <nox> | annevk: "mixin ParentNode"? |
| 15:32 | <annevk> | nox: something like that |
| 15:32 | <Domenic> | annevk: my thought was that classes always have constructors but you could explicitly opt in to [ThrowsWithoutSecret] or [ThrowsFromAuthorCode] or similar. |
| 15:33 | <annevk> | Domenic: that could work too |
| 15:34 | <Domenic> | The important thing is that you can only create class instances via their constructors, even if you're a spec. A spec might just have to use language like "construct-with-secret a new HTMLHRElement passing the parsed values as arguments" or something... |
| 15:37 | <Domenic> | I guess there's not a lot of value in passing arguments to a secret-protected constructor vs. just calling a no-arg secret-protected constructor and then directly reaching in and setting internal slots. Unless you cared about inter-spec encapsulation/invariant preservation or similar. |
| 15:38 | <Domenic> | I dunno, still unsure on the value of changing IDL syntax. There's so much to do in just updating it for latest ES, un-splitting the type definitions, etc. |
| 15:38 | <Domenic> | Not too crazy about doing that work on a non-CC0 document though |
| 15:42 | <annevk> | Domenic: yeah I've told heycam the same |
| 15:42 | <annevk> | nox: that might be a good reason not to convert to bikeshed, at least not until the licensing situation changes |
| 15:43 | <nox> | Ok. |
| 16:33 | <yoav> | annevk: https://github.com/whatwg/dom/pull/144 |
| 16:49 | <TabAtkins> | Ms2ger: pong |
| 16:50 | <Ms2ger> | TabAtkins, I filed issues instead |
| 16:51 | <TabAtkins> | Ms2ger: Elaborating a bit on the issues would help. ^_^ |
| 16:51 | <TabAtkins> | Like actually describing what problem you're having, and what you'd like me to do. |
| 16:51 | <Ms2ger> | TabAtkins, I started converting WebIDL to use bikeshed, and the first two issues I hit were missing references and missing highlighting for idl code |
| 16:52 | <Ms2ger> | TabAtkins, also, there may be issues with links to ecmascript definitions |
| 16:52 | <TabAtkins> | Okay. Ref requests need to be filed against SpecRef. |
| 16:52 | <Ms2ger> | https://github.com/Ms2ger/webidl/tree/bs is my wip |
| 16:53 | Ms2ger | is about to head out |
| 16:53 | <TabAtkins> | "highlighting for idl code" - is this for IDL definition blocks (<pre class=idl>), or for some other arbitrary IDL code? |
| 16:54 | <Ms2ger> | The "IDL informal syntax examples" bit (which is probably hard), and the "Code blocks" bit at https://heycam.github.io/webidl/#conventions |
| 16:57 | <TabAtkins> | Okay. Hm. So pygments doesn't already have an IDL highlighter? |
| 16:58 | <Ms2ger> | It does, but not for an IDL that expands to Interface Description Language |
| 17:00 | <TabAtkins> | Ah, kk. |
| 17:00 | <TabAtkins> | Hm. To make that work I'd need to write my own lexer/parser then. |
| 17:01 | <Ms2ger> | Oh, and I ignored the grammar things |
| 17:01 | <TabAtkins> | (I already need to write a new lexer/parser for CSS because the Pygments one is total shit, so learning how to do that is on my list already.) |
| 17:01 | <Ms2ger> | Anyway, I'm off for real |
| 17:01 | <TabAtkins> | kk! |
| 17:02 | <Ms2ger> | And thanks! |
| 17:11 | gsnedders | is getting tempted to write another new spec gen tool |
| 17:11 | <gsnedders> | because obviously that's what we need |
| 17:15 | <TabAtkins> | gsnedders: I'll kill you. |
| 17:24 | <tantek> | Specgen Thunderdome! |
| 17:43 | <gsnedders> | TabAtkins: plz no |
| 17:44 | <gsnedders> | TabAtkins: i won't be very helpful to the web community if I'm dead |
| 17:46 | <TabAtkins> | You won't be harmful either. |
| 17:47 | <TabAtkins> | And you won't have to deal with the pain of maintaining compat with Bikeshed's dfn metadata format as it expands. |
| 17:47 | <JoWie> | you might like https://github.com/jsdom/webidl2js |
| 17:54 | <annevk> | Domenic: I missed the commit where you removed event handler scripts and therefore thought the compiled copy was not up-to-date |
| 17:55 | <Domenic> | annevk: ah yeah. those were short lived haha. |
| 17:57 | <Domenic> | Going to be such a pain to fix the bug adam found/spec async... i thought it'd be easy to just piggyback on defer, but no, no free lunch for me |
| 17:57 | <annevk> | Domenic: I also missed that the URL restrictions didn't apply to <script type=module src>, but that makes sense |
| 17:58 | <annevk> | Domenic: he finds the best bugs |
| 17:58 | <Domenic> | annevk: what do you mean URL restrictions didn't apply? |
| 17:59 | <annevk> | Domenic: has to start with ../ / ./ |
| 17:59 | <Domenic> | annevk: ah yeah. |
| 18:07 | <annevk> | Domenic: I wonder if the type attribute requirements are better worded in a different way. E.g., say something along the lines of the script element can be used to specify classic scripts, module scripts, and data blocks. Then say, that if it is a module script, the type attribute must be specified and its value must be an ASCII case-insensitive match for |
| 18:07 | <annevk> | "module". |
| 18:07 | <annevk> | Domenic: currently that's not really required |
| 18:08 | <annevk> | Domenic: same of course for classic scripts and data blocks |
| 18:08 | <Domenic> | annevk: yeah I am not sure on this whole author-facing section; it almost feels like it wants to be split into three subsections (like <input type>) or something |
| 18:09 | <annevk> | Domenic: some of what is done there, such as a table with attribute combination overview, would not be a bad addition |
| 18:09 | <annevk> | Domenic: not sure we need all the complexity of several subsections though |
| 18:10 | <Domenic> | I think it would help. They'd be small subsections, not with their own headers and such. |
| 18:11 | <annevk> | Domenic: I was just about to say that I wouldn't mind a header above script state and prepare script... |
| 18:11 | <Domenic> | Yeah... |
| 18:12 | <Domenic> | "Processing model" perhaps |
| 18:12 | <annevk> | yeah, though mint an ID along with it |
| 18:13 | <annevk> | otherwise all the existing ones get renumbered |
| 18:14 | <Domenic> | haha yes true |
| 22:05 | <dbkaplun> | Hi WHATWG, how can I apply for membership? |
| 23:12 | <caitp> | dbkaplun: I will accept membership requests and financial donations via P.O. box 4967, panama city FL, 32403 |
| 23:12 | <caitp> | care of WHATWG registrar |
| 23:26 | <MikeSmith> | JoWie: https://github.com/jsdom/webidl2js looks pretty cool |
| 23:43 | <MikeSmith> | https://www.talater.com/chrome-is-listening/ "Chrome Bugs Allow Sites to Listen to Your Private Conversations" |
| 23:44 | <MikeSmith> | 「I reported this exploit to Google’s security team in private on September 13 [2014]. By September 19, their engineers have identified the bugs and suggested fixes. On September 24, a patch which fixes the exploit was ready, and three days later my find was nominated for Chromium’s Reward Panel... But then time passed, and the fix didn’t make it to users’ desktops. A month and a half later, I a |
| 23:45 | <MikeSmith> | sked the team why the fix wasn’t released. Their answer was that there was an ongoing discussion within the Standards group, to agree on the correct behaviour - “Nothing is decided yet.” As of today, almost four months after learning about this issue, Google is still waiting for the Standards group to agree on the best course of action, and your browser is still vulnerable.」 |
| 23:45 | <MikeSmith> | I wonder if that's still not been fixed |