| 07:17 | <annevk> | GPHemsley: for https://bugzilla.mozilla.org/show_bug.cgi?id=791428 you prolly want to find someone to cc that has experience with that code |
| 07:17 | <annevk> | GPHemsley: standards people are not going to be of much help I think ;) |
| 07:34 | <annevk> | hmm, IPv6 parsing in JavaScript is kinda annoying with the 53bit int limit |
| 08:26 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html |
| 08:26 | <MikeSmith> | from Tobie Langel |
| 08:26 | <MikeSmith> | "What's slowing down Mobile Facebook" |
| 08:53 | <smaug____> | ugh |
| 08:54 | <smaug____> | creating nodes in workers and moving them to main thread |
| 08:54 | <smaug____> | the API would become horrible |
| 08:54 | <smaug____> | what if you add event listener to the node in worker |
| 08:54 | <smaug____> | and transfer the node to mainthread |
| 09:07 | <annevk> | what's the context for DOM in workers? |
| 15:32 | <jgraham> | annevk: The facebook mail |
| 15:33 | <jgraham> | They seem to want to do infinite scrolling by preconstructing document fragments in a worker and then cloning them across to the main thread for rendering |
| 15:34 | <jgraham> | It is not obvious to me that this would be faster |
| 15:34 | <jgraham> | But presumably the response to smaug's concern is that such fragments would be dead until inserted into the main document |
| 15:35 | <jgraham> | So scripts would not run, event listeners would not fire, etc. |
| 16:05 | <zewt> | seems like an order of magnitude of complexity that should require an order of magnitude benefit |
| 17:07 | <annevk> | jgraham: oh, I searched that email for node and that yielded nothing |
| 17:24 | <jwalden> | dear lazywhatwg, does anyone know offhand what the document.all property looks like in Opera? a plain old object, an object that pretends to be falsy, an object that compares == to undefined/null (but not ===), something else? |
| 17:30 | <annevk> | falsy iirc |
| 17:47 | <jwalden> | interestingly, in Opera it seems document.all === undefined |
| 17:47 | <jwalden> | even thought it's an object |
| 17:48 | <jwalden> | jsc at least has == undefined but !== undefined |
| 17:50 | <jgraham> | jwalden: Gecko also has === undefined, no? |
| 17:51 | <jwalden> | jgraham: Gecko is very funky in how it does things right now |
| 17:51 | <jwalden> | jgraham: if you can manage to get the document.all value as an object, it will not be === undefined |
| 17:52 | <jwalden> | roughly speaking there is a heuristic that looks at bytecode patterns and decides whether the pattern represents an attempt to "detect" whether a property exists |
| 17:53 | <jwalden> | well, the heuristic applies to all property accesses, including ones not directly implemented in script, but it's roughly informed by whatever the current script evaluation context is |
| 17:54 | <jwalden> | I'm hoping to remove it in favor of the undefined-looking mechanism right now, on the basis of it being so much less invasive and impossible to implement around |
| 17:55 | <jwalden> | arguments for compatibility probably help with that to some extent |
| 17:55 | <jwalden> | rather, arguments that doing so increases compatibility help |
| 17:56 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#dom-document-all |
| 17:56 | <jgraham> | Yes, I imagine that argument would go "ain't no way we will ever get interoperability around crazy bytecode hacks" |
| 17:59 | <jwalden> | that's how the argument *has* gone in the past :-) |
| 17:59 | jwalden | doesn't really think undefined-looking objects are right, but he's pretty sure they're at least less wrong |
| 17:59 | <Hixie> | what the spec says (cited above) is, iirc, the closest i could get to defining what browsers did without going off into the weeds of defining things like bytecode hacks |
| 18:01 | <jwalden> | in any case, it appears that engines (excepting Gecko) don't try to make "all" in document lie |
| 18:02 | <Hixie> | that's consistent with the spec, woot |
| 18:03 | <jwalden> | yep |
| 18:05 | <jwalden> | a little unfortunate maybe, but extending the property-access ECMAScript interface is just about the scariest possible thing a JS engine can do, in terms of making it easier to write bugs, harder to write correct code, harder to implement a spec-compliant engine, etc. |
| 18:06 | jwalden | isn't convinced anyone (including anyone working on SpiderMonkey) is smart enough to do it correctly |
| 18:06 | <jwalden> | well, |
| 18:06 | <jwalden> | "correctly" in the sense of not breaking incidental stuff along the way |
| 18:12 | <jwalden> | I think Gecko still makes document.all only appear in quirks mode, tho |
| 18:12 | <jwalden> | which does help satisfy the "all" in document test |
| 18:13 | <jwalden> | (that is, making it false to dissuade IE-detectors to some extent) |
| 18:24 | <Hixie> | annevk: if a sandboxed iframe has allow-popups and creates a sandboxed popup, should that popup be able to open fullscreen? |
| 18:24 | <Hixie> | annevk: or do i need to have a sandbox flag that stops that except if the attribute allowfullscreen is set? |
| 18:25 | <Hixie> | (this would be the first time the sandboxed flags get affected by things not in the sandbox attribute) |
| 19:19 | Ms2ger | dives into his inbox |
| 19:19 | <Ms2ger> | 1161 unread... |
| 19:48 | <Ms2ger> | Down to a thousand, good time to head off... |
| 21:40 | <annevk> | Hixie: I guess it would need allowfullscreen |
| 21:40 | <annevk> | Hixie: roc might have a more informed opinion |
| 21:40 | <Hixie> | "it"? |
| 21:40 | <annevk> | Hixie: the allow-popups popup |
| 21:41 | <Hixie> | how can a popup have allowfullscreen? |
| 21:42 | <annevk> | the same way it can be sandboxed |
| 21:42 | <Hixie> | by adding a sandbox="" attribute on the iframe or in CSP? |
| 21:43 | <annevk> | I was thinking <iframe> |
| 21:43 | <Hixie> | ah ok |
| 21:43 | <Hixie> | so what i wrote in the bug, basically |
| 21:43 | <Hixie> | propagate a sandbox flag |
| 21:43 | <Hixie> | ok |
| 21:43 | <annevk> | uhuh |
| 22:01 | <brainproxy> | will this patch to the w3c's html5 spec re: link relations be incorporated into the whatwg's living standard? |
| 22:01 | <brainproxy> | https://github.com/w3c/html/commit/954203e085e601122a2df38207bfdd6d852a0963 |
| 22:02 | <Hixie> | no |
| 22:03 | <Hixie> | (it's pointless) |
| 22:03 | <Hixie> | (it's so trivial to register a link type that there's really no reason to use a url, and urls wouldn't work right anyway since the rel="" field is case-insensitive and doesn't do url processing so really they'd just be opaque strings) |
| 22:04 | <Hixie> | (if we wanted to support a non-registered proprietary value space here, we'd likely use java-style reverse-dns names, not urls) |
| 22:05 | <brainproxy> | what if I'm developing an "semantic profile" based API, like Amundsen's ALPS, and I don't want to necessarily register links rels, but at the same time want to generate html that is valid |
| 22:05 | <Hixie> | can you elaborate on that? |
| 22:05 | <Hixie> | what problem are you trying to solve with this? |
| 22:05 | <brainproxy> | Hixie: see http://amundsen.com/hypermedia/profiles/ |
| 22:06 | <brainproxy> | the idea is that you develop a semantic profile, where "rel" vals play an important role |
| 22:06 | <Hixie> | i have no idea what these words mean |
| 22:06 | <Hixie> | well that's not true |
| 22:06 | <Hixie> | i know what the words mean |
| 22:06 | <brainproxy> | the ALPS example is pretty short |
| 22:06 | <Hixie> | but put together in this order they don't add up to anything to me :-) |
| 22:07 | <Hixie> | i meant the words at http://amundsen.com/hypermedia/profiles/ |
| 22:07 | <brainproxy> | the idea is that you document rel, class, name attrs |
| 22:07 | <Hixie> | the closest thing to a problem description there seems to be "The purpose of Application-Level Profile Semantics (ALPS) is to document the application-level semantics of a particular implementation." but i've no idea what that means |
| 22:07 | <brainproxy> | so that clients can be programmed to understand what they mean |
| 22:07 | <brainproxy> | but if you just use any old rel value, it's not valid html5 |
| 22:07 | <Hixie> | can you give me a concrete example of what user-facing problem we're fixing with this? |
| 22:08 | <brainproxy> | it's another way to develop a hypermedia api using "semantic web" notions |
| 22:09 | <zewt> | ("hypermedia"? heh) |
| 22:09 | <Hixie> | what is a "hypermedia api" |
| 22:09 | <brainproxy> | basically term to suggest that the API embraces HATEOAS |
| 22:09 | <Hixie> | "HATEOAS"? |
| 22:09 | <Hixie> | assume i know nothing here, and start from zero :-) |
| 22:10 | <brainproxy> | hyertext/media as the engine of application state |
| 22:10 | <Hixie> | i'm a user, sitting at a computer |
| 22:10 | <Hixie> | what is my computer not doing that you are going to make it do |
| 22:11 | <brainproxy> | well this has more value for developers programming clients and servers based on web tech, and not necessarily joe smith using his browser |
| 22:11 | <Hixie> | well smith using his browser |
| 22:11 | <Hixie> | er |
| 22:12 | <Hixie> | well, developers programming clients and servers based on web tech are still solving joe smith problems, right? |
| 22:12 | <Hixie> | like, they write tools to help them send short messages to their friends |
| 22:12 | <brainproxy> | the idea is that I can give you an entry point to my api, and armed w/ the semantic profile, you can build a client that can use the api w/o having to know some uri generation scheme |
| 22:12 | <Hixie> | or to manage their calendar |
| 22:12 | <Hixie> | or watch porn |
| 22:12 | <Hixie> | or whatever |
| 22:12 | <Hixie> | "uri generation scheme"? |
| 22:13 | <Hixie> | i feel like i'm missing some key context here |
| 22:13 | <Hixie> | what kind of API are we talking about? |
| 22:13 | <brainproxy> | in other words, my documented api revolves around the semantics of the hypermedia and not around documenting how to build up uris to do what you want to do |
| 22:14 | <Hixie> | sounds like your API is very complicated :-) |
| 22:14 | <Hixie> | can't you just have a simple API? |
| 22:14 | <Hixie> | what does your API do? |
| 22:14 | <brainproxy> | well one in particular I'm building acts as a gateway between plain web (just html pages w/ links and forms) and industrial automation systems |
| 22:15 | <brainproxy> | so yes, there's a fair bit of complexity |
| 22:15 | <Hixie> | what is an "industrial automation system"? like, robots and stuff? |
| 22:17 | <brainproxy> | well, in general devices you'd find in a manufacturing environment communicate w/ each other, and w/ centralized systems to keep track of what's going on |
| 22:17 | <brainproxy> | alarms, events, data changes, an so on |
| 22:17 | <Hixie> | ok... |
| 22:17 | <Hixie> | what's that got to do with HTML? |
| 22:18 | <zewt> | things i don't want my factory communicating with: the web |
| 22:18 | <Hixie> | yeah really |
| 22:18 | <Hixie> | air gap that sucker :-P |
| 22:18 | <brainproxy> | using web tech doesn't mean you hang your ass out of the factory's firewally on port 80 |
| 22:18 | <brainproxy> | gimme a break :p |
| 22:19 | <brainproxy> | anyway, what it has to do w/ html; there are standards which govern how these things communicate |
| 22:19 | <Hixie> | please tell me they document binary TCP protocols that have nothing to do with HTTP |
| 22:19 | <brainproxy> | it's more than just wire protocols |
| 22:19 | <brainproxy> | and they do both binary and xml/soap |
| 22:20 | <zewt> | :| |
| 22:20 | <Hixie> | i think i see your problem :-) |
| 22:20 | <brainproxy> | it's all very stateful and not very nice to work with |
| 22:20 | <Hixie> | still don't see how this relates to HTML though |
| 22:20 | <Hixie> | let alone rel="" |
| 22:21 | <brainproxy> | well, i'm working on a gateway that one one side uses http/html as the application layer |
| 22:21 | <brainproxy> | and on the other side uses these industrial protocols |
| 22:21 | <Hixie> | i'll admit i know nothing about this at all, as should be clear from this conversation so far |
| 22:21 | <Hixie> | but that sounds like a terrible idea :-P |
| 22:22 | <brainproxy> | that's okay, you asked, so I was trying to explain it |
| 22:22 | <brainproxy> | i can stop if it's not interesting |
| 22:22 | <Hixie> | it is definitely interesting |
| 22:22 | <brainproxy> | anyway, Amundsen's ALPS thing and a book he wrote inspired me |
| 22:22 | <brainproxy> | but you end up generating a lot of rel values |
| 22:22 | <brainproxy> | which aren't registered |
| 22:22 | <brainproxy> | hence ... the option to use valid but non-registered rels is appealing |
| 22:22 | <Hixie> | what do these rel values mean? |
| 22:23 | <brainproxy> | they allow a client to understand what <a> is pointing to |
| 22:23 | <Hixie> | how, if there's no definiton? |
| 22:23 | <Hixie> | or are these entirely intended for proprietary use and not public web use? |
| 22:24 | <brainproxy> | there is, you document it, but it's not necessarily apt for publication in microformats |
| 22:24 | <Hixie> | i'm trying to work out what the consumption software for this is |
| 22:24 | <Hixie> | is this something that you would ever try to read from an unrelated third party? |
| 22:24 | <Hixie> | or is this all for use within a closed circle of people? |
| 22:26 | <brainproxy> | unrelated third-parties could leverage the api to communicate w/ each other's systems |
| 22:26 | <Hixie> | on the web? |
| 22:27 | <brainproxy> | well across the global Internet yes, or intra-enterprise, |
| 22:27 | <brainproxy> | and/or you could have small devices sporting a lightweight http/html stack use it to tie into the heavier-duty stuff |
| 22:28 | <Hixie> | it sounds to me like the solution to this is to define a specification for "Industrial API HTML definitions" or something, which introduces a new attribute like "api-rel" or whatever, which you can use for this purpose |
| 22:29 | <Hixie> | it doesn't sound like rel="" is the right thing at all |
| 22:29 | <brainproxy> | well no i disagree because rel conveys the meaning perfectly |
| 22:30 | <Hixie> | honestly it doesn't sound like HTML is the right thing at all, but I could see wanting to reuse it so that the same page could open both in a web browser and in this magical api software |
| 22:30 | <brainproxy> | and if someone wants to know what the heck rel="http://mycompany.com/rels/rel-1"; means then they can look it up |
| 22:30 | <brainproxy> | assuming I publishd documentation at the URI |
| 22:31 | <brainproxy> | it's not magical, you can write stuff like this easily with python or node.js or whatever |
| 22:31 | <zewt> | (why would you put a url in rel? that's totally wrong) |
| 22:31 | <brainproxy> | zewt: because that's what RFC 5988 recommendes |
| 22:31 | <brainproxy> | and the w3c editors saw the wisdom in it |
| 22:31 | <brainproxy> | and patched their spec |
| 22:31 | <Hixie> | doing things because an RFC recommends it is the worst possible reason to do something |
| 22:32 | <Hixie> | and the w3c editors didn't see the wisdom in it |
| 22:32 | <brainproxy> | Hixie: well if it's a bone-headed recommendation sure :) |
| 22:32 | <Hixie> | the w3c html chairs saw the wisdom |
| 22:32 | <Hixie> | and some w3c editors thought itwas so dumb they quit as editors :_) |
| 22:32 | <brainproxy> | so ... if want to know what rel="registered-rel" means |
| 22:32 | <brainproxy> | I can go look it up on microformats |
| 22:32 | <Hixie> | google [rel registered-rel] |
| 22:33 | <brainproxy> | or IANA i guess |
| 22:33 | <brainproxy> | but anyway, why is it bad to have the option to specify rel="http://mycompany.com/api/rels/rel-1"; |
| 22:33 | <brainproxy> | and then joe blow client app developer can go look it up |
| 22:33 | <brainproxy> | on my wiki, or whatever that uri points him to |
| 22:34 | <Hixie> | what's bad is defining an API using rel="" :-) |
| 22:34 | <brainproxy> | nah, it's brililant |
| 22:34 | <brainproxy> | :D |
| 22:35 | <brainproxy> | and you don't use just rel of course |
| 22:35 | <brainproxy> | rel, class, name... |
| 22:35 | <Hixie> | o_O |
| 22:35 | <Hixie> | i really am at a loss |
| 22:35 | <Hixie> | why would anyone want to do this with HTML |
| 22:35 | <brainproxy> | read the ALPS thing, and here's an example |
| 22:35 | <Hixie> | i did read the ALPS thing |
| 22:35 | <Hixie> | it broke my buzzword detector |
| 22:35 | <Hixie> | and i didn't understand a word of it |
| 22:36 | <brainproxy> | https://github.com/mamund/Building-Hypermedia-APIs/tree/master/nodejs/microblog |
| 22:36 | <Hixie> | it was as bad as some of the Semantic Web stuff |
| 22:36 | <brainproxy> | that's an implemntation of Amundsen's ALPS, by the author, using nodejs |
| 22:37 | <Hixie> | what does it do? |
| 22:37 | <brainproxy> | it's a microblog which implements his semantic pofile |
| 22:37 | <brainproxy> | outlined in that document |
| 22:37 | <Hixie> | but what does it _do_? |
| 22:37 | <brainproxy> | it's a microblog |
| 22:37 | <zewt> | (what the heck is a microblog, aren't blogs micro by definition) |
| 22:37 | <brainproxy> | like Twitter, it's just an example |
| 22:38 | <brainproxy> | and this is a js bot which consumes the api |
| 22:38 | <brainproxy> | https://github.com/mamund/Building-Hypermedia-APIs/blob/master/nodejs/microblog/public/javascripts/mbclient.js |
| 22:38 | <Hixie> | zewt: microblog is basically like IRC but for hipsters :-) |
| 22:38 | <Hixie> | brainproxy: i don't understand why this is better than just having an API that you call directly |
| 22:38 | <Hixie> | brainproxy: it seems like a massive amount of extra work for no benefit |
| 22:39 | <brainproxy> | what do you mean by API you call directly? |
| 22:39 | <Hixie> | basically it's just an extra level of indirection |
| 22:39 | <Hixie> | instead of having to hardcode the API, you hardcode the values in rel="" etc, look up the API, and call the API |
| 22:39 | <brainproxy> | you mean by documenting URI construction rules? |
| 22:39 | <Hixie> | why not just call the API |
| 22:39 | <Hixie> | well I wouldn't use the term "URI construction rules", but sure |
| 22:40 | <brainproxy> | well in this manner two different implementations could use completely different URI schemes |
| 22:40 | <Hixie> | personally i would do all these APIs over WebSocket these days |
| 22:40 | <brainproxy> | and it would work the same |
| 22:40 | <Hixie> | they could use completely different URI schemes but would still have to use identical rel="" etc schemes, right? |
| 22:40 | <brainproxy> | yes |
| 22:40 | <Hixie> | so where's the benefit |
| 22:41 | <brainproxy> | :/ |
| 22:41 | <Hixie> | why not just define a little JSON blob that defines the mapping to the "URI construction rules" |
| 22:41 | <Hixie> | if you want to abstract those out |
| 22:41 | <Hixie> | (and why not just screw URLs entirely, and just document and implement a microblogging WebSocket protocol) |
| 22:41 | <Hixie> | (then anyone who wants to microblog can just use that protocol, regardless of the implementation) |
| 22:41 | <brainproxy> | websockets are nice for some things, but.... |
| 22:42 | <Hixie> | things like microblogging APIs? :-) |
| 22:42 | <brainproxy> | websockets are stateful |
| 22:42 | <brainproxy> | for one |
| 22:42 | <brainproxy> | different paradigm |
| 22:44 | <brainproxy> | anyway, i'd like to see the option to use absolute URIs as rels, per rfc 5988 and the direction the w3c is going ... guess maybe whatwg isn't going that direction |
| 22:44 | <brainproxy> | got to get back to work, but thanks for chatting w/ me about it :) |