On Jun 2, 4:18 pm, Laurent vilday <mok> wrote:
> Thomas 'PointedEars' Lahn a écrit :
>>
> Are you, both, talking about a static HTML document or a dynamic web
> application ?

At a minimum, I'm discussing HTML pages where JavaScript is being used
and whether or not it is acceptable to depend on JavaScript. If it is
acceptable then under which circumstances.

Peter

In comp.lang.javascript message <48445DB3.2050507>, Mon,
2 Jun 2008 22:53:07, Thomas 'PointedEars' Lahn <PointedEars>
posted:
>Peter Michaux wrote:

>> Unfortunately you continue to berate others for similar types of
>> activities. [...]
>
>I am not going to comment on this new ad-hominem attack-rant of yours. It
>is a pity that you deem it necessary to resort to such things in order to
>back up your argumentation.

Don't misuse language. We do not use the fact that you are an obnoxious
hectoring bully as an argument against the technical validity of what
you say about JavaScript. Instead, we point out the unreasonable and
anti-social nature of your character, which is perfectly obvious of
itself to all bar you. If you were to get the appropriate psychiatric
treatment, and if it were to prove permanently successful, then you
might become a valued member of society. As it is, one can only wonder
whether there are still intact logs in Doorn.

VK wrote:
> On Jun 1, 5:31 pm, Dan Rumney <danrum> wrote:
>> VK, PointedEars,
>>
>> Please don't hijack this thread to bicker about accessibility.
>
> IMHO it is not hijacking but branching on a sub-topic within the same
> main topic. But I have no problem with shifting to a new topic like
> "Javascript and accessibility" if more on the sub-topic will be
> posted.
>
Then may I suggest that you take it to a separate thread rather than
confuse this one. I shall be pleased to join you there and comment on
what I fear are your barking mad opinions about the W3C. Do you have
some sort of personal gripe?

Peter Michaux wrote:
> On Jun 2, 4:18 pm, Laurent vilday <mok> wrote:
>
> At a minimum, I'm discussing HTML pages where JavaScript is being used
> and whether or not it is acceptable to depend on JavaScript. If it is
> acceptable then under which circumstances.
>
Is it reasonable to depend on Javascript in some conditions? Yes.
Is it reasonable to do so for a web page? No.

Why the difference (a question you did not ask)?

Answer:-
Javascript is a processing language and should be relied on where it
is the appropriate language for the intended location (client or
server) to carry out functions to be performed by a specific
application or process task. In these circumstances, Javascript
interpretation, any support software and specific sandbox settings or
activation on the target system should be part of the installation of
the process software or task set-up.

However, HTML is not a specific application (it is a general one) nor
process task (again, it is general). A particular web page may be
*intended* to be used as either or both an application or task but, if
so, it must specify the location, requirement and provision of
Javascript *PRIOR_TO* its use and must itself provide all those
requirements also prior to use. This is quite impractical for a web
page and so should not be relied upon.

> Are there any hidden advantages or disadvantages I may be aware of?

After some consideration and experimentation, one thing did occur to
me.

If a webpage is created on the client with multiple requests back to
the server for content, then that webpage can't be saved for later
offline viewing.

For my particular needs, that's no good.

I did spend a little time toying with the idea of creating some
Javascript and server code that would result in the Javascript packing
up the newly generated page and all the generated Javascript
objects... essentially freezing the state of the page and then passing
it back to the server which would respond by returning a ZIP file
containing all the necessary elements needed to view the page offline.

I then realised that was barmy. Why go to all the effort of that in
order to implement a content creation model that I wasn't even sure
was worth implementing in the first place!

Thanks to all for their comments. There have been some insightful
ones. I hope others have found this thread edifying.

On Jun 3, 8:32 pm, The Magpie <use> wrote:
> VK wrote:
>>
> Then may I suggest that you take it to a separate thread rather than
> confuse this one. I shall be pleased to join you there and comment on
> what I fear are your barking mad opinions about the W3C. Do you have
> some sort of personal gripe?

No, I don't any have personal gripe with W3C. If you think that
everything is just fine with both HTML standards and W3C then let's
talk about these illusions at comp.infosystems.www.authoring.html
because it gets pretty OT for clj( Follow-up to
comp.infosystems.www.authoring.html is set).

We just need to make a deal about some mouth control, so say opponents
will "saying" or "expressing an opinion" but not "barking" or making
other types of mis-articulated noise; and these will be "a different
opinion" or "an opinion I cannot agree with" but not "a mad idea" or
similar.

