03:01 | <zewt> | holy hell |
03:01 | <zewt> | opera stole my .ogg file extension |
03:02 | <zewt> | i thought the 90s file association wars were over :( |
03:03 | <smaug____> | nowadays it is usually more like "default browser" war |
03:03 | <zewt> | opera just landed dangerously close to quicktime in my mental software quality map |
03:10 | <zewt> | maybe foobar forgot to grab it to begin with? dunno, very bizarre in any case (dear opera: you're a browser) |
07:14 | <annevk> | ms2ger, hmm yeah, you'd need to have access to dev.w3.org |
07:27 | <annevk> | Hixie, did you mean the suggestion about treating attributes starting with "on" specially? I suppose we could do that |
07:28 | <Hixie> | hm if that was the suggestion it sounds suboptimal |
08:06 | annevk | reads the original thread again |
08:07 | <annevk> | oh |
08:08 | <annevk> | Hixie, so TabAtkins mentioned MooTools which has a magic attribute called "events" which takes its own object |
08:09 | <annevk> | though in his follow up he thought using magic on* was better... |
08:17 | <annevk> | the other alternative was using another argument for it |
09:13 | <annevk> | other problems with just object |
09:13 | <annevk> | they theoretically unordered |
09:13 | <annevk> | are* |
09:14 | <annevk> | but order is detectable for both attributes and event handlers |
09:56 | <annevk> | I wonder, if we introduce new Text(); how much is the DOMString stuff needed? |
09:56 | <annevk> | do we want node.appendChild("test") / new Text("test") / both? |
09:59 | <annevk> | I'm guessing all of it... |
10:43 | <annevk> | Acid3 updated, let the DOM simplifications commence |
10:44 | <Ms2ger> | \o/ |
12:18 | <rabbi1> | where can i find good ajaxcrud, simple and explained ..... |
14:04 | <llrcombs> | well, I think it's That Time |
14:04 | <llrcombs> | IE10/Metro is removing plugin support, and it's really time to define One Codec to Rule Them All |
14:05 | <Philip`> | There's already plenty of One Codecs defined |
14:05 | <llrcombs> | Chrome and FF won't budge on open-source-only codecs no matter how hard anyone tries, so it seems that WebM should be the One Codec that all browsers support |
14:09 | <Philip`> | Someone should suggest that idea to Apple and Microsoft |
17:08 | <Hixie> | annevk: hmm |
17:09 | <Hixie> | var e = Element.create('button', { name: 'command', value: 'search', disabled: true, onclick: function (event) { ... } }, 'Search'); |
17:09 | <Hixie> | annevk: maybe just decide how it works based on the value of the entry in the dictionary |
17:10 | <Hixie> | annevk: string = set content attribute, boolean true = set content attribute to '', boolean false = do nothing, function = set a bubbling event listener for the entry's name minus 'on'? |
17:11 | <Ms2ger> | That sounds pretty magical |
17:11 | <Hixie> | the event handler part is, yeah |
17:11 | <Hixie> | dunno what else to do |
17:12 | <Ms2ger> | Passing an extra object for event handlers would be less magical, but probably also less convenient |
17:13 | <Hixie> | actually it wouldn't be that inconvenient, if it came before the array still |
17:13 | <Hixie> | so long as we can distinguish 'object' from Element/string/Array/Node |
17:14 | <Hixie> | that might be non-trivial in idl |
17:14 | <Hixie> | we should look at use cases, see exactly what it looks like |
17:15 | <zewt> | Hixie: if it's a function, set the property by that name? avoids the "remove on" magic |
17:15 | <Hixie> | we don't want to be able to set arbitrary properties |
17:15 | <Hixie> | that has all kinds of weird side-effects |
17:16 | <zewt> | it'd be weird if "'onclick': func" didn't actually affect the onclick property |
17:16 | <Hixie> | e.g. consider Element.create('div', { innerHTML: function () { }, innerText: function () { } }, ['']); |
17:16 | <zewt> | eg. translating it to addEventListener("click", ...) and onclick ending up null would be weird |
17:16 | <Hixie> | yeah i agree that you want it affecting the 'onfoo's |
17:17 | <Ms2ger> | And we'll need to figure something out for the ordering as well |
17:18 | <Hixie> | we only need to worry about ordering if we allow arbitrary properties to be set |
17:18 | <Hixie> | which i recommend against |
17:19 | <Ms2ger> | Also for attributes |
17:19 | <Hixie> | why? |
17:19 | <Hixie> | the parser sets them and creates the element atomically |
17:19 | <Ms2ger> | That's fiction |
17:19 | <Hixie> | there's no order |
17:19 | <Hixie> | no it's not |
17:19 | <Hixie> | there's no way to detect the order |
17:19 | <Ms2ger> | There is |
17:19 | <Ms2ger> | element.attributes |
17:19 | <Hixie> | only in buggy browsers |
17:20 | <Hixie> | element.attributes should define its own order |
17:20 | <Ms2ger> | Right, the order in which they're set |
17:20 | <Hixie> | they're not set in an order |
17:22 | <Philip`> | Aren't there already lots of friendly DOM-wrapper APIs that could be copied from, instead of inventing something new? |
17:22 | Philip` | doesn't know of any but doesn't see why they wouldn't exist if people cared about it |
17:23 | <zewt> | there was a list at the beginning of the thread, I think |
17:23 | <zewt> | jquery, etc |
17:24 | <Ms2ger> | jquery is hardly where I'd look for good API design |
17:27 | <bga_> | Hixie btw instead new Element(name, optMap) you can do more orthogonally - new Element(name)._extend({innerHTML: '...'})._on('click', _foo) |
17:28 | <Hixie> | (Element.create(), not new Element()) |
17:28 | <bga_> | sorry |
17:28 | <Hixie> | chaining method calls seems a bit ugly to me |
17:28 | <Hixie> | but it's an option, certainly |
17:30 | <bga_> | Hixie but you can out {optMap} arg to _extend |
17:31 | <bga_> | c# has this init pattern iirc |
17:31 | <Philip`> | new Element("<button name='command' value='search' disabled onclick='...'>{caption}</button>", { "caption": "Search" }); - HTML already has a syntax for expressing DOM subtrees, it seems silly to invent a new one |
17:31 | <Hixie> | i don't see the advantage of Element.create('button').extend({name: 'foo'}).append('Submit'); over Element.create('button', {name: 'foo'}, 'Submit'); |
17:32 | <bga_> | but it looks as new Foo(){a: 1, b: 2} |
17:32 | <Hixie> | Philip`: what you just proposed _is_ new syntax |
17:32 | <zewt> | Philip`: err, you certainly don't want to be writing JS functions inside blocks of text inside jS |
17:32 | <zewt> | JS |
17:32 | <Hixie> | Philip`: assuming the {caption} part is magical |
17:33 | <Philip`> | Only mildly magical, to make it do something that's not redundant with innerHTML |
17:33 | <zewt> | well, string formatting is something that would be useful and that everyone keeps reinventing (though a different problem, of course) |
17:34 | <Hixie> | Philip`: how do you create an element whose contents are "a JS block is like {foo}." ? |
17:34 | <Ms2ger> | Of course it should be new Element("<button name='command' value='search' disabled onclick='...'>%s</button>" % ("Search",)) |
17:34 | <Hixie> | Philip`: how do you programatically decide whether an attribute is set or not? |
17:34 | <bga_> | Philip` ie already has this syntax |
17:34 | <Hixie> | Philip`: how do you reference a function for event handlers? |
17:35 | <Philip`> | new Element("<button onclick={handler}>", {"handler":function(){...}) plus sufficient magic, or something |
17:35 | <Hixie> | Philip`: moving away from innerHTML is what this discussion is all about |
17:35 | Philip` | notes that he hasn't read the discussion so he has no idea what the context is, and hasn't given this any non-trivial amount of thought |
17:35 | <zewt> | how do you add an attribute to the <button> definition programmatically? |
17:35 | <Hixie> | well if anne wants to spec an html parser in dom core, obviously i'll let him do it, but i am skeptical he'll want to :-) |
17:36 | <Philip`> | XML5 parser :-) |
17:36 | <Ms2ger> | I sure won't let him :) |
17:36 | <bga_> | Hixie advantage is you shouldnt copy if(optMap != null) this._extand(optMap) in every constructor |
17:37 | <bga_> | orthogonallity |
17:37 | <Hixie> | bga_: why is that an advantage? a single pointer comparison is trivial in cost. |
17:38 | <Hixie> | bga_: plus the whole point here is creating an element _with_ arguments, if you don't want arguments you can already do document.createElement('foo'); |
17:38 | <zewt> | in principle, the whole "set this bundle of properties" thing could be detached from creation, if there's no real need for them to be atomic |
17:39 | <zewt> | createElement("a").set({href: "url"}) |
17:39 | <bga_> | Hixie you can forget this magic line of code in some constructor. but main idea to move from new Point(x, y) to new Point(){x: x, y: y} form. |
17:40 | <bga_> | create element and set properties namely |
17:40 | <Ms2ger> | new Point({x: x, y: y}), I hope |
17:40 | <zewt> | ew |
17:41 | <Hixie> | bga_: if you want the JS language itself to change, I recommend bringing it up with the JS folk |
17:41 | <zewt> | (just an ugly example, a "point" constructor being the last thing you'd want that form for :) |
17:41 | <Hixie> | bga_: we're just proposing a new constructor within what JS already supports |
17:42 | <bga_> | Hixie ok. _extend() |
17:42 | <bga_> | or Ms2ger form |
17:42 | <bga_> | may be |
17:46 | <Hixie> | bga_: i still don't understand the advantage then |
17:49 | <bga_> | Hixie you want ta make same design bug as in Array#map, filter, some etc. each fn get context as last arg instead just force coder to use .bind if he want |
17:49 | <Hixie> | why is it a design bug? |
17:51 | <bga_> | you dont want to make obvious decomposition of functionality |
17:51 | <bga_> | fill object's properties is common task |
17:52 | <Hixie> | i have nothing against a generic syntax for filling an object's properties |
17:53 | <Hixie> | that's not what we're talking about here |
17:53 | <Hixie> | we're talking about a convenient constructor for creating an Element |
17:54 | <bga_> | ok |
17:54 | <Hixie> | i recommend bringing up the generic idea in the JS group |
17:54 | <Hixie> | if they add it, maybe we won't need a generic element constructor at all |
17:56 | <jarek> | not sure if I had understood your discussion correctly, but what's wrong with document.createElement()? |
17:56 | <jarek> | why add even more cruft to DOM? |
18:01 | <Ms2ger> | See the discussion on www-dom |
18:04 | <Hixie> | jarek: it's verbose |
18:05 | <jarek> | Hixie: it can be easily abstracted away with frameworks |
18:06 | <Ms2ger> | jarek, there's a list if you want to argue about the necessity |
18:06 | <Hixie> | jarek: why require that people use frameworks? |
18:09 | <bga_> | Hixie what do you think simple but strict(from oop view) about document.Div()? even w/o new |
18:09 | <bga_> | -about +about |
18:09 | <Hixie> | i don't understand the question |
18:10 | <bga_> | sorry. just document.Div() document.B() |
18:10 | <jarek> | are you planning to have spearate Element.createNS() constructor just like document.createElementNS()? |
18:11 | <jarek> | s/spearate/separate |
18:11 | <Hixie> | bga_: seems like it would mean a lot of constructors |
18:12 | <bga_> | document.Div(){id: 'foo'} if TC39 will accept this syntax |
18:12 | <Hixie> | jarek: no, iirc the proposal is to just support Element.create('foo'); for HTML, Element.create('svg:foo'); for SVG, and 'math:foo' for MathML. |
18:12 | <bga_> | Hixie but global scope already has alot of HTML*Element |
18:13 | <Hixie> | bga_: which don't map 1:1 to elements |
18:24 | <jarek> | what about E4X? Is it officially dead? |
18:25 | <Hixie> | unfortunately, seems that way. |
18:25 | <Hixie> | something like e4x would definitely be my preferred solution, personally |
18:26 | <Ms2ger> | brendan still objects to removing e4x from SpiderMonkey, IIRC |
18:27 | <jarek> | I doubt they will remove it from Firefox, this could break some extensions |
18:29 | <Ms2ger> | I've broken a lot of extensions, so that doesn't bother me much |
22:19 | <gsnedders> | OTW, I'd be in favour of e4x too, but pretty much including an entire XML tokenizer into the JS parser is somewhat ugly |
22:21 | <annevk> | So yeah, the question is whether we can distinguish between arrays and objects... |
22:23 | <gsnedders> | annevk: at what level? |
22:24 | <annevk> | IDL |
22:24 | <annevk> | method(string, object, object, array) |
22:24 | <annevk> | but you want these overloaded versions: |
22:24 | <annevk> | method(string, object, array) |
22:24 | <annevk> | method(string, array) |
22:25 | <annevk> | furthermore, array can also be DOMString |
22:25 | <annevk> | and ideally also a Node |
22:26 | <annevk> | object is always a JavaScript object |
22:26 | <annevk> | { ... } |
22:26 | <annevk> | I guess you can technically do it, but maybe not without upsetting the JavaScript gods |
22:26 | <gsnedders> | At a JS level, you could just check whether Array.prototype is in the prototype chain, or whether it was created through the array constructor (through [[HasInstance]] or whatever)… |
22:27 | <annevk> | I guess you can do the same for checking about it being a Node? |
22:27 | <annevk> | versus a {...} object? |
22:27 | <gsnedders> | But doing anything apart from treating arrays as if they were objects (which they are, they just have a different [[DefineOwnProperty]] which magically changes length) is evil. |
22:27 | <gsnedders> | annevk: Yeah. |
22:27 | <gsnedders> | Special-casing host objects is a lot less evil, too. |
22:27 | <annevk> | less evil? |
22:29 | <gsnedders> | Special-casing arrays v. other objects is evil. |
22:30 | <gsnedders> | {0: "a", 1: "b", 2: "c", length: 3} and ["a", "b", "c"] should be identical everywhere. |
22:32 | <annevk> | I guess it depends on how you view it |
22:32 | <gsnedders> | As an ES guy. :) |
22:32 | <gsnedders> | I don't care about your silly host objects. :) |
22:32 | <annevk> | I mean you can treat them identical and still make this work |
22:33 | <annevk> | you just say it's method(string, optional object, optional object, optional object) and deal with the specifics in the definition |
22:34 | <gsnedders> | ewwwww. |
22:36 | <gsnedders> | Just… just… forking based upon prototype chain or [[Class]] or [[HasInstance]] is evil, and only to be done when it's absolutely impossible to use generic objects. |
22:36 | <gsnedders> | (And that should be basically never, except when a host object deals with another host object) |
22:39 | <annevk> | can just look at the keys of the object my man :) |
22:39 | annevk | wants his convenient API damnit |
22:39 | <Hixie> | annevk: for the overloading, i think to do it you'd have to have a whole bunch of overloads, but you could do it |
22:40 | <annevk> | the magic properties could also work, but they are somewhat less appealing |
22:42 | <gsnedders> | annevk: And stop pretending I actually write ES, I just write testcases! :) |
22:43 | <annevk> | Hey you go around as the "ES guy" :p |
22:44 | <gsnedders> | No, that's farre :) |
22:55 | annevk | asks public-script-coord |
23:10 | <annevk> | gsnedders, well boo you |
23:10 | <annevk> | Mark Miller says we can! |
23:13 | <Hixie> | annevk: i said we could already :-P |
23:13 | <Hixie> | annevk: also, the last argument isn't just Node or string, it's Node or string followed by "..." |
23:15 | <annevk> | what does that mean? |
23:16 | <Hixie> | as in varargs |
23:17 | <annevk> | oh why is that useful? |
23:23 | <Hixie> | so you don't have to put the square brackets in |
23:24 | <Hixie> | Element.create('a', {href:'home.html'}, 'Go ', Element.create('em', 'Home!')); |
23:24 | <Hixie> | ...e.g. |
23:24 | <annevk> | interesting |
23:24 | <Hixie> | it's pretty easy to do it in webidl i think |
23:25 | <Hixie> | you just need to a lot of them |
23:25 | <Hixie> | to cover all the various combinations |
23:25 | <Hixie> | probably easier to just do it in prose |
23:25 | <annevk> | I'll think about it some more |
23:25 | <annevk> | there's no particular rush and http://www.reddit.com/r/IAmA/comments/kitcy/i_am_a_7_year_old_ama/ is really great |
23:26 | <annevk> | also, I need sleep |
23:26 | <annevk> | "What's the best advice you can give to my 2.5 year old son?" "A smacking and a beating." |
23:27 | <annevk> | the one under "What's your favorite joke?" too |
23:35 | <gsnedders> | annevk: That is brilliant. |
23:46 | <Philip`> | About type-based overloading: Can't you just use a different method name in each case? That seems more natural for a dynamically-typed language |