W3C home > Mailing lists > Public > public-html@w3.org > May 2015

Re: Deprecated Attr methods

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 25 May 2015 22:53:53 +0200
Message-ID: <CAMQvoCkF+wTCG+6EamuZ0JOdZhn3UphbAmX-HHM8N3Ok1hXzKA@mail.gmail.com>
To: Matthew Phillips <matthew@bitovi.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-html <public-html@w3.org>
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
>>
>>
Received on Monday, 25 May 2015 20:54:21 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:13 UTC