With such deal being set feel free to answer at ciwah.

Dan Rumney wrote:
>> Are there any hidden advantages or disadvantages I may be aware of?
>
> After some consideration and experimentation, one thing did occur to
> me.
>
> If a webpage is created on the client with multiple requests back to
> the server for content, then that webpage can't be saved for later
> offline viewing.

Yes, a snaphot of it can be saved. However, the application needs to
provide means to generate a static document from the dynamically generated
one. A document tree serialization may be used to create it within another
container (e.g. a popup window); the proprietary XMLSerializer(),
`outerHTML' and `innerHTML' features may be used for this.

Please don't remove the attribution line.


PointedEars

Thomas 'PointedEars' Lahn wrote:
> Dan Rumney wrote:
>>> Are there any hidden advantages or disadvantages I may be aware of?
>> After some consideration and experimentation, one thing did occur to
>> me.
>>
>> If a webpage is created on the client with multiple requests back to
>> the server for content, then that webpage can't be saved for later
>> offline viewing.
>
> Yes, a snaphot of it can be saved. However, the application needs to
> provide means to generate a static document from the dynamically generated
> one. A document tree serialization may be used to create it within another
> container (e.g. a popup window); the proprietary XMLSerializer(),
> `outerHTML' and `innerHTML' features may be used for this.

I should have written "can't *readily* be saved", I suppose.

Certainly, saving the generated HTML wouldn't be too tricky. My concern
would be in persisting any arbitrary Javascript objects which had been
generated as part of the current representation of the dynamic page and
which would be necessary for ongoing offline functioning of the page.

For me, the complexity of putting this solution together is sufficient
that it ceases to be worth it. I'm better off generating the content
dynamically on the server.

Others may feel its worth persevering with. To them, I wish good luck.

On Jun 3, 9:28 am, Dr J R Stockton <j> wrote:
[..]
> itself to all bar you. If you were to get the appropriate psychiatric
> treatment, and if it were to prove permanently successful, then you
> might become a valued member of society. As it is, one can only wonder
> whether there are still intact logs in Doorn.
>
> --
> (c) John Stockton, nr London, UK. ?...@merlyn.demon.co.uk Turnpike v6.05 MIME.
> Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
> Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
> Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

Cheers to that. It's a pity some people spend more time on petty
agendas (petty to the rest of us, anyway) and let their obvious
technical prowess get lost in the sound and fury.

Tyler

> You are ducking the issue. For the purpose of this discussion these
> are my business constraints. This is a realistic, possible situation
> in which a programmer may find himself.

Eh, don't listen to pointed ears. He likes to bicker about unrelated
shit.

On Jun 1, 4:53 am, Dan Rumney <dancr> wrote:
>
> I've been thinking about an alternative approach, whereby the page is
> built on the fly with various AJAX calls to the server to pull in the
> necessary components. In the extreme, I could visualize doing away
> with Perl generated pages entirely. All pages are HTML, with AJAX
> calls to the server. The responding scripts would return JSON or XML
> data which would be interpreted on the client side as required.

Hi Dan,

I also started playing with this idea some months back. i wrote a
post on this subject: http://schettino72.wordpress.com/200...script-widget/

I am successfully using this approach to design js widgets.

> If a webpage is created on the client with multiple requests back to
> the server for content, then that webpage can't be saved for later
> offline viewing.

Note that you dont need necessarilly to get your json(or whatever
data) from an AJAX call. I am passing the initial data data on div
with display set to none. this way it is possible to save the page and
see the content again offline.
of course this would work only if the data is not modified
dynamically. not sure your requirements ... but thats an idea.

cheers,
Eduardo

schettino72 wrote:
> On Jun 1, 4:53 am, Dan Rumney <dancr> wrote:
>> I've been thinking about an alternative approach, whereby the page is
>> built on the fly with various AJAX calls to the server to pull in the
>> necessary components. In the extreme, I could visualize doing away
>> with Perl generated pages entirely. All pages are HTML, with AJAX
>> calls to the server. The responding scripts would return JSON or XML
>> data which would be interpreted on the client side as required.
>
> [...]
> I also started playing with this idea some months back. i wrote a
> post on this subject: [..]

The script is junk, or as you would put it, bullshit, as it does not degrade
gracefully. (I wonder why people who want to build widgets don't start with
something obvious and simple, say, form controls.)

