| 00:17 | <zewt> | are there any html parsers for python that are actually reliable? been using html5lib but apparently it throws exceptions on some escapes, and the bug has been open for over three years, which tells me i should be looking for a new library... |
| 00:45 | <MikeSmith> | zewt: you have a link to that open html5lib issue? |
| 00:46 | <MikeSmith> | anyway, why not just use the default lxml html parser? |
| 00:47 | <MikeSmith> | it seems to work pretty well, even though it’s not completely conformant to the HTML parsing algorithm (and doesn’t claim to be) |
| 00:47 | <MikeSmith> | WebIDL question: does required DOMString foo mean an instance of foo can be the empty string? |
| 00:50 | <gsnedders> | zewt: the bug with the lxml treebuilder and non-XML-respresentable trees? I wish it were easier to fix. :( |
| 00:51 | <gsnedders> | (the narrow/wide split of Python 2 makes it absolutely horrible to fix…) |
| 00:51 | <gsnedders> | (I guess we could just do some really ugly hack for element names on narrow builds, but that doesn't entirely fix the issue) |
| 00:55 | <MikeSmith> | is there actually some way in WebIDL to explicitely specify that something must be non-empty? |
| 00:56 | <zewt> | https://github.com/html5lib/html5lib-python/issues/96 |
| 00:57 | <gsnedders> | zewt: yeah, that's the one |
| 01:00 | <jyasskin> | MikeSmith: "required" just means it must be present (in JS, "not undefined"). "" is a valid DOMString, so it's allowed in required dictionary elements. |
| 01:00 | <MikeSmith> | jyasskin: OK that’s what I thought, thanks |
| 01:01 | <jyasskin> | MikeSmith: WebIDL doesn't have a way to express constraints on the valid values in a field. In Bluetooth, I did it with https://webbluetoothcg.github.io/web-bluetooth/#uuids, but I also said what exception to throw in prose everywhere that uses a UUID. |
| 01:01 | <jyasskin> | The best fields are "required Type?": you can have null, but undefined is right out! ;-) |
| 01:02 | <MikeSmith> | oh |
| 01:02 | <MikeSmith> | then I guess that is what we may need to do more of in the Payment Request API spec where needed |
| 01:03 | <jyasskin> | But I picked SyntaxError in WebBT, which I think is wrong, so don't copy that part. ;) |
| 01:03 | <MikeSmith> | I am looking at https://bugs.chromium.org/p/chromium/issues/detail?id=636723 where Rouslan has “Accept any non-empty string” as the isssue title, but the Payment Request spec says nothing explicitly about it needing to be non-empty |
| 01:04 | <MikeSmith> | https://w3c.github.io/browser-payment-api/#paymentcurrencyamount |
| 01:06 | <jyasskin> | MikeSmith: I also note "MUST"s being applied to dictionary fields that are passed from user code to interface operations. You can't "MUST" a website; you have to instead say what happens when they do something you disapprove of. |
| 01:07 | <jyasskin> | It's possible the spec already does that; the MUSTs just triggered my reflexes. |
| 01:13 | <MikeSmith> | jyasskin: yeah me too. Those MUSTs should not be there, and I am actually right now at this moment writing a PR to change them to just (non-normative) “The following fields are required” |
| 01:13 | <jyasskin> | Woot |
| 01:14 | <MikeSmith> | but there are still some other places in the spec where it does not actually normatively specify what a UA should do with “invalid” instances of something |
| 01:14 | <MikeSmith> | see https://github.com/w3c/browser-payment-api/issues/235 |
| 01:15 | <MikeSmith> | https://w3c.github.io/browser-payment-api/#dfn-value |
| 01:15 | <jyasskin> | Indeed. My apologies for assuming you were responsible for the current spec text. :) |
| 01:15 | <MikeSmith> | heh |
| 01:16 | <MikeSmith> | you can blame Zach Koch :) |
| 01:16 | <MikeSmith> | anyway it is a very good spec overall |
| 01:16 | <MikeSmith> | I just ran into these misses when reviewing test cases |
| 01:42 | <zewt> | don't care about how control characters are parsed (it's junk anyway), just want it to not suddenly throw errors while parsing |
| 02:26 | <astearns> | there's a few "authors must" in the CSS specs. I suppose they should change to "authors ought to" |
| 02:26 | <zewt> | "wouldn't it be nice if authors would" |
| 02:27 | <astearns> | "I'd like imagine that authors would" |
| 02:28 | <variable> | astearns: "if people read the spec and cared about what it said, they would" |
| 02:28 | <zewt> | why don't we just stop fantasizing and go with "authors don't" |
| 02:35 | <MikeSmith> | astearns: there are some “authors must” and even “documents must” requirements in the HTML, but those are not ambiguous because the HTML spec defines an explicit “conforming documents” conformance class |
| 02:35 | <MikeSmith> | https://html.spec.whatwg.org/multipage/infrastructure.html#conforming-documents |
| 02:36 | <MikeSmith> | though we still have cases of implementors reading the spec and thinking those are meant to somehow be requirements for UAs |
| 02:37 | <MikeSmith> | I think there is a good argument to be made for not trying to specify both kinds of requirements in the same spec |
| 02:38 | <MikeSmith> | in other words, not trying to have a spec that attempts to be both for UA implementors and authors |
| 02:38 | <MikeSmith> | because in the end it just ends up being confusing for both implementors and authors |
| 02:39 | <MikeSmith> | and really in the case of the HTML spec, it’s a spec friendly for implementors in its style and content and not really friendly to authors |
| 02:40 | <MikeSmith> | I think most authors have no business trying to read the HTML spec |
| 02:40 | <MikeSmith> | or maybe we have no business continuing to imply that authors should |
| 02:42 | <MikeSmith> | I think there is a good argument to be made for a normative spec for document-conformance requirements that is written from the ground up with authors in mind |
| 02:42 | <MikeSmith> | a separate spec |
| 02:42 | <MikeSmith> | rather than what we have for authors now, which is stuff basically bolted onto the implementor spec |
| 02:43 | <variable> | MikeSmith: for the most part authors want tutorial like information, not spec like information, AFAICT |
| 02:43 | <MikeSmith> | and that bolted-on stuff is distracting and sometimes confusing to authors |
| 02:44 | <MikeSmith> | variable: right but we still need to have the normative requirements for authors defined somewhere |
| 02:45 | <caitp> | what if spec text could be both normative and accurate, and also accessible |
| 02:45 | <MikeSmith> | I really prefer the way that annevk writes specs, which are spare and clearly written for implementors only, in a way that they can implement from without distraction |
| 02:45 | <MikeSmith> | caitp: would that it could |
| 02:45 | <MikeSmith> | I think it cannot |
| 02:46 | <MikeSmith> | that is why I like annevk’s approach more |
| 02:46 | <howdoi> | would you have a div in a section or a section in a div or just use sections? |
| 02:46 | <variable> | howdoi: depends on what semantics you want |
| 02:47 | <howdoi> | From the spec, Note: The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline. |
| 02:47 | <MikeSmith> | to me annevk’s style does not attempt to be particularly accessible to non-implementors, and that is a feature |
| 02:47 | <variable> | howdoi: you should use <section> if you care about it from an outlining PoV |
| 02:47 | <variable> | tbh outlining is not commonly used |
| 02:47 | <MikeSmith> | others who understand the specs can write guides at MDN and places that accessible to authors, and optimized for authors |
| 02:47 | <variable> | MikeSmith: I think that is a reasonable approach |
| 02:48 | <howdoi> | variable: outlining is a pretty confusing term. |
| 02:48 | <MikeSmith> | howdoi: personally I think I would just not use section at all |
| 02:48 | <variable> | howdoi: the short version is: if you think it should live in a "table of contents" |
| 02:48 | <variable> | but MikeSmith's suggestion is reasonable |
| 02:48 | <MikeSmith> | at this point IMHO there are no real benefits in practice to using section, nor article |
| 02:49 | <variable> | since outlining is basically dead :( |
| 02:49 | <MikeSmith> | yeah |
| 02:49 | <howdoi> | just the readability? |
| 02:50 | <howdoi> | The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading. 🤔 😁 |
| 02:50 | <MikeSmith> | I implemented the outline algorithm in the HTML checker (validator) but I personally think authors are better of ignoring the outline algorithm and just using h1-h6 without section or even without div unless the div is needed for some other reason |
| 02:51 | <variable> | howdoi: this is the conversation that MikeSmith and I are basically having: the spec isn't great for people like you, authors |
| 02:51 | <howdoi> | variable: collusion of thoughts, it's a small world! |
| 02:51 | <variable> | MikeSmith: I wish that assistive devices were capable of using the outlining stuff, and that authors (or more accurately, framework authors) would care about this stuff |
| 02:52 | <howdoi> | we must start a session on how to read the spec |
| 02:52 | <variable> | but if the semantic web has taught us anything, its that people will not manually do stuff, ever |
| 02:52 | <howdoi> | later, how to submit a spec and convince the board :D |
| 02:52 | <howdoi> | strongly agree there. |
| 02:53 | howdoi | basically no one give a $hit about semantics, until it's affecting their page rank or something similar :( |
| 02:53 | <MikeSmith> | variable: yeah for AT software to use the outline stuff, browsers would first need to implement the requirements in the spec about actually exposing the outline in the right way to a11y APIs. Which browsers don’t, so there’s not much that AT software can do in the mean time |
| 02:55 | <MikeSmith> | but that said the JAWS vendor at least never implements anything unless they absolutely have to |
| 02:55 | <MikeSmith> | case in point is language detection |
| 02:55 | <MikeSmith> | language detection is something cheap and easy to implement |
| 02:56 | <howdoi> | maybe off-topic: If you were to do a simple PWA introduction to a crowd, say a workshop, what app would you do? |
| 02:56 | <MikeSmith> | and it would be of real benefit for JAWS users to have built-in language-detection support |
| 02:56 | <MikeSmith> | but as far as I know, JAWS has no such support |
| 02:57 | <MikeSmith> | howdoi: Ilya Grigorik’s O’Reilly book |
| 02:57 | <howdoi> | MikeSmith: https://hpbn.co/? |
| 02:58 | <MikeSmith> | yeah |
| 02:58 | <MikeSmith> | works offline |
| 02:58 | <howdoi> | that's already a PWA |
| 02:58 | <MikeSmith> | automatically |
| 02:58 | <howdoi> | you mean to say, build something like that? |
| 02:58 | <MikeSmith> | oh I guess I misunderstood your quesiton |
| 02:59 | <howdoi> | Say, you were asked to do a workshop on PWA, what would you build there? |
| 02:59 | <MikeSmith> | a book I guess |
| 02:59 | <howdoi> | please don't say a weather app :D |
| 02:59 | <MikeSmith> | it is the simplest case |
| 02:59 | <MikeSmith> | book with images |
| 02:59 | <howdoi> | okies, I was planning for flickr images |
| 02:59 | <howdoi> | or maybe XKCD |
| 02:59 | <howdoi> | and some videos |
| 02:59 | <MikeSmith> | yeah |
| 02:59 | <howdoi> | not sure if I need to cover push notifications and background sync. |
| 03:00 | <MikeSmith> | yeah that would make it a lot more complicated |
| 03:00 | <variable> | MikeSmith: reminds of the html fixer |
| 03:00 | <howdoi> | okies, will ditch them then, thanks for the feedback :) |
| 03:00 | <variable> | it takes arbitrary input and produces valid HTML as output |
| 03:00 | <variable> | "rm" |
| 03:01 | <MikeSmith> | variable: not http://www.htmlfixer.com/ I guess |
| 03:02 | <variable> | MikeSmith: no, its a unix tool |
| 03:02 | <variable> | "rm" |
| 03:03 | <MikeSmith> | ah I know rm of course but I guess I’m not getting the joke |
| 03:03 | <variable> | MikeSmith: the joke is that rm will correctly produce an empty document |
| 03:03 | <variable> | which is valid HTML |
| 03:03 | <MikeSmith> | ah OK |
| 03:04 | <MikeSmith> | seems like that would be more like touch(1) |
| 03:04 | <caitp> | usually that would result in a 404, which in your typical user agent would produce results inconsistent with the "document" |
| 05:21 | <rniwa> | annevk: hello |
| 05:41 | <annevk> | rniwa: heya, how are things? |
| 05:41 | <rniwa> | annevk: coming back to custom elements |
| 05:41 | <rniwa> | annevk: I have one question for you |
| 05:41 | <annevk> | rniwa: hope you left the office |
| 05:41 | <rniwa> | annevk: the namespace is supposed to be null |
| 05:41 | <rniwa> | annevk: by default, right? |
| 05:41 | <rniwa> | annevk: not empty string |
| 05:41 | <rniwa> | annevk: this is kind of relevant in terms of attributeChangedCallback |
| 05:41 | <annevk> | rniwa: for attributes? |
| 05:42 | <rniwa> | annevk: because it adds the namespace URI as the last argument |
| 05:42 | <rniwa> | annevk: yeah |
| 05:43 | <annevk> | rniwa: hmm I guess, mostly a legacy accident but all other APIs behave that way, right? |
| 05:43 | <rniwa> | annevk: https://gist.github.com/rniwa/a2b010863e8e6f111d540f29c7d45086 |
| 05:43 | <rniwa> | annevk: because attributeChangedCallback puts the namespace URI into an argument |
| 05:43 | <rniwa> | annevk: it makes this somewhat internal implementation detail of the spec exposed |
| 05:43 | <rniwa> | annevk: all existing APIs such as getAttribute has "?" qualifier |
| 05:44 | <rniwa> | annevk: so that makes the null-ness of namespace URI kind of irrelevant but this API would expose it. |
| 05:44 | <annevk> | rniwa: it should match mutation observers, can look up in 20 what that is |
| 05:46 | <rniwa> | annevk: that's a good point |
| 05:47 | <rniwa> | annevk: we DO use null in that case |
| 05:53 | <annevk> | rniwa: so yeah, https://dom.spec.whatwg.org/#concept-element-attributes-change does exactly the same for mutation observers and custom elements |
| 05:53 | <rniwa> | annevk: yeah |
| 05:53 | <rniwa> | annevk: cool |
| 05:53 | <rniwa> | annevk: it looks like this is just a bug in Chrome's implementation |
| 05:53 | <annevk> | rniwa: and https://dom.spec.whatwg.org/#dom-attr-namespaceuri returns that field literally too so I think we're good |
| 05:53 | <rniwa> | annevk: ah, okay |
| 05:53 | <annevk> | Oh Chrome does empty string? Geez... |
| 05:53 | <rniwa> | annevk: yeah |
| 05:54 | <rniwa> | annevk: well, null / empty string different is somewhat subtle due to historical nullability/undefined implicit coercion :( |
| 05:54 | <rniwa> | annevk: cdumez has been doing an amazing job updating our impl |
| 05:54 | <annevk> | Yeah, this should never have allowed null |
| 05:54 | <rniwa> | annevk: but there is a lot of crazy edge cases in WebIDL around that area |
| 05:55 | <annevk> | cdumez is great |
| 05:57 | <rniwa> | yeah |
| 06:03 | <rniwa> | sigh... our impl. of sequence conversion is completely busted :( |
| 06:04 | <annevk> | the finer details of sequences are hard due to all the subtle hooks in ECMAScript |
| 06:05 | <annevk> | bz explained it to me once and I promptly forgot 😟 |
| 06:06 | <rniwa> | annevk: it's not as bad as all the things Proxy can do |
| 06:07 | <rniwa> | annevk: e.g. you can trap `Get(constructor, "prototype")` with Proxy |
| 06:07 | <annevk> | I'm still a bit mystified as to why we have those |
| 06:07 | <rniwa> | annevk: and create an infinitely recursive prototype chain :( |
| 06:07 | <rniwa> | annevk: the part that sucks most about Proxy is that you can't do it per property |
| 06:07 | <rniwa> | annevk: so all bets are off for optimizations :( |
| 06:08 | <annevk> | I really hope the only justification wasn't just to explain the hooks a browser is using to implement some HTML features |
| 06:09 | <rniwa> | annevk: which is still strictly less worse than https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/isConcatSpreadable |
| 06:10 | <rniwa> | one of my colleagues spent one entire month optimizing this feature to not regress the perf in regular case :( |
| 06:10 | <rniwa> | I literally can't think of a situation in which one would want to use this feature instead of simply calling push... |
| 06:17 | <annevk> | That TC39 doesn't let itself influence by performance concerns is rather frustrating |
| 06:17 | <annevk> | But one thing Apple could help with is sending people to those meetings (I know they can be dull) and object to these kind of things |
| 06:18 | <rniwa> | annevk: oh i think we've been sending people to every TC39 meeting these days |
| 06:18 | <annevk> | Implementers seem somewhat underrepresented at times |
| 06:18 | <annevk> | Ah good |
| 06:18 | <annevk> | And yeah, this happend a while ago, as did freeze() et al |
| 06:21 | <rniwa> | annevk: yeah |
| 06:21 | <rniwa> | annevk: ES6 is quite a massive latency regression for us so we had to spend a lot of time optimizing various parts of the engine |
| 06:42 | <hsivonen> | I need a demo string that encodes without unmappables into a legacy multibyte encoding. Does anyone happen to know what's used in programming examples in Chinese, Japanese or Korean where "Hello, World!" is used in English? |
| 06:46 | <hsivonen> | Wikipedia suggests ハロー・ワールド in Japanese. Unclear if idiomatic. |
| 06:46 | <hsivonen> | I suppose that's good enough |
| 06:49 | <hsivonen> | oh. it looks like that's a phonetic rendering of English |
| 07:57 | <zewt> | hsivonen: phonetic renderings of English seems like exactly what the japanese would use |
| 08:38 | <hsivonen> | zewt: ok |
| 08:50 | <MikeSmith> | hsivonen: yeah for Japanese what zewt said I think though all examples in https://ja.wikipedia.org/wiki/Hello_worldプログラムの一覧 just use literal latin “Hello world” |
| 08:51 | <MikeSmith> | hmm except for https://ja.wikipedia.org/wiki/Hello_worldプログラムの一覧#KQ |
| 08:52 | <MikeSmith> | I wonder what KQ is |
| 08:52 | <MikeSmith> | oh man |
| 08:52 | <MikeSmith> | https://github.com/fumieval/LazyKQ |
| 08:52 | <MikeSmith> | that is pretty cool |
| 08:56 | <MikeSmith> | man the obnoxious of that is brilliant |
| 08:57 | <MikeSmith> | I will never again say that half-width katakana is useless |
| 08:59 | <MikeSmith> | botie, inform rniwa hey somebody finally found an appropriate use for half-width katakana https://github.com/fumieval/LazyKQ |
| 08:59 | <botie> | will do |
| 09:19 | <zewt> | as far as i can tell the main use of halfwidth katakana is to make my IME have an extra state to toggle through |
| 09:34 | <MikeSmith> | heh |
| 09:34 | <MikeSmith> | yup |
| 09:34 | <foolip> | annevk: how do I "sync html" in whatwg/xref? |
| 09:34 | <foolip> | the html.py script takes a while and does nothing |
| 09:35 | <annevk> | foolip: you need to manually add entries to html.json |
| 09:35 | <foolip> | how many specs are still using this? it's not great :) |
| 09:35 | <annevk> | foolip: it's sad |
| 09:35 | <annevk> | foolip: only anolis, they need to become bikeshed at some point |
| 09:35 | <foolip> | I assume you'd be happy to merge a bikeshed PR for fullscreen? |
| 09:35 | <annevk> | foolip: I'm mostly putting it off since it's a lot of work and the regressions from last couple of times haven't been great |
| 09:36 | <annevk> | foolip: yeah |
| 09:36 | <MikeSmith> | zewt: for the iPhone Apple dropped support for halfwidth katakana input in the IME a few years ago but then subsequently had to add it back |
| 09:36 | <foolip> | which others are still left on anolis? |
| 09:36 | <annevk> | foolip: Fetch, XHR I guess |
| 09:36 | <foolip> | mkay |
| 09:36 | <foolip> | oh well, not today |
| 09:36 | <foolip> | I can just push directly to xref I guess? |
| 09:37 | <annevk> | foolip: yeah |
| 09:38 | <foolip> | annevk: enjoy https://github.com/w3c/permissions/issues/121 |
| 09:38 | <foolip> | bah, not that one |
| 09:38 | <foolip> | https://github.com/whatwg/fullscreen/pull/46 |
| 09:39 | <annevk> | ta |
| 09:39 | <foolip> | I couldn't figure out the line wrapping rules so I went with inconsistent :) |
| 09:42 | <annevk> | Oh, I should have looked at that more carefully, oh well |
| 09:42 | <annevk> | We can fix that when we bikeshed it |
| 09:42 | <annevk> | Or rather, after |
| 09:43 | <annevk> | Best not to change line endings as part of the conversion as it'll make review too hard |
| 09:47 | <foolip> | I use git diff --word-diff -w a lot when reviewing spec changes because never changing line wrapping is hard |
| 09:58 | <MikeSmith> | oh wow |
| 09:58 | <MikeSmith> | I never heard of --word-diff |
| 09:58 | <MikeSmith> | this is great |
| 10:04 | <annevk> | https://github.com/w3c/webpayments-method-identifiers/issues/9 is all kinds of horrible |
| 10:04 | <annevk> | Payments WG is basically in back in the dark ages with nothing learned about anything |
| 10:07 | <annevk> | "I'll just fix @annevk" |
| 10:18 | <wilsonpage> | Domenic ping |
| 10:37 | <smaug____> | interesting. Chrome uses HTMLDocument for svg images |
| 10:38 | <smaug____> | but if one uses document.write for example, the document goes into some odd state without element |
| 10:38 | <smaug____> | s |
| 10:49 | <MikeSmith> | annevk: sorry to have roped you into that payments URL nonsense |
| 10:50 | <MikeSmith> | anyway I think the actual browser Payment Request API spec is a quite good spec |
| 10:51 | <MikeSmith> | it is the only thing that’s actually implemented at this point so the rest of that stuff is not really affecting anything anyway |
| 11:55 | <mathiasbynens> | annevk: can you make javascript.spec.whatwg.org 301 to https://github.com/tc39/ecma262/labels/web%20reality? I can set up a <meta>/JS-based redirect for now, but hey… |
| 12:20 | <annevk> | mathiasbynens: done |
| 12:35 | <mathiasbynens> | annevk: thanks! and woohoo |
| 12:40 | <MikeSmith> | http://stackoverflow.com/questions/38917631/why-is-it-impossible-to-gather-parent-window-location-from-iframe-when-different |
| 12:44 | <MikeSmith> | if the WebIDL for some field in a dictionary defines it as DOMString and my script sets it to null or undefined, then per WebIDL, the UA should throw? |
| 12:45 | <MikeSmith> | lacking the [TreatNullAsEmpty] annotation (or whatever teh exact name is) |
| 12:48 | <annevk> | youennf made really great Fetch tests |
| 12:48 | <annevk> | MikeSmith: required DOMString or just DOMString? |
| 12:49 | <annevk> | MikeSmith: either way, null should turn into "null" I think |
| 12:49 | <MikeSmith> | annevk: required DOMString |
| 12:49 | <annevk> | MikeSmith: then undefined should throw |
| 12:49 | <MikeSmith> | annevk: OK but then null should not? |
| 12:49 | <annevk> | MikeSmith: null should stringify |
| 12:49 | <MikeSmith> | or you mean it turns into the string "null"? |
| 12:49 | <MikeSmith> | hai |
| 12:49 | <annevk> | hai |
| 12:50 | <MikeSmith> | thanks |
| 12:50 | <annevk> | We use hai here at home all the time, such a great word |
| 12:50 | <MikeSmith> | haha |
| 12:50 | <MikeSmith> | yeah it’s pretty useful |
| 12:50 | <zcorpan> | mathiasbynens: \o/ |
| 13:01 | <Domenic> | mathiasbynens: you should write a blog post for blog.whatwg.org about sunsetting the JavaScript Standard! It's a fun success story. |
| 13:02 | <mathiasbynens> | Domenic: sounds fun, I’ll write something up next week! |
| 13:06 | <bradleymeck> | uggg please no more drama |
| 13:08 | <annevk> | ? |
| 13:10 | <bradleymeck> | annevk: was referring to the idea of making a blog post about bugs w/ JS spec |
| 13:10 | <Domenic> | ??? |
| 13:10 | <Domenic> | who suggested that? |
| 13:11 | <bradleymeck> | "mathiasbynens: you should write a blog post for blog.whatwg.org about sunsetting the JavaScript Standard! It's a fun success story." must have misread? |
| 13:11 | <annevk> | Yeah, I think you did |
| 13:11 | <bradleymeck> | then I am confused, w/e |
| 13:13 | <bradleymeck> | don't see how it could be read diff w/ scrollback though |
| 13:15 | <Domenic> | We're talking about https://github.com/whatwg/javascript/issues/29. You appear to be talking about a completely separate topic, bugs in ECMA262? |
| 13:16 | <bradleymeck> | yea, diff standard |
| 13:17 | <bradleymeck> | thx for the link, was very confused |
| 13:52 | <zcorpan> | dang I was for a moment looking forward to some JS drama :-) |
| 14:29 | <wanderview> | JakeA: annevk: have we considered exposing self.clients Clients interface on window or other workers? except for claim() it seems like it would work just as well from those globals |
| 14:30 | <JakeA> | "controlled" doesn't make as much sense from a window, but yeah, I think it'd be fine to have in other contexts |
| 14:31 | <wanderview> | JakeA: you mean for ClientQueryOptions? |
| 14:31 | <JakeA> | wanderview: yeah |
| 14:32 | <wanderview> | JakeA: it would be kind of nice if we could get people using Clients.openWindow() instead of window.open() |
| 14:33 | <JakeA> | wanderview: although… if you postmessage a client, would it still land on navigator.serviceWorker? |
| 14:33 | <wanderview> | JakeA: oh... I forgot about that part... thats kind of icky |
| 14:37 | <wanderview> | JakeA: it seems if we did this we would need to move .claim() into a specialization for service worker globals anyway... we could specialize postMessage() the same way |
| 14:37 | <JakeA> | Agreed |
| 14:37 | <wanderview> | I guess I could write an issue |
| 14:38 | <wanderview> | work, work |
| 14:38 | <JakeA> | There isn't a way to postmessage to SharedWorkers though |
| 14:38 | <JakeA> | other than navigator.serviceWorker |
| 14:38 | <JakeA> | self.onmessage doesn't exist |
| 14:38 | <wanderview> | JakeA: self.clients.onmessage? |
| 14:39 | <wanderview> | I mean.. we could hang it off of there for Client API postMessaging... |
| 14:39 | <JakeA> | wanderview: In retrospect, that's a better place for it than navigator.serviceWorker |
| 14:39 | <wanderview> | but sometimes it feels like we try to see how many messaging paths we can create |
| 14:40 | <wanderview> | JakeA: which reminds me... we talked about BroadcastChannel in service worker... would those messages get our new fangled ExtendableMessageEvent with waitUntil()? |
| 14:41 | <JakeA> | wanderview: I don't think so, since you'd need to be in another event to create the channel |
| 14:41 | <wanderview> | JakeA: I meant for receiving BroadcastChannel messages from a window, etc |
| 14:42 | <wanderview> | but maybe thats what you meant |
| 14:42 | <wanderview> | I see |
| 14:42 | <JakeA> | wanderview: are you suggesting a new top-level thing like self.onbroadcastchannelmessage? |
| 14:42 | <wanderview> | JakeA: no... I was just wondering if BroadcastChannel is easily usable in SW... or if it has problems due to waitUNtil() being missing... but you correctly point out you already need to be in a place with a waitUntil |
| 14:43 | <wanderview> | JakeA: I wonder how long until people start putting `self.waitUntil = evt.waitUntil` at the top of all their event handlers |
| 14:43 | <wanderview> | I guess we need async waitUntil for that to be more useful |
| 14:44 | wanderview | may not be thinking right today... |
| 14:44 | <JakeA> | It'd still fall foul of overall limits right? |
| 14:44 | <wanderview> | JakeA: you mean the timeout with a waitUntil() holding things alive too long? |
| 14:45 | <JakeA> | yeah |
| 14:45 | <wanderview> | JakeA: it should I think |
| 14:45 | <wanderview> | JakeA: although if you keep getting functional events then I think the timer woudl be reset, of course |
| 14:53 | <wanderview> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/955 |
| 14:54 | <JakeA> | Cheers! |
| 15:10 | <Domenic> | wilsonpage: pong |
| 15:12 | <wilsonpage> | Domenic got a tricky situation with my fastdom library regarding multiple versions running on the same page |
| 15:12 | <wilsonpage> | annevk pointed me your way :) |
| 15:12 | <wilsonpage> | https://github.com/wilsonpage/fastdom/issues/90 |
| 15:12 | <wilsonpage> | Domenic I imagine the problem has been solved someplace beforebefore |
| 15:13 | <Domenic> | Hmm not sure exactly what makes me qualified to help here, but I guess I can weigh in on option A/B/C... |
| 15:15 | <wilsonpage> | Domenic that would be a mega help :) |
| 15:16 | <Domenic> | Goodness this is a tough one :( |
| 15:16 | <Domenic> | Most libraries don't have this kind of coordination problem |
| 15:17 | <wilsonpage> | Domenic yeah most the options I came up with are pretty lame |
| 15:17 | <wilsonpage> | But I'm all out |
| 15:40 | <Domenic> | Today I learned about <meta http-equiv="default-style">. Whyyyy |
| 15:56 | <wilsonpage> | Domenic great response, thanks mate! |
| 17:44 | <TabAtkins> | astearns: No, "authors must" is intentional and should be kept. It's just a different conformance class that we can't actually test. ^_^ It still, of course, has zero influence on what the implementors have to do. |
| 17:52 | <TabAtkins> | MikeSmith: As an implementor / fellow spec editor, I'm actually not a fan of how extreme Anne takes his "spare, details-only" speccing. Makes it very difficult to tell what the *intent* is of something, or sometimes what it even *means*. |
| 17:53 | <TabAtkins> | Despite the occasional implementor trying to interpret an informative detail as if it had normative consequences, I find it's worthwhile overall to give understandable context (to the point that a clueful web author could understand), as it's caught a lot of algorithm bugs when someone was able to go "huh, that result doesn't seem to match what it claims it |
| 17:53 | <TabAtkins> | should be doing...". |
| 18:05 | <astearns> | "conformance class that we can't actually test" doesn't make any sense to me. The instances I saw were more like, "If you don't do this, you're gonna have a bad time." |
| 18:15 | <smaug____> | igrigorik: what does Math.random() r 2 - r; mean in requestIdleCallback spec? |
| 18:17 | <wanderview> | JakeA: Domenic: unfortunately I have to stop working streams API stuff in firefox for the time being... trying to find someone else to pick it up |
| 18:17 | <Domenic> | wanderview: awww sad! You seemed to be making a lot of progress! What happened? |
| 18:17 | <Mek> | smaug____: looks like some kind of markdown processing gone bad (replacing * r * with <em>r</em> |
| 18:18 | <wanderview> | Domenic: we need to fix a number of service worker issues in order to enable multiple renderer processes in firefox... thats a high priority thing at the moment |
| 18:18 | <Domenic> | wanderview: ah well that's pretty understandable. |
| 18:18 | <wanderview> | Domenic: also, I was not making very good progress because I don't really know the js engine stuff very well |
| 18:19 | <wanderview> | Domenic: but with it shipped in both edge and chrome (and likely coming soon in safari) I think the pressure is on to implement it |
| 18:19 | <smaug____> | you see, if it was a normal webidl based spec it would all be easier and understandabe ;) |
| 18:19 | <smaug____> | understanable |
| 18:19 | <wanderview> | hoping we can get one or two people with better knowledge on it |
| 18:21 | <TabAtkins> | Mek: That's precisely why Bikeshed doesn't have inline-markdown support turned on by default. :/ |
| 18:21 | <wanderview> | Domenic: if not, then I will circle back to it after we have multi-e10s working |
| 18:43 | <Domenic> | Anyone remember the bugzilla bug about radio button names and unicode case matching? |
| 18:52 | <annevk> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16970 |
| 18:58 | <zewt> | TabAtkins: think we've had the conversation a few times before, but I disagree on "authors must"; it's just a confusingly poor choice of terminology |
| 19:00 | <botie> | rniwa, at 2016-08-12 08:59 UTC, MikeSmith said: hey somebody finally found an appropriate use for half-width katakana https://github.com/fumieval/LazyKQ |
| 19:04 | <Domenic> | annevk: thanks! |
| 19:17 | <rniwa> | MikeSmith: that's some crazy language. |
| 20:43 | <smaug____> | igrigorik: ping |
| 20:43 | <smaug____> | igrigorik: what should timeRemaining() return if JS keeps IdleDeadline after the callback? |
| 20:46 | <smaug____> | filed a bug |