| 00:00 | <arv> | annevk: one of the benefits I see though is that it would prevent new APIs that cannot be expressed in JS without proxies |
| 00:00 | <annevk> | yeah, that is the biggest win |
| 00:02 | <TabAtkins> | Clearly we should write idl in Dart. |
| 00:02 | <annevk> | arv, I don't know what proxies are |
| 00:03 | <annevk> | arv, what APIs cannot be expressed in JS? Last time this came up Brendan discussed things such as document.all |
| 00:03 | <arv> | annevk: Proxies are interceptors |
| 00:03 | <Hixie> | (what's wrong with APIs not being implementable in JS? We don't want JS to implement them, we want browsers to implement them. They only need to be _usable_ from JS.) |
| 00:04 | <arv> | arv: Yah, things like HTMLCollection and all other collections in DOM |
| 00:04 | <arv> | arv: Other things include dataSet (I don't remember the interface name) |
| 00:05 | <arv> | I want JS to be able to host the DOM. I think the right thing to do is to fix JS in this case though |
| 00:06 | <Hixie> | why on earth would you want JS to be able to host the DOM? |
| 00:06 | <Hixie> | the requirements for doing that seem like a whole bunch of things that aren't useful for general purpose web authoring |
| 00:06 | <Hixie> | so that seems like a very odd thing to prioritise |
| 00:07 | <smaug____> | https://github.com/andreasgal/dom.js/ |
| 00:07 | <arv> | Consistency. No more alien behavior |
| 00:07 | <Hixie> | consistency is not a goal |
| 00:07 | <arv> | smaug____: Andreas uses proxies |
| 00:07 | <smaug____> | indeed |
| 00:07 | <smaug____> | for implementation |
| 00:07 | <arv> | smaug____: Which we created for this purpose |
| 00:07 | <arv> | smaug____: and other use cases of course |
| 00:08 | <TabAtkins> | Being unable to write a library with functionality similar to the native DOM is bad. |
| 00:08 | <zewt> | (well, the interface of an API should always be implementable in JS; the underlying functionality not so much, of course) |
| 00:09 | <Hixie> | TabAtkins: you can write a library with functionality similar to the native DOM, but I disagree with the premise that if you couldn't that would be bad. Why would it be bad? |
| 00:10 | <TabAtkins> | Hixie: You couldn't do so, before we added proxies. |
| 00:10 | <Hixie> | sure you could, for some value of "similar" |
| 00:10 | <TabAtkins> | Hixie: It's bad because it means that libraries are forever different and possibly substandard to the native version. |
| 00:10 | <Hixie> | why is that bad |
| 00:10 | <zewt> | how is it not bad? |
| 00:10 | <TabAtkins> | Yes. |
| 00:11 | <annevk> | I'm also having a hard time seeing why it's bad. |
| 00:11 | <zewt> | for example, i should be able to implement standardized, drop-in-compatible APIs in JS, as far as is possible given their underlying functionality |
| 00:11 | <Hixie> | zewt: why??? |
| 00:12 | <Hixie> | has anyone actually got an argument here that explains why we would ever want proxies or all this "self-hosting js dom" stuff other than a flat assertion that we should? |
| 00:12 | <zewt> | (eg. implementing things like the hidden attribute on browsers that don't support it yet, as an obvious and simple example) |
| 00:12 | <annevk> | We don't apply that principle anywhere else. E.g. as we discussed earlier with CSS exposing access for any kind of property is not going to fly. |
| 00:13 | <Hixie> | we don't make it possible for authors to implement http in a web browser |
| 00:13 | <Hixie> | or implement css |
| 00:13 | <TabAtkins> | Hixie: I don't understand how you don't understand why having magical syntax capabilities that only the native platform can use is bad. |
| 00:13 | <zewt> | ^ |
| 00:13 | <TabAtkins> | Um, neither of those are turing-complete languages. |
| 00:13 | <zewt> | it seems to obvious to me that I don't know how to explain it further, heh |
| 00:14 | <TabAtkins> | Also, it turns out there may actually be a performance win from hosting the DOM in pure JS, since you're not having to call across FFI boundaries. |
| 00:14 | <annevk> | TabAtkins, what makes it being turing-complete relevant? |
| 00:14 | <zewt> | APIs exposed to JS should be using the *same vocabulary as the language itself* |
| 00:14 | <TabAtkins> | annevk: DSLs are not the same thing as full languages. |
| 00:14 | <Hixie> | (imho proxies in js are a terrible idea, fwiw. they are massively complex and don't provide anything authors actually need. I'm all for providing things like getters and setters, and maybe syntax to make some members private or have "real" classes, but having an API that lets you fiddle with the low-level bits of objects is just asking for authors to shoot themselves in the feet.) |
| 00:15 | <TabAtkins> | Hixie: Things like proxies are useful for reimplementing the DOM. They're also useful for other things. Almost any feature that could be a magical native feature could be useful somewhere else too. |
| 00:15 | <Hixie> | TabAtkins: every platform has capabilities only the native platform has. e.g. only the kernel can allocate memory to a process. What's wrong with that? |
| 00:15 | <zewt> | (don't know anything about proxies; I'm only talking at the JS language level) |
| 00:15 | <smaug____> | from implementation point of view implementing DOM using a "safe" (!= C++) language would be good. JS is such a safe language, and browser devs happen to be familiar with it. |
| 00:15 | <smaug____> | bu that is all just implementation detail |
| 00:16 | <TabAtkins> | The kernel isn't a programming language. We're talking syntax. |
| 00:16 | <smaug____> | but yes, performance can be also better when implemented in JS |
| 00:16 | <zewt> | Hixie: anyone can implement a function with the same API as malloc/free or brk, though |
| 00:16 | <TabAtkins> | Functionality can be special and magical; by definition, some it has to be. Syntax doesn't need to be, though. |
| 00:16 | <Hixie> | syntax is basically irrelevant to anything, imho |
| 00:16 | <annevk> | TabAtkins, still not an argument |
| 00:16 | <Hixie> | who cares what the syntax is |
| 00:17 | <TabAtkins> | And that's fundamentally why you're wrong, Hixie. |
| 00:17 | <annevk> | TabAtkins, in reply to "not the same" |
| 00:17 | <Hixie> | it's like people who say that they prefer python to perl or whatever because it has spaces indenting or doesn't or whatever |
| 00:17 | <Hixie> | who cares |
| 00:17 | <zewt> | what? |
| 00:17 | <Hixie> | TabAtkins: so far your argument has consistent of no more than an assertion, so i'm pretty confident that i'm not wrong :-) |
| 00:17 | <Hixie> | consisted |
| 00:18 | <Hixie> | or at least, that you haven't in any way provided a reason why i should think that i'm wrong |
| 00:18 | <TabAtkins> | annevk: A DSL has a special, limited purpose. It's not meant as a general-purpose computing language. It does one thing and does it well. |
| 00:18 | <Hixie> | JavaScript is not meant as a general-purpose computing language. |
| 00:18 | <TabAtkins> | A general purpose computing language is, well, general-purpose. |
| 00:18 | <Hixie> | It's a language for writing Web apps. |
| 00:18 | <annevk> | TabAtkins, you are just explaining what a DSL is, you are not giving an argument |
| 00:18 | <zewt> | i should be able to implement a class with a drop-in-compatible interface to, say, IDB or Blob or any other API, and pass the object to something that expects that API, and make it work; if that's impossible because the API is something that can't be expressed in JS itself, that's a flaw |
| 00:18 | <Hixie> | zewt: i strongly disagree with that |
| 00:18 | <zewt> | why/ |
| 00:19 | <zewt> | also ? |
| 00:19 | <TabAtkins> | I strongly agree with zewt, and think you're a bad person for disagreeing, Hixie. |
| 00:19 | <hober> | Consider the desire to write a polyfill library |
| 00:19 | <zewt> | heh |
| 00:19 | <TabAtkins> | ^_^ |
| 00:19 | <Hixie> | zewt: you should absolutely _not_ be able to create an API that fakes a native, privileged object. That ways lies security nightmares. |
| 00:19 | <zewt> | how so? |
| 00:19 | <hober> | you write the library in js and want it to be a drop-in replacement for the equivalent dom feature |
| 00:19 | <zewt> | if your security model depends on not being able to have the same interface as some native object, your security model is deeply broken |
| 00:20 | <zewt> | that doesn't even make sense |
| 00:20 | <mkanat> | zewt: The security model does depend on people not being able to replace certain objects themselves, though. |
| 00:20 | <TabAtkins> | annevk: People do not expect to be able to self-host DSLs. |
| 00:20 | <zewt> | this is simple duck typing (as it's called in Python, at least) |
| 00:20 | <zewt> | caring about the interface and not the object type |
| 00:20 | <Hixie> | i don't even know where to begin in explaining why it's a bad idea to be able to replace native objects |
| 00:20 | <Hixie> | take Event for example |
| 00:20 | <TabAtkins> | annevk: Largely because, since a DSL is designed for a specific domain by definition, self-hosting is virtually never that domain. |
| 00:20 | <Hixie> | dispatching an Event has all kinds of special infrastructure |
| 00:20 | <Hixie> | like whether the event is trusted |
| 00:21 | <Hixie> | what phase the event is in |
| 00:21 | <Hixie> | etc |
| 00:21 | <annevk> | you are not making sense |
| 00:21 | <annevk> | TabAtkins that is |
| 00:21 | <Hixie> | a real (native) Event object implements all that machinery in a way that the UA knows it can trust |
| 00:21 | <zewt> | obviously we're not talking about passing reimplementations to native methods |
| 00:21 | <Hixie> | you can't just fake an Event and dispatch it |
| 00:21 | <TabAtkins> | annevk: I don't know what else to say. ;_; You asked me why a DSL doesn't need to be able to self-host. I explained why. |
| 00:21 | <Hixie> | zewt: "obviously" nothing |
| 00:21 | <Hixie> | zewt: i have no idea what you're talking about! |
| 00:21 | <zewt> | no, obviously, we're talking about *within javascript*, not to native non-JS methods |
| 00:22 | <TabAtkins> | Hixie: Pay attention to zewt's example. Look at IDB, for example |
| 00:22 | <Hixie> | zewt: ok let's reset this conversation. what is it you want to do? |
| 00:22 | <Hixie> | zewt: that you can't do without JS being all kinds of more complicated? |
| 00:22 | <TabAtkins> | Being able to fake idb via some other mechanism to polyfill older browsers is a Good Thing(tm). |
| 00:22 | <Hixie> | i have no idea what "idp" and "polyfill" are |
| 00:22 | <Hixie> | "idb" |
| 00:22 | <TabAtkins> | IndexedDB. |
| 00:22 | <TabAtkins> | Polyfilling. Shimming. Whatever. |
| 00:22 | <hober> | use case: this browser doesn't support the new form validation dom api. i want to have a drop-in replacement "formvalidationapi.js" |
| 00:22 | <TabAtkins> | The fact that you don't know this word is a strong indicator that you're out of touch with webdev needs. ^_^ |
| 00:23 | <Hixie> | o_O |
| 00:23 | <zewt> | i didn't know that word D: |
| 00:23 | <TabAtkins> | Polyfilling = using JS in an older browser to fake a feature that isn't implemented in the old browser yet. |
| 00:24 | <TabAtkins> | Allowing you to pretend that the new feature exists everywhere. |
| 00:24 | <Hixie> | if the use case we're talking about is "i want to reimplement the API that the UA doesn't provide because it's an old API" then the solution is IMHO not to reimplement the API but to provide an API of your own that abstracts away what background API exists |
| 00:24 | <Hixie> | don't just reimplement whatever shit i came up with |
| 00:24 | <zewt> | strongly disagree |
| 00:24 | <TabAtkins> | No, that's wrong. That way means that we live with libraries forever, or someday make a painful migration back to native. |
| 00:24 | <Hixie> | (or even better, just wait til it's implemented everywhere) |
| 00:24 | <TabAtkins> | We want to work with the native stuff. |
| 00:25 | <zewt> | i want to implement the standard API (or as close as I can get) in a self-contained way that I can drop in on browsers that need it, and forget about it, and then other code (that other people may have to read) don't have to learn my new special wrapper API, it just uses the standard one that everyone knows |
| 00:25 | <Hixie> | adding a whole bunch of complexity to the platform purely so that in the future, new APIs can be shimmed by script, seems like an incredible waste of time |
| 00:25 | <Hixie> | (frankly, if we're creating APIs that you _can_ shim, then we're clearly not adding APIs that matter) |
| 00:25 | <TabAtkins> | ... |
| 00:26 | <TabAtkins> | I don't understand you at all, Hixie. |
| 00:27 | <Hixie> | ditto :-) |
| 00:27 | <TabAtkins> | That seems to argue that there's no reason to every make a convenience api, if it's at all possible for a library, no matter how complex, to implement the same functionality. |
| 00:27 | <zewt> | lots of APIs can be implemented in JS that you really don't want to if you can help it (obvious examples being performance-critical stuff, like SHA-1 and crypto) |
| 00:28 | <Hixie> | i'm strongly inclined to avoid adding convenience APIs and performance-critical stuff should just be implemented in JS and JS should be fast enough |
| 00:28 | <zewt> | wow, we just diverged from reality by about a light year :) |
| 00:28 | <Hixie> | hey, you're the one who wants JS to be able to fake native code! |
| 00:28 | <TabAtkins> | Everything you have just said is wrong-headed, Hixie. |
| 00:28 | <Hixie> | TabAtkins: i'm eager to hear your arguments showing how that is the case |
| 00:29 | <arv> | Take dataSet for example, it adds no new semantic value. Only convenience. But since it requires interceptors/proxie s it cannot be emulated in older browsers |
| 00:29 | <Hixie> | TabAtkins: but so far all you've done is ad hominem and argument from assertion |
| 00:29 | <zewt> | i'm the one who wants to be able to implement APIs as fallbacks when I have to, for compatibility; i certainly do want to be able to use ones with decent native performance when they're available |
| 00:30 | <Hixie> | zewt: i don't see why the shims have to implement the native APIs perfectly down to the last "readonly" or whatnot. JS today is quite close enough for shim purposes. |
| 00:30 | <arv> | ...and if you wrap it in another library all platforms, now and forever suffer the extra latency of downloading that library |
| 00:30 | <Hixie> | not now and forever, only now and up to when the API is widely implemented |
| 00:31 | <arv> | Hixie: es5 is not close enough |
| 00:31 | <Hixie> | (it's not like that latency is that big a deal -- measure it) |
| 00:31 | <Hixie> | arv: do you have any examples of how it is not close enough? |
| 00:31 | <zewt> | Hixie: i'm not saying it needs to be an exact implementation (i did say "as close as I can get"); I'm saying implementing the APIs is a generally useful thing to be able to do |
| 00:31 | <Hixie> | arv: (i think es3 was close enough) |
| 00:31 | <arv> | Hixie: so you expect people to go back and update web pages? |
| 00:31 | <Hixie> | arv: ones that are still used? yeah. the web moves on. |
| 00:32 | <arv> | element.dataSet.newProperty = newValue; // try to emulate that |
| 00:32 | <Hixie> | arv: (apps aren't like docs in that regard) |
| 00:32 | <arv> | Hixie: fair enough |
| 00:32 | <zewt> | (being able to implement them more closely is a good thing, and the bits where we can't I'd consider flaws, but whether they're enough of flaws to spend a lot of engineering fixing is a different question) |
| 00:32 | <Hixie> | arv: just use setAttribute('data-new-property') until it's widely available. next? |
| 00:32 | <arv> | Hixie: but more and more docs have jQuery in them |
| 00:32 | <TabAtkins> | Hixie: No, I haven't, but you dont' seem to be understanding me well enough. So, let's try again. |
| 00:32 | <arv> | Hixie: so why did we add dataSet then? |
| 00:33 | <Hixie> | arv: i thought we were talking about cases where people _weren't_ useing libraries? |
| 00:33 | <Hixie> | arv: for convenience in 10 years |
| 00:33 | <TabAtkins> | !_! |
| 00:33 | <Hixie> | same reason we add new CSS features |
| 00:33 | <TabAtkins> | And with sufficient JS powers, we can achieve convenience *today*. |
| 00:33 | <arv> | Hixie: my point re jquery was that most content today are more than just static pages |
| 00:34 | <Hixie> | arv: that's _clearly_ not the case. |
| 00:34 | <Hixie> | arv: the vast majority of content is docs |
| 00:34 | <Hixie> | arv: without script at all |
| 00:34 | <Hixie> | arv: other than ads and analytics |
| 00:34 | <Hixie> | TabAtkins: why does it matter if we get the convenience at t=-5y, t=0, or t=5y? |
| 00:35 | <TabAtkins> | t=5y is five years away! |
| 00:35 | <Hixie> | so? |
| 00:35 | <Hixie> | 5 years ago today was five years away |
| 00:35 | <zewt> | not all of us are vampires |
| 00:35 | <TabAtkins> | We don't have infinite time to wait for things! We often dont' even have moderate finite amounts of time! |
| 00:35 | <annevk> | Got to love the IE blog " WebVTT originated from W3C discussions last year after a need for simple caption authoring was identified." |
| 00:35 | <zewt> | wait do vampires age, i'm not a vampireologist |
| 00:35 | <Hixie> | impatience is _certainly_ not the reason to add orders of magnitude of complexity to the platform |
| 00:36 | <TabAtkins> | If you characterize it as "impatience", you'll never see the value in it of course. |
| 00:36 | <Hixie> | if you're impatient, you'll never see the value in waiting? :-) |
| 00:37 | <Hixie> | seriously, the web moves so fast these days compared to any point in the past, it's incredible that there are still people who want it to move faster |
| 00:37 | <TabAtkins> | Now is always better than later. The faster you can innovate in one area, the faster innovation happens everywhere else. |
| 00:37 | <zewt> | patience doesn't enter into it; a page that I have to write today I have to write today, I don't get to tell my boss "let's wait five years" |
| 00:37 | <Hixie> | we're probably the fastest moving industry there is |
| 00:37 | <Hixie> | there's such a thing as going _too_ fast, imho :-) |
| 00:37 | <TabAtkins> | I'm trying to force the Singularity here, dammit! |
| 00:37 | <Hixie> | now is _not_ always better than later. Later you have more experience, and waiting means you can fix things. |
| 00:37 | <hober> | Hixie: indeed |
| 00:38 | <zewt> | you don't have nearly as much experience if you never use a feature because you have to wait 5 years for it to become widely available :) |
| 00:38 | <TabAtkins> | Hixie: Plus, some parts of the platform do *not* move quickly. Mobile, for example. |
| 00:38 | <Hixie> | just look at the issue rniwa raised earlier, where itemtype changed and rniwa wanted to use prefixes because of it |
| 00:38 | <TabAtkins> | Or, you know, the ~40% of the web still on IE7 or lower. |
| 00:39 | <TabAtkins> | Plus zewt's point, that adoption in JS means more experimentation and more experience. |
| 00:39 | <TabAtkins> | It would have taken much longer to get querySelector if jQuery hadn't existed. |
| 00:40 | hober | thinks mobile is moving pretty quickly actually |
| 00:40 | <TabAtkins> | Hixie: out of curiosity, since you said that you don't think convenience APIs should exist, do you think we shouldn't have done querySelector? |
| 00:40 | <zewt> | mobile is sort of crippled because phone manufacturers rarely update browsers |
| 00:40 | <TabAtkins> | hober: The edge is moving roughly as fast as the edge of the desktop. The tail is still pretty slow, though. |
| 00:40 | <TabAtkins> | Because of what zewt just said. |
| 00:41 | <zewt> | (which is gross and embarrassing; all mobile platforms are *new* platforms, and there's no excuse that they don't all have well-built upgrade systems for browsers) |
| 00:41 | <hober> | I can think of some phone manufacturers who are pretty good at updating their browsers :) |
| 00:41 | <TabAtkins> | Still not the majority. ^_^ |
| 00:42 | <smaug____> | hober: tell me one. (I may actually change my phone reasonable soon) |
| 00:42 | <TabAtkins> | smaug____: Presumably he was referring to iphone |
| 00:42 | <zewt> | no android phone does, since it pretty much takes a full OS update to update the browser |
| 00:42 | <smaug____> | ( though, I can just use Nightly and update the browser every day ) |
| 00:43 | <smaug____> | does iphone's Safari get updated often? |
| 00:44 | <miketaylr> | zewt: of course there are browsers available on the android platform that update much faster than the OS |
| 00:44 | <hober> | It doesn't come out every six weeks, but then again, like Hixie said, there's such a thing as moving too fast. :) |
| 00:50 | <hober> | un-derailing the conversation for a moment, I think both Hixie & TabAtkins are making reasonable points: |
| 00:50 | <hober> | I agree with Tab that it would be nice for JS authors to be able to write polyfills for features, and at least in some cases JS should be augmented to facilitate that. |
| 00:50 | <hober> | Hixie's right, though, that if a new API is easily polyfillable, that's a smell that the API probably doesn't belong in the platform |
| 00:51 | <TabAtkins> | I still disagree with that. We can produce high-value convenience APIs that are easily polyfillable. |
| 00:51 | <TabAtkins> | They are still worthwhile to add to the platform. |
| 00:52 | <TabAtkins> | For example, getting the mouse location relative to a target element is pretty easy. I reinvent it every time I write anything using the mouse. |
| 00:52 | <TabAtkins> | It's still a high-value thing to provide natively, precisely *because* I have to reinvent it every single time I write anything using the mouse. |
| 00:53 | <TabAtkins> | (Plus, something can be easy to polyfill the primary use-case for, but still offer additional value in providing corner-cases that are harder to polyfill.) |
| 00:53 | <hober> | Yeah, I have "probably" in my line above to give myself enough rhetorical wiggle room to agree with you in some cases and not in others. :) it's a judgement call |
| 00:53 | <TabAtkins> | Plus, it's still surprisingly easy to get the mouse thing wrong. |
| 00:53 | <zewt> | miketaylr: but most people use the stock browser, and people should be able to do so |
| 00:54 | <miketaylr> | (for sure) |
| 00:54 | <zewt> | TabAtkins: there's also a lot of value in standardizing basic stuff like that that's used a lot, instead of every page reinventing it slightly differently |
| 00:54 | <TabAtkins> | Yup. |
| 00:55 | <TabAtkins> | So whether or not it can be polyfilled easily is, I think, a useless signal when deciding whether to add it. |
| 00:55 | <TabAtkins> | Whether it's useful and commonly-needed is really what you need to account for. |
| 00:59 | <TabAtkins> | (I suppose if something is rarely needed, but really useful when it is needed, whether or not it's easy to duplicate in JS can be a useful factor to consider.) |
| 00:59 | <Hixie> | TabAtkins: (sorry, was afk) |
| 01:00 | <TabAtkins> | It's cool, I can talk enough for both of us. |
| 01:00 | <Hixie> | TabAtkins: i think querySelector() is fine, because the UA has all kinds of knowledge and ability to optimise that the script doesn't |
| 01:00 | <Hixie> | TabAtkins: but equally, i think it doesn't make much sense to implement a JS version of it |
| 01:01 | <TabAtkins> | Well, not *now* it doesn't. It made all kinds of sense when jQuery did it. |
| 01:01 | <Hixie> | TabAtkins: having said that, i think ES3 is quite capable of providing enough of a shim for it that we don't need more magical syntax features. |
| 01:01 | <TabAtkins> | Actually, though, it does still make sense to implement it in JS, because there are still significant browsers that don't have it. |
| 01:02 | <TabAtkins> | Yes, querySelector requires nothing special on the syntax front to shim. That was just a question about your general point that convenience features shouldn't be added. |
| 01:03 | <Hixie> | TabAtkins: what are examples of things that you think need shimming that can't be sufficiently shimmed with JS? |
| 01:04 | <TabAtkins> | arv gave an example in the form of dataSet. |
| 01:04 | <TabAtkins> | It can be shimmed now, with Proxies. |
| 01:04 | <Hixie> | an example that isn't trivially dealt with by just using getAttribute |
| 01:05 | <Hixie> | that is, an example where the convenience provided is great enough to justify adding a bunch of features to support providing the convenience |
| 01:05 | <TabAtkins> | No. The syntax is the important part there. dataSet is exactly equivalent in *functionality* to setAttribute. It's more convenient to use because of syntax. |
| 01:05 | <Hixie> | sure but it's not important enough to matter |
| 01:05 | <TabAtkins> | The fact that it was an obvious enough syntax win for you to add it should be a sufficient answer as to why outside JS libs would want it. |
| 01:05 | <zewt> | if it wasn't important enough to matter then why was it added in the first place? |
| 01:05 | <Hixie> | given the choice between a bunch of syntax to allow authors to emulate dataSet and just using DOM Core, DOM Core is the obviously better choice. |
| 01:07 | <Hixie> | to add a feature to the platform you have to compare the cost of not having it to the cost of implementing it. The cost of not having dataSet is minimal, the cost of implementing dataSet is even less so. The cost of not having dataSet is minimal, the cost of implementing a bunch of additions to JS to enable authors to fake it is comparatively huge. |
| 01:07 | <arv> | another one is classList |
| 01:07 | <TabAtkins> | The cost of never having anything like dataSet is larger. |
| 01:07 | <arv> | same issues as dataSet but more useful (IMO) |
| 01:08 | <Hixie> | you can surely fake enough of classList today |
| 01:09 | <Hixie> | it's just a bunch of methods |
| 01:09 | <Hixie> | where's the problem? |
| 01:09 | <annevk> | it's dataset not dataSet btw |
| 01:10 | <TabAtkins> | annevk: I always forget. arv said dataSet early, so I copied him. |
| 01:12 | <zewt> | ... by the way, what's so badly complex about proxies? google isn't finding much about them, but https://gist.github.com/1202328 looks fairly straightforward |
| 01:13 | <zewt> | (not as nice as Python's __getattr__, but I assume performance is the problem with that interface) |
| 01:13 | <TabAtkins> | zewt: Decent tutorial at http://soft.vub.ac.be/~tvcutsem/proxies/ |
| 01:14 | <arv> | classList[index] cannot be emulated |
| 01:14 | <zewt> | looks fairly self-contained |
| 01:16 | <paul_irish> | fwiw https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills lists basically every shim/polyfill for all newish features there is. |
| 01:16 | <paul_irish> | elem.classList[methodname]('classname') is unsupported in the polyfill listed. |
| 01:17 | <Hixie> | arv: so just use classList.item(index) |
| 01:17 | <zewt> | heh Video Timed Track (subtitles) |
| 01:17 | <Hixie> | arv: you don't have to duplicate the entire API, only enough of the API for it to be usable |
| 01:17 | <zewt> | an assured way of making sure nobody can find VTT: call it Video Timed Track |
| 01:18 | <TabAtkins> | Hixie: The fact that the platform has a nice convenient way of doing something, but libraries can't ever duplicate it, is a bug. |
| 01:18 | <Hixie> | TabAtkins: so you keep saying, but that doesn't follow from the use cases you describe |
| 01:18 | <TabAtkins> | Again, if it was sufficiently obvious of a win to be included in the first place, it's clearly a useful thing for libraries to have as well. |
| 01:18 | <paul_irish> | zewt: just updated so the abbv is present in the page |
| 01:19 | <Hixie> | TabAtkins: you are assuming that something was added to the platform because it was a good idea and not just because i copied-and-pasted other parts of the platform that did it too |
| 01:19 | <Hixie> | TabAtkins: there's plenty of stuff in the platform that isn't a win at all, let alone a "sufficiently obvious win" |
| 01:19 | <TabAtkins> | Are you saying that relatively new APIs you've designed are mistakes? |
| 01:19 | <zewt> | i'd suggest that one of the following must be true: 1: being able to write foo.bar and have bar looked up dynamically is a useful idiom in APIs, and it should be possible to do this in JS libraries; or 2: it's not very useful, and no new APIs should do that |
| 01:20 | <zewt> | (speaking of getattr(foo, "bar"), not getters, of course) |
| 01:20 | <Hixie> | TabAtkins: many have plenty of mistakes or bits that are consistent merely for the sake of consistency, or have features that are made available because they can be but where if i was designing the API for an environment where they could not be i wouldn't blink at omitting it |
| 01:21 | <Hixie> | TabAtkins: .item(n) vs [n] being a classic example of the latter |
| 01:21 | <Hixie> | TabAtkins: (having said that, i've no objection to JS adding a neat syntax to support index getters in classes) |
| 01:21 | <TabAtkins> | Sigh. It seems like every feature that we point out, you say wasn't necessary in the first place and doesn't need to be done in library code. |
| 01:22 | <Hixie> | TabAtkins: yes, it is my argument that everything you can't do in JS is stuff you needn't do in JS |
| 01:22 | <annevk> | I think [n] is nice to have |
| 01:22 | <erlehmann> | best browser ever http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html |
| 01:22 | <TabAtkins> | Hixie: That's a stupid argument. ^_^ |
| 01:22 | <annevk> | emulating IDL [replaceable] and such however goes a bit far |
| 01:22 | <zewt> | i'm still not understanding what's so objectionable about this proxy interface; it looks self-contained and already implemented in FF |
| 01:22 | <Hixie> | TabAtkins: it's backed up by the fact that every concrete example you've given has in fact supported my argument |
| 01:22 | <Hixie> | TabAtkins: if you have a counter-example i'm certainly open to it |
| 01:23 | <TabAtkins> | Hixie: Only in your mind. ;_; Because you self-admitedly don't consider syntax important. |
| 01:23 | <Hixie> | TabAtkins: also, note that i have no objection to specific features being added to JS, my objection is to the explicit goal of adding everything necessary to emulate DOM APIs in JS |
| 01:23 | <Hixie> | TabAtkins: because i think that goal is sufficiently met already |
| 01:24 | <TabAtkins> | I consider self-hosting a valuable property for a language to have. |
| 01:24 | <Hixie> | a valuable feature for a turing-complete language and an API to have but not a language like CSS? |
| 01:25 | <TabAtkins> | Yes? |
| 01:26 | <TabAtkins> | Again, DSL is, by definition, domain-specific, not general-purpose. |
| 01:27 | <Hixie> | the DOM API is not domain-specific? |
| 01:27 | <Hixie> | _JS_ is not domain-specific? |
| 01:27 | <zewt> | js certainly is not |
| 01:28 | <TabAtkins> | Nobody's asking to be able to self-host the DOM API in the DOM API. We want to host the DOM in JS. |
| 01:28 | <TabAtkins> | JS is most certainly not domain-specific! What possibly could possess you to think it is? |
| 01:28 | <erlehmann> | DOMain-specific! |
| 01:28 | <TabAtkins> | erlehmann: :headdesk: |
| 01:28 | zewt | eyes Unity editor open with a couple JS scripts that have nothing to do with the web |
| 01:28 | <Hixie> | it's the web's programming language, i can't imagine any other context in which i'd actually want to use it |
| 01:28 | <erlehmann> | careful, TabAtkins. or i shall make a new comic. |
| 01:28 | <zewt> | TabAtkins: (the important question: whose head) |
| 01:29 | <TabAtkins> | Hixie: You are operating under an incorrect definition of "domain-specific" and "general purpose". |
| 01:29 | <Hixie> | TabAtkins: and you're mis-using "self-hosting" :-) |
| 01:29 | <TabAtkins> | No I'm not. ^_^ |
| 01:29 | <Hixie> | JS implementing DOM is not self-hosting |
| 01:29 | <Hixie> | that would be JS implementing JS |
| 01:30 | <Hixie> | if JS is "general purpose", why is CSS not "general purpose"? |
| 01:30 | <TabAtkins> | Yes. DOM is a library built in JS. By definition, if JS is self-hosting, it can host the DOM too. |
| 01:30 | <Hixie> | DOM is _not_ a library build in JS! |
| 01:30 | <Hixie> | it's an API exposed to JS built typically in C++ |
| 01:30 | <TabAtkins> | Hixie: Um, because CSS is a DSL. It's nowhere near turing-complete, and not intended for generic computation. |
| 01:30 | <Hixie> | ... |
| 01:30 | <zewt> | "..." what? |
| 01:31 | <Hixie> | we're going around in circles |
| 01:31 | <TabAtkins> | I don't understand how! |
| 01:31 | <Hixie> | whether something is turing complete or not doesn't have any bearing on whether it's general purpose or not |
| 01:31 | <TabAtkins> | How can you possibly think CSS is a general-purpose computer language?!? |
| 01:31 | <zewt> | i don't understand the question--of course you can't implement CSS features in CSS; CSS isn't even a programming language |
| 01:31 | <TabAtkins> | zewt: Sure it is. It's just a very limited one. |
| 01:31 | <zewt> | it's not, not by any definition of the term I've ever seen or used |
| 01:32 | <TabAtkins> | It's a styling and layout programming language. |
| 01:32 | <TabAtkins> | You're probably just not very familiar with declarative languages. |
| 01:32 | <zewt> | it's a layout language; it's not a layout *programming* language |
| 01:32 | <TabAtkins> | CSS is a program that accepts a DOM as input and produces a laid-out page. |
| 01:32 | <Hixie> | none of us seem to agree on terminology here |
| 01:32 | <zewt> | heh |
| 01:33 | <Hixie> | anyway |
| 01:33 | <Hixie> | i have to go |
| 01:33 | <zewt> | TabAtkins: i disagree, but let's skip this debate :) |
| 01:33 | <TabAtkins> | Hixie: Pretty sure everyone extra-disagrees with your terms, though, if you consider CSS a general-purpose alnguage and JS not. |
| 01:33 | <zewt> | (was: re: third-order tangent) |
| 01:33 | <Hixie> | but i must first say that i continue to see no intrinsic reason why a library that implements a DOM shim would need to support every last subtlty of the DOM |
| 01:33 | <Hixie> | it just has to be close enough |
| 01:33 | <Hixie> | TabAtkins: i consider both to be domain-specific |
| 01:34 | <TabAtkins> | Hixie: Is C domain-specific? |
| 01:34 | <annevk> | extra-disagree lol |
| 01:34 | <Hixie> | no, C is general-purpose |
| 01:34 | <TabAtkins> | Then your definition is broken. |
| 01:34 | <Hixie> | ko |
| 01:34 | <Hixie> | ok |
| 01:34 | <zewt> | in every other language I've used at any length, every API exposed to the language can be exposed by code written in the language itself; JS being the weird exception |
| 01:34 | <Hixie> | the point is moot, since i don't think whether something is general purpose or not should control whether it needs to have the syntactic ability to emulate its APIs or not |
| 01:35 | <Hixie> | zewt: you haven't used many languages |
| 01:35 | <annevk> | Wikipedia sides with Hixie fwiw http://en.wikipedia.org/wiki/General-purpose_programming_language |
| 01:35 | <Hixie> | zewt: there are tons of languages that can't describe all their APIs |
| 01:35 | <TabAtkins> | annevk: How so? |
| 01:36 | <zewt> | perhaps badly-designed languages, which I do try hard to avoid |
| 01:36 | <Hixie> | zewt: e.g. Perl (some of its APIs are especially crazy), Pascal (normal Pascal can't implement its own Writeln function) |
| 01:36 | <zewt> | nice timing bringing up Perl :) |
| 01:36 | <TabAtkins> | JS is a perfectly fine general-purpose functional programming language. It happens that in its most common implementations there are a couple of additional libraries built-in that are designed for easier writing of webapps, is all. |
| 01:36 | <zewt> | (pascal is a toy language, as far as I'm concerned) |
| 01:36 | <zewt> | (havn't touched it in ... 15 years?) |
| 01:37 | <Hixie> | i happen to be particularly familiar with those two so can comment authoratively off the top of my head |
| 01:37 | <Hixie> | i'd be surprised if there weren't similar limitations in most languages |
| 01:37 | <Hixie> | but i really have to go |
| 01:37 | <Hixie> | bbl |
| 01:38 | <TabAtkins> | annevk: Yup, reading further, I'm quite certain that Wikipedia disagrees with Hixie. There is no reasonable definition of "domain-specific" under which JS is one. |
| 01:38 | <zewt> | (C, C++, Python) |
| 01:47 | <erlehmann> | C is general purpose. I make music with a compiler. :3 |
| 01:48 | <annevk> | TabAtkins, I meant for "C" |
| 01:48 | <erlehmann> | #include <math.h> |
| 01:48 | <erlehmann> | #include <stdio.h> |
| 01:48 | <erlehmann> | main(){long int t;int sample;for(t=0;;t++){sample=(((t&512)>>(int)(3*sin(t*4&(int)(t/256))))>>(t>>18)|((t&512)>>(int)(4*sin(t*4&(int)(t/512))))>>(t>>27));fputc(sample, stdout);}} |
| 01:49 | <erlehmann> | just pipe this to /dev/audio :3 |
| 01:49 | <annevk> | given that JavaScript is used on e.g. servers and elsewhere it does not really seem that domain specific to me |
| 01:49 | <TabAtkins> | annevk: Did you think I was saying that C was domain-specific? |
| 01:49 | <annevk> | but I don't really care |
| 01:49 | <erlehmann> | javascript ist used on servers … and desktops. doesn't gnome have javascript? |
| 01:50 | <bga_> | gnome3 - yes |
| 01:50 | <TabAtkins> | Even if JS was only ever used in webpages in browsers, it's still not domain-specific. It is capable of (and designed for) arbitrary computation. |
| 01:50 | <erlehmann> | i concur. |
| 01:51 | <TabAtkins> | This isn't like, I dunno, using XSLT to compute mandelbrots. |
| 01:51 | <bga_> | also qml |
| 01:51 | <erlehmann> | hey, i wrote a CMS abomination in XSLT once. i think everyone has to live through that, coming-of-age-story. |
| 01:53 | <TabAtkins> | bga_: From wikipedia's description, it looks like QML is a DSL. |
| 01:53 | <TabAtkins> | It looks like you can run arbitrary JS, but it's designed for designing UI. |
| 01:54 | <TabAtkins> | And the syntax is clearly slanted towards that end. |
| 02:11 | <TabAtkins> | erlehmann: By the way, it would be great if you could put in a Kate Beaton credit in your comic. |
| 02:12 | <erlehmann> | TabAtkins, oh. i thought people knew that already. |
| 02:12 | <erlehmann> | after all, it was for and about you, i spotted the fat pony in your sig! |
| 02:12 | <TabAtkins> | Some of us do, sure. It's always good manners to credit, though, for the people who aren't already aware of an awesomic comic. |
| 02:12 | <erlehmann> | s/sig/avatar/ |
| 02:12 | <erlehmann> | okay.jpg |
| 02:13 | <TabAtkins> | It gives you an opportunity to evangelize a bad-ass comic. ^_^ |
| 02:13 | <erlehmann> | i am actually right now reading through “hark, a vagrant” |
| 02:13 | <erlehmann> | and must admit i have no idea what the title says |
| 02:14 | <TabAtkins> | The title? |
| 02:14 | <TabAtkins> | Oh, the phrase "hark, a vagrant"? |
| 02:14 | <erlehmann> | yesss |
| 02:14 | <TabAtkins> | It's a phrase from an early bio comic. Kate is walking past a homeless dude, who shouts for her. She responds (to no one in particular), "Hark, a vagrant!". |
| 02:14 | <TabAtkins> | Where "hark" is an archaic term meaning "Hey!" |
| 02:15 | <erlehmann> | what is a vagrant |
| 02:15 | <erlehmann> | then |
| 02:15 | <TabAtkins> | A homeless dude. |
| 02:15 | <erlehmann> | intredasting. |
| 02:16 | <erlehmann> | so i learned something |
| 02:16 | <erlehmann> | thanks, tab atkins. |
| 02:17 | <erlehmann> | i was just thinking that kate beaton could make erotic comics, but then i remembered the workings of jess fink. |
| 02:17 | <erlehmann> | screw that. |
| 02:18 | <TabAtkins> | Hey, I kinda like Chester 5000. |
| 02:19 | <erlehmann> | i would like to draw that way. alas, i can only make icons and pixel graphics :/ |
| 02:20 | <erlehmann> | in before over 9000 years of mastering |
| 02:20 | <erlehmann> | the skill of drawing |
| 02:29 | <annevk> | ooh, roc is at that conference today |
| 02:29 | <annevk> | that's too bad |
| 02:29 | <annevk> | can someone else answer my fullscreen questions? |
| 02:29 | <annevk> | (if so, see the WHATWG list) |
| 02:39 | <zewt> | personally I don't understand the "full screen without input" idea--that's crippling to essentially every usage, i can't imagine anyone ever using it |
| 02:39 | <zewt> | even a trivial video player wants space to pause |
| 02:40 | <annevk> | you get some keyboard always |
| 02:40 | <annevk> | but even then I fail to see the concern given the various things that are in place |
| 02:42 | <zewt> | the entire "go fullscreen first and ask if that was okay" model that it seems everyone is implementing is really worrisome |
| 02:43 | <zewt> | i don't want sites taking my browser window fullscreen to show a gigantic interstitial ad (at which point the browser asking permission is basically going "wow, that was annoying, wasn't it?") |
| 02:43 | <zewt> | i'm surprised i havn't seen sites do that with flash, though i guess i wouldn't since i flashblock by default |
| 02:43 | <annevk> | it's going to use the "trusted click" model for sure |
| 02:43 | <zewt> | that doesn't help, it just moves the annoyance to the first time you click anywhere |
| 02:44 | <annevk> | i guess some sites do that with popups these days |
| 02:44 | <zewt> | lots of pages listen for clicks on document to open a popup yeah what you said |
| 02:44 | <zewt> | the only benefit, IMO, to the only-on-click model is preventing infinite recursion |
| 02:45 | <zewt> | not so much preventing the annoyance itself, just keeping it from exploding |
| 02:45 | <zewt> | (and it's clearer than magic behind-the-scenes heuristics like "has this site opened a popup/tried to go fullscreen already in the last few seconds") |
| 02:48 | <annevk> | so you prefer upfront confirmation? |
| 02:49 | <zewt> | as long as there's an easy "always allow for this site" option, yeah |
| 02:50 | <annevk> | ugh |
| 02:50 | <zewt> | the API already allows it, but it seems like both FF and Chrome are going the ask-afterwards route |
| 02:50 | <annevk> | seems better to just nuke it permanently for the few sites that abuse it |
| 02:50 | <zewt> | it's the sort of thing that seems really tempting for low-grade advertisers to push sites to do |
| 03:12 | <erlehmann> | annevk, with geolocation, upfront notification is working. |
| 03:12 | <erlehmann> | also, what zewt said. madness. |
| 03:15 | <zewt> | what happens with ask-after notifications if a page goes fullscreen, shows an ad for 2-3 seconds, then exits before the user has a chance to click "stop doing that"? browsers would also need to keep the "allow/block fullscreen" question open after exiting fullscreen to prevent that |
| 04:13 | <annevk> | zewt, sure |
| 04:13 | <annevk> | erlehmann, you want to optimize for the positive case |
| 04:13 | <annevk> | these DOM Level 3 Events emails sure are entertaining |
| 04:18 | <erlehmann> | annevk, too many asshats out there. let me be the first to abuse SUDDEN FULLSCREEN MADNESS. |
| 04:18 | <erlehmann> | just think: this, combined with shock sites. |
| 04:31 | <annevk> | erlehmann, yeah I totally see myself browsing shock sites all day |
| 05:07 | <annevk> | heycam|away, hey |
| 05:08 | <annevk> | heycam|away, I guess we could reuse Error, but is it worth it? |
| 05:21 | <annevk> | is cpearce on IRC? |
| 05:43 | <zewt> | synchronous calls waiting for an animation to complete? D: |
| 06:42 | <zcorpan> | s/may only be called/must be called/ is a "worthy grammatical clarification"? ok |
| 06:59 | <Hixie> | zcorpan: if by "worthy grammatical clarification" you mean "correction for bogus use of RFC2119 terms" :-) |
| 07:08 | <zcorpan> | d3e is full of it it seems |
| 07:12 | <Hixie> | d3e? |
| 07:13 | <Hixie> | oh dom events? |
| 07:13 | <Hixie> | hm |
| 07:18 | <Hixie> | what's the state of the art in terms of networking protocols to transfer responsibility for a token from one server on the Internet to another server? |
| 07:18 | <Hixie> | that is, is there an established solution, or is it a known unsolveable problem, or something else? |
| 07:19 | <Hixie> | (that is, say there are two servers A and B, and A currently has ownership/responsibility of a token X, and wants to transfer it to B, but wants B to only take it if B knows that A knows that B has taken it) |
| 07:20 | <Hixie> | (abarth?) |
| 07:20 | <abarth> | Hixie: sorry, playing bridge |
| 07:20 | <abarth> | send email |
| 07:20 | <Hixie> | nothing important, just my question above |
| 07:21 | <Hixie> | not a web standard thing |
| 07:21 | <Hixie> | enjoy your bridge :-) |
| 07:54 | <RobbertAtWork> | I had this idea about the Component Model: if you allow to register existing tagNames without the x- prefix, web pages could reserve the privilege of creating scripts (against XSS). (function() { var script = HTMLScriptElement; var secretTagName = randomTagName(); Element.register("script", function(){}); Element.register(secretTagName, HTMLScriptElement); })() |
| 07:55 | <RobbertAtWork> | execute this in the <head> and no scripts after that will be evaluated. |
| 09:31 | <annevk> | zcorpan, good question |
| 09:31 | <annevk> | zcorpan, sicking suggested we keep it because browsers keep the state around internally |
| 09:32 | <zcorpan> | the isWhiteSpace thing? |
| 09:32 | <annevk> | yes |
| 09:32 | <foolip> | Hixie, rniwa, Opera support document.getItems(), but not the spec changes that were made a few days ago of course |
| 09:33 | <annevk> | I'll add a comment to https://bugzilla.mozilla.org/show_bug.cgi?id=687422 |
| 09:57 | <RobbertAtWork> | annevk: I always though element content whitespace was a different thing |
| 09:57 | <RobbertAtWork> | [ |
| 09:58 | <RobbertAtWork> | http://www.w3.org/TR/REC-xml/#dt-elemcontent says element content is content of elements that must contain only child elements |
| 09:58 | <RobbertAtWork> | so the contents of a <ul> element for example |
| 09:58 | jgraham | reads a little backscroll, finds js being described as a "functional" language, gives up |
| 09:58 | <annevk> | yeah it is a different thing, but browsers never implemented the attribute based on semantics of the language so it became to mean isWhiteSpace as far as implementations go |
| 09:58 | <RobbertAtWork> | so I figured for white-space text nodes between <ul> and <li> isElementContentWhitespace would be true |
| 09:59 | <RobbertAtWork> | while for whitespace text nodes in <li> elements it would be false |
| 09:59 | <annevk> | yeah |
| 10:00 | <RobbertAtWork> | So I'd say: add isWhiteSpace to the DOM4 standard, rename the current implementations, and let isElementContentWhitespace return false as long as it isn't implemented |
| 10:00 | <annevk> | is the latter useful? |
| 10:01 | <annevk> | or the former for that matter, nobody brought up a use case yet :) |
| 10:01 | <RobbertAtWork> | yeah, it would fix implementations that depend on it's functionality |
| 10:02 | <annevk> | it's probably going to return undefined |
| 10:02 | <annevk> | as it already does in some browsers |
| 10:03 | <Philip`> | jgraham: Would you prefer it to be called a dysfunctional language? |
| 10:04 | <jgraham> | Philip`: Depends how annoyed I am with it at the time :) |
| 10:04 | <RobbertAtWork> | XML Information Set says on the subject of element content whitespace "If there is no declaration for the containing element, …, this property has no value", so I guess null or undefined is okay with me, although null is more like other DOM properties |
| 10:06 | <annevk> | RobbertAtWork, I mean we would remove it for now |
| 10:07 | <RobbertAtWork> | annevk: fine |
| 10:11 | <RobbertAtWork> | annevk: isWhiteSpace is quite useful for minifying, for scripts that know what whitespace is ignorable. Xopus uses it to minimize the amount of nodes in memory, removes the ignorable whitespace according to the current Schema |
| 10:16 | <zcorpan> | wouldn't you want to minify on the server side? |
| 10:19 | <RobbertAtWork> | wouldn't you want to use the DOM for that? |
| 10:20 | <RobbertAtWork> | using the DOM is the easiest approach for several minifying passes |
| 10:20 | <zcorpan> | using the DOM for that seems horrible |
| 10:20 | <RobbertAtWork> | removing all type attributes from style elements is way easier using DOM than regexp |
| 10:21 | <zcorpan> | you're not limited to DOM and regexp on the server |
| 10:23 | <zcorpan> | anyway, i think we shouldn't design the DOM around server-side use cases |
| 10:23 | <zcorpan> | doing so introduced a lot of bloat to the DOM that we're now trying to clean up in DOM4 |
| 10:23 | <RobbertAtWork> | then I want to minify on the client |
| 10:24 | <zcorpan> | why? |
| 10:33 | <RobbertAtWork> | zcorpan: I'll get back to you on that, have to go now |
| 10:35 | <zcorpan> | k |
| 11:37 | <jgraham> | Hixie: BTW one concreate reason to prefer DOM-in-JS is that it may provide performance wins. JS-C++ boundaries are generally bad for perf. especially as you can't JIT across them |
| 11:43 | <smaug____> | (that argument was covered last night.) |
| 11:44 | <smaug____> | (and it is very valid one, although kind of implementation detail) |
| 11:44 | <jgraham> | Oh, like I say hundreds of lines of argument were too much to read |
| 11:45 | <smaug____> | :) |
| 11:47 | <jgraham> | I'm not sure dismissing it as an implementation detail is valid though; implementation details can be critical particularly if they are a fundamental characteristic of all sucessful implementations |
| 12:49 | <gsnedders> | (Esp. with a tracing JIT DOM-in-JS should be able to provide good perf, because you'll simply cut out a lot of the complexity) |
| 12:52 | <jgraham> | What's extra sensory perception got to do with anything? |
| 12:53 | <gsnedders> | … |
| 12:54 | <jgraham> | o |
| 12:54 | <jgraham> | ^man with third eye |
| 12:54 | <jgraham> | Unless you are using a proportionally spaced font for irc, in which case it sucks to be you |
| 13:35 | <matjas> | what’s the appropriate markup for stuff like “Note: foo bar baz” or “Update: foo bar baz” in blog posts? currently i just use <p> for both, with an extra <ins> for updates |
| 13:35 | <matjas> | perhaps <small> would be better? |
| 13:36 | <annevk> | <p> seems fine |
| 13:36 | <annevk> | in specs we use <p class=note>foo bar baz |
| 13:36 | <annevk> | we don't do updates |
| 13:37 | <matjas> | cool, thanks |
| 13:49 | <annevk> | oooooh yeeah |
| 13:49 | <annevk> | Xbox 360 is finally getting server-side storage for gamertags and such |
| 15:41 | <annevk> | discussing standards on twitter sucks badly |
| 15:41 | <annevk> | can someone make it stop? |
| 15:42 | <annevk> | Google+ sort of works, but excludes Ms2ger; mailing lists really would be best |
| 15:43 | <jgraham> | echo '127.0.0.1 twitter.com' >> /etc/hosts |
| 15:46 | <Philip`> | The W3C ought to develop a social network platform designed for discussing and developing specifications, rather than expecting people to use antiquated things like mailing lists or inappropriate things like Twitter |
| 15:47 | <astearns> | tldr: gamily standards! |
| 15:47 | <astearns> | *gamify |
| 15:48 | <hsivonen> | annevk: yeah, I can't figure out how slightlyoff_afk wants node renames to behave or what the use case for node renames is |
| 15:48 | <annevk> | he just wants everything to be a function |
| 15:49 | <annevk> | and then since new Element() would be pointless, he suggested something about a writable local name, which of course would not work, but never mind that |
| 15:50 | <hsivonen> | it would be kinda unfortunate if the platform implementation couldn't be organized into classes the way it can be organized if a node can't change what element it represents |
| 15:51 | <hsivonen> | node renaming is like every element being input type=foo |
| 15:52 | <jgraham> | Making the interface of an Element immutable seems like an important invariant to preserve |
| 15:53 | <annevk> | anyway I doubt he really wants to change that |
| 15:54 | <annevk> | he's just trying to make his vague case for constructors everywhere |
| 15:56 | <hsivonen> | "constructors everywhere" isn't a use case. what's the motivation for constructors everywhere? is there a blog post about this? |
| 16:05 | <annevk> | yes, but I didn't get it |
| 16:05 | <annevk> | I think it has something to do with the idea that the DOM has to be written in terms of ECMAScript |
| 16:05 | <annevk> | and ECMAScript does not know objects you cannot new? |
| 16:06 | <annevk> | but how this helps anyone... |
| 16:06 | <jgraham> | http://www.w3.org/mid/CANr5HFU5PVs0ad_KDE+zVjKgrKFfpF_E0zFvVPx7BymJc9nedQ⊙mgc |
| 16:06 | <jgraham> | Well of course you can create objects that you cannot new using ES |
| 16:10 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1186 is a trivial example |
| 16:11 | <jgraham> | The problem seems to be a belief that not being able to do new HTMLFooElement() even where that doesn't make sense, is screwing over authors |
| 16:12 | <jgraham> | In general having constructors where they make sense doesn't seem like a bad idea |
| 16:13 | <jgraham> | They don't really make sense on HTMLElement and "subclasses" though becase there isn't a 1:1 mapping between interface objects and instances |
| 16:14 | <jgraham> | (that is, not every instance you might want to create has a corresponding interface object) |
| 16:17 | <annevk> | yeah, I think we should add them for Text/Comment/Document |
| 16:17 | <annevk> | dunno about Element |
| 16:44 | <dglazkov> | good morning, Whatwg! |
| 16:44 | <Hixie> | mornin' |
| 16:44 | <smaug____> | hyvää iltaa |
| 16:45 | <dglazkov> | anything with umlauts is cool by definition |
| 16:46 | <jgraham> | Finnish isn't a real language it's just a conspiracy to make the rest of the world feel stupid |
| 16:46 | <smaug____> | :p |
| 16:46 | <Hixie> | what's vietnamese then? :-) |
| 16:49 | <astearns> | a conspiracy to prop up the diacritic industry |
| 16:50 | <miketaylr> | a purveyor of fine sandwiches |
| 16:50 | <jgraham> | Oh is that the basis you were comparing on? I was going to say that vietnamese didn't seem very gramatically complex |
| 16:51 | <jgraham> | (although I only glanced at wikipedia, so maybe it is) |
| 16:51 | <jgraham> | whereas the dead giveaway that Finnish is a conspiracy is that they go around talking about 15 cases for nouns |
| 16:51 | <astearns> | omniglot tells me that Vietnamese has six tones. that seems complex |
| 16:51 | <jgraham> | To speak, sure |
| 16:52 | <jgraham> | I rather suspect it would entirely exclude me from the set of potential vietnamese speakers, for example |
| 16:54 | <scor> | Hixie: what was the rationale for conflatin type and vocabulary into @itemtype? |
| 17:02 | <Hixie> | scor: i don't understand the question |
| 17:19 | <hsivonen> | the rules under "If the element is a time element with a @datetime attribute" in https://dvcs.w3.org/hg/htmldata/raw-file/24af1cde0da1/microdata-rdf/index.html illustrate what's wrong with RDF datatyping |
| 17:20 | <Hixie> | hey, i'm an author on that document |
| 17:20 | <Hixie> | go figure |
| 17:20 | <Hixie> | i didn't even know it existed! |
| 17:21 | <hsivonen> | Hixie: is part of the text copied and pasted from something you wrote? |
| 17:21 | <Hixie> | i assume so |
| 17:23 | <scor> | Hixie: sorry, got side tracked. when you took RDFa and designed microdata, what drew you to combine the concepts of vocabulary namespace with the type (in @itmetype)? |
| 17:25 | <scor> | Hixie: RDFa distinguishes the two, but afaik microdata conflates them (this is not a critizism, I just trying to understand what was the rational for combining them) |
| 17:26 | <gkellogg> | About @datetime data typing, I didn't invent this, but found it in a tracker bug I thought Hixie had agreed with; it makes sense to me anyway. |
| 17:26 | <Hixie> | scor: i didn't take RDFa to design microdata |
| 17:27 | <hsivonen> | http://lists.w3.org/Archives/Public/public-html-xml/2011Oct/0022.html |
| 17:27 | <gkellogg> | About the new Microdata-RDF doc, Jeni asked me to resurrect it, and of course, it borrows heavily from the previous Microdata spec |
| 17:27 | <Hixie> | gkellogg: the text hsivonen mentions is the right way to map <time> to RDFa but it illustrates what's wrong with RDF datatyping nonetheless |
| 17:27 | <Hixie> | gkellogg: (note, <time> is likely going away) |
| 17:28 | <Hixie> | scor: RDF doesn't really have a concept of a vocabulary at the syntax level |
| 17:28 | <annevk> | hsivonen, you posted that for entertainment I hope? |
| 17:29 | <gkellogg> | Hixie: I heard that, to be replaced by <data> I suppose? |
| 17:29 | <annevk> | surprised nobody has replied with, "Agreed, it's called XHTML5, you can use it today." |
| 17:29 | <annevk> | or some such |
| 17:29 | <Hixie> | gkellogg: yeah, something like that |
| 17:30 | <Hixie> | gkellogg: wouldn't affect the spec you're writing much except you'd have to add more types to the list hsivonen mentioned (and rename the element and attribute names, of course) |
| 17:30 | <gkellogg> | Martin Heff has complained about the lack of data typing in Microdata, and would like to see a way to infer this from referenced vocabularies. We considered this for RDFa but rejected it. |
| 17:31 | <gkellogg> | Hixie: I intend to follow both HTML5 and Microdata specs as they continue to evolve. Your participation, direct or indirect would be welcome. |
| 17:31 | <annevk> | Hixie, I looked at the fullscreen stuff and integrating it directly into HTML might not be a bad idea |
| 17:31 | <Hixie> | gkellogg: microdata has data typing, it's just in the vocabularies rather than in the data (since otherwise you have to repeat it with every property use, which seems silly) |
| 17:32 | <annevk> | Hixie, then again, I can probably define most methods as a separate thing and HTML would just define things such as <iframe allowfullscreen> |
| 17:32 | <Hixie> | annevk: let's do that (the split), i'd rather not have to start defining rendering if i can help it |
| 17:32 | <Hixie> | annevk: the rendering section is bad enough |
| 17:33 | <gkellogg> | Hixie: to be more specific, rules for creating RDF from Microdata with data typed literals. Vocabulary-based typing relies on the processor to do this on it's own, without it's being stated explicitly in the generated RDF. Otherwise, I agree that the way to do it is through datatype inference. |
| 17:36 | <Hixie> | gkellogg: no i mean the microdata vocabulary, not the rdf vocalubary. The microdata to RDF convertor would have to know about the microdata vocabulary to add the data typing |
| 17:36 | cygri | how about strongly deprecating? |
| 17:36 | <Hixie> | gkellogg: (there's not really much point in processing data for which you don't know the vocabulary, anyway, it's not like you can actually do anything with the type information in that case) |
| 17:36 | cygri | </joking> |
| 17:37 | cygri | is an idiot. wrong chat window |
| 17:38 | <gkellogg> | In my spec, there's always a vocabulary as in every @itemprop results in a URI. If that URI can be dereferenced and it is an RDFS (or OWL) schema, you could use it to find range information that could be used for datatype inference, but this isn't the SWIG discussion list :) |
| 17:39 | <scor> | Hixie: in microdata, is there any difference between a vocabulary and a type? it seems the type in @itemtype defines the vocabulary |
| 17:39 | <Hixie> | scor: a vocabulary in microdata is a group of short names that are defined in a spec and grouped under one (or more) type(s) |
| 17:40 | <Hixie> | scor: it's not equivalent to the type concept in rdf |
| 17:40 | <Hixie> | scor: which is just another property value |
| 17:40 | <scor> | Hixie: so would you say that a microdata vocabulary has the same URI as the type or not? |
| 17:40 | <Hixie> | scor: a vocabulary in microdata doesn't have a url |
| 17:41 | <scor> | ah, so how is it defined? by its popular name? |
| 17:41 | <Hixie> | the same way, e.g., HTML's vocabulary is defined. In a spec. |
| 17:41 | <hsivonen> | annevk: I posted it out of bewilderment about how XHTML5 connects to "Obama Care" |
| 17:44 | <gkellogg> | hsivonen: I missed your discussion on mapping <time> datatypes, can you re-post? |
| 17:45 | <Hixie> | gkellogg: http://krijnhoetmer.nl/irc-logs/whatwg/20111013#l-1181 |
| 17:46 | <gkellogg> | Hixie: sorry, I can't fix RDF data typing, it is what it is :) |
| 17:46 | <jgraham> | hsivonen: He could have been honest and titled the email "XHTML5: THINK OF THE CHILDREN!" |
| 17:46 | <Hixie> | gkellogg: i highly recommend ignoring RDF in general :-) |
| 17:47 | <gkellogg> | Hixie: I gathered that :) Sadly, RDF tends to be a kind of addiction, perhaps we need a 12-step program :) |
| 17:49 | <Hixie> | can't help you there :-) |
| 17:49 | <jgraham> | gkellogg: Don't they ask about that at immigration? "Are you now, or have you ever been, addicted to RDF? YES [ ] NO [ ]" |
| 17:51 | <scor> | lol. is it a crime nowadays? |
| 18:10 | <hsivonen> | gkellogg: http://krijnhoetmer.nl/irc-logs/whatwg/20111013#l-1181 was all I said |
| 18:12 | <gkellogg> | hsivonen: got it, thanks. The main problem here is that there's really no way, except if the property range can be narrowed, do do _any_ datatype inference without performing datatype inference from the corresponding vocabulary description. If there's another way to get better datatype information out of a doc without relying on external resources, I'd like to know. |
| 18:15 | <hsivonen> | gkellogg: I wasn't suggesting that the algorithm was wrong |
| 18:16 | <hsivonen> | gkellogg: I was suggesting that RDF could do without having datatyping in the first place |
| 18:18 | <Hixie> | when i tell a group that use cases would be helpful if they want the spec changed, after three years of telling them this, they should not respond with "ah, thanks, that's helpful, we'll look for use cases" as if this was the first time they'd heard that use cases might be the best way to give feedback. |
| 18:19 | <gkellogg> | Hixie: W3C HTML Data TF is specifically chartered to identify such use cases. |
| 18:20 | <Hixie> | jeni's reply suggested that the idea of getting use cases was a novel one |
| 18:20 | <Hixie> | so if you're right, apparently not everyone has read the charter |
| 18:22 | <gkellogg> | Hixie: http://www.w3.org/2011/htmldata/track/actions/7 |
| 18:23 | <Hixie> | gkellogg: http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0068.html "OK, that's helpful" |
| 18:23 | <Hixie> | anyway |
| 18:23 | <Hixie> | i'm not complaining or anything |
| 18:24 | <Hixie> | use cases are great |
| 18:24 | <Hixie> | i've been asking for them for forever now |
| 18:27 | <gkellogg> | Hixie: experience with other groups indicates that collecting use cases is always problematic; it seems like a chore. However, as you point out, you can't really derive requirements without use cases. But in their absence, you may need to draw on anecdotal evidence. |
| 18:27 | <Hixie> | no, in their absence, you don't do anything. :-) |
| 18:31 | <hsivonen> | Why does MapsGL use WebGL for 2D vector graphics maps? |
| 18:31 | <Hixie> | what does it use? |
| 18:31 | <zewt> | why not? |
| 18:31 | <hsivonen> | instead of using SVG or Canvas 2D |
| 18:31 | <Hixie> | ah, dunno |
| 18:31 | <hsivonen> | zewt: WebGL isn't a 2D graphics API |
| 18:31 | <zewt> | sure it is |
| 18:31 | <zewt> | 2d is a subset of 3d |
| 18:32 | <Hixie> | probably easier to just code 2d as a special case of 3d? |
| 18:32 | <zewt> | opengl is very good at 2d graphics |
| 18:32 | <Hixie> | i honestly have no idea |
| 18:32 | <hsivonen> | zewt: well, MapsGL fails at anti-aliasing where SVG or Canvas 2D would give it "for free" |
| 18:32 | <hsivonen> | Hixie: maybe the reason indeed is using the same thing for both streets and the buildings |
| 18:33 | <hsivonen> | so the rendering tech doesn't change when zooming in to the building level |
| 18:33 | <zewt> | you can open antialiased webgl contexts (may or may not actually be supported, of course) |
| 18:33 | <Hixie> | drawing a map is quite a complicated problem, so i wouldn't be surprised if it was just a matter of wanting to only do it once |
| 18:34 | <zewt> | (easy to do 2d vector AA in software on anything; no so easy with OpenGL if the underlying hardware isn't good at it) |
| 18:34 | <hsivonen> | anyway, great to see Maps features that previously required Android or Flash Player now supported on the Open Web Platform |
| 18:34 | <Hixie> | indeed |
| 18:36 | <zewt> | also if you already have GPU-based map rendering for some other platform, porting to WebGL is probably easier |
| 18:37 | <arv__> | One of the reason to use WebGL over canvas/svg is performance |
| 18:37 | <hsivonen> | I wonder how long it will take for a WebGL version of Google Earth to emerge |
| 19:11 | <gsnedders> | hsivonen: Well, supported on the "Open Web" if your UA string is correct. |
| 19:12 | <gsnedders> | (which I'm not sure really counts as open web, thus the scare quotes) |
| 19:49 | <manu-db> | hsivonen, dglazkov, Hixie: Any public feedback on http://convergence.io/ from browser manufacturers yet? (removing CAs via Network Perspectives and Notaries?) |
| 19:57 | <hober> | gsnedders: indeed |
| 20:44 | <Hixie> | Philip`: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14421 |
| 21:32 | <adtykfhyipoh> | hey |
| 21:32 | <adtykfhyipoh> | I've got a question |
| 21:34 | <adtykfhyipoh> | sicking |
| 21:34 | <adtykfhyipoh> | hello |
| 21:34 | <sicking> | hello |
| 21:34 | <adtykfhyipoh> | I have a question about javascript |
| 21:34 | <adtykfhyipoh> | I need to save an array of the image tags on a website (var images = document.getElementsByTagname("img");) and I need it stored in another array |
| 21:35 | <adtykfhyipoh> | so that when all the images are changed, the copy of the images array is unchanged |
| 21:41 | <zewt> | irc is hard |
| 21:43 | <bga_> | dom has so many shortcuts. doc.images, doc.links, window[id] etc |
| 21:43 | <bga_> | but ppl use long пУИЕТ |
| 21:44 | <bga_> | *gEBTN |
| 21:44 | <bga_> | Ж. |
| 21:44 | <bga_> | *:/ |
| 21:44 | <bga_> | stupid autoswitcher |
| 21:58 | <smaug____> | window[id] works in general only in quirks mode |
| 21:58 | <smaug____> | (and it should be actually removed since it is so error prone) |
| 21:59 | <bga_> | but its handy :) |
| 22:08 | <ojan> | TabAtkins: do you know any of the editors of http://dev.w3.org/csswg/css3-writing-modes ? |
| 22:08 | <ojan> | TabAtkins: I'd like to see the spec change for http://lists.w3.org/Archives/Public/www-style/2011Sep/0375.html |
| 22:08 | <ojan> | TabAtkins: not sure who/how to nag about it |
| 22:45 | <smaug____> | ojan: so you want fantasai |
| 22:50 | <ojan> | smaug____: oh? is she one of the editors? |
| 22:50 | ojan | doesn't know her real name |
| 22:50 | <smaug____> | ojan: the spec says Elika |
| 22:51 | <ojan> | smaug____: thx |
| 22:51 | <smaug____> | ojan: anyway, I copy-pasted your comment to her (she is in moznet) |
| 22:51 | <smaug____> | though, apparently afk |
| 22:52 | <ojan> | smaug____: thanks! it's nothing urgent, but just wanted to make sure it doesn't get lost. |
| 23:12 | <Hixie> | heycam: ping |
| 23:12 | <Hixie> | heycam: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13093 |
| 23:58 | <Hixie> | man, my css-fu these days is week |
| 23:58 | <Hixie> | weak even |
| 23:59 | <Hixie> | what's the practical difference between a presentational attribute css rule and a UA stylesheet css rule? just that the user style sheet overrides the UA one but not the pres hints? |