> I am successfully using this approach to design js widgets.

Self-delusion comes in small packages.

Next, please.


PointedEars

P.S.
Since Dan is a Google Groups user and does not post with only e-mail address
in the From header, he must have subscribed to this newsgroup (as you
probably have). Therefore I doubt he appreciates your Cc:ing him unsolicited.

On Jun 16, 2:14 am, Thomas 'PointedEars' Lahn <PointedE>
wrote:
>
> > [...]
> > I also started playing with this idea some months back. i wrote a
> > post on this subject:[..]...
>
> The script is junk, or as you would put it, bullshit, as it does not degrade
> gracefully. [...]

hehehe. good one.
I guess you didnt get it. It is clear to everybody in this thread that
we are not discussing about accessibility. remember?

On Jun 1, 6:31 pm, Dan Rumney <danrum> wrote:
> VK, PointedEars,
> Please don't hijack this thread to bicker about accessibility.

But since we are on the subject... Graceful degradation is not the
only way to deal with accessibility. You could have 2 versions of your
page one for the folks that have javascript and other for who doesnt.
So when a user that doesnt have javascript comes to your page, he is
redirect to another version of the page that does not require
javascript. I am not sure but it seems that gmail uses this aproach -
they have 2 versions of gmail, not one with graceful degradation.
Does it seem doable to you?

> (I wonder why people who want to build widgets don't start with
> something obvious and simple, say, form controls.)
Thats easy. It is because people that want to build widgets dont want
to build *any* widget. If they need a "Super XYZ" they cant just build
form controls widget. understand?

> Next, please.

Not so fast ;)
Lets assume that accessibility for the folks with no javascript is
always necesasry...
Now the question is: What is better? Graceful degradation or 2
versions (javascript/no javascript) of your page?
Well, it is impossible to give a definitive answer. for something
obvious and simple I guess graceful degradation will always be easier.
But for complex widgets I am not sure.

Let's have a constructive discussion. You could start implementing a
basic album viewer with graceful degradation. It can be a crap, like
mine, the point is just to understand the advantages and disavantages
of each approach...


>
> PointedEars
>
> P.S.
> Since Dan is a Google Groups user and does not post with only e-mail address
> in the From header, he must have subscribed to this newsgroup (as you
> probably have). Therefore I doubt he appreciates your Cc:ing him unsolicited.

I guess most peole, like me, are just casual readers that dont follow
or reply every single mail in high traffic email list like this. Since
I am coming late to this discussion I though Dan might not be
following it anymore. Since he was asking for feedbackI would not
classify it as "unsolicited". Anyway,Dan I apologize if I've caused
any incovenient to you.

cheers,
Eduardo

schettino72 wrote:
> Thomas 'PointedEars' Lahn wrote:
>>> [...]
>>> I also started playing with this idea some months back. i wrote a
>>> post on this subject:[..]...
>> The script is junk, or as you would put it, bullshit, as it does not degrade
>> gracefully. [...]
>
> hehehe. good one.
> I guess you didnt get it. It is clear to everybody in this thread that
> we are not discussing about accessibility. remember?
>
> On Jun 1, 6:31 pm, Dan Rumney <danrum> wrote:
>> VK, PointedEars,
>> Please don't hijack this thread to bicker about accessibility.

You should have read my reply to that, then you would not have needed
to make this sideshow.

This isn't e-mail, BTW.


PointedEars

On Jun 15, 11:26 am, schettino72 <schettin> wrote:
> On Jun 1, 4:53 am, Dan Rumney <dancr> wrote:
>

[snip]

>
> I also started playing with this idea some months back. i wrote a
> post on this subject:[..]...
>

[snip]

Those photos are cool. What is that?


> Note that you dont need necessarilly to get your json(or whatever
> data) from an AJAX call. I am passing the initial data data on div
> with display set to none. this way it is possible to save the page and
> see the content again offline.
> of course this would work only if the data is not modified
> dynamically. not sure your requirements ... but thats an idea.


If you're going to do that, then make a list of links.

<ul>
<li><a href="hens.jpg" title="desc o hens">hens</a></li>
</ul>

I did that for Y! about 3.5 years ago. After I made that
functionality, the producer told me that they were "going with a popup
and using a third party slideshow".

I got the images with 90's style Ajax - new Image(). I also used fade
effect for transitioning one to the next. All following the long-
forgotten LSM (Layered, Semantic Markup).