portfolio page

Jeff wrote:
> paul watt wrote:
>> Hi,
>> I've created a portfolio page using a Alistapart javascript.
>
> Why?
>
> Its at
>> http://www.paulwatt.info/port2.html . it works ok, but i want to add a
>> hyperlink to each image displayed.
>> How can I do this?
>
> Most people don't bother to walk the node tree.
>
> Just use innerHTML, it was originally an IE thing but everyone
> supports it. It makes life a lot easier.

Many purists would disagree. But in addition to being easier, it's also
considerably faster:
http://www.quirksmode.org/dom/innerhtml.html

You just have to keep in mind that there are some instances where
innerHTML won't work - such as adding items to a SELECT or adding rows
to a table

>
> Let me know if you don't how that works.
>
> Jeff
>
>>
 >> Stay informed about: portfolio page 

On 2 Jan, 09:41, Jeff <jeff DeleteThis @spam_me_not.com> wrote:

> I read something on this speed thing some time ago,

The quirksmode article is bogus and out of date too. All it ever
showed was that IE had speed problems with DOM access. Real browsers
are a whole different picture.


> I seem to
> recall that innerHTML works so well because it is tightly integrated
> into the rendering engine at a higher level.

WTF does that mean? "More tightly integrated" "at a higher level" is
simply tautological anyway. If you think for a moment about how
innerHTML works (it requires a parse operation on an arbitrary string)
then you'll appreciate just how awkward and slow it has the potential
to be. What happens if you embed "</html>" into your inserted HTML
data? Should it then truncate the entire DOM at that point? Whole can
of worms.

