| 00:27 | <MikeSmith> | oh man the whole Tracking Protection dark comedy just got even more tragic/comic |
| 00:29 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-tracking/2013Aug/0024.html |
| 00:30 | <miketaylr> | oh vey |
| 00:31 | <MikeSmith> | Peter Swire stepping down as co-chair in order to join the "Review Group on Intelligence and Communications Technology" thing that President Obama set up to whitewash all the legal violations he and the NSA have been doing |
| 00:31 | <miketaylr> | [insert THANKS OBAMA meme here] |
| 00:31 | <MikeSmith> | heh |
| 00:57 | <jamesr__> | very preliminary data suggests that accesses to "document.charset" are really common |
| 00:57 | <jamesr__> | i think some common JS is trying to sniff IE by bool-checking that |
| 00:58 | <jamesr__> | which is sad since webkit/blink have also exposed it forever |
| 03:41 | <zewt> | var ie = (Math.random() < 0.5) // web-compat this, mo-fos |
| 03:41 | <miketaylr> | D: |
| 03:52 | <rsc33> | why on linux chromium when I type <aa in the html it dispalys as text on the web page but on windows on chrome it doesn't display, in a fact it deletes whole row of text? |
| 07:02 | <zcorpan> | jamesr__: that seems like an argument to drop it from webkit/blink |
| 07:03 | <zcorpan> | unless they have that code path mean "IE and WebKit" i guess |
| 07:29 | <zcorpan> | Hixie_: looks like you didn't finish this sentence: |
| 07:29 | <zcorpan> | If |
| 07:29 | <zcorpan> | decDependencies() is called and it reduces the number to zero, |
| 08:18 | <zcorpan> | does anyone know if IE supports alternative stylesheets? (JS or UI or both?) |
| 08:18 | <zcorpan> | what's the log output of http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2497 |
| 08:27 | <zcorpan> | heycam|away: TabAtkins: The CSSOM spec is probably wrong when it comes to how to deal with variables. |
| 08:38 | <Ms2ger> | Maybe not only there ;) |
| 09:32 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-texttrack-mode |
| 09:32 | <Ms2ger> | Isn't the first dl there backwards? |
| 09:40 | <zcorpan> | Ms2ger: backwards as in the text in dt should be in dd instead? |
| 09:40 | <Ms2ger> | Yeah |
| 09:41 | <zcorpan> | i guess |
| 09:44 | Ms2ger | takes some paper to interpret the ORA |
| 09:53 | <Ms2ger> | In step 12.3 at http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm, is the definition of V missing? |
| 09:57 | <SimonSapin> | hsivonen: I don’t understand https://twitter.com/hsivonen/status/372656748928053249 , what’s a fallback encoding in this case? |
| 09:58 | <hsivonen> | SimonSapin: the encoding that's used for HTML if there's no declared encoding and nothing to inherit |
| 09:59 | <SimonSapin> | hsivonen: that’s based on the user’s locale? |
| 09:59 | <hsivonen> | SimonSapin: yes (unfortunately!) |
| 09:59 | <SimonSapin> | ew |
| 09:59 | <hsivonen> | indeed |
| 10:00 | <SimonSapin> | I’m gonna pretend I don’t know about this for now. |
| 10:01 | <Ms2ger> | Fun, isn't it |
| 10:01 | <SimonSapin> | for some values of "fun" |
| 10:01 | <zcorpan> | looks like Default-Style <meta> is a working way to switch stylesheet sets in Blink in JS |
| 10:02 | <Ms2ger> | zcorpan, review comments! ;) |
| 10:02 | <jgraham> | hsivonen: I would be concerned about the small sample size there |
| 10:02 | <zcorpan> | Ms2ger: hmm? |
| 10:03 | <Ms2ger> | https://critic.hoppipolla.co.uk/r/74 |
| 10:04 | <zcorpan> | Ms2ger: nice! |
| 10:04 | <hsivonen> | jgraham: why when the Esperanto result confirms expectations? |
| 10:04 | <SimonSapin> | what’s the sample size, by the way? |
| 10:05 | <SimonSapin> | maybe in absolute number of sessions |
| 10:05 | <hsivonen> | SimonSapin: varies by locale but, IIRC, > 600 for Esperanto |
| 10:06 | <jgraham> | hsivonen: I'm not saying I don't believe the results. But that's only because it confirms my bias, not because I know that the data is trustworthy |
| 10:06 | <hsivonen> | and yes, even pure 100% vs. 0% results were possible with thousands of datapoints, e.g. Finnish Fennec |
| 11:47 | <john____> | hi |
| 11:48 | <john____> | all alone? |
| 11:50 | <john____> | He "Finnish" |
| 11:51 | <john____> | OK, will just put a question and see if anyone bites |
| 11:52 | <john____> | Have added specs for meta names for a search script |
| 11:52 | <john____> | there are comment tags that have errors in w3.validator |
| 11:52 | <john____> | Element name fdse:robots cannot be represented as XML 1.0. <FDSE:ROBOTS value="none"> |
| 11:53 | <john____> | Any ideas how to fix this? |
| 11:53 | <john____> | The tag goes within html not in the header |
| 11:54 | <john____> | Nice it lets you madk off areas of text so the search scrip only sees the code you want |
| 11:55 | <john____> | like <nav></nav> could work |
| 11:55 | <john____> | mask off areas |
| 11:57 | <john____> | - sulk - |
| 11:58 | <john____> | OK, have emailed Hixie_ |
| 11:59 | <john____> | see yah grizzly dudes |
| 12:01 | <Ms2ger> | Bye. |
| 12:25 | <annevk> | fifteen minutes for a reply? wow |
| 13:38 | <Ms2ger> | new Blob(new String("abc")) |
| 13:38 | <annevk> | Aight, zip archive stuff: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0278.html |
| 13:38 | <Ms2ger> | What should that do? |
| 13:39 | <annevk> | Ms2ger: I'd expect a blob consisting of three bytes |
| 13:39 | <Ms2ger> | But the first argument to the constructor is a sequence |
| 13:40 | <annevk> | oh my god |
| 13:40 | <annevk> | who designed that?! |
| 13:40 | annevk | sheds a tear |
| 13:40 | <zcorpan_> | changing style sheet set with Default-Style in webkit doesn't seem to add the new stylesheet to document.styleSheets. and the old stylesheet's cssRules gets emptied. |
| 13:40 | <zcorpan_> | or blink is what i'm testing, but i guess it's the same |
| 13:41 | <gsnedders> | Ms2ger: You're using a string object, you're doing it wrong. |
| 13:41 | <annevk> | If we remove alternate style sheets, default-style can go too |
| 13:41 | <Ms2ger> | gsnedders, no, I explicitly want to test a String object |
| 13:46 | <freddyb> | I just read the zip proposal email. very interesting :) |
| 13:46 | <freddyb> | I found it worthwhile mentioning that something similar to the sub-scheme example already works in firefox jar:http://html5sec.org/test.jar!/test.html |
| 13:47 | <freddyb> | (jar files are zips, considering that manifest files are optional) |
| 13:47 | <gsnedders> | Why is the state of MTP on Linux so bad the easiest way to copy stuff to my tablet is over wifi, slowly? |
| 13:51 | <freddyb> | I'm a bit worried about all three approaches for the zip idea..the first would introduce just another URL scheme for with deriving an origin could be harder than it seems |
| 13:51 | <annevk> | freddyb: yeah I know, although I haven't played with them recently |
| 13:51 | <annevk> | freddyb: so, if we put it on the URL object as sub-scheme, the origin would still be computed in the same way |
| 13:51 | <annevk> | freddyb: but sub-scheme seems really icky |
| 13:52 | <freddyb> | I find them all icky :P |
| 13:52 | <annevk> | I like fragments. But they're kinda incompatible with supporting them in <iframe> and such. |
| 13:52 | <freddyb> | the media fragment looks so capable of being misunderstood |
| 13:53 | <annevk> | And might require a bunch more infrastructure changes than changing the URL parser as sicking pointed out repeatedly to me. |
| 13:53 | <SimonSapin> | annevk: Firefox supports view-source: in <iframe> |
| 13:53 | <freddyb> | because it suddenly has a completely different meaning depending on the resource being returned (espeically without a file name extension), where one program might think it's a portion of an HTML document and others agree it's a file within a zip |
| 13:53 | <annevk> | Fragments are however the only way of using URLs as designed |
| 13:53 | <annevk> | SimonSapin: yeah we should nuke that |
| 13:54 | <freddyb> | yeah, I really hope the view-source/iframe thing gets nuked. there's already a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=624883 |
| 13:54 | <freddyb> | annevk: that's true! but it is really ambigous, isnt it? |
| 13:55 | <SimonSapin> | annevk: zip-relative URLs that start with '%!'. Is this a bad idea? |
| 13:56 | <freddyb> | :) |
| 13:56 | <freddyb> | why not use a character that doesnt have a meaning yet? like $ ;) |
| 13:57 | <annevk> | SimonSapin: you'd have to elaborate |
| 13:57 | <annevk> | freddyb: $ is used in URLs on the web |
| 13:58 | <freddyb> | really? I didn't know. but let's not bikeshed on this. a different character would make more sense to me. |
| 13:58 | <SimonSapin> | annevk: do you think it is a good or bad idea to support <img src="%!foo.png"> which is zip-relative just like <img src="/foo.png"> is host-relative. |
| 13:59 | <annevk> | SimonSapin: I don't think any relative URLs should be able to get out of the zip |
| 14:00 | <SimonSapin> | why not? But this is not the case here: src="%!foo.png" only makes sense if the base URL is in a zip as well, eg. http://example.net/zip%!a/b/c.html |
| 14:00 | <annevk> | We could make it %/ I suppose. |
| 14:01 | <annevk> | SimonSapin: if the idea is that it's a self-contained package, being able to refer to other files on the same server using a relative URL seems very strange |
| 14:02 | <annevk> | SimonSapin: and more likely an error |
| 14:02 | <annevk> | SimonSapin: or worse, exploit |
| 14:03 | <GPHemsley> | Was a question-mark-prefixed character combo already considered and rejected? |
| 14:04 | <annevk> | GPHemsley: question-mark is already used... |
| 14:05 | <GPHemsley> | annevk: So is percent-sign... |
| 14:05 | <annevk> | GPHemsley: did you read my email? |
| 14:05 | <GPHemsley> | Yes |
| 14:05 | <annevk> | It points out why percent-sign in this way works. |
| 14:05 | <GPHemsley> | Yes, but that wasn't my question |
| 14:06 | <annevk> | So you want %? ? |
| 14:06 | <GPHemsley> | I was thinking something more like ?/ |
| 14:06 | <GPHemsley> | but that's why I'm asking |
| 14:06 | <annevk> | That works today in all user agents... |
| 14:06 | <annevk> | % doesn't as I pointed out... |
| 14:07 | <GPHemsley> | so it's a necessity that the URL not work in any current UA? |
| 14:10 | <hsivonen> | annevk: %! looks less scary to me than using # |
| 14:13 | <GPHemsley> | annevk: What happens if your zip file is created using page.php?file=test.zip ? |
| 14:15 | <annevk> | GPHemsley: ? is part of the normal path so that would work |
| 14:15 | <SimonSapin> | annevk: isn’t it the query string? |
| 14:15 | <annevk> | SimonSapin: query string is part of the path |
| 14:16 | <GPHemsley> | annevk: url_test.php?file=test.zip&spacer=1%!example.png wouldn't work |
| 14:16 | <annevk> | SimonSapin: in the HTTP sense |
| 14:16 | <GPHemsley> | at least, not as currently parsed by PHP |
| 14:16 | <annevk> | GPHemsley: why not? |
| 14:16 | <SimonSapin> | but in the URL model sense? |
| 14:16 | <annevk> | GPHemsley: you realize %!image.png would not go to the server right |
| 14:16 | <GPHemsley> | because it sets $_GET['spacer'] = 1%!example.png |
| 14:16 | <SimonSapin> | annevk: I think you need to clarify that |
| 14:17 | <annevk> | SimonSapin: that's at the end of the email? |
| 14:17 | <GPHemsley> | annevk: The %! part currently does get sent to the server, and would in any legacy URL parser, I think. |
| 14:17 | <annevk> | GPHemsley: sure |
| 14:18 | <annevk> | GPHemsley: actually, legacy parsers ought to reject that |
| 14:18 | <GPHemsley> | well, Gecko doesn't |
| 14:18 | <annevk> | yeah, in the query string it's a bit more tricky I suppose |
| 14:18 | <GPHemsley> | nor does Chrome |
| 14:18 | <SimonSapin> | annevk: clarify that %! works in the query string as well as in the path (in URL spec sense) |
| 14:19 | <annevk> | SimonSapin: clarify where? |
| 14:19 | <annevk> | SimonSapin: nothing of this is defined dude... |
| 14:19 | <annevk> | relax |
| 14:19 | <SimonSapin> | yeah, I just assumed that this didn’t work but you seemed to assume that it does |
| 14:19 | <GPHemsley> | annevk: Is there a reason you can't overload # to be used multiple times? |
| 14:19 | <GPHemsley> | e.g. #page_id#/file/path.html |
| 14:20 | <annevk> | explained in the email |
| 14:23 | <zcorpan> | which browsers treat %! as network error? |
| 14:27 | <annevk> | zcorpan: I thought Safari and IE did |
| 14:27 | <annevk> | zcorpan: can't reproduce in Safari though |
| 14:27 | annevk | looks in IE |
| 14:27 | <zcorpan> | ok |
| 14:29 | <annevk> | IE throws for .open("GET", "%") in XHR |
| 14:35 | <annevk> | "but adding complexity doesn't" goes on to advocate for the most complex of three variants |
| 14:37 | <GPHemsley> | annevk: I've responded to your e-mail. Let me know what you think of my idea. (Caveat: I haven't actually read the media fragments spec to see if it's compatible with my idea.) |
| 14:37 | <annevk> | I'm pretty sure media fragments are out |
| 14:37 | <annevk> | or fragments in general |
| 14:41 | <SimonSapin> | GPHemsley: what would #! be standardized to? |
| 15:05 | <jgraham> | GPHemsley: Since there is nothing that depends on this feature so far it seems possible to make it come before the query part. I guess that's kind of ugly though |
| 15:05 | <jgraham> | (i.e. http://example.com/foo.php%!path/in/foo?file=test.zip |
| 15:06 | <jgraham> | ) |
| 15:06 | <jgraham> | (means you can't have a ? in the filename) |
| 15:06 | <SimonSapin> | jgraham: so the server would have GET /foo.php?file=test.zip ? |
| 15:08 | <jgraham> | Yeah |
| 15:08 | <jgraham> | Did I mention ugly? |
| 15:08 | <jgraham> | (also, it doesn't solve bz's concern with data: urls) |
| 15:09 | <annevk> | jgraham: if you did it that way for data URLs that'd be massively confusing :) |
| 15:09 | <SimonSapin> | jgraham: what about data: urls? |
| 15:10 | <jgraham> | Right, I think data urls might sink the whole idea? |
| 15:10 | <SimonSapin> | is it really useful to extract files from data:application/zip,… ? |
| 15:11 | <annevk> | jgraham: No, %! is illegal in data URLs too |
| 15:11 | <jgraham> | SimonSapin: Probably someone will want to for some reason. But it also makes things more confusing in general if there are different rules that you have to learn for different special cases |
| 15:11 | <annevk> | jgraham: Gecko's current architecture might sink it for Gecko, though... |
| 15:12 | <jgraham> | annevk: "illegal", but does it work? |
| 15:12 | <annevk> | jgraham: I suspect it wouldn't in IE, but I can't be bothered to open the VM again |
| 15:12 | jgraham | guesses the Blink/WebKit people won't be delighted by non-string origins, but might be wrong |
| 15:14 | <annevk> | jgraham: what do you mean? |
| 15:16 | <gavinc> | Hrm, anyone know if there was any more thought/action on http://www.w3.org/community/cssselfrags/ ? |
| 15:17 | <GPHemsley> | SimonSapin: No idea; perhaps just reserve #-prefixed combos for future use (and define #! using some vague language that corresponds to its usage now)? |
| 15:18 | <SimonSapin> | GPHemsley: given everyone is doing their own thing, I don’t now what there is to standardize |
| 15:18 | <GPHemsley> | SimonSapin: Don't they all vaguely revolve around AJAXy things? |
| 15:19 | <GPHemsley> | jgraham: Yeah, that is ugly, in that it doesn't make logical hierarchical sense. |
| 15:19 | <SimonSapin> | yes, vaguely |
| 15:19 | <GPHemsley> | SimonSapin: So that might be enough. #-prefix is reserved, #! is AJAKy stuff, #/ is subpath stuff |
| 15:20 | <GPHemsley> | then you have an extension vector beyond ZIP |
| 15:20 | <GPHemsley> | for packages |
| 15:20 | <jgraham> | GPHemsley: Fortunately URLs don't make logical hierachical sense, so that's not a problem |
| 15:20 | <SimonSapin> | #foo is already used for anchors |
| 15:20 | <GPHemsley> | jgraham: They don't? (Other than domain vs. path direction) |
| 15:21 | <jgraham> | … |
| 15:21 | <jgraham> | Well other than the cases they don't, they do, sure. |
| 15:21 | <GPHemsley> | well besides that one (which IMO is fairly simple), what others are there? |
| 15:24 | <GPHemsley> | jgraham: ^ |
| 15:24 | <zewt> | GPHemsley: i regularly use #arbitrary-junk |
| 15:24 | <GPHemsley> | zewt: As in, a non-existent anchor? |
| 15:25 | <zewt> | yes |
| 15:25 | <zewt> | eg. http://foo.com/app?server=query#client/path?client=query |
| 15:26 | <GPHemsley> | oh |
| 15:26 | <GPHemsley> | hmm |
| 15:26 | <GPHemsley> | my guess is that's frowned upon |
| 15:26 | <GPHemsley> | but what do I know |
| 15:26 | <SimonSapin> | is it? |
| 15:27 | <zewt> | *shrug* nothing wrong with it |
| 15:27 | <zewt> | for that matter, gmail does it |
| 15:27 | <zewt> | (just happened to glance over at my gmail window, heh) |
| 15:28 | <zewt> | anyway, just saying it's too late to try to "reserve" #stuff |
| 15:28 | <GPHemsley> | ah, so they do |
| 15:28 | <GPHemsley> | well, that's why this spec might be useful :P |
| 15:28 | <GPHemsley> | standardize on a single one |
| 15:29 | <GPHemsley> | although I suppose Gmail's usage isn't strictly bad |
| 15:29 | <GPHemsley> | since it can be considered an ID |
| 15:29 | <zewt> | well, any path might be considered an ID |
| 15:29 | <GPHemsley> | perhaps |
| 15:29 | <GPHemsley> | but they seem to be #<mailbox>/<hash> |
| 15:30 | <zewt> | settings uses things like "#settings/general" |
| 15:31 | <GPHemsley> | fine, #<page>[/<hash>]? |
| 15:32 | <zewt> | it's just a magic-client-encoded-thing-that-looks-like-a-path, i don't know all the cases they use of course |
| 15:32 | <GPHemsley> | the beauty of having a reserved #/ for a path is that you can define how to parse it |
| 15:32 | <GPHemsley> | and then suddenly everyone can use it interoperably |
| 15:32 | <zewt> | there's "#label/label name/thread id" if you're viewing a thread while in a label view |
| 15:33 | <zewt> | you can treat #foo as a path and parse it, with or without a leading / |
| 15:33 | <zewt> | (as long as it won't explode violently if people put weirdo things in there) |
| 15:33 | <GPHemsley> | yes, you can |
| 15:33 | <GPHemsley> | the prefix would indicate that it is definitely a path, though |
| 15:33 | <GPHemsley> | as opposed to just an opaque ID |
| 15:34 | <zewt> | well, "most likely a path" |
| 15:35 | <zewt> | but i mean, you can expose an API that says "return data from the start of the fragment to the first ?", which would give any path-like part of the fragment, and if you're not using the fragment like that, you just don't use that function |
| 15:35 | <GPHemsley> | sure |
| 15:52 | <annevk> | You don't need to be confident as fragments for zip archives have no meaning. However, fragments for zip archives don't work because of relative URLs. |
| 15:52 | <annevk> | I'd personally be fine with not supporting that case, but other people aren't. |
| 15:53 | <SimonSapin> | why wouldn’t it work to special-case relative URLs in zip? |
| 15:54 | <zewt> | i don't follow--none of the proposals would work for relative urls without extra work |
| 15:54 | <zewt> | personally I suspect supporting zips for navigation is a massively bad idea... |
| 15:55 | <jgraham> | People seem to want to package up whole apps/bundles of resources in a single HTTP request |
| 15:55 | <zewt> | doesn't seem to justify the complexity |
| 15:55 | <jgraham> | This use case keeps coming up |
| 15:56 | <zewt> | as hixie would say, that's not a use case |
| 15:56 | <jgraham> | Well sure. I'm the wrong person to defend this |
| 15:56 | <zewt> | the only use case i can see is "distribute a website as a single file that can be loaded directly" |
| 15:56 | <jgraham> | But I think there are actual use cases being mentioned |
| 16:00 | <annevk> | zewt: e.g. a game you want to distribute to a bunch of sites in an <iframe>, or probably more common, an ad |
| 16:00 | <annevk> | zewt: people use Flash for it today, because of the convenient container format |
| 16:00 | <zewt> | i don't see why that needs to be bundled in one file |
| 16:02 | <jgraham> | I'm not sure what a use case that *required* everything to be bundled in a single file would look like. But doing so can have advaantages e.g. fewer round trips to load, easier to embed, etc. |
| 16:02 | <annevk> | That's how existing infrastructure deals with these things. Everything can be changed of course, but that's the XHTML2 approach. Re-architect the things you have and you'll be fine. |
| 16:03 | <zewt> | bundling resources to reduce fetches is one thing (when you have 100 16x16 icons), but that doesn't argue for reducing to *1* fetch |
| 16:03 | <zewt> | so the web should optimize for infrastructure built specifically for Flash? uh okay |
| 16:04 | <jgraham> | Hmm? |
| 16:04 | <jgraham> | It's not infrastructure built for flash |
| 16:04 | <jgraham> | The flash example is "people are working around the lack of this today by using a non-web technology" |
| 16:04 | <zewt> | then what are we talking about? clearly not infrastructure built for the web, since we're talking about something the web can't do |
| 16:05 | <jgraham> | Flash is a non-web technology |
| 16:05 | <jgraham> | Today people bundle resources in flash files and include them on web pages as opaque blobs |
| 16:05 | <zewt> | sorry, you've lost me--I said "instrastructure for Flash", you say "not flash", I say "then what?" and you reply "flash" :) |
| 16:06 | <jgraham> | I said not infrastructure built for flash |
| 16:06 | <jgraham> | I don't even know what that is |
| 16:11 | <annevk> | Hixie_: why does "Too many recipients to the message" require moderator approval on whatwg⊙wo? |
| 16:11 | <annevk> | Hixie_: that seems annoying |
| 16:36 | <GPHemsley> | annevk: Probably a spam protection |
| 16:36 | <GPHemsley> | but it would be good if subscribers were exempt from that |
| 16:39 | <GPHemsley> | annevk: Fragments for zip archives work even with relative URLs if you allow multiple uses of # (i.e. #/path#id) |
| 16:39 | <GPHemsley> | (and the path fragment comes before the ID fragment) |
| 16:40 | <annevk> | GPHemsley: there's too many infrastructure changes required for fragment identifiers |
| 16:40 | <GPHemsley> | annevk: Examples? |
| 16:41 | <annevk> | GPHemsley: fragment identifier changes don't roundtrip through fetch so you'd need all kinds of special casing |
| 16:41 | <annevk> | GPHemsley: as explained in my email... |
| 16:42 | <annevk> | I should probably just have left it out as suggestion altogether... |
| 16:42 | <GPHemsley> | I've read your e-mail. So please either point me to a specific paragraph where you think you explained it already, or please answer my question directly. |
| 16:49 | <annevk> | Dude, I just explained it |
| 16:50 | <GPHemsley> | annevk: Special casing where? |
| 16:52 | <annevk> | Where you specify the URL? E.g. <img>, <a>, <script>, etc. |
| 16:55 | <Hixie_> | annevk: it's a common source of spam. |
| 16:57 | <annevk> | zewt: the directory is at the end of zip archives |
| 16:57 | <annevk> | zewt: Eric is right |
| 16:57 | <Hixie_> | annevk: also really it usually means that you're annoying people (how often do all those people really need to be cc'ed?) |
| 16:58 | <annevk> | Hixie_: they asked |
| 16:58 | <Hixie_> | i said "usually", not always :-) |
| 16:58 | <annevk> | hah |
| 17:00 | <annevk> | https://twitter.com/stevelosh/status/372740571749572610 is pretty good |
| 17:00 | <GPHemsley> | annevk: Are you saying that you'd have to special-case the ZIP URL in each of the definitions for <img>, <a>, <script>, etc.? |
| 17:01 | <annevk> | GPHemsley: you'd special-case the Document as being derived from zip, and then whenever you have fragment references you need to do special handling |
| 17:02 | <zewt> | annevk: i know they're at the end of zip archives (i've implemented zip clients like four times), you read the end of the file first |
| 17:03 | <annevk> | zewt: you don't get the end of the file first over HTTP... |
| 17:04 | <zewt> | that's why you use range requests |
| 17:04 | <annevk> | o_O |
| 17:04 | <zewt> | ... |
| 17:05 | <annevk> | That's not at all streaming as commonly understood |
| 17:05 | <zewt> | we're not talking about streaming at all |
| 17:05 | <annevk> | Oh yes we were. |
| 17:05 | <zewt> | (this isn't a streaming feature at all) |
| 17:05 | <zewt> | no, we're not. |
| 17:05 | <annevk> | Well whatever then. |
| 17:05 | <zewt> | why are you so obnoxiously snarky lately? it's very tiresome |
| 17:07 | <annevk> | Because Eric said "it's not a great format because it's not streamable" and you say it's not about streaming. |
| 17:09 | <zewt> | streaming is "read the start of a file and take data as it comes in"; this isn't a streaming feature at all, it's a random access feature |
| 17:09 | <zewt> | and zips support both |
| 17:09 | <zewt> | eric misused the word "streaming", and I explained in my email that what this feature wants is random access, not streaming (and how it supports both). |
| 17:10 | <annevk> | Even random access is poor because it's at the end of the zip archive |
| 17:11 | <annevk> | In any event, I gave up because we don't really have to agree on this |
| 18:07 | <TabAtkins> | Do we generally dislike putting things on navigator, or are there good reasons to do so sometimes? |
| 18:08 | <Ms2ger> | If they're todo with the navigator, I guess |
| 18:08 | <TabAtkins> | "network service discovery"? |
| 18:08 | <Ms2ger> | Doesn't sound like it |
| 18:10 | <TabAtkins> | "To enable Web pages to connect and communicate with Local-networked Services provided over HTTP..." |
| 18:11 | <Domenic_> | what is a navigator anyway |
| 18:12 | <Domenic_> | does it navigate the netscape? |
| 18:12 | <TabAtkins> | The thing that navigates. |
| 18:12 | <TabAtkins> | Yes. |
| 18:12 | <TabAtkins> | It's the salty sea-captain of your browser. |
| 18:12 | <Hixie_> | i'd put things on navigator if they're abotu the browser specifically |
| 18:18 | <wycats> | Hixie_: I'm around finally |
| 18:19 | <wycats> | the tl;dr is that modules aren't part of <script>s; they're separate files that are loaded through the loader |
| 18:19 | <wycats> | there are several approaches we're considering for bundling... zip URLs are one of them, and annevk is helping with that |
| 18:20 | <wycats> | but modules are always name->exports |
| 18:20 | <wycats> | when you import { something } from "name", the Loader goes through a bunch of user/browser specified hooks that end up with a fetched source |
| 18:21 | <wycats> | which is then processed for exports |
| 18:21 | <wycats> | if the source is an ES6 module, the system will do the processing, but an author can also override the link hook to process foreign modules (AMD/CommonJS/etc) as long as they can produce an immutable set of exports |
| 18:24 | <wycats> | Hixie_: is that any clearer? |
| 18:27 | <miketaylr> | TabAtkins: i know rwaldron gets upset about adding things to navigator, but I think it's fine if it is somehow related to device (or browser as proxy for device) |
| 18:39 | <rwaldron> | miketaylr: doesn't matter, the navigator object is already the new garbage dump, so it's lost cause to care. |
| 18:39 | miketaylr | shrugs |
| 18:41 | <rwaldron> | Anyway, I agree with the positions stated above, ie. "<Hixie_> i'd put things on navigator if they're abotu the browser specifically" and "<Ms2ger> If they're todo with the navigator, I guess" |
| 18:41 | <Hixie_> | wycats: why couldn't you declare a module with <script>? |
| 18:41 | <rwaldron> | getUserMedia? vibrate? contacts? |
| 18:42 | <rwaldron> | those are not browser related and yet... there they are. |
| 18:42 | <Hixie_> | wycats: i mean, if we added the logic to do that |
| 18:42 | <wycats> | Hixie_: we could have <script module="name">...</script> |
| 18:42 | <wycats> | that would work, and be up to the browser to manage |
| 18:42 | <Hixie_> | wycats: that's what i proposed in the script preloading e-mail yesterday, fwiw |
| 18:43 | <wycats> | From the perspective of ES6, the browser loader is just managing the storage for the "name" module |
| 18:43 | <Hixie_> | right |
| 18:44 | <Domenic_> | yeah that would just be (optimizable) sugar for <script>Loader.load("name");</script> |
| 18:44 | <wycats> | it's potentially slightly confusing from a terminology perspective |
| 18:44 | <wycats> | <module name="foo">...</module> might be better |
| 18:44 | <wycats> | since the contents of the script tag isn't a JS script |
| 18:44 | <Domenic_> | <link rel="js-module">? |
| 18:44 | <Hixie_> | Domenic_: it has other advantages, e.g. it lets you make other scripts wait until this one is downloaded before they try to run |
| 18:44 | <wycats> | links don't close |
| 18:45 | <Hixie_> | <module> has a very poor back-compat story and <link> wouldn't let you do inline modules |
| 18:45 | <Domenic_> | Hixie_: ah right, that whole microsyntax that was developing. |
| 18:45 | <wycats> | Hixie_: <script type="module"> :P |
| 18:45 | <Hixie_> | wycats: well that's what module="" would do, the type is still js |
| 18:46 | <wycats> | you probably want it to not be parsed in old browsers so it could be polyfilled |
| 18:46 | <wycats> | via a transpiler |
| 18:46 | <Hixie_> | wycats: does running a script that contains nothing but a module declaration throw a SyntaxError? or does it do something else? |
| 18:46 | <wycats> | Hixie_: there is no such thing as a module declaration |
| 18:46 | <wycats> | (anymore) |
| 18:46 | <Hixie_> | oh |
| 18:46 | <Hixie_> | so you can't distinguish a module from a program at a syntax level? |
| 18:46 | <wycats> | Hixie_: exactly |
| 18:46 | <Hixie_> | interesting |
| 18:46 | <Domenic_> | wycats: oh?? |
| 18:46 | <wycats> | except for the existence of import/export |
| 18:47 | <Domenic_> | woah, things have changed |
| 18:47 | <wycats> | Domenic_: we're going to lean on network-level bundling (SPDY, HTTP2, zip URLs, etc.) for bundling |
| 18:47 | <Hixie_> | import/export would fail in legacy browsers? |
| 18:47 | <Domenic_> | wycats: +1 from me, just thought that was a non-starter for consensus |
| 18:47 | <wycats> | Hixie_: yep |
| 18:47 | <Hixie_> | ok then polyfilling is easy, since the script would fail |
| 18:47 | <wycats> | which is why I was suggesting <script type="module" module="foo"> |
| 18:47 | <Hixie_> | no need to do anything more explicit |
| 18:48 | <wycats> | it's theoretically possible to have a module with no import/export |
| 18:48 | <Hixie_> | would such a module be able to detect it was being run as a module vs a program? |
| 18:48 | <Domenic_> | ^ fairly common for shim modules |
| 18:48 | <wycats> | Hixie_: yes, modules opt into strict mode, for one thing |
| 18:48 | <wycats> | they also have different scope |
| 18:48 | <Hixie_> | ok so it could just do its own fallback handling |
| 18:48 | <wycats> | var foo = 1 doesn't pollute the global scope in modules |
| 18:49 | <Hixie_> | "ok, i'm a program, let's do this..." vs "ok, i'm a module, let's do that..." |
| 18:49 | <wycats> | Hixie_: it would be nicer to stop modules from loading at all in old browsers |
| 18:50 | <Hixie_> | just stick an import declaration |
| 18:50 | <Hixie_> | it'll fail early |
| 18:50 | <wycats> | would <script type="text/javascript; module"> be parsed as JS |
| 18:50 | <Hixie_> | or export |
| 18:50 | <Hixie_> | or whatever |
| 18:50 | <wycats> | Hixie_: perhaps |
| 18:50 | <Hixie_> | you don't want to require type=module, since it'll be a cost you have to pay for all time |
| 18:50 | <wycats> | I'm unsure what the consequences of gratuitous exceptions might be |
| 18:50 | <wycats> | type=module could be optional |
| 18:50 | <wycats> | just to aid polyfills |
| 18:51 | <Hixie_> | well they can do that regardless |
| 18:51 | <wycats> | it's just a type that new browsers treat as JS |
| 18:51 | <Hixie_> | type=text/plain or whatever |
| 18:51 | <Hixie_> | oh, i see |
| 18:51 | <wycats> | no... if they do it it will block new browsers from parsing as JS |
| 18:51 | <wycats> | c |
| 18:51 | Hixie_ | shrugs |
| 18:51 | <wycats> | (confirm) |
| 18:51 | <wycats> | Hixie_: it's a pretty simple back-compat hack without long-term consequences |
| 18:51 | <Hixie_> | unless there's a big problem here it seems simpler to not do anything |
| 18:52 | <Hixie_> | anyway. how much are we really expecting authors to bother with modules and try to be backwards-compatible? |
| 18:52 | <Hixie_> | i'd expect authors to wait a few years before trying to use this |
| 18:52 | <Hixie_> | doesn't seem worth the pain |
| 18:52 | <wycats> | I plan to use modules within months for Ember |
| 18:52 | <wycats> | via polyfills |
| 18:52 | <wycats> | and transpilers |
| 18:53 | <wycats> | https://github.com/square/es6-module-transpiler |
| 18:53 | <Hixie_> | sure but you're not going to use <script module> to do it, you didn't even know it was an option :-P |
| 18:53 | <wycats> | for now, I can tell people to do <script type="text/x-module"> |
| 18:53 | <wycats> | and not worry about future breakage |
| 18:53 | <wycats> | but it would be nice if there was something that would "just work" in the future |
| 18:54 | <wycats> | so eventually the polyfill could be retired |
| 18:54 | <wycats> | or only loaded in old browsers |
| 18:54 | <Hixie_> | in the future, there won't be old browsers |
| 18:54 | <Hixie_> | :-) |
| 18:55 | <wycats> | in the far future, there won't be old browsers |
| 19:01 | <Hixie_> | bbiab, food |
| 21:46 | gavinc | cries at url handling |
| 21:46 | <gavinc> | Fish%20&%3B%20Richardson gee thanks for turning the URL into HTML |
| 22:07 | <annevk> | whoa, seems a couple of people replied to my email |
| 22:08 | <annevk> | oh no, it's mostly fine |
| 22:22 | <annevk> | gavinc: that looks some other layer got in between, that's not typical URL handling, unless you're messing with the wrong encodings... but then you wouldn't get that exactly either |
| 22:24 | <MikeSmith> | annevk: last week when you were talking about this zip and URL stuff I hadn't realized where you were headed with it. This is pretty cool (now that I understand) |
| 22:24 | <MikeSmith> | I hope it gets some interest and support |
| 22:27 | <annevk> | It's getting a bit more concrete |
| 22:27 | <annevk> | There's some notes about other details here btw: https://etherpad.mozilla.org/zipurls |
| 22:31 | MikeSmith | reads |
| 22:32 | <MikeSmith> | nice simple API |
| 22:35 | <annevk> | I'm fearing it might get more complicated if people want to support creation client-side |
| 22:35 | <Hixie_> | so does nobody have an opinion on the script preloading thing other than kyle? (kyle promised to write me some e-mails this weekend) |
| 22:36 | <annevk> | "some emails"? *braces for impact* |
| 22:36 | <annevk> | I suspect JakeA will review |
| 22:37 | <Hixie_> | he said he'd take some time to make them shorter, so there's hope :-) |
| 22:37 | annevk | has been working on zip archives |
| 22:42 | <zewt> | Hixie: i seem to recall having one, but it's been too long |
| 22:42 | <zewt> | i may have got out-bandwidthed on that discussion |
| 22:45 | <gavinc> | annevk: Yeah, a few things went wrong to get that result. Javascript bug, apache rewrite bug, template language bug. All combined for awesome. |
| 22:47 | <JakeA> | annevk: Hixie_: I'll look through it all tomorrow. It's possible he has a point, I just haven't seen it yet. I'll need to sharpen my cruft scythe to cut through all the word-fern |
| 23:26 | <Hixie_> | zewt, JakeA: in my last e-mail there was a proposal that should address most use cases. i'm particualrly interested in feedback on that proposal (whether i missed use cases that it fails, whether some use cases should be abandoned and thus the proposal simplified, or whether there's another way to address those use cases) |