| 05:17 | <foolip> | Hixie: sorry, I was not around, but I'll check your fix |
| 05:18 | <foolip> | Hixie: I'm in UTC+7 (Vietnam) now so I'll seldom be online when you are |
| 10:25 | <zcorpan> | should DOMException have [Exposed] also? annevk-cloud__ heycam|away |
| 10:57 | <annevk> | zcorpan: DOMException will be defined as part of IDL |
| 10:57 | <annevk> | zcorpan: in terms of JavaScript |
| 10:59 | <annevk> | hmm not being logged |
| 13:16 | <annevk> | oh, is |
| 13:20 | <zcorpan_> | annevk: ok. could you put in a note saying that the plan is to have it available in workers? |
| 13:25 | <annevk> | What's the rush? |
| 13:25 | <annevk> | Is [Expsosed] even defined for non-interface things? |
| 14:03 | <MikeSmit1> | about https://www.w3.org/Bugs/Public/show_bug.cgi?id=24480 maybe we should add back the "Web developer view" button |
| 14:03 | <MikeSmit1> | or "Hide UA implementation details" or whatever it was called |
| 14:05 | <MikeSmit1> | because the commenter appears to be perturbed about the "run synthetic click activation steps" algorithm being in the section that gives info about the various types of content (flow, phrasing, etc.) |
| 14:06 | <MikeSmit1> | and because the experiment of providing a separate "Developer Edition" spec doesn't appear to have become a huge success |
| 14:08 | <annevk> | It hasn't? |
| 14:08 | <annevk> | People rave about it on Twitter quite often |
| 14:08 | <annevk> | developers.whatwg.org that is |
| 14:09 | <MikeSmit1> | really? |
| 14:09 | <MikeSmit1> | I guess I'm just out of touch |
| 14:10 | <MikeSmit1> | and personally I really prefer Hixie's styling to the styling in that developer version |
| 14:10 | <MikeSmit1> | I find that developer version harder to read |
| 14:11 | <Ms2ger> | Habit? :) |
| 14:13 | <annevk> | MikeSmit1: also, the person giving feedback in that bug is zcorpan, he's well aware of all those things |
| 14:13 | <MikeSmit1> | eh? |
| 14:13 | <Ms2ger> | "The MathML3 DTD has been updated" |
| 14:13 | <Ms2ger> | Good that someone is doing useful work |
| 14:13 | <MikeSmit1> | annevk: zcorpan filed that bug? |
| 14:14 | <MikeSmit1> | oh yeah I see he did |
| 14:30 | <zcorpan_> | MikeSmith: i filed it because of https://www.w3.org/Bugs/Public/show_bug.cgi?id=24473 |
| 14:31 | MikeSmith | loooks |
| 14:31 | <MikeSmith> | ah yeah |
| 14:33 | <Domenic_> | I <3 the developer version and refer people to it often |
| 14:33 | <zcorpan_> | annevk: no rush but it might help test writers an implementers when deciding what self.DOMException should be in workers :-) |
| 14:34 | <annevk> | zcorpan_: what is self.Error in a worker? |
| 14:35 | <annevk> | I suspect we're basically waiting for heycam to recover from jetlag at this point |
| 14:35 | <annevk> | Unless he went somewhere else after Seattle |
| 14:38 | <zcorpan> | annevk: it's a function |
| 14:38 | <zcorpan> | annevk: everything defined in JS is available in workers i think |
| 14:39 | <Ms2ger> | I would assume that, yes |
| 14:39 | <annevk> | So http://people.mozilla.org/~jorendorff/es6-draft.html#sec-%realm%.prototype.eval lacks a hook for CSP |
| 14:39 | <annevk> | Domenic_: should I just file a bug against JS for that? |
| 14:47 | Ms2ger | wonders how chromium people look at diffs |
| 14:52 | <annevk> | I filed https://bugs.ecmascript.org/show_bug.cgi?id=2494 |
| 15:24 | <Domenic_> | annevk: interesting. might be worth bringing in dave to the conversation since i think he's heading up the realm work. |
| 15:24 | <annevk> | Domenic_: added dherman |
| 15:36 | <annevk> | Domenic_: I'm curious if there's more such trickery |
| 15:37 | <Domenic_> | annevk: I think in pure ES5, eval and Function are the only eval-er. |
| 15:37 | <Domenic_> | ES6 adds Realm and GeneratorFunction; it might add some stuff in Loader but I think that was all encapsulated by Realm. |
| 15:37 | <annevk> | Domenic_: there's structured clones of course which apparently are handled in the JS engine already |
| 15:37 | <annevk> | Seems bad to set these precedents that specification authors can just hack the JS engine on the side, although you wouldn't want to gate everything on TC39 either |
| 15:38 | <Domenic_> | yeah... |
| 15:40 | <annevk> | Oooh, so Realm needs a flag too for CSP |
| 15:44 | <Domenic_> | Loader too http://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.eval |
| 15:44 | <Domenic_> | Hmm both reference IndirectEval but that doesn't exist according to Ctrl+F |
| 15:44 | <Domenic_> | seems like this stuff is still WIP |
| 15:45 | <annevk> | Note that I also filed a complaint with those responsible: http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/ |
| 15:47 | <annevk> | At some point we need some kind of low-tolerance policy for forking someone else their algorithm in your own specification without prior coordination |
| 15:47 | Ms2ger | looks for someone with experience with the v8 api |
| 15:49 | ondras | has some |
| 15:49 | <ondras> | being the author of an embedding alternative to node |
| 15:49 | <ondras> | Ms2ger: ^ |
| 15:49 | <ondras> | but I have to leave soon, so I might reply later |
| 15:59 | <gsnedders> | Domenic_: Function isn't relevant as an eval-er in ES5, given it's creates a new scope whose containing environment is the global-scope. |
| 15:59 | <gsnedders> | (likewise indirect eval) |
| 16:02 | <Domenic_> | gsnedders: I imagine CSP still cares. |
| 16:03 | <Domenic_> | if CSP doesn't care about indirect eval then it won't care about Loader or Realm either |
| 16:03 | <annevk> | It cares |
| 16:04 | <Domenic_> | annevk: changes to the URL spec seem pretty great. |
| 16:04 | <annevk> | I like my new advice section |
| 16:04 | <annevk> | I made it up in bed in SF and then forgot about it for a while |
| 16:04 | <gsnedders> | Domenic_: Yeah. CSP cares. But CSP also needs to care about things at the DOM level to do what it needs. |
| 16:05 | <gsnedders> | Domenic_: (e.g., var s = document.createElement("script"); s.textContent = "blah"; document.documentElement.appendChild(s); or whatever) |
| 16:05 | <annevk> | And fetch. CSP affects all. |
| 16:06 | <gsnedders> | This would be so much less confusing if I weren't in two conversations about two different CSPs. :) |
| 16:06 | <Domenic_> | annevk: still not sure i get "scheme data." An example or two of the decomposition might be useful. |
| 16:06 | <annevk> | Domenic_: data:text/html,teehee |
| 16:07 | <annevk> | text/html,teehee is scheme data, but noted |
| 16:07 | <Domenic_> | ahhh interesting. |
| 16:07 | <zcorpan> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=580234 is INVALID now right? |
| 16:07 | <annevk> | zcorpan: yeah I guess |
| 16:07 | <annevk> | zcorpan: depending on what UAs align on for the URL parser |
| 16:08 | <annevk> | zcorpan: but yeah, that bug won't be used for aligning that |
| 16:08 | <Ms2ger> | zcorpan, as long as you have a test :) |
| 16:09 | <annevk> | Domenic_: most of this rewrite was done to fix blob URLs btw |
| 16:10 | <annevk> | Domenic_: where we introduce a component called "object" that holds a structured clone of the Blob the scheme data of a "blob" URL points to, which is then used when fetching... |
| 16:10 | <Domenic_> | ah interesting... it might be worth pointing out in a non-normative section how blob URLs are indeed covered by the spec. I didn't even think of them, but it's great that they are covered. |
| 16:11 | <zcorpan> | Ms2ger: http://web-platform.test:8000/websockets/constructor/017.html |
| 16:11 | <annevk> | Well, I need to write that integration bit still :-) |
| 16:11 | <annevk> | It's going to be fairly explicit once everything is done |
| 16:12 | <Ms2ger> | zcorpan, nice how I can just click that link now :) |
| 16:12 | <zcorpan> | hmm i don't get a result for that test |
| 16:13 | <Ms2ger> | I get all passes |
| 16:20 | <zcorpan> | yeah now i do too. had messed up my working copy |
| 16:21 | <TabAtkins_> | Domenic_: What were the Promise changes that were decided against? |
| 16:23 | <TabAtkins_> | Domenic_: I assume it was "welp, monads suck". |
| 16:23 | <TabAtkins_> | Also, presented without comment: http://lists.w3.org/Archives/Public/www-style/2014Feb/0024.html |
| 16:23 | <Ms2ger> | I see the stack of links |
| 16:23 | <Ms2ger> | I see the sender |
| 16:24 | Ms2ger | closes tabs |
| 16:24 | <Ms2ger> | *tab |
| 16:24 | <Ms2ger> | And not you |
| 16:24 | <TabAtkins_> | Good job, you passed the test. |
| 16:25 | <Ms2ger> | TabAtkins_, do you know if there's a way to look at a side-by-side diff of a blink revision? |
| 16:25 | <TabAtkins_> | No, I don't know. |
| 16:25 | TabAtkins_ | is not much of a Blink dev. |
| 16:26 | Ms2ger | looks for blink devs, then :) |
| 16:28 | <Domenic_> | TabAtkins_: yeah that's what it sounds like. Minutes coming out soon... |
| 16:29 | <TabAtkins_> | I hate that the existing shitty promises led to monadic promises seeming like a complication rather than a simplification, as they got bolted on to the side. |
| 16:30 | <TabAtkins_> | And it means that we *will* have the possibility of problems with async maps, as we discussed in the Service Worker f2f. :/ |
| 16:30 | Ms2ger | sees monads, tunes out |
| 16:30 | <TabAtkins_> | Le sigh. I also fucking hate the word "monad", because it's a crappy nonsense word that looks confusing. |
| 16:30 | <TabAtkins_> | Like using "Functor" for "Mappable". |
| 16:31 | <jgraham> | "monad" just sounds like a lonely nomad |
| 16:31 | <jgraham> | Which isn't at all scary |
| 16:32 | <TabAtkins_> | But anyway, if we're stuck with crappy promises, it means you'll never be able to get a useful API out of an async map. |
| 16:32 | <Ms2ger> | I also tune out on "responsive images" :) |
| 16:32 | <TabAtkins_> | Because it'll inherently mix up "failed because the key wasn't in the map" and "key was in the map, but it was for a failed promise". |
| 16:32 | <jgraham> | I thought there was a whole debate in which you had some way of getting monadic promises to coexist with whatever other people liked |
| 16:32 | <TabAtkins_> | You'll have to handle both of these completely separate cases in the same .then() branch. |
| 16:33 | <TabAtkins_> | jgraham: Yes, there was. But Domenic_ is making it sound like people gave up on that at last week's tc39 meeting. |
| 16:33 | <TabAtkins_> | I'll wait for minutes, I guess. |
| 16:34 | <TabAtkins_> | (Getting them to coexist is easy - it's basically equivalent to saying that arrays can nest, but we'll also give you an iterator that moves through the flattened array instead so you can pretend they don't.) |
| 16:34 | <jgraham> | TabAtkins_: There are certain choice words that you should use when people try to make decisions at face to face meetings like that |
| 16:34 | <Ms2ger> | This is why you're careful with "may": https://twitter.com/aloria/status/429375273625452544 |
| 16:34 | <TabAtkins_> | (Actually it's exactly equivalent to that, because MONADS.) |
| 16:37 | <TabAtkins_> | jgraham: I also see the word "gonad" when I write "monad", which isn't great either. |
| 16:39 | <annevk> | Tentative plan: recast current parser as base URL parser. Introduce new URL parser that invokes that and adds blob magic. Allows rest of the world to pretend blobs don't exist, makes it likely web standards pick the right parser. |
| 16:39 | <gsnedders> | You should just follow SPJ's view that it is misnamed and should instead be a "warm fuzzy thing", because people won't be scared of it. |
| 16:40 | <TabAtkins_> | gsnedders: It's not even a *thing*, though. It's an interface or typeclass or abstract base class or trait or whatever-the-hell your language calls "here's some behavior that multiple things can implement". |
| 16:41 | <TabAtkins_> | Giving it a "thing" name confused me when I first started learning about it, and I'm sure messes with a lot of other people too. |
| 16:45 | <jgraham> | Well the same applies to "algebra" or something; it's the name for a set of rules that allow computation. Actually "algebra" is worse because it's the general name to mean any set of rules that allow some kind of abstract computation. |
| 16:45 | <jgraham> | But I'm not sure that people find algebra confusing because of the name |
| 16:46 | <jgraham> | They find it confusing because it's hard to internalise a system of rules and the consequences of those rules |
| 16:48 | <TabAtkins_> | And yet they find it easy to internalize "Mappable" as being "a thing with .map()". |
| 16:48 | <TabAtkins_> | Or "Iterable" as being "a thing I can iterate". |
| 16:48 | <Ms2ger> | Or "Monad" as being "a thing I can moon" |
| 16:48 | <TabAtkins_> | "Monad" is just a terrible name for "Map-then-Flatten-able". (Which, granted, is also a terrible name.) |
| 16:49 | <TabAtkins_> | You get it, Ms2ger! |
| 16:49 | <jgraham> | Well iterable is easy because there is only a single operation which is familiar from other contexts |
| 16:49 | <TabAtkins_> | Monad just combines two extremely familiar operations - map and flatten. |
| 16:50 | <Ms2ger> | Flatten? |
| 16:50 | Ms2ger | isn't sure he's ever had to use it |
| 16:51 | <TabAtkins_> | You've never flattened an array? |
| 16:52 | <Ms2ger> | Not that I can remember |
| 16:52 | <Ms2ger> | I certainly wouldn't say its on the same level as map |
| 16:52 | <TabAtkins_> | All right. Yeah, I grant that it's less common than "map", but still not anything exotic. |
| 16:53 | <Ms2ger> | So it's a map that can push multiple values, or what? |
| 16:53 | <TabAtkins_> | In terms of arrays and other containers, yeah, that's it. (Or zero values.) |
| 16:54 | <TabAtkins_> | "Flatten" ends up being a really generic concept that gets stretched all over the place, but for the most common cases, it's just that. |
| 16:54 | <Ms2ger> | Fascinating |
| 16:54 | <gsnedders> | Yay, back on this side of the split! |
| 16:54 | <TabAtkins_> | (It's just "how do I turn Thing<Thing<Foo>> into Thing<Foo>?".) |
| 16:54 | <annevk> | You want to avoid the word monad |
| 16:54 | <Ms2ger> | That may well be the first time someone managed to explain monads in an understandable way |
| 16:54 | <TabAtkins_> | Ms2ger: BLAME HASKELL |
| 16:55 | <Ms2ger> | Sure, I'll blame haskell for a great good |
| 16:56 | <gsnedders> | TabAtkins_: A monad is just a definition of a sequence of computational actions. It is pretty much a thing that can do anything. |
| 16:56 | <TabAtkins_> | Monads are among the simplest things I can describe in terms of generic behaviors, but they've built up this terrible mystique and also everyone's crap at explaining them for no reason I can fathom. |
| 16:56 | <TabAtkins_> | gsnedders: So you're also one of the people who's crap at explaining them. ^_^ |
| 16:56 | <Ms2ger> | Clearly :) |
| 16:56 | <TabAtkins_> | Jumping straight to the "but 'flatten' is really just a way of describing computational sequencing!" is why everyone hates monads. |
| 16:57 | <TabAtkins_> | You've got a Thing which contains a value. You define .map() so functions can work on the value without caring about the Thing. But sometimes your functions want to return a Thing too, and now you've got nested Things. Define a way to flatten a nested Thing into a single Thing, and you've got monads. |
| 16:59 | <gsnedders> | TabAtkins_: It's not even any behaviour. |
| 16:59 | <gsnedders> | TabAtkins_: It's not really a type. |
| 16:59 | <TabAtkins_> | Yes, it's a typeclass. |
| 16:59 | <TabAtkins_> | Or interface, or trait, or ABC. |
| 16:59 | <TabAtkins_> | Just like "Mappable" isn't a type. |
| 16:59 | <TabAtkins_> | You don't inherit from Mappable. |
| 17:00 | <gsnedders> | A map is a perfectly common name in category theory for functors. :P |
| 17:00 | <gsnedders> | TabAtkins_: :) |
| 17:01 | <gsnedders> | TabAtkins_: It's hard to explain *because* it's so abstract. |
| 17:01 | <astearns> | monads are living mirrors of the entire universe |
| 17:01 | <astearns> | (I only ever knew the philosophical term) |
| 17:01 | Ms2ger | puts astearns on the list too |
| 17:02 | <TabAtkins_> | gsnedders: Only if you're trying to explain it the most abstract terms. Explain it in concrete terms, same as .map(), and nobody gets lost. Let them build up to the abstract shit later, after they've gotten a hold on the most useful forms of it. |
| 17:03 | <TabAtkins_> | Most people don't need to know that functions are containers for their return value, and thus are monads, with composition being the flattening operation. |
| 17:03 | <TabAtkins_> | Sorry, composition is the mapping operation. |
| 17:03 | <TabAtkins_> | Flattening is just calling the return value with the same args again. |
| 17:04 | <jgraham> | TabAtkins_: Your way gives false insight though |
| 17:04 | <TabAtkins_> | jgraham: No, it gives useful insight. All learning goes from concrete to abstract, and most people are actually totally fine with staying at some level of concreteness. |
| 17:04 | <jgraham> | You take something that people already understand (lists) |
| 17:05 | <jgraham> | And then you say "look this thing is an example of X, so now you understand X" |
| 17:05 | <TabAtkins_> | Yes. |
| 17:05 | <jgraham> | But they don't. They understand what they understood to begin with. |
| 17:05 | <TabAtkins_> | For most purposes, you *do* understand X. |
| 17:06 | <jgraham> | From your example I couldn't tell you whether any non-list thing was a monad |
| 17:06 | <TabAtkins_> | Specifically, for the purpose of stopping remarks like "sees monads, tunes out", when we're not doing anything that needs more than that basic understanding. |
| 17:06 | <TabAtkins_> | jgraham: From my example, no. From my accompanying explanation (map, then flatten), you can. |
| 17:07 | <jgraham> | TabAtkins_: "map then flatten" still doesn't tell me anything much |
| 17:07 | <TabAtkins_> | You map, then you flatten. What's there to tell? |
| 17:07 | <TabAtkins_> | If you map and end up with a nested Thing, you flatten back to a single Thing. |
| 17:08 | <TabAtkins_> | It's not complicated. Don't try to make it so. |
| 17:08 | <jgraham> | I suspect you are taking people from "thing I don't understand" to "thing that TabAtkins_ keeps insisting is easy and to do with lists, but I don't understand and therefore I am too stupid to understand" |
| 17:08 | <TabAtkins_> | Do you understand "turn a nested Thing<Thing<value>> back to Thing<value>", and how flattening arrays is an example of that? |
| 17:09 | <jgraham> | TabAtkins_: Sure. For the record, I don't claim to have a good grasp of this, but I am slightly above the level at which I have given examples of how people will not understand |
| 17:10 | <TabAtkins_> | That's literally all you need to understand for most monads in practice. If you've got a class with a .map() method, and a .flatten() method that will turn it from being nested to being flat, you're good. |
| 17:11 | <gsnedders> | Also, "most functions in most languages are actually monads". |
| 17:11 | <jgraham> | TabAtkins_: So, for example, one of the things that "everyone knows" about Monads is that Haskell uses them for IO (this is small values of "everyone", I admit). But it is entirely unclear from your example how monads work for that. Or for many of the other things that they are used for |
| 17:11 | <jgraham> | It is also very unclear why one would want to make one's own code monadic |
| 17:12 | <TabAtkins_> | Monads for IO are one of those abstract things that you dont' need to know to understand monads. |
| 17:12 | <TabAtkins_> | jgraham: Sure, that takes a few (easy, concrete) examples to show. |
| 17:12 | <TabAtkins_> | Arrays (and other containers), Option types, and you're pretty much good. |
| 17:13 | <TabAtkins_> | The IO monad leverages the "flatten is just a way to sequence computations" abstraction that is way above most uses of monads. |
| 17:16 | <jgraham> | I'm not sure that map/flatten is very obvious for maybe. |
| 17:18 | <jgraham> | (which is about the most trivial example) |
| 17:18 | <mathiasbynens> | Domenic_: does http://domenic.me/aplus-tests-against-the-browser/ match what’s in ES6 spec draft completely? |
| 17:19 | <TabAtkins_> | Sure, it's the first step outside of the base "container" concrete examples. |
| 17:19 | <TabAtkins_> | But it's easy to show - a Maybe either holds a value, or holds nothing. When you map, you either map the value and return a new Maybe holding the return value, or just return an empty Maybe again. |
| 17:20 | <Domenic_> | mathiasbynens: it matches a subset of the ES6 spec. |
| 17:20 | <TabAtkins_> | If you have nested Maybes (because your mapped function also returned a Maybe), then you flatten a Maybe<Maybe<val>> into just a Maybe<val>, and a Maybe<Nothing> into a Nothing. |
| 17:20 | <mathiasbynens> | Domenic_: thanks for confirming |
| 17:22 | <TabAtkins_> | (Maybe can be implemented as an Array that holds either 0 or 1 values, where its .map() is Array.map(), and it's .flatten() is Array.flatten().) |
| 17:32 | <dglazkov> | good morning, Whatwg! |
| 17:35 | <aleray> | hi, using html5lib python I would like to clean up a webpage. For instance I would like to remove (including it's content) the script tags |
| 17:35 | <aleray> | I'm confused between filters, tokenizer and sanitizer |
| 17:35 | <aleray> | what is the difference? |
| 17:51 | <gsnedders> | aleray: The honest answer is the sanitizer API is a mess and needs completely changed. If you want something more stable, Bleach may or may not be suitable for your purposes. |
| 17:52 | <jgraham> | (Bleach uses html5lib internally) |
| 17:52 | <gsnedders> | (But provides a stable API, and will magically stay up-to-date with html5lib when all the breakage happens there.) |
| 17:53 | <jgraham> | But basically the tokenizer takes the tokens produced by reading the HTML before they are built into a tree (start-tag, end-tag, etc.) |
| 17:53 | <jgraham> | Using this for sanitising is rather broken and will not be supported in the future |
| 17:53 | <gsnedders> | s/sanitising/anything/ |
| 17:54 | <jgraham> | Using it for treebuilding is just fine :) |
| 17:54 | <jgraham> | A filter is something that runs on the output of a treewalker. A treewalker is something that takes a parsed HTML tree and produces a series of events like start-tag, end-tag, etc. that would reconstruct that tree |
| 17:55 | <gsnedders> | Some filters currently operate (and only work) on the tokeniser. Such as the sanitizer. |
| 17:55 | <jgraham> | So it's a bit like a tokenizer with different input |
| 17:55 | <jgraham> | No, no |
| 17:55 | <jgraham> | The sanitiser tries to operate on both |
| 17:55 | <jgraham> | Badly |
| 17:56 | <gsnedders> | But only works on the tokenizer. It will *always* fail with a tree-walker. |
| 17:56 | <gsnedders> | Though it tries to work with it. |
| 17:56 | <jgraham> | A serializer takes the output from a tree walker, possibly after it passed though a filter, and writes it as markup |
| 17:57 | <jgraham> | So the setup you want is tokenizer -> treebuilder -> treewalker -> sanitizer filter -> serializer |
| 17:57 | <jgraham> | But that doesn't wuite work right now |
| 17:57 | <jgraham> | *quite |
| 17:57 | <gsnedders> | I think it might if the document has no attributes. |
| 17:57 | <jgraham> | (the first two parts are just called "parser") |
| 17:58 | <gsnedders> | On the other hand, the probability of having a document with no attributes… :) |
| 18:03 | <annevk> | http://esdiscuss.org/topic/specification-styles#content-11 Well, anti-IDL camp, curious to see your move :-) |
| 18:07 | <annevk> | Domenic_: you're missing that there's associated state with running a script |
| 18:08 | <Domenic_> | annevk: I don't get it. What state. Where is it captured. |
| 18:08 | <Domenic_> | Is this another thing where DOM specs have forked ES execution semantics? |
| 18:08 | <Domenic_> | so that [[Call]] takes some invisible parameter in DOM land? |
| 18:08 | <annevk> | Domenic_: it's script thread state |
| 18:08 | <annevk> | Domenic_: no, it's just some global associated with the current task |
| 18:08 | <annevk> | Domenic_: ES is just not complete in its task description |
| 18:08 | <Domenic_> | so that state isn't captured in the ES spec anywhere? |
| 18:09 | <aleray> | gsnedders, sorry I missed your answer. |
| 18:09 | <annevk> | Domenic_: it doesn't have tasks |
| 18:09 | <aleray> | I'm actually using bleach, but I don't find how to remove a tag and its content (eg. script tags) |
| 18:10 | <Domenic_> | .then, and ES in general, does not specify or care about this DOM thing. It just invokes [[Call]]. If window.postMessage.bind(...) has a special [[Call]] that uses some global state, then it needs to be specified by window.postMessage; it's not the promise spec's job |
| 18:11 | <aleray> | gsnedders, so if I don't want to use bleach, I'd rather use filters right? |
| 18:15 | <annevk> | Domenic_: ES5 doesn't queue tasks |
| 18:46 | <SimonSapin__> | annevk-cloud: I don’t really like the idea of "initial value" for the components of URL objects |
| 18:47 | <SimonSapin__> | or rather, baking mutability in the standard |
| 18:57 | <SimonSapin__> | annevk-cloud: Should the model also define constraints like "in the ASCII range" or "ASCII digits" (port) ? |
| 19:06 | <SimonSapin__> | annevk-cloud: Also, was it deliberate to go with a "flat" model where every component always exists, rather than expressing in the model constraints like "scheme data is exclusive with (user, password, host, port, path)"? https://github.com/SimonSapin/rust-url/blob/1db0239ec2c2cfcee5b7fb6e7402571844cb2135/url.rs#L33 |
| 19:45 | <jsbell> | TabAtkins_: Any motion on (or interest in) EventStream since last April? |
| 19:56 | <TabAtkins_> | jsbell: Nope. |
| 20:25 | <SimonSapin> | annevk-cloud: only file URLs can have a null host, right? |
| 21:16 | <smaug____> | dglazkov: I assume with http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.html you mean that blink will ship something but changes are still expected |
| 21:16 | <smaug____> | to shadow dom handling |
| 21:16 | <smaug____> | (like event propagation and what not) |
| 21:16 | <dglazkov> | smaug____: yep |
| 21:16 | <smaug____> | and you just want some css stuff to be a bit more stable |
| 21:16 | <TabAtkins_> | But syntax has a habit of freezing much faster than those things. |
| 21:16 | <TabAtkins_> | Yeah. |
| 21:17 | <dglazkov> | smaug____: also CSS stuff is hard to tweak with polyfills :-\ |
| 21:17 | <smaug____> | sure |
| 21:17 | <Domenic_> | Does blink have plans to implement <style scoped> independent of shadow DOM? |
| 21:18 | <TabAtkins_> | It's not a priority right now, I don't think. |
| 21:18 | <dglazkov> | there was an implementation in there, but nobody watned it |
| 21:18 | <Domenic_> | sad |
| 21:18 | <smaug____> | It is just that http://lists.w3.org/Archives/Public/www-style/2014Feb/0036.html used rather strong and generic language |
| 21:19 | <smaug____> | (I hadn't noticed those emails but bz mentioned in moznet#content) |
| 21:19 | <TabAtkins_> | smaug____: Sorry for the generic language - I was addressing the CSSWG, so "API" was understood to be "CSS API". |
| 21:19 | <Ms2ger> | CSS has APIs? :) |
| 21:41 | <yoav> | zcorpan: You around? |
| 21:41 | <zcorpan> | yes |
| 21:41 | <yoav> | Regarding the <img src crossorigin> stuff discussed on blink-dev |
| 21:42 | <yoav> | I can't find a browser that complies with the spec |
| 21:44 | <yoav> | zcorpan: see http://jsbin.com/OnOkuQE/1 |
| 21:45 | <yoav> | Can't find a browser where bla.gif is requested with an "origin" header |
| 21:45 | <Hixie_> | so... |
| 21:45 | <Hixie_> | did ES kill the convenience type "ArrayBufferView"? |
| 21:50 | <zcorpan> | yoav: quite possible yeah. also i don't see the origin header in either request in firefox, but 'crossOrigin' in new Image() returns true |
| 21:51 | <yoav> | Hmm |
| 21:51 | <yoav> | Firefox does fail to add "origin" on both |
| 21:51 | <yoav> | Chrome adds it to bla2.gif, as well as IE |
| 21:52 | <jcgregorio> | Hixie_, annevk-cloud: per our discussion on Friday about Path/Path2D, this should work in Safari http://goo.gl/2uY5aA |
| 21:52 | <yoav> | I'm guessing Opera would too, but I can't test it, since there's no Linux version :P |
| 21:52 | <Hixie_> | wtf is "c.currentPath" |
| 21:53 | <Hixie_> | jcgregorio: yeah, ok, i didn't realise the safari implementation had no bearing on reality |
| 21:53 | <Hixie_> | jcgregorio: let's rename it! |
| 21:53 | <jcgregorio> | that was a proposed attribute, it's in Webkit, and behind a flag in blink |
| 21:53 | <yoav> | zcorpan: The point is, the part in the standard you pointed at regarding "stable state" doesn't seem to be implemented anywhere |
| 21:54 | <jcgregorio> | reading the list it looks like it got shot down, but still |
| 21:54 | <jcgregorio> | ended up implemented |
| 21:54 | <zcorpan> | yoav: right |
| 21:55 | <Hixie_> | jcgregorio: yeah the attribute doesn't make much sense |
| 21:55 | <zcorpan> | yoav: that's bad :-) |
| 21:55 | <Hixie_> | jcgregorio: (hence the result on the list) |
| 21:55 | <Hixie_> | jcgregorio: Path objects are supposed to be just used in arguments to e.g. fill() and stroke() |
| 21:55 | <Hixie_> | jcgregorio: changing the canvas' implied default path (or whatever i called it) is just weird |
| 21:56 | <jcgregorio> | Hixie_: agreed, which is what I'm trying to land in Blink |
| 21:56 | <Hixie_> | jcgregorio: cool |
| 21:56 | <Hixie_> | jcgregorio: if you land it with a different name for Path, like Path2D or CanvasPath or whatever, i'll use whatever name you used |
| 21:56 | <yoav> | zcorpan: Yeah. Not sure what the next step should be. I can open a bug about it,but with it not working in all other browsers, it might be tough |
| 21:57 | <Domenic_> | Hixie_: not sure about "killed" but http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typedarray-objects seems relevant |
| 21:57 | <jcgregorio> | Hixie_: ok |
| 21:57 | <Hixie_> | Domenic_: yeah looks like the spec just dropped that name on the floor, probably didn't realise that a bunch of other specs were depending on it |
| 21:58 | <Hixie_> | Domenic_: i'm introducing a typedef on my side to ease the transition |
| 21:58 | <zcorpan> | yoav: indeed, it seems high risk, but still is easy to argue that the spec's behavior is better for authors |
| 21:58 | <Hixie_> | still no idea what i can do about "ArrayBuffer implements Transferable" though |
| 21:58 | <Hixie_> | i wish the JS spec was more WebIDLy |
| 21:59 | <yoav> | zcorpan: I agree. It's also better for srcset, not just crossorigin |
| 21:59 | <zcorpan> | yoav: <video> already does this (presto follows the spec closely there, not sure about other engines) |
| 21:59 | <zcorpan> | yep |
| 21:59 | <zcorpan> | and picture too |
| 21:59 | <yoav> | yeah |
| 22:02 | <Hixie_> | i wonder if JS still has the concept of a "readonly ArrayBuffer" |
| 22:02 | <Domenic_> | frozen? |
| 22:03 | <Hixie_> | no frozen means all kinds of other crap |
| 22:03 | <Hixie_> | like you can't change its properties |
| 22:03 | <Domenic_> | indeed. |
| 22:03 | <Domenic_> | I guess I don't know what readonly means |
| 22:03 | <Hixie_> | i basically never want frozen in my specs except for the Window and Location objects in cross-origin situations, if then |
| 22:03 | <Hixie_> | read only means "can't mutate underlying data" |
| 22:04 | <TabAtkins_> | So you can still add expandos? |
| 22:04 | <Hixie_> | sure |
| 22:05 | <TabAtkins_> | Yeah, that's a useful definition of it for me, for most purposes. Just that the properties the spec defines can't be altered by userland code. |
| 22:09 | <Hixie_> | i wonder if you can mutate teh data returned by an xhr.response |
| 22:09 | <TheSeeker> | Is the work at http://wiki.whatwg.org/wiki/Adaptive_Streaming just a proposal, or is that able to be implemented immediately? |
| 22:10 | <Hixie_> | given that it starts with "Here is a (rough and incomplete) proposal", i'm going to guess "proposal" |
| 22:14 | <Hixie_> | wow. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2794 |
| 22:14 | <Hixie_> | it's mutable. |
| 22:21 | <TheSeeker> | Hixie_: I was hoping that maybe someone might have implemented some proof of concepts of the idea since 2011, I guess not? :/ |
| 22:21 | <Hixie_> | no idea |
| 22:22 | Hixie_ | doesn't recall seeing this page before |
| 22:22 | <heycam> | zcorpan, annevk-cloud, so do we want to expose DOMException to workers? I guess yes, as there's nothing really DOM-ish about it, and if we have APIs that use DOMExceptions that we then want to expose to workers it would be good not to use a different exception there. |
| 22:22 | <Hixie_> | TheSeeker: (the wiki is more a scratch space for the whatwg, we don't really work on the wiki) |
| 22:22 | <Hixie_> | TheSeeker: (work happens on the mailing list or in bugs, mainly) |
| 22:22 | <Hixie_> | heycam: i throw DOMExceptions on workers, fwiw |
| 22:22 | <heycam> | Hixie_, ok cool, will make it so |
| 22:23 | <zcorpan> | heycam: we already have WebSocket, EventSource, XMLHttpRequest... |
| 22:23 | <Hixie_> | zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24454 is proving to be a pain in the ass to fix btw :-P |
| 22:23 | <heycam> | zcorpan, since DOMException is going to be built in, I'll just make it exposed in all globals |
| 22:24 | <TheSeeker> | I'm trying to work out the best way to get streaming video working over Freenet ... which will require either major changes to Freenet (allowing for range-requests) or some kind of chunked video format where chunks are <= 4 MB each... |
| 22:24 | <zcorpan> | Hixie_: oh, does it affect everything that uses typed arrays? |
| 22:25 | <Hixie_> | yeah |
| 22:25 | <Hixie_> | zcorpan: i'm having to rework all the prose to use the new hooks |
| 22:25 | <zcorpan> | ok :-| |
| 22:25 | <Hixie_> | it had to happen eventually |
| 22:25 | <zcorpan> | heycam: sounds good |
| 22:30 | <TheSeeker> | oh well, I guess I'll start lookign somewhere else, thanks anyway. |
| 22:31 | <Hixie_> | i've really no idea how to use these hooks |
| 22:32 | <Hixie_> | do they really expect the HTML spec to have lots of [[blabla]] %blabla% BlaBla(...) so on in the prose? |
| 22:35 | <Hixie_> | zcorpan: i'm actually going to not bother trying to call the precise hooks. if you think it needs to be more closely defined, then please file a bug saying exactly what you want the spec to say. i can't work out what to say short of making the spec full of ugly things that i'm not convinced would actually improve interop. |
| 22:36 | <zcorpan> | Hixie_: ok i'll have a look tomorrow |
| 22:38 | zcorpan | is a bit surprised <svg>'s content model allows stuff in any order |
| 22:39 | <Hixie_> | structured clone of arraybufferview |
| 22:39 | <Hixie_> | ow |
| 22:41 | <Hixie_> | wtf does https://people.mozilla.org/~jorendorff/es6-draft.html#sec-new-dataview-argumentslist mean |
| 22:43 | <Domenic_> | It's the standard boilerplate for saying that calling new on DataView does the normal thing, not a special thing like it does on e.g. Array |
| 22:44 | <Domenic_> | the meat is in https://people.mozilla.org/~jorendorff/es6-draft.html#sec-dataview-buffer-byteoffset-bytelength and a bit in https://people.mozilla.org/~jorendorff/es6-draft.html#sec-dataview-@@create |
| 22:44 | <Hixie_> | i'm all for making specs be well-defined and all |
| 22:44 | <Hixie_> | but this goes beyond that and reaches a level of obscurity that i can't even dream of achieving. |
| 22:45 | <Domenic_> | it does seem a bit redundant. i can't actually find any examples that are nonstandard. (Array wasn't one of them it turns out.) |
| 22:46 | <Domenic_> | Ah, wow, Object is the exception it seems. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-new-object-argumentslist |
| 22:46 | <Hixie_> | ok, open this: |
| 22:46 | <Hixie_> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data |
| 22:46 | <Hixie_> | and look where it says "ArrayBufferView" |
| 22:46 | <Hixie_> | how do i translate that to match the JS spec? |
| 22:46 | <Hixie_> | i cannot figure it out at _all_ |
| 22:46 | <heycam> | zcorpan, for <title>? |
| 22:47 | <heycam> | zcorpan, it's just like in HTML where <title> can be any child of <head>, doesn't need to be the first or whatever |
| 22:47 | <zcorpan> | heycam: yeah i for some reason expected the descriptive elements to have to come first |
| 22:48 | <zcorpan> | heycam: well html separates <head> stuff from <body> stuff |
| 22:49 | <heycam> | zcorpan, oh you know SVG Tiny 1.2 has more strict author requirements about the position of <title>/<desc> |
| 22:49 | <heycam> | it's not in SVG 2 though (yet? maybe should port some of that wording across) |
| 22:49 | <Domenic_> | Hixie_: https://bugs.ecmascript.org/show_bug.cgi?id=2495 FWIW |
| 22:49 | <Hixie_> | Domenic_: it's not that it's repeated that i find confusing, btw. it's that it's utterly impenetrable. |
| 22:49 | <Hixie_> | Domenic_: i've literally no idea what that means |
| 22:50 | <Domenic_> | oh, well, i'm guessing that's just a matter of ES spec familiarity |
| 22:50 | <Domenic_> | I would translate it this way: |
| 22:50 | <Hixie_> | there's spec familiarity, and then there's the %foo% @@foo [[foo]] Foo() stuff that they use instead of English |
| 22:51 | <Hixie_> | Domenic_: do you have any idea how to translate the above HTML spec prose into JS-compatible prose? |
| 22:51 | <hober> | as a rule of thumb, if Hixie_ doesn't understand your spec prose after multiple reads, your spec is wrong. :) |
| 22:51 | <hober> | sorry, "prose" |
| 22:51 | <Hixie_> | i dunno about wrong, but i could certainly get behind "overly obtuse" |
| 22:52 | <hober> | s/wrong/bad/ then |
| 22:52 | <zcorpan> | heycam: now you made me try to read svg tiny 1.2's relaxng schema :-P |
| 22:52 | <heycam> | zcorpan, sorry |
| 22:53 | <heycam> | zcorpan, it may or may not describe the requirements reflected in the prose, who knows :) |
| 22:53 | <zcorpan> | heycam: i didn't find it in prose so i guessed maybe it just has its content model requirements in the schema |
| 22:53 | <Domenic_> | Hixie_: I see the rough outlines of how to do this. But getting the appropriate references right will take some time. I will work on it later tonight. |
| 22:54 | <heycam> | zcorpan, yeah it might be where I'm remembering it from |
| 22:54 | <zcorpan> | heycam: anyway i think any order seems better |
| 22:54 | <Hixie_> | Domenic_: don't worry about it, it'll become moot when JS takes over defining this stuff |
| 22:54 | <heycam> | zcorpan, ok |
| 22:56 | <Domenic_> | Hixie_: wait, I think it's as simple as: "Let _output_ be %TypedArray%(_input_)" |
| 22:57 | <Domenic_> | Using https://people.mozilla.org/~jorendorff/es6-draft.html#sec-%typedarray%-typedarray |
| 22:57 | <zcorpan> | i sometimes don't understand Hixie_'s spec prose after multiple reads, too. but i think that has more to do with the relevant thing being complex than with the way it is written |
| 22:57 | <hober> | zcorpan: right |
| 22:57 | <Domenic_> | You could change the predicate to "If _input_ has a [[TypedArrayName]] internal slot" as well. |
| 22:57 | <Hixie_> | Domenic_: the underlying buffer is changed by this (to a new buffer that's in the algorithm's "memory") |
| 22:58 | <Hixie_> | Domenic_: i think [[DataView]] is the internal property you're supposed to look for |
| 22:58 | <Domenic_> | Hixie_: I think that matches; %TypedArray% re-allocates a new buffer for its return value |
| 22:58 | <heycam> | "W3C DOM4" |
| 22:58 | <Hixie_> | Domenic_: i don't want it to allocate a new buffer, i need it to use the buffer that was cloned from the original one |
| 22:58 | <Domenic_> | Hixie_: I would bet they come together. The %TypedArray% algorithm does a predicate assert for [[TypedArrayName]] though. |
| 22:59 | <Domenic_> | ahhh |
| 22:59 | <Domenic_> | wow where is that captured in the HTML spec? |
| 22:59 | <annevk-cloud> | Hixie_: there are a bunch of IDL bugs open on integrating with ArrayBuffer and friends, I recommend waiting for that |
| 23:00 | <Hixie_> | Domenic_: it's the result of calling the algorithm recursively |
| 23:00 | <annevk-cloud> | SimonSapin: patches welcome |
| 23:01 | <annevk-cloud> | heycam: yes to workers :) |
| 23:01 | <SimonSapin> | annevk-cloud: Some of it is opinions rather than clear bugs |
| 23:01 | <Domenic_> | Hixie_: which clause gets entered on the recursion? I don't know what the IDL attributes of ArrayBufferViews are |
| 23:01 | <Hixie_> | Domenic_: (if you're cloning the ArrayBuffer, then it'll be cloned and put in the /memory/ variable before you get to this algorithm) |
| 23:02 | <Hixie_> | Domenic_: |
| 23:02 | <Hixie_> | er |
| 23:02 | <Hixie_> | Domenic_: "buffer", primarily |
| 23:02 | <annevk-cloud> | SimonSapin: I agree with some, eg immutable, but not clear how to do it simply |
| 23:02 | <SimonSapin> | annevk-cloud: btw, https://github.com/SimonSapin/rust-url/blob/master/parser.rs now passes your tests, with functional-style code rather than a state machine |
| 23:02 | <Domenic_> | So "If input is an ArrayBuffer object"? |
| 23:02 | <Hixie_> | Domenic_: no, it gets as far as step 1, then returns |
| 23:02 | <Hixie_> | Domenic_: because the buffer is in /memory/ |
| 23:02 | <SimonSapin> | though I found some issues (meaning we need more tests :)) |
| 23:02 | <Hixie_> | Domenic_: the mapping of old buffer to new buffer, that is |
| 23:03 | <Hixie_> | Domenic_: (it's cloned as part of creating the "transfer map" in the postMessage() methods) |
| 23:03 | <Domenic_> | hmm |
| 23:04 | <annevk-cloud> | SimonSapin: cool |
| 23:07 | <zcorpan> | heycam: i think document.title should be strict about using an svg:title child of the root when the root is svg:svg |
| 23:07 | <heycam> | zcorpan, yes I agree. what's the alternative though? |
| 23:08 | <zcorpan> | heycam: alternatives include ignoring the root and return the first html:title or svg:title in the document, for instance |
| 23:08 | <heycam> | zcorpan, ok. but yes selecting the first svg:title child of the root sounds like the right thing to me. |
| 23:09 | <zcorpan> | same on setting, and appending a title to the root if there isn't a title |
| 23:10 | <heycam> | yeah |
| 23:10 | <zcorpan> | and here i started to wonder about <svg>'s content model :-) |
| 23:10 | <Domenic_> | for comic relief http://stackoverflow.com/questions/21405066/is-this-an-ie11-radio-button-rendering-bug-they-look-like-googly-eyes |
| 23:12 | <zcorpan> | optical illusion, heh |
| 23:12 | <annevk-cloud> | Structured clone proposal Dimitry and I wrote was accepted by TC39 last week btw I saw somewhere |
| 23:13 | <annevk-cloud> | So at some point that too should be somebody else their problem |
| 23:13 | <Hixie_> | well, it'll still be my problem for a lot of it, i assume |
| 23:13 | <Hixie_> | i mean, i doubt they're going to actually spec how postMessage() works, for example |
| 23:13 | <annevk-cloud> | You get hooks |
| 23:14 | <Hixie_> | i hope they're better hooks than i get for ArrayBuffer |
| 23:14 | <annevk-cloud> | They are similar in need, no? |
| 23:15 | <Hixie_> | the hooks for ArrayBuffer are incomprehensible |
| 23:15 | <annevk-cloud> | You are hacking around something ES does not define but ES engines have |
| 23:15 | <annevk-cloud> | It has no hooks for the host environment afaict |
| 23:16 | <annevk-cloud> | Anyway, I recommend postponing those issues for a bit |
| 23:17 | <Hixie_> | btw what's the status on the event loop hooks? |
| 23:18 | <Hixie_> | i still haven't heard anything from anyone about that |
| 23:18 | <Hixie_> | which you'd think i'd hear about, since right now i'm the guy speccing the event loop |
| 23:19 | <Domenic_> | https://people.mozilla.org/~jorendorff/es6-draft.html#sec-enqueuetask |
| 23:19 | <Domenic_> | I think the idea was to do a minimal amount of work and leave most of that in your capable hands still |
| 23:20 | <Domenic_> | https://people.mozilla.org/~jorendorff/es6-draft.html#sec-nexttask-result-algorithm-step is probably the most likely to step on your toes, but seems sufficiently small and vague as to not do so that badly |
| 23:21 | <zcorpan> | Hixie_: maybe you can take inspiration from microsoft and close spec bugs claiming optical illusion |
| 23:21 | <Hixie_> | zcorpan: i believe the w3c already uses that kind of approach, so i'll let them be in charge of that |
| 23:22 | <Hixie_> | Domenic_: so should i be invoking this stuff somewhere? |
| 23:22 | <Domenic_> | allen has so many typos... -_- |
| 23:22 | <Hixie_> | seems like EnqueueTask() should invoke a callback on my side so i can add an HTML-spec "task" to an HTML-spec "task queue" to do something useful |
| 23:23 | <Domenic_> | I think the intent is to let the "implementation defined" stuff give control back over to your more-fleshed-out event loop |
| 23:23 | <Domenic_> | e.g. "If all Task Queues are empty, the result is implementation defined." |
| 23:24 | <annevk-cloud> | Note that ES task === HTML microtask |
| 23:24 | <annevk-cloud> | :/ |
| 23:24 | <Domenic_> | I am trying to find how you get *in* to this system though |
| 23:24 | <Domenic_> | yeah that was unnecessarily confusing annevk-cloud |
| 23:24 | <Hixie_> | for some definition of "===" |
| 23:24 | <Domenic_> | in earlier drafts he showed me it said microtask |
| 23:25 | <annevk-cloud> | Hixie_: 😀 |
| 23:25 | <zcorpan> | does the ES event loop know about 'stable state'? |
| 23:25 | <Domenic_> | Ah this is how you get in. "When there is no running execution context and the execution context stack is empty, the ECMAScript implementation removes the first PendingTask from a Task Queue and uses the information contained in it to create an execution context and starts execution of associated Task abstraction operation." |
| 23:26 | <Domenic_> | interestingly that sounds related to "stable state"? |
| 23:27 | <Domenic_> | so e.g. that prose sentence will launch you into something like PromiseReactionTask. Which will then call NextTask when it's done with its stuff. Which when there are no more ES microtasks, will have an implementation-defined result. Which is where things can go back to HTML's control |
| 23:30 | <Domenic_> | I think it would be more friendly if instead of that prose sentence there was some kind of Drain(Micro)TaskQueue operation you could call |
| 23:38 | <Hixie_> | Domenic_: k well... i'll await a bug or e-mail requesting integration with a proposal for how to do it, i guess :-) |