| 01:48 | MikeSmith | wonders if any HTML parser implementors/testers are around |
| 01:48 | <MikeSmith> | thinking about https://github.com/inikulin/parse5/issues/26#issuecomment-113298544 |
| 01:49 | <MikeSmith> | I'm not sure what he means there about "if an html opening tags is found in the 'in body' insertion mode, its attributes should extend the attributes of the first html element. Doing this would basically buffer the whole document in memory." |
| 01:49 | <gsnedders> | I am? |
| 01:49 | gsnedders | looks |
| 01:50 | <MikeSmith> | gsnedders: I think I know now |
| 01:51 | <MikeSmith> | he means specfically the `html` element in the "in body" insertion mode |
| 01:51 | <MikeSmith> | https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inbody |
| 01:51 | <MikeSmith> | the "Otherwise, for each attribute on the token, check to see if the attribute is already present on the top element of the stack of open elements. If it is not, add the attribute and its corresponding value to that element." part |
| 01:51 | <MikeSmith> | that is nuts |
| 01:52 | <gsnedders> | yeah, html start tags do that |
| 01:52 | <MikeSmith> | ok |
| 01:52 | <MikeSmith> | so he seems right |
| 01:52 | <gsnedders> | yep |
| 01:52 | <MikeSmith> | well I mean, he's right that doing that requires buffering the whole document in memory |
| 01:52 | <MikeSmith> | unless I'm missing something |
| 01:53 | <MikeSmith> | I don't understand what he means by "A way to mitigate this could be to send provisional html tags" |
| 01:53 | <gsnedders> | idk, sounds like doing weird shit by special casing the html element |
| 01:53 | <MikeSmith> | yeah |
| 01:53 | <gsnedders> | like sending "here's the html element", "oh wait no here's more for the html element" |
| 01:54 | <gsnedders> | the only practical way to do SAX for HTML is to admit fatal errors |
| 01:54 | <gsnedders> | IMO |
| 01:54 | <MikeSmith> | really? |
| 01:54 | <MikeSmith> | ok |
| 01:54 | <MikeSmith> | that's the core of what I've been wondering |
| 01:55 | <gsnedders> | you can so easily end up having to buffer so much that I'm never convinced it's worth it |
| 01:55 | <gsnedders> | esp. with AAA |
| 01:55 | <MikeSmith> | yep |
| 01:55 | <MikeSmith> | sadly |
| 01:55 | <MikeSmith> | though I was hoping to hear you say otherwise |
| 01:55 | <gsnedders> | the requirement that you fatally error when you first hit a parse error or never means you can't do limited buffering based on allowing n tokens, really |
| 01:56 | <gsnedders> | at least while complying with the spec |
| 01:56 | <gsnedders> | though maybe that's a memory limitation and hence allowable? |
| 01:56 | <MikeSmith> | hmm yeah but that would be a lazy way out |
| 01:56 | <gsnedders> | AAA only requires buffering while the list of formatting elements is not empty, no? |
| 01:57 | <gsnedders> | but you must always buffer while the list is not empty, right? |
| 01:57 | <MikeSmith> | ah yeah |
| 01:57 | <gsnedders> | and you have to buffer all tables entirely |
| 01:57 | <gsnedders> | I mean for a fair few documents that's essentially buffering the whole document |
| 01:57 | <MikeSmith> | sure yeah that's certain |
| 01:58 | <gsnedders> | which people probably don't expect of a streaming parser |
| 01:58 | <MikeSmith> | true |
| 01:58 | <MikeSmith> | again, sadly |
| 01:58 | <gsnedders> | I think the only sensible way to do a streaming API is buffer everything or admit fatal errors, basically. |
| 01:59 | <MikeSmith> | yeah so I guess that's wahy Henri's SAX parser just either buffers the entire document or lets you opt into fatal-error-for-any-non-streaming-case |
| 02:00 | <MikeSmith> | gsnedders: if you have time please consider adding a comment at https://github.com/servo/html5ever/issues/149 |
| 02:00 | <MikeSmith> | and/or talking to SimonSapin about it here |
| 02:00 | <gsnedders> | try reminding me in a few days |
| 02:00 | <MikeSmith> | hai |
| 02:01 | <MikeSmith> | well I'll make a comment right now on that issue and point to the logs here and ping you in the comment |
| 02:01 | <MikeSmith> | and remind you later if needed |
| 02:08 | <gsnedders> | kk |
| 07:36 | <annevk> | jgraham: that's not defined by HTML? |
| 08:07 | <SimonSapin> | Thanks for looking into it MikeSmith, gsnedders |
| 08:10 | <Ms2ger> | That didn't take long: https://bugzilla.mozilla.org/show_bug.cgi?id=1182775 |
| 08:11 | <MikeSmith> | SimonSapin: well Ivan Nikulin (parse5 implementor) is still convinced it's feasible |
| 08:12 | <MikeSmith> | he just commented a couple minutes ago to say as much |
| 08:12 | <MikeSmith> | https://github.com/inikulin/parse5/issues/26#issuecomment-121160391 |
| 08:12 | <MikeSmith> | I very much hope he's right |
| 08:12 | <MikeSmith> | gsnedders: shttps://github.com/inikulin/parse5/issues/26#issuecomment-121160391 |
| 08:12 | <MikeSmith> | oofs |
| 08:12 | <MikeSmith> | gsnedders: https://github.com/inikulin/parse5/issues/26#issuecomment-121160391 |
| 08:14 | <MikeSmith> | Ms2ger: that means gmail's using invalid linear-gradient syntax? |
| 08:14 | <annevk> | Maybe he's saying something else? The parser doesn't really have to buffer, but it definitely needs to plug into some DOM... |
| 08:14 | <annevk> | MikeSmith: we removed -moz- gradient syntax |
| 08:14 | <MikeSmith> | annevk: ah OK |
| 08:15 | <MikeSmith> | I guess breaking gmail is a good way to find out if people are paying attention |
| 08:15 | <MikeSmith> | annevk: streaming parse |
| 08:15 | <MikeSmith> | *parser |
| 08:15 | <annevk> | You can implement <table><p> "streaming" as long as the other side can deal with "you need to modify the tree" |
| 08:15 | <MikeSmith> | well how does the other side know that ahead of time? |
| 08:15 | <annevk> | If the other side throws away the tree it's not going to be the correct |
| 08:16 | <annevk> | You don't |
| 08:16 | <SimonSapin> | MikeSmith: I wonder if you and him are talking about the same thing. The initial message of inikulin/parse5#26 is about making the input of the tokenizer (bytes or text) be a stream instead of a single string/buffer. I was asking whether the *output* of the tree builder could be like SAX/StAX |
| 08:16 | <annevk> | Yeah, agreed, he's talking about something else |
| 08:16 | <MikeSmith> | ah |
| 08:17 | <MikeSmith> | yeah |
| 08:17 | MikeSmith | looks back |
| 08:17 | <SimonSapin> | What annevk said. That last comment also talks about modifying nodes that were already "emitted" |
| 08:17 | <annevk> | We've known since 2006 or so that a streaming HTML parser requires a different set of rules |
| 08:17 | <MikeSmith> | yeah I misunderstand what kind of streaming that issue was about |
| 08:17 | <annevk> | And Hixie has thought of specifying one for search engines, but it never became high enough priority |
| 08:18 | <MikeSmith> | annevk: sure (about streaming requiring different rules) |
| 08:18 | <SimonSapin> | annevk: different rules would give different results, right? Isn’t that an interop problem? |
| 08:19 | <annevk> | SimonSapin: yeah, of sorts |
| 08:19 | <MikeSmith> | ah I didn't know that's what you meant |
| 08:19 | <annevk> | SimonSapin: but you'd opt into that for the perf |
| 08:20 | <SimonSapin> | hum, ok |
| 08:20 | <annevk> | I mean that was the idea |
| 08:20 | <MikeSmith> | I think that's not true the rules need to be different. The different rule is that you either need to buffer the whole document, or you need to just fail on any markup cases that need non-streaming behavior |
| 08:21 | <MikeSmith> | Henri's buffered SAX parser is fully conforming |
| 08:21 | <annevk> | At the time anyway e.g. Google didn't modify some tree so would have some minor differences from browsers, a tradeoff they thought was worth it |
| 08:21 | <annevk> | (Google the search engine) |
| 08:22 | <annevk> | MikeSmith: if you buffer it's not really streaming imo |
| 08:22 | <annevk> | MikeSmith: buffer the whole document is akin to just building a tree |
| 08:23 | <SimonSapin> | MikeSmith: I’m ok with the conclusion: it’s only possible with tradeoffs that make it not worth it. (Either not-really-streaming or fatal errors.) |
| 08:24 | <MikeSmith> | SimonSapin: ok |
| 08:26 | <MikeSmith> | annevk: well the difference is you're not also building some tree/DOM-like thing from it (which among other things requires a lot more memory than just putting the source into memory) |
| 08:26 | <MikeSmith> | but I agree it's not real streaming |
| 08:28 | <SimonSapin> | And so far I’m only guessing what the original poster of https://github.com/servo/html5ever/issues/149 is trying to do |
| 08:28 | <annevk> | MikeSmith: well even if you buffer the whole document you'll still need to create some tree, no? To be able to modify it and place that <p> before <table>? |
| 08:29 | <MikeSmith> | annevk: yeah but it can just be a much smaller and simpler stack |
| 08:30 | <MikeSmith> | I think Henri's parser keeps a few different stacks for that and other things |
| 08:30 | <MikeSmith> | but it never builds a tree of the entire document, nor needs to |
| 08:30 | <MikeSmith> | it mostly just passes on the events |
| 08:31 | <MikeSmith> | well, or in the end that's all the SAX API exposes, just eventsーstartElement, endElement, etc. |
| 08:35 | <jgraham> | annevk: Well it seems like it almost is? |
| 08:35 | <annevk> | now you're making me look |
| 08:36 | <jgraham> | annevk: I mean if I have <iframe src="someting that causes a network error or CORS error"></iframe> I *think* you end up in https://html.spec.whatwg.org/#read-ua-inline |
| 08:37 | <jgraham> | But then it's entirely unclear what e.g. iframe.contentDocument should be |
| 08:37 | <annevk> | step 22 of navigate seems to leave a bunch of things up to the user agent |
| 08:38 | <annevk> | it includes network errors in "some sort of processing that will not affect the browsing context" |
| 08:39 | <annevk> | jgraham: so yeah, I guess I don't really know |
| 08:40 | <jgraham> | I don't see how network errors will "not affect the browsing context" given that the normal implementation is to navigate to an error page |
| 08:41 | <annevk> | agreed |
| 08:42 | <jgraham> | The context here is SW tests that try to check that a CORS-forbidden resource didn't load |
| 08:42 | <jgraham> | Do you agree that checking that the iframe either has a null contentDocument or has a contentDocument but the contents are not the contents of the resource that was expected to load is reasonable per-spec |
| 08:42 | <jgraham> | ? |
| 08:42 | <annevk> | I'm not sure what to tell you. You know better than anyone that navigate is a mess... |
| 08:43 | <jgraham> | Well yes :) |
| 08:43 | <annevk> | Yeah, that seems reasonable, but I would prefer a "TODO" comment there that suggests further work is needed to narrow it down to one or the other |
| 08:44 | <jgraham> | Sure, I'll file a spec bug later today and we can link that |
| 09:37 | <JakeA> | annevk: What redirect mode is CSS fetched with? What is it about the CSS fetch that allows relative URLs to work after redirects? |
| 09:37 | <annevk> | JakeA: nothing |
| 09:38 | <JakeA> | annevk: as in, it's not defined, or it doesn't need to be defined? |
| 09:38 | <annevk> | JakeA: it is defined and changes the default if you use fetch() |
| 09:39 | <annevk> | JakeA: we discussed this about fetch() vs event.default() |
| 09:39 | <annevk> | It wasn't seen as a problem... |
| 09:39 | <JakeA> | I'm not saying it is |
| 09:39 | <JakeA> | Just trying to follow it through the fetch spec |
| 09:40 | <annevk> | <link rel=stylesheet href=/x> ends up with /x being the base URL, regardless of what fetch("/") actually results in |
| 09:40 | <annevk> | it's no different from <img src=/x> |
| 09:41 | <JakeA> | annevk: ahh I see, so a normal fetch updates locationURL, which the CSS uses as its base? |
| 09:42 | <annevk> | no, fetch() doesn't update the URL |
| 09:42 | <annevk> | actually, I'm not even sure how to parse that sentence |
| 09:42 | <annevk> | locationURL is not a thing |
| 09:43 | <JakeA> | "Let locationURL be the result of parsing location with request's current url." |
| 09:43 | <JakeA> | Ahh, but that's appended to the request's url list |
| 09:43 | <JakeA> | I guess it's that that CSS uses to get its base url? |
| 09:44 | <annevk> | Again, if the request from the page is for /x, /x is the base URL even though fetch("/x") may follow many redirects |
| 09:45 | <annevk> | The `locationURL` stuff is completely local to the fetch() happening in the service worker |
| 09:46 | <JakeA> | annevk: I'm not talking about fetch(), I'm talking about how the part of the spec that requests CSS sets the base url correctly. |
| 09:46 | <JakeA> | I'm talking about without a SW |
| 09:46 | <annevk> | I see |
| 09:47 | <annevk> | JakeA: basically step 10 of "main fetch" |
| 09:47 | <annevk> | JakeA: https://fetch.spec.whatwg.org/#concept-response-url is the URL eventually used |
| 09:48 | <JakeA> | annevk: gotcha, cheers |
| 09:49 | <annevk> | (That note has a type s/request/response/ which I'll fix.) |
| 09:49 | <annevk> | typo |
| 10:15 | <annevk> | JakeA: so are you still figuring out what the complete picture should be for redirects? |
| 10:15 | annevk | has nearly fixed https://github.com/whatwg/fetch/issues/70 |
| 10:21 | <ondras> | hmh |
| 10:21 | <ondras> | https://github.com/ModuleLoader/es6-module-loader |
| 10:21 | <ondras> | is some kind of baseurl supported with the es6 module loader? |
| 10:21 | <ondras> | the docs are only relevant for the 0.16 branch, that is outdated |
| 10:22 | <ondras> | and the 0.17 does not support System.baseURL. Is this feature present in the spec? |
| 10:31 | <JakeA> | annevk: trying to :) I think between opaque redirects and useFinalUrl (or whatever it gets called) we probably don't need event.default() - but just running it through my head |
| 11:03 | <MikeSmith> | fyi I just now deployed a somewhat disruptive change to the production W3C validator |
| 11:04 | <MikeSmith> | if anybody notices that the sky seems to be falling as result please ping me |
| 11:05 | <MikeSmith> | e.g., rage in the twitter-sphere or wherever about it breaking somebody's thing |
| 11:06 | <MikeSmith> | the validator is serving at least 9-10 validation requests a second so I'd imagine it will get noticed pretty quickly |
| 11:21 | <JakeA> | annevk: how are you feeling about the security the opaque redirect? Does it need further review? I could try and find someone for that |
| 11:22 | <annevk> | JakeA: I'm pretty confident with my outline |
| 11:22 | <annevk> | JakeA: the only thing I'm less sure about is exposing "manual", but I guess I should just do it |
| 11:23 | <annevk> | As in, I wonder if it's a good enough term and such |
| 11:24 | <JakeA> | annevk: would a cross-origin manual-redirect fetch be a network failure? |
| 11:25 | <annevk> | That's also a good question |
| 11:25 | <JakeA> | I shouldn't be able to detect redirects from other origins, and the different type would reveal that |
| 11:26 | <annevk> | You can already detect them with CSP |
| 11:26 | <annevk> | And now also with fetch(url, {redirect:"error"}) |
| 11:26 | <JakeA> | hah, didn't realise CSP exposes that |
| 11:26 | <JakeA> | that's kinda suprising |
| 11:27 | <annevk> | WebAppSec, despite the name, is not great at SOP |
| 11:27 | <annevk> | (or redirects) |
| 11:28 | <annevk> | JakeA: I guess the other question is whether request /a with a opaque redirect whose url is /test should work |
| 11:29 | <annevk> | Restricting them to only those navigation requests that can handle them in the first place seems kind of nice |
| 11:29 | <annevk> | And further reduces the complexity tax |
| 11:30 | <JakeA> | annevk: yeah, I agree with you on that |
| 11:31 | <annevk> | JakeA: I guess I'll add all these restrictions for now, same-URL, same-origin |
| 11:32 | <annevk> | JakeA: it will handle navigate |
| 11:32 | <annevk> | and then we can see from there |
| 11:33 | <JakeA> | annevk: Just to check we're talking about the same thing, where are you going to make it fail? fetch(url, {redirect: "manual"}) should be able to return an opaque redirect, but if the SW returns it & the request isn't a navigation request, it'll fail. |
| 11:33 | <JakeA> | Is that what you're thinking? |
| 11:33 | <annevk> | it would fail if url is not same-origin |
| 11:34 | <annevk> | and it would fail if the response's url field from the SW does not match url |
| 11:35 | <JakeA> | same-origin makes sense |
| 11:35 | <JakeA> | annevk: what badness does the URL check prevent? |
| 11:37 | <annevk> | It would prevent creating a new code path that doesn't exist today |
| 11:38 | <JakeA> | I guess we can always open it out later |
| 11:38 | <annevk> | If I navigate to "/x" and the SW returns a redirect whose url is "/y" (redirecting to "/z"), the UA would have to redirect from "/x" to "/z" |
| 11:39 | <JakeA> | Yep |
| 11:39 | <annevk> | And not hit "/y", which is likely problematic |
| 11:39 | <JakeA> | Some potential weirdness with relative urls there too |
| 11:39 | <annevk> | I don't know, maybe it's okay |
| 11:40 | <JakeA> | We already allow returning a redirect to anywhere |
| 11:41 | <annevk> | That is true, but user agent code around redirects is even more fragile than I thought, so I'm a bit worried |
| 11:44 | <annevk> | Perhaps the navigate restriction is enough for now. I can't really think of anything bad with that restriction plus the opaqueness |
| 11:44 | <annevk> | Other than potential impl issues, but impls can raise those separately |
| 12:58 | <MikeSmith> | annevk: btw looking further at Henri's SAX-API parser code, I realize I was talking out of my hat earlier |
| 12:58 | <MikeSmith> | as far as it not building a full tree |
| 12:58 | <MikeSmith> | https://github.com/validator/htmlparser/tree/master/src/nu/validator/saxtree |
| 12:59 | <MikeSmith> | it's even called "saxtree", which should have been a clue to me |
| 14:37 | <Ms2ger> | philipj, any news on https://code.google.com/p/chromium/issues/detail?id=310450 ? |
| 14:38 | <philipj> | Ms2ger: no, I haven't really made any attempt at all since I filed it |
| 14:38 | <philipj> | is it a site compat problem? |
| 14:39 | <philipj> | I presume you've also seen the discussion I and roc are having on the WHATWG mailing list? |
| 14:39 | <philipj> | somewhat related, at least |
| 14:39 | <Ms2ger> | No, I was just cleaning out old emails |
| 14:40 | <philipj> | OK, let me know if you're having trouble with that default in particular, that would be a reason to bump its priority over the other gazillion :) |
| 14:41 | <Ms2ger> | philipj, if you have a test in wpt, I can have some newcomer pick it up :) |
| 14:41 | <philipj> | Ms2ger: The problem with preload and wpt is that the spec just doesn't say much normative at all :/ |
| 14:41 | <Ms2ger> | \o/ |
| 14:42 | <philipj> | We wrote some pretty elaborate buffering tests for preload behavior for Presto, but there's just no justification for it in the spec, so they were removed during upstreaming |
| 14:42 | <philipj> | maybe we should have a "stuff we agree on even though the spec allows for differences" test suite :) |
| 14:43 | <Ms2ger> | I think that would make sense |
| 14:44 | <philipj> | maybe some way to mark tests as optional in wpt? |
| 14:44 | <Ms2ger> | jgraham, ^ |
| 15:01 | <jgraham> | I guess? I mean I don't really like the idea of optional tests |
| 15:03 | <Ms2ger> | I generally think that more test coverage in CI is nice, even if there's disagreement about whether a FAIL is a failure |
| 15:07 | <gsnedders> | SimonSapin: FWIW, I think admitting fatal errors probably is useful for some uses (mostly when you're dealing with large corpora and trying to do analysis of it, and rejecting some inputs doesn't hurt too much) |
| 15:08 | <gsnedders> | philipj: are thy in t/core? |
| 15:08 | <gsnedders> | philipj: like, the dump of it? |
| 15:09 | <philipj> | gsnedders: yeah, the tests exist in public |
| 15:09 | <philipj> | they were even part of a wpt review that maybe I could dig up if you're very curious |
| 15:10 | <gsnedders> | nah, not really |
| 15:10 | <gsnedders> | :) |
| 15:10 | <philipj> | in any case, they are or have been somewhere in https://github.com/operasoftware/presto-testo/tree/master/core/standards/web-apps/media |
| 16:45 | <Ms2ger> | Any reason https://terinjokes.github.io/console-spec/ isn't on spec.whatwg.org? |
| 16:49 | <annevk> | Ms2ger: I guess it isn't quite ready yet |
| 16:54 | <annevk> | https://twitter.com/domenic/status/620998989144530944 still waiting for whatwggreen |
| 16:57 | <annevk> | terinjokes: <3 console spec logo |
| 16:59 | <giltayar> | Who's working on script type="module"? |
| 17:01 | <annevk> | giltayar: dherman is |
| 17:16 | <webzen> | hi |
| 17:16 | <botie> | what's up, webzen |
| 17:16 | <webzen> | i'm stuck http://laravel.io/bin/321ne |
| 17:16 | <webzen> | trying to bundle |
| 17:21 | <webzen> | please :-) |
| 17:30 | <annevk> | https://twitter.com/w3cmemes/status/621008028578349056 is pretty excellent trolling on several levels |
| 17:30 | <annevk> | kudos |
| 18:02 | <smaug____> | heh |
| 19:01 | <arno_> | Hi, I have a question about CanvasRenderingContext2d.putImageData |
| 19:01 | <arno_> | spec says that "Throws a NotSupportedError exception if any of the arguments are not finite." |
| 19:02 | <arno_> | https://developers.whatwg.org/the-canvas-element.html#pixel-manipulation |
| 19:02 | <arno_> | but idl spec says that "If x is NaN, +Infinity or −Infinity, then throw a TypeError." (when converting to double) |
| 19:03 | <arno_> | http://www.w3.org/TR/WebIDL/#idl-double |
| 19:03 | <arno_> | this seems conflicting to me. So I'm wondering if that's that a bug in the spec, or if did miss something? |
| 19:04 | <Domenic> | Hmm that sounds like a bug |
| 19:05 | <Domenic> | arno_: already fixed in latest spec https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-putimagedata |
| 19:05 | <Domenic> | sadly developers.whatwg.org is old :( |
| 19:06 | <arno_> | Domenic: I still see it |
| 19:06 | <arno_> | Throws a NotSupportedError exception if any of the arguments are not finite. |
| 19:06 | <arno_> | https://html.spec.whatwg.org/multipage/scripting.html#pixel-manipulation |
| 19:06 | <Domenic> | arno_: oh, that's in the non-normative description |
| 19:06 | <Domenic> | yeah i guess that's a bug |
| 19:06 | <Domenic> | mind filing it? should be able to just select the text and click something in the lower-riught |
| 19:07 | <arno_> | oh. It turns out it's already filled |
| 19:07 | <arno_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=28327 |
| 19:07 | <arno_> | Domenic: thanks for the help |
| 19:09 | <Domenic> | Gosh, wouldn't it be nice if HTML was something you could pull request... |
| 20:03 | <wanderview> | Domenic: in chrome's implementation... does response.body.cancel() effectively cancel the backing fetch? |
| 20:03 | <Domenic> | wanderview: yep |
| 20:03 | <wanderview> | Domenic: do we need that cancelable promise thing for fetch then? |
| 20:03 | <Domenic> | wanderview: yes, if we want to cancel before headers arrive |
| 20:04 | <wanderview> | right |
| 20:04 | <wanderview> | ok |
| 20:54 | <jsbell> | Ms2ger: In wpt's FileAPI tests, there are assertions that e.g. "te(xt/plain" is not a valid type - https://github.com/w3c/web-platform-tests/blob/master/FileAPI/blob/Blob-slice.html#L165 - do you know where that requirement comes from? Assertions fail in Gecko and Blink, doesn't match spec. (I can PR to fix, just wondering about the history) |
| 21:11 | <smaug____> | in chromium how does one reply to a message event in serviceworker? |
| 21:11 | <smaug____> | event.source seems to be null there |
| 21:15 | <Ms2ger> | jsbell, it used to say that at least |
| 21:16 | <Ms2ger> | jsbell, I'd be glad to see fixes to current spec |
| 21:24 | <jsbell> | Hrm, wonder if he meant "to align with spec" or "to align spec with tests" |
| 21:36 | <jgraham> | jsbell: I'm pretty sure he means "so that tests and spec and impementations all align" |
| 21:37 | <annevk_> | jsbell: step 5 https://w3c.github.io/FileAPI/#constructorBlob |
| 21:37 | <annevk> | I think it used to do an actual MIME type check... not sure why that got removed again |
| 21:38 | <jsbell> | yep |
| 21:38 | <annevk> | Implementers are so lazy when it comes to data types |
| 21:38 | <annevk> | Languages, MIME types, encoding labels, ... |
| 21:39 | <jsbell> | yep => those steps don't ensure it's a "parsable MIME type", just that anything non-ASCII => "", otherwise just lower-cased |
| 21:39 | <annevk> | that spec is a bit of a mess |
| 21:39 | <jsbell> | the 2012 version had a bit more verbiage but I think it was normatively the same |
| 21:45 | <annevk> | philipj: smaug____: https://github.com/whatwg/dom/issues/54 |
| 21:55 | <smaug____> | hmm, maybe |
| 21:55 | <smaug____> | probably |
| 22:06 | <Domenic> | :D |
| 22:33 | <sicking> | Domenic: I suspect it'll be easier to add a subclass to Array that has .item(), than to try to deprecate .item() on an API-by-API basis |
| 22:34 | <Domenic> | sicking: fair enough, yeah |
| 22:34 | <sicking> | Domenic: i agree that it sucks though. |
| 22:34 | <sicking> | Domenic: i guess we could even try to add Array.prototype.item... that seems unlikely to work though |
| 22:36 | <Domenic> | sicking: yeah a subclass seems preferable to that. Although I imagine the writers of Web IDL binding code will not be as excited about another custom type :P |
| 22:36 | <sicking> | meh, I think that's the least of our problems |
| 22:37 | <Domenic> | I dunno, I got pretty strong pushback trying to make DOMException a custom type (like ES Errors) instead of a WebIDL-defined one. |
| 22:37 | <Domenic> | I guess the payoff is higher here |
| 22:37 | <sicking> | Other than the sadness of the confusion of having some Arrays with .item, and some without .item, Gecko's first problem would be that we don't support subclasses of natives yet |
| 22:37 | <Domenic> | I hear that's almost there... |
| 22:38 | <sicking> | yeah. I don't know what "almost" means though |
| 22:38 | <sicking> | but yeah, i've heard that too |