Really Ugly?

[Karl Swedberg-2]

Hello my jQuery friends,

I received a comment on learningjquery.com this evening from someone who had a grievance with part of some example code. I was wondering if any of you would be willing to shed some light on this for me. I think what he's getting at is the whole "innerHTML is evil" thing, but since he doesn't really explain why he think it's "really ugly," I'm just not sure. 

Here is the relevant snippet of his comment:  

Nice post, but …
This part of code :

$('#show-alert').click(function() {
$('<div class="quick-alert">Alert! Watch me before it\'s too late!</div>') .insertAfter( $(this) );
}

should be AVOIDED as is. Inserting HTML code like this is really ugly, it’s a lot better to use the DOM methods :

$('#show-alert').click(function() {
var oDIV = document.createElement('div');
oDiv.className = 'quick-alert';
oText = document.createTextNode("Alert ! Watch me before it's too late !");
$(oDiv).append(oText);
$(oDiv).insertAfter(this);
}

I'd love to hear your opinions about this. With HTML/CSS stuff, I'm obsessed with standards and such. And one of the things that has always really attracted me to jQuery is its unobtrusiveness. I also read Jeremy Keith's DOM Scripting book and really appreciated his approach -- which is similar to what this commenter is suggesting. But I also love the super-fast development that can be done with jQuery and don't want to have to give that up if it's just a matter of someone's aesthetic sensibility being offended. I guess I just want to do the right thing. 

thanks,

--Karl

_________________

Karl Swedberg

www.englishrules.com

www.learningjquery.com

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Rey Bango-2]

Hi Karl,

The use of innerHTML is fairly common. I actually asked Klaus Hartl the
same thing awhile back and here's his reply:

"according to the IE documentation, the innerHTML property is read-only
for the following elements: col, colgroup, frameset, html, style, table,
tbody, tfoot, title and tr. And I think also select (but I'm not sure
anymore, because I cannot find anything in the docs).

Most relevant here are table and select elements I guess. Populating a
selectbox by simply changing innerHTML ( $('select').html('<option> ...
</option>') ) doesn't work. For tables a fix is already in jQuery. "

I think alot of people like using innerHTML because of the convenience
and according to this blog entry by Rob Gonda, speed:

http://www.robgonda.com/blog/index.cfm?mode=search

HTH,

Rey...

Karl Swedberg wrote:

>
> Hello my jQuery friends,
>
> I received a comment on learningjquery.com this evening from someone who
> had a grievance with part of some example code. I was wondering if any
> of you would be willing to shed some light on this for me. I think what
> he's getting at is the whole "innerHTML is evil" thing, but since he
> doesn't really explain why he think it's "really ugly," I'm just not sure.
>
> Here is the relevant snippet of his comment:  
>
>> Nice post, but …
>> This part of code :
>>
>> $('#show-alert').click(function() {
>> $('<div class="quick-alert">Alert! Watch me before it\'s too
>> late!</div>') .insertAfter( $(this) );
>> }
>>
>> should be AVOIDED as is. Inserting HTML code like this is really ugly,
>> it’s a lot better to use the DOM methods :
>>
>> $('#show-alert').click(function() {
>> var oDIV = document.createElement('div');
>> oDiv.className = 'quick-alert';
>> oText = document.createTextNode("Alert ! Watch me before it's too late
>> !");
>> $(oDiv).append(oText);
>> $(oDiv).insertAfter(this);
>> }
>>
> I'd love to hear your opinions about this. With HTML/CSS stuff, I'm
> obsessed with standards and such. And one of the things that has always
> really attracted me to jQuery is its unobtrusiveness. I also read Jeremy
> Keith's DOM Scripting book and really appreciated his approach -- which
> is similar to what this commenter is suggesting. But I also love the
> super-fast development that can be done with jQuery and don't want to
> have to give that up if it's just a matter of someone's aesthetic
> sensibility being offended. I guess I just want to do the right thing.
>
> thanks,
>
> --Karl
> _________________
> Karl Swedberg
> www.englishrules.com
> www.learningjquery.com
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[thumblewend]

On 01/02/2007, at 12:30 PM, Karl Swedberg wrote:

> I'd love to hear your opinions about this. With HTML/CSS stuff, I'm  
> obsessed with standards and such. And one of the things that has  
> always really attracted me to jQuery is its unobtrusiveness. I also  
> read Jeremy Keith's DOM Scripting book and really appreciated his  
> approach -- which is similar to what this commenter is suggesting.  
> But I also love the super-fast development that can be done with  
> jQuery and don't want to have to give that up if it's just a matter  
> of someone's aesthetic sensibility being offended. I guess I just  
> want to do the right thing.
>

Here is my current understanding of this issue. (Anyone, please  
correct me where I am wrong). The main reason why innerHTML is said  
to be evil is that it is not part of the standards. Therefore, if a  
vendor creates a new user agent they may not decide to implement  
support for it, leaving your web app or site broken and probably  
adversely affected accessibility-wise. Whilst it is hard to imagine  
any new browsers not supporting innerHTML as it is what some people  
call a "pseudo-standard", I suppose it is not as hard to imagine  
various new mobile devices and other unconventional browsers  
supporting JavaScript but not what they may consider "extras" such as  
innerHTML.
Also, if you ever want to serve the page as XHTML your script will  
not work because innerHTML does not work for XML pages of course.
Personally, I have just resigned to using it when using jQuery  
because the ease and speed benefits you mentioned are just too darn  
seductive. The code is also much more readable so less-techy people  
can possibly change the output easier.
I'll be interested to hear what other people think about this.

Joel Birch.

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Stephen Woodbridge]

Karl Swedberg wrote:

>
> Hello my jQuery friends,
>
> I received a comment on learningjquery.com this evening from someone who
> had a grievance with part of some example code. I was wondering if any
> of you would be willing to shed some light on this for me. I think what
> he's getting at is the whole "innerHTML is evil" thing, but since he
> doesn't really explain why he think it's "really ugly," I'm just not sure.
>
> Here is the relevant snippet of his comment:  
>
>> Nice post, but …
>> This part of code :
>>
>> $('#show-alert').click(function() {
>> $('<div class="quick-alert">Alert! Watch me before it\'s too
>> late!</div>') .insertAfter( $(this) );
>> }
>>
>> should be AVOIDED as is. Inserting HTML code like this is really ugly,
>> it’s a lot better to use the DOM methods :
>>
>> $('#show-alert').click(function() {
>> var oDIV = document.createElement('div');
>> oDiv.className = 'quick-alert';
>> oText = document.createTextNode("Alert ! Watch me before it's too late
>> !");
>> $(oDiv).append(oText);
>> $(oDiv).insertAfter(this);
>> }
>>
> I'd love to hear your opinions about this. With HTML/CSS stuff, I'm
> obsessed with standards and such. And one of the things that has always
> really attracted me to jQuery is its unobtrusiveness. I also read Jeremy
> Keith's DOM Scripting book and really appreciated his approach -- which
> is similar to what this commenter is suggesting. But I also love the
> super-fast development that can be done with jQuery and don't want to
> have to give that up if it's just a matter of someone's aesthetic
> sensibility being offended. I guess I just want to do the right thing.
>
> thanks,

Karl,

I think this the argument about separation of content and structure.
Like the MVC concepts it is "bad" practice mix you content and
structure. Hence 7 lines instead of 4.

Personally, I don't like it conceptually either, but it is very
convenient and all to easy to do for speed and easy of prototyping.

I think this is also revolves around what we want to be "teaching" new
jQuery users by the examples we use.

my 2 cents,
   -Steve W

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Brandon Aaron]

Standards vs. Reality ... doesn't always mix very well. If someone
feels very strongly about *not* using the innerHTML property, then
that someone could use any one of the several DOM creation plugins
that are available. They all use the long route to adding elements to
the DOM (if I remember correctly).

I'm all for standards but I'm also in the trenches crunching out web
sites. The reality is that innerHTML works and it is fast. When used
by jQuery (in the respect of .append('html string')) it becomes very
readable, maintainable and I become more productive.

Let's not forget that xmlHttpRequest is also not standard.

It should be noted that when the elements are actually added to the
DOM, jQuery does *not* use innerHTML. It only uses innerHTML to
normalize some cross-browser issues and quickly get the actual
elements out of an HTML string.

--
Brandon Aaron

On 1/31/07, Karl Swedberg <karl@...> wrote:

>
>
> Hello my jQuery friends,
>
> I received a comment on learningjquery.com this evening from someone who had
> a grievance with part of some example code. I was wondering if any of you
> would be willing to shed some light on this for me. I think what he's
> getting at is the whole "innerHTML is evil" thing, but since he doesn't
> really explain why he think it's "really ugly," I'm just not sure.
>
> Here is the relevant snippet of his comment:
>
>
>
> Nice post, but …
>  This part of code :
>
>  $('#show-alert').click(function() {
>  $('<div class="quick-alert">Alert! Watch me before it\'s too late!</div>')
> .insertAfter( $(this) );
>  }
>
>  should be AVOIDED as is. Inserting HTML code like this is really ugly, it's
> a lot better to use the DOM methods :
>
>  $('#show-alert').click(function() {
>  var oDIV = document.createElement('div');
>  oDiv.className = 'quick-alert';
>  oText = document.createTextNode("Alert ! Watch me before it's too late !");
>  $(oDiv).append(oText);
>  $(oDiv).insertAfter(this);
>  }
> I'd love to hear your opinions about this. With HTML/CSS stuff, I'm obsessed
> with standards and such. And one of the things that has always really
> attracted me to jQuery is its unobtrusiveness. I also read Jeremy Keith's
> DOM Scripting book and really appreciated his approach -- which is similar
> to what this commenter is suggesting. But I also love the super-fast
> development that can be done with jQuery and don't want to have to give that
> up if it's just a matter of someone's aesthetic sensibility being offended.
> I guess I just want to do the right thing.
>
> thanks,
>
> --Karl
> _________________
> Karl Swedberg
> www.englishrules.com
> www.learningjquery.com
>
>
>
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/
>
>
>

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Brandon Aaron]

On 1/31/07, Rey Bango <rey@...> wrote:
> [...] And I think also select (but I'm not sure
> anymore, because I cannot find anything in the docs).

It is read-only for select elements too.

> Most relevant here are table and select elements I guess. Populating a
> selectbox by simply changing innerHTML ( $('select').html('<option> ...
> </option>') ) doesn't work. For tables a fix is already in jQuery. "

Actually it is possible since 1.0.4 to just use the DOM Manipulation
methods on select elements as it is fixed like it is for tables.

Just wanted to clear that up.

--
Brandon Aaron

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[thumblewend]

On 01/02/2007, at 1:07 PM, Brandon Aaron wrote:

> Let's not forget that xmlHttpRequest is also not standard.

I thought this was recently made standard.
Joel.

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Brandon Aaron]

I'm pretty sure it is still a working draft:
http://www.w3.org/TR/XMLHttpRequest/

However, it is pretty much guaranteed to be a standard. :)

--
Brandon Aaron

On 1/31/07, Joel Birch <j_birch@...> wrote:

> On 01/02/2007, at 1:07 PM, Brandon Aaron wrote:
>
> > Let's not forget that xmlHttpRequest is also not standard.
>
> I thought this was recently made standard.
> Joel.
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/
>

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[thumblewend]

On 01/02/2007, at 1:24 PM, Brandon Aaron wrote:

> On 1/31/07, Joel Birch <j_birch@...> wrote:
>> On 01/02/2007, at 1:07 PM, Brandon Aaron wrote:
>>
>>> Let's not forget that xmlHttpRequest is also not standard.
>>
>> I thought this was recently made standard.
>> Joel.
> I'm pretty sure it is still a working draft:
> http://www.w3.org/TR/XMLHttpRequest/
> However, it is pretty much guaranteed to be a standard. :)
> --
> Brandon Aaron

Gotchya, thanks.
Joel.

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[AHeimlich]

On 1/31/07, Joel Birch <j_birch@...> wrote:

> Let's not forget that xmlHttpRequest is also not standard.

I thought this was recently made standard.
Joel.

It has -- it just hasn't been finalized yet: http://www.w3.org/TR/XMLHttpRequest/

The Web API Working Group[1] is working on a bunch of other cool stuff too, like a selectors API[2] (image a jQuery-like selector engine that's native to the browser!)

Also, for those that are interested, here's some benchmarks of W3C DOM methods vs innerHTML: http://www.quirksmode.org/dom/innerhtml.html

[1] http://www.w3.org/2006/webapi/
[2] http://www.w3.org/TR/selectors-api/

--
Aaron Heimlich
Web Developer
aaron.heimlich@...
http://aheimlich.freepgs.com
_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[dave.methvin]

Karl Swedberg-2 wrote:

Here is the relevant snippet of his comment:

> Nice post, but …  it’s a lot better to use the DOM methods :
>
> $('#show-alert').click(function() {
> var oDIV = document.createElement('div');
> oDiv.className = 'quick-alert';
> oText = document.createTextNode("Alert ! Watch me before it's too  
> late !");
> $(oDiv).append(oText);
> $(oDiv).insertAfter(this);
> }

That kind of defeats the terseness of jQuery. If you're set on avoiding any use of .innerHTML just use one of the jQuery DOM plugins. Then you can say something like this and it will only use DOM functions:

$('#show-alert').click(function() {
   $(this).after(
      $.DIV({className: 'quick-alert'},
      "Alert ! Watch me before it's too late !")
    );
};

I *do* think that people need to be more careful when using an innerHTML approach to building content, maybe that's what the OP was trying to get at. For example, let's say you do something like this:

$("#myinput").bind("change", function(){
  $("#youtyped").html(this.value);
});

Whatever the user enters in the input field will be copied to the element, but what if the user enters html? That could cause some serious havoc with your document. (Starting with jQuery 1.1 the .text() method is a setter, but at the moment it just sends the input to .html() which wouldn't fix this problem.)

If you use DOM creation functions, there's no html interpretation of the data and therefore no potential for screwups. But a lot of the time you're not processing user data and it is very handy to drop in a quick scrap or two of html.

[AHeimlich]

Some parts of this message have been removed. Learn more about Nabble's security policy.

And here's a discussion of innerHTML by Peter Paul Koch (aka ppk): http://www.webreference.com/programming/javascript/ppk2/4.html

On 1/31/07, Aaron Heimlich <aaron.heimlich@...> wrote:

On 1/31/07, Joel Birch <j_birch@...> wrote:

> Let's not forget that xmlHttpRequest is also not standard.

I thought this was recently made standard.
Joel.

It has -- it just hasn't been finalized yet: http://www.w3.org/TR/XMLHttpRequest/

The Web API Working Group[1] is working on a bunch of other cool stuff too, like a selectors API[2] (image a jQuery-like selector engine that's native to the browser!)

Also, for those that are interested, here's some benchmarks of W3C DOM methods vs innerHTML: http://www.quirksmode.org/dom/innerhtml.html

[1] http://www.w3.org/2006/webapi/
[2] http://www.w3.org/TR/selectors-api/

--
Aaron Heimlich
Web Developer
aaron.heimlich@...
http://aheimlich.freepgs.com

--
Aaron Heimlich
Web Developer
aaron.heimlich@...
http://aheimlich.freepgs.com
_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[John Resig]

> Whatever the user enters in the input field will be copied to the element,
> but what if the user enters html? That could cause some serious havoc with
> your document. (Starting with jQuery 1.1 the .text() method is a setter, but
> at the moment it just sends the input to .html() which wouldn't fix this
> problem.)

Yes it does. jQuery 1.1 passes all of the text to
document.createTextNode() before inserting it into the DOM - causing
all HTML-like characters to be serialized.

--John

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[John Resig]

> Also, if you ever want to serve the page as XHTML your script will
> not work because innerHTML does not work for XML pages of course.

innerHTML works just fine on XHTML pages - jQuery.com is XHTML.
Additionally, as mentioned before, jQuery doesn't use innerHTML for
insertion - only serialization (even .html()). This way you can even
do:

  $(someXMLDoc).append("<foo bar='baz'/>");

--John

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[thumblewend]

On 01/02/2007, at 1:48 PM, John Resig wrote:
> innerHTML works just fine on XHTML pages - jQuery.com is XHTML.

Ah yes, I meant XHTML served as XML not text/html. Are you saying  
that innerHTML works even when served as an application of XML? If  
so, I stand gratefully corrected.
Joel.

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Chris Domigan]

Ah yes, I meant XHTML served as XML not text/html. Are you saying
that innerHTML works even when served as an application of XML? If
so, I stand gratefully corrected.
Joel.

I use  .html() fine and I'm serving  proper xml :)

Chris

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[thumblewend]

On 01/02/2007, at 1:58 PM, Chris Domigan wrote:

> Ah yes, I meant XHTML served as XML not text/html. Are you saying
> that innerHTML works even when served as an application of XML? If
> so, I stand gratefully corrected.
> Joel.
>
>
> I use  .html() fine and I'm serving  proper xml :)
>
> Chris

I was referring to using innerHTML only, though. It has been  
mentioned that .html() does not use innerHTML for insertion into the  
DOM.

Joel.

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Andronicus Riyono]

On 2/1/07, Joel Birch <j_birch@...> wrote:
> I was referring to using innerHTML only, though. It has been
> mentioned that .html() does not use innerHTML for insertion into the
> DOM.
>
> Joel.

Agreed, as far as i remember, using XHTML 1.1 and serving it as xml,
innerHTML is read only. that's one of the reasons why i go back to
XHTML 1.0 strict served as text/html nowadays...

--
---------------------------------------------
 There's nothing impossible for an open mind
---------------------------------------------

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[dave.methvin]

 
> It has been mentioned that .html() does not use innerHTML
> for insertion into the DOM.

Any of the jQuery functions that take a html string go through innerHTML to
convert it to DOM nodes. That includes .html() but also methods like
.append() when they are passed strings (as opposed to DOM nodes). If you
want to avoid innerHTML just use one of the DOM plugins.


_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Klaus Hartl]

Joel Birch schrieb:

> On 01/02/2007, at 12:30 PM, Karl Swedberg wrote:
>
>> I'd love to hear your opinions about this. With HTML/CSS stuff, I'm  
>> obsessed with standards and such. And one of the things that has  
>> always really attracted me to jQuery is its unobtrusiveness. I also  
>> read Jeremy Keith's DOM Scripting book and really appreciated his  
>> approach -- which is similar to what this commenter is suggesting.  
>> But I also love the super-fast development that can be done with  
>> jQuery and don't want to have to give that up if it's just a matter  
>> of someone's aesthetic sensibility being offended. I guess I just  
>> want to do the right thing.
>>
>
> Here is my current understanding of this issue. (Anyone, please  
> correct me where I am wrong). The main reason why innerHTML is said  
> to be evil is that it is not part of the standards. Therefore, if a  
> vendor creates a new user agent they may not decide to implement  
> support for it, leaving your web app or site broken and probably  
> adversely affected accessibility-wise. Whilst it is hard to imagine  
> any new browsers not supporting innerHTML as it is what some people  
> call a "pseudo-standard", I suppose it is not as hard to imagine  
> various new mobile devices and other unconventional browsers  
> supporting JavaScript but not what they may consider "extras" such as  
> innerHTML.
> Also, if you ever want to serve the page as XHTML your script will  
> not work because innerHTML does not work for XML pages of course.
> Personally, I have just resigned to using it when using jQuery  
> because the ease and speed benefits you mentioned are just too darn  
> seductive. The code is also much more readable so less-techy people  
> can possibly change the output easier.
> I'll be interested to hear what other people think about this.
>
> Joel Birch.

Joel, I couldn't have said it better. You read my mind.


-- Klaus


_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/