On Mon, Aug 8, 2011 at 9:17 AM, Tab Atkins Jr. wrote:
> On Mon, Aug 8, 2011 at 1:17 AM, Jonas Sicking wrote:
>> Is there a reason to support namespaced attributes at all? They are
>> extremely rare, especially on the web.
>>
>> Ideally I'd like to deprecate them, but I suspect that's not doable.
On Mon, Aug 8, 2011 at 1:17 AM, Jonas Sicking wrote:
> Is there a reason to support namespaced attributes at all? They are
> extremely rare, especially on the web.
>
> Ideally I'd like to deprecate them, but I suspect that's not doable.
> But I see no reason to support them in new APIs.
SVG requi
On 2011-08-08 11:34, Jonas Sicking wrote:
...
First off, that's infinitely more work to support a rarely used
feature than not supporting it at all.
Second, since that notation isn't used anywhere else, it's a pretty
big cost in brain print for users.
So no, I wouldn't say it's cheap.
...
Wel
On Mon, Aug 8, 2011 at 2:17 AM, Julian Reschke wrote:
> On 2011-08-08 10:17, Jonas Sicking wrote:
>>
>> On Mon, Aug 8, 2011 at 12:52 AM, Tab Atkins Jr.
>> wrote:
>>>
>>> On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooney
>>> wrote:
Third, is the order of attributes significant for XML name
On 2011-08-08 10:17, Jonas Sicking wrote:
On Mon, Aug 8, 2011 at 12:52 AM, Tab Atkins Jr. wrote:
On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooney wrote:
Third, is the order of attributes significant for XML namespace
declarations? eg does this:
mean the same thing as
? If not, including names
On 8/6/11, Charles Pritchard wrote:
[...]
> I've stated in prior threads, that unless the word is aria-* or data-*,
> properties are set on the element.
I see. But that's inherently inconsistent and mostly misleading
("attr" alludes to "attribute" not "usually property except when it's
data or ari
On Mon, Aug 8, 2011 at 12:52 AM, Tab Atkins Jr. wrote:
> On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooney wrote:
>> Third, is the order of attributes significant for XML namespace
>> declarations? eg does this:
>>
>> mean the same thing as
>>
>> ? If not, including namespaces in the attribute dic
On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooney wrote:
> Third, is the order of attributes significant for XML namespace
> declarations? eg does this:
>
> mean the same thing as
>
> ? If not, including namespaces in the attribute dictionary is fraught,
> because the iteration order of properties
On 8/6/2011 3:54 PM, Garrett Smith wrote:
On 8/6/11, Charles Pritchard wrote:
On 8/6/2011 9:05 AM, Dominic Cooney wrote:
Element.create looks neat. Three thoughts:
...
Let me briefly reiterate that I think we want *both* Element.create
and constructors; they have complementary uses.
I agree
On 8/6/11, Charles Pritchard wrote:
> On 8/6/2011 9:05 AM, Dominic Cooney wrote:
>> Element.create looks neat. Three thoughts:
> ...
>> Let me briefly reiterate that I think we want *both* Element.create
>> and constructors; they have complementary uses.
> I agree.
And for no reason, it seems.
>
On 8/6/2011 9:05 AM, Dominic Cooney wrote:
Element.create looks neat. Three thoughts:
...
Let me briefly reiterate that I think we want *both* Element.create
and constructors; they have complementary uses.
I agree.
Second, re: setAttribute vs setting properties, there might be types
other
Element.create looks neat. Three thoughts:
First, I think Element.create *and* constructors like new
HTMLDivElement(attributes, children) are both useful. Element.create is good
when you have a tag name in hand, are creating unknown elements, or are
creating elements that don’t have a specific con
On 8/4/11, Garrett Smith wrote:
[...]
ser-generated function function.
>
> The scope of handler attributes is explained in HTML 5, though
> incompletely:
> http://dev.w3.org/html5/spec/Overview.html#event-handler-content-attributes
> That's incomplete.
>
Correction: It is complete, I just misread
On 8/4/11, Jonas Sicking wrote:
> On Wed, Aug 3, 2011 at 8:10 AM, Tab Atkins Jr. wrote:
>> On Wed, Aug 3, 2011 at 12:34 AM, Anne van Kesteren
>> wrote:
>>> On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr.
>>> wrote:
On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard wrote:
> On Tue, Aug
On Wed, Aug 3, 2011 at 8:10 AM, Tab Atkins Jr. wrote:
> On Wed, Aug 3, 2011 at 12:34 AM, Anne van Kesteren wrote:
>> On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr.
>> wrote:
>>> On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard wrote:
On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr.
w
On 8/3/2011 8:51 AM, Anne van Kesteren wrote:
On Wed, 03 Aug 2011 17:46:50 +0200, Glenn Maynard wrote:
What's the difference?
ele.setAttribute(x, val) works on any element. ele[x] = val does not.
They also behave differently for a large number of cases and the
latter often takes values of a
On Wed, Aug 3, 2011 at 12:34 AM, Anne van Kesteren wrote:
> On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr.
> wrote:
>> On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard wrote:
>>> On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr.
>>> wrote:
MooTools is basically identical to Prototype, excep
On Wed, Aug 3, 2011 at 11:50 AM, Tab Atkins Jr. wrote:
> for(key in attrs) a.setAttribute(key,attrs[key]);
>
> This would obviously produce a different result here, as the function
> would be stringified into something useless.
>
I think that means it's the wrong thing to do. Within JavaScript c
On Wed, 03 Aug 2011 17:46:50 +0200, Glenn Maynard wrote:
What's the difference?
ele.setAttribute(x, val) works on any element. ele[x] = val does not. They
also behave differently for a large number of cases and the latter often
takes values of a type other than DOMString.
I'd expect th
On Wed, Aug 3, 2011 at 8:46 AM, Glenn Maynard wrote:
> On Wed, Aug 3, 2011 at 3:34 AM, Anne van Kesteren wrote:
>> On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr.
>> wrote:
>>> Hmm, is everything exposed as on* attributes now? If so, then yeah,
>>> just do that; no need to mess around with a
On Wed, Aug 3, 2011 at 3:34 AM, Anne van Kesteren wrote:
> On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr.
> wrote:
>
>> Hmm, is everything exposed as on* attributes now? If so, then yeah,
>> just do that; no need to mess around with a magic property in the
>> attributes bag.
>>
>
> This wou
On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr.
wrote:
On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard wrote:
On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr.
wrote:
MooTools is basically identical to Prototype, except that you can
additionally set listeners on the element during creation
On 8/2/11, Tab Atkins Jr. wrote:
> On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard wrote:
>> On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr.
>> wrote:
>>> MooTools is basically identical to Prototype, except that you can
>>> additionally set listeners on the element during creation by using a
>>>
On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard wrote:
> On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr. wrote:
>> MooTools is basically identical to Prototype, except that you can
>> additionally set listeners on the element during creation by using a
>> magical "events" property in the attribute
On 8/2/11, Tab Atkins Jr. wrote:
> On Tue, Aug 2, 2011 at 9:48 AM, Aryeh Gregor wrote:
>> On Mon, Aug 1, 2011 at 9:33 PM, Maciej Stachowiak wrote:
>>> In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
>>> following idea for convenient element creation:
>>> Element.create(t
On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr. wrote:
> MooTools is basically identical to Prototype, except that you can
> additionally set listeners on the element during creation by using a
> magical "events" property in the attribute bag, which takes an object
> of event names and functions.
On Tue, Aug 2, 2011 at 2:05 PM, Tab Atkins Jr. wrote:
> Read again - the idea is to auto-expand arrays.
>
> (I don't have much of a preference between "just use an array" and
> "use varargs, but expand arrays". I agree that using only varargs
> without expansion would be bad.)
I'm against "use v
On Tue, Aug 2, 2011 at 9:48 AM, Aryeh Gregor wrote:
> On Mon, Aug 1, 2011 at 9:33 PM, Maciej Stachowiak wrote:
>> In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
>> following idea for convenient element creation:
>> Element.create(tagName, attributeMap, children…)
>> C
On 8/2/2011 9:48 AM, Aryeh Gregor wrote:
On Mon, Aug 1, 2011 at 9:33 PM, Maciej Stachowiak wrote:
In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
following idea for convenient element creation:
Element.create(tagName, attributeMap, children…)
Creates an element with
On Tue, Aug 2, 2011 at 12:36 AM, Jonas Sicking wrote:
> I'm not sure if it's better to include the children as a var-args
> list, or as an array. Certainly when typing things normally var-args
> saves you the "[" and "]", but when coding, if you've built the child
> list dynamically and have an ar
On Tue, Aug 2, 2011 at 10:37 AM, Ian Hickson wrote:
> On Tue, 2 Aug 2011, Dimitri Glazkov wrote:
>> On Tue, Aug 2, 2011 at 1:27 AM, Roland Steiner
>> wrote:
>> > On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking
>> > wrote:
>> >> This doesn't explain why a factory method is better than explicit
>> >
On Tue, 2 Aug 2011, Dimitri Glazkov wrote:
> On Tue, Aug 2, 2011 at 1:27 AM, Roland Steiner
> wrote:
> > On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking
> > wrote:
> >> This doesn't explain why a factory method is better than explicit
> >> constructors though? The above could be written as
> >>
On Mon, Aug 1, 2011 at 9:33 PM, Maciej Stachowiak wrote:
> In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
> following idea for convenient element creation:
> Element.create(tagName, attributeMap, children…)
> Creates an element with the specified tag, attributes, and c
On Tue, Aug 2, 2011 at 1:27 AM, Roland Steiner wrote:
> On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking wrote:
>> This doesn't explain why a factory method is better than explicit
>> constructors though? The above could be written as
>>
>> new HTMLParagraphElement(null, "foo", ...);
>
> It's not a
On Tue, Aug 2, 2011 at 1:27 AM, Roland Steiner wrote:
> On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking wrote:
>> This doesn't explain why a factory method is better than explicit
>> constructors though? The above could be written as
>>
>> new HTMLParagraphElement(null, "foo", ...);
>
> It's not a
On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking wrote:
> This doesn't explain why a factory method is better than explicit
> constructors though? The above could be written as
>
> new HTMLParagraphElement(null, "foo", ...);
It's not a general use case, but at least when it comes to XBL-like
compone
On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak wrote:
>
> In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
> following idea for convenient element creation:
> Element.create(tagName, attributeMap, children…)
> Creates an element with the specified tag, attributes, and
On Aug 1, 2011, at 9:25 PM, Ian Hickson wrote:
> On Tue, 2 Aug 2011, João Eiras wrote:
>>
>> While the idea is interesting, "create" is a too simple name to add on
>> something as polluted as Element.
>
> Why?
>
> I think create() is fine. It's a pretty common name for a factory or
> constru
On Aug 1, 2011, at 8:43 PM, Tab Atkins Jr. wrote:
> On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard wrote:
>> Can we have it 'inherit' a parent namespace, and have chaining properties?
>>
>> Element.create('div').create('svg').create('g').create('rect', {title: 'An
>> svg rectangle in an HTM
On Aug 1, 2011, at 8:36 PM, João Eiras wrote:
> On , Ian Hickson wrote:
>
>> On Mon, 1 Aug 2011, Ryosuke Niwa wrote:
>>> On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak wrote:
>>> >
>>> > In an IRC discussion with Ian Hickson and Tab Atkins, we can up with
>>> > the following idea for conven
On Tue, 2 Aug 2011, João Eiras wrote:
>
> While the idea is interesting, "create" is a too simple name to add on
> something as polluted as Element.
Why?
I think create() is fine. It's a pretty common name for a factory or
constructor (in languages with named constructors), and having it on th
On Tue, 2 Aug 2011, João Eiras wrote:
>
> However, Nodes need a ownerDocument, and that needs to be supplied, even
> if optionally. Doing document.createElement implies the document,
> Element.create does not.
Just use the same document as new Image(), new Option(), or new Audio().
--
Ian Hic
On Mon, Aug 1, 2011 at 8:52 PM, João Eiras wrote:
> On , Tab Atkins Jr. wrote:
>
>> On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard wrote:
>>>
>>> Can we have it 'inherit' a parent namespace, and have chaining
>>> properties?
>>>
>>> Element.create('div').create('svg').create('g').create('rect
On , Tab Atkins Jr. wrote:
On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard wrote:
Can we have it 'inherit' a parent namespace, and have chaining properties?
Element.create('div').create('svg').create('g').create('rect', {title: 'An svg
rectangle in an HTML div'});
Ooh, so .create is def
On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard wrote:
> Can we have it 'inherit' a parent namespace, and have chaining properties?
>
> Element.create('div').create('svg').create('g').create('rect', {title: 'An
> svg rectangle in an HTML div'});
Ooh, so .create is defined both on Element (defa
On 2/08/11 3:36 PM, João Eiras wrote:
However, Nodes need a ownerDocument, and that needs to be supplied, even
if optionally. Doing document.createElement implies the document,
Element.create does not.
I figure the ownerDocument would be window.document (where the window
object is the global o
On , Ian Hickson wrote:
On Mon, 1 Aug 2011, Ryosuke Niwa wrote:
On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak wrote:
>
> In an IRC discussion with Ian Hickson and Tab Atkins, we can up with
> the following idea for convenient element creation:
>
> Element.create(tagName, attributeMap, chi
On Mon, Aug 1, 2011 at 6:43 PM, Ian Hickson wrote:
> On Mon, 1 Aug 2011, Maciej Stachowiak wrote:
>>
>> Creates an element with the specified tag, attributes, and children.
>>
>> tagName - tag name as a string; by default it does "smart" selection
>> of SVG, HTML or MathML namespace. Authors
On Mon, 1 Aug 2011, Ryosuke Niwa wrote:
> On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak wrote:
> >
> > In an IRC discussion with Ian Hickson and Tab Atkins, we can up with
> > the following idea for convenient element creation:
> >
> > Element.create(tagName, attributeMap, children�)
>
> Can
On Aug 1, 2011, at 6:43 PM, Ian Hickson wrote:
> On Mon, 1 Aug 2011, Maciej Stachowiak wrote:
>>
>> Creates an element with the specified tag, attributes, and children.
>>
>> tagName - tag name as a string; by default it does "smart" selection
>> of SVG, HTML or MathML namespace. Autho
On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak wrote:
>
> In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
> following idea for convenient element creation:
>
> Element.create(tagName, attributeMap, children…)
>
Can we alternatively extend document.createElement? Or wa
On Mon, 1 Aug 2011, Maciej Stachowiak wrote:
>
>Creates an element with the specified tag, attributes, and children.
>
>tagName - tag name as a string; by default it does "smart" selection
> of SVG, HTML or MathML namespace. Authors can also use an html: svg: or
> mathml: prefix to over
In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
following idea for convenient element creation:
Element.create(tagName, attributeMap, children…)
Creates an element with the specified tag, attributes, and children.
tagName - tag name as a string; by default it doe
53 matches
Mail list logo
