| 00:03 | <annevk> | smola: : failing is because of port parsing |
| 00:04 | <annevk> | smola: so it doesn't really count I think |
| 00:10 | <smola> | annevk: yes, and then if you do a.host = 'a:b' the behaviour also differs |
| 00:10 | <annevk> | smola: yeah I know, URLs are a mess |
| 00:11 | <annevk> | smola: I personally like what we have now, modulo the check needing to come after IDNA |
| 00:12 | <annevk> | smola: I'd really like to let someone else do the domain parsing entirely |
| 00:12 | <annevk> | smola: but the IETF / Unicode crowd isn't doing much at the moment |
| 00:13 | <smola> | as far as I see, the post-ToASCII checks (and deciding which characters to allow there) are the only thing left? |
| 00:16 | <smola> | well, there's other stuff such as length limits according to DNS |
| 00:16 | <smola> | not sure if that should be part of the spec though |
| 00:19 | <annevk> | if they are observable before we hit DNS, yes |
| 00:19 | <annevk> | IDNA does those checks |
| 00:19 | <smola> | yeah, that is, max 127 labels, 63 bytes per label, 253 bytes in the full textual representation |
| 00:19 | <smola> | or something like that |
| 00:19 | <annevk> | but maybe they are skipped if everything is ASCII? |
| 00:19 | <smola> | Firefox checks some of them |
| 00:21 | <smola> | I think they're done independently of it being ASCII or not |
| 00:21 | <smola> | but it's too late to check it :p |
| 00:21 | <annevk> | oh, 12:21, I'll have a look tomorrow I suppose |
| 00:23 | <smola> | yup, I'm leaving for today, good night |
| 00:28 | <annevk> | nn |
| 07:01 | <zcorpan_> | annevk-cloud: re http://krijnhoetmer.nl/irc-logs/whatwg/20140113#l-961 check the error console |
| 07:01 | <zcorpan_> | annevk-cloud: you probably want document.documentElement.removeChild |
| 07:04 | <zcorpan_> | oh that was pointed out already |
| 07:07 | <zcorpan_> | annevk-cloud: presto's xml parser (and old html parser) would go wacky when removing an element during parsing, iirc |
| 08:35 | Ms2ger | wonders what happened to initialTime |
| 08:41 | <Ms2ger> | http://html5.org/tools/web-apps-tracker?from=7045&to=7046 apparently |
| 10:37 | <annevk> | Lol at www-tag |
| 10:45 | <annevk> | If server configuration became easier CORS could be a setting at the DNS level. Where servers announce they know CORS exists, thereby avoiding the need for preflight requests. |
| 10:46 | <annevk> | Could also configure HSTS there... |
| 10:53 | <darobin> | and CSP |
| 10:55 | <annevk> | CSP is not quite global; CORS isn't quite either of course... |
| 11:18 | <smola> | zcorpan_: you mentioned a set of 102,000 pages containing weird URLs |
| 11:18 | <smola> | zcorpan_: is that public? |
| 11:19 | <zcorpan_> | smola: http://webdevdata.org |
| 11:20 | <annevk> | smola: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23009 |
| 11:23 | <smola> | annevk: yeah, I was checking now, thanks |
| 11:23 | <annevk> | smola: I guess I should also ban 0x09, 0x0A, and 0x0D |
| 11:24 | <smola> | zcorpan_: awesome, thank you |
| 11:24 | annevk | adds those |
| 11:25 | <smola> | annevk: if re-parsing must give the same result, yes |
| 11:25 | <annevk> | smola: we want idempotency as much as possible for security |
| 11:26 | <smola> | yes, I also want idempotency because I use this code for URL normalization in crawling |
| 11:26 | <smola> | non-idempoency: more duplicates |
| 11:29 | <annevk> | Still a bunch of open bugs around percent encoding :/ |
| 11:29 | <annevk> | I hate that shit |
| 11:33 | <gjsrivastava> | Hi |
| 11:36 | <smola> | annevk: btw, has someone ever seen such weird hostnames in weird intranet configurations? |
| 11:36 | smola | thinks those intranets are just magic elves |
| 11:37 | <hsivonen> | annevk: lots of cool things could be done if 1) DNS was easy to configure (it actually can be pretty easy), 2) DNSSEC was deployed (can be bought as a service already) and 3) middle boxes allowed currently-unusual DNS responses to flow through |
| 11:37 | <hsivonen> | annevk: the situation with #3 is really sad |
| 11:37 | <hsivonen> | middle boxes are sad |
| 11:37 | <annevk> | middleware is sad |
| 11:38 | <annevk> | smola: hmm, I should have done some testing maybe, I cannot reproduce even the label limits |
| 11:39 | <annevk> | E.g. try |
| 11:39 | <annevk> | <a href="http://0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/">test</a>; |
| 11:39 | <annevk> | <script>w(document.querySelector("a").host.length)</script> |
| 11:40 | <annevk> | IDNA interoperability is so sad |
| 11:41 | <smola> | annevk: true, it actually works in chrome |
| 11:42 | <smola> | of course it'll never resolve |
| 11:42 | <annevk> | smola: works in Firefox too |
| 11:42 | <smola> | hm, or it might resolve with /etc/hosts ? |
| 11:43 | <annevk> | I suppose it could, I don't really have any desire to go lower on the stack at the moment |
| 11:43 | <annevk> | This part is fucked up enough as is |
| 11:44 | <smola> | on Firefox+Linux it does not resolve it in any case |
| 12:05 | <hsivonen> | "A new body is required to take on the responsibility of providing standards for an open web." http://lists.w3.org/Archives/Public/public-restrictedmedia/2014Jan/0070.html |
| 12:06 | <Ms2ger> | WHATWG? |
| 12:09 | <jgraham> | Not the Web Hypermedia Including Concessions for Hollywood Working Group? |
| 12:14 | <Ms2ger> | Clever, sir, clever |
| 12:33 | <smola> | anti-DRM candidate emailing from @live.com, interesting :p |
| 12:43 | <darobin> | nice one jgraham, really nice one |
| 12:43 | <darobin> | and then we could go WHICH hunting |
| 12:46 | <gjsrivastava> | sankha93 are you around? |
| 12:47 | <blackhair> | gjsrivastava: I know sankha but he is not here right now |
| 14:41 | <jgraham> | Domenic_: Note that "will" in spec language is a statement of fact |
| 14:43 | <jgraham> | So if you were to say "these steps will be run asynchronously", there would have to be text elsewhere that actually caused those steps to run |
| 15:29 | <annevk> | Why do we not have utility functions for specifications? |
| 15:29 | <annevk> | E.g. hex bytes to number |
| 15:32 | <Domenic_> | jgraham: hmm thanks, good to note |
| 15:33 | <annevk> | In fact, that's not much more than a note |
| 15:33 | <annevk> | A statement of fact is more like "A has an associated B." |
| 15:34 | <annevk> | Facts describe the world, notes explain it, and requirements make it run. |
| 15:34 | <Domenic_> | It felt like a fact to me. It's a requirement to run those steps, but a fact about those steps is that they will happen asynchronously. |
| 15:34 | <Domenic_> | although, they don't have to be asynchronous |
| 15:34 | <Domenic_> | if e.g. that data is cached in memory |
| 15:35 | <annevk> | Well, notes should be factual, but they are usually duplicative. |
| 15:38 | <jgraham> | Domenic_: http://ln.hixie.ch/?start=1140242962&count=1 is the canonical source on this |
| 15:38 | <Domenic_> | jgraham: ah excellent. |
| 15:46 | <annevk> | Seems I use statement of fact more as a definition. I try to avoid the statements of facts Hixie talks about, as, as he points out, they are confusing |
| 15:47 | <jgraham> | Yeah. In this case I think it would be very confusing. |
| 15:47 | <annevk> | http://www.w3.org/TR/2014/NOTE-calendar-api-20140114/ |
| 15:47 | <annevk> | http://www.w3.org/TR/2014/NOTE-messaging-api-20140114/ |
| 15:47 | <annevk> | http://www.w3.org/TR/2014/NOTE-system-info-api-20140114/ |
| 15:47 | <annevk> | http://www.w3.org/TR/2014/NOTE-contacts-api-20140114/ |
| 15:47 | <annevk> | http://www.w3.org/TR/2014/NOTE-gallery-20140114/ |
| 15:47 | <annevk> | http://www.w3.org/TR/2014/NOTE-webintents-local-services-20140114/ |
| 15:48 | <annevk> | bye bye APIs? |
| 15:54 | <annevk> | Domenic_: in https://github.com/domenic/promises-unwrapping/issues/85 what does getWebApplicationsMetadata() do? |
| 15:55 | <annevk> | Domenic_: if that's about asking the user something, I don't really get how it can be synchronous |
| 15:56 | <Domenic_> | annevk: I think marcosc's intent was that it gets <title> and some <meta> tags, or some manifest stuff. The user-asking happens in userAgentSpecificChoooser |
| 15:56 | <annevk> | Domenic_: which also seems sync in your text |
| 15:57 | <annevk> | Domenic_: in particular https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md#addbookmark-- seems very bad |
| 15:57 | <Domenic_> | annevk: userAgentSpecificChoooser is async |
| 15:57 | <annevk> | Domenic_: you cannot tell from that example text |
| 15:58 | <Domenic_> | annevk: yeah, we are discussing on www-tag how I seem to have implicitly assumed (as a JS programmer) that any algorithmic step that involves asking the user would automatically be async |
| 15:58 | <annevk> | Domenic_: from that example spec text you'd implement a sync chooser and resolve and then return |
| 15:58 | <Domenic_> | you can see similar confusion in my https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md#delay-ms-, which as boris points out would naively block for ms milliseconds |
| 15:59 | <annevk> | Domenic_: yes |
| 15:59 | <annevk> | Domenic_: that's why the return early, but continue running steps in the background makes a lot of sense |
| 16:00 | <annevk> | Domenic_: I haven't seen anyone been confused with those |
| 16:00 | <Domenic_> | annevk: I maintain that it makes zero sense at all |
| 16:00 | <Domenic_> | to me it translates to return x; setImmediate(function () { /* do those extra steps */ }) |
| 16:00 | <Domenic_> | (pretending that setImmediate is a thing) |
| 16:00 | <annevk> | no, it's much more like set up an internal event listener to wait for something and then return |
| 16:01 | <annevk> | the remainder of the steps explain what |
| 16:01 | <annevk> | you don't queue a task to wait for something, you wait for something to be queued |
| 16:02 | <Domenic_> | well, where does that internal event listener get set up |
| 16:02 | <Domenic_> | it certainly can't get set up after you return |
| 16:03 | marcosc | catches up... denies everything while doing so |
| 16:03 | <annevk> | Domenic_: shrug |
| 16:04 | <annevk> | Whether you say "The remainder is run asynchronous. Return here." "Return here, but continue doing this" seems immaterial |
| 16:04 | <jgraham> | So the Hixie model isn't beautiful in that it doesn't map directly to programming language constructs |
| 16:04 | <annevk> | I'm interested in cleaning it up further, but it's much more clear than what you have, which leads everyone to assume we suddenly have sync constructs |
| 16:04 | <jgraham> | But it does do the right thing |
| 16:06 | <Domenic_> | yes, what i have right now is clearly wrong |
| 16:07 | <Domenic_> | and, after everyone explaining exactly how wrong, i'll agree it's more wrong than the current model |
| 16:07 | <Domenic_> | but i think it's important to clean up the current model |
| 16:09 | <marcosc> | oh, seems I missed the update to that bug |
| 16:09 | <marcosc> | I'll have to re-read the document |
| 16:09 | <marcosc> | Domenic_: thanks anyway for notifying me of the update - sorry I missed it. Should I review the doc now? |
| 16:10 | <Domenic_> | marcosc: sure! everyone else is doing it now :). http://lists.w3.org/Archives/Public/www-tag/2014Jan/0038.html http://lists.w3.org/Archives/Public/www-tag/2014Jan/0052.html |
| 16:12 | <marcosc> | Domenic_: ok, will try to do it later today |
| 16:12 | <marcosc> | Btw, I found it quite helpful last time around. It was the missing manual :) |
| 16:13 | <annevk> | Domenic_: so I think typically you want to listen for activity and then queue a task to do several things in response |
| 16:13 | <annevk> | Domenic_: e.g. XHR listens to network activity and then queues a single task to dispatch several events and update some properties |
| 16:14 | <annevk> | Domenic_: it's very common to group updating a property and dispatching the event directly after |
| 16:14 | <annevk> | Domenic_: I suspect most things can be implemented given those two concepts |
| 16:15 | <annevk> | Domenic_: prolly some legacy exceptions in HTML though |
| 16:15 | <Domenic_> | annevk: hmm ok, will study. |
| 16:16 | <Domenic_> | annevk: I find the task queues confusing though; e.g. it seems like it should be possible to call back from C++ to JS without using a task queue |
| 16:16 | <annevk> | Domenic_: if it's sync, sure |
| 16:17 | <annevk> | Domenic_: if it's async, not really, you'd get race issues |
| 16:17 | <jgraham> | Right. Task queues are just the event loop for the spec |
| 16:17 | <Domenic_> | even if it's async... e.g. in Node when I program C++ extensions, I can just call back into JS. |
| 16:17 | <annevk> | Domenic_: how do you know JS is not running? |
| 16:17 | <Domenic_> | it can be either sync or async; promises normalize it to async |
| 16:17 | <Domenic_> | annevk: fair point |
| 16:19 | <annevk> | I don't know what Node's model looks like unfortunately, but I do know that for the web platform we need a task queue. |
| 16:21 | <Domenic_> | nah, I think it has a task queue, I just didn't realize I was using it. |
| 16:21 | <Domenic_> | this helped click with me exactly what "queue a task" means... |
| 16:22 | <Domenic_> | I thought it was something like setImmediate(taskCode), albeit with a task queue name that the loop does complicated stuff with |
| 16:22 | <Domenic_> | but it's really more about proxying back to JS from C++ land, it sounds like... |
| 16:22 | <jgraham> | The name isn't complicated |
| 16:23 | <jgraham> | the event loop pulls a task off one of the task queues to run |
| 16:23 | <jgraham> | The name tells you which task queue |
| 16:23 | <Domenic_> | it's a lot more complicated that fifo |
| 16:23 | <jgraham> | a task goes on |
| 16:24 | <jgraham> | So things are fifo per queue |
| 16:24 | <jgraham> | But not fifo overall |
| 16:24 | <jgraham> | But of course UAs don't pick a queue at random |
| 16:24 | <annevk> | A simpler example of the listen, queue thing is setTimeout() |
| 16:25 | <jgraham> | They can have internal priority e.g. always process user events like click or whatever first |
| 16:25 | <annevk> | First you listen until some period of time has passed, then you queue a task to do some operation |
| 16:25 | <annevk> | You need to queue a task because mouse events, network events, parsing, etc. might all go on as well and they need to be ordered somehow |
| 16:29 | <Domenic_> | Yeah |
| 16:29 | <Domenic_> | I should blog all this learnings |
| 16:36 | <annevk> | Domenic_: as for the ES being complicated and more precise, that's kinda why we have IDL |
| 16:37 | <annevk> | Domenic_: now if the ES spec defined IDL and had some of its own stuff in terms of that, we might be able to make the whole thing more portable... |
| 16:40 | <Domenic_> | annevk: this is more about algorithmic steps though |
| 16:40 | <Domenic_> | annevk: I feel I often see web specs say things in one or two sentences that would take a page to express in ES-spec's precision |
| 16:42 | <jgraham> | So one of the main complaints that we get about web specs is that we aim for precision rather than the touchy-feely specs of yore |
| 16:45 | <annevk> | It's funny really |
| 16:45 | <annevk> | But I do admit to taking shortcuts now and then |
| 16:45 | <annevk> | There's too much to define |
| 16:46 | <annevk> | But I'm not sure if it then immediately lacks precision. It only lacks precision if you can implement it in two different ways... |
| 16:51 | <Domenic_> | Right... I'm not sure I'd know how to spot such instances. For the ES spec I can always see how you would, e.g. by inserting objects that trigger edge case behaviors, or testing esoteric properties of the objects you are given. |
| 16:52 | <annevk> | IDL cleans most of that up |
| 16:53 | <jgraham> | Indeed, IDL takes care of a lot of the sanitisation |
| 16:53 | <annevk> | Domenic_: as for the algorithmic steps, you could have shorthands for all the common operations |
| 16:54 | <annevk> | Domenic_: that do the magic, but it'd require a huge amount of effort to figure out all the primitives across the many many APIs |
| 16:55 | <jgraham> | You also run the risk of lasagne specs |
| 16:56 | <jgraham> | Which are neatly divided into layers, but impossible to understand overall by reading any one bit of text |
| 16:56 | <annevk> | But but but layering |
| 17:44 | <dglazkov> | good morning, Whatwg! |
| 17:45 | <jory> | Good morning to you, dglazkov. |
| 19:52 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-dom/2014JanMar/0016.html |
| 23:11 | <Hixie> | how very sad, scrollable regions don't get 'focus' events |
| 23:13 | <Hixie> | hm, they do if you tab, in firefox |
| 23:28 | <Hixie> | hah, chrome gets <area> focusing wrong |
| 23:28 | <Hixie> | if two <img>s use the same <area>, and you click on the second <img>'s use of the <area>, the first one gets the focus ring |
| 23:29 | <Hixie> | firefox renders them right but sends a focus event again if you just tap from one to the other |
| 23:29 | <Hixie> | even though nothing changed focus at the element level |