| 01:59 | <MikeSmith> | zewt: used fetch |
| 02:00 | <MikeSmith> | tobie++ indeed |
| 02:00 | <MikeSmith> | brave man |
| 03:41 | <zewt> | mike: shouldn't need to rewrite with a different api for that, no reason it should work with one and not the other |
| 03:41 | <zewt> | (sounds like that's just encouraging people to not use https, if they have to rewrite code with a different api to make it work) |
| 03:59 | <MikeSmith> | zewt: I meant this is maybe a case where there’s no plan to change/update XHR for this or any other new cases |
| 03:59 | <MikeSmith> | cannot just keep going in and updating legacy funky API |
| 04:06 | <zewt> | doesn't seem funky to add an "allow mixed" flag to XHR, the fewer barriers discouraging HTTPS the better |
| 04:07 | <zewt> | (i still use XHR, it works fine for me so I've never felt like spending time learning a new API, especially one that isn't universal yet) |
| 04:15 | <MikeSmith> | zewt: well for better or worse I think the plan of record is that at this point there are no plans to ever update XHR with anything new |
| 04:16 | <jyasskin> | And there are fetch() polyfills. |
| 04:26 | <boogyman> | Domenic: why is Firefox's rendering a bad thing? The author created invalid markup |
| 04:26 | <Domenic> | boogyman: people create invalid markup all the time... you still gotta render something reasonable. |
| 04:27 | <boogyman> | and you consider negative numbers unreasonable? |
| 04:27 | <Domenic> | Yeah definitely |
| 04:27 | <boogyman> | I guess we disagree |
| 04:28 | <Domenic> | I mean this needs to be interoperable at the very least. |
| 04:28 | <Domenic> | https://github.com/whatwg/html/issues/1617 |
| 04:33 | <boogyman> | Why is it a bad thing that the UA could be put into quirksmode with invalid syntax like this? |
| 04:33 | <Domenic> | I don't think this has anything to do with quirks mode... |
| 04:34 | <Domenic> | UAs need to be interoperable not just when authors are well-behaved, but also when they aren't. |
| 04:34 | <Domenic> | Authors writing invalid markup is not a license for no longer following specs. (Although in this case the spec is missing details.) |
| 04:35 | <boogyman> | the alternative is to try and create notations for every found use-case? |
| 04:35 | <boogyman> | is the* |
| 04:35 | <Domenic> | Yes, that's what specs do |
| 04:35 | <Domenic> | That was the whole HTML4 -> HTML5 revolution |
| 04:36 | <Domenic> | That's why we have a HTML parser spec instead of DTDs |
| 04:36 | <boogyman> | fair enough |
| 08:10 | <Ms2ger> | annevk, happy birthday |
| 08:22 | <tobie> | Happy birthday, annevk! (And happy national holiday in your country of adoption:) |
| 08:22 | <annevk> | Cheers 😊 |
| 08:23 | <Ms2ger> | Oh, so that's why you moved there? :) |
| 09:38 | <mounir> | smaug____: I've added metrics to measure EventSource usage in Document and Workers in Chromium |
| 09:39 | <mounir> | smaug____: it should appear in https://www.chromestatus.com/metrics/feature/popularity as EventSourceDocument and EventSourceWorker but at the moment, the data is only collected on Dev/Canary and will soon be on Beta, give it some time to really have useful data |
| 09:40 | <smaug____> | thanks |
| 10:33 | <mathiasbynens> | annevk: is `new URLSearchParams('foo=%EF%BF%BF').get('foo')` supposed to perform UTF-8-style URL-decoding? i.e. should it return '\xEF\xBF\xBF' (Chromium) or '\uFFFF' (Firefox)? |
| 14:22 | <annevk> | mathiasbynens: suspect Fx is correct |
| 14:22 | <mathiasbynens> | annevk: was hoping that was the case, as it’s the more useful behavior (by far) |
| 14:23 | <mathiasbynens> | but |
| 14:23 | <mathiasbynens> | https://bugs.chromium.org/p/chromium/issues/detail?id=633153#c4 |
| 14:24 | <annevk> | Will look later this week |
| 16:23 | <annevk> | tobie: hope you have a good holiday too btw 😊 |
| 17:03 | <tobie> | annevk: :) |
| 18:51 | <TabAtkins> | tobie: That does work, but the [] aren't part of the definition. Remove those (or shift them outside {{}} braces) and it should link up. |
| 20:07 | <tobie> | TabAtkins: So {{TreatNullAs}} yields: <code class="idl"><a data-link-type="idl">TreatNullAs</a></code> |
| 20:07 | <tobie> | <a extended-attribute>TreatNullAs</a> yields: <a class="idl-code" data-link-type="extended-attribute">[TreatNullAs]</a> |
| 20:09 | <tobie> | TabAtkins: OK, I think this ties to the GH issue I opened. |
| 20:09 | <TabAtkins> | tobie: Yes, those are compatible - "idl" is a supertype representing all the IDL types, of which "extended-attribute" is one. |
| 20:10 | <tobie> | Aren't we loosing info that could be useful for styling or when parsing the spec to fill-in the shepherd DB? |
| 20:14 | <jsbell> | TabAtkins; In https://wicg.github.io/entries-api/ I end up with refs to [File-1] (autogenerated from normative refs) and [FileAPI] (from explicit informative refs), pointing at the same doc. Is that a bikeshed thing or a specref thing? |
| 20:16 | <TabAtkins> | jsbell: That's me giving FileAPI a weird shortname; I just updated it to be "fileapi" instead, so I think it'll match up now. |
| 20:16 | <TabAtkins> | If it still does [Fileapi-1] vs [FileAPI], file on me. |
| 20:17 | <jsbell> | testing... |
| 20:17 | <TabAtkins> | tobie: Nobody's losing anything, they're specifying what they need. If they want to be more specific (because they're styling based on class or something), they can do so, but the shorthand purposely covers a large group of things for convenience. |
| 20:17 | <TabAtkins> | jsbell: You'll have to `bikeshed update` |
| 20:19 | <jsbell> | TabAtkins: yep. Hrm, now getting No 'idl' refs found for 'File'... |
| 20:23 | <TabAtkins> | Might be rebuilding right now, or maybe you have some manual declarations that "File" comes from the "file" spec? |
| 20:24 | <jsbell> | TabAtkins: No manual declarations for those. I'll try again in a bit. (FYI, 4 errors total. idl/interface/idl-name for File, idl for FileReader) |
| 21:08 | <tobie> | TabAtkins: would you have any idea why the following https://github.com/tobie/webidl/blob/bikeshed/index.bs errors with: |
| 21:08 | <tobie> | FATAL ERROR: Multiple local 'interface' <dfn>s have the same linking text 'DOMString'. |
| 21:17 | <tobie> | TabAtkins: I can search and replace all of the instances of "DOMString" with garbage and keep only this one: <h4 oldids="dom-DOMString" id="idl-DOMString" interface="">DOMString</h4> while still triggering the issue. |
| 21:21 | <tobie> | TabAtkins: reduced test case here: https://gist.github.com/tobie/3ff6f07158403cde5d154156e2e535d2 |
| 23:58 | <TabAtkins> | tobie: Ah, sorry, that's because of my terrible hacks to let people link to some of the webidl things. Manually specified anchor blocks count as "local" definitions, and DOMString is in Bikeshed's default anchor file. |
| 23:58 | <TabAtkins> | So you're colliding with the built-in "DOMString" definition. :/ |
| 23:59 | <TabAtkins> | I'll remove that as soon as WebIDL can legitimately provide a dfn for the term; for now just suffer thru it. |