| 00:03 | <Hixie> | annevk: ideas on how to procede for https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 ? |
| 01:08 | <erlehmann> | regarding progressive images, is there a user agent that downloads only the first scan of a progressive JPEG when bandwith is contrained? |
| 01:09 | <erlehmann> | the second time the FF DA it could stop downloading stuff. but then that implies range requests. |
| 01:10 | <SamB__> | well, if the connection is ultra slow it could RST |
| 01:10 | <erlehmann> | i already experimented with creating thumbnails that way |
| 01:10 | <erlehmann> | IZE_TARGET=$(od -t x1 <"$1" |grep 'ff da' |head -n2 |tail -n1 |cut -d' ' -f1) |
| 01:10 | <erlehmann> | head -c"$SIZE_TARGET" <"$1" |
| 01:10 | <erlehmann> | env printf '\xff\xd9' # add End Of Image (EOI) JPEG marker |
| 01:11 | <erlehmann> | works quite well! |
| 01:20 | <erlehmann> | http://kaioa.com/k/test/choppy/index.html |
| 02:55 | <MikeSmith> | Hixie: related to https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/07v_yMErc_A from abarth (against the intent to implement for the table sortint API), I wonder if in the future we'll continue the policy of dropping a feature if multiple vendors declinine to natively implement it |
| 02:56 | <MikeSmith> | Hixie: If we want web-components libraries to have something standard to implement and expose, we'd still need a spec that defines the standard behavior |
| 02:59 | <caitp> | why would web components libraries care about a standard, they'd have no reason to be interoperable with each other |
| 03:00 | <caitp> | the linked sortable-table component is certainly not compliant with the standard, it's just another cute javascript library, which is yet another piece of third party code that application developers don't want to use and probably won't |
| 03:01 | <caitp> | standards make sense for interop, but when interop doesn't matter, there isn't much point |
| 03:07 | <MikeSmith> | caitp: the other reason for having the standard is to have sane behavior that's has some discussion and some level of agreement behind it |
| 03:07 | <MikeSmith> | s/the other/one other/ |
| 03:08 | <MikeSmith> | and to ensure interoperability for the case where some UAs do implement it natively |
| 03:08 | <MikeSmith> | so devs can code against the same API |
| 03:10 | <caitp> | sure, that makes sense when some vendors take the plunge and implement |
| 03:10 | <caitp> | but if nobody does, then all the discussion in the world doesn't matter, because what ends up happening is people just hack stuff together using the tools that they know |
| 03:11 | <caitp> | there will be common patterns of behaviour, but there won't be concensus |
| 03:11 | <caitp> | they won't be interchangeable |
| 03:11 | <caitp> | and that's the status quo, we already have that |
| 03:12 | <caitp> | what we don't have is an environment where I can write a rich application without relying on scripting |
| 03:55 | <JonathanNeal> | Life! Seriously, I just want to code. |
| 04:01 | <caitp> | well, Mozilla would probably be more open to implementing experimental features like that, I mean they've already got support for microdata and I can't think of any other implementations |
| 04:02 | <caitp> | or any apps that really need it |
| 04:02 | <JonathanNeal> | caitp: do you have an opinion on how far along the table sort polyfill should be before I throw it on GitHub? |
| 04:03 | <caitp> | I don't think it really matters, there's no reason you can't just put up a bikeshed and start getting people to look at it and see what's missing/broken/wrong |
| 04:04 | <JonathanNeal> | good point, but if it’s about getting attention, should i wait till tomorrow 9 PST? |
| 04:06 | <caitp> | I dunno, planning on tweeting it or something? |
| 04:07 | <JonathanNeal> | If tweeting means interested devs, opinions, etc. |
| 04:14 | <JonathanNeal> | Devs bring action. Action brings features. |
| 05:01 | <zcorpan_> | Hixie: what is correct behavior here per spec? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3134 |
| 05:02 | <Hixie> | from memory, i'd expect it to nuke the document, then alert "foo" |
| 05:02 | <Hixie> | oh hm actually |
| 05:02 | <Hixie> | step 15 says to create a new Window object |
| 05:02 | <Hixie> | so maybe not |
| 05:03 | <Hixie> | nuke the document and alert "undefined"? |
| 05:07 | <caitp> | didn't that come up last week? we determined blink was doing the wrong thing and gecko was doing it right |
| 05:07 | <caitp> | well, I came to that conclusion |
| 06:05 | <JonathanNeal> | Sorry if I’m late to the party, but does http://lists.w3.org/Archives/Public/www-validator/2014Aug/0026.html mean we could automate document validation? I’m guessing this has been possible for a long time and I was just not privy to it. |
| 06:14 | <zcorpan_> | Hixie: yeah it's not clear to me if creating a new Window means the old variables go away, but i guess they should |
| 06:15 | <zcorpan_> | Hixie: see https://miketaylr.com/posts/2014/08/document-writing-zeptos.html |
| 06:18 | <SamB__> | zcorpan_: Creating a new Window doesn't make the variables *go away*, they're still there on the old Window. Throwing out the old Window, on the other hand ... |
| 06:20 | <zcorpan_> | SamB__: can you get back to the old window? or keep a kungfu deathgrip of it somehow? |
| 06:21 | <SamB__> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3134 |
| 06:21 | <SamB__> | %3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0Avar%20x%20%3D%20%27foo%27%3B%0Aonload%20%3D%20function%28%29%20%7B%0Adocument%2Ewrite%28%27%3Cscript%3Ealert%28window%2Ex%29%3C%5C%2Fscript%3E%27%29%3B%0A%7D%0A%3C%2Fscript%3E% |
| 06:23 | <Hixie> | there's no way from JS to ever actually hold a reference to a Window |
| 06:23 | <Hixie> | you can only ever hold a WindowProxy |
| 06:24 | <SamB__> | hmm |
| 06:24 | <SamB__> | how do I know there's a window at all? |
| 06:25 | <SamB__> | (maybe you meant to say "another window"?) |
| 06:26 | <mathiasbynens> | Hixie: the Chromium team doesn’t seem to think native table sorting is a good idea :( https://groups.google.com/a/chromium.org/d/topic/blink-dev/07v_yMErc_A/discussion |
| 06:27 | <SamB__> | can't you just use SQL for that |
| 06:34 | <caitp> | it was a long-shot to get support for that because the status quo has been good enough for so long, so nobody is really surprised that it got rejected, but it's understandably disappointing for people |
| 06:37 | <zcorpan_> | x is still in scope after document.write() has returned though |
| 06:39 | <SamB__> | yeah, if code is still running for a given Window, that Window is still alive: it's the frickin global scope! |
| 06:42 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3135 |
| 07:10 | <MikeSmith> | JonathanNeal: yeah this is first time I've done a public announcement about the vnu.jar file being available, but I've been working on it for a while and made it available previously but just without announcing it |
| 07:13 | <MikeSmith> | JonathanNeal: Jörn Zaefferer's been providing https://github.com/jzaefferer/grunt-html for a while, which uses that jar file |
| 07:15 | <MikeSmith> | JonathanNeal: I think a big part of the reason I initially created the file is that Jorn wanted something to use for automating testing of HTML files for JQuery UI testing |
| 07:17 | <MikeSmith> | stop everything -- a bug reporter says, "I have now invested quite a lot effort into this bug, time has come for you to act" |
| 07:19 | MikeSmith | adds that to w3c bugzilla quips |
| 07:22 | Ms2ger | acts |
| 07:23 | <Ms2ger> | -> RESO WONTFIX |
| 07:27 | <zcorpan_> | MikeSmith: which bug? |
| 07:36 | <MikeSmith> | zcorpan_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376 |
| 08:07 | <hsivonen_> | annevk: whoa! it looks like CORS breaks the rule that ED is newer than TR! |
| 08:08 | <Ms2ger> | hsivonen, the ED is at http://fetch.spec.whatwg.org/ ;) |
| 08:09 | <hsivonen> | Ms2ger: oh. |
| 08:09 | <hsivonen> | Ms2ger: have the CORS bits changed since TR? |
| 08:10 | <Ms2ger> | No idea |
| 08:23 | <foolip> | annevk: sorry, I didn't see your message yesterday |
| 08:24 | <foolip> | I'm not entirely sure what I want, I filed another bug where I thought I figured out the underlying problem, but even then I'm not sure |
| 09:46 | <JakeA> | wanderview: filed a ticket to allow ServiceWorker over http on localhost https://bugzilla.mozilla.org/show_bug.cgi?id=1059174 |
| 09:56 | <JakeA> | annevk: Is Firefox going to make fetch available on window.fetch? |
| 14:21 | <wanderview> | JakeA: I think annevk might be out today |
| 14:21 | <JakeA> | wanderview: ahh ok, no worries |
| 14:21 | <wanderview> | JakeA: we can ask nsm when the US west coast wakes up |
| 14:30 | <wanderview> | JakeA: does this pref work for allowing http? dom.workers.serviceWorkers.testing.enabled |
| 14:31 | <wanderview> | we also have this: https://bugzilla.mozilla.org/show_bug.cgi?id=1003991 |
| 14:33 | <JakeA> | wanderview: worried that a developer may enable that for testing but forget to unset it, leaving their browser less secure. Same with the devtools-open thing, not sure the browser should be less secure because devtools are open. A flag with comma separated origins (or similar) would work |
| 14:34 | <JakeA> | wanderview: in Chrome, we're going to allow serviceworkers on localhost by default, but a way to whitelist particular domains would be useful too |
| 14:35 | <wanderview> | JakeA: yea, the dom.workers.serviceWorkers.testing.enabled pref is not something to recommend in general and should eventually go away |
| 14:35 | <JakeA> | wanderview: ohh, does that exist currently? |
| 14:35 | <wanderview> | JakeA: it does I think |
| 14:36 | <wanderview> | JakeA: I think the localhost approach has merit... I left both bugs open... we can do one or both... I'll ask nsm what he thinks |
| 14:37 | <JakeA> | cool! |
| 14:37 | <wanderview> | it doesn't show in about:config, but I think you can add it there |
| 14:38 | <JakeA> | gotcha, cheers |
| 14:43 | <JakeA> | wanderview: It's dom.serviceWorkers.testing.enabled - and it works. Cheers! |
| 14:44 | <wanderview> | great! |
| 15:23 | <Domenic> | wow, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376 he is saying just plain false things in his last comment |
| 15:33 | <caitp> | well they seem to have made up their mind about it, anyway |
| 15:34 | <wanderview> | JakeA: I have some answers to some of your questions... |
| 15:35 | <wanderview> | JakeA: we are going to fix console.log() to work on SharedWorker/ServiceWorker before Sep 30, but possibly not before your demo... this will probably broadcast to same-origin devtools web console for now... full worker support in devtools is in progress, but will take longer |
| 15:35 | <wanderview> | JakeA: we do plan to expose window.fetch() |
| 15:36 | <wanderview> | JakeA: we also plan to support http SW on localhost, although it might not be available till after Sep 30 |
| 15:36 | <wanderview> | hope that helps! |
| 15:45 | <MikeSmith> | Domenic: at least the part where he says "I'm at the end of my wisdom now" seems like it might be non-false |
| 15:45 | <JakeA> | wanderview: Cool! I'm giving the talk later in the year too, so I'll update it as things progress |
| 15:45 | <JakeA> | that's cool, cheers! |
| 16:41 | <Ms2ger> | Something up with irc.w3.org? |
| 16:41 | <Ms2ger> | And with that, it's back |
| 18:19 | <Sample> | What is the origin of the bizarrely verbose x-www-form-urlencode? Is Ian Hickson to blame? |
| 18:19 | <Sample> | And what's with the decade+ of the x- prefix |
| 18:20 | <Ms2ger> | Probably IETF |
| 18:26 | <jsbell> | Late-90s: "What content type should we use for our beta product?" "We haven't issued an RFC yet, so you should call it x-something until you're ready to document it" (one week later) "we have an install base of 250 million and can't break compatibility" "d'oh" |
| 18:29 | <Sample> | Seems like an inherent, natural, and built-in problem of the x- prefix |
| 18:30 | <Sample> | I mean, what's the problem with dropping it and supporting the x- prefix for legacy compatability |
| 18:31 | <jsbell> | For what benefit? Agreed that 'x-' now has no meaning, but it's harmless and supporting two variants is more work for what benefit? |
| 18:31 | <Sample> | I don't know, clarity, semantic importance, accordance with specification |
| 18:32 | <Sample> | "more work" is a pretty odd defense |
| 18:32 | <Sample> | more work for whom? |
| 18:35 | <jsbell> | Presumably, every web server vendor needs to add support for both. Then after some period of time browser vendors could consider no longer sending the x-, at the risk of breaking some web sites. |
| 18:37 | <Sample> | yep |
| 18:37 | <jgraham> | Yeah, so you are proposing changing every server in the world in order to drop two characters from an opaque string |
| 18:37 | <jgraham> | The cost/benefit there is terrible |
| 18:38 | <jgraham> | Even if it wasn't there's simply no way to make it happen |
| 18:38 | <Sample> | Lol, you people are mad. Are you finding it an unreasonable burdeon to impart on web server vendors to "add support" to specification? It's the entirety of their service |
| 18:38 | <jgraham> | Even things that have high cost and relatively little usage are almost impossible to change |
| 18:39 | <jgraham> | e.g. we have been unsuccessful at dropping attribute nodes and so far seem unsuccessful at dropping mutation events |
| 18:40 | <jgraham> | Sample: We have literally no way of imparting burdens on web server vendors |
| 18:41 | <jgraham> | Even if we did, this wouldn't solve that problem |
| 18:41 | <jgraham> | Lots of individual applications will have code that specifically looks at MIME types |
| 18:42 | <jgraham> | Changing those individual applications is straight up impossible |
| 18:42 | <Sample> | I'm not sure user agents should have catered to that either |
| 18:44 | <JakeA> | In IDB, you can do index.openCursor(range), but if that index is build of multiple properties, as in entryStore.createIndex(name, ['a', 'b']), what is 'range' acting on? |
| 18:44 | <Sample> | but at least that argument holds some weight compared to "but it would be more work" |
| 18:44 | <JakeA> | built* |
| 18:44 | <jsbell> | JakeA: The index keys |
| 18:45 | <Sample> | the "change ever server in the world" argument is nearly equally ridiculous though |
| 18:45 | <jsbell> | JakeA: Want a more clarifying example? |
| 18:45 | <jsbell> | Sample: so when do browser vendors get to stop sending the 'x-' ? |
| 18:46 | <Sample> | whenever they choose to. probably not for a long time. but developers can make the decision when they reasonably expect to talk to modern webservers. in the exact same manner they make the decision not to cater to IE8 |
| 18:47 | <JakeA> | jsbell: I understand that if entryStore.createIndex(name, 'name'), then index.openCursor(IDBKeyRange.only('george')) gets me the entries where the 'name' property equals 'george'. But what if it's entryStore.createIndex(name, ['name', 'age'])? What does index.openCursor(IDBKeyRange.only('george')) do now? |
| 18:48 | <JakeA> | jsbell: And what if I wanted to get the entries with name 'george' and age 30 |
| 18:48 | <jsbell> | jakeA: Since you didn't specify multiEntry, the keys in the index will be arrays e.g. ['alice', 30], ['bob', 40] |
| 18:48 | <jsbell> | JakeA: So you'd need to do e.g. index.openCursor(IDBKeyRange.only(['alice', 30])) |
| 18:48 | <JakeA> | jsbell: Aha! |
| 18:49 | <jsbell> | JakeA: or index.openCursor(IDBKeyRange.lowerBound(['alice'])) to start getting all the alice records, and manually stop when you run out. |
| 18:49 | <Sample> | if it would enter a specification there could at least be progress. it's as if the argument is entirely about "bad enough". x-IllIlIIlIllllI would be "too bad" but "x-web-world-form-encodeuricomponent" may not be. what about not playing "bad enough" |
| 18:50 | <JakeA> | jsbell: multiEntry fails if it's a compound key, right? |
| 18:50 | <jsbell> | jakeA: Or compute a range of "first alice" through "last possible alice" which is slightly nontrivial, see https://gist.github.com/inexorabletash/5462871 |
| 18:50 | <Sample> | its funny that the original argument is "too much work for servers", with no consideration to the PEOPLE (developers) who need to know and account for standards. where is the "too much work" exactly |
| 18:52 | <jsbell> | JakeA: right, or you'd get an index entry for 'alice' and another index entry for 30, which is kinda weird. That said, https://www.w3.org/Bugs/Public/show_bug.cgi?id=21836 |
| 18:53 | <JakeA> | jsbell: excellent, thanks! |
| 18:54 | <jsbell> | JakeA: happy to help |
| 18:56 | <JakeA> | jsbell: it'd be great to do a deep dive article on IDB in the nature of http://www.html5rocks.com/en/tutorials/es6/promises/ - I might give that a ago towards the end of the year, prepare for big questions |
| 18:57 | <jsbell> | JakeA: I'd love to help, let me know if it materializes. |
| 18:59 | <JakeA> | jsbell: comparing your string prefix code with https://github.com/dfahlander/Dexie.js/blob/b0cbae793de7177491ba9f6e0854673c27279168/src/Dexie.js#L1449 - Dexie's seems simpler, any idea how it works? |
| 19:00 | <jsbell> | JakeA: I'm pedantic and handle numbers, dates and arrays, not just strings. Also... |
| 19:00 | <JakeA> | I mean just the string bit |
| 19:02 | <jsbell> | JakeA: presumably it fails on strings that actually end with U+FFFF, let me squint at it a bit... |
| 19:02 | <JakeA> | Glad it's not painfully obvious |
| 19:04 | <Sample> | jgraham: any thought on my final statement regarding supporting a more sane and less legacy mime type or is your defense impenetrable? |
| 19:05 | <jsbell> | JakeA: yeah, so if 'abc' were your prefix, that'd compute a range of 'abc' ... 'abc\uFFFF' which would exclude 'abc\uFFFF\uFFFF' |
| 19:09 | <JakeA> | jsbell: that's good enough for me in this case, cheers! |
| 19:32 | <JakeA> | annevk: can we get a .keys() on http://fetch.spec.whatwg.org/#headers? |
| 19:35 | <JakeA> | The chrome impl has forEch currently |
| 19:36 | <wanderview> | JakeA: I think he wanted something about es6 iterators to be available |
| 19:36 | <wanderview> | I didn't quite follow what he wanted |
| 19:36 | <JakeA> | Yeah, worried that's coming too late |
| 19:37 | <wanderview> | .keys() seems reasonable to me... although you can't observe the absolute ordering of the headers with it |
| 19:37 | <JakeA> | true |
| 19:38 | <JakeA> | only an issue with multiple headers of the same name |
| 19:38 | <wanderview> | yea... I only mention it because the spec says we have to maintain the absolute ordering... but then has no way to observe it |
| 19:39 | <jsbell> | The ES6ism would probably be: let keys = []; for (let header of headers) keys.push(header[0]); |
| 19:40 | <wanderview> | ah, so duplicate keys in the array |
| 19:40 | <JakeA> | I suppose you could get the right order then |
| 19:40 | <wanderview> | although that is weird given you can't get at the per-key value |
| 19:40 | <JakeA> | yeah |
| 19:41 | <JakeA> | you'd be getAll(key)[blah] |
| 19:41 | <JakeA> | es6 iterators will fix that |
| 19:41 | <wanderview> | yea |
| 19:41 | <jsbell> | Map.prototype.entries() would be the thing to copy to get key/value pairs |
| 19:42 | <jsbell> | --> food |
| 19:42 | <Domenic> | Ideally that interface should have keys()/values()/entries()/forEach()/[Symbol.iterator]() |
| 19:42 | <Domenic> | I think annevk wanted some IDL thing that will automatically implement those |
| 19:43 | <Domenic> | Probably the way forward would be to prod him for exactly what he wants and then have someone do the WebIDL pull request |
| 19:44 | <Domenic> | but be careful exposing stuff without a solid spec because e.g. if you made keys() return an array that would be unlike all other ES6 things |
| 19:44 | <Domenic> | (which just expose a custom iterator) |
| 19:45 | <Domenic> | forEach for example needs to conform to the forEach((key, value, headers) => {}, thisArg) signature |
| 19:45 | <wanderview> | I guess the Cache/CacheStorage keys() are already non-standard as they return a Promise<sequence<>> |
| 19:45 | <Domenic> | yeah |
| 19:46 | <Domenic> | that is where ES7-timeframe async iterators would come in |
| 19:46 | <Domenic> | oh right, I remembered why I came to this tab |
| 19:47 | <Domenic> | I wanted to complain about how the ARIA spec is a big mix of "maybe authors will be expected to do this if they have a good reason" |
| 19:47 | <Domenic> | "and authors are expected to have valid reason to provide a WAI-ARIA role even on elements that would not normally be repurposed" :-S |
| 19:55 | <Domenic> | Hixie: is there a reason why e.g. myHR.getAttribute("role") is null insteadof "separator"? That is, lots of elements have implicit (or "strong native") ARIA roles, but we don't reflect them in their DOM attributes |
| 19:55 | <Domenic> | Hmm, OK, maybe it's because of the fact that strong native ARIA things are supposed to be non-overridable |
| 19:56 | <Domenic> | and the default implicit ARIA things need to be the default if you remove the attribute |
| 19:56 | <Domenic> | Hixie: nevermind! I think it makes sense now. |
| 20:02 | <annevk> | Domenic: yup, I want that |
| 20:03 | <Domenic> | annevk: what kind of text do you envision writing. i.e. how much work do spec-writers have to do. |
| 20:04 | <annevk> | there's a bug for that :p |
| 20:05 | annevk | tries to find it |
| 20:06 | <annevk> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183 is the bug on what I'd like |
| 20:06 | <annevk> | Domenic: not sure how attainable it is |
| 20:07 | <annevk> | Domenic: but basically it comes down to the minimum amount of information you would need from an object to get all those methods |
| 20:07 | <annevk> | Domenic: while not caring about perf I guess |
| 20:23 | <jsbell> | I believe, given an internal list, you need to define the hooks length(list) and get(itemKind, list) for itemKind of "key", "value", "key+value"; the rest is boilerplate |
| 20:26 | <jsbell> | (to match the ES6 iterators with regards to liveness etc) |
| 20:27 | <jsbell> | *sigh*, and then there's the /empty/ case Domenic points out in the bug comment. Bleah. |
| 20:28 | <Domenic> | I don't think we should do live iterators in any case on the platform |
| 20:28 | <Domenic> | Even for live NodeLists |
| 20:34 | <jsbell> | I suppose DOMTokenList should be set-like |
| 20:38 | <annevk> | jsbell: yeah, misnamed |
| 20:39 | <annevk> | jsbell: I'm trying to at least make the underlying terminology for those objects is correct, though I only started doing so recently so there's probably room for improvement |
| 20:39 | <annevk> | /\ sure |
| 20:58 | <Hixie> | mathiasbynens: if you want the feature, defend it :-) |
| 21:04 | <Hixie> | caitp: can you clarify what exactly it is you changed in https://gist.github.com/caitp/71a97bcb41fdb145b688 ? trying to manually do the diff is giving me a headache |
| 21:05 | <caitp> | the use of phrases like "12.7 Repeat while group cursor is not null" rather than "Label: <do a thing>" + "If <x> jump to <label>" |
| 21:06 | <caitp> | for instance |
| 21:07 | <caitp> | but that's not really the important part (although it is nice to see the pattern that is happening on the first step rather than down 15 steps) |
| 21:07 | <caitp> | the important thing is the changes to indentation and nested numbering, makes it so much easier to visualize. |
| 21:48 | <Hixie> | caitp: ok that didn't really respond to comment 2 then, ok |
| 21:48 | <Hixie> | caitp: responded on the bug |