Really Ugly?

[thumblewend]

On 01/02/2007, at 6:56 PM, Klaus Hartl wrote:
> Joel, I couldn't have said it better. You read my mind.
>
> -- Klaus

That might be because I most likely learnt all of that from you at  
some stage.
Thanks Klaus.

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

[Klaus Hartl]

Brandon Aaron schrieb:

> 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.

Thanks Brandon, yeah, that quote is quite old...


-- Klaus


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

[Klaus Hartl]

Stephen Woodbridge schrieb:

> 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

Steve, on the other hand, even if you use the standard methods to create
elements, you will not get content and structure separated of course.

You'll just use 5 lines more to obfuscate it ;-)


-- Klaus


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

[Klaus Hartl]

Joel Birch schrieb:
> 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.

It is a common misunderstanding amongst web developers that using an
XHTML Doctype on top of a document makes it XHTML. It's not, it's
actually still HTML with some weird slashes here and there where they
don't belong. The document will still be parsed by the HTML tag soup parser.

The reason why this works at all is that the HTML parsers are pretty
error prone and will ignore these slashes. Nonetheless the W3C
recommends to follow the HTML Compatibility Guidelines when using XHTML
but serving it as text/html:
http://www.w3.org/TR/xhtml1/guidelines.html

But then people even put an XML declaration on top and serve it as
text/html...

To sum it up: "MIME types matter; DOCTYPEs don't" (Anne van Kesteren,
http://annevankesteren.nl/2004/07/mime).

If you're serving as text/html it is always HTML. If you're serving as
application/xhtml+xml it's XHTML. I do that as an exercise on my own
blog. Beware of draconian error handling and some subtle but important
differences for style sheets and DOM scripting.

With IE 7 not supporting true XHTML I consider XHTML pretty dead for at
least the next few years. And have started to switch back to HTML 4 Strict.


-- Klaus



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

[Klaus Hartl]

Klaus Hartl schrieb:
>> Just wanted to clear that up.
>
> Thanks Brandon, yeah, that quote is quite old...

Old in terms of jQuery age :-)


-- Klaus


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

[Christof Donat]

Hi,

> Hence 7 lines instead of 4.

Nope. Without a DOM-builder plugin I would write this

> >> $('#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 way:

$('#show-alert').click(function() {
        $(document.createElement('div'))
                .addClass('quick-alert')
                .text("Alert! Watch me before it's too late!")
                .insertAfter(this);
});

5 Lines with readability optimization, 1 without ;-)

Daves solution is even shorter than yours, but you need to load the
DOM-builder plugin first. Using olsows DOM-builder plugin
http://mg.to/2006/02/27/easy-dom-creation-for-jquery-and-prototype#comment-176 
you would write:

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

That is a bit longer than daves solution, but on the other hand olsows plugin
is very small.

Christof

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

[Brandon Aaron]

On 2/1/07, Klaus Hartl <klaus.hartl@...> wrote:
> With IE 7 not supporting true XHTML I consider XHTML pretty dead for at
> least the next few years. And have started to switch back to HTML 4 Strict.

Same here actually. Each new site I've been doing recently is all HTML 4 Strict.

--
Brandon Aaron

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

[Karl Swedberg-2]

Thanks, everyone, for the excellent responses to my question. I knew I could count on this group to provide well informed, well reasoned advice.

To be fair to the commenter, he did mention one of the DOM creation plugins (I just didn't include that part of the comment in the original post):

Or, with the DOMCreate plugin for jQuery :

$('#show-alert').click(function() {

var oDiv = jQuery.create('div', {'class':'quick-alert'}, ["Alert ! Watch me before it's too late !"]});

$(this).after(oDiv);

}

Thanks also for the links to other resources on the innerHTML matter. I've been reading the excellent PPK on JavaScript, so I thought I'd add a couple quotes from that book into the mix:

Even though officially it's a Microsoft proprietary property, it is supported by all modern browsers, and is a required item in the bag of tricks any JavaScripter should carry...

innerHTML is not a part of the W3C DOM specification. For some people, that's reason enough not to use it. Personally, I disagree sharply ...innerHTML is excellently suited for some tasks, and it has perfect browser compatibility.

You'll have to decide this for yourself, but I don't see any good reasons for refusing to use innerHTML. Instead, we should try to find out in which situations innerHTML will work better than pure DOM methods, and in which situations the pure methods will have the advantage...

Since innerHTML is so powerful, you should take care to always pass it correct HTML. Garbage HTML can cause very weird effects....

- PPK on Javascript, Peter-Paul Koch. 380, 381.

Cheers, everyone, and thanks again for all the excellent input!

--Karl

_________________

Karl Swedberg

www.englishrules.com

www.learningjquery.com

On Feb 1, 2007, at 2:56 AM, Klaus Hartl wrote:

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/

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

[thumblewend]

On 02/02/2007, at 12:26 AM, Brandon Aaron wrote:

> On 2/1/07, Klaus Hartl <klaus.hartl@...> wrote:
>> With IE 7 not supporting true XHTML I consider XHTML pretty dead  
>> for at
>> least the next few years. And have started to switch back to HTML  
>> 4 Strict.
>
> Same here actually. Each new site I've been doing recently is all  
> HTML 4 Strict.
>
> --
> Brandon Aaron

My preference is also to use HTML 4 Strict. However, when a client  
mentions XHTML because they've heard it's desirable, I do not fight  
the battle and simply serve XHTML 1 Strict served as HTML. There are  
bigger things to worry about, considering that they amount to the  
same thing and will for a while. It was good to hear everyone's  
opinion on all these things.

Joel.

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

[Christof Donat]

Hi,

> Steve, on the other hand, even if you use the standard methods to create
> elements, you will not get content and structure separated of course.

Yes of course. If that is the goal, use load() to get some template-content or
clone it from the page and fill it with your dynamic data:

$('#show-alert').click(function() {
        var clone = $('.alerttemplate')
                .clone()
        clone.html(
                clone.html()
                        .replace(/\$\{content\}/,"Alert! Watch me before it's too late!")
                        .replace(/\$\{class\}/,'quick-alert')
        ).insertAfter(this);
});

Of course that is longer, but it should be the best way to really separate
content and code. Oops we have been using innerHTML ;-)

Of course for some browsers that can be resolved with XSL/T, but, alas we need
ActiveX to convince IE to cooperate...

Yes, I try to avoid innterHTML wherever possible, but I don't think there
should be a dogma.

Christof

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

[Geoffrey Knutzen]

I am kicking off a new project today and I am going back to HTML 4 strict as
well.

Note that Yahoo is HTML 4 strict for IE 7 & FF, but not for IE 6

-----Original Message-----
From: discuss-bounces@... [mailto:discuss-bounces@...] On
Behalf Of Brandon Aaron
Sent: Thursday, February 01, 2007 5:26 AM
To: jQuery Discussion.
Subject: Re: [jQuery] Really Ugly?

On 2/1/07, Klaus Hartl <klaus.hartl@...> wrote:
> With IE 7 not supporting true XHTML I consider XHTML pretty dead for at
> least the next few years. And have started to switch back to HTML 4
Strict.

Same here actually. Each new site I've been doing recently is all HTML 4
Strict.

--
Brandon Aaron

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


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