On Fri, 11 Mar 2011, Jonas Sicking wrote:
On Tue, Dec 28, 2010 at 11:46 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 20 Sep 2010, Mounir Lamouri wrote:
With the current specification, these two elements will not have the
same value:
input value=foo#13;bar type='hidden'
input
On Tue, Jun 14, 2011 at 2:00 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Mar 2011, Jonas Sicking wrote:
On Tue, Dec 28, 2010 at 11:46 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 20 Sep 2010, Mounir Lamouri wrote:
With the current specification, these two elements will not have the
On Tue, 14 Jun 2011, Jonas Sicking wrote:
The problem, if I understand things correctly, is that setAttribute is
*not* order agnostic, while the parsing code is expected to be. This
means that we can't use the same code paths for setAttribute and
parsing.
You can, you just have to have a
On 03/12/2011 12:56 AM, Jonas Sicking wrote:
inp = document.createElement(input);
inp.setAttribute(value, foo\nbar);
inp.setAttribute(type, hidden);
and
inp = document.createElement(input);
inp.setAttribute(type, hidden);
inp.setAttribute(value, foo\nbar);
This does not seem desirable.
(Sorry to bring back an old thread. Trying to catch up on old to-do's
now that FF4 is almost out the door)
On Tue, Dec 28, 2010 at 11:46 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 20 Sep 2010, Mounir Lamouri wrote:
With the current specification, these two elements will not have the
same
On Mon, 20 Sep 2010, Mounir Lamouri wrote:
With the current specification, these two elements will not have the
same value:
input value=foo#13;bar type='hidden'
input type='hidden' value=foo#13;bar
Yes they will. The attribute order has no effect. Elements are created
by the parser with
On Mon, 20 Sep 2010, Mounir Lamouri wrote:
Hi,
For a few days, Firefox's nightly had a bug related to value sanitizing
which happens to be a specification bug.
With the current specification, these two elements will not have the
same value:
input value=foo#13;bar type='hidden'
input
On 9/21/10 4:06 AM, James Graham wrote:
The concept of Creating an Element already exists [1] and is atomic,
Where does it say that it's atomic? I don't see that anywhere (and in
fact, the create an element code in the Gecko parser is most decidedly
non-atomic). Now maybe the spec intends
On 09/21/2010 10:12 AM, Boris Zbarsky wrote:
On 9/21/10 4:06 AM, James Graham wrote:
The concept of Creating an Element already exists [1] and is atomic,
Where does it say that it's atomic? I don't see that anywhere (and in
fact, the create an element code in the Gecko parser is most
On 9/21/10 5:09 AM, James Graham wrote:
It is described as a single step in the spec, which I take to imply that
it should behave as a single operation from the point of view of the
rest of the spec.
That doesn't work if your parser and DOM aren't very very _very_ tightly
coupled, since there
On Tue, Sep 21, 2010 at 9:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/21/10 5:09 AM, James Graham wrote:
It is described as a single step in the spec, which I take to imply that
it should behave as a single operation from the point of view of the
rest of the spec.
That doesn't work if
On 09/21/2010 10:18 PM, Jonas Sicking wrote:
On Tue, Sep 21, 2010 at 9:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Also, it would mean that the following two pieces of code behaves differently:
inp = document.createElement(input);
inp.setAttribute(value, foo\nbar);
inp.setAttribute(type,
12 matches
Mail list logo
