| 04:29 | <Krinkle> | Hm.. is there an interface exposed in browsers to build a DOM from HTML gradually (as opposed to all at once). Essentially consuming a stream. While conceptually slow/complex to do manually (I think), the logic for deciding when a tag is save to include in the dom and how to build it already exists in browsers today. Exposing this with events would be interesting. |
| 04:34 | <MikeSmith> | Krinkle: what you're describing sounds pretty much like the SAX API |
| 04:34 | <MikeSmith> | which isn't something that browsers implement and it's kinda hard to imagine how they would usefully |
| 04:35 | <MikeSmith> | as far as the parsed document that browsers expose |
| 04:36 | <MikeSmith> | but I think there's at least one JS-based SAX implementation |
| 04:36 | <MikeSmith> | or you know about SAX already, maybe I'm not understanding what you're proposing |
| 04:37 | <MikeSmith> | *if you know about SAX already |
| 04:38 | <Krinkle> | The use case I'm working on is for Wikipedia's visual document editor. It loads an HTML5 representation of the article (essentially what readers see without a theme or scripts, and more data about where individual pieces originate from), uses DOMParser, and then processes that to compose a content editable surface. |
| 04:38 | <Krinkle> | It'd be rad to do that from a stream and start building our linear model while HTML is interpreted. |
| 04:39 | <Krinkle> | (e.g. XHR2 streams) |
| 05:01 | <MikeSmith> | rektide: ↑ |
| 05:03 | <MikeSmith> | Krinkle: it sounds like a JS-based SAX parser could help get you there |
| 05:07 | <Krinkle> | MikeSmith: Yeah, there exist good SAX parsers for JSON. I'm skeptical how an HTML would work. Implementing html5 properly is no easy task. And I suspect it might perform poorly compared to native and perhaps nullify the advantage of streaming. Having said that, we have observed that parsing large documents can definitely take a considerable amount of time (seconds), so there's room. |
| 05:07 | <Krinkle> | MikeSmith: Though I forgot for a second that our internal html5 representation of the article content is actually valid XML as well. |
| 05:15 | <MikeSmith> | Krinkle: yeah if you need to make something that's capable of handling arbitrary HTML content from the Web, you need something that implements the HTML parsing algorithm, there's also the problem that there are parts of the HTML5 parsing algorithm that can't be implemented in truly streaming parser |
| 05:16 | <Krinkle> | MikeSmith: Yeah, but the spec handles quite explicitly from what I recall and browsers (nowadays) implement that. |
| 05:17 | <Krinkle> | Hence I figured it should be too complicated to expose since the behaviour is already specified. Since browsers generally do parse from a stream as well (e.g. server can flush buffer early). |
| 05:17 | <Krinkle> | shouldn't * |
| 05:18 | <Krinkle> | It'll probably never happen, but something like DOMParser that takes a Blob/Buffer (node-ism) and returns Promise with EventEmitter. That's what I'd expect server-side. |
| 08:45 | <annevk> | Domenic: did you see https://github.com/kriskowal/gtor/blob/master/README.md#singular-and-temporal from Kris? |
| 08:45 | <annevk> | Domenic: I guess you have |
| 08:46 | <annevk> | Domenic: it's kinda nice how he talks about futures/promises/tasks to mostly do the same thing, but I'm not sure I see JavaScript going that way |
| 08:46 | <annevk> | Domenic: but maybe at some point |
| 08:47 | <annevk> | Domenic: although on the other hand, people have trouble deciding between a promise and a callback; giving them three different types of promises might be a bit much |
| 08:58 | <nekllen> | Hi! I'd like to integrate with validator directly in my java code (rather than as an external http service); how possible is this? |
| 08:59 | <MikeSmith> | hi nekellen |
| 08:59 | <MikeSmith> | it's possible |
| 09:01 | <MikeSmith> | nekellen: the code you want to look as an example is https://github.com/validator/validator/blob/master/src/nu/validator/client/SimpleCommandLineValidator.java |
| 09:01 | <MikeSmith> | the entry point in the sources is https://github.com/validator/validator/blob/master/src/nu/validator/validation/SimpleDocumentValidator.java |
| 09:04 | <nekellen> | MikeSmith: ok, great. Is there some description of which dependencies I'll need to include? I saw in https://github.com/validator/validator/issues/13 that validator was potentially using older/unsupported versions of libs |
| 09:05 | <nekellen> | or are all of these getting included in validator.jar ? |
| 09:05 | <MikeSmith> | yeah the dependencies are all in validator.jar |
| 09:05 | <MikeSmith> | all 22MB of them |
| 09:09 | <MikeSmith> | in your code basically you want to do validator = new SimpleDocumentValidator() then validator.setUpMainSchema then validator.setUpValidatorAndParsers and then, depending on where the doc you're checking is coming from, either validator.checkHtmlInputSource or validator.checkHttpURL or validator.checkHtmlFile |
| 09:11 | <MikeSmith> | oh the other main thing you need to do first is to set up an ErrorHandler |
| 09:15 | <nekellen> | MikeSmith: That gives me a good place to start, thanks! |
| 09:15 | <MikeSmith> | cheers |
| 10:29 | <annevk> | wanderview: I just realized I have not adequately defined Headers' guard for cloning |
| 12:24 | <annevk> | Summary of fetch termination: https://annevankesteren.nl/2015/02/cancelable-promises |
| 12:30 | <zcorpan> | and darobin 386es Yucca |
| 12:30 | <darobin> | there are days on which it's impossible to resist :) |
| 12:31 | <zcorpan> | yeah i know |
| 12:31 | <annevk> | wanderview: btw, that guard thing is fixed now, while you sleep :p |
| 12:45 | <zcorpan> | where's krijn? |
| 12:57 | <zcorpan> | TabAtkins: i can add some headings to <img> i guess |
| 14:03 | <wanderview> | annevk: sleep is a strong word when you have a baby (which I'm sure you know) |
| 14:03 | <annevk> | heh |
| 14:04 | <zcorpan> | annevk: would it make sense to have a <meta> or <link> to invoke the OPTIONS * preflight, to reduce latency? |
| 14:05 | <zcorpan> | latency of the initial API use, i mean |
| 14:06 | <annevk> | zcorpan: requesting CORS for a particular origin? Yeah maybe |
| 14:06 | <zcorpan> | yeah |
| 14:08 | <zcorpan> | it would also provide an opt-in if it's not compatible to do OPTIONS * from APIs |
| 14:11 | <wanderview> | annevk: just to clarify... response2 = response1.clone()... response2 should have the same header guard as response 1, correct? |
| 14:12 | wanderview | reboots because windows decided to install updates. |
| 14:12 | <annevk> | wanderview: yup |
| 14:12 | <wanderview> | thanks |
| 14:43 | <tty> | hi all. i have made a top navigation menu that i want to include in two or more apps like wordpress. i want the apps to have the same global navigation. for the moment i have tried copy/paste the navigation html/css/js. i tried putting all js and css on one server and loading the navigation html with jquery enabling CORS. is there a better way to approach this? angularjs? iframes? |
| 15:04 | <jgraham> | annevk: Is it defined somewhere (url)? what the valid syntax of a path is? |
| 15:05 | <jgraham> | Oh yeah |
| 15:05 | <jgraham> | I see now |
| 16:05 | <annevk> | Domenic: bz thinks it's somewhat critical that eventually all consumers get some notification of cancelation |
| 16:05 | <annevk> | Domenic: is that a recognized goal of cancelable promises? |
| 16:08 | <annevk> | dglazkov: thanks for setting it all up! |
| 16:21 | <Domenic> | Krinkle|detached: MikeSmith: https://www.npmjs.com/package/parse5 has a streaming mode and at least in its normal mode passes all the parser tests. Don't know the details, but it might be interesting. |
| 16:22 | <Domenic> | annevk: yeah, I'm unsure on Task<T> being worth the trouble. Although, duck-typing would let most consumers treat them identically to promises. |
| 16:22 | <Domenic> | Future<T> seems much less interesting to me, but that's an age-old debate |
| 16:23 | <Domenic> | annevk: in practice we haven't found a use case for notifying consumers of cancellation |
| 16:23 | <Domenic> | everyone just filters out the cancellation rejection and ignores it. |
| 16:28 | <MikeSmith> | Domenic: niceーthanks |
| 16:29 | <annevk> | Domenic: okay, I should ask bz |
| 17:42 | <annevk> | Domenic: so bz brings up the case of the end user terminating fetches by hitting something in the UI |
| 17:43 | <annevk> | Domenic: is that cancel-like or network-error-like? |
| 17:43 | <Domenic> | annevk: that sounds network-error-like to me. |
| 17:43 | <annevk> | Domenic: what about killing a worker or navigating away from a page? |
| 17:43 | <annevk> | Domenic: okay, it currently is that way |
| 17:43 | <Domenic> | all of those cases sound the same as if the server just immediately cut off the connection |
| 17:44 | <annevk> | Domenic: but from the other consumers of the promise, how is one consumer cutting off the connection any different? |
| 17:44 | <Domenic> | annevk: yeah, multi-consumer is the problem indeed, hmm. |
| 17:45 | <annevk> | promise.onterminate trololol |
| 17:47 | <Domenic> | maybe .terminate({ rejectWith: }) provides the answer |
| 17:47 | <Domenic> | browsers do .terminate({ rejectWith: NetworkError }) |
| 17:47 | <Domenic> | but most users do .terminate() |
| 17:49 | <TabAtkins> | I said that was a nice model. ^_^ |
| 17:50 | <annevk> | Yeah, I guess the question is whether we should start with it or introduce it when it becomes a pain point |
| 17:53 | <Domenic> | yeah i was kind of hoping we would start with .terminate() and then find out we never needed { rejectWith } |
| 19:34 | <Krinkle> | Domenic: Thanks :) |
| 22:19 | <caitp-> | are webidl attributes supposed to be configurable? |
| 22:19 | <caitp-> | like, in general |
| 22:19 | <heycam> | yes, in general |
| 22:27 | <caitp-> | hm, jsc does some weird stuff |
| 22:30 | <TabAtkins> | caitp-: Yes it does, but also note that WebKit/Blink put attributes in the wrong place. They're placed on the object, when WebIDL says they should be getter/setters on the prototype. |
| 22:31 | <caitp-> | i heard there was some progress on that, wasn't there? |
| 22:32 | <TabAtkins> | Yeah, we keep trying. |
| 22:48 | <gsnedders> | rewriting test harnesses has to be my least fun hobby ever |
| 22:50 | <espadrine> | I'm puzzled by window.location.hostname outputting IPv6 hostnames without the brackets. |
| 22:55 | <gsnedders> | espadrine: where's your sense of logic? |
| 22:55 | <espadrine> | let me put it at the door ☺ |
| 23:39 | <MikeSmith> | about the fact that Blink and WebKit don't conform to the WebIDL requirement to expose DOM attributes as getters/setters of prototypes, what real-world differences in practice does that make for web developers? |
| 23:40 | <MikeSmith> | as far as how devs actually program to the APIs |
| 23:40 | <MikeSmith> | I guess it at least affects the case where somebody's monkey-patching the prototype? |
| 23:41 | <MikeSmith> | or not really? |
| 23:42 | <MikeSmith> | anyway it doesn't seem like that difference is a pain point for web devs to the point where any have taken time to complain about it |
| 23:44 | <MikeSmith> | so I wonder what real problems if any it's causing in practice |
| 23:50 | <Domenic> | MikeSmith: yes it affects monkey patching pretty drastically |
| 23:50 | <Domenic> | e.g. the shadow DOM polyfill has to monkey-patch all the constructors to produce instances with overwritten methods, instead of just monkey-patching the methods directly |
| 23:50 | <Domenic> | and even that doesn't catch instances that come from the browser itself |
| 23:51 | <Domenic> | so you have ot patch all methods that access e.g. Nodes and patch those nodes before the author sees them |
| 23:51 | <Domenic> | it's pretty disastrous |
| 23:51 | <Domenic> | (and slow) |
| 23:55 | <MikeSmith> | oh |
| 23:55 | <MikeSmith> | Domenic: thanks yeah I see now |
| 23:56 | <MikeSmith> | so I guess I'm now a bit surprised that more polyfill/library authors haven't complained about this more |
| 23:57 | <MikeSmith> | or maybe they have and I just wasn't paying attention |
| 23:57 | <smaug____> | now we need to convince only webkit to handle attributes properly |
| 23:57 | <MikeSmith> | anyway I guess the other elephant in the room on this is what plans does the WebKit team have if any for fixing this in WebKit |
| 23:57 | <MikeSmith> | smaug____: coke jinx |
| 23:59 | <MikeSmith> | smaug____: I wonder if there's even an open WebKit bug for it |