JSON without AJAX

T

Thomas 'PointedEars' Lahn

Lasse said:
A plausible theory, but not the way it is, sadly.
If IE simply didn't recognize HTML 4.01 doctypes, then the declaration
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
should trigger standards mode.
Click to expand...

No, it should not. Without a system identifier, Quirks/Compatibility Mode
should be and is indeed triggered in all known browsers that support
DOCTYPE switching. It happens that the system identifier, i.e. the DTD
URL, makes the difference.

<URL:http://hsivonen.iki.fi/doctype/>

The reason why declaring HTML 4.0 without system identifier triggers
(Almost) Standards Compliance Mode is not well-founded IMHO. Even in
HTML 4.0, which has been obsoleted 6 years ago, the system identifier
was part of the specification.

<URL:http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.2>


PointedEars
 
V

VK

Thomas said:
No, it should not. Without a system identifier, Quirks/Compatibility Mode
should be and is indeed triggered in all known browsers that support
DOCTYPE switching. It happens that the system identifier, i.e. the DTD
URL, makes the difference.
Click to expand...

This question is formally out of topic - and actually is out
JavaScript/JScript domain. But for testing purposes it is important to
know how to guaranteed put IE into Strict mode (or whatever IE thinks
Strict mode is). I studied carefully:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>
but I have to admit that I left even more clueless than before I came
there.

So what is the magic DTD which works for both IE and all standard
compliant browsers? And why all articles on MSDN seem to be about IE
6.x? Does it mean that IE 5.5 works only in one "IE-or-kiss-my-a**"
mode?
 
B

bwucke

Robert said:
True, but it doesn't change the fact that the are not equally
unreliable. If for some reason you are forced to take one of these
planes which one would you take?
If they are (almost) equally unreliable it sounds like you don't have
much of a preference :p
Click to expand...

You can sometimes quit the game.
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
Lasse Reichstein Nielsen wrote:

No, it should not. Without a system identifier, Quirks/Compatibility Mode
should be and is indeed triggered in all known browsers that support
DOCTYPE switching.
Click to expand...

I don't know where you got that idea, but it is not, and never was,
the way the DOCTYPE switching worked.

The MSDN page that has been referred a few times already was the
original documentation of DOCTYPE switching when it was first
introduced in IE 5.5. There is no standard governing it. All later
implementations in later versions of IE and in other browsers have
chosen to be compatible with IE 5.5's DOCTYPE switch for purely
pragmatic reasons.

A DOCTYPE declaration without a system identifier, but with a puiblic
public identifier specifying a strict version of HTML 4 (4.0 or 4.01)
will trigger standards mode.
It happens that the system identifier, i.e. the DTD URL, makes the
difference.
Click to expand...


It is defined that way in some cases, yes, and for a Strict version
of HTML 4, the system identifier doesn't make a difference ...
<URL:http://hsivonen.iki.fi/doctype/>
Click to expand...

.... except in Mac IE 5, according to this page.

The reason why declaring HTML 4.0 without system identifier triggers
(Almost) Standards Compliance Mode is not well-founded IMHO. Even in
HTML 4.0, which has been obsoleted 6 years ago, the system identifier
was part of the specification.
Click to expand...

DOCTYPE switching has never been formally reasoned. It was merely a
pragmatic way of allowing new pages to select standards mode while
breaking as few existing pages as possible. Whether you violate the
HTML standard by omitting the system identifier or not is not relevant
to whether standards mode CSS interpretation should be used. What
matters is that old pages is rendered in the way they are intended,
and new pages are rendered according to the CSS1 standard.

Personally, I would prefer as many DOCTYPE's as possible to trigger
standards mode, so an unsuspecting page author will not trigger quirks
mode unless he really means it. Making an absolutely correct HTML
DOCTYPE declaration a prerequisite for standards mode would be counter
to that wish.

