| 00:21 | <tantek> | anyone here have any idea why annevk is notable? His notability is being questioned https://en.wikipedia.org/wiki/Anne_van_Kesteren by a user named "Ham Pastrami" (no joke) |
| 00:22 | <TabAtkins> | Where's the notability question? |
| 00:22 | <TabAtkins> | Oh, duh, the warning right at the top of the page. |
| 00:22 | <tantek> | that banner you missed at the top |
| 00:43 | <TabAtkins> | Okay, removed the banner with some justification in edit summary; anne seems to reasonably qualify as notable per the Notability page. |
| 07:02 | <nishu> | does websocket work on port 80 only? or is it for the http handshake and then there is another port used? |
| 07:04 | <ondras> | it works on any port |
| 07:05 | <ondras> | and does not switch ports during the handshake |
| 07:48 | <hsivonen> | annevk: what's the history of the ISO-2022-JP-3 Kana set being part of Web ISO-2022-JP while ISO-2022-JP-1, ISO-2022-JP-2 and the rest of ISO-2022-JP-3 aren't? |
| 07:50 | <annevk> | hsivonen: too long ago |
| 07:50 | <annevk> | hsivonen: I think we dropped parts of ISO-2022 based on other browsers not supporting things, but I'm not entirely sure |
| 07:51 | <annevk> | hsivonen: I guess I could grep the log |
| 07:52 | <annevk> | hsivonen: https://github.com/whatwg/encoding/commit/19b0ebf0e48c3a607ab7623b5b272642dd59d6e7 |
| 07:53 | <annevk> | hsivonen: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26885 discusses an earlier change where we removed parts of it because we only needed those parts for Thunderbird |
| 07:59 | <hsivonen> | annevk: I mean: ESC ( I wasn't part of the RFC and came as part of the *third* round of extensions, so how come browser adopted that one? |
| 07:59 | <hsivonen> | "I" in "ESC ( I" being part of the byte sequence |
| 07:59 | <annevk> | hsivonen: maybe Microsoft shipped it from day 1? |
| 08:00 | <hsivonen> | annevk: OK |
| 08:00 | <annevk> | hsivonen: that sounds like a before-my-time question |
| 08:00 | <hsivonen> | annevk: it is |
| 08:00 | <hsivonen> | annevk: but you might still know, so I asked |
| 08:11 | <hsivonen> | TIL: Erik van der Poel is one of the authors of the ISO-2022-JP RFC |
| 08:11 | <hsivonen> | (I'm assuming the same Erik van der Poel as the one who worked on Gecko i18n in the Netscape days) |
| 08:14 | <annevk> | And is now at Google, suspect that's accurate |
| 09:36 | <zcorpan> | Domenic: in webkit i get this error for const c = document.querySelector("#c").contentWindow; (from multiple globals test in the spec) SyntaxError: Can't create duplicate variable that shadows a global property: 'c' |
| 09:36 | <zcorpan> | Domenic: bug in webkit? |
| 09:57 | hsivonen | is surprised that ISO-2022-JP (the original) can't represent Katakana |
| 09:57 | <hsivonen> | am I missing something? |
| 10:00 | <hsivonen> | looking at what Wikipedia says about Katakana usage, it seems incredible that the encoding for Japanese email couldn't encode the words for "television" or "America" |
| 10:00 | <hsivonen> | what am I missing? |
| 10:00 | <kochi> | hsivonen: I guess you are confused about half-width katakana and full-width katakana |
| 10:01 | <hsivonen> | kochi: ooh! that's it. Thanks. |
| 10:01 | <kochi> | hsivonen: what ISO-2022-JP cannot represent is half-width Katakana, full-width Katakana is included in ISO-2022-JP, IIUC. |
| 10:01 | <hsivonen> | kochi: yeah, that's the situation |
| 10:03 | <kochi> | ISO-2022-JP used to be the canonical encoding for emails (as it uses only 7bits), so half-width Katakana could not be used in such emails. |
| 10:07 | <kochi> | s/canonical encoding for emails/canonical encoding for emails for Japanese usersss/ |
| 10:08 | <kochi> | oops, too many ss |
| 10:11 | <hsivonen> | unfortunately, there is still a lack of consensus on the "used to be" part |
| 10:14 | <annevk> | Really? I thought everyone was agreed on UTF-8 now? |
| 10:14 | <annevk> | What's the holdout? |
| 10:15 | <hsivonen> | annevk: Thunderbird! also, Apple Mail users who install the "Letter Fix" hack that restores the capability to send ISO-2022-JP email. |
| 10:16 | <kochi> | hsivonen: do you mean "it is still"? |
| 10:16 | <hsivonen> | kochi: there are people who argue it is still, yes, despite e.g. Gmail removing the capability to send non-UTF-8 email |
| 10:17 | <annevk> | Ugh |
| 10:17 | <kochi> | hsivonen: isee, I know there used to be such people, but TIL still they are :) |
| 10:19 | <kochi> | If any mailer sends UTF-8 mail without MIME header, that's bad, but if with MIME header, it should be totally fine. |
| 10:20 | <kochi> | Is there any network that passes only 7bits or truncates 8-bit char to 7bit? :) |
| 10:22 | <hsivonen> | as I understand it, that's not the assumed threat |
| 10:23 | <hsivonen> | instead, I gather the assumed problems are 1) email clients on pre-Android/iOS phones and 2) some server-side things that don't look at headers and just assume the body is ISO-2022-JP |
| 10:23 | <hsivonen> | I don't know if either actually still exist |
| 10:27 | <hsivonen> | anyway, if there's a list of email clients (besides Gmail) that 1) are used in Japan and 2) can't be made to send ISO-2022-JP (not even via a hack like Letter Fix), I'd be interested in the list |
| 10:27 | <hsivonen> | (so that I could appeal to the list as evidence that Thunderbird could go UTF-8-only, too) |
| 10:29 | <kochi> | I'm not familiar with email clients of these days, sorry I can't help for that. |
| 10:30 | <kochi> | it is interesting to know there are still ISO-2022-JP email activists |
| 10:30 | <annevk> | hsivonen: does Thunderbird still have a significant userbase? |
| 10:32 | <hsivonen> | annevk: yes |
| 10:36 | <smaug____> | what does "When a node is inert, then the user agent must act as if the node was absent for the purposes of targeting user interaction events" mean? |
| 10:36 | <smaug____> | oh, there is example below |
| 10:36 | <smaug____> | hmm hmm |
| 10:36 | <kochi> | cannot take focus, take key events etc.?? |
| 10:37 | <smaug____> | those are clear, but mouse event handling |
| 10:37 | <smaug____> | it becomes bizarre |
| 10:54 | <smaug____> | inert is nicely very much underdefined |
| 13:28 | <zcorpan> | smaug____: isn't mouse events and hit testing in general underdefined? |
| 13:30 | <annevk> | that's rhetorical, right? |
| 13:39 | <smaug____> | zcorpan: it is. But my comment isn't about that, but whether inert affects to hit testing or just skips some elements in the event path |
| 15:57 | <Domenic> | botie: tell zcorpan yes, bug in webkit (https://bugs.webkit.org/show_bug.cgi?id=159270), although I thought I created a version that works there too, hmm... |
| 15:57 | <botie> | will do |
| 15:57 | <Domenic> | botie, you are inhumanly fast |
| 15:57 | <botie> | OK, Domenic. |
| 16:42 | <botie> | zcorpan, at 2016-06-30 15:57 UTC, Domenic said: yes, bug in webkit (https://bugs.webkit.org/show_bug.cgi?id=159270), although I thought I created a version that works there too, hmm... |
| 19:21 | <smaug____> | TabAtkins: so Worklets in their current form are like Workers with super tiny API (no networking, no communication with the main thread)? |
| 19:22 | <smaug____> | or perhaps ian is here? |
| 19:23 | <smaug____> | I guess main thread can communicate by sending data:, urls as imported scripts |
| 19:23 | <smaug____> | but there is no worklet->main thread communication |
| 19:24 | <smaug____> | are there plans to add some simple postMessage like communication channel? |
| 19:30 | <annevk> | smaug____: I think the idea is for them to be like pure functions |
| 19:32 | <smaug____> | right |
| 19:33 | <smaug____> | and I guess Worklet having possible multiple workletglobals make the communication a bit hard |
| 19:33 | <smaug____> | but mainthread -> worker communication is there via data:, trick, which is a bit ugly |
| 19:34 | <iank___> | Sorry on phone at the moment... but various specs can add worklet to main communication if they need to. |
| 19:34 | <smaug____> | hmm, I'd still assume mainthread -> worklet communication will be needed |
| 19:34 | <smaug____> | perhaps not worklet -> mainthread |
| 19:35 | <iank___> | Depends on the spec. Paint api all the communication is done through the style engine as the functions should be "pure" |
| 19:35 | <iank___> | Adding side channel breaks this. |
| 19:36 | <smaug____> | well, there is already script importing as a mainthread->worklet communication channel |
| 19:37 | <iank___> | Audio folks have communication from a main thread class instance to a specific worklet class instance. So dont need to worry about the multiple globals problem. |
| 19:37 | <iank___> | Yeah that's right. |
| 19:37 | <smaug____> | I would be surprised if that data:, won't be used if there is no other communication channel |
| 19:37 | <smaug____> | for stuff like passing some settings to worklet |
| 19:38 | <iank___> | Right, I'm sure that people will do that but want to discourage that for css related things. :) If that makes sense. |
| 19:40 | <smaug____> | iank___: could you explain how registerPaint is supposed to work |
| 19:40 | <smaug____> | it is not clear from the spec yet |
| 19:41 | <smaug____> | one registers some callback |
| 19:41 | <smaug____> | which is just a function |
| 19:41 | <smaug____> | but then there is the comment "Note: This is how the class should look. " |
| 19:43 | <smaug____> | https://drafts.css-houdini.org/css-paint-api-1/#dom-paintworkletglobalscope-registerpaint seems to use some ecma stuff when it really should just rely on webidl. Like, couldn't registerPaint take PaintClass as the second param? |
| 19:43 | <iank___> | Yeah can you give me 15 mins? |
| 19:43 | <smaug____> | sure |
| 19:56 | <iank___> | back! Yeah I need to fix the spec to convert a bunch of the things to WebIDL types. But basically it registers a class. E.g. |
| 19:56 | <iank___> | https://github.com/GoogleChrome/houdini-samples/blob/master/paint-worklet/circle/paintworklet.js#L17 |
| 19:57 | <iank___> | the engine is responsible for creating an instance of the class, then invoking it to generate images. |
| 19:58 | <iank___> | It's possible for the engine to kill the PaintWorkletGlobalScopes if a window/tab is backgrounded for example to reclaim memory, and restarted if foregrounded again. |
| 20:47 | <smaug____> | iank___: why engine needs to create instance? |
| 20:48 | <smaug____> | I mean, why isn't a callback interface instance passed to registerPaint ? |
| 20:50 | <smaug____> | (I don't understand how killing PaintWorkletGlobalScopes is related to this. paintCtor can be created dynamically, so it might not be available after restarting the worklet) |
| 20:51 | <TabAtkins> | annevk or Domenic: Can one of y'all comment on https://github.com/w3c/svgwg/issues/181 and tell them to not add any more camelCase names to SVG? |
| 20:52 | <smaug____> | hmm, so the spec uses a callback registration mechanism no other API in the web platform is using |
| 20:52 | <Domenic> | smaug____: is this about custom elements? I just fixed that... |
| 20:52 | <Domenic> | smaug____: oh you're talking about paint |
| 20:52 | <smaug____> | Domenic: this is about PaintWorkletGlobalScope |
| 20:53 | <Domenic> | smaug____: I think they were copying custom elements and will fix it soon |
| 20:53 | <smaug____> | aha |
| 20:53 | <smaug____> | yeah, this looks rather weird currently |
| 20:53 | <smaug____> | maybe there is some good reason, but don't know what that is |
| 20:53 | <Domenic> | that said, I think if your complaint is registering a class instead of registering a callback, that likely won't change... |
| 20:56 | <smaug____> | Domenic: I'm just complaining it being unusual and spec using ecma terminology and not easily understandable webidl |
| 20:56 | <smaug____> | Domenic: I'd expect callback to be an instance of a class |
| 20:56 | <smaug____> | not a class itself |
| 20:56 | <Domenic> | that's not the intent of this API |
| 20:57 | <Domenic> | The intent is to allow you to register a constructor which is called later |
| 20:57 | <Domenic> | similar to custom elements |
| 20:57 | <smaug____> | why? |
| 20:57 | <smaug____> | in this case |
| 20:57 | <Domenic> | So that it can be created repeatedly |
| 20:58 | <smaug____> | what can be created repeatedly? |
| 20:58 | <smaug____> | or why you need to create anything repeatedly? |
| 20:58 | <Domenic> | Because worklets are created and destroyed often, and each time you need to create a new paint thingy, is my understanding |
| 20:59 | <Domenic> | I guess I'll let iank___ take back over if it's just questions of "how is this API intended to be used" |
| 20:59 | <smaug____> | but when you create workletglobalscope again, you don't know whether you still have the same classes available |
| 20:59 | <TabAtkins> | One of the ways we intend to enforce "this should be a pure function" (without having to go whole-hog and define brand-new concepts of a frozen environment or something) is to kill and restart things somewhat arbitrarily. |
| 21:00 | <TabAtkins> | So if you do rely on a long-lived thing thru multiple invocations, you'll have a bad time. |
| 21:00 | <smaug____> | yes. And I don't understand how the class approach helps with that |
| 21:07 | <TabAtkins> | Oh, I have no comment on that. Please open issues and comment if you have problems with any particular in the approach; we've been dying trying to get other people to review this stuff in depth. |
| 21:22 | <iank___> | Right, it's pretty non-obvious why we did it like that for the current API. This is mainly for future stuff we want to be able to do. |
| 21:23 | <smaug____> | iank___: what kind of future stuff you have in mind? |
| 21:23 | <iank___> | Bascially consider the use-case where the author wants to pre-generate a bunch of images; and you have the ability to create additional PaintRenderingContext2D's for example. |
| 21:23 | <iank___> | e.g. (sorry typing). |
| 21:24 | <iank___> | registerPaint('foo', class { constructor { this.frameN = new PaintRenderingContext2d(100, 100) /* bunch of pre-initialization */ } |
| 21:24 | <iank___> | paint(ctx, geom, styleMap) { if (something) { ctx.drawImage(this.frameN); } } |
| 21:25 | <iank___> | we cut a bunch of things from v1 paint api, but you're right the current API could just be registerPaint('foo', callbackFn) |
| 21:26 | <iank___> | layout api will have a lot more of these things that you'll want to cache on the class instance. |
| 21:26 | <smaug____> | hmm, I didn't understand that example |
| 21:26 | <smaug____> | this.frameN is just set once |
| 21:26 | <smaug____> | I assume |
| 21:27 | <smaug____> | or is registerPaint such that each time paint will be called, a new instance of the class is created? |
| 21:28 | <smaug____> | (that would be rather garbage heavy) |
| 21:28 | <iank___> | yeah this.frameN is just set once, ("frameN" may have been a bad name, just pretend its a heavyweight image that you want to cache). instance of class is re-used across paint method invocations. |
| 21:29 | <smaug____> | right. So all that could be done just by passing an callback interface object, no? |
| 21:29 | <smaug____> | why the need to pass ctor |
| 21:30 | <smaug____> | (I could totally miss something here. This is just all very unique to the platform (well, custom elements apparently has something similar, but it has some reasons for being unusual )) |
| 21:32 | <iank___> | Here is an example with layout: https://gist.github.com/bfgeek/a4ca5e42f7e379c2b4009ca71e6ae296 |
| 21:33 | <iank___> | layout example shows more clearly why you'd want this cache-on-class behaviour. |
| 21:35 | <smaug____> | you cache on the instance of the class |
| 21:42 | <iank___> | yup that's right. (sorry 2 ticks) |
| 21:44 | <smaug____> | so, why the need for class here. |
| 21:44 | <smaug____> | and not an instance of such |
| 21:52 | <iank___> | gives explicit control to the engine for what instances actually need to be created. |
| 21:52 | <iank___> | for example if the author is doing a large amount of work in the constructor, and that paint-image-function is never used. |
| 21:52 | <iank___> | with the class based approach authors can put large amounts of initialization code on the ctor, and it's only called if actually needed. |
| 21:53 | <iank___> | / or when it is needed. |
| 21:54 | <smaug____> | well, often that kind of stuff is cached when the heavy operation is first time called |
| 21:54 | <smaug____> | so, the first paint() call could do the caching |
| 21:54 | <smaug____> | it isn't any different than doing caching in constructor and then using it paint() which is first time called right after paint() |
| 21:56 | <smaug____> | the class approach would make sense if we'd expect multiple instances for some reason, but looks like that isn't the case. |
| 21:56 | <iank___> | you are right, but i kinda disagree because the engine can potentially schedule constructor in an idle period ahead of the callback. |
| 21:57 | <iank___> | right, so again this makes a lot more sense for layout at the moment b/c we stripped so much from paint ^-^ |
| 21:59 | <iank___> | we were debating if for paint we'd have an instance per set of paint arguments. e.g. |
| 21:59 | <iank___> | background-image: paint(chat-bubble, round); |
| 21:59 | <iank___> | background-image: paint(chat-bubble, bevel); |
| 21:59 | <iank___> | (^ different instances). |
| 21:59 | <iank___> | but really not sure yet. |
| 21:59 | <smaug____> | ok, the paint spec doesn't hint anyhow that it is ok for UA to run steps in "draw a paint image" asynchronously |
| 21:59 | <iank___> | i'll file an issue for that. |
| 22:00 | <smaug____> | this class thing just seem to mostly make the spec more complicated than it needs to be |
| 22:01 | <smaug____> | and not really giving anything. |
| 22:01 | <smaug____> | callback interface would be simpler. |
| 22:01 | <smaug____> | but perhaps I'm missing something here |
| 22:07 | <iank___> | for paint you are right that it is more complex spec wise but it gives us a few things in my mind; (1) future-proofing for additional methods on the class (2) consistency with other houdini spec's which will rely on the class based things very heavily (3) explicit signalling for when to create cached things. |
| 22:09 | <Domenic> | Hmm, according to Chrome's IDL at least, the HTMLDocument/XMLDocument/Document merger looks closer than I thought it would |
| 22:13 | <smaug____> | iank___: why other houdini specs will rely on class based setup? |
| 22:14 | <iank___> | for layout you'll have an instance per Node in the tree for example. |
| 22:14 | <smaug____> | and I don't understand (1) at all :) and there is no explicit signalling when to create cached things. Right now it happens during the same event loop spin as paint(), so caching in constructor would be rather bad. caching should happen earlier |
| 22:14 | <smaug____> | iank___: ahaa |
| 22:14 | <iank___> | \o/ |
| 22:15 | <smaug____> | ok, if so, that would be a good reason. |
| 22:15 | <smaug____> | it wasn't clear from worklet or paint specs |
| 22:15 | <smaug____> | and I don't know where the layout spec lives |
| 22:16 | smaug____ | searches |
| 22:16 | <iank___> | https://github.com/w3c/css-houdini-drafts/tree/master/css-layout-api |
| 22:16 | <iank___> | ^ has the best information at the moment. |
| 22:16 | <iank___> | but it's patchy. |
| 22:16 | <iank___> | I'm going to do a rev of the layout api in the next few weeks |
| 22:17 | <iank___> | it's 5x more complex than paint as so many new concepts that we haven't exposed previously. |
| 22:17 | <iank___> | but would love feedback on it. |
| 22:17 | <iank___> | if you'll be at TPAC we'll be spending a bunch of time on it. |
| 22:18 | <smaug____> | I'm trying to stay away from css/layout stuff ;) but worklet is also an API so need to understand why and what we might implement in Gecko |
| 22:20 | <smaug____> | but yes, I'm planning to be at TPAC |
| 22:20 | <iank___> | cool, yeah we tried to make it as simple as possible and allow engines to experiment with a bunch of things if they like, so if you have any suggestions feel free to reach out. |
| 22:23 | <iank___> | in blink we've currently just got a main thread impl of worklets, and at the moment working on an audio thread for the webaudio api. |
| 22:23 | <smaug____> | will you reuse worket implementation for worklets |
| 22:23 | <smaug____> | or are workers in blink too heavy for this? |
| 22:24 | <smaug____> | s/worket/worker/ |
| 22:25 | <Domenic> | new WebSocket(relativeURL) is supposed to work, right? |
| 22:25 | <iank___> | yeah we basically are extracting a bunch of common infrastructure out (global initialization, etc) so they share quite a lot of code. |
| 22:26 | <iank___> | the "heavy" part comes from that each script has to have a new global, which we don't have for worklets. |
| 22:26 | <iank___> | i think we are at ~100k for an empty v8 global memory wise. |
| 22:28 | <smaug____> | ah, I was thinking importing scripts similar to importing scripts inside workers, where the same global is reused of course |
| 22:28 | <smaug____> | but yeah, global creation is rather heavy |
| 22:29 | <Domenic> | holy shit new WebSocket("relative-url") does not work |
| 22:29 | <Domenic> | oh I guess that's predicatable since it has to start with ws:// |
| 23:04 | <iank___> | smaug____: yeah that's basically how we've implemented it. |
| 23:05 | <iank___> | we aren't doing any of the "load like a module yet" but will once the v8 team implements. |