2017-05-01 [09:25:13.0000] https://w3ctag.github.io/design-principles/#casing-rules recommends "public-key" for an enumeration value, right? [09:25:34.0000] (Context: https://github.com/w3c/webauthn/pull/432/files#diff-ec9cfa5f3f35ec1f84feb2e59686c34dR419) [09:54:08.0000] One counter-argument in favor of using "publickey" for both the dictionary member and enum value is that then devs don't need to remember which is which. [10:06:12.0000] jyasskin: well, if it's two words, then the dictionary member should be publicKey [10:06:28.0000] (and "public-key" for the enumeration, yes) [12:11:03.0000] Hmm it's a holiday in Europe? [12:11:35.0000] Ah yes Labour Day apparently [12:13:12.0000] Domenic: most of the world, AFAIK [12:56:36.0000] Yes. [12:56:51.0000] Workers Day [12:57:18.0000] Though I guess on this IRC channel that better name is ambiguous. [13:24:06.0000] Worklet's Day is just the morning of May 1. [13:26:04.0000] *groan* [13:39:14.0000] whats the status of http://tabatkins.github.io/specs/css-nesting/ ? Any way to tell how far along the standards process that spec is? [15:03:28.0000] bret: as far as I can tell it's just an idea, no implementer interest yet. Not sure on the CSSWG's feelings on it though; maybe search their minutes? [15:11:54.0000] ok ill dig around [16:41:51.0000] Yeah, Stage 0 in tc39 terms 2017-05-02 [05:34:33.0000] Domenic: It seems a little surprising that moduleMap keys on URL and not URL + credentials. Or am I thinking about this wrongly? [05:36:38.0000] Domenic: Eg, if I'm deliberately trying to fetch a module with credentials, I may end up getting a non-credentialed version because some unrelated script imported it earlier without credentials [05:48:46.0000] JakeA: it doesn't seem overly problematic [05:49:05.0000] JakeA: and it's unclear whether the added complexity of the alternative is worth it [05:50:17.0000] annevk: Well, it just caught me out when I was creating a demo of script modules, but maybe it won't happen in the real world. [05:51:31.0000] JakeA: did you want both separately? [05:52:41.0000] annevk: Yeah, but I was creating a demo where one script didn't have credentials and the next one did, so it isn't a real world example [05:53:03.0000] Surprised me though [05:53:56.0000] JakeA: we also do this for SharedWorker, even across non-module/module boundaries [05:54:15.0000] JakeA: it's a little surprising, but I'm not sure it's worth making the key more complicated [05:55:16.0000] annevk: I guess I expected it to work like the cache [05:55:51.0000] In terms of using creds as part of the key anyway [06:09:46.0000] annevk: does a VARY header effect the moduleMap? [06:11:44.0000] wanderview: nope [06:14:25.0000] I guess module map is not long lived? [06:20:12.0000] wanderview: indeed, lifetime of the thing it's attached to [07:37:42.0000] foolip: considering being a total jerk and manually overriding the webrtc url in Specref. :D [08:08:18.0000] annevk: I think I finally understand response filtering in Fetch, but it took me a while. It also threw a couple implementors for a loop, so I'm trying to see if we can make it any more clear [08:08:57.0000] but I recognize that it's actually a kind of complicated behavior, so I don't know if I'll really be able to improve on what we have already [08:09:27.0000] jugglinmike: if you can that'd be great [08:09:48.0000] jugglinmike: annevk: did you guys come to a conclusion about the desired behavior? [08:10:06.0000] ah, no, wanderview--I didn't raise this with annevk [08:10:33.0000] I gotta go and I haven't seen an issue... [08:10:40.0000] annevk: this is the test that wanderview, Mek, and I all agreed was "correct" on Friday https://github.com/w3c/web-platform-tests/compare/master...bocoup:sw-resp-tainting [08:10:43.0000] I might be able to reply later today, but no guarantees [08:10:50.0000] ohh, okay [08:11:21.0000] jugglinmike: oh right, I did look at that, and it looked reasonable, but a description of what I'm looking at would've helped [08:11:47.0000] annevk: I think the issue is that the spec actually might say the opposite of what we all thought was correct [08:11:52.0000] I haven't been able to write a coherent issue because I'm not so confident that anything is wrong here... Just a little confusing [08:12:41.0000] Yeah, wanderview's point was that a "basic filtered" response shouldn't be considered a "filtered response" at all [08:12:52.0000] or rather, that was surprising to me [08:13:15.0000] I would expect step 14 of main fetch to increase the tainting level if the request tainting is greater than the response tainting [08:13:21.0000] anyway, we should probably put this all in an issue [08:14:21.0000] Hmm, yeah, does a synthetic response have any filter applied to it? [08:14:28.0000] Anyway, issue would be good I guess [08:14:43.0000] Ahh, wanderview that's the ticket. There may be a problem where the outer fetch needs *more* filtering [08:14:54.0000] Okay, that's the insight I needed to write something coherent [08:14:58.0000] I'll get on that now [08:15:41.0000] jugglinmike: thats essentially the way I wrote it in gecko... https://dxr.mozilla.org/mozilla-central/source/dom/fetch/InternalRequest.h#363 [08:16:09.0000] and in the synthesized case it gets used here: https://dxr.mozilla.org/mozilla-central/source/dom/workers/ServiceWorkerEvents.cpp#232 [08:22:49.0000] jugglinmike: thanks for working through this [08:23:09.0000] My pleasure (as unlikely as that may sound) [11:26:21.0000] Domenic: can't remember if you were part of this conversation...are , the response should still be avail in developer tools right? Either way, Issue with this is people say the data passed to window.onerror is obfuscated when window.onerror gets an error from script.js [16:28:23.0000] This gist: https://gist.github.com/domfarolino/28725582270679b9e17fa74922cbfd65 produces this output in Chrome: https://image.ibb.co/gSgWyF/Screen_Shot_2017_05_21_at_4_27_06_PM.png [16:28:59.0000] However in FF we don't get the "Script error" 0 0 thing...we just straight up get the real data [16:47:13.0000] domfarolino: yeah the response will always be available in devtools [16:47:35.0000] right, wanted to make sure we were on the same page [16:48:22.0000] as far as why there’s a difference between Firefox and Chrome in what you get from window.onerror I dunno [16:48:49.0000] it could be a bug in Firefox that it’s not conforming to the Fetch spec on this [16:49:02.0000] or I could just not be understanding [16:49:13.0000] but annevk will be able to give you a clear answer [16:53:03.0000] MikeSmith could you help find the section in the fetch spec you are referring to? I know that HTML refers to the `crossorigin` attribute and how it helps expose more specific error data (https://html.spec.whatwg.org/multipage/scripting.html#attr-script-crossorigin) but don't know where this sort of thing is in fetch 2017-05-22 [17:29:31.0000] domfarolino: I think what the Fetch spec requires browsers to expose in this case is an “opaque filtered response” https://fetch.spec.whatwg.org/#concept-filtered-response-opaque [17:29:39.0000] > An opaque filtered response is a filtered response whose type is "opaque", url list is the empty list, status is 0, status message is the empty byte sequence, header list is empty, body is null, and trailer is empty. [17:31:36.0000] because the “response tainting” is "opaque" https://fetch.spec.whatwg.org/#concept-request-response-tainting [17:32:34.0000] and the response tainting is "opaque" because the mode is "no-cors" [17:33:27.0000] and the mode is "no-cors" because that is the default unless some other part of the fetch algorithm sets it to something else [17:33:33.0000] https://fetch.spec.whatwg.org/#concept-request-mode [17:34:06.0000] the possible modes are "same-origin", "cors", "no-cors", "navigate", or "websocket" [17:35:15.0000] and since this is not a same-origin fetch, nor a navigation, nor a websocket fetch, nor a CORS-enabled fetch, the mode remains set at the default "no-cors" [17:44:48.0000] MikeSmith ok so does all that apply even though im using a script tag for the loading and not making a request with fetch? [17:46:24.0000] Even if so, not sure why it would be opaque? It is a CORS-enabled request (since I'm using crossorigin attr on script tag) [17:52:09.0000] the Fetch spec defines the primitives for all fetches, regardless of whether they ' [17:53:22.0000] *regardless of whether they’re done usin the fetch() method or if instead the UA is initiating the fetch (instead of it being initiated from JS) [17:54:40.0000] for (no crossorigin attr, so opaque response right?) [21:43:59.0000] Domenic: source: https://fetch.spec.whatwg.org/#concept-filtered-response-opaque [21:44:24.0000] Oh, that's easy. Dev tools have special powers. [21:44:36.0000] The important thing is you can't write code in your web page to read the contents. [21:44:48.0000] Haha alright....yes! that second message is what I was about to say [21:47:13.0000] Domenic: Sorry one more thing! So I couldn't get FF to show me an error message of "Script error" via running the following gist locally https://gist.github.com/domfarolino/28725582270679b9e17fa74922cbfd65 whereas Chrome was properly muting errors. [21:47:42.0000] Yeah, I'm not sure what's up with that; Firefox may be going against the spec. [21:48:33.0000] Gotcha..didn't know if my reproduction was bogus or not..Alright I may look into filing a bug I guess [21:48:53.0000] I assume errorjs.js is adding a window.onerror handler? [21:49:37.0000] errorjs.js has the exact same contents as the script loaded above it actually [21:49:56.0000] so I guess I'm adding the handler twice...which I didn't think about [21:50:26.0000] Interesting... [21:50:32.0000] I guess it should override it [21:50:38.0000] So it should still be muted [21:51:02.0000] although hmm the function redeclarations for a/b/c might confuse things... [21:51:50.0000] Ah true. I should change it up then. Maybe add the handler inline, and rename all functions. Regardless, Chrome gives me two different outputs in window.onerror...one muted, one not. FF gives both unmuted [21:52:25.0000] Yeah, presumably there's some interop bug here, although it's a bit harder to determine who's wrong. [21:52:32.0000] Anyway, bedtime for me :) [21:52:54.0000] Thanks for the info. gn [23:22:33.0000] domfarolino: thinking about the was CORS works, the fact you can always see a response in devtools is expected [23:23:04.0000] because the browser is what enforces cross-origin restrictions, not servers [23:24:29.0000] generally if you can get a response from a server using any other client, curl or whatever, then the browser is going to get a response too [23:24:41.0000] Right, I just didn't know how far that obfuscation reach was. As in...is both the user of the browser AND the site code that does not have access to opaque responses OR JUST the site code (meaning devtools can see all). But this was a naive thought anyways [23:24:53.0000] Yes the curl is a good examp [23:25:26.0000] yeah just the site code can’t see it [23:25:26.0000] but it’s not a naive thought [23:26:05.0000] because I think the CORS protocol is kind of non-intuitive [23:27:05.0000] I think most people are surprised to find out they can see a response in devtools but their code can’t get to it [23:27:25.0000] It is certainly kind of odd. Always struck me as odd that the browser was the one managing the security, not the server (prized resource)...but then I learned about preflighting which makes more sense. [23:27:32.0000] Yeah that makes sense [23:27:35.0000] right [23:28:41.0000] anyway the web runtime is always the oddball [23:28:49.0000] see the channel /topic and all that [23:29:54.0000] So moral of the story, any state-changing server endpoints that can be accessed via CORS should be written in such a way (seemingly accepting POST is sufficient) that requests to it will def be preflighted [23:29:58.0000] Yeah haha trueee [23:34:57.0000] Question: is it possible to programmatically get the response to a script requested with CORS (not using fetch). Like If I were to programmatically insert a script whose crossorigin attr was set, and I insert it into say the head..can I, even then, get at its response? Should be no prob from a websec standpoint, but is there a mechanism to do this? [23:38:31.0000] domfarolino: no mechanism do that as far as I know [23:39:08.0000] you’d instead need to initiate the request using fetch() or XHR rather than script element [23:40:37.0000] ✔ [03:14:54.0000] mkwst: https://github.com/whatwg/fetch/issues/546 - NSFW results when doing compat analysis is a bit annoying (for me); possibly worse than annoying for others. (I can cope fine with "regular" porn sites, though I didn't want to see animal porn...) Wonder if something can/should be done about this [03:32:32.0000] zcorpan: Sorry. I didn't actually visit all the sites, just `view-source:[site]`. I only pulled up the site when the hit wasn't in the actual body of the page. [03:32:42.0000] Which site should I have flagged? [03:33:03.0000] (Really, sorry. I didn't mean to send to you horribleness.) [03:33:57.0000] mkwst: I didn't look at these results, just noted you marked some as NSFW. The animal porn was from earlier analysis I did a while back, unrelated to this. Sorry for being unclear! [03:34:14.0000] Oh, good. :) [03:35:40.0000] I was going through `javascript:` URL navigation hits on Friday, and that seemed pretty bad, which lead me to the `view-source:` method today. [03:36:01.0000] It works pretty well. I only had to actually visit ~8 or so sites today. [03:36:42.0000] yeah I also opt for view-source: unless I want to see what's broken visually. Faster to load as well [03:39:17.0000] zcorpan: also, FWIW, there are places like the UK where the legal status of visiting such sites is dubious (i.e., visiting them *is* illegal, though unknowingly clicking on a link to them is legal, but it means that one probably doesn't want to spend time clicking around) [03:43:14.0000] I added a bullet point to https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit# [03:49:09.0000] Why is drafts.csswg.org often damn slow? [03:52:09.0000] nox: if it’s slower than normal the best person to give a heads-up to is plinss [03:52:55.0000] MikeSmith: Meh, fast Internet probably spolied me. [03:52:58.0000] spoiled* [03:53:16.0000] OK [06:43:08.0000] annevk: Getting back to https://github.com/whatwg/fetch/pull/442#discussion_r103624566 (finally) [06:43:46.0000] should the potential destination be linked to a specific request, or should it be a detached concept that translates to destination? [06:45:06.0000] yoav: I would say detached [06:45:20.0000] yoav: just like you can normalize a method without a request [06:45:34.0000] OK, makes sense [07:28:37.0000] Anyone want to review https://github.com/w3c/fxtf-drafts/pull/169 ? (non-normative, should be pretty quick, but blocks me sending an email proposing a WD) [07:32:27.0000] Domenic? ^ [07:32:37.0000] sure [07:32:48.0000] ❤️ [07:36:20.0000] Hmm, it seems a bit unfortunate it's new DOMPoint(x, y, z, w) but new DOMMatrix([m11, ...]), i.e. you need extra []s for DOMMatrix [07:36:28.0000] annevk: one more Q. Would you like the elimination of empty potential-destination happen at the caller, or as part of the translation into a destination? [07:36:49.0000] If it's the latter, I'd love some guidance as to how to define it [07:37:32.0000] Domenic: yeah... [07:38:41.0000] Domenic: could maybe change it, but extra churn, and another incompatible change from what gecko has shipped for a few years [07:39:03.0000] Yeah, probably not worth it. [07:44:44.0000] Domenic: I guess remove "Changed fromString() static method to overloaded constructor." since that didn't exist in the previous WD [07:46:47.0000] Oh, yeah, I'm not up to date on my WDs :P [07:47:18.0000] Domenic: ok PTAL [07:48:05.0000] Domenic: you mean you didn't read the previous WD cover-to-cover, multiple times, then backwards at least once?! [07:48:23.0000] zcorpan: gotta go afk for ~30 mins, sorry! But feel free to merge. [07:48:33.0000] annevk: nm. I think I figured it out [07:48:35.0000] ok. thx [08:29:50.0000] yoav: the caller would invoke this before creating a request, I'd think [08:30:07.0000] yoav: until we have some kind of lowercase-request creator algorithm [08:34:04.0000] Domenic: https://tools.ietf.org/html/rfc8174 [08:34:15.0000] Domenic: guess we need to fork 2119 [08:34:18.0000] Oh boy [08:35:27.0000] "2. Clarifying Capitalization of Key Words" "NEW" text seems rather IETF-specific and verbose. [08:35:51.0000] Oh I see the portion other specs are supposed to use is smaller [08:36:06.0000] I guess we should indirect everything through Infra and then Infra can say something about ignoring RFC 8174. [08:36:50.0000] Maybe we can move "willful violation" to Infra too hrm [08:42:25.0000] Domenic: when should I expect this definition to be available through Bikeshed? [08:43:15.0000] jugglinmike: usually less than 24 hours; my understanding is the ingestion process happens at some set time every day. (TabAtkins may know exactly when.) After it is then you need to do bikeshed update, or use the web service. [08:43:40.0000] got it. Thanks! [08:51:25.0000] Domenic: sgtm [08:52:51.0000] Will file an issue so I don't forget, maybe a PR later 2017-05-23 [19:19:33.0000] Domenic: briefly revisiting last night's conversation...since scripts "optionally" have a muted errors field (https://html.spec.whatwg.org/#muted-errors), does that mean that there really is no interop bug after all, because it isn't a "requirement" for browsers to mute errors from x-o scripts? [20:22:50.0000] domfarolino: it is a req [20:23:44.0000] domfarolino: I think that just means it is not always set, could be clearer [20:31:39.0000] Ok I see thanks annevk [20:35:09.0000] Would you consider a PR that either moves the word "optionally" down to the description as opposed to the title, or removes it altogether? [20:36:01.0000] I'm wondering if "A flag which, if set, means" covers the "optionally" aspect of setting that flag, while preserving its requirement of existing nevertheless [00:08:18.0000] hm [00:08:20.0000] https://jsfiddle.net/3vx88jtj/1/ [00:08:29.0000] is this behavior standardized somewhere? [00:08:48.0000] i.e. how canvas font sizes <1 are supposed to work with transforms? [00:12:42.0000] domfarolino: yeah, a rewrite to a flag of sorts would make sense [00:13:01.0000] domfarolino: sorry for the late reply, missed your follow-up [00:14:52.0000] ondras: Browsers are, in general, allowed to apply a minimum font size. See https://jsfiddle.net/3vx88jtj/2/ [00:15:09.0000] (Mine applies a min of 12px.) [00:16:52.0000] TabAtkins: based on my current experience (ff, chrome), the behavior is weird and inconsistent. [00:17:18.0000] for instance, the resulting height is ~always the same, ff+chrome [00:17:23.0000] for the whole input range of your fiddle [00:17:33.0000] but the letter spacing jumps rapidly [00:18:14.0000] and chrome fixes the ctx.font value on a minimum of "2px" for the rightmost 1/3 of the slider [00:18:28.0000] while still maintaining the proper size of the rendered result [00:19:19.0000] => chrome's .font getter returns different values than those that are actually applied [00:19:59.0000] anyway, apparently rendering text to a (highly) scaled canvas seems to be a large amount of pain [00:20:02.0000] damn. [00:20:25.0000] Ah, you might not have a meaningful min; mine blows up pretty quickly as soon as you start moving the slider to the right. [00:21:03.0000] my height is constant, the width/letterspacing jumps in an unusable fashion [00:21:43.0000] Yeah, font renderers don't really work on arbitrary floats; they all round to various precisions at various spots. [00:21:54.0000] okay [00:22:12.0000] sounds like I will have to cancel the transform for font rendering and compute it myself [00:33:38.0000] annevk: when defining a method, is there an equivalent to ASSERT_UNREACHED()? Should I throw in cases that should not happen? (e.g. because callers should collapse potential-destination values to known values before they call the translation method) [00:43:44.0000] yoav: see Infra, you can use Assert: [00:48:09.0000] cool, thx! [00:49:00.0000] so something like "Assert: this should never be reached."? [00:55:22.0000] yoav: prolly better to assert before the branch [00:55:41.0000] ok, makes sense [00:55:50.0000] Yeah, assert your preconditions. Failling the assert is a spec error, not a runtime error. [00:55:52.0000] yoav: Assert: destination is not fetch or some such [00:56:27.0000] If it's a runtime error, then you do indeed need to throw; asserts might be useful afterwards to remind the spec reader what values are left over. [01:01:36.0000] Asserts won't "run" after throw; throw terminates [01:07:03.0000] Right, I mean like "1. If |x| is a weird value, throw a TypeError. 2. Assert: |x| is a FooEnum value. 3. More stuff..." [01:09:21.0000] Ah [01:12:11.0000] annevk: https://github.com/whatwg/fetch/pull/547 [01:12:59.0000] annevk: so getting back to HTML checking for the Encoding files, we want to run the checker if any .text files change or if the visualize.py file changes? [01:13:20.0000] It's getting bikeshed errors regarding the linking of "preload destination". I'm not sure if it real errors or a bikeshed issue related to having a space as part of the linked term (there are other errors with space in them) [01:15:36.0000] There's definitely nothign wrong with ahving spaces in a term. [01:15:53.0000] MikeSmith: .bs or visualize.py I suppose [01:16:16.0000] yoav: That said, I don't see "preload destination" in the ref database. [01:16:18.0000] MikeSmith: hmm yeah, also addition of txt I guess [01:17:02.0000] or changes to the .txt files? I notice a recent commit that makes changes to them [01:17:11.0000] TabAtkins: that's probably because I just made it up and didn't know I should also add it to a ref database :) [01:17:37.0000] also s/preload destination/potential destination/ [01:17:55.0000] Oh! Jeez, no wonder I was confused when reading the PR. ^_^ [01:18:11.0000] yoav: I can review later today, but I'd have the steps in opposite order; early return for fetch, then assert it's a destination, then return input [01:18:31.0000] annevk: OK, I'll reverse them [01:18:36.0000] In the PR, you'll get a linking error because you're not defining a "potential destination" term; you're defining "potential-destination". [01:18:49.0000] MikeSmith: yeah I suppose [01:18:58.0000] TabAtkins: doh! [01:19:52.0000] TabAtkins: Still getting the error after deleting the "-" [01:20:11.0000] ...and replacing it with a space? [01:20:19.0000] yeah [01:21:11.0000] Push the change; you shouldn't be having any trouble. [01:21:31.0000] yoav: I don't think it's worth having a dfn for that [01:22:35.0000] yoav: if you wanted to define such a term you'd define it as a superset of destination [01:22:36.0000] annevk: OK, I'll remove it then [01:23:18.0000] Can replace it with just a |var| if you want the styling. [01:23:51.0000] annevk: but we do need HTML to link to it later on. Can we do that without a dfn? [01:24:19.0000] No. [01:25:17.0000] TabAtkins: pushed the change in the mean time. I still see the error (but I'm sure I'm holding it wrong :D) [01:31:27.0000] I'm extremely confused by what's going on here. [01:32:34.0000] TabAtkins: confused by my patch, or by the error? [01:34:12.0000] yoav: then you need to define it as a distinct type [01:34:36.0000] The error. [01:35:27.0000] I'll check more on this before bed, in heading to dinner now. [01:37:08.0000] TabAtkins: Thanks :) [01:37:31.0000] annevk: pointers to an example of defining as a distinct type? [01:40:29.0000] yoav: see eg dfn of method [01:40:52.0000] yoav: X is "fetch" or a destination [01:41:11.0000] yoav: on mobile due to sick kid btw [01:41:34.0000] Hence poor latency [01:43:26.0000] annevk: looking, and no worries RE latency. I know what it's like [01:49:57.0000] TabAtkins: Split out the definition. Now I'm longer seeing the error [01:50:31.0000] annevk: uploaded. Let me know what you think (when you have time) [02:03:25.0000] Oh shoot, I realize what's up with the error now. [02:04:47.0000] Looks like I don't special-case for=/ on a dfn to mean "no for value". So it was registering it with a for of /, which you can't actually specify on a link. [02:06:08.0000] When you split out the definition, you also just removed the for attribute from the dfn, which resolved the issue. [02:06:26.0000] This is a Bikeshed bug, tho. [02:17:12.0000] TabAtkins: OK, cool. Happy to find bikeshed bugs by doing things you normally wouldn't :D [03:00:13.0000] does the fetch spec say something about what should happen when the promise returned by fetch is resolved, but there is no scheduled work on the event loop (and so technically, we don't enter a microtask checkpoint)? [03:01:37.0000] jochen__: HTML would say something about that, but that can't really happen, since fetch resolves the promise from a task [03:35:33.0000] jochen__: in fact, promises never resolve without a task being involved [03:54:27.0000] ah, found it [07:32:47.0000] TabAtkins: while you're around and fixing BS bugs… [07:33:08.0000] TabAtkins: I'm having an issue where BS seems to rewrite an inline SVG [07:33:55.0000] TabAtkins: removing the namespace in the process, which then gets rejected by echidna's HTML validator. [07:35:23.0000] if that is about the xlink:href vs href I fixed that in the HTML checker at the end of last week [07:35:43.0000] if it’s about some other error I can fix that too [07:36:18.0000] MikeSmith: how do you know this? [07:36:30.0000] assuming it’s another case where the SVG changed the doc-confoormaces requirements in SVG2 [07:37:14.0000] MikeSmith: I have no idea. This thing displays is the limit of my understanding of namespaces in SVG [07:37:36.0000] MikeSmith: can I point you to the error, BS source and output? [07:37:43.0000] well as far as SVG checking I can make the checker do whatever creates the least problems for people trying to get real work done [07:37:46.0000] tobie: sure [07:37:59.0000] MikeSmith: source: https://github.com/w3c/sensors/blob/9335c1fa027fe309a3fd13b98914b7d479968252/index.bs#L735-L800 [07:38:36.0000] no version of the SVG spec has ever clearly stated actual doc-conformance requirements consistently anyway [07:38:39.0000] /me looks [07:38:53.0000] MikeSmith: echidna error: https://labs.w3.org/echidna/api/status?id=916cf371-4630-491c-abd6-c663b65e6bbd [07:39:20.0000] /me looks again [07:39:22.0000] MikeSmith: validator error: https://validator.w3.org/nu/?doc=http://owl.w3.org//916cf371-4630-491c-abd6-c663b65e6bbd/Overview.html [07:40:34.0000] MikeSmith: Bikeshed output of SVG: https://gist.github.com/tobie/d4a0e43cc7781fec2daa933674d099f5 [07:40:58.0000] ah I think that is a bikeshed bug [07:41:13.0000]