Re: Deprecated Attr methods

We were planning on including it on an upcoming release of CanJS but looks
like we'll have to work-around it for now.  I'm not sure if this is a
common pattern or not.  Angular 2 is introducing this type of syntax for
data binding (but in their case I don't believe they are writing out the
attributes) so it might become more popular for other frameworks in the
future.

On Mon, May 25, 2015 at 4:53 PM, Philip Jägenstedt <philipj@opera.com>
wrote:

> Interesting, I didn't know there was a discrepancy between the characters
> accepted in the HTML parser and contexts like Element.setAttribute(). It
> doesn't sound useful at all to limit setAttribute() more strictly than the
> parser.
>
> I've noted the problem on the tracking bug for Attr simplification in DOM:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26609#c10
>
> Matthew, is the code that call cloneNode() on Attr objects your own, or is
> this a pattern one should expect to find a lot in the wild? It seems that
> of all the things inherited from Node to Attr, cloneNode() might be the
> most used, because apparently it's the safe way to copy attributes from one
> element to another.
>
> Philip
>
> On Mon, May 25, 2015 at 7:00 PM, Matthew Phillips <matthew@bitovi.com>
> wrote:
>
>> Yes, this is exactly what I am doing.
>> On May 25, 2015 11:43 AM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:
>>
>>> On 5/25/15 4:29 AM, Philip Jägenstedt wrote:
>>>
>>>> I'm not quite following, how are you setting the attribute name (not
>>>> value) to "[foo]"?
>>>>
>>>
>>>   data:text/html,<div [foo]=bar>
>>>
>>> or equivalent with the innerHTML setter.
>>>
>>> Once such an attribute is created by the parser, it can currently be
>>> cloned and set on other elements via Attr APIs, right?  And such an
>>> attribute cannot be created via setAttribute/setAttributeNS.
>>>
>>> -Boris
>>>
>>>
>


-- 
Bitovi
Development | Design | Training | Open Source