| 00:00 | <jamesr___> | othermaciej: i think in that case microtasks shouldn't fire |
| 00:00 | <jamesr___> | since the general philosophy is that they run on clean callstacks, no? |
| 00:00 | <othermaciej> | I don’t know what the philosophy is |
| 00:00 | <othermaciej> | The spec doesn’t explain the theory of microtasks at a high level, it just has a bunch of algorithms that reference each other |
| 00:00 | <jgraham> | jsbell: Right, but the problem is semantics. A test for cross-origin communication isn't necessarily going to work if I just s|http://locahost:8000|https://{{host}}:{{ports[https][0]}}| |
| 00:01 | <othermaciej> | so I can’t tell if I’m following them correctly |
| 00:01 | <jamesr___> | i think the idea is you implement the algorithms you don't have to understand the theory :) |
| 00:01 | <jgraham> | jsbell: So it would be useful if the chrome tests were rewritten to run from https:8443 by default |
| 00:01 | <othermaciej> | jamesr___: what confuses me is this Note: https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9:clean-up-after-running-a-callback |
| 00:02 | <othermaciej> | jamesr___: it seems like most kinds of callbacks do not in fact eventually call the “clean up after running a callback” steps |
| 00:02 | <othermaciej> | jamesr___: which is the hook where microtasks might be run after running some script |
| 00:02 | <jsbell> | jgraham: if you're asking us to s/http/https/, s/8000/8443/ where possible in the blink repo, then SGTM |
| 00:02 | <jamesr___> | looks like that's only reached by 8.1.3.3 which is reached by creating a <script> |
| 00:02 | <othermaciej> | jamesr___: that note implies they would, but it only seems to apply to non-function entry into script |
| 00:03 | <othermaciej> | jamesr___: if that is totally intentional, then perhaps the only issue is that the note is confusing |
| 00:03 | <jamesr___> | it seems a bit confusing. the flag in the queue is needed since the event loop can be entered reentrantly |
| 00:03 | <jgraham> | jsbell: Yeah, that would be ideal |
| 00:03 | <jamesr___> | i.e. you could within a microtask call showModalDialog() and then start spinning again |
| 00:04 | <jamesr___> | could you insert a new <script> within a microtask? |
| 00:04 | <jamesr___> | i mean you could, but would it run then? |
| 00:05 | <othermaciej> | I don’t know |
| 00:05 | <jamesr___> | well you could via showModalDialog |
| 00:05 | <jamesr___> | since you can do anything in that |
| 00:05 | <othermaciej> | document.write() would run it synchronously but I am not sure if something about microtasks prevents it |
| 00:05 | <jamesr___> | but i don't think that's what the note is supposed to signify. definitely worth some clarification |
| 00:05 | <jsbell> | jgraham: but ideally we should be using resources/test-helpers.js and get_host_info() everywhere instead of hardcoding anything |
| 00:06 | <othermaciej> | I notice though that there is nothing to account for non-<script> script callbacks in that algorithm |
| 00:06 | <jsbell> | jgraham: i.e. crbug.com/462361 |
| 00:06 | <othermaciej> | I guess the only relevance is to prevent the algorithm from re-entering so it doesn’t matter that most script callbacks don’t do it |
| 00:07 | <jgraham> | jsbell: Right, but irrespective of that moving from http to https by default requires changes to what's considered cross-origin + etc. |
| 00:08 | <jsbell> | jgraham: get_host_info() populates e.g. HTTPS_REMOTE_ORIGIN; assuming the tests use those variables correctly, wouldn't that cover it? (sorry if I'm being dense here) |
| 00:09 | <jgraham> | Well I think my point is just that the changes there might not be trivial, depending on *exactly* what is being tested |
| 00:09 | <jsbell> | jgraham: Agreed. |
| 00:11 | <jgraham> | e.g. if the default server is https://localhost:8443 then the remote origin probably has to be a subdomain, or different port, or something, whereas at the moment https is itself a seperate origin |
| 00:11 | <jgraham> | (and different tests might want different things here) |
| 00:12 | <jgraham> | Anyway I guess I will look at this more tomorrow, now I will sleep |
| 00:12 | <jgraham> | jsbell: thanks for the help! |
| 00:12 | <jsbell> | jgraham: I'll reply to the thread a bit and annotate the bug, but your clarifications (post sleep!) will help, thx! |
| 02:42 | <jpdevries> | Hello all. I understand this would probably target HTML6, but does anyone else feel there is a case for allowing multiple <base> tags on a page (outside of <head>)? Imagine being able to nest a base tag in a section and have it override the base href for that section and it's inner elements. |
| 09:02 | <Ms2ger> | "I tried to make an "end credits" slide w/ IE-only APIs not in Project Spartan that scrolls while I talk. The list was so long it crashed PPT" |
| 09:13 | <jgraham> | Ms2ger: Pointer? |
| 09:14 | <Ms2ger> | https://twitter.com/jacobrossi/status/580253880690208768 |
| 09:21 | <Ms2ger> | annevk_, https://github.com/servo/servo/issues/5336 |
| 11:47 | <tiago> | hi, how would I read a certain meta tag with html5lib? |
| 11:47 | <tiago> | in python |
| 11:47 | <tiago> | like, <meta name="description" content="Something" /> |
| 11:47 | <tiago> | I need the "Something" |
| 11:52 | <JakeA> | tiago: this channel is for HTML & DOM specs. In JS it could be document.querySelector('meta[name=description]').getAttribute('content'), dunno if html5lib has something similar. It isn't maintained by whatwg. |
| 11:52 | <tiago> | Thanks JakeA, it's just because the html5lib github page points to this channel |
| 11:54 | <JakeA> | Streams people (cc Domenic), if I have an underlying binary stream, piped to a text decoding transform stream, piped to a CSV decoder, should the CSV decoder yield, say, a CSV cell per read, or is it customary to deliver as much data as you can per read? |
| 11:57 | <JakeA> | tiago: oh, actually, maybe I'm wrong, looks like quite a few people in this channel build that lib. My bad. +MikeSmith gsnedders |
| 11:58 | <tiago> | ah |
| 12:06 | <JakeA> | tiago: once you've got a document, you can use .childNodes to gets its children etc etc. Once you find the meta, use .attributes and find the one with name 'name' |
| 12:06 | <JakeA> | https://github.com/html5lib/html5lib-python/blob/f5fd711dd3e933353423656b8adf114e436cc4bb/html5lib/treebuilders/etree.py#L19 |
| 12:07 | <tiago> | thanks JakeA, I will tr |
| 12:07 | <tiago> | *try |
| 12:51 | <Domenic> | JakeA: CSV cell (more likely row) per read is generally customary |
| 12:54 | <JakeA> | Domenic: thanks! |
| 12:56 | <JakeA> | Domenic: btw, the streams API seems to be a perfect balance of simplicity and functionality. Nice one |
| 12:56 | <Domenic> | :D |
| 13:08 | <wanderview> | yea, it seems for chunk or message oriented streams like ReadableStream... each chunk should be a logical object for whatever transformation you are doing |
| 13:08 | <wanderview> | I think its less clear for ReadableByteStreams |
| 13:09 | <JakeA> | wanderview: yeah, or text which is "as many chars as possible", and it only holds back incomplete chars |
| 13:26 | <annevk_> | Domenic: iirc I told you that TextDecoder kept state, but TextEncoder didn't |
| 13:27 | <annevk> | JakeA: you should keep passing stream:true until you hit OEF |
| 13:29 | <JakeA> | annevk: that's what I'm doing |
| 13:29 | <JakeA> | stream is !result.done |
| 13:30 | <annevk> | JakeA: we could maybe make pipe(new TextDecoder) work for the common case, if TextDecoder/TextEncoder implement some stream-protocol |
| 13:31 | <Domenic> | annevk: ah yes, now I remember |
| 13:31 | <JakeA> | annevk: at a quick glance, I think that could be possible in a backwards compatible way |
| 13:32 | <JakeA> | You could maybe even define .decode in terms of real streams |
| 13:32 | <Domenic> | yeah just add .writable and .readable properties |
| 13:33 | <JakeA> | Domenic: the bit I'm worried about is what .decode etc do if you're using the decoder as a stream |
| 13:33 | <Domenic> | yeah true |
| 13:33 | <Domenic> | perhaps unnecessarily complicated |
| 13:34 | <JakeA> | Domenic: it could be as simple as it throws if the stream is locked |
| 13:34 | <Domenic> | Mehhhh |
| 13:35 | <JakeA> | Using it as a stream, *and* calling .decode sounds like a mistake |
| 13:39 | <wanderview> | It seems the streamified object should wrap an existing TextDecoder object |
| 13:40 | <JakeA> | Gone done a post on fetch & streams http://jakearchibald.com/2015/thats-so-fetch/ |
| 13:41 | <Domenic> | wanderview: or TextDecoder should wrap a streamified object. But, they should be separate I think... too messy otherwise. |
| 13:41 | <wanderview> | Domenic: I think since TextDecoder existed first... its easier to write the new stream in terms of the TextDecoder |
| 13:42 | <Domenic> | Sure |
| 13:59 | <annevk> | JakeA: "Dramatic reconstruction" :-) |
| 14:06 | <JakeA> | annevk: I had to fallback to an SVG of that on iphone because they *still* don't allow inline video |
| 14:07 | <JakeA> | Could have used a 5mb gif but screw that |
| 14:14 | <Domenic> | an svg O_O i gotta see this |
| 14:16 | <Domenic> | hmm tried it on my ipad looks the same |
| 14:19 | <Domenic> | don't engage webreflection... |
| 14:24 | <JakeA> | Domenic: ah, too late |
| 14:25 | <Domenic> | he is _the_ es-discuss troll |
| 14:25 | <JakeA> | Domenic: the SVG is static unfortunately. Inline video works fine on ipad |
| 14:25 | <Domenic> | hmm i was picturing an animated vector representation |
| 14:25 | <JakeA> | So I'm not crazy then? I can't match up what webreflection is saying to reality |
| 14:26 | <wanderview> | JakeA: I think maybe if someone focuses on the tongue-in-cheek parts they could view it as a rant... *mumbles something about cognitive bias* |
| 14:27 | <JakeA> | maybe. I tried to keep it tongue-in-cheek and of course didn't name |
| 14:28 | <gsnedders> | JakeA: the official policy has always been there's no real topic for this channel, and nobody really cares about using this for html5lib since half the discussions historically were half spec discussions and actual questions are pretty infrequent |
| 14:29 | <MikeSmith> | does anybody maintain a JSON file or something with a list of the currents UA strings for major browsers? |
| 14:30 | <MikeSmith> | something meant to be easily consumable |
| 14:30 | <wanderview> | JakeA: I know... it was a valiant effort... but people tend to see what they expect to see unfortunately |
| 14:31 | <JakeA> | gsnedders: noted, cheers! |
| 14:33 | <ondras> | webreflection is andrea giammarchi_ |
| 14:33 | <ondras> | ? |
| 14:33 | <ondras> | I recall his talk on jsconf.eu ~2012 or so |
| 14:34 | <caitp-> | was this whole thing about how fetch is bad because of promises, or was that a different one? |
| 14:35 | <jgraham> | MikeSmith: At one point that UA sniffing tool thing had them, I think. Or I guess regexps that were supposed to match lots of known browsers |
| 14:35 | <wanderview> | caitp-: I believe this started with "OMG fetch is not based on streams" |
| 14:35 | <wanderview> | or maybe there are two issues flying about |
| 14:36 | <MikeSmith> | jgraham: ok |
| 14:38 | wanderview | enables Cache by default in Firefox nightly. |
| 14:39 | <JakeA> | ondras: he's a cool guy, he's just a bit hot-headed about this |
| 14:39 | <jgraham> | MikeSmith: Something like https://github.com/3rd-Eden/useragent/blob/master/lib/regexps.js |
| 14:40 | <JakeA> | caitp-: yeah, partly it was "this is not based on streams" even though it is, but also that we don't have cancellation yet, but that's on its way |
| 14:44 | <JakeA> | wanderview: ohhhh! In window objects too? |
| 14:44 | <MikeSmith> | jgraham: looking now |
| 14:44 | <wanderview> | JakeA: yep... it won't ride the trains to release yet, though |
| 14:45 | <wanderview> | I'm going to push a blog post in a bit explaining |
| 14:45 | <MikeSmith> | jgraham: ah coolーthanks |
| 15:18 | wanderview | can never figure out how to get images to look right in twitter summary cards. |
| 15:23 | <wanderview> | JakeA: here is the blog explaining what we are doing: https://blog.wanderview.com/blog/2015/03/24/service-workers-in-firefox-nightly/ |
| 23:21 | <MikeSmith> | wanderview: nice blog post |
| 23:21 | <MikeSmith> | wanderview: thanks for taking time to write it up |
| 23:22 | <MikeSmith> | wanderview: the amount of work you've been doing to get there is pretty phenomenal |
| 23:25 | jgraham | always forgets who wanderview is |
| 23:26 | <jgraham> | Also wanderview++ on landing the SW stuff. Hopefully we make more progress with the Blink tests soon |
| 23:26 | <MikeSmith> | ah tests |
| 23:30 | <jsbell> | jgraham: If no-one beats me to it, I'll try and pick up the blink side of the test todos, but I'm booked solid for ~2 weeks |
| 23:31 | <jgraham> | jsbell: That sounds great :) (well not that you are booked solid ofc. Unless it's solid fun ;) |
| 23:51 | <jsbell> | wanderview: is the caches API in FF scoped to SW or exposed everywhere? |