It's impossible to "benchmark" innerHTML because it's too open-ended a
question, depending on what you put into it. If you use it to insert
valid snippets; such as simple new <li> elements, then it will
typically be comparable with direct DOM access for practical purposes
(typical real-world code examples, ignoring IE's DOM speed problem).
If you insert a single element with huge text content (it all needs
parsing), then it can even be benchmarked to come out slower than a
DOM operation that inserts a new text node, with the implicit
information that there's no structural HTML content (i.e. tags) within
it.

OTOH, if you insert a large number of <li> into innerHTML, especially
if each one contains a large amount of HTML structure with many nested
elements, then you can easily beat DOM methods accessed from a slowish
scripting language like JavaScript. The key here is that you've only
hit the performance bottleneck of parsing _once_ for the whole
operation. The scripting language is also hitting the call overhead of
COM (or whatever) once for each DOM method call.

Personally I almost never use innerHTML, except for the very quickest
prototyping. In the minions' code (big intranet web apps) it's
specifically forbidden in favour of DOM methods, just for the
maintainability aspects. Using .innerHTML isn't itself unworkable, but
it does encourage some hideously sloppy coding style. Forcing the use
of DOM methods requires a bit mor ethought, and that tends to
encourage production of better code (on average, on large projects).
 >> Stay informed about: portfolio page 

Tony wrote:
> Jeff wrote:
>> paul watt wrote:
>>> Hi,
>>> I've created a portfolio page using a Alistapart javascript.
>>
>> Why?
>>
>> Its at
>>> http://www.paulwatt.info/port2.html . it works ok, but i want to add
>>> a hyperlink to each image displayed.
>>> How can I do this?
>>
>> Most people don't bother to walk the node tree.
>>
>> Just use innerHTML, it was originally an IE thing but everyone
>> supports it. It makes life a lot easier.
>
> Many purists would disagree.

And there's a lot of those!

> But in addition to being easier, it's also
> considerably faster:
> http://www.quirksmode.org/dom/innerhtml.html
>
> You just have to keep in mind that there are some instances where
> innerHTML won't work - such as adding items to a SELECT

Fortunately, there's long been an easy method to do that.

or adding rows
> to a table


You got me there.

I read something on this speed thing some time ago, and I seem to
recall that innerHTML works so well because it is tightly integrated
into the rendering engine at a higher level. I hadn't realized just how
slow the DOM methods are.

Looks like Paul will have to look this up himself, or annoy the
regulars at comp.lang.javascript. I think what Paul overlooked is that
there is no URL to pull out of the "this" reference, the href is already
pointing at the image source. I suppose he could add that to the link,
and it may or may not work, but it wouldn't be pure.

Jeff
>
>>
>> Let me know if you don't how that works.
>>
>> Jeff
>>
>>>
 >> Stay informed about: portfolio page 

Jeff wrote:

>> innerHTML won't work - such as adding items to a SELECT

<snip>

> Looks like Paul will have to look this up himself, or annoy the
> regulars at comp.lang.javascript. I think what Paul overlooked is that

Say, that wouldn't be Paul Lutus, would it?


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project - http://improve-usenet.org
 >> Stay informed about: portfolio page 

Blinky the Shark wrote:
> Jeff wrote:
>
>>> innerHTML won't work - such as adding items to a SELECT
>
> <snip>
>
>> Looks like Paul will have to look this up himself, or annoy the
>> regulars at comp.lang.javascript. I think what Paul overlooked is that
>
> Say, that wouldn't be Paul Lutus, would it?
>
>
I'm missing the punchline on this one Blinky.

I can't say that I've used any of his software, or read his book.. I
know he's an interesting guy, but...

Jeff
 >> Stay informed about: portfolio page 

Andy Dingley wrote:
> On 2 Jan, 09:41, Jeff <jeff.TakeThisOut@spam_me_not.com> wrote:
>
>> I read something on this speed thing some time ago,
>
> The quirksmode article is bogus and out of date too. All it ever
> showed was that IE had speed problems with DOM access. Real browsers
> are a whole different picture.
>
>
>> I seem to
>> recall that innerHTML works so well because it is tightly integrated
>> into the rendering engine at a higher level.
>
> WTF does that mean?

Damn if I know. You'll get that at 4:41 AM.

"More tightly integrated" "at a higher level" is
> simply tautological anyway. If you think for a moment about how
> innerHTML works (it requires a parse operation on an arbitrary string)
> then you'll appreciate just how awkward and slow it has the potential
> to be. What happens if you embed "</html>" into your inserted HTML
> data? Should it then truncate the entire DOM at that point? Whole can
> of worms.
>
> It's impossible to "benchmark" innerHTML because it's too open-ended a
> question, depending on what you put into it. If you use it to insert
> valid snippets; such as simple new <li> elements, then it will
> typically be comparable with direct DOM access for practical purposes
> (typical real-world code examples, ignoring IE's DOM speed problem).
> If you insert a single element with huge text content (it all needs
> parsing), then it can even be benchmarked to come out slower than a
> DOM operation that inserts a new text node, with the implicit
> information that there's no structural HTML content (i.e. tags) within
> it.

Well, that makes sense as the speed is related to the number of
operations.
>
> OTOH, if you insert a large number of <li> into innerHTML, especially
> if each one contains a large amount of HTML structure with many nested
> elements, then you can easily beat DOM methods accessed from a slowish
> scripting language like JavaScript. The key here is that you've only
> hit the performance bottleneck of parsing _once_ for the whole
> operation. The scripting language is also hitting the call overhead of
> COM (or whatever) once for each DOM method call.
>
> Personally I almost never use innerHTML, except for the very quickest
> prototyping. In the minions' code (big intranet web apps) it's
> specifically forbidden in favour of DOM methods, just for the
> maintainability aspects.

My guess is that AJAX is opening up all these questions. Without it,
there just isn't enough reasons to use either to care.

I suppose if you are inserting premade html then it makes sense to
use innerHTML. If you are taking data and then formatting html out of
that then the DOM makes sense. And if you are reordering html, like you
would do if you were sorting tables by column, then it's much easier to
keep track of using DOM methods.

Of course none of this discussion helps the OP, but then, that's the
nature of usenet!

Jeff



Using .innerHTML isn't itself unworkable, but
> it does encourage some hideously sloppy coding style. Forcing the use
> of DOM methods requires a bit mor ethought, and that tends to
> encourage production of better code (on average, on large projects).
 >> Stay informed about: portfolio page 

Jeff wrote:

> Blinky the Shark wrote:
>> Jeff wrote:
>>
>>>> innerHTML won't work - such as adding items to a SELECT
>>
>> <snip>
>>
>>> Looks like Paul will have to look this up himself, or annoy the
>>> regulars at comp.lang.javascript. I think what Paul overlooked is that
>>
>> Say, that wouldn't be Paul Lutus, would it?
>>
>>
> I'm missing the punchline on this one Blinky.

There wasn't any. I saw "innerHTML", which sounds Lutuslike, and I saw
"annoy", and make a guess.

> I can't say that I've used any of his software, or read his book.. I
> know he's an interesting guy, but...

Historically speaking, I don't know if you're aware that he wrote Apple
Writer in the late 1970s, which IIRC was "the" Apple word processor before
the Apple Works suite came along. Before there were Macs.


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project - http://improve-usenet.org
 >> Stay informed about: portfolio page 

On 2 Jan, 12:26, Jeff <jeff.DeleteThis@spam_me_not.com> wrote:

> My guess is that AJAX is opening up all these questions. Without it,
> there just isn't enough reasons to use either to care.

No, AJAX is closing off the options. Old hackery could work
with .innerHTML but large AJAX systems need careful good-practice work
through the DOM or else the whole thing falls into a fragile pile that
you can't maintain.

As much AJAX is also increasingly built from server-side frameworks,
the authors see less and less of the client-side JS or the generated
HTML anyway. Most of these frameworks (all the good ones!) use DOM
methods in their generated code, not innerHTML.



> I suppose if you are inserting premade html then it makes sense to
> use innerHTML.

If it's "premade" and static enough for this to be a good idea, you
can just use SSI.
 >> Stay informed about: portfolio page 

On Jan 2, 4:26 am, Tony <nos....RemoveThis@example.com> wrote:
> Jeff wrote:
> > paul watt wrote:
> >> Hi,
> >> I've created a portfolio page using a Alistapart javascript.
>
> > Why?
>
> > Its at
> >>http://www.paulwatt.info/port2.html. it works ok, but i want to add a
> >> hyperlink to each image displayed.
> >> How can I do this?
>
> > Most people don't bother to walk the node tree.
>
> >   Just use innerHTML, it was originally an IE thing but everyone
> > supports it. It makes life a lot easier.
>
> Many purists would disagree. But in addition to being easier, it's also
> considerably faster:http://www.quirksmode.org/dom/innerhtml.html

innerHTML is a string.
The DOM is not a string, it's a hierarchal object structure. Shoving a
string into an object is impure and similar to wrapping a spaghetti
noodle around an orange and calling it lunch.

Alternatives to innerHTML:
http://slayeroffice.com/articles/innerHTML_alternatives/
 >> Stay informed about: portfolio page 

Andy Dingley wrote:
> On 2 Jan, 12:26, Jeff <jeff RemoveThis @spam_me_not.com> wrote:
>
>> My guess is that AJAX is opening up all these questions. Without it,
>> there just isn't enough reasons to use either to care.
>
> No, AJAX is closing off the options. Old hackery could work
> with .innerHTML but large AJAX systems need careful good-practice work
> through the DOM or else the whole thing falls into a fragile pile that
> you can't maintain.
>
> As much AJAX is also increasingly built from server-side frameworks,
> the authors see less and less of the client-side JS or the generated
> HTML anyway. Most of these frameworks (all the good ones!) use DOM
> methods in their generated code, not innerHTML.
>

My last job was building a heavily ajax-based system. Frameworks that
used DOM methods were painfully slow. innerHTML was quite fast.

You said the Quirksmode article was out of date and inaccurate - I'd
like to see the supporting evidence for your contention. My experience
tends to back up what PPK says.
 >> Stay informed about: portfolio page 

Blinky the Shark wrote:
> Jeff wrote:
>
>> Blinky the Shark wrote:
>>> Jeff wrote:
>>>
>>>>> innerHTML won't work - such as adding items to a SELECT
>>> <snip>
>>>
>>>> Looks like Paul will have to look this up himself, or annoy the
>>>> regulars at comp.lang.javascript. I think what Paul overlooked is that
>>> Say, that wouldn't be Paul Lutus, would it?
>>>
>>>
>> I'm missing the punchline on this one Blinky.
>
> There wasn't any. I saw "innerHTML", which sounds Lutuslike, and I saw
> "annoy", and make a guess.

I was referring to Paul Watt, the OP who started this thread.

Although I can see getting your innerHTML as something Lutus would do!
>
>> I can't say that I've used any of his software, or read his book.. I
>> know he's an interesting guy, but...
>
> Historically speaking, I don't know if you're aware that he wrote Apple
> Writer in the late 1970s, which IIRC was "the" Apple word processor before
> the Apple Works suite came along. Before there were Macs.

Loosely. I had to look it up.

I did read how he knew it worked when he was struck by lightening and
it picked up where he left off. That's an experience I wish Bill Gates
would have had, of course, it wouldn't have worked afterwards!
>
>
 >> Stay informed about: portfolio page 

Jeff wrote:

> Blinky the Shark wrote:
>> Jeff wrote:
>>
>>> Blinky the Shark wrote:
>>>> Jeff wrote:
>>>>
>>>>>> innerHTML won't work - such as adding items to a SELECT
>>>> <snip>
>>>>
>>>>> Looks like Paul will have to look this up himself, or annoy the
>>>>> regulars at comp.lang.javascript. I think what Paul overlooked is that
>>>> Say, that wouldn't be Paul Lutus, would it?
>>>>
>>>>
>>> I'm missing the punchline on this one Blinky.
>>
>> There wasn't any. I saw "innerHTML", which sounds Lutuslike, and I saw
>> "annoy", and make a guess.
>
> I was referring to Paul Watt, the OP who started this thread.

Okay. Thanks for that, even though I had to drag it out of you.


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project - http://improve-usenet.org
 >> Stay informed about: portfolio page 

RafaMinu wrote:
> On Jan 2, 4:26 am, Tony <nos....RemoveThis@example.com> wrote:
>> Jeff wrote:
>>> paul watt wrote:
>>>> Hi,
>>>> I've created a portfolio page using a Alistapart javascript.
>>> Why?
>>> Its at
>>>> http://www.paulwatt.info/port2.html. it works ok, but i want to add a
>>>> hyperlink to each image displayed.
>>>> How can I do this?
>>> Most people don't bother to walk the node tree.
>>> Just use innerHTML, it was originally an IE thing but everyone
>>> supports it. It makes life a lot easier.
>> Many purists would disagree. But in addition to being easier, it's also
>> considerably faster:http://www.quirksmode.org/dom/innerhtml.html
>
> innerHTML is a string.
> The DOM is not a string, it's a hierarchal object structure. Shoving a
> string into an object is impure and similar to wrapping a spaghetti
> noodle around an orange and calling it lunch.
>
> Alternatives to innerHTML:
> http://slayeroffice.com/articles/innerHTML_alternatives/

From the linked page:

"It's not a standard. It's a proprietary property that Microsoft
introduced (along with the less popular outerHTML) that the other
browser makers picked up."

Couldn't you say exactly the same thing about XMLHttpRequest?
 >> Stay informed about: portfolio page