[jQuery] Re: Is this "quirk" of jQuery still true?
On Sep 4, 11:28 am, p_W wrote:
> I just wanted to address setAttribute real quick...correct me if I'm
> wrong, but I was under the impression that IE does not support
> setAttribute(), that you had to use dot notation for IE (so
> element.attribute = value instead of element.setAttribute("attribute",
> "value"))
setAttribute "works" in IE as far back as 6 at least, but has quirks
(try using it to set an onclick listener). There is rarely any need to
set HTML attributes when dealing with an HTML DOM, just set the
appropriate property.
setAttribute and getAttribute are useful for DOMs that are not HTML,
or for non-standard attributes in an HTML DOM - though that makes the
markup invalid and so shouldn't be used. Again, just use standard
object property access methods (dots or square brackets).
--
Rob
[jQuery] Re: Is this "quirk" of jQuery still true?
I just wanted to address setAttribute real quick...correct me if I'm
wrong, but I was under the impression that IE does not support
setAttribute(), that you had to use dot notation for IE (so
element.attribute = value instead of element.setAttribute("attribute",
"value"))
On Sep 3, 4:36 pm, Ricardo wrote:
> Nope. The DOM (Document Object Model) has a tree structure, just like
> HTML, with elements owning children. And as HTML is a "static"
> document (you can't mess with it any other way except via DOM), you
> can't traverse it, you can only traverse the DOM that represents it :)
>
> On Sep 3, 10:15 am, "Rick Faircloth" wrote:
>
> > > It is impossible to know the OP was just a bit lazy or
> > > doesn't fully understand the concepts.
>
> > The latter...I'm the OP and I can promise you that I don't fully
> > understand all the concepts. :o)
>
> > Anyway, back to the DOM & HTML...
>
> > If, as you state, "there is no HTML in the DOM," from a "technical"
> > standpoint, then I suppose it's technically inaccurate to speak
> > of "traversing the DOM", since what is really being done is
> > "traversing of the HTML elements." Would that be a fair statement?
>
> > Rick
>
> > -----Original Message-
> > From: jquery-en@googlegroups.com [mailto:jquery...@googlegroups.com] On
>
> > Behalf Of RobG
> > Sent: Thursday, September 03, 2009 1:43 AM
> > To: jQuery (English)
> > Subject: [jQuery] Re: Is this "quirk" of jQuery still true?
>
> > On Sep 3, 1:25 pm, "Rick Faircloth" wrote:
> > > Thanks for the explanation, Rob.
>
> > > I'll have to check into setAttribute...am I correct in assuming
> > > that "setAttribute" is a Javascript function, but not jQuery?
>
> > setAttribute is a DOM Core method of the Element interface[1]. jQuery
> > wraps a great many such methods, but not this one. There is rarely any
> > need to use it for HTML documents, particularly as it is broken in
> > parts in IE. There is also little use for it as setting the DOM
> > property directly is simpler (and likely much faster as it doesn't
> > require a method call). setAttribute may handy for XML documents
> > though.
>
> > > Also, your statement, "There is no 'HTML in the DOM'. HTML is used
> > > to create a DOM." seems like semantics.
>
> > Yes, it is, but in a technical group I think it is important. It is
> > impossible to know the OP was just a bit lazy or doesn't fully
> > understand the concepts. Better to be sure than make a wrong
> > assumption.
>
> > > So is it correct to say that a DOM contains no HTML?
>
> > Yes. HTML is a markup language, it is interpreted by browsers to
> > generate a DOM. Javascript interacts with the DOM, not the markup.
>
> > An analogy is that a plan is used to build a house. Instructions to
> > tradesmen to change the design might be reflected in the house, but
> > aren't automatically reflected in the plans unless you also tell the
> > draughtsman to change them. innerHTML and other DOM inspection tools
> > are like an "as built" plan of part of the house.
>
> > 1. http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082>
>
> > --
> > Rob
[jQuery] Re: Is this "quirk" of jQuery still true?
Nope. The DOM (Document Object Model) has a tree structure, just like HTML, with elements owning children. And as HTML is a "static" document (you can't mess with it any other way except via DOM), you can't traverse it, you can only traverse the DOM that represents it :) On Sep 3, 10:15 am, "Rick Faircloth" wrote: > > It is impossible to know the OP was just a bit lazy or > > doesn't fully understand the concepts. > > The latter...I'm the OP and I can promise you that I don't fully > understand all the concepts. :o) > > Anyway, back to the DOM & HTML... > > If, as you state, "there is no HTML in the DOM," from a "technical" > standpoint, then I suppose it's technically inaccurate to speak > of "traversing the DOM", since what is really being done is > "traversing of the HTML elements." Would that be a fair statement? > > Rick > > -Original Message- > From: jquery-en@googlegroups.com [mailto:jquery...@googlegroups.com] On > > Behalf Of RobG > Sent: Thursday, September 03, 2009 1:43 AM > To: jQuery (English) > Subject: [jQuery] Re: Is this "quirk" of jQuery still true? > > On Sep 3, 1:25 pm, "Rick Faircloth" wrote: > > Thanks for the explanation, Rob. > > > I'll have to check into setAttribute...am I correct in assuming > > that "setAttribute" is a Javascript function, but not jQuery? > > setAttribute is a DOM Core method of the Element interface[1]. jQuery > wraps a great many such methods, but not this one. There is rarely any > need to use it for HTML documents, particularly as it is broken in > parts in IE. There is also little use for it as setting the DOM > property directly is simpler (and likely much faster as it doesn't > require a method call). setAttribute may handy for XML documents > though. > > > Also, your statement, "There is no 'HTML in the DOM'. HTML is used > > to create a DOM." seems like semantics. > > Yes, it is, but in a technical group I think it is important. It is > impossible to know the OP was just a bit lazy or doesn't fully > understand the concepts. Better to be sure than make a wrong > assumption. > > > So is it correct to say that a DOM contains no HTML? > > Yes. HTML is a markup language, it is interpreted by browsers to > generate a DOM. Javascript interacts with the DOM, not the markup. > > An analogy is that a plan is used to build a house. Instructions to > tradesmen to change the design might be reflected in the house, but > aren't automatically reflected in the plans unless you also tell the > draughtsman to change them. innerHTML and other DOM inspection tools > are like an "as built" plan of part of the house. > > 1. http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082> > > -- > Rob
[jQuery] Re: Is this "quirk" of jQuery still true?
> It is impossible to know the OP was just a bit lazy or > doesn't fully understand the concepts. The latter...I'm the OP and I can promise you that I don't fully understand all the concepts. :o) Anyway, back to the DOM & HTML... If, as you state, "there is no HTML in the DOM," from a "technical" standpoint, then I suppose it's technically inaccurate to speak of "traversing the DOM", since what is really being done is "traversing of the HTML elements." Would that be a fair statement? Rick -Original Message- From: jquery-en@googlegroups.com [mailto:jquery...@googlegroups.com] On Behalf Of RobG Sent: Thursday, September 03, 2009 1:43 AM To: jQuery (English) Subject: [jQuery] Re: Is this "quirk" of jQuery still true? On Sep 3, 1:25 pm, "Rick Faircloth" wrote: > Thanks for the explanation, Rob. > > I'll have to check into setAttribute...am I correct in assuming > that "setAttribute" is a Javascript function, but not jQuery? setAttribute is a DOM Core method of the Element interface[1]. jQuery wraps a great many such methods, but not this one. There is rarely any need to use it for HTML documents, particularly as it is broken in parts in IE. There is also little use for it as setting the DOM property directly is simpler (and likely much faster as it doesn't require a method call). setAttribute may handy for XML documents though. > Also, your statement, "There is no 'HTML in the DOM'. HTML is used > to create a DOM." seems like semantics. Yes, it is, but in a technical group I think it is important. It is impossible to know the OP was just a bit lazy or doesn't fully understand the concepts. Better to be sure than make a wrong assumption. > So is it correct to say that a DOM contains no HTML? Yes. HTML is a markup language, it is interpreted by browsers to generate a DOM. Javascript interacts with the DOM, not the markup. An analogy is that a plan is used to build a house. Instructions to tradesmen to change the design might be reflected in the house, but aren't automatically reflected in the plans unless you also tell the draughtsman to change them. innerHTML and other DOM inspection tools are like an "as built" plan of part of the house. 1. http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082 > -- Rob
[jQuery] Re: Is this "quirk" of jQuery still true?
Saving state for positioned elements, etc. (other than just form field data) is an interesting problem, as you say, with the complexity of apps using user-positioned elements or other manipulations. I've no solution at this point...haven't run into that situation...yet... -Original Message- From: jquery-en@googlegroups.com [mailto:jquery...@googlegroups.com] On Behalf Of Scott Haneda Sent: Wednesday, September 02, 2009 11:43 PM To: jquery-en@googlegroups.com Cc: Subject: [jQuery] Re: Is this "quirk" of jQuery still true? This is an intersting problem though. Without the ability to edit the HTML, a page refresh is going to kill any work you did. Granted, in most cases, the need for a page refresh would not matter, as the browser is going to drop the input form data anyway. One advantage would be you could potentially store the form data. As web apps become more complex, it may not be form data, but positioned elements. What is the best way to save this state in hopes of protecting the user from a refresh? Is it even worth it? I can see three ways. Local browser data store, not currently supported by all browsers. Second is appending to a refresh link, or the URL directly, some data that can store the last state. Third is use of cookies to store state. Curious what others chose to use in solving this, or if it is even something considered a problem worth solving. -- Scott Iphone says hello. On Sep 2, 2009, at 7:29 PM, "Rick Faircloth" wrote: > Thanks for the reply, Ricardo... > > After thinking about it, it really doesnft matter if the HTML is cha > nged. > It'll process fine, as you said. > > What I was really trying to avoid was a problem with the newly entered > data being removed if I focused on the field with the cursor again. > > I came up with a better solution that deleted the error message I put > into the field, but didn't delete the new typed in code.
[jQuery] Re: Is this "quirk" of jQuery still true?
On Sep 3, 1:25 pm, "Rick Faircloth" wrote: > Thanks for the explanation, Rob. > > I'll have to check into setAttribute...am I correct in assuming > that "setAttribute" is a Javascript function, but not jQuery? setAttribute is a DOM Core method of the Element interface[1]. jQuery wraps a great many such methods, but not this one. There is rarely any need to use it for HTML documents, particularly as it is broken in parts in IE. There is also little use for it as setting the DOM property directly is simpler (and likely much faster as it doesn't require a method call). setAttribute may handy for XML documents though. > Also, your statement, "There is no 'HTML in the DOM'. HTML is used > to create a DOM." seems like semantics. Yes, it is, but in a technical group I think it is important. It is impossible to know the OP was just a bit lazy or doesn't fully understand the concepts. Better to be sure than make a wrong assumption. > So is it correct to say that a DOM contains no HTML? Yes. HTML is a markup language, it is interpreted by browsers to generate a DOM. Javascript interacts with the DOM, not the markup. An analogy is that a plan is used to build a house. Instructions to tradesmen to change the design might be reflected in the house, but aren't automatically reflected in the plans unless you also tell the draughtsman to change them. innerHTML and other DOM inspection tools are like an "as built" plan of part of the house. 1. http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082 > -- Rob
[jQuery] Re: Is this "quirk" of jQuery still true?
This is an intersting problem though. Without the ability to edit the HTML, a page refresh is going to kill any work you did. Granted, in most cases, the need for a page refresh would not matter, as the browser is going to drop the input form data anyway. One advantage would be you could potentially store the form data. As web apps become more complex, it may not be form data, but positioned elements. What is the best way to save this state in hopes of protecting the user from a refresh? Is it even worth it? I can see three ways. Local browser data store, not currently supported by all browsers. Second is appending to a refresh link, or the URL directly, some data that can store the last state. Third is use of cookies to store state. Curious what others chose to use in solving this, or if it is even something considered a problem worth solving. -- Scott Iphone says hello. On Sep 2, 2009, at 7:29 PM, "Rick Faircloth" wrote: Thanks for the reply, Ricardo... After thinking about it, it really doesn’t matter if the HTML is cha nged. It'll process fine, as you said. What I was really trying to avoid was a problem with the newly entered data being removed if I focused on the field with the cursor again. I came up with a better solution that deleted the error message I put into the field, but didn't delete the new typed in code.
[jQuery] Re: Is this "quirk" of jQuery still true?
Thanks for the explanation, Rob.
I'll have to check into setAttribute...am I correct in assuming
that "setAttribute" is a Javascript function, but not jQuery?
Also, your statement, "There is no 'HTML in the DOM'. HTML is used
to create a DOM." seems like semantics.
So is it correct to say that a DOM contains no HTML?
Rick
-Original Message-
From: jquery-en@googlegroups.com [mailto:jquery...@googlegroups.com] On
Behalf Of RobG
Sent: Wednesday, September 02, 2009 11:05 PM
To: jQuery (English)
Subject: [jQuery] Re: Is this "quirk" of jQuery still true?
On Sep 3, 6:55 am, "Rick Faircloth" wrote:
> I read that in an article dated October 17, 2008, that it was not possible
> to change the actual
>
> HTML in the DOM
There is no "HTML in the DOM". HTML is used to create a DOM.
> of the "value" attribute of a text input using
> $(this).val('myNewValue');
Because that changes the DOM value property, not the HTML value
attribute.
The HTML value attribute (if present) is used to set the DOM
defaultValue property and provide an initial value for the value
property. User initiated changes to the input's value will change the
DOM value property. Setting the value property will change the
displayed value. If the input is in a form and the form is submitted,
the value of the value property is submitted (assuming the input is
successful).
The defaultValue is used to set the value of the input if the form's
reset method is called and can be changed by assigning a new value to
it programmatically.
The HTML attribute value can be changed using setAttribute.
There is no specification for how to generate HTML from a DOM, what
you'll get is dependent on the browser and the method or tool (e.g.
the browser-dependent innerHTML property[1])
Using innerHTML as the tool to convert DOM to HTML, it can be seen
that in IE changes to the element's value property are reflected in
the value attribute but not in Firefox. Other tools may have different
results. If you want consistent behaviour in that regard, do the DOM
to HTML transformation yourself.
> My experiments just now bear this out.
>
> Is this still true? The writer of the article developed a work-around
using
> a hidden input and
>
> manipulating its value with a rel to the original input. Is this still
the
> best way?
If you want to reliably set the HTML attribute value, use setAttribute
as it is specified as doing that (and realise that setAttribute is
broken in IE in places).
1. innerHTML is a widely copied IE proprietary property that has no
public specification and is known to be implemented differently in
different browsers.
--
Rob
[jQuery] Re: Is this "quirk" of jQuery still true?
On Sep 3, 6:55 am, "Rick Faircloth" wrote:
> I read that in an article dated October 17, 2008, that it was not possible
> to change the actual
>
> HTML in the DOM
There is no "HTML in the DOM". HTML is used to create a DOM.
> of the "value" attribute of a text input using
> $(this).val('myNewValue');
Because that changes the DOM value property, not the HTML value
attribute.
The HTML value attribute (if present) is used to set the DOM
defaultValue property and provide an initial value for the value
property. User initiated changes to the input's value will change the
DOM value property. Setting the value property will change the
displayed value. If the input is in a form and the form is submitted,
the value of the value property is submitted (assuming the input is
successful).
The defaultValue is used to set the value of the input if the form's
reset method is called and can be changed by assigning a new value to
it programmatically.
The HTML attribute value can be changed using setAttribute.
There is no specification for how to generate HTML from a DOM, what
you'll get is dependent on the browser and the method or tool (e.g.
the browser-dependent innerHTML property[1])
Using innerHTML as the tool to convert DOM to HTML, it can be seen
that in IE changes to the element's value property are reflected in
the value attribute but not in Firefox. Other tools may have different
results. If you want consistent behaviour in that regard, do the DOM
to HTML transformation yourself.
> My experiments just now bear this out.
>
> Is this still true? The writer of the article developed a work-around using
> a hidden input and
>
> manipulating its value with a rel to the original input. Is this still the
> best way?
If you want to reliably set the HTML attribute value, use setAttribute
as it is specified as doing that (and realise that setAttribute is
broken in IE in places).
1. innerHTML is a widely copied IE proprietary property that has no
public specification and is known to be implemented differently in
different browsers.
--
Rob
[jQuery] Re: Is this "quirk" of jQuery still true?
Thanks for the reply, Ricardo...
After thinking about it, it really doesnt matter if the HTML is changed.
It'll process fine, as you said.
What I was really trying to avoid was a problem with the newly entered
data being removed if I focused on the field with the cursor again.
I came up with a better solution that deleted the error message I put
into the field, but didn't delete the new typed in code.
Rick
-Original Message-
From: jquery-en@googlegroups.com [mailto:jquery...@googlegroups.com] On
Behalf Of Ricardo
Sent: Wednesday, September 02, 2009 9:09 PM
To: jQuery (English)
Subject: [jQuery] Re: Is this "quirk" of jQuery still true?
The change in value won't appear in the HTML (in firebug for example),
but the value *will* change and be submitted with the form. That's
standard DOM scripting behaviour. There is no reason to change the
attribute in the HTML unless you want to print it somewhere.
On Sep 2, 5:55 pm, "Rick Faircloth" wrote:
> I read that in an article dated October 17, 2008, that it was not possible
> to change the actual
>
> HTML in the DOM of the "value" attribute of a text input using
> $(this).val('myNewValue');
>
> My experiments just now bear this out.
>
> Is this still true? The writer of the article developed a work-around
using
> a hidden input and
>
> manipulating its value with a rel to the original input. Is this still
the
> best way?
>
> Thanks for any insights.
>
> Rick
>
>
> ---
>
> "Those who hammer their guns into plows will plow for those who do not."
-
> Thomas Jefferson
[jQuery] Re: Is this "quirk" of jQuery still true?
The change in value won't appear in the HTML (in firebug for example),
but the value *will* change and be submitted with the form. That's
standard DOM scripting behaviour. There is no reason to change the
attribute in the HTML unless you want to print it somewhere.
On Sep 2, 5:55 pm, "Rick Faircloth" wrote:
> I read that in an article dated October 17, 2008, that it was not possible
> to change the actual
>
> HTML in the DOM of the "value" attribute of a text input using
> $(this).val('myNewValue');
>
> My experiments just now bear this out.
>
> Is this still true? The writer of the article developed a work-around using
> a hidden input and
>
> manipulating its value with a rel to the original input. Is this still the
> best way?
>
> Thanks for any insights.
>
> Rick
>
>
> ---
>
> "Those who hammer their guns into plows will plow for those who do not." -
> Thomas Jefferson
