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