| 00:07 | <jamesr_> | what happens to those? |
| 00:08 | <jamesr_> | ah, generate parse errors |
| 00:09 | <jamesr_> | shouldn't be too bad if you're already in the error handling state to check back for what the error was |
| 00:09 | jamesr_ | handwaves wildly |
| 00:24 | <gsnedders> | jamesr_: But you need to know you're parsing for document.write |
| 00:25 | <gsnedders> | jamesr_: On the other hand, they can only occur when you're in the document.write case… |
| 00:25 | <gsnedders> | hmmm… |
| 00:25 | <gsnedders> | maybe this can be done more reasonably than I thought… |
| 00:28 | <zewt> | do you mean real lone surrogates, or temporary lone surrogates that get completed with the next document.write() call (which I thought worked, though I don't think I've tested it myself) |
| 00:32 | <gsnedders> | They do work. Really I want stats for both, but if nothing has lone surrogates, then there aren't temporary lone surrogates. |
| 00:41 | SamB | wonders if there's any code out there that works in chunks and would have temporary lone surrogates more-or-less at random |
| 00:42 | <zewt> | that's been the theory |
| 00:44 | SamB | wonders what sort of thinking would motivate the sort of code that might split surrogate pairs across chunks on the client-side ... |
| 00:44 | <zewt> | pretty easy if you're getting data over the network in fixed-sized blocks, i just don't know why you'd do that with document.write |
| 00:47 | <SamB> | zewt: yeah, I thought of that possible motivation |
| 02:05 | <karlcow> | wrong test? or bug? http://www.w3c-test.org/html/webappapis/scripting/processing-model-2/compile-error-data-url.html |
| 02:06 | <caitp> | probably both |
| 02:09 | <caitp> | well nightly comes closer to passing it than chrome stable |
| 02:12 | <Hixie> | the answers to your questions lie in the specification :-) |
| 02:14 | <caitp> | "the specification" |
| 02:15 | <caitp> | "the" |
| 02:17 | <caitp> | but, for what it's worth, the DOM specs on the w3c don't seem to cover onerror in any significant detail, and neither the webapps spec nor fetch seem to say anything about the "content" of a data-url being url encoded |
| 02:18 | <karlcow> | hm might have found a bug in a test. jgraham where is the best place to report a bug. |
| 02:18 | <Hixie> | the whatwg html standard defines onerror. |
| 02:18 | <karlcow> | http://www.w3c-test.org/html/semantics/grouping-content/the-blockquote-element/grouping-blockquote.sub.html |
| 02:18 | <karlcow> | second test |
| 02:19 | <caitp> | i guess the url spec says to percent encode things, maybe |
| 02:19 | <karlcow> | {actual: "blehblah", resolved: document.location.protocol + "//" + document.location.host + "/blehblah"}, |
| 02:19 | <karlcow> | the document.location.path is missing. |
| 02:23 | <karlcow> | s/path/pathname/ |
| 02:23 | <caitp> | the definition in the html spec seems idetical to the webapps definition, which doesn't specify whether or not source should be urlencoded |
| 02:47 | <Hixie> | the webapps definition includes how to process a <script> element?! |
| 03:09 | <Hixie> | holy cow, i got a tree constructor test all the way through my parser to "stop parsing" |
| 03:10 | <Hixie> | of course it promptly crashed because the output verifier isn't implemented yet... |
| 03:34 | <Hixie> | hm |
| 03:34 | <Hixie> | what order are the attributes in tree constructor tests? |
| 03:37 | <Hixie> | ah, it does say "sorted lexicographically" |
| 03:37 | <Hixie> | good good |
| 04:16 | <MikeSmith> | Hixie: I forgot what reason you're implementing a parse for |
| 04:17 | <MikeSmith> | *parser |
| 04:18 | <Hixie> | for my new pipeline |
| 04:19 | SamB | pretends to imagine trying to parse HTML in silicon |
| 04:28 | <Hixie> | woot, my parser passes one tree constructor test! |
| 05:31 | <karlcow> | html5 parsing <font face…><form…> markup </form></font> https://github.com/webcompat/web-bugs/issues/74 |
| 06:09 | <zcorpan> | intredasting. commented |
| 06:10 | <zcorpan> | ("<font face…><form…> markup </form></font>" by itself is fine) |
| 06:10 | <zcorpan> | Hixie: AAA disassociating form controls broke the above site |
| 06:32 | <karlcow> | zcorpan: thanks for the comment |
| 06:33 | <karlcow> | I tried with any inline elements and indeed it kicks in every time. |
| 06:34 | <zcorpan> | karlcow: my knee-jerk reaction is that this is probably uncommon enough (since it hasn't come up until now) that it's not worth fixing in the spec |
| 06:34 | <zcorpan> | karlcow: similar to "<table><form><tr><td><input>" in innerHTML (which has come up but not so often) |
| 06:35 | <karlcow> | yeah… I wonder if it's worth fixing instead of trying to convince the Webmaster to fix his Web site. |
| 06:35 | <karlcow> | Specifically when it will soon not work anywhere |
| 06:35 | <zcorpan> | they maintained the site enough to notice that there was a problem and add big fat warnings about it |
| 06:36 | <zcorpan> | they could have fixed the markup instead |
| 06:36 | <zcorpan> | (note that AAA doesn't trigger for any inline, just a handful of elements) |
| 08:13 | <jgraham> | karlcow: On the web-platform-test github page, perhaps? I'm not really sure |
| 08:16 | <annevk> | I have some plans on merging XMLHttpRequest into Fetch as they are intertwined. Is there some way to put all of XMLHttpRequest's history into Fetch whenever I get around to that? |
| 08:20 | <jgraham> | annevk: Yes |
| 08:21 | <tobie> | annevk: do you intend for the fetch API to replace xhr in devs' toolboxes? |
| 08:22 | <annevk> | tobie: yeah I guess |
| 08:22 | <annevk> | tobie: at some point I'll stop adding features to XHR |
| 08:24 | <annevk> | jgraham: great |
| 08:24 | <tobie> | annevk: so I understand the editorial reason for merging the two specs, but my gut reaction is that it's sending the wrong message wrt to the above. |
| 08:26 | <annevk> | tobie: I don't think that's going to be a problem |
| 08:26 | <annevk> | tobie: we define legacy features in tandem with new features all the time |
| 08:26 | <karlcow> | jgraham: thanks. https://github.com/w3c/web-platform-tests/issues/1042 |
| 08:28 | <tobie> | annevk: yeah, I guess if those are marked clearly. |
| 08:49 | <annevk> | tobie: I'd just name the section "Legacy XMLHttpRequest API" |
| 08:50 | <tobie> | annevk: <3 |
| 08:50 | <tobie> | annevk: how polyfillable is fetch? |
| 08:51 | <annevk> | tobie: large parts can be polyfilled, but without proxy server you can't do "No CORS" |
| 09:27 | <JakeA> | annevk: been chatting to abarth. Seems like we used to still render an <img crossorigin> that failed its CORS check, but it couldn't be used on a canvas. This sounds sensible and the same behaviour we'd want for the SW cache. Apparently Jonas fought for <img crossorigin> to break on CORS failure, any idea why? |
| 09:27 | <annevk> | JakeA: dunno |
| 09:27 | <JakeA> | annevk: no worries, will bug him about it later |
| 10:09 | <annevk> | JakeA: did he say anything about CORS without opt-in? |
| 10:09 | <JakeA> | annevk: he said it was a stupid idea and I should be ashamed of myself |
| 10:09 | <JakeA> | (he didn't quite put it like that) |
| 10:11 | <annevk> | heh |
| 10:13 | <annevk> | JakeA: so the remaining issues are Response.prototype.type; a better definition of multipart/form-data so we can go both ways (not high priority for me at the moment); finding out the best representation of headers both close-to-the-metal and high-level API-wise; and actually defining all the various things |
| 10:14 | <annevk> | JakeA: and then for service workers we need to figure out what we need to do with Response objects (or their corresponding responses) coming from service workers |
| 10:34 | <JakeA> | annevk: I'm still keen on .type reflecting the filtering. So "basic", "cors", "opaque" "error" |
| 10:34 | <annevk> | JakeA: yeah I think it makes sense to expose that. Hopefully the security guys are paying attention |
| 10:36 | <JakeA> | annevk: we already expose the difference between "opaque" and "error" though the promise resolve/reject |
| 10:36 | <JakeA> | annevk: I guess image load events do the same, although only for images |
| 10:36 | <annevk> | JakeA: yeah and also through load/onerror in <img> and such |
| 10:36 | <JakeA> | SNAP |
| 10:36 | <JakeA> | I win |
| 10:36 | <annevk> | JakeA: heh |
| 10:37 | <annevk> | JakeA: if SW declines to handle a request and that request ends up doing HTTP auth (due to 401) the subsequent request will also not go through SW |
| 10:38 | <annevk> | JakeA: see the text under 401 in HTTP fetch |
| 10:38 | <annevk> | JakeA: that seems like the right thing |
| 10:43 | <JakeA> | annevk: yeah, that feels right |
| 10:47 | <annevk> | I would have liked if the people working on HTTP were a bit more opinionated on what a good header representation makes |
| 10:47 | <annevk> | You'd think that if you worked on HTTP for a good decade you'd know what you want |
| 10:50 | <Ms2ger> | Ask ChrisMorgan in ircmo #rust |
| 10:58 | <annevk> | Ms2ger: he's not around |
| 10:58 | <Ms2ger> | Oh, right |
| 10:58 | <Ms2ger> | He's somewhere in Australia, IIRC |
| 10:59 | <annevk> | Just like mnot, that doesn't work |
| 11:01 | smaug____ | lost the conversation about making data url handling inconsistent |
| 11:01 | <smaug____> | I think it was in webapps |
| 11:01 | <annevk> | smaug____: I moved it to WHATWG |
| 11:01 | <smaug____> | oh, there it is |
| 11:07 | <annevk> | Ms2ger: is he just working on an HTTP library or he has extensive knowledge about the compat issues and why browser and potentially proxy implementations are weird? |
| 11:46 | <Witget> | Hi people. Who can help with adding a meta tag in http://wiki.whatwg.org/wiki/MetaExtensions |
| 11:46 | <Witget> | ? |
| 12:12 | <annevk> | Witget: pm me a desired username and email |
| 12:36 | <zcorpan_> | MikeSmith: https://critic.hoppipolla.co.uk/r/1739 |
| 13:27 | <annevk> | JakeA: I guess if you do Response.redirect() the resulting Response object should have a type that's "redirect"? Seems fine to me |
| 13:27 | <annevk> | JakeA: just not if it's a network redirect |
| 13:37 | <JakeA> | annevk: I don't think it needs it. It'd just be "basic" |
| 13:38 | <JakeA> | annevk: it's just a factory that sets the headers |
| 13:40 | <annevk> | Hmm, I guess it would be a bit annoying to define it accurately |
| 13:41 | <annevk> | I'll kill redirect for now |
| 13:43 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/287 makes me want to kill the * thing again |
| 13:44 | <annevk> | JakeA: exact match should win I think |
| 13:44 | <annevk> | JakeA: it is somewhat confusing though |
| 13:45 | <JakeA> | annevk: so /foo beats /fo* and /foo*? I agree it makes most sense. I just don't know how useful single path matches are vs the complication they bring |
| 13:46 | <JakeA> | I've tried to get Alex to drop them in the past |
| 13:47 | <annevk> | I don't know |
| 13:47 | <annevk> | I was in favor of starting out with origin-only |
| 13:48 | <JakeA> | I like scope, it's been useful in github pages during my testing |
| 13:57 | <annevk> | JakeA: do you make sure to make a copy of Request/Response when you store them in the database? |
| 13:57 | <annevk> | JakeA: seems like we need to support structured clones |
| 13:58 | <JakeA> | annevk: Yeah, they should be structured cloneable |
| 14:11 | <annevk> | darobin: what specs manipulate JSON? |
| 14:11 | <darobin> | JSON forms, JSON-LD, manifest |
| 14:11 | <darobin> | just off the top of my head |
| 14:12 | <darobin> | I wouldn't be surprised if we saw more showing up now and then |
| 14:12 | <annevk> | darobin: oh, mostly vaporware :p |
| 14:12 | <darobin> | huhu |
| 14:12 | <annevk> | darobin: that bug was about a parsed representation btw, not serialized |
| 14:12 | <darobin> | annevk: precisely |
| 14:29 | <annevk> | JakeA: defined redirect(), except for one thing, the url of the new object |
| 14:29 | <annevk> | JakeA: we haven't really discussed how to handle urls for synthetic responses yet |
| 14:30 | <arunranga> | annevk, once we use a parsed URL for scheme data, is the current string-based origin extraction sufficient? It’s what implementations do right now. |
| 14:31 | <annevk> | arunranga: is it? afaik Chrome uses a tuple for origin |
| 14:31 | <annevk> | arunranga: not a single string |
| 14:31 | <annevk> | arunranga: e.g. to determine if something is a secure origin we'd look at the scheme of the origin only, for that you'd need to parse it |
| 14:32 | <arunranga> | annevk, but you can extract scheme from the string. |
| 14:32 | <arunranga> | Chrome’s implementation seems to “tag” a blob URL with an origin, serialized as a string. |
| 14:32 | <annevk> | arunranga: there's an alternative way of doing this of course, which is that I check that windows's associated document's origin serialized + "/" is a substring for the blob URL thingie |
| 14:32 | <annevk> | arunranga: then you don't have to extract |
| 14:32 | <JakeA> | annevk: What is response.url used for when it comes to constructed responses? |
| 14:32 | <annevk> | JakeA: dunno |
| 14:33 | <JakeA> | annevk: I think it's redundant so can be null |
| 14:33 | <annevk> | JakeA: so I fetch an image with CORS from http://www.google.com/spoofinggoogle |
| 14:33 | <annevk> | JakeA: the SW replies with a custom response |
| 14:34 | <annevk> | JakeA: is that URL now associated with a safe response somehow? might be bad? |
| 14:34 | annevk | isn't really sure |
| 14:35 | <arunranga> | annevk, Chrome uses a string, but tuples are themselves extractable from it: blob:http%3A//www.w3.org/3fb1659b-1352-40b0-a029-ce91536696ea |
| 14:35 | <JakeA> | annevk: I think it's fine. The SW could also respondWith(fetch('/local.png')) |
| 14:35 | <arunranga> | ^ the “/“ separates a UUID from the origin |
| 14:35 | <annevk> | arunranga: how do you know it uses a string? |
| 14:35 | <arunranga> | So it isn’t quite a tuple. |
| 14:36 | <JakeA> | annevk: You can shoot yourself in the foot if you want, but I don't think it's harmful to anyone else |
| 14:44 | <arunranga> | annevk: Blob URLs *are* strings; seems like origins were implicit but we’ve now made them explicit by appending them to a string. |
| 14:45 | <annevk> | arunranga: I understand that you have a string representation of an origin, we were talking about extracting the origin for internal use |
| 14:46 | <annevk> | arunranga: what is the origin of a blob URL you navigate to? |
| 14:46 | <arunranga> | annevk: would extracting a string (generated by the Origin Spec’s Unicode Serialization of an Origin algo.) be insufficient? Internally tuples can be generated from the string. |
| 14:46 | <ChrisMorgan> | annevk: I’m sorry to say that I don’t have much experience in the practical nastinesses of how proxies and such behave. My background—not a terribly long one either, by the way, I’m only 22, though I’ve worked with the web for just on half my life now—is more in web application development. |
| 14:47 | <annevk> | hey ChrisMorgan |
| 14:47 | <annevk> | ChrisMorgan: the relevant issue is tracked here https://github.com/slightlyoff/ServiceWorker/issues/300 |
| 14:47 | <ChrisMorgan> | I just had strong opinions on things like header representation, which led me to working in Rust for the past year or so, doing strongly typed HTTP and such. |
| 14:48 | <annevk> | ChrisMorgan: please be sure to read the referenced Gecko code as it might put some constrains on us |
| 14:48 | <arunranga> | annevk, the Unicode Serialized Origin is what’s nested in the blob: URL. Extracting it is a matter of string parsing. Tuple generation, if necessary for same origin comparision, can be done safely, since the emiter methods emit a safe string. |
| 14:49 | <arunranga> | So I’m not sure recursive parsing is useful. |
| 14:49 | <annevk> | arunranga: if "an origin" is a tuple, you can't just set it to a string |
| 14:49 | <ChrisMorgan> | annevk: I know of Guile and intarweb, two Scheme things that use strongly typed headers, and Spray for Scala. |
| 14:50 | <arunranga> | annevk, would you prefer to do recursive pasing? |
| 14:50 | <arunranga> | Which is to parse the blob: URL recursively for an origin? |
| 14:50 | <annevk> | arunranga: I'm not sure I fully understand all the implications yet of this |
| 14:50 | <annevk> | arunranga: of a blob having an embedded origin that is |
| 14:51 | <annevk> | ChrisMorgan: we can't do much strong typing, this is a JS API |
| 14:51 | <annevk> | ChrisMorgan: it's mostly about whether this should be a map or a list, ... |
| 14:51 | <ChrisMorgan> | annevk: my intent with Teepee is to largely implement the specs as they are and adjust the parsing et al. as necessary, doing large-scale analysis of real life, covering things like the Common Crawl. |
| 14:51 | <zewt> | annevk: what's the functional difference? the origin being anything but a simple string is new to me |
| 14:51 | <arunranga> | Thing is, the origin is already that of the incumbent settings object. Fx’s single process means that we never needed to make it explicit. Multi-process UAs can parse strings for sanity checks; not sure why we need to keep the tuple around, but we could. |
| 14:52 | <annevk> | zewt: e.g. to see if something is a secure origin you check the scheme |
| 14:52 | <annevk> | zewt: see https://w3c.github.io/webappsec/specs/mixedcontent/ |
| 14:52 | <zewt> | then parse the origin to get the scheme from it |
| 14:52 | <annevk> | zewt: yes, either that or origin is already a tuple and setting it to a string is wrong |
| 14:53 | <ChrisMorgan> | Go deals with headers as a mapping of header name strings to an array of strings. |
| 14:53 | <zewt> | if they're functionally interchangeable than neither is wrong |
| 14:53 | <arunranga> | annevk, actually, one thing we can do is parse the origin string and extract a scheme, host, port tuple |
| 14:53 | <zewt> | arunranga: i just said that :P |
| 14:53 | <annevk> | zewt: just depends on what the model is |
| 14:53 | <arunranga> | zewt :) annevk, I’m not sure where the tuple would live. |
| 14:53 | <zewt> | if neither is wrong, having the origin mbe a string to line up with document.location.origin seems most natural, at least at first glance |
| 14:53 | <annevk> | zewt: which is what I asked |
| 14:53 | <arunranga> | Other than being parsed for extraction |
| 14:54 | <ChrisMorgan> | annevk: seems to me that getting sense out of HTTP headers without a strongly typed interface is a futile endeavour… |
| 14:54 | <ChrisMorgan> | (Alas.) |
| 14:54 | <annevk> | ChrisMorgan: the way you described Go does not like super strongly typed, that level of detail works |
| 14:54 | <annevk> | ChrisMorgan: although it also depends a bit on how they parse incoming values I guess |
| 14:54 | <ChrisMorgan> | Indeed, Go is typically pretty weakly typed. |
| 14:55 | <caitp> | indeed. |
| 14:55 | <ChrisMorgan> | I’m not certain how it handles things like `Accept: foo, bar\r\nAccept: baz`, whether ['foo', 'bar', 'baz'] or ['foo, bar', 'baz'], but I would expect the latter. |
| 14:56 | <annevk> | Hmm |
| 14:56 | <ChrisMorgan> | Without knowledge of the grammar of the header, it is impossible to do anything at all. |
| 14:56 | <ChrisMorgan> | Because you need to know whether it’s a list type or not. |
| 14:57 | <annevk> | Well clearly it is possible to do something hence everyone having a generic abstraction |
| 14:57 | <ChrisMorgan> | In RFC 2616-speak, it’s the difference between #(…) and anything else. |
| 14:57 | <ChrisMorgan> | If it is a list, then that earlier example would be foo, bar, baz. If it is not a list, the behaviour is undefined. I’m not certain what the typical behaviour is. |
| 14:58 | ChrisMorgan | is not pleased with any HTTP specs, including HTTP/2; they leave *so* much undefined |
| 14:58 | <annevk> | Yeah okay, seems you got about as far as I did with this |
| 14:58 | <ChrisMorgan> | HTTP/2 even inserts *deliberate* ambiguity of behaviour in a couple of places! |
| 14:59 | annevk | hopes mnot wakes up |
| 14:59 | <annevk> | zewt: typically the underlying model is more complex, and the APIs return something serialized |
| 15:00 | <annevk> | zewt: I'm not sure why origin would be any different |
| 15:00 | <ChrisMorgan> | Header fields `Foo: bar` and `Foo: baz` should NOT be treated as equivalent to `Foo: bar, baz`; only if it is a list is that correect… |
| 15:01 | <ChrisMorgan> | And then of course there’s Set-Cookie… *sigh* |
| 15:02 | <caitp> | it's gonna be okay dude, we can still get hadfield's tweets to the space station |
| 15:04 | <ChrisMorgan> | caitp: sometimes I’d prefer it if it *didn’t* work, because then we’d need to fix it. As it is, “if it ain’t broke, don’t fix it” prevails ☹ |
| 15:04 | ChrisMorgan | agrees with the Varnish author on some of the things he’s saying about HTTP/2 and wishing it would break more |
| 15:06 | <arunranga> | annevk, seems like you’re right: Fetch should totally shoulder request/response pieces. The fact that File APi does it at all is actually a legacy issue. |
| 15:07 | <arunranga> | annevk, but I’m unclear on the bit about URL Parse, namely https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987. Is it assigned to me? If so, what am I missing? |
| 15:08 | <ChrisMorgan> | Oh, by the way, I don’t like CORS much. Especially the way that preflight requests hate 3xx, that I really don’t understand (it says to treat it as a network error!). Working around that has cost several days’ work for a team that I was working with a few weeks ago, changing a thing in the API to use a 2xx status code with a Location header, the JS client manually following the redirect… ☹ |
| 15:09 | <annevk> | ChrisMorgan: seems like you forgot to give feedback somewhere |
| 15:09 | <annevk> | ChrisMorgan: at least, I didn't see it |
| 15:09 | <annevk> | ChrisMorgan: having said that, not sure how we can do that sanely |
| 15:10 | <annevk> | arunranga: it's not clear to me if the current story we have is correct |
| 15:10 | <ChrisMorgan> | annevk: research has shown quite a few people really fed up by that. I wasn’t sure who I should complain to when I discovered this 278 inthe code… |
| 15:10 | <annevk> | ChrisMorgan: is that research published? |
| 15:11 | <annevk> | ChrisMorgan: for starters you can file bugs on the standard: http://fetch.spec.whatwg.org/ |
| 15:11 | <annevk> | arunranga: I have somewhat limited time now |
| 15:11 | <ChrisMorgan> | annevk: “research” == Google, Stack Overflow, Chrome bug tracker, &c. |
| 15:12 | <ChrisMorgan> | Most people seem to figure it a browser bug, but I tracked it through the specs and W3C and WHATWG agree that 3xx is treated as network error :-( |
| 15:12 | <annevk> | ChrisMorgan: pointers welcome if you file a bug |
| 15:12 | <annevk> | Yes I know, I wrote the spec |
| 15:12 | <annevk> | (both of them) |
| 15:13 | <ChrisMorgan> | I see that it’s not the easiest problem, but I was wondering about something like just doing another preflight request if necessary. |
| 15:13 | <ChrisMorgan> | Certainly I haven’t thought all the implications through. |
| 15:13 | <zewt> | annevk: fwiw, the "implicit" blob origin approach seems to sidestep this stuff, since the "real" origin stays internal |
| 15:13 | <ChrisMorgan> | But it is a very annoying limitation. |
| 15:14 | <ChrisMorgan> | CORS as a whole is annoying… but I understand why it is necessary and so there isn’t anything that could obviously be better. |
| 15:14 | <zewt> | one case i noticed where it was visible was when creating a blob URL from inside a file: origin, UAs don't expose the origin, so Chrome gives a bogus "blob:null/uuid" url, but Firefox's "blob:uuid" doesn't care |
| 15:15 | <ChrisMorgan> | annevk: you’ve convinced me, I’ll see about filing a bug about trying to get 3xx to work with preflight requests. |
| 15:15 | <ChrisMorgan> | Probably take a day or two. |
| 15:16 | <zewt> | (the "implicit" approach has its own weirdnesses, like how new URL(blobURL).origin would give different results depending on whether the URL was revoked or not) |
| 15:16 | <ChrisMorgan> | Now, I should go to sleep. |
| 15:18 | <annevk> | zewt: blob:null would be correct as the serialization of a unique ID origin is null |
| 15:18 | <annevk> | zewt: which is another argument as to why origin is not a string |
| 15:19 | <ChrisMorgan> | annevk: sorry I can’t help you more. |
| 15:20 | <zewt> | annevk: if you can't parse the actual origin back out of the blob URL, i think the reasons for the "explicit" origin approach go away |
| 15:20 | <zewt> | maybe not completely, since the URL API would be the same... |
| 15:22 | <zewt> | i guess it means that taking a blob URL and returning its origin would have to dig into the blob URL store (since eg. for file URLs the origin isn't actually in the URL), but the script-visible resulting .origin string would be identical both ways ("null"), only the internal origin would be different |
| 15:23 | <zewt> | i guess that's ugly but not horrible |
| 15:23 | <annevk> | ChrisMorgan: thanks for your thoughts, have a good night |
| 15:24 | <zewt> | though it would become script-visible again if there was something like url.isSameOrigin(url2) |
| 15:29 | <arunranga> | annevk: so is that bug a placeholder bug for tweaking the Fetch story for Blob URLs? I’m not 100% sure what action to take on it, but I can leave what’s currently in http://dev.w3.org/2006/webapi/FileAPI/#requestResponseModel to Fetch. |
| 15:30 | <arunranga> | (by “that bug” I mean Bug 25987) |
| 16:21 | <annevk> | arunranga: it's a bug about what the overall model should be |
| 16:27 | <zewt> | if we want to be able to figure out same-origin for file urls (maybe data too? not following that thread), seems like simple string parsing is out, at least |
| 17:05 | <Ms2ger> | Did I just get an email with an attachment w3c-standard-....docx? |
| 17:05 | <SamB> | Ms2ger: people are crazy sometimes ... |
| 17:09 | <jgraham> | Ms2ger: I don't know, did you? |
| 17:09 | <Ms2ger> | Either I did or I'm hallucinating about public-web-perf |
| 17:10 | <jgraham> | I like to pretend that public-web-perf is all hallucination |
| 17:11 | jgraham | checks a few recent emails, finds that it is still bz suggesting that specs should actually define things, closes the folder again |
| 17:48 | <zewt> | crazytalk |
| 18:14 | <IZh_> | Hixie: Hi. Minory typo. In the Forms section the example of the Pizza form and the example of server query string contains different phone numbers. ;-) |
| 18:15 | <Hixie> | please file all the bugs using the form on the page |
| 18:15 | <Hixie> | i can't track bugs reported on irc :-) |
| 18:16 | <IZh_> | I'll try. At this moment I'm on the phone with very bad internet connection in a subway. :-) |
| 18:17 | gsnedders | tries and work out how the sanest way to parse the parser spec is… |
| 18:19 | <Ms2ger> | Bootstrapping |
| 18:20 | <gsnedders> | :) |
| 18:20 | <gsnedders> | I should probably start off by just creating a list of all sentences in the tokenizer spec |
| 18:22 | <annevk> | zewt: not sure why we'd want to |
| 18:25 | <zewt> | not sure either, wasn't able to construct a test case (postMessage won't post to a file: iframe) |
| 18:26 | <zewt> | well, you should be able to use a blob url created in a file: url within that page |
| 18:27 | <zewt> | and if you're getting the origin by parsing the string, you can't check that since all you have is "null" |
| 18:29 | <annevk> | I'm not too concerned about file URL compat |
| 18:30 | <zewt> | well, it works in browsers today |
| 18:31 | <zewt> | (at least Chrome, on a quick test) |
| 18:34 | <zewt> | same for data: urls, which also give blob:null/uuid urls |
| 18:35 | <zewt> | making blob urls not work inside anything with a unique origin doesn't seem good |
| 18:38 | <annevk> | I guess they always compare against the serialized origin in which case it would always work |
| 18:38 | <annevk> | As I suggested earlier, just serialize the origin and append "/" and see if it's a substring |
| 18:39 | <zewt> | but the serialized origin is just "null", so it wouldn't be comparing that they're the same origin, it'd consider two different "unique origins" as being the same origin since they serialize the same |
| 18:41 | <zewt> | so i guess you could define that to work, but i'd imagine that'd just be defeating the check |
| 18:46 | <annevk> | I don't think it would combined with the fact that the blob URL store is unique per environment |
| 18:46 | <annevk> | As document.domain only works for HTTP URLs |
| 18:49 | <zewt> | i guess it just seems like asking for trouble that if you create a blob URL in two different unique origins, you end up with two URLs that are same-origin with each other |
| 18:50 | <zewt> | no idea what the side-effects would be, just that it seems like unexpected behavior in a security-sensitive value |
| 18:59 | <Philip`> | gsnedders: I tried parsing the parser spec once, and gave up and decided it was way easier and more reliable to just transcribe it into a declarative language by hand |
| 19:04 | <Hixie> | ok well my attempt to define how the JS loader works has kinda run aground before getting started. I guess es-discuss isn't going to be getting much traffic during the f2f. |
| 19:11 | <Hixie> | firefox does such a great job of actually rendering the HTML spec once it's loaded |
| 19:12 | <Hixie> | i wish i had a browser with chrome's load-time behaviour and firefox's render-time behaviour, on the spec... |
| 19:13 | SamB | remembers about that ghost of an idea he had to implement chunking in JS using display:none ... |
| 19:15 | <gsnedders> | Philip`: I know. I cited your mailing list post about that in my BSci thesis ;P |
| 19:16 | <SamB> | I wonder if the same is true of, say, the Relax NG or Relax NG Compact spec ... |
| 19:17 | <SamB> | I remember seeing something that looked suspiciously like a formal semantics in one or both of those ... |
| 19:18 | <gsnedders> | So my attempt to directly translate the spec into a declarative language led to bugs in the transcription |
| 19:18 | <gsnedders> | So I'm unsure about any property proven of that model |
| 19:18 | <gsnedders> | Because I don't trust it models the spec. |
| 19:19 | <Hixie> | bugs in the transcription? |
| 19:20 | <gsnedders> | The transcribed, formal, declarative copy didn't match the spec. |
| 19:21 | <Hixie> | was it an automated transcription? |
| 19:21 | <gsnedders> | No. By hand. |
| 19:22 | <Hixie> | ah |
| 19:22 | <gsnedders> | Unrelated: how is my desk such a mess? |
| 19:25 | <gsnedders> | /Why/ do I have year old train tickets? When am I going to need them? |
| 19:27 | <Philip`> | gsnedders: You should just run it against the test suite until it passes |
| 19:28 | <Philip`> | You'll have to do that anyway, because there's no way to tell your automatic translation thing isn't full of bugs |
| 19:28 | <Huvet> | I get a crash in html5lib==1.0b3 with '<z\uFFFD>' -> ValueError: chr() arg not in range(256) -- is this a known bug? |
| 19:29 | <Hixie> | foolip: ping |
| 19:29 | <Philip`> | gsnedders: and it's much easier to notice and fix bugs in a manual translation, than in a script that's full of regexps that try to pattern-match all the dozens of ways Hixie can phrase the same concept |
| 19:30 | <Hixie> | heh |
| 19:30 | <gsnedders> | Huvet: using lxml? |
| 19:31 | <gsnedders> | Huvet: probably a known bug |
| 19:31 | <Huvet> | gsnedders: yes |
| 19:31 | <Philip`> | qr/Act as if an end tag (?:token )?with (?:the )?tag name "(\S+)" had been seen, (?:and )?then, if that token wasn't ignored, reprocess the current token\./ |
| 19:31 | <IZh> | Why there are no term "positive integer"? There are lots of "non-negative integer greater than zero". |
| 19:31 | <Hixie> | foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24684 |
| 19:31 | <Philip`> | (from my old attempt at a translator) |
| 19:31 | <gsnedders> | Philip`: I was hoping from my brief experiment to do stuff a bit better than that |
| 19:31 | <gsnedders> | IZh: because people get into arguments about what a positive integer is |
| 19:31 | <Hixie> | i recommend just using an NLP library |
| 19:32 | <gsnedders> | Hixie: my plan. |
| 19:32 | Hixie | ducks and runs |
| 19:32 | <gsnedders> | Hixie: Not actually using a full parser, because that';ll never work |
| 19:32 | <gsnedders> | Hixie: But can likely get somewhere |
| 19:32 | <IZh> | gsnedders: Hmm... Is there any another meaning of what positive integer could be? |
| 19:33 | <gsnedders> | (Your grammar is weird in places in the spec. :)) |
| 19:33 | <gsnedders> | IZh: Some include 0. |
| 19:33 | <annevk> | zewt: they wouldn't be able to reach each other since each would have its own unique blob URL store |
| 19:33 | <annevk> | zewt: the additional origin check is only relevant for document.domain purposes afaict |
| 19:33 | <IZh> | gsnedders: I would send them back to school. Zero is not a positive. |
| 19:34 | <Hixie> | gsnedders: i meant some mythical library that literally just understands the spec :-) |
| 19:35 | <annevk> | foolip: wanna cleanup https://code.google.com/p/chromium/issues/detail?id=341854 ? |
| 19:35 | <annevk> | I wish someone on Gecko's end would drop xml:base already |
| 19:36 | <Ms2ger> | Not it |
| 19:37 | <caitp> | is URLUtils.searchParams actually implemented anywhere? |
| 19:38 | <IZh> | Hixie: When ACID4 will be ready? |
| 19:38 | <Ms2ger> | Never |
| 19:39 | <Ms2ger> | The Acid tests have been increasingly bad for the web, so we stopped doing them |
| 19:39 | <annevk> | caitp: Gecko |
| 19:39 | <caitp> | hmm |
| 19:39 | <IZh> | Ms2ger: why bad? |
| 19:39 | <caitp> | that's too bad, it would be really convenient to use them :( I guess that will give me something to hack into blink then |
| 19:39 | <Ms2ger> | Acid2 caused the only quirks-mode / standards-mode difference in the HTML parser |
| 19:40 | <Ms2ger> | And it caused years of confusion about -- in comments |
| 19:40 | <annevk> | I wonder why window.location.searchParams is not a thing |
| 19:40 | <Ms2ger> | Acid3... *sigh* |
| 19:40 | <SamB> | Hixie: it sounds like you need more macros ;-P |
| 19:41 | <Ms2ger> | annevk can give you some examples of what acid3 did... I'm off for today |
| 19:41 | <Hixie> | IZh: probably not until browsers stop caring about standards again |
| 19:41 | <annevk> | Ms2ger: isn't there enough written about that? |
| 19:41 | <Hixie> | Ms2ger: i think the acid tests did lots of good stuff, but for sure they also had some negative side-effects. |
| 19:41 | <Ms2ger> | Sure |
| 19:41 | <annevk> | Yes, it's grey again, not white or black |
| 19:42 | <Ms2ger> | I feel like the good stuff/bad stuff ratio decreased over time, though |
| 19:42 | <caitp> | hmm, I guess writing to searchParams in gecko has no effect, darn. |
| 19:42 | <IZh> | Never thought that tests may harm... |
| 19:43 | <Ms2ger> | If passing them is a goal by itself, regardless of what behaviour it tests for... |
| 19:44 | <IZh> | Looks like I'm very ancient and out-of-dated. ;-) |
| 19:45 | <caitp> | they have surgery to fix that these days, it worked wonders for pete burns |
| 19:47 | <gsnedders> | Hixie: bah, all NLP libraries are terrible, they are pretty much all done based on Chomsky's generative grammars, which is an utterly stupid idea. |
| 19:48 | <gsnedders> | But I'm not getting on that soapbox. :) |
| 19:48 | <gsnedders> | IZh: The problem with the Acid tests is they mostly force people to implement specs that nobody actually cares about and everyone has interoperably broken for years. |
| 19:50 | <IZh> | gsnedders: I see... |
| 19:51 | <Hixie> | actually the acid tests were pretty carefully written to not do that, by and large |
| 19:51 | <gsnedders> | still, a few pretty notable cases (like the comment parsing stuff) |
| 19:51 | <gsnedders> | I think everyone parsed <p><table> the same as well? |
| 19:53 | <Hixie> | well the two things you said are differnet issues |
| 19:53 | <Hixie> | acid2 dates back to the days where we were trying to get browsers to do the right thing in standards mode, rather than fixing the specs. |
| 19:54 | <Hixie> | back before we (I, at least) understand that specs were not stone tablets handed down from on high |
| 19:54 | <Hixie> | understood |
| 19:54 | <SamB> | Hixie: basically, when you were young and naive? |
| 19:54 | <Hixie> | well, naive, anyway |
| 19:56 | <IZh> | Off the topic: I'm waiting for wildcards in css-properties. I don't like to see series of -x-moz, -x-ie, -x-opera, -x-webkit... doing the same things under similar names. Why not use -x-*-something or -x-anyvendor-something? |
| 19:57 | <caitp> | what problem would that solve other than making experimental properties less cumbersome to use in css? |
| 19:57 | <SamB> | IZh: I thought the trend was to just drop the prefixes? |
| 19:59 | <SamB> | and use other mechanisms to discourage use way too early |
| 20:00 | <Hixie> | hahahahaha |
| 20:01 | <Hixie> | "In total, 3190 tests fail to pass in two implementations." "We contend that the specification being proposed for advancement through the process has demonstrated interoperability." |
| 20:01 | <SamB> | how many tests did they have? |
| 20:02 | <zewt> | 3190 |
| 20:02 | <zewt> | (no idea heh) |
| 20:02 | <SamB> | if zewt is right, can we exile the perpetrators |
| 20:02 | <Hixie> | they have about 1000 tests, with about 100 assertions in each test on average |
| 20:03 | <IZh> | SamB: the trend is good. |
| 20:03 | <zewt> | number of assertions beyond the first to fail in a test tends to be meaningless, at least in my tests |
| 20:04 | SamB | is a bit confused at the idea of the test continuing past failed asserts |
| 20:04 | SamB | guesses asserts mean something strange in JS ... |
| 20:04 | <Philip`> | Is it saying there are two implementations which the tests do not pass in, or that there are not two implementations which the tests pass in? |
| 20:04 | <Hixie> | the coverage is pretty anemic. There's some areas that have good coverage, e.g. the canvas features (though not new ones), <video>, and parsing |
| 20:04 | <SamB> | Philip`: lol |
| 20:04 | <Hixie> | Philip`: the latter |
| 20:05 | <Hixie> | for contrast, there are 3539 occurances of the word "must" in the HTML spec |
| 20:06 | <Hixie> | (very few of which are in the parser section) |
| 20:06 | <SamB> | Hixie: what about in the *real* HTML spec |
| 20:07 | <Hixie> | that's the one i was talking about |
| 20:07 | <SamB> | oh |
| 20:07 | <Hixie> | i guess their fork is missing some sections so they'll have fewer |
| 20:07 | <SamB> | I'm kind of surprised by "very few of which are in the parser section" |
| 20:08 | <gsnedders> | the parser section is: "you MUST use the following state machine: [insert thousands of lines of state machine]" |
| 20:09 | <gsnedders> | Hixie: that on public-html? |
| 20:09 | <Hixie> | yeah |
| 20:09 | <Hixie> | SamB: what gsnedders said |
| 20:09 | <SamB> | ah, well, okay |
| 20:09 | <SamB> | I figured it was something like that ... |
| 20:09 | <SamB> | hidden/factored-out musts ... |
| 20:10 | <gsnedders> | Hixie: where? I see no reference to the word "advancement" since 2012? |
| 20:10 | <Hixie> | it was in the -details.html file robin linked to |
| 20:10 | <Hixie> | sorry |
| 20:13 | <gsnedders> | The fun part is the whole sections of the spec with no tests. |
| 20:13 | <gsnedders> | Like #loading |
| 20:13 | <caitp> | that does sound like fun |
| 20:14 | <caitp> | exhilarating |
| 20:30 | <jgraham> | Hixie: is this the HTML spec? |
| 20:31 | <Hixie> | is what the HTML spec? |
| 20:31 | <jgraham> | I think it makes a lot more sense to do that than to hold the spec up until implementors fix all the tests, which they won't |
| 20:31 | <jgraham> | s/tests/bugs/ |
| 20:31 | <jgraham> | The thing about testing |
| 20:32 | <Hixie> | i think it makes perfect sense to publish a patent policy snapshot, for sure |
| 20:32 | <Hixie> | but if they want to do that, why pretend they have a real test suite yet |
| 20:33 | <jgraham> | Hixie: and your assertion that there are 1000 tests with 100 asserts each is just wrong |
| 20:34 | <Hixie> | yeah, i later found http://www.w3c-test.org/html/dom/reflection-embedded.html which alone is 17% of the test suite |
| 20:34 | <Hixie> | so the 100 is more a mean than a median |
| 20:34 | <jgraham> | Counting files just doesn't make any sense |
| 20:35 | <jgraham> | You could put the same 100 tests in 100 files and 100 tests in 1 file |
| 20:35 | <jgraham> | It would be the same amount of testing |
| 20:35 | <SamB> | yeah |
| 20:36 | <Hixie> | sure. i was saying this in the context of robin comparing to the svg and css test suites, where he was citing test file numbers. |
| 20:36 | <Hixie> | svg had ~300 tests, but since each one tested a few hundred thousand pixels, it's more like 300,000,000 test assertions |
| 20:36 | <jgraham> | I think that's an absurd way to look at it |
| 20:37 | <SamB> | indeed |
| 20:37 | <Hixie> | it's not clear to me that numbers are a useful way to look at it at all |
| 20:37 | <Hixie> | what matters is coverage |
| 20:37 | <SamB> | many of those pixels aren't even all that important |
| 20:37 | <Hixie> | SamB: many of the test assertions aren't even all that important too :-) |
| 20:37 | <jgraham> | Not important in a different way |
| 20:38 | <SamB> | I mean, you know, it's not the end of the world if we don't get a byte-for-byte identical rasterization on every renderer |
| 20:38 | <jgraham> | I agree that counting tests isn't a very useful exercise |
| 20:39 | <jgraham> | But I also think that intentionally blocking progress on something we agree is useful for technical reasons is more stupid |
| 20:39 | <Hixie> | well sure. that the process is dumb is something i believe in so strongly that i quit the w3c. |
| 20:39 | <Hixie> | my complaint was in the context of robin saying this test suite was more useful than previous test suites, and trying to justify a huge error rate that way. |
| 20:40 | <SamB> | yeah, lintian actually has lots of tests that test many checks each |
| 20:40 | <Hixie> | (i posted my rant on public-html, fwiw) |
| 20:41 | <jgraham> | I saw |
| 20:41 | <jgraham> | I strongly suspect it is better than past testsuites |
| 20:41 | <SamB> | yeah, somehow I doubt the SVG testsuite outright fails at a single pixel component being off by one ... |
| 20:42 | <Hixie> | the CSS2.1 test suite isn't bad either |
| 20:43 | <Hixie> | i don't have a good handle on the coverage of either the CSS2.1 test suite or the HTML test suite, but the HTML test suite sure has some large holes |
| 20:43 | <Hixie> | (which isn't a criticism of the effort, it's obviously an on-going effort) |
| 20:43 | <Hixie> | (it's only a criticism of an attempt to use it as a proxy for something that has full coverage) |
| 20:44 | <SamB> | basically, I guess what I mean is that having tests fail when there is actually nothing wrong is BAD BAD BAD |
| 20:46 | <Hixie> | where are tests failing when there's nothing wrong? |
| 20:47 | <SamB> | Hixie: well, either there are loads HTML5 tests that are improperly failing, OR interop is actually fairly bad for the tested stuff |
| 20:48 | <Hixie> | interop is actually fairly bad for the tested stuff. |
| 20:48 | <SamB> | you don't just get to hand-wave away the failing tests |
| 20:48 | <Hixie> | the tested stuff that fails, anyway |
| 20:48 | <Hixie> | couldn't agree more |
| 20:48 | <SamB> | even if GDB's test suite *is* a gross offender here |
| 20:48 | <Hixie> | (that's why i predicted REC in 2022, not 2014, back when i cared about this) |
| 20:49 | <Hixie> | the fundamental problem is that the w3c is trying to use a broken process. They want patent coverage, which is a good thing to get ASAP, but their process says they can only get it once they have Proved Interoperability. |
| 20:49 | <Hixie> | there's just no reason they should gate the former on the latter. |
| 20:50 | <SamB> | it basically never goes green, so consequently it's not easy to catch new/reintroduced problems in the bud |
| 20:50 | <SamB> | Hixie: indeed |
| 20:50 | <SamB> | that's insane |
| 20:50 | <SamB> | they should demand the patent stuff ASAP |
| 20:59 | <zewt> | Hixie: i know nothing about the details, but maybe the agreements with people giving patent licenses depend on that, and they're afraid that asking everyone to change that could harm them somehow? (eg. "licenseholders review patent contract and someone decides they're better off keeping their landmines") |
| 21:01 | <Hixie> | not clear on what they could be concerned about |
| 21:01 | <Hixie> | a patent license is always against a specific piece of text |
| 21:01 | <zewt> | (not saying that'd be a good or bad reason, but it'd be a reason that I could parse) |
| 21:03 | <zewt> | it's not the patent license that would change, it's the process for giving the license |
| 21:05 | <zewt> | has the Process(r) for receiving patent licensing changed in recent memory (say, a couple years)? |
| 21:05 | <zewt> | (not an important question, just wondering if changing this would be opening an old box that nobody's modified in a decade, or if it's been dusted off periodically for something or other) |
| 21:05 | <Hixie> | no |
| 21:05 | <Hixie> | it's a decade+ old |
| 21:06 | <zewt> | well, if the compiler for changing the process (getting w3c members to agree to the change, possibly bringing Executives into the picture) hasn't been invoked in a decade, i could at least follow why they'd be uneasy about doing so |
| 21:07 | <annevk> | krit: http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0093.html reads a bit like STFU |
| 21:08 | <zewt> | (in any case i'd hope that the people who would initiate such a change would at least be willing to say in broad terms why they won't do it, so I guess there's not much point in my guessing) |
| 21:08 | <jgraham> | Hand waving away the failing stuff *for the purposes of the Process* is the only pragmatic way to get W3C to put some text under their patent policy and stop focussing on a out of date draft |
| 21:10 | <jgraham> | SamB: You can effectively use a testsuite where tests fail. You just have to know which tests fail |
| 21:10 | <SamB> | jgraham: okay, yeah, that can work too |
| 21:11 | <SamB> | but AFAICT we haven't got that either |
| 21:12 | <zewt> | jgraham: yeah, i guess the "50000 tests are failing, interop success!" silliness is ignorable if the only purpose is to invoke patent agreements (so long as BS'ing the test results like that doesn't jeopardize the license, which I'd hope it doesn't) |
| 21:12 | <jgraham> | SamB: We (Mozilla) do. It's not quite stable enough for production yet, but it works |
| 21:13 | <jgraham> | (and the code we use is open source and can be adapted for other browsers) |
| 21:15 | <krit> | annevk: the opposite is the case. I would like to see progress. You are right that the WG didn't spend a hell of time on fetching and security yet. Especially I didn't have much time. |
| 21:16 | <SamB> | jgraham: I was referring to GDB, in case that wasn't clear |
| 21:16 | <krit> | annevk: I really welcome help on this topic. I added some content so that people feel more encouraged to add stuff to the Wiki. It is less likely that people contribute to an empty Wiki. |
| 21:16 | <SamB> | where it'd tend to be at LEAST arch-dependent |
| 21:17 | <SamB> | and, hmm, I guess some of them depend on e.g. whether libc or gcc was built with "systemtap" probes |
| 21:19 | <SamB> | (not actually intended for use with systemtap, but using its sys/sdt.h and thus its probe ABI) |
| 21:20 | <jsbell> | Hixie: thanks for the events vs. microtasks answer. Exactly what I was hoping for. |
| 21:27 | <Hixie> | jsbell: np. it's got lots of rough edges still, unfortunately. |
| 21:35 | <jgraham> | SamB: Oh, it wasn't |
| 21:47 | <Hixie> | where do i file bugs to suggest something for the html test suite to test, again? |
| 21:47 | <Hixie> | https://github.com/w3c/web-platform-tests/issues ? |
| 21:48 | <Hixie> | looks like yes |
| 21:52 | <Hixie> | annevk: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25504 |
| 22:25 | <TabAtkins> | JakeA: I don't know why you want a "soft fail" behavior for crossorigin stylesheets there. |
| 22:49 | <foolip> | Hixie: I don't have any ideas for https://www.w3.org/Bugs/Public/show_bug.cgi?id=24684#c22 I'm afraid |
| 22:50 | <foolip> | annevk: I've starred it for when I need to procrastinate |
| 23:01 | <caitp> | can anyone explain what "should" happen in a case like this? http://jsfiddle.net/Wz59M/1/ |
| 23:02 | <caitp> | other than crashing FF nightly, that probably isn't supposed to happen |
| 23:03 | <caitp> | basically, from angular's POV, chrome is doing the "wrong thing" here, and firefox is doing the "right thing", but I just want to get a feel for "why" one or the other is the right thing |
| 23:04 | <Hixie> | half-way through the script, there's no options at all |
| 23:04 | <Hixie> | then you insert one |
| 23:04 | <Hixie> | so it's selected |
| 23:04 | <Hixie> | then you insert another |
| 23:04 | <Hixie> | and, well, there's already a selected one |
| 23:05 | <othermaciej> | I would expect “don’t show me” to show |
| 23:06 | <Hixie> | this is why the insertd one is selected: "If nodes are inserted or nodes are removed causing the list of options to gain or lose one or more option elements, or if an option element in the list of options asks for a reset, then, if the select element's multiple attribute is absent, the select element's display size is 1, and no option elements in the select element's list of options have their selectedness set to true, the user agent must set the selectedness |
| 23:06 | <caitp> | I think the issue is that, `x` does already have a selected option |
| 23:06 | <caitp> | you add another option which isn't selected, but chrome decides that it is selected |
| 23:07 | <caitp> | oh, we are removing the selected option |
| 23:07 | <othermaciej> | yeah, the selected option is removed before a new one is added |
| 23:07 | <Hixie> | i don't see anything in the spec that says what should happen when you add a second selected one... |
| 23:08 | <caitp> | okay, so inserting an option into a select with no options should select that option |
| 23:08 | <Hixie> | that's probably a bug... |
| 23:08 | <Hixie> | caitp: yeah, that part is clear |
| 23:08 | <Hixie> | caitp: it's the next insertion that's unclear to me |
| 23:08 | <Hixie> | file a bug? i gotta run, meeting |
| 23:08 | <caitp> | have fun :> |
| 23:08 | <othermaciej> | oh, right, it’s dynamically inserting an <option> with the selected attribute |
| 23:16 | <caitp> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23574 seems related, although i'm not familiar enough with that section of the spec to really explain it |
| 23:17 | <caitp> | at least, it's related to the bug on angular, not the underlying "insertion of option[selected]" I guess |