| 07:19 | <zcorpan> | karlcow: certainly you can run the url tests in non-browser url impls. just need to write a runner yourself |
| 07:39 | <annevk> | JakeA: use MDN |
| 08:16 | <karlcow> | zcorpan: I guess so. I was confused by the "Visit urltest and leave a comment with the user agent and hex code that that the web page reports." |
| 08:16 | <karlcow> | http://intertwingly.net/stories/2014/10/05/urltest |
| 08:20 | <karlcow> | I'm also trying to understand what is supposed to be the format but I see that you have to create your own doc by reading urltestparser.js |
| 08:20 | <karlcow> | https://github.com/w3c/web-platform-tests/tree/master/url |
| 08:22 | <karlcow> | hmm I don't want to fork web-platform-tests. I guess I can copy locally files in a specific directory |
| 08:25 | <zcorpan> | anyone have ie11? |
| 08:25 | <karlcow> | oh understood |
| 08:26 | <karlcow> | the 1st item in the list is the URI, the rest of the line is the decomposition |
| 08:26 | <karlcow> | pfew |
| 08:26 | <zcorpan> | second item is the base iirc |
| 08:26 | <karlcow> | what is https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt#L21 |
| 08:26 | <zcorpan> | karlcow: feel free to submit a PR with documentation for the format :-) |
| 08:27 | <karlcow> | when there is href='' |
| 08:27 | <zcorpan> | karlcow: empty string input, empty string base |
| 08:27 | <karlcow> | ah so example.org is the token local whatever host the page is from? |
| 08:28 | <karlcow> | Starting to make sense. :) |
| 08:28 | <zcorpan> | no it uses the base from an earlier test that sets base |
| 08:29 | <karlcow> | houla… |
| 08:29 | <karlcow> | why's that? |
| 08:29 | <zcorpan> | i think |
| 08:29 | <zcorpan> | to avoid repeating it i guess? |
| 08:30 | <karlcow> | hmm |
| 08:30 | <karlcow> | https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt#L20-L21 |
| 08:30 | <karlcow> | line 20 host = f |
| 08:30 | <karlcow> | line 21 host = example.org though it is not in the address |
| 08:31 | <zcorpan> | https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt#L4 |
| 08:33 | <karlcow> | hmm I meant in 19. 20 doesn't seem to be defined at all. |
| 08:34 | <karlcow> | zcorpan: yes the test line 4. I don't understand either. :) |
| 08:35 | <zcorpan> | karlcow: it sets the base url that is used for all the tests below until another test sets a different base url |
| 08:35 | <zcorpan> | karlcow: that's where example.org comes from |
| 08:40 | <karlcow> | if host=='': |
| 08:40 | <karlcow> | host=(something_defined_earlier_up_the_stack) |
| 08:40 | <karlcow> | else: |
| 08:40 | <karlcow> | host=(the_one_extracted_for_this_test) |
| 08:40 | <karlcow> | is it what you are saying? |
| 08:49 | <annevk> | iirc it's something like that, yes |
| 08:49 | <karlcow> | annevk: thanks. |
| 08:49 | <karlcow> | I'm not sure I get everything yet |
| 08:50 | <karlcow> | but it seems the parsing rules of each line depends on a previous state. Not really simple. :/ |
| 08:50 | <annevk> | I guess when I have a chance to work on URLs again I can add some documentation and fix some of the tests |
| 08:50 | karlcow | would have preferred redundancy |
| 08:50 | <annevk> | It's optimized for writing tests by hand |
| 08:52 | <karlcow> | annevk: can you give the key for the 1st line? https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt#L4 |
| 08:52 | <karlcow> | more exactly why "http://example\t.\norg http://example.org/foo/bar"; |
| 08:54 | <annevk> | karlcow: what is unclear? |
| 08:55 | <karlcow> | so let me try. The first string is the one to be tested: "http://example\t.\norg"; |
| 08:55 | <karlcow> | Then the second string is for ? |
| 08:55 | <karlcow> | After this is what we must find "s:http h:example.org p:/" for the result. aka http://example.org/ |
| 08:56 | <annevk> | second string is the base URL |
| 08:56 | <annevk> | iirc |
| 08:56 | <annevk> | karlcow: https://github.com/w3c/web-platform-tests/blob/master/url/urltestparser.js#L51 is the parser |
| 08:58 | <karlcow> | ah base href="http://example.org/foo/bar"; with <a href="http://example\t.\norg">blah</a>; |
| 09:00 | <karlcow> | oooooh number of spaces in between the string is meaningful. argh |
| 09:02 | <annevk> | Ah I see, some tests MikeSmith added in https://github.com/w3c/web-platform-tests/commit/2712b5611a4e048e04a7dc814a7a31413d2d367a are not conforming to the spec |
| 09:05 | <karlcow> | burn MikeSmith |
| 09:05 | <karlcow> | ;) |
| 09:08 | <zcorpan> | Hixie: caniuse boxes was popular if twitter is any indication |
| 09:10 | <karlcow> | hmm this will be PITA to parse in python |
| 09:10 | <zcorpan> | karlcow: can't you just split on " " like the JS impl? |
| 09:11 | <karlcow> | zcorpan: it will concatenate the spaces |
| 09:11 | <karlcow> | >>> 'http://example\t.\norg http://example.org/foo/bar s:http h:example.org p:/'.split(' ') |
| 09:11 | <karlcow> | ['http://example\t.\norg';, 'http://example.org/foo/bar';, 's:http', 'h:example.org', 'p:/'] |
| 09:11 | <karlcow> | >>> '\sfoo.com\s\s s:http h:example.org p:/foo/foo.com'.split(' ') |
| 09:11 | <karlcow> | ['\\sfoo.com\\s\\s', 's:http', 'h:example.org', 'p:/foo/foo.com'] |
| 09:11 | <karlcow> | ah no my bad |
| 09:12 | <karlcow> | working |
| 09:12 | <karlcow> | hmm I should stop working for today |
| 09:12 | <karlcow> | >>> '\sfoo.com\s\s s:http h:example.org p:/foo/foo.com'.split(' ') |
| 09:12 | <karlcow> | ['\\sfoo.com\\s\\s', '', 's:http', 'h:example.org', 'p:/foo/foo.com'] |
| 09:13 | <karlcow> | ok |
| 09:13 | <karlcow> | all good |
| 09:13 | <karlcow> | thanks annevk and zcorpan |
| 09:14 | <zcorpan> | Hixie: should we move the browser icons to resources.whatwg.org? they're not used by wpt anymore |
| 09:14 | <zcorpan> | er, s/wpt/wat/ i guess. or hst |
| 09:16 | <zcorpan> | should we use svg browser icon when one exists? |
| 09:17 | <annevk> | if they look better |
| 09:18 | <annevk> | web-apps-tracker looks a bit duller now without the colorful icons |
| 09:51 | <MikeSmith> | annevk: about the URL tests I think those are all canonicalization tests. anyway, if you make a PR for the ones to remove, I can do the review duties |
| 10:03 | <zcorpan> | hmm, android browser doesn't seem to be in https://github.com/alrra/browser-logos |
| 10:11 | <zcorpan> | https://github.com/alrra/browser-logos/issues/45 |
| 10:45 | <zcorpan> | annevk: we could make the new icons more colorful i suppose |
| 10:46 | <annevk> | zcorpan: also maybe indicate in title="" somehow what they are about |
| 10:46 | <annevk> | zcorpan: currently all you get is "Stable" and no information on the icons |
| 10:48 | <zcorpan> | yeah that could be better. "Affects validators, browsers, tools. Stable content." |
| 10:51 | <MikeSmith> | yeah please |
| 11:49 | <rubys> | karlcow: you might want to follow the json link from the first paragraph in: http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI |
| 11:51 | <karlcow> | Ah good. Normalized. |
| 11:52 | <karlcow> | rubys: Thanks sam |
| 11:53 | <annevk> | JakeA: beverloo: https://notifications.spec.whatwg.org/#service-worker-api (note that I haven't defined how these work just yet) |
| 11:58 | <JakeA> | annevk: ta, will review. I have *one whole day* in the office before I'm off to the next thing :( |
| 11:58 | <JakeA> | (but it's Fronteers so yey!) |
| 11:59 | <annevk> | JakeA: cool, make sure to attend jam session |
| 12:00 | <JakeA> | yeah, my usual tactic there is to stay downstairs and drink la chouffe, but I'm going to be super-sober this time |
| 12:01 | <annevk> | JakeA: will hopefully get the text around the API in shape today; hopefully this API matches what we've discussed |
| 12:12 | <zcorpan> | annevk: does http://intertwingly.net/stories/2014/10/05/urltest-results/a193745897 need to resolve? |
| 12:14 | <annevk> | zcorpan: SimonSapin filed a bug on it at some point, I don't remember finding the argument for arbitrary limits compelling |
| 12:15 | <annevk> | zcorpan: why would the IETF version not have a port there btw? |
| 12:15 | <annevk> | rubys: ^ |
| 12:15 | <zcorpan> | annevk: if it gets clamped or truncated somewhere, isn't that a security problem? |
| 12:16 | <SimonSapin> | TCP and UDP only support port numbers in 0..65535 |
| 12:17 | <jgraham> | FWIW if OSes store port numbers as 16 bit integers (I don't know if they do) that seems like a compelling reason to not support ports outside that range |
| 12:17 | <SimonSapin> | jgraham: "store"? |
| 12:18 | <annevk> | zcorpan: we don't limit domain length in parsing either |
| 12:18 | <jgraham> | SimonSapin: In the sense that the OS has data structures that model port numbers as 16 bit unsigned integers |
| 12:18 | <annevk> | zcorpan: it's not clear to me why port constraints would be different from domain constraints |
| 12:19 | <zcorpan> | annevk: i don't know if domain length has issues. maybe it does? |
| 12:20 | <jgraham> | annevk: Storing a number is conceptually rather different from storing a string |
| 12:20 | <annevk> | jgraham: port is a string |
| 12:20 | <jgraham> | annevk: In actual sockets implementations? |
| 12:21 | <SimonSapin> | annevk: port is serialized as a string in href.port in JS |
| 12:21 | <SimonSapin> | opening a socket in unix takes a 16-bit int |
| 12:21 | <annevk> | SimonSapin: for URLs it's a string https://url.spec.whatwg.org/#concept-url-port |
| 12:21 | <SimonSapin> | annevk: yes, that’s what the spec says right now, and I’m suggesting that maybe should change |
| 12:22 | <annevk> | zcorpan: it would change the way URLs parse |
| 12:22 | <annevk> | zcorpan: and while there's rules on what can work over TCP/UDP, there's no rules that say http://f:9999999999/ is an invalid URL |
| 12:23 | <annevk> | zcorpan: or that http://f[repeat 300 times]/ is one |
| 12:23 | <SimonSapin> | annevk: we’re discussing making up the rule |
| 12:23 | <jgraham> | annevk: Having a gratuitous mismatch between what can actually work and what's allowed seems bad |
| 12:23 | <annevk> | jgraham: if you use a URL as identifier it works fine |
| 12:24 | <jgraham> | If you are using a URL as an identifier you are already doing it wrong |
| 12:24 | <annevk> | I don't disagree, but breaking such usage seems bad |
| 12:25 | <jgraham> | Do you have any evidence that this would break anyone? |
| 12:25 | <annevk> | Shouldn't the evidence be the other way around? |
| 12:26 | <SimonSapin> | annevk: safari and chrome already don’t support above 65535, though they do something different with it |
| 12:26 | <annevk> | Note that this bug is still open apparently, I haven't actually made a decision: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26446 |
| 12:26 | <annevk> | It does seem however unfortunate to further deviate from the IETF (I think rubys made a mistake somewhere as I'm pretty sure the IETF RFCs allow that case) |
| 12:27 | <annevk> | That bug does suggest that all browsers have a limit, just that the one in Firefox is a bit higher. |
| 12:28 | <SimonSapin> | Firefox also keeps an integer internally, just a 32-bit one |
| 12:28 | <rubys> | Note that instead of doing the hard work of reading the IETF specs, I'm using an implementation that claims to be compliant as a proxy. |
| 12:28 | <jgraham> | Right, this "port is a string" isn't actually an implementation strategy that anyone seems interested in |
| 12:29 | <jgraham> | Which to me weighs higher than then unproven risk of breaking someone using URLs as identifiers |
| 12:29 | <jgraham> | +unresolvable |
| 12:31 | <annevk> | rubys: surely it must be compliant with all the tests the IETF has released, I guess I should reread the spec then |
| 13:29 | <zcorpan> | Hixie: see https://resources.whatwg.org/browser-logos/ - use opera-mobile.png for opera mini and firefox.png for firefox mobile |
| 13:43 | <annevk> | Domenic: I might be willing to adopt the [[slot]] and obj@[[slot]] notation at some point throughout the stuff I edit |
| 13:43 | <annevk> | Domenic: although it might be a hassle for those that reference the existing concepts |
| 13:43 | <annevk> | Domenic: is there syntax for internal classes/objects as well? |
| 13:52 | <zcorpan> | Hixie: https://html.spec.whatwg.org/#attr-script-async has two boxes on top of each other |
| 13:57 | <zcorpan> | Hixie: it's not always clear what the box refers to. e.g. https://html.spec.whatwg.org/multipage/indices.html#event-hashchange maybe replace "Support:" with the caniuse title? |
| 14:05 | <annevk> | Does anyone have an idea what it would take to enable caniuse.com boxes on other specifications? |
| 14:05 | <darobin> | annevk: you mean like embed a little caniuse thing next to a section? |
| 14:06 | <annevk> | darobin: as HTML has |
| 14:06 | <darobin> | oh that |
| 14:18 | <zcorpan> | annevk: maybe port hixie's thing to bikeshed? |
| 14:20 | <annevk> | would also need to port the specs to Bikeshed |
| 14:20 | <annevk> | but yeah, I guess that's the long term game |
| 14:29 | <Domenic> | annevk: what's an internal class/object? |
| 14:29 | <annevk> | Domenic: concept-request would be one |
| 14:29 | <annevk> | Domenic: or concept-url |
| 14:30 | <Domenic> | annevk: I think ES usually represents those as Records |
| 14:30 | <annevk> | Domenic: what if they have method-like-things attached? |
| 14:30 | <Domenic> | annevk: you define abstract ops that take the record as its first param |
| 14:30 | <annevk> | Domenic: I guess then it has global abstract operations... ew |
| 14:31 | <annevk> | Domenic: is that better? |
| 14:31 | <Domenic> | annevk: unclear. Feels more like a program, less like prose. But I guess it's less important than internal slots since internal slots could be used for e.g. structured clone |
| 14:32 | <Domenic> | I guess if one of the internal slots contained a Record it'd be easier to programmatically clone it than if it contained a concept. |
| 14:34 | <annevk> | well, you could have internal slots and internal methods to work around that |
| 14:34 | <annevk> | Domenic: and "feels like a program" seems rich coming from TC39 :p |
| 14:35 | <annevk> | but I could go either way |
| 14:36 | <Domenic> | Hmm it's true there actually are internal methods already. But they mean something kind of different... |
| 14:37 | <Domenic> | interesting, it doesn't look like the spec calls out internal methods as special. but in practice it only uses them for things that are applicable across all objects, e.g. [[Call]] or [[GetPrototypeOf]] |
| 14:38 | <Domenic> | whereas it uses internal slots for very case-specific things |
| 14:39 | <Domenic> | "Spec-ES" is probably the more interesting route |
| 14:39 | <annevk> | "Spec-ES"? |
| 14:41 | <Domenic> | http://esdiscuss.org/topic/for-of-loops-iteratorclose-and-the-rest-of-the-iterations-in-the-spec#content-25 |
| 14:41 | <JakeA> | annevk: so, does self.Notification not exist within a ServiceWorker? |
| 14:41 | <annevk> | JakeA: it does |
| 14:41 | <Domenic> | letting you use some kind of ES dialect instead of this weird pseudocode-slash-prose that the ES spec uses |
| 14:41 | <Domenic> | but just ES doesn't suffice because you need mechanisms to avoid using user-modifiable things |
| 14:45 | <annevk> | that and better IDL seems about right |
| 14:45 | <JakeA> | annevk: so, if you create a notification within a ServiceWorker, it's automatically 'persistent' and events go through that SW? |
| 14:46 | <JakeA> | annevk: but if you want to do that from a page, you use reg.showNotification? |
| 14:46 | <annevk> | JakeA: no, you need to use showNotification() for that |
| 14:46 | <annevk> | JakeA: new Notification is for non-persistent notifications |
| 14:47 | <JakeA> | annevk: hmm, so "new Notification" is pretty much just a gotcha within SW? |
| 14:48 | <annevk> | JakeA: it would be the same as in other workers |
| 14:48 | <annevk> | JakeA: I think it makes sense to have the non-persistent notification API as well |
| 14:49 | <annevk> | JakeA: and we need to expose Notification objects somehow since they are returned from events in service workers |
| 14:50 | <JakeA> | annevk: right, but "new Notification" is going to cause problems in SW since it terminates while inactive |
| 14:50 | <annevk> | JakeA: problems how? |
| 14:51 | <Domenic> | Can you have a makePersistent(notificationInstance) that explains how some `Notification`s are persistent? |
| 14:51 | <JakeA> | annevk: you create a notification, add events, SW terminates, events never fire |
| 14:52 | <JakeA> | annevk: previous designs had "new Notification" within a serviceworker be persistent, which sounds like a sensible default |
| 14:56 | <annevk> | JakeA: we decided to use a promise instead |
| 14:57 | <annevk> | JakeA: does a ServiceWorkerRegistration always have an active worker? |
| 14:58 | <JakeA> | annevk: no, .register resolves when the worker starts installing. It'll have an active worker when navigator.serviceWorker.ready resolves |
| 15:01 | <annevk> | JakeA: when should showNotification start working? |
| 15:01 | <annevk> | JakeA: that is, when does push stuff start working? |
| 15:01 | <JakeA> | annevk: push doesn't work until there's an active worker |
| 15:01 | <annevk> | okay, I'll just follow that |
| 15:02 | <JakeA> | (pretty much why we have .ready) |
| 15:04 | <annevk> | JakeA: should notifications be associated with the registration or the service worker returned from active worker? I guess with the registration, right? |
| 15:07 | <JakeA> | annevk: Yeah, the registration |
| 15:07 | <JakeA> | That's how push etc work |
| 15:07 | <JakeA> | so if the active SW changes, the new one gets the event |
| 15:10 | <JakeA> | annevk: I'm struggling to find the justification for getUserMedia to stick with callbacks |
| 15:10 | <annevk> | JakeA: thanks for the help |
| 15:10 | <annevk> | JakeA: I don't either |
| 15:11 | <annevk> | JakeA: I think at this point it's basically ekr trying to maintain his position from a year ago, that not everyone is convinced promises ought to be used everywhere |
| 15:11 | <annevk> | JakeA: which given that he's not really a JavaScript person, is a real shame |
| 15:11 | <JakeA> | ugh |
| 15:12 | <annevk> | JakeA: btw, Google's main guy didn't help much |
| 15:12 | <annevk> | JakeA: not sure if you saw the ridiculous presentation he gave |
| 15:13 | <JakeA> | annevk: Was that the contentless PDF thing? |
| 15:13 | <annevk> | JakeA: http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/att-0003/Thoughts_on_Promises__Public_.pdf |
| 15:13 | <JakeA> | yeah fuck that |
| 15:14 | <annevk> | Last year their argument was that WebRTC would be ready way before promises. And now promises has been in stable for a long time the new argument seems to be "uh we don't want to change our mind" |
| 15:14 | <JakeA> | annevk: have any other APIs shipped with success/failure callbacks since promises went stable? |
| 15:14 | <annevk> | nope |
| 15:15 | <annevk> | I told them |
| 15:15 | <annevk> | Their priority of constituencies is clearly wrong |
| 15:19 | <JakeA> | annevk: it's not even a big spec change. In fact, it's more effort. Just delete navigator.getUserMedia if it's just an alias |
| 15:20 | <JakeA> | Domenic: Is the TAG still charged with beating people with sticks if they pull this shit? |
| 15:20 | <annevk> | I didn't get that either |
| 15:21 | <annevk> | JakeA: do you know how to do this: https://github.com/slightlyoff/ServiceWorker/issues/504 ? |
| 15:22 | <slightlyoff> | I'm not sure it's exposed in the SW. We have unregister available there, though |
| 15:23 | <JakeA> | I think there's a ticket for this, searching… |
| 15:23 | <slightlyoff> | And its a good question as to why not. |
| 15:23 | <slightlyoff> | Which I will think about. |
| 15:23 | <JakeA> | https://github.com/slightlyoff/ServiceWorker/issues/421 |
| 15:23 | <annevk> | Even if it's not exposed, I need access to it from spec language |
| 15:24 | <annevk> | E.g. otherwise how do I get all the Notification objects for Notification.get() that match the current service worker's service worker registration |
| 15:25 | <annevk> | The model does not seem to spell out that there's a relationship there and how you can get from one to the other |
| 15:25 | <JakeA> | there should be an API |
| 15:29 | <annevk> | APIs are easy if your model is in order... |
| 15:30 | <annevk> | At least if there was a model I wouldn't be blocked on writing text for the Notifications API |
| 15:33 | <slightlyoff> | The model is coherent |
| 15:33 | <slightlyoff> | But lack of API is bad |
| 15:34 | <slightlyoff> | JakeA: will need to replicate browser-side API in full to expose states |
| 15:35 | <annevk> | The model is not coherent... |
| 15:35 | <JakeA> | slightlyoff: we can reuse the full registration object I think, then expose self.registration |
| 15:35 | <annevk> | It doesn't even say that a service worker has an associated service worker registration |
| 15:35 | <slightlyoff> | Yep |
| 15:35 | <annevk> | Or that a service worker can be obtained from a global object |
| 15:35 | <annevk> | There's a lot of stuff missing in the model |
| 15:36 | <slightlyoff> | annevk: you can't get run in the SW global context WO a registration ;-) |
| 15:36 | <slightlyoff> | So the model *is* coherent. But agree spec text needs improvement |
| 15:36 | <annevk> | slightlyoff: oh, so magic is acceptable here? |
| 15:36 | <slightlyoff> | Did I say that? |
| 15:37 | <slightlyoff> | Why so trolly? |
| 15:37 | <JakeA> | I think we're getting tired up in terminology here |
| 15:37 | <annevk> | Because I have a problem with the spec and you keep saying it's fine, while you mean that the idea is fine |
| 15:37 | <JakeA> | In the spec the ServiceWorker instance needs to have an explicit link back to the registration |
| 15:38 | <annevk> | And the SW spec has been a source of frustration for a long time now |
| 15:38 | <slightlyoff> | I didn't say its fine. I said it needs to be improved, but that the conceptual framework isn't broken (as you had alluded to) |
| 15:39 | <annevk> | No, I alluded to the model described in the spec being broken |
| 15:39 | <annevk> | Because it is, as I can't use it to define other features elsewhere, or use it to explain to developers how things need to be implemented in Gecko |
| 15:40 | <slightlyoff> | Lets improve the spec text then! Thanks for pointing out the lack of API. |
| 15:41 | <annevk> | Please do it, I filed doezens of issues :-) |
| 15:41 | <annevk> | dozens, even |
| 15:51 | <JakeA> | Can't help feeling my posts are being ignored on public-media-capture |
| 15:52 | <annevk> | JakeA: filed https://github.com/slightlyoff/ServiceWorker/issues/505 on better hooks for other specs (currently none) |
| 15:55 | <Domenic> | JakeA: yes. Stick-beating incoming. |
| 16:00 | <JakeA> | annevk: dupe of https://github.com/slightlyoff/ServiceWorker/issues/349? |
| 16:02 | <annevk> | JakeA: yeah I guess, although I think I don't understand why activeWorker needs to be done as an async check |
| 16:02 | <annevk> | JakeA: or why InvalidStateError instead of TypeError |
| 16:11 | <JakeA> | annevk: happy to unasync. I picked InvalidStateError because the registration is in an invalid state for the API call. Maybe I'm getting the usage of that error wrong? |
| 16:13 | <annevk> | JakeA: I have a slight preference to use built-in exceptions over DOMException |
| 16:13 | <JakeA> | why? |
| 16:13 | <annevk> | JakeA: DOMException's design doesn't match that of built-in exceptions |
| 16:13 | <annevk> | JakeA: and otherwise it seems to not matter much |
| 16:13 | <JakeA> | fair enough |
| 16:14 | <JakeA> | I'm not particularly bothered |
| 16:17 | <JakeA> | http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0047.html "I'm not particularly interested in deprecating it" - was there a reason given? |
| 16:18 | <annevk> | No |
| 16:18 | <JakeA> | He's just using this as an anti-promise thing isn't he? |
| 16:19 | <annevk> | He just put it forward as ultimatum during the teleconference that promises could be added if we promised not to bring up deprecating for three years or so |
| 16:19 | <annevk> | I don't think he even cares as he's clearly not invested in JavaScript much. He's an IETF professional standards person afaict |
| 16:20 | <JakeA> | No point having navigator.getUserMedia if it's just a non-promise version of navigator.mediaDevices.getUserMedia |
| 16:20 | <JakeA> | The prefixed versions can remain for that |
| 16:21 | <JakeA> | The only reason to keep navigator.getUserMedia is if you're on some kind of anti-promise mission |
| 16:23 | <annevk> | I must admit I don't understand why they went from a nice short API to something that long |
| 16:24 | <JakeA> | gives them somewhere to put other methods I guess |
| 16:24 | <annevk> | At least migrate to MediaDevice.get() or some such |
| 16:24 | <JakeA> | although I'd rename getUserMedia to request, or open |
| 16:24 | <JakeA> | haha |
| 16:24 | <JakeA> | yeah |
| 16:25 | <annevk> | Seems like it could have used a ton more input from web developers |
| 16:27 | <Domenic> | SSLLabs is not very good at telling me what is losing points |
| 16:28 | <Domenic> | But, https://promisesaplus.com is now TLSified, yay CloudFlare |
| 16:35 | <Hixie> | hm, not sure what to do about async vs defer |
| 16:36 | <Hixie> | you can tell what the boxes are for by clicking the caniuse.com link, but in general I'd much rather the context be unambiguous than rely on caniuse's headings to disambiguate |
| 16:36 | <Hixie> | context meaning where the box is being all that's necessary |
| 16:38 | <Hixie> | btw do people like the right-aligned version numbers or would it be better to have them inline with the browser version? it's not really useful to have them compared to each other... |
| 16:39 | <Hixie> | also, in case anyone is curious, the sort order is by global usage share, and i limit it to the top 12 (but there's only 11 browsers in the data). |
| 16:39 | <Hixie> | (iirc) |
| 16:42 | <Domenic> | JakeA: annevk: http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0070.html |
| 16:43 | <annevk> | Domenic: ta |
| 16:43 | <jgraham> | Hixie: Sorting by global usage share seems unfortunate. I'd just sort into desktop / mobile and then alphabetically, if possible |
| 16:43 | <Hixie> | jgraham: that key isn't in the data |
| 16:44 | <Hixie> | (i originally sorted by usage because i was only showing 5) |
| 16:44 | <annevk> | Domenic: you can get more detailed results through https://www.ssllabs.com/ssltest/analyze.html?d=promisesaplus.com&s=104.28.31.16 |
| 16:44 | <jgraham> | Hixie: Alphabetically is |
| 16:44 | <Hixie> | jgraham: that seems a bit arbitrary |
| 16:45 | <jgraham> | Hixie: usage share is also arbitary and doesn't really promote good authoring practices |
| 16:45 | <Hixie> | sorting alphabetically also has the disadvantage of putting three google products at the top |
| 16:46 | <jgraham> | Well that's one reason that sorting by device type works better |
| 16:46 | <Hixie> | sorting by device type doesn't seem to promote good authoring practices either :-) |
| 16:46 | <Hixie> | (but in any case, i don't have that key) |
| 16:46 | <jgraham> | Well maintaining that key locally seems rather easy |
| 16:47 | <Hixie> | i would rather not make this any more brittle than it is. it's already really dependent on the caniuse.com format. |
| 16:48 | <jgraham> | Well that seems somewhat inevitable. On that note, it should also say "data from" rather than "see also" to be clear whose assessment of "support" is being used |
| 16:49 | <jgraham> | And browsers that don't support a thing should still be listed, but in some way that shows it isn't supported |
| 16:49 | <Hixie> | yeah, that's what i had at first. The problem is that on some of the boxes, there's no browsers that support it, and then having the "data from" line alone is very strange. |
| 16:49 | <jgraham> | Well happily both those changes together solve that problem |
| 16:50 | <Hixie> | well right now i'm showing browsers that have the "y". |
| 16:50 | <Hixie> | what do i do for other codes? |
| 16:50 | <Hixie> | there's like half-a-dozen other states |
| 16:50 | <Domenic> | Hixie: example link for us to look at? |
| 16:50 | <Hixie> | Domenic: link to what? |
| 16:50 | <jgraham> | Hixie: What are the other states? I think partial and none are rather easy to understand |
| 16:50 | <annevk> | Domenic: http://www.jamescrowley.co.uk/2014/02/02/achieving-forward-secrecy-and-strict-transport-security-in-iis/ |
| 16:51 | <jgraham> | and display |
| 16:51 | <Hixie> | jgraham: see "stats" in https://github.com/Fyrd/caniuse/blob/master/CONTRIBUTING.md |
| 16:51 | <annevk> | Domenic: https://html.spec.whatwg.org/multipage/embedded-content.html#the-video-element has an example of the caniuse box |
| 16:51 | <Hixie> | jgraham: (and note that a browser can have multiple codes, and each version can have different codes) |
| 16:52 | <jgraham> | Hixie: That sounds like it's even more important to present more than just "y" |
| 16:53 | <jgraham> | Hixie: Most of those seem to map onto "no" other than y or a |
| 16:53 | <Hixie> | jgraham: tell you what. make me a mock-up of how i should render them, and i'll see what i can do. |
| 16:54 | <jgraham> | Something like: |
| 16:54 | <jgraham> | Chrome 34+ |
| 16:55 | <jgraham> | Firefox (partial) 29+ <- this line in grey |
| 16:55 | <jgraham> | IE None <- this line also in grey |
| 16:57 | <Hixie> | jgraham: and what do i map to these three states? |
| 17:02 | <JakeA> | Domenic: good email, although I don't think they have good reason to ship with callbacks at all (even if promises are also returned) |
| 17:03 | <annevk> | Yeah, if navigator.getUserMedia() is dead, it seems like only promises could work |
| 17:06 | <Domenic> | annevk: doesn't requiring TLS 1.2 kill a lot of older browsers |
| 17:06 | <annevk> | Domenic: I don't know, I never got that far since I'm on DreamHost and haven't explored my own setup yet |
| 17:06 | <annevk> | getting my own setup* |
| 17:07 | <Domenic> | https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers |
| 17:07 | <gsnedders> | Domenic: Android < 4, and IE6 are the big casualties, IIRC |
| 17:07 | <Domenic> | looks like IE10 is a big casualty... |
| 17:08 | <gsnedders> | it's disabled by default? oh. :( |
| 17:09 | <annevk> | Wow why is that? |
| 17:09 | <gsnedders> | probably for the same reason Opera had it disabled by default for years; it breaks sites |
| 17:11 | <annevk> | Ah yeah, they hadn't actually made TLS forward compatible |
| 17:11 | <gsnedders> | IIRC it *is* forward compatible per spec. |
| 17:11 | <gsnedders> | Just many implementations aren't. |
| 17:11 | <annevk> | And then they forgot to deploy tests? |
| 17:11 | <gsnedders> | Because nobody ever tested the forward compatiblity stuff. |
| 17:12 | <annevk> | Not a bug surprise coming from the IETF |
| 17:12 | <gsnedders> | Dude, practically nobody was writing large testsuites in 2008. |
| 17:12 | <gsnedders> | It was hardly just the IETF then. |
| 17:12 | <annevk> | I think we had <canvas> back then and the HTML parser test suite |
| 17:12 | <gsnedders> | …which is pretty much an irrelevantly small part of the the HTML spec in 2008. |
| 17:15 | <Hixie> | and the CSS test suite |
| 17:15 | <Hixie> | (CSS was the first group to really do a test suite) |
| 17:16 | <gsnedders> | that wasn't that big in 2008, though |
| 17:16 | <gsnedders> | well, I guess the huge MS dump was around then |
| 17:17 | <annevk> | Hixie had a huge amount of tests |
| 17:17 | <annevk> | Still does |
| 17:18 | <annevk> | Ooh, Twin Peaks is making a return |
| 17:19 | <annevk> | I guess I better finish watching S2 |
| 17:19 | <Hixie> | how do i make an image monochrome in css? |
| 17:19 | <Hixie> | does that exist yet? |
| 17:20 | <jgraham> | Hixie: Everything that isn't a or y gets mapped to None, a gets mapped to partial |
| 17:20 | <Hixie> | well "unknown" presumably doesn't get mapped to none |
| 17:20 | <Hixie> | and notes are presumably ignored? |
| 17:21 | <Hixie> | what if it's "a y"? |
| 17:21 | <Hixie> | or "a d"? |
| 17:21 | <Hixie> | or "y u"? |
| 17:22 | <annevk> | Hixie: I think with CSS filters that should be possible, don't know about support |
| 17:22 | <annevk> | Hixie: filter: grayscale(100%) seems to be the desired syntax |
| 17:22 | <Hixie> | aha |
| 17:22 | <Hixie> | thanks |
| 17:22 | <Hixie> | (was just finding that on the olde blogosphere) |
| 17:23 | <jgraham> | Hixie: Just use the latest information |
| 17:23 | <annevk> | Hixie: you might get away with filter:grayscale (leaving out the parameter as it defaults to 100%) |
| 17:23 | <Hixie> | jgraham: latest as in for each browser, walk up until you get to one that doesn't include a "u"? |
| 17:23 | <Hixie> | jgraham: my questions above were for the value of a single version, not across versions |
| 17:24 | <Hixie> | (the state is documented as a space-separated list of codes, per version) |
| 17:24 | <jgraham> | Hixie: I'm not sure what the semantics of the data are supposed to be then |
| 17:25 | <Hixie> | it's all documented in that link i pasted earlier |
| 17:25 | <jgraham> | Hixie: if "y" in data.split(): "y" elif "a" in data.split: "partial" |
| 17:26 | <jgraham> | else: none |
| 17:26 | <Hixie> | ok that's what i did |
| 17:26 | <Hixie> | look now |
| 17:27 | <Hixie> | hm the (limited) thing didn't work |
| 17:27 | <Hixie> | oh i see why |
| 17:28 | <jgraham> | Hixie: (limited) could have more contrast |
| 17:29 | <Hixie> | than "none", or do you mean both should be darker? |
| 17:29 | <jgraham> | Than None |
| 17:30 | <Hixie> | try now |
| 17:32 | <jgraham> | Hixie: That looks better |
| 17:34 | <Hixie> | can you tell why the box in the cell at https://html.spec.whatwg.org/#event-hashchange is a different density than the boxes elsewhere? |
| 17:36 | <Hixie> | the height of each of the 'table' rows ends up smaller somehow |
| 17:36 | <Hixie> | oh i wonder if it's inherited border-collapse or some stupid thing like that |
| 17:37 | <Hixie> | yeah that must be it |
| 17:38 | <Hixie> | man this lack of a left margin is taking me longer to get used to than most of these style changes |
| 17:38 | <Hixie> | i guess i've been staring at it for over a decade and a half at this point |
| 17:41 | <Hixie> | man, resizing the html spec makes multiprocess firefox shudder. |
| 17:46 | <Hixie> | annevk: any chance you can make the two sections labeled "Parser" in teh url spec have different names? I keep ending up staring at the host parsing algorithm wondering why it's not about urls. |
| 17:54 | <Hixie> | can someone test IE on http://www.hixie.ch/tests/adhoc/html/navigation/fragids/ tests 019-022 ? (follow the links on that page and tell me if they're green or red) |
| 17:55 | <Hixie> | (the pages, that is) |
| 17:58 | <Hixie> | (that's for https://www.w3.org/Bugs/Public/show_bug.cgi?id=26988 ) |
| 17:59 | <boogyman> | Windows 8, IE10 test 19 fails |
| 18:00 | <Hixie> | uh |
| 18:00 | <Hixie> | does 001 pass? |
| 18:00 | <Hixie> | 19 was supposed to be the control! |
| 18:01 | <boogyman> | 001 is success |
| 18:01 | <Hixie> | huh |
| 18:01 | <Hixie> | do any of the others 020-022 pass? |
| 18:02 | <boogyman> | 021 is netiher |
| 18:05 | <Hixie> | neither? |
| 18:05 | <Hixie> | as in it doesn't scroll at all? |
| 18:05 | <Hixie> | wild |
| 18:07 | <boogyman> | When I say neither, I mean the position on the screen gives me a box at the top of client height with a box, with a blue border, but no background to the phrase contained within that box. |
| 18:08 | <Hixie> | o_O |
| 18:08 | <Hixie> | so it's scrolling to "te st" in 021, but not making it match :target |
| 18:09 | <Hixie> | but in 019 it's not even scrolling to "te st" |
| 18:09 | <Hixie> | what does it do in 020? |
| 18:09 | <Hixie> | and in 001 it's scrolling to "test" and making it match :target |
| 18:09 | <boogyman> | okay, maybe I should read next time. 19, 21, 22 all pass, 20 fails |
| 18:10 | <Hixie> | oh |
| 18:10 | <Hixie> | ok that makes more sense |
| 18:10 | <Hixie> | interesting |
| 18:10 | <Hixie> | so only chrome and webkit scroll to id="te%20st" |
| 18:23 | <hober> | gahh, lists.whatwg.org is still broken? |
| 18:36 | <Ms2ger> | Hixie, fwiw, I believe Fx used to have something in the parser for that |
| 18:40 | <Ms2ger> | Hixie, all those tests appear to use p[id] |
| 18:40 | <Ms2ger> | Doesn't the weird behaviour only apply to a[name]? |
| 18:51 | <annevk> | Hixie: yeah seems fair, can't do it right away, so if someone can remind me if I forget... |
| 19:38 | <_MysT> | Weird Mobile (android) Issue: http://gildedsocial.com/ Body { background-image: *** } not loading within Chrome or Default Browser in Android only (Firefox works) - Does anyone have any clue on this? Can't seem to get the background image to load at all!! |
| 20:30 | <Domenic> | Do we have use counter data on navigator.webkitGetUserMedia vs. navigator.getUserMedia? /cc annevk |
| 20:43 | <annevk> | dunno |
| 20:48 | <annevk> | I hate it when people suggest it is more likely they will address your feedback if you provide edits to the draft |
| 20:48 | <annevk> | I wonder if Art's etiquette guide covers that as it's absolutely wrong |
| 20:51 | <annevk> | hober: is the W3C archive not working for you? |
| 20:51 | <annevk> | hober: I suspect it'll be a while before DreamHost gets its act together |
| 20:53 | <annevk> | Hixie: hober: https://discussion.dreamhost.com/archive/index.php?thread-134209.html explains the problem as of Feb 2012 |
| 20:53 | <tantek> | annevk - (hopefully) quick q - do you plan on addressing URL equivalency checking in the URL spec? |
| 20:53 | <tantek> | as in, is URL1 == URL2 ? |
| 20:54 | <tantek> | e.g. does https://annevankesteren.nl == https://annevankesteren.nl/ |
| 20:54 | <tantek> | or even does http://annevankesteren.nl/ == https://annevankesteren.nl/ ? |
| 20:54 | <annevk> | tantek: if you parse them first and then compare the serialization, yes |
| 20:54 | <Ms2ger> | == is pointer comparison |
| 20:54 | <annevk> | tantek: the second would not |
| 20:55 | <tantek> | annevk - so I suppose I'm asking if that "parse them first and then compare the serialization" is worthy of mentioning in the spec as "How to compare URLs" |
| 20:55 | <annevk> | tantek: we don't currently treat /%7E and /~ as equivalent as browsers and not all servers do |
| 20:55 | <tantek> | annevk - I trust you to make reasonable decisions in terms of what should or should not be equivalent. |
| 20:55 | <annevk> | tantek: file a bug maybe? I suppose it's worth mentioning |
| 20:55 | <tantek> | I just want it specified :) |
| 20:56 | <tantek> | but wanted to run it by you first to see if you thought it was reasonable to include in scope |
| 20:56 | <annevk> | there's a semi-open issue on providing an API for comparison that gives several options for how much normalization you want |
| 20:56 | <annevk> | but there wasn't much feedback on it thus far |
| 20:57 | <tantek> | I think it's more important to specify comparison than to provide an API for it. |
| 21:01 | <annevk> | https://streams.spec.whatwg.org/ \o/ |
| 21:01 | <annevk> | Will read it through tomorrow Domenic |
| 21:01 | <annevk> | Domenic: dunno if you do blog posts, but maybe you want to write one about this https://blog.whatwg.org/ |
| 21:02 | <Domenic> | annevk: good idea probably ... still some areas need fleshing out, but the main stuff is there. Large parts are implementable. |
| 21:02 | <annevk> | tantek: fair, is there a specification that would reference such an algorithm? |
| 21:02 | <annevk> | tantek: that's the main reason I haven't written anything down yet |
| 21:03 | <annevk> | tantek: lack of something that wants to use it |
| 21:03 | <annevk> | tantek: which means it would be hard to test URL comparison, but I could still give recommendations I suppose |
| 21:03 | <tantek> | annevk - yes, the microformats representative h-card algorithm needs to reference something for comparing URLs. |
| 21:04 | <tantek> | and we're building code that depends on that algorithm actively - so it's a real world thing |
| 21:04 | <tantek> | not just a random spec thing |
| 21:04 | <tantek> | so it's likely to fully implement what you're specifying |
| 21:04 | <tantek> | and test it in real use on the web |
| 21:04 | tantek | tries to only ask for things that have pretty-immediate real world need :) |
| 21:05 | <annevk> | tantek: if you could file a bug and reference those things that'd be great |
| 21:05 | <annevk> | tantek: you're also free to use our support forum, I track it actively for input |
| 21:05 | <annevk> | (I'll prolly look through these logs again tomorrow, but I might forget) |
| 21:06 | <Domenic> | we have a support forum? |
| 21:06 | <annevk> | Domenic: that's how tantek refers to our mailing list, I was joking |
| 21:07 | <annevk> | Domenic: though we have https://forums.whatwg.org/ and a help mailing list |
| 21:07 | <annevk> | Domenic: whatwg/streams is already more popular than any other repo it seems, nice job |
| 21:13 | <Domenic> | :D |
| 21:25 | <Hixie> | hober: lists.whatwg.org is considered permanently dead. If you have broken URLs, you can easily fix them by opening them in browsers that haven't seen any other WHATWG URLs, copying the first sentence then searching for it on google and using the lists.w3.org URL instead. |
| 21:26 | <Hixie> | hober: all documentation has been updated (i believe) to not mention lists.whatwg.org |
| 21:27 | <Ms2ger> | Hixie, easily? |
| 21:35 | <Hixie> | ms2ger: takes a few seconds |
| 21:35 | <jgraham> | I have a cookbook from a slightly crazy resturant from the north of Sweden where agriculture is marginal at best. It will occasionally call for ingredients like "onion that has never been stored in the fridge". "Browser that has never seen other WHATWG URLs" puts me in the mind of this book which, I note, is totally impractical, but fascinating. |
| 21:42 | astearns_ | adds to the list of browsers I should have installed |
| 21:43 | <Hixie> | jgraham: heh |
| 21:43 | <Hixie> | i just make sure my non-test version of Safari never visits https://*.whatwg.org |
| 21:43 | <annevk> | Now all I want for Christmas is a browser that has never seen the web |
| 21:43 | <Hixie> | and list that browser for this purpose |
| 21:44 | <jgraham> | annevk: I hear Servo is the big toy this Christmas |
| 22:01 | <tantek> | annevk - will do |
| 22:06 | <hober> | Hixie annevk: how hard would it be to set up an automatic redirect, for individual message urls anyway, to http://www.w3.org/mid/${MESSAGE_ID} |
| 22:09 | <tantek> | and w3c bugzilla is busted for me - logins don't work |
| 22:09 | <tantek> | nor does password reset |
| 22:10 | <Hixie> | hober: sadly, we have zero control over that domain |
| 22:12 | <tantek> | fine I'm putting it on the whatwg.org wiki then |
| 22:13 | <tantek> | since even whatwg emails are archived at w3c now |
| 22:13 | <hober> | :( |
| 22:15 | <tantek> | new section: https://wiki.whatwg.org/wiki/URL#Requests_and_Issues |
| 22:15 | <tantek> | new request: https://wiki.whatwg.org/wiki/URL#How_to_compare_URLs |
| 22:15 | <tantek> | thanks again annevk |
| 22:21 | <Domenic> | TabAtkins: was there a nicer way to do long abstracts in Bikeshed than prefixing "Abstract: " before each line? E.g. using indentation? |
| 22:43 | <Hixie> | tantek: you really should figure out what's up with your bugzilla setup, its been broken for months |
| 22:44 | <tantek> | I suppose I can ping sysreq again about it. |
| 22:47 | <tantek> | I try to avoid W3C's bugzilla, and tracker too. |
| 23:24 | <TabAtkins> | Domenic: As long as lines are blank or start with whitespace, they're assumed to be a continuation of the previous metadata value. |
| 23:24 | <TabAtkins> | Domenic: Written in the docs. ^_^ |
| 23:37 | <aklein> | Hixie: you around? got a bit of a puzzling foster parenting situation |
| 23:37 | <Hixie> | sure |
| 23:38 | <aklein> | I'm interested in the parsing of "<body><a><table><a>" |
| 23:39 | <aklein> | what's interesting about it is that the foster-parenting algorithm manages to attach the second <a> to the first <a> even though it's already been "closed" |
| 23:39 | <Hixie> | so <a> is _really_ magical |
| 23:39 | <Hixie> | even more than most magical elements |
| 23:40 | <Hixie> | does your original question depend on the <a> magic or is that a distraction? |
| 23:40 | <aklein> | I'm not really sure yet |
| 23:40 | <Hixie> | ok |
| 23:41 | <aklein> | well, it's definitely related |
| 23:41 | <Hixie> | actually in this case i think the magic doesn't matter |
| 23:41 | <Hixie> | the short answer is, the first <a> isn't closed |
| 23:41 | <Hixie> | the <table> is in it |
| 23:41 | <aklein> | but we process a fake end tag for it! |
| 23:41 | <aklein> | let me go read the spec, I've been reading Blink code |
| 23:41 | <Hixie> | well, that's the magic i was talking about |
| 23:41 | <Hixie> | the end tag is ignored iirc |
| 23:41 | <aklein> | maybe this is a Blink bug then |
| 23:42 | <aklein> | how is the fake end tag ignored? |
| 23:42 | <Hixie> | well it's not really ignored |
| 23:43 | <Hixie> | it's just that the foster parenting is using the original <a> regardless |
| 23:44 | <Hixie> | you can see this magic in comparing these: |
| 23:44 | <aklein> | even though it's not on the stack of open elements... |
| 23:44 | <Hixie> | <a><table><a></table><i> vs <b><table><b></table><i> |
| 23:45 | <Hixie> | notice how in the first one, the third <a> is a sibling of the first one |
| 23:45 | <Hixie> | whereas in the second one, the third <b> is a child of the first |
| 23:46 | <aklein> | interesting... |
| 23:46 | <aklein> | so as it turns out the fragment I'm really interested in is "<template><a><table><a>" |
| 23:49 | <aklein> | which is causing blink to attach the second <a> to the template contents, rather than to the first <a> |
| 23:54 | <aklein> | Hixie: hmm, Gecko gets this right, we really may just have a Blink bug here |
| 23:54 | <aklein> | Hixie: sorry for the premature noise |
| 23:54 | <Hixie> | oh no worries, that's what i'm here for :-) |
| 23:54 | <Hixie> | if you decide it's a spec bug let me know |
| 23:54 | <aklein> | sure |
| 23:55 | <Hixie> | i don't guarantee the template stuff is bug free in the spec :-) |
| 23:55 | <caitp> | html parsing is arguably one giant spec bug that can never be fixed |
| 23:55 | <aklein> | Hixie: I'm going to try re-implementing this bit of logic with what the spec says and I'll see what I get |