| 01:04 | <Hixie_> | man, i hate twitter. not even enough room for "thanks!" in my last tweet. |
| 01:20 | <tantek> | Hixie_ perhaps you should start tweeting from your own site instead. #indiewebcamp ;) |
| 01:21 | <Hixie_> | how would that reach the people on twitter? |
| 01:21 | <Hixie_> | i only tweet when i have to respond to something there |
| 01:21 | <tantek> | Hixie_ I've been tweeting from my own site since 2010-01-01 |
| 01:22 | <tantek> | "how would that reach the people on twitter?" in short, POSSE |
| 01:22 | <tantek> | longer explanation: http://indiewebcamp.com/POSSE |
| 01:23 | <tantek> | specifically for responding to something on Twitter: http://indiewebcamp.com/Twitter#POSSE_Replies_to_Tweets |
| 01:25 | <Hixie_> | so... that's exactly what i did |
| 01:25 | <Hixie_> | i posted to "my own site", the whatwg mailing list, then responded to a comment on twitter by linking to that. |
| 01:27 | <tantek> | ah, a manual POSSE ok |
| 01:28 | <Hixie_> | (btw, automated syndication to third-party sites is terrible. it makes interaction with the syndicators on those sites horrible.) |
| 01:28 | <Hixie_> | i love how many people have reforwarded paul_irish's tweet and my tweet vs how many have actually given any feedback. -_- |
| 01:29 | <tantek> | email is hard, let's tweet |
| 01:30 | <Hixie_> | btw i was amused the other day |
| 01:30 | <Hixie_> | i was reading some indieweb stuff that someone linked to on g+, i think it wa-- oh, he left. |
| 01:30 | <Hixie_> | oh well. |
| 01:42 | <MikeSmith> | oh "whenneeded" |
| 01:42 | <MikeSmith> | that's quite a string a letteres in a row |
| 01:46 | <Hixie_> | yeah the attribute name definitely leaves something to be desired |
| 01:47 | <MikeSmith> | random thought for an alternative: "earmarked" |
| 01:48 | <MikeSmith> | "I encourage you to work on editing." hah yeah |
| 01:48 | <MikeSmith> | "Less words please." |
| 01:50 | <Hixie_> | earmarked="asap" vs earmarked="jit"? hmm... |
| 01:51 | <Hixie_> | the thing about whenneeded="" is that it is thematically consistent with needed="", at least |
| 01:51 | <Hixie_> | and markNeeded(), though i've since renamed that execute() in the proposal |
| 01:52 | <MikeSmith> | so could just use "earmark" as a noun instead of "earmarked" |
| 01:52 | <MikeSmith> | is there any purpose of the dependency count other than knowing whether it's zero or non-zero? |
| 01:53 | <MikeSmith> | or you need the actual count for knowing how many times you need to iterate? |
| 01:54 | <Hixie_> | it's just a boolean, but having it be a count means you don't (as an author) need to do the count yourself |
| 01:54 | <MikeSmith> | ok |
| 01:59 | <zewt> | i haven't had a chance to go over that email in depth, but one early impression: having a set of strings is easier to debug than a refcount (if somebody forgets to decrement a count, or decrements it twice, it's harder to figure out who than if you add and remove a string from a set) |
| 02:47 | <MikeSmith> | Hixie_: so how do I get the dependency count? Or I don't need to, I just do decDependencies() til and if it throws, that's all I need to know? |
| 02:48 | <MikeSmith> | also, you got an sentence there that you cut off in mid-thought, "If decDependencies() is called and it reduces the number to zero, |
| 02:48 | <MikeSmith> | ... |
| 02:50 | <Hixie_> | MikeSmith: you shouldn't need the number yourself, i don't think |
| 02:51 | <MikeSmith> | ok |
| 02:51 | <Hixie_> | MikeSmith: yeah, the sentence should be something like "...zero, you check if you should run the script" or some such |
| 04:31 | <MikeSmith> | Hixie_: for the case of <table><input></table> do you think the validator should emit an error message or not? |
| 04:31 | <MikeSmith> | ideally I mean |
| 06:11 | <MikeSmith> | hsivonen: per spec it seems like <table><input></table> should cause a parse error to be reported before it gets foster-parented |
| 06:11 | <MikeSmith> | but in the parser code I find no condition under which it will actually report an error |
| 06:22 | <MikeSmith> | specifically, in the TreeBuilder code at http://hg.mozilla.org/projects/htmlparser/file/f5c39b263341/src/nu/validator/htmlparser/impl/TreeBuilder.java#l1875 before it checks for type=hidden (and falls back to IN_BODY) or otherwise proceeds, it seems like it should call errStartTagInTable(name) right away |
| 06:35 | <hsivonen> | MikeSmith: OK |
| 06:36 | <MikeSmith> | hsivonen: should I raise a bug and make a patch? |
| 06:46 | <hsivonen> | MikeSmith: makes senes |
| 06:46 | <hsivonen> | sense |
| 06:46 | <MikeSmith> | k |
| 07:42 | <zcorpan> | annevk: application/xml doesn't work for .svg if you want to be able to embed it in <img> |
| 07:43 | <zcorpan> | annevk: also, mapping for .xhtml and .xht are usually application/xhtml+xml |
| 07:44 | <zcorpan> | annevk: iirc, the correct type for .ico is image/x-icon (MS don't use image/vnd.microsoft.icon and they didn't register it) |
| 07:52 | <zcorpan> | Hixie_: how about when="asap", when="jit"? |
| 07:52 | <zcorpan> | or when=needed :-) |
| 08:09 | <hsivonen> | annevk: could you retweet https://twitter.com/hsivonen/status/372993894767525888 from @encodings please? |
| 09:02 | <jgraham> | I agree with zewt about the refcount sounding hard to debug |
| 09:59 | <hsivonen> | Clearly, I don't have enough Twitter followers using the Greek localization of Windows |
| 10:03 | <zcorpan> | hsivonen: is there data on how often users switch style sheets in firefox? |
| 10:04 | <hsivonen> | zcorpan: I don't know. probably not |
| 10:04 | <zcorpan> | ok |
| 10:04 | <hsivonen> | zcorpan: why do you want to know? |
| 10:05 | <zcorpan> | hsivonen: i'm investigating whether alternative stylesheets can be dropped from the web platform |
| 10:06 | <annevk> | zcorpan: good point about SVG, I don't want to do XHTML unless we decide we need MIME type to decide Document type which would be unfortunate |
| 10:08 | <annevk> | hsivonen: will do, if you have access to WHATWG GitHub you can do that too though |
| 10:08 | <hsivonen> | zcorpan: Would x% of Firefox sessions involve an alternative stylesheet having been selected at least once during the session be a suitable metric? |
| 10:09 | <hsivonen> | annevk: If I have access, I don't know about it. Thanks. |
| 10:10 | <annevk> | hsivonen: do you want to be a member? |
| 10:10 | <hsivonen> | annevk: ok |
| 10:11 | <annevk> | hsivonen: added |
| 10:11 | <hsivonen> | annevk: you retweeted as URL, but close enough :-) |
| 10:11 | <hsivonen> | annevk: thanks |
| 10:11 | <annevk> | hsivonen: oh lol |
| 10:11 | annevk | fixes |
| 10:13 | <zcorpan> | hsivonen: yeah, i guess |
| 10:14 | <hsivonen> | zcorpan: ok. that would be pretty easy to do with telemetry |
| 10:34 | <annevk> | Modules without module {}; that's kinda neat. |
| 10:44 | <zcorpan> | hsivonen: it would also be interesting to know how often stylesheets are switched using javascript. i would expect most users that switch stylesheets use page-provided button rather than the browser's View menu |
| 10:44 | <hsivonen> | zcorpan: ah. that might be harder to detect |
| 10:45 | <zcorpan> | hsivonen: i think the most common way to switch is toggling .disabled on <link>, but i don't have data on that |
| 10:46 | <zcorpan> | (and it doesn't work in webkit/blink (anymore)) |
| 10:55 | <zcorpan> | hsivonen: blink/webkit have UseCounter to measure API usage. does gecko have something like that? |
| 11:01 | Ms2ger | wonders if Opera had that first |
| 11:02 | <jgraham> | zcorpan: Looks like you can do something like that. Although I haven't quite worked out which API one uses for counting things |
| 11:02 | <jgraham> | Ms2ger: I don't think so |
| 11:20 | <hsivonen> | zcorpan: not in genenic way |
| 11:20 | <hsivonen> | generic |
| 11:21 | <hsivonen> | aargh. Our Macedonian localization defaults to UTF-8 |
| 11:21 | <hsivonen> | why not windows-1251? |
| 11:22 | <hsivonen> | I think I'm done tilting at the localization windmills and will now endeavor to take this stuff away from localizations. |
| 11:22 | <hsivonen> | The files on spec bugs, though. |
| 11:23 | <hsivonen> | The spec doesn't cover Belarusian, Kazakh or Macedonian |
| 11:23 | <hsivonen> | or Greek |
| 11:27 | annevk | -> lunch |
| 11:29 | <SimonSapin> | hsivonen: is there a spec describing all that? |
| 11:29 | <hsivonen> | SimonSapin: not all that. I need to file spec bugs to broaden the HTML spec's coverage |
| 11:32 | <JakeA> | annevk: If I navigate to a file within a zip, how does the browser know how to render it, given the lack of content-type? |
| 11:32 | <JakeA> | (still working through the thread, so sorry if that came up) |
| 11:42 | <zcorpan> | has IE always had swapNode()? |
| 11:43 | <zcorpan> | document.documentElement.swapNode(document.doctype) works |
| 12:03 | <darobin> | haha, sweet |
| 12:04 | <darobin> | zcorpan: I have dim memories of using swapNode() from a long time ago; I suspect it's been around for quite a while |
| 12:04 | <darobin> | it's nice, too |
| 12:37 | <annevk> | JakeA: file extension |
| 12:37 | <JakeA> | annevk: Would that be a new thing to add to the platform? |
| 12:37 | <annevk> | JakeA: yes |
| 12:38 | <JakeA> | gotcha |
| 12:38 | <annevk> | JakeA: congrats on being the first to think about this |
| 12:38 | <annevk> | JakeA: https://etherpad.mozilla.org/zipurls explains it |
| 12:38 | <annevk> | JakeA: might put that text in http://fetch.spec.whatwg.org/ later today so it's more readable |
| 12:41 | <annevk> | JakeA: oh, many good points in your email |
| 12:41 | <annevk> | JakeA: we'd need to forward some headers indeed |
| 12:42 | JakeA | wonders if index.html would be returned for a zip url for a directory that contained an index.html |
| 12:44 | <annevk> | JakeA: you mean if you do html.zip%! ? |
| 12:44 | <JakeA> | yeah |
| 12:44 | <annevk> | JakeA: we could |
| 12:45 | <JakeA> | or whatever.zip%!dir |
| 12:45 | <JakeA> | where there was a dir/index.html |
| 12:45 | <annevk> | JakeA: that's more magical |
| 12:45 | <annevk> | JakeA: because there could be a "dir" too |
| 12:45 | <annevk> | although I guess we could go by lack of extension |
| 12:45 | <annevk> | or require a trailing / |
| 12:46 | <annevk> | I guess in general we could add those kind of things, but it would involve more logic and reinventing even more stuff |
| 12:46 | <JakeA> | I was pondering what would break if I took an existing static site and zipped it |
| 12:46 | <annevk> | e.g. would it then look for index.xml ? |
| 12:46 | <JakeA> | agree it's magic, but perhaps expected |
| 12:47 | <JakeA> | tbh, most of the complication here is allowing full pages to load from a zip |
| 12:49 | <annevk> | JakeA: that's what pushes you from fragments to sub-scheme / zip-path, agreed |
| 12:50 | <annevk> | JakeA: either way complexity is there though |
| 12:50 | <JakeA> | annevk: yeah, I thought for a moment the relative-url problem goes away if it was only allowed on resources, but it doesn't (css, svg etc) |
| 12:51 | <JakeA> | in fact, having relative urls work feels super important for css |
| 12:54 | <annevk> | Yeah, should probably start using CSS as example |
| 13:10 | <annevk> | JakeA: replied. Still don't quite a good argument against the "use a fancy server setup" annoyingly enough |
| 13:10 | <annevk> | JakeA: I guess it sorta boils down to "don't argue for XHTML2 when we can do this in HTML instead" but it doesn't fit exactly |
| 13:11 | <JakeA> | yeah, I know what you mean. |
| 13:11 | <jgraham> | FWIW I assume that module syntax could be changed if there was a strong benefit to having multiple modules in a file |
| 13:12 | <JakeA> | But we already have concatenation of CSS, JS, image spriting… I don't think there's a benefit combining the different types together |
| 13:12 | <JakeA> | If I combine CSS & JS, I'm delaying first-render |
| 13:12 | <annevk> | jgraham: It was recently changed to remove it |
| 13:13 | <annevk> | JakeA: that depends on request latency vs bandwidth too |
| 13:14 | <annevk> | JakeA: with high latency a single request might be good |
| 13:14 | <annevk> | JakeA: especially if we improve the zip archive format over time (or introduce a fancy researched alternative) |
| 13:15 | <jgraham> | annevk: I know, but that could have been because the use case wasn't discussed, or they didn't consider the problems with zip files or something |
| 13:15 | <JakeA> | annevk: If first render requires HTML + CSS (2 requests), then HTML + ZIP{CSS + JS} (2 requests) is going to take longer no matter what the latency is |
| 13:16 | <JakeA> | since ZIP{CSS + JS} will be larger than CSS |
| 13:17 | <jgraham> | Uh |
| 13:17 | <jgraham> | I assume you mean ZIP(CSS+JS) will be larger than ZIP(CSS) |
| 13:18 | <jgraham> | But it is also possible that the optimal is HTML(inc. minimal inline CSS) + ZIP(CSS+JS) |
| 13:18 | <annevk> | JakeA: I'm saying it might be less long overall and for high latency that might be better |
| 13:19 | <JakeA> | jgraham: I was assuming the CSS would be gzipped |
| 13:19 | <annevk> | JakeA: if you argue on perf grounds however you clearly want a fully optimized HTTP2 setup that's not going to be in the hands of anyone soon |
| 13:19 | <JakeA> | jgraham: and yeah, inline CSS would be faster still |
| 13:22 | <wilhelm_> | Is this stuff in any spec yet? |
| 13:22 | <JakeA> | annevk: if the use-case here is cutting down http requests for performance reasons, we need a format that allows for streaming, otherwise we're trading time-to-first-render for overall load time, and I think the former is better in most cases |
| 13:22 | <JakeA> | Eg, I'd rather look at the core content but missing imagery than a blank screen |
| 13:23 | <annevk> | JakeA: I think the use cases are easier management of files and dealing with the myriad of zip archive-based formats out there |
| 13:26 | <jgraham> | I think it is inevitable that people will want to use this for performance |
| 13:27 | <annevk> | They might, and if it doesn't work they'll switch back. Or Google or Apple or Microsoft will invent a better format with the same properties. |
| 13:27 | <JakeA> | I guess it'd be useful for things I explicitly don't want to render progressively, like fonts maybe |
| 13:28 | <JakeA> | especially different weights of the same typeface |
| 13:28 | <annevk> | Or things you want to have fetched together. Or things you want to distribute on lots of servers without having to worry about files going missing or getting replaced. |
| 14:14 | <annevk> | JakeA: more to the point, do you think Chrome would be interested in implementing something like this? |
| 14:14 | <GPHemsley> | I was considering adding recommended file extensions to mimesniff before; would that be helpful with zip packages? |
| 14:16 | <annevk> | No, and please don't do that |
| 14:17 | GPHemsley | goes back to not caring about things |
| 14:17 | <annevk> | Apart from one sad place in plugin loading, the web doesn't do extensions. |
| 14:19 | <GPHemsley> | The original intent was for downloading |
| 14:21 | <annevk> | Oh, opposite direction... |
| 14:21 | <JakeA> | annevk: no idea tbh, Alex Russell has better contacts there. If it's required to sensibly work with ES modules, I guess it'll go in |
| 15:57 | <annevk> | heycam|away: so we need actual Array in IDL |
| 15:57 | <annevk> | heycam|away: and I'd like to hint in the IDL what developers can expect |
| 15:57 | <annevk> | heycam|away: e.g. Promise<Array[DOMString]> |
| 16:11 | <jgraham> | Ms2ger: So if the manifest files for w-p-t aren't going to be human-written, shall I just switch to manifestdestiny? |
| 16:12 | <Ms2ger> | So what did we end up with? |
| 16:14 | <Ms2ger> | Autogenerated manifests in the repo? |
| 16:15 | <jgraham> | I think we ended up with -manual suffix indicates a manual test, -ref suffix indicates a ref, markup files containing testharness.js scripts are testharness files and markup files containing whatever the reftest stuff is are ref files. All other files are helper files except a blacklist of files/directories that are nothing |
| 16:15 | <jgraham> | And maybe we get override.manifest (which could be a different format) |
| 16:15 | <jgraham> | Depending on what happens about tests that want URLs |
| 16:17 | <Ms2ger> | I think I'd prefer just having a python script that computes and returns the data |
| 16:17 | <Ms2ger> | Rather than that + its output |
| 16:19 | <jgraham> | If you do that you can't cache it |
| 16:19 | <jgraham> | Which is annoying |
| 16:20 | <jgraham> | In particular if you want to parse files rather than use regexps, it's necessary to allow incremental updates |
| 16:20 | <jgraham> | Alhtough I guess maybe just dumping JSON would work too |
| 16:21 | <jgraham> | In fact that seems far and away the simplest thing |
| 16:21 | <jgraham> | I'll do that |
| 16:21 | <jgraham> | (also, for Moz. we need to store the expected result of each test somewhere, and I imagine that will also be in the manifest, on a local branch) |
| 16:22 | <Ms2ger> | How does updating work anyway? Based on timestamps? |
| 16:22 | <jgraham> | Based on git hash |
| 16:22 | <jgraham> | I haven't fully thought about this yet |
| 16:22 | <Ms2ger> | And a local branch of what? |
| 16:22 | <Ms2ger> | For the expected result |
| 16:23 | <Ms2ger> | You need to be able to easily update those in an m-c push |
| 16:23 | <jgraham> | Well |
| 16:23 | <jgraham> | This is the bit I haven't fully thought about yet |
| 16:23 | <Ms2ger> | That's a somewhat important bit :) |
| 16:24 | <jgraham> | But I figure you have a local clone with a "mozilla" branch |
| 16:24 | <Hixie_> | MikeSmith: for the case of <table><input></table> - sure, why would it not be an error? i mean, it's a content model thing if nothing else |
| 16:24 | <jgraham> | And Mozilla is origin/master + a commit that adds the manifests |
| 16:24 | <Hixie_> | MikeSmith: note that <input type=hidden> doesn't get foster parented |
| 16:24 | <Hixie_> | zcorpan: <script when> doesn't really make sense though |
| 16:24 | <Ms2ger> | Hixie_, content model how? There's no input in the table in the DOM |
| 16:24 | <jgraham> | and when you update origin you rebase onto that branch |
| 16:24 | <jgraham> | Uh |
| 16:25 | <jgraham> | You rebase that branch onto origin/master |
| 16:25 | <Hixie_> | Ms2ger: oh, fair enough |
| 16:25 | <Hixie_> | anything that's foster parented should always be a parse error |
| 16:25 | <Ms2ger> | Fair |
| 16:25 | <jgraham> | So you are always a few commits ahead of origin, but nothing should conflict |
| 16:25 | <Hixie_> | and if it's not foster parented (e.g. cos type=hidden) then it's a content model error instead |
| 16:25 | <Ms2ger> | jgraham, no idea what you're saying :) |
| 16:26 | <jgraham> | and then in m-c you either copy that branch across with all the manifest data, or make the build process pull in a specific revision of that repo (like gaia) |
| 16:26 | <jgraham> | Ms2ger: Oh :( |
| 16:26 | <Hixie_> | in other news, the updated dfn.js is cool. |
| 16:26 | <Ms2ger> | I *really* don't want to touch other repos to fix Gecko bugs |
| 16:26 | <Hixie_> | why i didn't do this earlier, i dunno |
| 16:27 | <jgraham> | Ms2ger: Well if you want to commit a test to the other repo you kind of have to. But if you want to use it read-only then copying is a reasonable thing to do ofc. |
| 16:27 | <jgraham> | I'm not sure which is best overall |
| 16:27 | <annevk> | Hixie_: what's new? |
| 16:27 | <jgraham> | But I'm sure this is at least a solvable problem |
| 16:28 | <Hixie_> | annevk: it moves the box to the bottom right when you click a link, so you can just go through the others without having to go back to the dfn each time |
| 16:28 | <jgraham> | What I am even more worried about is how you get a all the expected data up to date automagically |
| 16:28 | <jgraham> | It seems like it has to be racy |
| 16:28 | <annevk> | Hixie_: wow |
| 16:29 | <Hixie_> | it was like 3 lines of new code |
| 16:29 | <jgraham> | Hixie_: Oooh! Neat |
| 16:29 | <annevk> | Hixie_: that's awesome |
| 16:29 | <Hixie_> | brb commute |
| 16:30 | <Ms2ger> | jgraham, how about "each m-c revision knows which tests are expected to fail"? |
| 16:31 | <jgraham> | Ms2ger: How though? If I import 100 new tests how do I work out which tests are expected to fail? |
| 16:32 | <jgraham> | I can run those tests in a specific revision and update the expectations |
| 16:32 | <jgraham> | But by the time I do that there will be a new revision |
| 16:32 | <jgraham> | of m-c |
| 16:32 | <jgraham> | Which might fail different tests |
| 16:32 | <Ms2ger> | And then make sure you push the expectations before something lands that changes the expectations |
| 16:32 | <jgraham> | That sounds racy… |
| 16:33 | <Ms2ger> | Not more so than any change |
| 16:35 | <jgraham> | Hmm, maybeI have to think of m-c as a shared resource with some sort of optimistic concurrency |
| 16:35 | <Ms2ger> | Or you can close all the trees :) |
| 16:36 | <Ms2ger> | Doesn't help if a change that breaks your expectation landed on fx-team while you landed your update to inbound |
| 16:38 | <Ms2ger> | Let's say I don't think someone breaking your tests while you're adding them is something you should worry about a lot |
| 16:38 | <jgraham> | So the problem I have is that it doesn't obviously feel like it will be low contention. I don't know what the rate of changesets coming in that affect web platform support is |
| 16:42 | <Ms2ger> | Depends on how big your imports will be, I guess |
| 16:43 | <Ms2ger> | And how diverse |
| 16:47 | <jgraham> | Yeah, I guess that's a good point. If the imports are frequent there is less chance of conflicts. |
| 16:48 | <jgraham> | I don't control the diversity though if the goal is to run everything (which I think it is) |
| 16:48 | <annevk> | Zip archives: http://fetch.spec.whatwg.org/#zip-archives (has infrastructure plus API, but not the URL/Fetch stuff) |
| 16:59 | <SimonSapin> | annevk: does the zip format have a spec you can refer to? |
| 16:59 | <annevk> | SimonSapin: I think it might be http://www.pkware.com/documents/casestudies/APPNOTE.TXT |
| 17:04 | <jgraham> | My understanding is that that's a "spec" more in the tradition of HTML4 |
| 17:05 | <jgraham> | i.e. it doesn't actually define enough to provide interop |
| 17:05 | <SimonSapin> | jgraham: are you suggesting that annevk should rewrite it? :) |
| 17:05 | <zewt> | yeah, I wasn't sure if you mean "refer to" as in "look at as a reference to write a spec" or as in "a normative reference" |
| 17:05 | <zewt> | but yes, it definitely needs to be rewritten (a much smaller subset of) |
| 17:06 | <zewt> | otherwise it'll be an interop nightmare (for example, like we talked about on the list, the local file header vs. central file directory issue) |
| 17:07 | <zewt> | and all the usual error handling and parsing details that non-web-specs rarely address |
| 17:08 | <zewt> | afk |
| 17:08 | <jgraham> | SimonSapin: I'm suggesting that someone has to if we want this to not be a disaster |
| 17:09 | <jgraham> | So yes, in short |
| 17:12 | <annevk> | That APPNOTE.TXT file seems to suggest that might not be okay with them? It's a bit unclear what the legal situation is to me. |
| 17:12 | <annevk> | Which I guess might kill this thing altogether? |
| 17:18 | <tantek> | how does HTTP 1.1 reference gzip compression? |
| 17:23 | <jgraham> | RFC 1952 |
| 17:49 | <Hixie_> | annevk: (your zip idl has > where you want <) |
| 17:50 | <Hixie_> | annevk: is there a url format for accessing files in zip archives? |
| 17:50 | <Hixie_> | annevk: or do you have to get urls to files out of them by script? |
| 17:50 | <TabAtkins> | Hixie_: That's what Anne is trying to come up with. |
| 17:51 | <Hixie_> | doesn't it have to be a fragment identifier? |
| 17:51 | <Hixie_> | i mean, it's semantically logical, no? |
| 17:52 | <Hixie_> | http://.../...zip#path/to/file.html#fragmentInHTMLFile |
| 17:52 | <Hixie_> | i guess it makes relative urls weird |
| 18:28 | <zewt> | Hixie_: i think all of the approaches do something weird with relative urls |
| 18:29 | <zewt> | annevk: sorry, suggest that what might not be okay with them? |
| 18:30 | <zewt> | the file format needs respeccing no matter what, as for whether it's okay to use that as a reference I don't know... |
| 19:47 | <annevk> | Hixie_: fragment identifiers have problems, see the email |
| 19:47 | <Hixie_> | "the"? |
| 19:47 | <annevk> | Hixie_: OP |
| 19:47 | <Hixie_> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0278.html ? |
| 19:47 | <annevk> | Hixie_: yeah |
| 19:48 | <Hixie_> | if you're going to change the url syntax anyway, you can make fragments work |
| 19:48 | <annevk> | zewt: see section 1.4 of http://www.pkware.com/documents/casestudies/APPNOTE.TXT |
| 19:48 | <Hixie_> | just redefine how relative urls are resolved when you're in a "zip context" |
| 19:49 | <annevk> | Hixie_: except then you also need to change HTML, CSS, etc. to make them aware they're loaded from a zip |
| 19:49 | <Hixie_> | why? |
| 19:49 | <annevk> | Hixie_: "zip context" ;) |
| 19:49 | <Hixie_> | it's a pretty localised change |
| 19:49 | <Hixie_> | you'd just have http://.../...zip#path/to/file#subfrag |
| 19:50 | <annevk> | What about the links in #path/to/file ? |
| 19:50 | <Hixie_> | and you'd say that when you're in a zip file context resolving a url, "foo/bar" resolves relative to the #path/to/file part |
| 19:50 | <Hixie_> | i guess you'd actually only have to change the relative url resolver, not the syntax |
| 19:50 | <annevk> | And ##foo would cause scrolling? |
| 19:51 | <Hixie_> | just #foo would cause scrolling |
| 19:52 | <Hixie_> | it'd require careful thought around how Location exposes these urls |
| 19:52 | <annevk> | Given that the resolved URL would also still have the fragments and you'd sometimes have to move them over to Fetch and sometimes handle them locally it would all get rather messy... |
| 19:53 | <Hixie_> | i think that's a given regardless of the solution... |
| 19:53 | <annevk> | Using a sub-scheme or zip-path seems much simpler |
| 19:53 | <Hixie_> | well a subscheme doesn't seem to be any cleaner really |
| 19:53 | <Hixie_> | you have all the same problems |
| 19:53 | <Hixie_> | like, Location's API would be very confused |
| 19:54 | <Hixie_> | anyway, i'm not saying teh frag id thing is a better idea |
| 20:03 | <annevk> | Your fragment idea is novel, admittedly. Should probably consider it some more. |
| 20:05 | <Hixie_> | might be worth looking at how compound e-mails handle relative urls |
| 20:05 | <Hixie_> | oh, here's another idea |
| 20:05 | <Hixie_> | so you navigate to http://example.com/foo.zip#baz/bar.html |
| 20:05 | <Hixie_> | but the actual URL of the file that's loaded isn't that |
| 20:06 | <Hixie_> | it's zip:///baz/bar.html |
| 20:06 | <Hixie_> | or zip://36573525327537/baz/bar.html |
| 20:06 | <Hixie_> | or zip://example.com/36573525327537/baz/bar.html |
| 20:07 | <Hixie_> | where 36573525327537 is some unique id for the zip file |
| 20:07 | <Hixie_> | much like how blob: urls work |
| 20:08 | <annevk> | Yeah, mnot suggested that too |
| 20:08 | <Hixie_> | probably need to encode the origin in there somehow |
| 20:08 | <annevk> | Then you have an outer and inner URL and need to deal with origin specially. |
| 20:08 | <annevk> | The only problem %/ or %! has is that it's not legal URL syntax at the moment... |
| 20:08 | <Hixie_> | well we already have lots of logic for dealing with origins like that |
| 20:09 | <Hixie_> | what would %/ have Location.path return? |
| 20:09 | <annevk> | Your goal is preserving URL syntax to the extent it is ruined already? |
| 20:10 | <Hixie_> | my goal is mainly making it possible to take self-contained stuff, stick it in a zip file, and have it work unmodified |
| 20:10 | <zewt> | Hixie_: it seems like it would be nice to not have blob's "local magic URL segment" so ZIP urls can always be sent around like any other URL |
| 20:10 | <Hixie_> | even if it messes around with locationpath |
| 20:10 | <annevk> | Hixie_: the bit up to %/ I think |
| 20:10 | <annevk> | Hixie_: we'd have zipPath for the other bit |
| 20:10 | <Hixie_> | zewt: you would have two URLs, one that you send around, and one used internally to make relative urls work |
| 20:10 | <Hixie_> | annevk: so you'd still have to redefine relative url resolution |
| 20:11 | <annevk> | Hixie_: yes, definitely, the idea of %! is to confine changes to URL and Fetch |
| 20:11 | <zewt> | (the whole idea of supporting navigation to zip urls makes me nervous, it's the part that makes everything complicated) |
| 20:11 | <Hixie_> | annevk: my concern with that is js-implemented url resolution would utterly break |
| 20:11 | <annevk> | zewt: no, CSS with subresources has the same issues |
| 20:12 | <annevk> | Hixie_: please hop on the new URL() train? |
| 20:12 | <Hixie_> | ? |
| 20:12 | <zewt> | annevk: not familiar with that |
| 20:12 | <annevk> | Hixie_: maybe I'm not following your concern |
| 20:13 | <Hixie_> | annevk: say you have some script that does path manipulation |
| 20:13 | <Hixie_> | like, it concatenates "/subresource/foo.png" to location.path or something |
| 20:13 | <Hixie_> | it would break if you took that whole app and packaged it in a zip, if we change how relative urls work |
| 20:14 | <annevk> | Hixie_: it seems that's true for using fragments too |
| 20:14 | <Hixie_> | yes |
| 20:14 | <Hixie_> | only the inner/outer thing would keep that, of the suggestions i've seen so far, i think |
| 20:16 | <annevk> | I guess there's some appeal to it, but it seems fairly bad to introduce even more origin-magic. Shit like that goes wrong all the time. :/ |
| 20:16 | <Hixie_> | oh? |
| 20:16 | <Hixie_> | like when? |
| 20:16 | <Hixie_> | we use it e.g. for srcdoc: |
| 20:17 | <Hixie_> | not to mention about:blank, of course |
| 20:17 | <Hixie_> | (srcdoc="", not srcdoc:) |
| 20:17 | <annevk> | It's not like data URLs work fine... Gecko had a bunch of problems with jar URLs. Not sure about srcdoc="". |
| 20:17 | <Hixie_> | data: URLs work fine, the problem is that there's two different implementations and people disagree about which we should be doing. |
| 20:18 | <Hixie_> | (plus some issues around redirects, but we get that kind of issue with other schemes too) |
| 20:21 | <annevk> | Introducing inner/outer seems bad too. And will break code that uses e.g. document.location to get the origin... |
| 20:25 | <JakeA> | Can the browser render a html response half way through the transfer, without chunked encoding? |
| 20:26 | <Hixie_> | yes |
| 20:26 | <JakeA> | Even if it's gzipped? |
| 20:26 | <Hixie_> | sure |
| 20:26 | <Hixie_> | (whether they do or not, i dunno. but they could.) |
| 20:26 | <heycam> | annevk, noted (about Array) |
| 20:27 | <Hixie_> | annevk: yeah, that's why i was trying to put the origin into the url somehow... |
| 20:27 | <JakeA> | Yeah, thought so, in an argument where I'm being told it's not possible. Pfft. |
| 20:27 | <Hixie_> | JakeA: why wouldn't it be possible? |
| 20:27 | <JakeA> | Hixie_: yep, that's what I'm saying |
| 20:27 | <annevk> | I wonder how much people are confusing gzip and zip |
| 20:28 | <annevk> | many... |
| 20:28 | <annevk> | heycam: so yeah, we should fix the whole array mess and prolly remove [] |
| 20:28 | <JakeA> | What's the benefit of chunked encoding then? Flushing without knowing the content length? |
| 20:29 | <annevk> | heycam: sequence<> seems good, but could just be "... sequence" maybe? |
| 20:29 | <Hixie_> | JakeA: there are various advantages, but yeah, one is not having to know the length ahead of time |
| 20:29 | <annevk> | heycam: like Constructor(...Blob parts, Options dict) |
| 20:30 | <heycam> | I'm not sure "…" is the right semantics if you want to pass an [] object |
| 20:30 | heycam | -> call |
| 20:30 | <JakeA> | Hixie_: cheers! |
| 20:32 | <annevk> | heycam: I thought sequence was like var freshArr = [...arrLike] in ES6 |
| 20:32 | <annevk> | heycam: I think that's what we want it to be anyway |
| 20:38 | <annevk> | heycam: ah calls... boring |
| 20:38 | <annevk> | heycam: I also wanted to talk about ByteString and [EnsureUTF16] |
| 20:39 | <TabAtkins> | annevk: You don't want to use ... in that way. |
| 20:40 | <TabAtkins> | foo(...parts, dict) is equivalent to foo(parts[0], parts[1], parts[2], ..., dict) in user code. |
| 20:40 | <TabAtkins> | Which is not the same as what you're trying to indicate there. |
| 20:40 | <annevk> | Ah yeah, that's how the constructor should have worked. |
| 20:40 | <annevk> | So you want [...Blob] parts I guess |
| 20:40 | <TabAtkins> | Yeah. |
| 20:41 | <TabAtkins> | I guess. |
| 20:41 | <annevk> | Doing new-ES-style destructering makes a lot of sense now it exists |
| 20:42 | <annevk> | heycam: I'm not really happy with the syntax at the moment, but http://fetch.spec.whatwg.org/#api is something like what should be expressible I guess |
| 21:57 | <Domenic_> | heycam: annevk: TabAtkins: I think ideally parameters that can be "sequences" should just use `Array.from` semantics. |
| 21:57 | <TabAtkins> | Domenic_: What does that mean? |
| 21:58 | <Domenic_> | TabAtkins: works on iterables, array-likes, and true arrays. |
| 21:58 | <TabAtkins> | Ah, ok. Yes. |
| 21:59 | <Domenic_> | although, you have to anticipate the possibility of infinite iterators, hrm. |
| 21:59 | <Domenic_> | i guess Array.from just loops forever for those |
| 22:02 | <TabAtkins> | Yes. |
| 22:12 | <heycam> | annevk, for what you put in http://fetch.spec.whatwg.org/#api does Array differ from sequence at all? |
| 22:12 | <heycam> | (just more obvious?) |
| 22:13 | <heycam> | or is it that it's allowed to return a reference to a not-newly-created object? |
| 22:33 | <MikeSmith> | Hixie_: about <table><input></table> Henri's parser wasn't emitting an error for it so I'd been assuming there was some reason for that, that it was intentional -- that the spec didn't require a parse error for it |
| 22:35 | <MikeSmith> | then... I actually bothered to read the spec. So I filed https://bugzilla.mozilla.org/show_bug.cgi?id=910588 (log a parse error for <table><input></table>) & I'll send a patch there |
| 22:36 | <MikeSmith> | that thing is that when Henri's code isn't doing what I'd expect my first assumption is always that it's because I'm misunderstanding something or doing something wrong |
| 23:00 | <Hixie_> | MikeSmith: hehe |
| 23:00 | <Hixie_> | MikeSmith: i know the feeling |
| 23:09 | <zewt> | gar gmail's ui is stupid |
| 23:09 | <zewt> | i can't collapse hixie's 50-page reply without it also hiding the reply I'm writing to it |
| 23:09 | <zewt> | 2px scrollbar |
| 23:09 | <Hixie_> | pine baby |
| 23:10 | <zewt> | definitely not pining for pine |
| 23:11 | <MikeSmith> | pine is so old school |
| 23:11 | <MikeSmith> | mutt is what everybody's using these days |
| 23:13 | <hober> | gnus 4 eva |
| 23:14 | <Hixie_> | i could never figure gnus out |
| 23:14 | <Hixie_> | would make my life way easier given that i do everything else in emacs |
| 23:17 | <MikeSmith> | hober and howcome are keeping gnus alive |
| 23:19 | <zewt> | what exactly happened to the idea of spammers being blacklisted |
| 23:20 | <zewt> | at some point spamming openly became "okay" and nobody asked me |
| 23:20 | <MikeSmith> | zewt: sounds like a job for Peter Swire |
| 23:22 | <MikeSmith> | Hixie_: if you hit yourself on the head with a brick first, gnus starts to make more sense |
| 23:22 | <MikeSmith> | oh wait sorry I guess that's the general strategy for using emacs |
| 23:22 | <Hixie_> | zewt: it did? |
| 23:22 | <Hixie_> | spamming whom where? |
| 23:22 | <zewt> | on the internet |
| 23:23 | <Hixie_> | i don't understand what you think changed |
| 23:24 | <zewt> | marketing departments somehow convinced the world that "this person gave us his email address for transactional mails in order to complete a purchase" == "we can send commercials to this email address" |
| 23:28 | <Hixie_> | you're clearly transacting with the wrong merchants. |
| 23:29 | <zewt> | that would be "all merchants" these days :( |
| 23:29 | <Hixie_> | not the ones i use... |
| 23:38 | <heycam> | TabAtkins, are those section links in the margin css-variables positioned using ems? I wonder if it would look better with a fixed distance from the title of the section |
| 23:39 | <TabAtkins> | Yes they are, and yes, I thought that too. I hadn't gotten around to it yet. |
| 23:39 | <heycam> | :) |
| 23:39 | <TabAtkins> | Gonna move 'em with rems I guess. |
| 23:39 | <heycam> | yeah that's what I was thinking |
| 23:39 | <heycam> | the line-height (I guess?) also makes their yellow background look a bit big |
| 23:39 | <heycam> | not sure what you can do about that, while keeping them baseline aligned with the text of the section, though |
| 23:40 | <heycam> | *text of the section title |
| 23:40 | <TabAtkins> | I tried to make the clickable area sufficiently large. That does make it look a little weird. |
| 23:40 | <TabAtkins> | Maybe I can just make the line-height bigger? |
| 23:40 | <TabAtkins> | I need to experiment. |
| 23:40 | <heycam> | interestingly, the Chinese-style angle quotes used around tokens are shown as full width characters in Chrome, but narrowly in Firefox |
| 23:41 | <heycam> | (the latter looks nicer) |
| 23:41 | <TabAtkins> | They look very similar to me on Linux. |
| 23:41 | <heycam> | wonder if a different font is being selected |
| 23:41 | <heycam> | anyway |
| 23:42 | <heycam> | now that we have variables, I want a CSS function that can be used to do operations on colours |
| 23:42 | <TabAtkins> | Yeah, must be. I get ugly full-width on one of my machines, in some context. |
| 23:42 | <heycam> | so I can hue rotate, desaturate, etc. based on a variable value |
| 23:42 | <TabAtkins> | What do you take me for, an amateur? http://tabatkins.github.io/specs/css-color/Overview.html#modifying-colors |
| 23:42 | <heycam> | I was thinking we could use the filter function values |
| 23:42 | <TabAtkins> | Got approved to go to ED yesterday. |
| 23:42 | <heycam> | oh there you go ;) |
| 23:55 | <MikeSmith> | TabAtkins: you need approval to make an ED? |
| 23:56 | <TabAtkins> | MikeSmith: To actually make a work item for the CSSWG, in the CSSWG's part of the w3 url namespace? Yes, by convention. |
| 23:56 | <TabAtkins> | I put "personal" EDs off in my github due to this. |
| 23:56 | <TabAtkins> | This is partially a result of CSS editors always pointing people to look at our ED repo - anything in there is assumed to be "real". |
| 23:58 | <MikeSmith> | ok |
| 23:59 | <Hixie_> | do we have anything in any spec that prevents scripts in inactive documents from running? e.g. when nodes in inactive documents receive events? |