(With "almost standards mode" we really have three modes now: As IE 5
did it, as IE 6 does it, and as the standard says. When IE 7 comes, we'll
probably have "almost, but not entirely, completely unlike standard mode"
too.)

/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
I don't know where you got that idea, but it is not, and never was,
the way the DOCTYPE switching worked.
Click to expand...

It is.
[...]
A DOCTYPE declaration without a system identifier, but with a puiblic
public identifier specifying a strict version of HTML 4 (4.0 or 4.01)
will trigger standards mode.
Click to expand...

That is not what you stated, so not what I replied to.


BTW: Merry Christmas! to all who celebrate it :)

PointedEars
 
L

Lasse Reichstein Nielsen

It's a conditional statment: *If* IE didn't *recognize* the DOCTYPE,
*then* it should use the rule for an unrecognized DOCTYPE, which means
switching to standards mode.

As it is, it does recognize it, but the statment is still correct.

This was written in response to
<URL:where VK said that IE didn't have HTML 4.01 in its "registered DOCTYPE
table", and that the strict DOCTYPE triggered standards mode for this
reasons. The transitional DOCTYPE without system identifier was a
counterexample to this.
That is not what you stated, so not what I replied to.
Click to expand...

It seems what you responded to was also not what I stated, since we
are both right :)
BTW: Merry Christmas! to all who celebrate it :)
Click to expand...

Indeed, merry christmas to all.

/L 'and stay jolly!'
 
M

Matt Silberstein

Thomas 'PointedHead' Lahn babbled the following incoherently in
comp.lang.javascript:

I can load .js files dynamically just as reliably as I can load them
statically. Either something is reliable and always works, or, it is
unreliable and doesn't always work. Since external files can never
"always be loaded" then it is unreliable. As is loading them
dynamically. That makes them both unreliable. And unreliable is not
relative. If two things are both unreliable, then they are equally
unreliable.
Click to expand...

Nonsense. Something can work 99% of the time, something else 1%, they
are not equally reliable.
In the future, it might help you if you would endeavor to understand the
language I am using and the meanings of what I post. It would keep you
from replying as much and keep me from correcting you so much.
Click to expand...
--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"
 
V

VK

Matt said:
Nonsense. Something can work 99% of the time, something else 1%, they
are not equally reliable.
Click to expand...

That is a persistent discussion in this group of the definition "work",
"doesn't work", "universal" and "reliable". Like:
<http://groups.google.com/group/comp..._frm/thread/c532483403801387/13291deab867e19b>

As both sides seem to have explored all possible arguments and
injurations, one can just join to one side or other.

JavaScript/JScript program just cannot "work" in all possible
environments - in the meaning always produce the exact intended results
- unless it's something really primitive on JavaScript 1.0 level.

But the program should always try to handle its environmental problems
internally thus never let any errors to go uncaught out of the program
context - so it would halt any script execution on the current page
(JavaScript "blue screen" equivalent).
I say "should try to handle" instead of "must handle" because there are
always situations which are out of scope and power of software
developers (think Konqueror 1.x)

Also in a functional environment program should show a stable
functionning *withing the spelled usage rules*.

Therefore I don't care at all if say script impants will not work under
Netscape 4, Opera 6, SuperMuper 0.1 etc. - as long as attempt to use
them do not lead to the script abort and as long as user gets a nice
explanation in say myObject.error.message field.

I also don't care if it will be defined that script implants shouldn't
be used no more than say 1024 per page with the max refresh rate say
5sec - as long as it stated clearly in the manual.

But as long as the defined system requirements and usage rules are
accomplished, the script has to work as intended.

That's the point of view I follow and will follow. For a discussion of
how wrong I am (if any - and w/o my participation) it would be the most
approipriate to move the relevant discussion into a new thread.
 
B

bwucke

