| 00:33 | <zewt> | browsers very challenging to use when they don't show a busy pointer |
| 00:33 | <zewt> | click link, nothing happens, wonder |
| 00:35 | <zewt> | TabAtkins: not sure if relevant but http://krijnhoetmer.nl/irc-logs/whatwg/20140412#l-231 |
| 00:36 | <SamB> | zewt: how does that work when there is no pointer to start with |
| 00:37 | <SamB> | I bet mobile users hate imagemaps even more than desktop users do ;-) |
| 00:37 | <zewt> | that's a problem for those platforms, if I'm on a platform with a mouse (or equivalent), it needs to show that it heard my click |
| 00:38 | <zewt> | (was looking for that link above, and getting irritated at clicking links on that page, and not being able to tell naturally whether it was network lag or just me fatfingering the touchpad) |
| 00:38 | <SamB> | hmm, don't they usually replace the favicon with a throbber too? |
| 00:38 | <zewt> | that's not an alternative--that's not where I'm looking when I click |
| 01:10 | <MikeSmith> | . |
| 01:11 | <paul_irish> | . |
| 01:12 | <MikeSmith> | heh |
| 02:23 | <MikeSmith> | slightlyoff: can you let Takuya know I'm downstairs? |
| 13:14 | <jgraham> | zcorpan: Did you see I reviewed your worker changes? |
| 13:14 | <zcorpan> | jgraham: nope. lost focus of critic |
| 13:15 | <zcorpan> | jgraham: thanks |
| 13:26 | <jgraham> | zcorpan: For the record, I am still seeing some instability in /html/infrastructure/urls/resolving-urls/query-encoding/* and /websockets/unload-a-document/[005|003].html |
| 13:27 | <zcorpan> | jgraham: do you have more details for query-encoding? |
| 13:33 | <zewt> | n.onshow = () => setTimeout(() => n.close(), 7000) <- this syntax is not even remotely okay |
| 13:34 | <zewt> | stop taking one of the syntactically cleaner languages and making it gross |
| 13:34 | Ms2ger | gets off zewt's lawn |
| 13:41 | <jgraham> | zcorpan: TEST-UNEXPECTED-FAIL | /html/infrastructure/urls/resolving-urls/query-encoding/utf-16be.html | loading image <video poster> | expected PASS | assert_equals: expected substring %C3%A5 got undefined expected 2 but got 24 |
| 13:41 | <jgraham> | TEST-UNEXPECTED-FAIL | /html/infrastructure/urls/resolving-urls/query-encoding/utf-16le.html | loading image <video poster> | expected PASS | assert_equals: expected substring %C3%A5 got undefined expected 2 but got 24 |
| 13:41 | <jgraham> | TEST-UNEXPECTED-FAIL | /html/infrastructure/urls/resolving-urls/query-encoding/utf-8.html | loading image <video poster> | expected PASS | assert_equals: expected substring %C3%A5 got undefined expected 2 but got 24 |
| 13:41 | <jgraham> | TEST-UNEXPECTED-FAIL | /html/infrastructure/urls/resolving-urls/query-encoding/windows-1252.html | hyperlink auditing <area ping> | expected TIMEOUT | assert_unreached: Reached poll timeout Reached unreachable code |
| 13:41 | <jgraham> | TEST-UNEXPECTED-FAIL | /html/infrastructure/urls/resolving-urls/query-encoding/utf-16be.html | CSS <link> (utf-8) #<id>::before { content:<url> } | expected PASS | assert_unreached: Reached poll timeout Reached unreachable code |
| 13:42 | <zcorpan> | MikeSmith: webvtt in http://platform.html5.org should have the link updated |
| 13:42 | <jgraham> | That's from 3 runs, so it isn't really telling you much about low-frequency failures |
| 13:45 | <zcorpan> | jgraham: for <area ping> do you think there's a race between the test timing out and the xhr interval timing out? (maybe it can set the result to TIMEOUT instead?) |
| 13:45 | <zcorpan> | jgraham: that test would reliably FAIL if gecko didn't lie about supporting it |
| 13:45 | <jgraham> | zcorpan: Yeah, that's a plausible race |
| 13:47 | <jgraham> | I guess it's *possible* to set the status to timeout, but it's not really supported |
| 13:52 | <MikeSmith> | zcorpan: fixed |
| 13:55 | <MikeSmith> | “consensus is the lack of leadership” |
| 13:55 | <MikeSmith> | from http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/ |
| 13:55 | <MikeSmith> | attributed to Margaret Thatcher |
| 13:56 | <MikeSmith> | Hixie: ↑ |
| 13:56 | <Ms2ger> | Well |
| 13:56 | <Ms2ger> | "My seven years on the Internet Engineering Task Force (IETF), ..." |
| 13:57 | <darobin> | was that Maggie channelling Hixie? :) |
| 13:58 | <yoav> | Who's the best person to bug about fonts, their dimensions, "ex" and "ch" units and media queries? |
| 13:59 | <Ms2ger> | Let's just say TabAtkins |
| 14:01 | <MikeSmith> | yoav: I agree with Ms2ger |
| 14:01 | <MikeSmith> | I smell a consensus emerging |
| 14:01 | <yoav> | consensus is good. Is there a use case as well? |
| 14:02 | <SimonSapin> | yoav: Does this help? http://dev.w3.org/csswg/mediaqueries/#units second paragraph |
| 14:02 | <Ms2ger> | yoav, no, consensus is the lack of leadership ;) |
| 14:02 | <MikeSmith> | yoav: a use case for TabAtkins? |
| 14:03 | <yoav> | SimonSapin: I'm not sure I understand what does it mean for 'ex' and 'ch'. Is there a default value for them? (like the default font size is for 'em') |
| 14:04 | <SimonSapin> | well, let’s look at their definition |
| 14:05 | <SimonSapin> | http://dev.w3.org/csswg/css-values/#font-relative-lengths "ch unit: Equal to the used advance measure of the "0" (ZERO, U+0030) glyph found in the font used to render it." |
| 14:05 | <SimonSapin> | so you do that with the initial value of font-family, font-size, font-weight, etc |
| 14:07 | <SimonSapin> | in other words, as in a document with no style (including UA) applied |
| 14:07 | <TabAtkins> | 'ex' has a default value if there's no font around - it's .5em. |
| 14:07 | <TabAtkins> | 'ch' doens't have a value without a font, and that's a bug. |
| 14:08 | <SimonSapin> | TabAtkins: I’m not the .5em thing applies to MQs |
| 14:08 | <SimonSapin> | I’m not convinced* |
| 14:08 | <TabAtkins> | Why wouldn't it? It's for when the font doesn't tell you an 'ex' size. |
| 14:08 | <TabAtkins> | Which I suspect would include when there's no font at all. |
| 14:08 | <yoav> | SimonSapin & TabAtkins: So, in the context of Media queries, I'd need to get the default browser font, and get the metrics from it? |
| 14:08 | <SimonSapin> | there is a font, the initial value of font-family |
| 14:09 | <SimonSapin> | yoav: I think so, but TabAtkins seems to disagree |
| 14:09 | <TabAtkins> | SimonSapin: Ugh, I guess so, but that's ugly and not very useful. |
| 14:09 | <SimonSapin> | ex is ugly in any case, but meh |
| 14:10 | <TabAtkins> | ex is a useful unit; you hush your mouth. |
| 14:10 | <yoav> | Impl wise, if I have to take a shortcut around their calculation for MQs |
| 14:10 | <SimonSapin> | yoav: 1ex = 0.5em is valid per spec if you don’t want to bother doing all this |
| 14:10 | <SimonSapin> | "impractical" |
| 14:11 | <yoav> | What do I do as a default value for 'ch'? |
| 14:11 | <TabAtkins> | I'll bring it up in the call this morning and edit the spec. |
| 14:11 | <TabAtkins> | It'll probably be .5em as well. |
| 14:11 | <SimonSapin> | TabAtkins: what do implementations do? |
| 14:11 | <yoav> | TabAtkins: Sounds great! |
| 14:12 | <TabAtkins> | SimonSapin: No clue. Not sure who implements 'ch' yet. |
| 14:12 | <SimonSapin> | I’ll try and make a test case for ex in MQs |
| 14:12 | <TabAtkins> | Well, Blink implements it. Let's see... |
| 14:13 | <yoav> | TabAtkins: Blink has a zeroWidth() on the platform's fontMetrics |
| 14:14 | <yoav> | But calling it triggers some weird witchcraft, which makes it impossible for me the cache it just before starting a new thread and passing the value to that thread |
| 14:16 | <yoav> | Looks like this zeroWidth is set by looking at the actual glyphs |
| 14:17 | <yoav> | TabAtkins: I think I'd be able to get these values into where I need them at some point, but I'd love a reasonable default I can use to substitute them in the mean time |
| 14:18 | <TabAtkins> | .5em is definitely a reasonable default for both of them, even if it's just a temporary value that you'll fix later. |
| 14:21 | <SimonSapin> | (min-width: 100ex) and (min-width: 50em) switch at different points on Gecko and Blink on my system http://result.dabblet.com/gist/10883309/fc063ef48196cedcbd457f1609de1e4041e9d5d9 |
| 14:23 | <SimonSapin> | TabAtkins: I’m fine with allowing 1ch = .5em "where it is impossible or impractical to determine" like ex, but not with "it must be .5em in MQs" |
| 14:23 | <TabAtkins> | I'm okay with that. |
| 14:31 | <TabAtkins> | Based on initial testing, Blink uses the real value of 'ex' in MQs, but doesn't support 'ch' at all yet. |
| 14:35 | <zcorpan> | i find not supporting 'ch' at all bettre than 0.5em |
| 14:36 | <MikeSmith> | annevk: the Writing section of the URL spec doesn't specify what code points are valid in a schem |
| 14:36 | <zcorpan> | at least in the preloader context |
| 14:36 | <MikeSmith> | e |
| 14:37 | <TabAtkins> | zcorpan: At least in Chrome's default serif font, 1ch exactly equals .5em. |
| 14:38 | <annevk> | MikeSmith: "A scheme must be one ASCII alpha, followed by zero or more of ASCII alphanumeric, "+", "-", and ".". A scheme must be registered ...." |
| 14:40 | <zcorpan> | TabAtkins: yeah but what if it isn't and you have breakpoints where you care about 'ch' specifically, it would be bad if the preloader thinks one thing and later evaluations think another |
| 14:40 | <TabAtkins> | Right, if you have sufficient knowledge to do better, you should do better. |
| 14:42 | <zcorpan> | gotta go |
| 14:44 | <MikeSmith> | annevk: oh I missed that somehow |
| 15:36 | <JakeA> | Is there anything aside from AppCache that can be used to determine if a cross-origin url looks like a 200? |
| 15:38 | <jgraham> | JakeA: I have no idea about context, but do you mean "in the absence of CORS"? |
| 15:38 | <JakeA> | jgraham: yeah |
| 15:39 | <annevk> | JakeA: aah, cross-origin... |
| 15:40 | <jgraham> | I'm not sure about arbitary urls but <img> and <script> could be used for resources with known behaviour |
| 15:40 | <JakeA> | Trying to work out what to do for serviceworker caches. Either follow AppCache and consider 4xx 5xx a failure, or consider that AppCache feature an error that shouldn't be repeated |
| 15:40 | <JakeA> | jgraham: Good point, CSS too. |
| 15:50 | <tobie_> | JakeA: I'll be working with Moz on their SW implementation. Essentially on the testing part + API feedback |
| 15:50 | <JakeA> | Oh cool! |
| 15:50 | <tobie_> | JakeA: we should sync on the testing front to make sure we don't dup the effort. |
| 15:52 | <JakeA> | tobie_: Agreed. I'm not at that stage yet (still sorting out the algorithms), don't suppose you're posting to a mailing list? |
| 15:52 | <jsbell> | tobie_: We're starting a collection of testharness.js tests for SW as we move into end-to-end testable territory. |
| 15:53 | <tobie_> | jsbell: are you writing those locally or directly against the W3C repo? |
| 15:53 | <jgraham> | tobie_, jsbell: \o/ |
| 15:53 | <jsbell> | tobie_: Locally for now due to churn, but we'll move them to W3C eventually |
| 15:54 | <jgraham> | I am avaliable for all your test automation / infrastructure needs |
| 15:54 | <jernoble|laptop> | ericc: so i have a text track question for you. |
| 15:54 | <jsbell> | For now just in https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/ |
| 15:56 | <tobie_> | jgraham: awesome. SW lifecycle makes testing a tad challenging |
| 15:56 | <tobie_> | Will have to dig more before I can meaningfully ask for help. |
| 15:56 | <jsbell> | speaking of testharness.js - step_func doesn't propagate the return value through so you can't use it in a Promise chain. Should we fix? |
| 15:57 | <jgraham> | tobie_: Yep, I expect there could be some challenges |
| 15:57 | <jgraham> | jsbell: Fixes to make testharness.js better for promise APIs would be awesome |
| 15:57 | <tobie_> | jsbell: thanks for the link. |
| 15:58 | <jgraham> | I notice that zcorpan reviewed https://critic.hoppipolla.co.uk/r/1151 so I will fix that up. Might make writing some tests a little bit easier. |
| 15:58 | <tobie_> | JakeA: what's the preferred place to discuss Sw? |
| 15:58 | <jsbell> | jgraham: I'll see if it's as simple as I think, then make a PR |
| 15:59 | <JakeA> | tobie_: If it's an isuse, https://github.com/slightlyoff/ServiceWorker/issues/. For general stuff, public-webapps I guess |
| 15:59 | <tobie_> | ty |
| 17:23 | <jsbell> | JakeA: SW's Unregister rejects if the registration is not found. That makes it non-idempotent, and unlike e.g. Indexed DB. Is there a strong reason for that? |
| 17:27 | <JakeA> | jsbell: No strong opinion on that one. Means you won't be able to tell the difference between a successful unregistration & a typo in the scope, but consistency sounds better |
| 17:27 | <jsbell> | I'll file a bug. |
| 17:29 | <JakeA> | Cheers, if there's no complaints I'll fix that tomorrow (going to get rid of algorithms.md and just add them to the spec) |
| 17:29 | <JakeA> | (still can't spell algorithms without a spellcheck) |
| 17:32 | <jsbell> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/233 - thanks. |
| 18:04 | <arunranga> | annevk, do you still think that maintaning a check for Blob closure in the read operation for Blob objects is wrong? That is http://dev.w3.org/2006/webapi/FileAPI/#readOperationSection |
| 18:04 | <JakeA> | tobie_: So, this ServiceWorker thing is pretty new and big. Thinking about what we can do for user-support & want it to be a cross-browser effort |
| 18:05 | <JakeA> | tobie_: Any objections to an IRC room, mailing list & StackOverflow attack? |
| 18:06 | <annevk> | arunranga: what is it going to do? return the empty byte sequence? |
| 18:06 | <arunranga> | annevk, no; it should return failure along with a termination reason. |
| 18:06 | <arunranga> | annevk, I don’t think returning the emtpy byte sequence was the right choice. |
| 18:07 | <arunranga> | could you use that in other places, including parse/fetch and formdata? |
| 18:08 | <Domenic_> | JakeA: mailing list vs. stackoverflow has historically been a tricky balance |
| 18:09 | <arunranga> | annevk, basically we’re fleshing out the model in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25302#c9 |
| 18:09 | <annevk> | arunranga: I don't understand that model, you have a function that's supposedly async, but sometimes synchronously returns? |
| 18:09 | <annevk> | arunranga: how does that make sense? |
| 18:09 | <JakeA> | Domenic_: I know. Just been thinking about that. Maybe take mailing list threads and turn them into SO q&a, but maybe they consider that an abuse of SO. |
| 18:10 | <arunranga> | annevk, you proposed a wrapper for closure check within that function. |
| 18:10 | <arunranga> | annevk, unless you want closure checks within individual APIs, and not on the read operation |
| 18:12 | <arunranga> | annevk, I guess the real question is where the closure check should happen. |
| 18:12 | <annevk> | arunranga: if you sometimes sync return, all callers will need to check anyway, so I'm not sure how you're helping by making it weird |
| 18:18 | <annevk> | arunranga: you'll need to through the various scenarios, and figure out what the best model would be for the programmer |
| 18:18 | <Domenic_> | JakeA: as long as it's a well-defined Q&A then you can definitely do that. Answering your own questions is a good thing. People in #promises do that sometimes when we see a FAQ |
| 18:18 | <annevk> | arunranga: e.g. should closed blobs fail silently generally or fail hard |
| 18:18 | <annevk> | arunranga: once you've sorted that out you can figure out a set of concepts for APIs that take blobs to use |
| 18:19 | <annevk> | JakeA: btw, one thing I was wondering about is whether we could expose .status even for OpaqueResponse |
| 18:20 | <annevk> | JakeA: that way you'd know something is being redirected or some such |
| 18:20 | <annevk> | JakeA: and you could implement AppCache as polyfill? |
| 18:21 | <JakeA> | annevk: The more info like that we can expose, the better. Ran that past any security people? |
| 18:23 | <annevk> | JakeA: given that it's already exposed... |
| 18:23 | <annevk> | JakeA: and the bit of the redirect we'd expose is not the thing that's vulnerable |
| 18:24 | <JakeA> | annevk: Wellllll, appcache gives you "it worked" or "it didn't work", where "it didn't work" could be 4xx, 5xx. But it doesn't tell you which |
| 18:24 | <Domenic_> | It might be useful to expose the strings "4xx" or "5xx" even |
| 18:24 | <annevk> | JakeA: fair, and I guess we rather not expose it at all |
| 18:25 | <annevk> | .status is a number |
| 18:25 | <Domenic_> | as if JavaScript cares ;) |
| 18:25 | <annevk> | given that people do comparison with < and >, I do |
| 18:25 | <Domenic_> | still works with strings! |
| 18:26 | <Domenic_> | (well, not very well) |
| 18:27 | <JakeA> | Having cache.add reject if things are 4xx, 5xx, or cross-origin redirect is enough for most things |
| 18:27 | <JakeA> | An option-bag on new Cache() could be used to change those behaviours |
| 18:28 | <arunranga> | annevk, there are actually standard synchronous checks for files on disk that won’t be accounted for in the read operation then. |
| 18:28 | <arunranga> | annevk, this also includes snapshot state and other things. |
| 18:29 | <arunranga> | annevk, individual methods will have to do those. The idea of a ‘reusable’ read operation won’t be that useful then. Or, individual checks will be done for files on disk but not within the read operation. |
| 18:31 | <annevk> | I have no idea what you're talking about arunranga|afk :/ |
| 18:32 | <annevk> | arunranga|afk: the whole point is that read runs in the background, just like fetch... you'll need to elaborate |
| 18:34 | <arunranga|afk> | annevk, a read operation should “fail hard” for a closed blob. That check is synchronous, but clearly can’t be done within the read operation itself. Also, a read operation should fail if the file has changed on disk. |
| 18:35 | <arunranga|afk> | annevk, that’s what I mean. It’s clear these checks can’t be spec’d in a read operation, so APIs have to individually run these checks. I’m happy with that; I tried to see if we could put it in one place place |
| 18:36 | <annevk> | arunranga|afk: I think you need to do some more archeology of how file read actually works |
| 18:36 | <annevk> | arunranga: the whole operation should be async |
| 18:36 | <annevk> | arunranga: presumably there's bits where it can fail, e.g. if the file was moved |
| 18:36 | <annevk> | arunranga: that could happen while reading as well |
| 18:37 | <annevk> | arunranga: so you'll have to explain what happens to the bytes that have already been read, and whether anything is signified at that point, etc. |
| 18:38 | <Domenic_> | sounds like streeeeeams |
| 18:38 | <annevk> | uhuh |
| 18:38 | <annevk> | sounds like Domenic_ found his hammer |
| 18:38 | <Domenic_> | hahaha |
| 18:38 | <annevk> | *new* hammer |
| 18:38 | <Domenic_> | so true |
| 18:39 | <Domenic_> | yeah i needed a new hammer |
| 18:39 | <arunranga> | annevk, sure, but if there’s a hard fail on closure, and that check is synchronous, it can’t be done within the read operation. |
| 18:39 | <arunranga> | And Fx currently proposes a snapshot state check that isn’t asynchronous. |
| 18:39 | <arunranga> | I think my archaeology is probably ok. |
| 18:40 | <arunranga> | I think your insistence on a read operation that’s reusable is good. I’m not sure how some checks can be included within it. That’s fine; FileReader will have to have its own API level checks. |
| 18:41 | <arunranga> | Or maybe a task can determine this fail. |
| 18:41 | <arunranga> | Domenic_ it does sound like streams |
| 18:41 | <arunranga> | (screams/streams) |
| 18:42 | <Domenic_> | arunranga: I am not sure streams can help, since this is largely an existing API/paradigm but ... maybe you could conceptualize how it would work if that existing API was built on top of a stream instance? |
| 18:43 | <Domenic_> | (I don't really understand the problem being talked about, but people started talking about sync vs. async I/O and bits that could fail and what happens to the bytes that have already been read, which are all questions we answered for streams) |
| 18:44 | <annevk> | Domenic_: the problem is basically reading from disk |
| 18:44 | <annevk> | Domenic_: how to define that |
| 18:45 | <annevk> | arunranga: it seems like nonsense that FileReader would have different failures from other APIs, that should all be part of the read concept |
| 18:45 | <Domenic_> | ... in a cross-platform way |
| 18:45 | <annevk> | uhuh |
| 18:45 | <Domenic_> | hammertime answer: with a ReadableStream! |
| 18:46 | <annevk> | Yeah, I don't really understand the difficulty, it seems like you keep consuming bytes, something may fail so you need to deal with that, and you need to present that somehow to your caller |
| 18:47 | <arunranga> | Tasks would be the right answer. |
| 18:47 | <Domenic_> | what is the API under discussion? I thought it was blobs and close() |
| 18:48 | <arunranga> | It is! It’s blobs, close() and closure checks within a read operation. |
| 18:48 | <Domenic_> | what's the API for a read operation |
| 18:48 | <annevk> | FileReader, xhr.send(FormData / Blob) |
| 18:48 | <Domenic_> | isn't xhr.send a write? |
| 18:49 | <arunranga> | Domenic_, FileReader is a caller for a read operation |
| 18:49 | <arunranga> | So’s FormData |
| 18:49 | <annevk> | Domenic_: it's a pipe I guess |
| 18:49 | <arunranga> | read operation uses a Blob and reads it into memory asynchronously or synchronously |
| 18:50 | <Domenic_> | i see |
| 18:51 | <arunranga> | annevk, I am probably not using tasks aggressively enough. I’ll rethink this a bit. |
| 18:51 | <arunranga> | annevk, thanks. |
| 18:51 | <Domenic_> | annevk is always on peoples' case about not using tasks enough ;) |
| 18:51 | <Domenic_> | thanks arunranga annevk for patiently explaining to me |
| 18:51 | <arunranga> | Domenic_, annevk is always on my case period. |
| 18:51 | <Domenic_> | aww |
| 18:52 | <annevk> | hah |
| 18:55 | <jsbell> | JakeA: FYI, for the extended appcache errors I wedged in, status = 0 for any off-origin failure (4xx, 5xx, or network error) |
| 18:55 | <jsbell> | which at least garnered no objections |
| 18:55 | <jsbell> | which may say more about how much everyone loves appcache than the proposal... |
| 19:02 | <JakeA> | jsbell: that's fair. All we need for SW is fulfill/reject and some vague ability to control what should be considered a failure |
| 19:02 | <annevk> | jsbell: URL objects should just be stringified |
| 19:03 | <annevk> | jsbell: http://url.spec.whatwg.org/#url-apis-elsewhere re: IDBv2 |
| 19:04 | <jsbell> | annevk: Not storing URLs; allowing URLs into DB. e.g. <img src="indexeddb:///music/album-covers/1ab2c3df"> |
| 19:04 | <annevk> | ooh |
| 19:04 | <annevk> | confusing |
| 19:04 | <jsbell> | (totally made up scheme, don't quote it) |
| 19:05 | <jsbell> | Sorry. Mail was unclear. Wiki link is better: http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures |
| 19:14 | <arunranga> | jsbell, annevk, scheme proliferation continues :) there’s also a filesystem: scheme to get into the filesystem. |
| 19:15 | <Domenic_> | back in my day we just called that C:!! |
| 19:17 | <annevk> | arunranga: jsbell: one filesystem: scheme might be good, if we need to support relative references and such |
| 19:17 | <annevk> | arunranga: the less URL parser hacks the better |
| 19:18 | <arunranga> | annevk, you mean one scheme to rule both the indexeddb use case, and the filesystem use case? |
| 19:18 | <annevk> | yes |
| 19:19 | <arunranga> | annevk, it could work. |
| 19:19 | <Ms2ger> | Call it blobl: |
| 19:19 | <Ms2ger> | blob:* |
| 19:19 | <Domenic_> | fs:/dev/idb/... |
| 19:20 | <annevk> | Domenic_: don't you mean \\lolwindows\file |
| 19:20 | <Domenic_> | hehehe |
| 19:21 | <Domenic_> | all i'm sayin is that my surface pro 2 was way prettier than all those macbooks at the tag meeting |
| 19:21 | <arunranga> | Ms2ger, I wondered about reusing blob: even for filesystem URL (which by the way is in Chrome for the old filesystem API: http://www.html5rocks.com/en/tutorials/file/filesystem/). |
| 19:21 | <arunranga> | But I’m not sure now |
| 19:23 | <annevk> | I think you want some kind of URL scheme that supports relative URLs |
| 19:23 | <annevk> | blob is not that |
| 19:34 | <arunranga> | annevk, yep. I’ll bet naming is one of the few following hard problems |
| 19:41 | <zewt> | using blob urls for blobs coming from a fs API makes sense, connecting them to fs paths wouldn't |
| 19:50 | <annevk> | that depends on what you want to do |
| 19:51 | <arunranga> | zewt, the use case is the feature that’s already in Chrome. |
| 19:56 | <SamB_> | zewt: but ... plan9! |
| 20:14 | <SamB> | Hmm, you guys know MS icon files can have more than one image in, right? Seems like that's not very well supported on the web ... |
| 20:37 | <zewt> | nothing to do with use cases, blob urls have nothing whatsoever to do with paths |
| 20:38 | <zewt> | urls for referring to paths inside a filesystem API need a different scheme |
| 20:39 | <SamB> | zewt: I guess you missed the joke |
| 20:42 | <zewt> | arun was telling a joke? |
| 20:43 | <SamB> | no I was |
| 20:43 | <SamB> | hmm, okay, I follow you now |
| 20:45 | <SamB> | I take it there's a problem with file:/// ? |
| 20:46 | <Domenic_> | paul_irish: pretty one-sided poll ;) |
| 20:47 | <zewt> | i haven't followed the fs stuff, but i assume it supports sandboxed filesystems |
| 20:47 | <zewt> | which wouldn't be file: |
| 20:49 | <annevk> | Domenic_: https://plus.google.com/+PaulIrish/posts/QchucJRH7BX is great |
| 20:49 | <Domenic_> | :D |
| 20:51 | <SamB> | ah, yes, so I see looking at the html5rocks thing |
| 20:54 | SamB | ponders cross-origin file access ;-P |
| 20:58 | <SamB> | hmm, how many OSes even provide for asynchronous directory creation ... |
| 21:02 | <SamB> | and ... huh ... I'm not aware of any OSes that have handles for directory entries |
| 21:09 | <SamB> | and, hmm, why am I thinking that the biggest risk connected with the ability to write malicious files to disk is that a script could write a file to disk for the express purpose of triggering a warning from an antivirus program? |
| 21:11 | <SamB> | or, um, it could cause searches in explorer on XP to pop up that annoying dialog box it pops up for multi-volume zips ... |
| 21:14 | <SamB> | lol @ <http://www.w3.org/respec/>;: "sadly it cannot replace RFC 2119 with the more accurate RFC 6919". |
| 21:15 | <tiglionabbit> | has anyone put forward a spec for supporting pen pressure and sub-pixel positioning? |
| 21:16 | <SamB> | tiglionabbit: are you looking to write some kind of painting/drawing program? |
| 21:16 | <tiglionabbit> | that would be nice |
| 21:17 | <tiglionabbit> | currently the only way I know of to get at this information is through CelloSoft JTablet, which is a Java applet plugin |
| 21:17 | <tiglionabbit> | and nobody wants to use Java applets anymore |
| 21:17 | <SamB> | I don't imagine Android can run those? |
| 21:18 | <tiglionabbit> | chrome for mac can’t even run them |
| 21:19 | <tiglionabbit> | nor can chrome for chromebooks |
| 21:20 | <SamB> | huh |
| 21:20 | <SamB> | ... isn't there a standard API for JVM plugins? |
| 21:21 | <tiglionabbit> | sure, but chrome only distributes a 32-bit version, and java only distributes 64-bit |
| 21:21 | <SamB> | by which I mean "whatever Mozilla has been using" |
| 21:21 | <SamB> | ah! |
| 21:21 | <SamB> | right |
| 21:22 | <tiglionabbit> | anyway, has anyone made a spec for this? |
| 21:22 | <SamB> | that actually rings a bell for some reason; can't think why as I haven't even messed with any x86 macs that much |
| 21:22 | <tiglionabbit> | can I get involved with this somehow? |
| 21:23 | <SamB> | sorry, was talking about the mac java thing ... |
| 21:26 | <Domenic_> | pointer events? |
| 21:30 | <annevk> | tiglionabbit: you could start with hit testing |
| 21:30 | <tiglionabbit> | what’s that? |
| 21:30 | <annevk> | tiglionabbit: http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html |
| 21:30 | <annevk> | tiglionabbit: it's kind of critical for any kind of cursor input, except we've no idea how it works on the web |
| 21:31 | <tiglionabbit> | eh? |
| 21:32 | <tiglionabbit> | I’ve never noticed a problem with this |
| 21:32 | <tiglionabbit> | I’d be much more interested in getting tablet pen events |
| 21:32 | <tiglionabbit> | or, extending the existing events with the tablet pen properties of pressure and sub-pixel position |
| 21:34 | <Domenic_> | i think pointer events have this |
| 21:34 | <tiglionabbit> | really? |
| 21:35 | <Domenic_> | pretty sure, but you should check the spec |
| 21:35 | <SamB> | annevk: really? no idea? |
| 21:36 | <tiglionabbit> | oh I see |
| 21:36 | <tiglionabbit> | unfortunately only supported by IE11 apparently |
| 21:36 | <tiglionabbit> | well at least there’s hope |
| 21:38 | <Domenic_> | my good deed for the day https://github.com/webcomponents/webcomponents.github.io/issues/96 |
| 21:41 | <annevk> | SamB: see the email, I'm making it worse than it sounds, but there's no standard, which is pretty bad |
| 21:41 | <annevk> | SamB: CSS box tree not being defined in detail contributes to this of course |
| 21:41 | <annevk> | SamB: maybe you want to start there if you are doing it from first principles... |
| 21:42 | <Domenic_> | I hear TabAtkins is on it ^_^ |
| 21:55 | <smaug____> | tiglionabbit: pointer events are being implemented in other engines |
| 21:55 | <smaug____> | well, I think not webkit, but elsewhere |
| 22:00 | <zewt> | SamB: all OS's support async directory creation; you just do it in a thread |
| 22:00 | <SamB> | zewt: oh. right. |
| 22:00 | <zewt> | (i think windows does support doing every FS operation async with the "overlapped" API) |
| 22:00 | <annevk> | cwilso_____: see also http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg543 and such |
| 22:01 | <SamB> | zewt: yes I did get that impression when I looked at their APIs last |
| 22:01 | <zewt> | (it may just create a thread behind the scenes) |
| 22:01 | <SamB> | or heck it could just not do it asynchronously |
| 22:02 | <zewt> | doubt that |
| 22:02 | <zewt> | it'd become really obvious as soon as you do something on a dirty CD |
| 22:02 | <zewt> | the overlapped API is nasty enough that i'd just do it myself with a thread, though |
| 22:08 | <cwilso> | annevk: yep, I'd say abarth and I do not completely agree there. |
| 22:09 | <cwilso> | I do agree it should be clear where any spec text came from |
| 22:09 | <cwilso> | (and whose work it is) |
| 22:09 | <annevk> | yeah, everyone says that |
| 22:09 | <cwilso> | canonicality is a tough one. |
| 22:09 | <annevk> | lots of nice talk |
| 22:09 | <annevk> | little walk |
| 22:09 | <annevk> | or some such |
| 22:10 | <cwilso> | because.... coming back to what I said like 9 years ago when Hixie et al asked me to join the whatwg effort... there's no IP fence of any kind around the WHATWG spec. |
| 22:10 | <cwilso> | because no one adds that text, you mean? |
| 22:10 | <cwilso> | If so, that's messed up. |
| 22:11 | <cwilso> | (And I do agree with abarth quite strongly that " the document should clearly state that it is based in part (or in whole) on the WHATWG version. " |
| 22:11 | <annevk> | "the WHATWG spec"? |
| 22:12 | <cwilso> | s/WHATWG spec/WHATWG work. |
| 22:12 | <SamB> | annevk: you want it under a license that requires attribution, instead of a PD declaration? |
| 22:12 | <SamB> | or, er, cwilso |
| 22:12 | <annevk> | because the W3C likes to pretend the WHATWG doesn't really exist |
| 22:12 | <cwilso> | that is, the work mode of the W3C engenders some kind of shared IP promise. |
| 22:12 | SamB | sometimes confuses people whose nicks have the same length and capitalization pattern, especially if they get colored similarly in his client ... |
| 22:13 | <annevk> | oh |
| 22:13 | annevk | was confused |
| 22:13 | cwilso | thinks that's the first time annevk and he have been confused, and think he's probably more offended than me. |
| 22:17 | <SamB> | hmm, now what's a license that requires attribution but isn't too long? expat license looks a bit long to include on spec pages ... |
| 22:19 | <cwilso> | samb: was the question to me "do you want it under a license that requires attribution, instead of a PD declaration?" if so, what's "it"? |
| 22:19 | <SamB> | the WHATWG stuff |
| 22:21 | <SamB> | hmm, GNU has a nice short one in (info "(maintain)License Notices for Other Files") |
| 22:23 | <SamB> | Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty. |
| 22:23 | <SamB> | except maybe that's actually a copyleft by accident? |
| 22:24 | <annevk> | SamB: cwilso is not concerned with the license |
| 22:24 | <cwilso> | I don't need anything to change. :P |
| 22:26 | SamB | was just thinking some kind of license requirement would be a reasonable way of ensuring that the W3C don't "forget" to attribute something ... |
| 22:26 | <crocket> | !schools |
| 22:26 | <annevk> | SamB: requiring something from the W3C would also require something from others, the latter would be bad |
| 22:31 | <annevk> | Domenic_: I think the main problem with UI events, btw, is the interaction between them |
| 22:32 | <annevk> | Domenic_: e.g. in one task you hit test, dispatch mouseX, check for cancelled, then what? what about focus? what about :hover at this point? etc. |
| 22:32 | <SamB> | annevk: well, okay, probably that's not the right form of attribution; maybe something that could be satisfied by simply saying "From WHATWG html:" |
| 22:33 | <annevk> | Domenic_: and now it's not just mouse and focus, but also pointer, and "indie UI", and if you're unlucky, touch |
| 22:34 | <annevk> | SamB: I don't think the W3C should copy in the first place |
| 22:34 | <annevk> | SamB: if they want to make lawyer snapshots so they get IP protection fine, but they're not doing that |
| 22:35 | <SamB> | what exactly ARE they doing besides cutting features they think are unstable or something like that? |
| 22:37 | <annevk> | SamB: they're causing confusion and wasting resources |
| 22:38 | <annevk> | SamB: HTML and 2D <canvas> are probably worst |
| 22:38 | <SamB> | oh, they're copying others? |
| 22:39 | <annevk> | Yes, most of http://www.whatwg.org/specs/ is copied in one way or another |
| 22:46 | <danbeam> | info Domenic_ |
| 22:46 | <danbeam> | whoops, sorry |
| 22:46 | <danbeam> | Domenic_: I would like more info from you, though :P, if you can respond to http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/254147.html |
| 22:47 | <danbeam> | full disclosure, I'm implementing this in blink -- https://chromiumcodereview.appspot.com/228783007/ |
| 22:53 | <cwilso> | annevk: "make the lawyer snapshots so they get IP protection" is a horribly, dangerously naive view of IP. |
| 22:54 | <cwilso> | if the W3C group truly only C&P'ed WHATWG specs, no one would be in the WGs. And there would be no IP commitments. |
| 22:54 | <paul_irish> | Domenic_: crazy results on that poll, yeah. |
| 22:55 | <annevk> | cwilso: the dog & pony show they put up now is a horrible waste of resources |
| 22:55 | <paul_irish> | I wish it wasn't so damn uneven. I'm sure that with less experienced developers it'd flop the more to seconds, though. :/ |
| 22:55 | <danbeam> | paul_irish: is it actually s instead of ms? (assuming you're talking about that animation poll) |
| 22:55 | <paul_irish> | danbeam: yes elem.animate() from web animations API defines duration in seconds, yah |
| 22:55 | <annevk> | Domenic_: paul_irish: note that media elements use seconds (iirc) |
| 22:56 | <annevk> | Domenic_: paul_irish: I think based on feedback from Apple |
| 22:56 | <danbeam> | paul_irish: considering there's probably not an animation in all of chrome (native or web) that's over 1s, I do find that kind of odd |
| 22:56 | <cwilso> | yeah, media apis and web audio. |
| 22:57 | <paul_irish> | yeah I'd imagine 80% of all css animations are <1s. |
| 22:57 | <cwilso> | annevk: not really a dog and pony show, more of a "maimed and angry cat parade" |
| 22:57 | <sgalineau> | paul_irish: I'd say that's because most animations in CSS are transitions which are inherently short |
| 22:58 | <danbeam> | paul_irish: that, in itself, should probably enough to make the default unit milliseconds instead of seconds, audio/media should be much longer so seconds makes more sense there |
| 22:58 | <paul_irish> | aye. so likely avg duration in keyframe animations is longer. seems legit. |
| 22:58 | <danbeam> | but obviously it's not the end of the world if I have to do .2 instead of 200 |
| 22:59 | <sgalineau> | paul_irish: but the use-case for @keyframes was more about longer-run effects, I think. in practice it's been rare thus far because transition effects was really the one everybody wanted |
| 23:00 | <sgalineau> | paul_irish: then there's also the spinner/throbber type @keyframes that may last 1s *per cycle* but are meant to go for as long as it takes.... |
| 23:01 | <cwilso> | danbeam: sgalineau: actually in Web Audio many durations are short (most are "transitions" (i.e. scheduled ramps)). But WA units are definitively floating point, and use of ms was heavily ingrained due to "usable precision in an integer unit". |
| 23:02 | <sgalineau> | cwilso: yeah, something like audio strikes me as implying units more precise than seconds |
| 23:02 | <sgalineau> | cwilso: or at a minimum support for fractional values |
| 23:02 | <zewt> | audio time should just be 64-bit seconds |
| 23:03 | <cwilso> | zewt: hope you mean 64-bit FLOAT seconds |
| 23:03 | <zewt> | it's particularly silly to use ms if you still have to use floats, and integer milliseconds aren't precise enough for some audio use cases |
| 23:03 | <zewt> | cwilso: yep |
| 23:03 | <sgalineau> | I suppose 64-bit milliseconds might be OK.... |
| 23:03 | <cwilso> | zewt: that's precisely why they ended up that way across the WA API. |
| 23:04 | <cwilso> | sgalineau: WHY use milliseconds, though? |
| 23:04 | <sgalineau> | what kind of use-cases need sub-millisecond in audio? |
| 23:04 | <cwilso> | sgalineau: getting samples to precisely align on a beat. |
| 23:04 | <zewt> | rhythm games |
| 23:04 | <cwilso> | getting buffers to play contiguously. |
| 23:04 | <sgalineau> | ok, cool. |
| 23:05 | <sgalineau> | you could use CSS seconds; they're about 0.96 normal seconds when you hold them at arm's length |
| 23:05 | sgalineau | cannot tire of CSS unit jokes |
| 23:06 | <MikeSmith> | tmux attach-session -d -t ssb |
| 23:34 | <SteveF> | annevk: the w3c html spec is pretty clear in regards to attribution http://www.w3.org/html/wg/drafts/html/master/ if anybody thinks otherwise all they have to do is speak up |