Re: Element.create(): a proposal for more convenient element creation

On 8/6/2011 3:54 PM, Garrett Smith wrote:
> On 8/6/11, Charles Pritchard<chuck@jumis.com>  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.
Dominic stated several reasons.
(Element.create('div') instanceof HTMLDivElement);


>>> Second, re: setAttribute vs setting properties, there might be types
>>> other than functions we want to not treat as strings; for example if a
>>> UA implements CSSOM it might be nice to be able to set a style without
>>> having to serialize and reparse the CSSStyleDeclaration.
>>>
>>> Can we spec whether something in the attributes hash is set via
>>> setAttribute or via setting a property based on the IDL for that element?
>> How about .attributes as another reserved word:
>>
>> Element.create('div', { attributes: { 'class': 'foo'} });
>> Element.create('div', { attributes: [ 'class','foo','class','bar'] }
>> ).attr({textContent: 'Bar class'});
>>
> textContent is a property, not an attribute. Properties vs attributes
> was already explained in this thread.
> [...]

I've stated in prior threads, that unless the word is aria-* or data-*, 
properties are set on the element.
Here, I've added attributes as another reserved word, for setting 
attributes.

The proposed attr() method sets properties, as create() does.

Element.create('div',{className: 'class'}).attr({className: 'class ', attributes: {'class': 'class'}).getAttribute('class') == 'class';

Received on Saturday, 6 August 2011 23:02:21 UTC