VK said:
Matt Silberstein wrote:
But the program should always try to handle its environmental problems
internally thus never let any errors to go uncaught out of the program
context - so it would halt any script execution on the current page
(JavaScript "blue screen" equivalent).
I say "should try to handle" instead of "must handle" because there are
always situations which are out of scope and power of software
developers (think Konqueror 1.x)
Click to expand...

or out of their concern. If I write a greasemonkey (Firefox extension)
script, do I really have to worry if it works correctly in MSIE and
Opera? Do I have to check for methods I -know- Firefox supports, and
know the script won't be ever executed outside Greasemonkey sandbox?

Right now I'm writing a js app where I don't bother about MSIE
compatiblity. It does one simple check, and says "Sorry, MSIE is not
supported." It makes heavy use of features MSIE doesn't support, and
trying to be compatibile would severely cripple it. I know the target
audience has almost entirely switched to non-MSIE browsers, so I don't
worry too much about it. And for all the rest there's a primitive
non-js text-only interface. Sure I could try making workarounds and
crippled versions of all its parts to get it to run in MSIE, but that
would possibly double my amount of work, and I had enough headaches
with Opera support already.

Also in a functional environment program should show a stable
functionning *withing the spelled usage rules*.
Click to expand...

You can't spell out -all- the rules. Try spelling out the rules for
hardware: non-faulty, non-infected, non-crippled, non-overloaded,
non-underpowered, non-overheated...
You didn't say the PC running your app can't be submerged 5m deep in a
swamp, therefore your app failing to run on it is not reliable?
We should draw a clear line of responsiblity. An app running on a
faulty system isn't necessarily wrong. It's the system that's wrong.
And with the state of JS interpreters nowadays, ALL systems are more or
less faulty. Apps may do all within their power to patch and avoid
holes in the system they are running on, but avoiding -all- of them is
pretty much impossible.
If you disagree, please port some bigger JS app to Links javascript
engine first.
 
L

Lasse Reichstein Nielsen

[email protected] said:
If I write a greasemonkey (Firefox extension)
script, do I really have to worry if it works correctly in MSIE and
Opera? Do I have to check for methods I -know- Firefox supports, and
know the script won't be ever executed outside Greasemonkey sandbox?
Click to expand...

Since Opera has introduced user.js-scripts that are compatible with
greasemonkey, then it would be nice if you check that it works there
too :)
<URL:http://www.opera.com/support/tutorials/userjs/examples/>

But no, if you write for a specific platform, then obviously you need
only consider the variations inside that platform.
When nothing else is stated, in this group the default assumed
platform is the web in general, where you cannot safely make any
assumptions.

You make life much easier for yourself using standards, since they
are more likely to be supported on other platforms as well, should
you ever want to extend the scope to cover another platform - and
you only need to learn how to do things one way :)

/L
 
B

bwucke

Lasse said:
You make life much easier for yourself using standards, since they
are more likely to be supported on other platforms as well, should
you ever want to extend the scope to cover another platform - and
you only need to learn how to do things one way :)
Click to expand...

Well, I do. Primarily because standards are best documented
(self-documenting) so they are easiest way to write. But then, when I
have my nice and pretty standards-compilant source, first, it doesn't
work in any real browser (except of Amaya maybe ;) and second, it lacks
a few features that aren't part of any standard but are quite handy and
widely supported. So I start breaking my nice standard-compilant code
to make it work... Pity, but that's the state of things.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Survey details won't go through using php, ajax, Mysql 0
address LINK object in the HEAD section 5
Sort by number of characters 1
JQuery add shadow error 4
Align img inside nav tabs section 5
Help with my responsive home page 2
Working on mobile css menu with plenty of frustration! 2
Uncaught ReferenceError: item is not defined at HTMLButtonElement.onclick in the: <button onclick="item.inserir()">Inserir dados</button> 1

Staff online

Members online

Total: 30 (members: 3, guests: 27)
Robots: 423

Forum statistics

Threads
473,769
Messages
2,569,577
Members
45,052
Latest member
LucyCarper

Latest Threads

Top