JSON without AJAX
VK
A mechanics to get text stream into browser from any Web location
without reloading the current page.
1) This mechanics has to support *at the very least* IE 5.5 and higher
and Firefox 1.5 and higher: but it may be completely different from one
browser to another. It is important only to be able to build an
uniformed interface atop of it.
2) This mechanics has to exploit some core features of modern browsers
so it would not be possible to lock it without stopping the browser to
be a browser (like visited links sniffing).
Com'on guys: let's hack sh** out of them! :-)
My initial donation:
1)
<link
id = "JSON"
title="JSON"
rel="alternate appendix"
type="text/plain"
href="data.txt"
charset="iso-8859-1"
hreflang="en-US">
Not even a hack, but seems to way to get the data.txt content
2)
<link
id = "JSON"
title="JSON"
rel="alternate stylesheet"
type="text/css"
href="data.css"
charset="iso-8859-1"
hreflang="en-US">
That would be nearly ideal as style rule declaration is almost
identical to JSON object syntaxes. But unknown attributes are ignored
so:
.data {
key1:value1;
key2:value2;
key3:value3;
}
will result into empty parenthesis
.data {}
Any way to stop it?
3)
IE-only "download" behavior
Not explored plus seems too easy to "upgrade security" if Microsoft
decides to. Still decided to mention.
P.S. If you find some really breathtaking solution conformant to the
requirement 2) above you may want to try to copyright it first before
posting in a public forum. Or you may don't - but needs to be
mentioned.
RobG
> Mission statement:
>
> A mechanics to get text stream into browser from any Web location
> without reloading the current page.
>
> 1) This mechanics has to support *at the very least* IE 5.5 and higher
> and Firefox 1.5 and higher: but it may be completely different from one
> browser to another. It is important only to be able to build an
> uniformed interface atop of it.
>
> 2) This mechanics has to exploit some core features of modern browsers
> so it would not be possible to lock it without stopping the browser to
> be a browser (like visited links sniffing).
>
> Com'on guys: let's hack sh** out of them! :-)
No hack required:
<script type="text/javascript" src="json.data"></script>
You can even dynamically load the script files using DOM to add the
script elements.
[...]
>
> P.S. If you find some really breathtaking solution conformant to the
> requirement 2) above you may want to try to copyright it first before
> posting in a public forum.
No need to 'try to copyright it'. Original work is copyright the
moment it is fixed in some medium (in most jurisdictions that observe
copyright).
> Or you may don't - but needs to be
> mentioned.
No, it doesn't.
--
Rob
VK
RobG wrote:
> No hack required:
> <script type="text/javascript" src="json.data"></script>
> You can even dynamically load the script files using DOM to add the
> script elements.
That was the most obvious one, already discussed in this group.
Drawbacks:
1) Interpreter will try to parse received data right on arrival. For
serialized objects it will create unnecessary overheat plus potential
error stream.
Does
scriptObject.defer = true
help in that?
2) IE supports onreadystatechange for scriptObject.
readyState comes in traditional IE's string notation:
"uninitialized"
"loading"
"loaded"
"interactive"
"complete"
(instead of 0 -4, that was IE's partial compromise for AJAX users).
That would be easy to fix but up to date no other rivals seems to
support onreadystatechange except for XMLHttpRequest (?)
So how to get state update in a nice and reliable way?
> No need to 'try to copyright it'. Original work is copyright the
> moment it is fixed in some medium (in most jurisdictions that observe
> copyright).
Read the already discussed GIF story. At least in the USA if you post
some information in a public media and do not state any copyrights in
such publication, it is assumed that you forward it to the public
domain. Still reversable but easier to say right away "This work is
mine and I want to copyright it as soon as I can". Why make things more
difficult as they should be? ;-)
VK
> mine and I want to copyright it as soon as I can".
As you may notice * I * personally do not say it anywhere.
But I cannot act for everyone else.
bwu...@gmail.com
image? (<img src> or Image() ?)
re: copyright. By law you own copyright to anything you publish unless
you state otherwise. Thing is, you need some kind of proof you're the
original author. Anyone can publish your work and (wrongly) claim
copyright on it, and unless you can prove you created it before they
did, you can do nothing about it even if lawfully it belongs to you.
Doesn't work on patenting, ideas enter public domain and become
unpatentable when published - so nobody can copy your code verbatim
legally but they can use the same ideas.
VK
bwu...@gmail.com wrote:
> On related note, any way to access/process the data (binary) of an
> image? (<img src> or Image() ?)
>From the disk or from the web?
On Firefox and Netscape you can use undocumented but perfectly
functionning btoa() and atob() methods to convert data to base64 and
back for Web transmission.
IE doesn'r have such methods so they need to be emulated by custom
JavaScript program. Due to some buffer limitations any solution will
get dead slow or even crashes for files approx. > 100Kb
Explicit binary transmission (or reading binary files from disk) is not
allowed in IE: you're getting only the file header.
Noop :-(
> re: copyright. By law you own copyright to anything you publish unless
> you state otherwise. Thing is, you need some kind of proof you're the
> original author. Anyone can publish your work and (wrongly) claim
> copyright on it, and unless you can prove you created it before they
> did, you can do nothing about it even if lawfully it belongs to you.
> Doesn't work on patenting, ideas enter public domain and become
> unpatentable when published - so nobody can copy your code verbatim
> legally but they can use the same ideas.
Good to know to everyone, thanks.
VK
> On related note, any way to access/process the data (binary) of an
> image? (<img src> or Image() ?)
Thinking over:
What DOM objects ever had or have or will have loadable .location .src
or .href or similar property?
Off my head:
window
frame
document
iframe
link (style)
script
object (HTML) ?
image
Is it all?
bwu...@gmail.com
A
APPLET
AREA
BASE
INPUT type=image
META (sometimes contains URLs...)
everything that takes "longdesc".
Thomas 'PointedEars' Lahn
He referred to "DOM objects ever had or have or will have
_loadable_ .location .src or .href or similar property",
note the Subject.
If you would have quoted what you are referring to, you
would have known.
<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
<URL:http://www.safalra.com/special/googlegroupsreply/>
PointedEars
VK
Thomas 'PointedEars' Lahn wrote:
> bwu...@gmail.com wrote:
>
> >> Is it all?
> > A
> > APPLET
> > AREA
> > BASE
> > INPUT type=image
> > META (sometimes contains URLs...)
> > everything that takes "longdesc".
INPUT type=image
At least one hit to the piggybank. But I'm affraid by usability same as
Image - see higher in this thread.
I had no idea about "longdesc". But like META or A - just passive URI
linking.
Here is the property dump of SCRIPT object in Firefox 1.5 I'm wondering
if any of properties could be checked for presence / availability
during the script loading to emulate onreadystatechange functionality.
Not to say I cannot do it myself - but someone may have an immediate
answer or comment.
nodeName = SCRIPT
nodeValue = null
nodeType = 1
parentNode = [object HTMLHeadElement]
childNodes = [object NodeList]
firstChild = [object Text]
lastChild = [object Text]
previousSibling = [object Text]
nextSibling = null
attributes = [object NamedNodeMap]
ownerDocument = [object HTMLDocument]
insertBefore = function insertBefore() {
[native code]
}
replaceChild = function replaceChild() {
[native code]
}
removeChild = function removeChild() {
[native code]
}
appendChild = function appendChild() {
[native code]
}
hasChildNodes = function hasChildNodes() {
[native code]
}
cloneNode = function cloneNode() {
[native code]
}
normalize = function normalize() {
[native code]
}
isSupported = function isSupported() {
[native code]
}
namespaceURI = null
prefix = null
localName = SCRIPT
hasAttributes = function hasAttributes() {
[native code]
}
tagName = SCRIPT
getAttribute = function getAttribute() {
[native code]
}
setAttribute = function setAttribute() {
[native code]
}
removeAttribute = function removeAttribute() {
[native code]
}
getAttributeNode = function getAttributeNode() {
[native code]
}
setAttributeNode = function setAttributeNode() {
[native code]
}
removeAttributeNode = function removeAttributeNode() {
[native code]
}
getElementsByTagName = function getElementsByTagName() {
[native code]
}
getAttributeNS = function getAttributeNS() {
[native code]
}
setAttributeNS = function setAttributeNS() {
[native code]
}
removeAttributeNS = function removeAttributeNS() {
[native code]
}
getAttributeNodeNS = function getAttributeNodeNS() {
[native code]
}
setAttributeNodeNS = function setAttributeNodeNS() {
[native code]
}
getElementsByTagNameNS = function getElementsByTagNameNS() {
[native code]
}
hasAttribute = function hasAttribute() {
[native code]
}
hasAttributeNS = function hasAttributeNS() {
[native code]
}
id =
title =
lang =
dir =
className =
text =
function init() {
var out = document.forms[0].out;
var js = document.getElementsByTagName('SCRIPT')[0];
for (i in js) {out.value+= i+' = '+js[i]+'\n';}
}
htmlFor =
event =
charset =
defer = false
src =
type = text/javascript
ELEMENT_NODE = 1
ATTRIBUTE_NODE = 2
TEXT_NODE = 3
CDATA_SECTION_NODE = 4
ENTITY_REFERENCE_NODE = 5
ENTITY_NODE = 6
PROCESSING_INSTRUCTION_NODE = 7
COMMENT_NODE = 8
DOCUMENT_NODE = 9
DOCUMENT_TYPE_NODE = 10
DOCUMENT_FRAGMENT_NODE = 11
NOTATION_NODE = 12
offsetTop = 0
offsetLeft = 0
offsetWidth = 0
offsetHeight = 0
offsetParent = null
innerHTML =
function init() {
var out = document.forms[0].out;
var js = document.getElementsByTagName('SCRIPT')[0];
for (i in js) {out.value+= i+' = '+js[i]+'\n';}
}
scrollTop = 0
scrollLeft = 0
scrollHeight = 0
scrollWidth = 0
clientHeight = 0
clientWidth = 0
tabIndex = -1
blur = function blur() {
[native code]
}
focus = function focus() {
[native code]
}
style = [object CSSStyleDeclaration]
removeEventListener = function removeEventListener() {
[native code]
}
dispatchEvent = function dispatchEvent() {
[native code]
}
baseURI = file:///D:/JS/TMP1135277704.htm
compareDocumentPosition = function compareDocumentPosition() {
[native code]
}
textContent =
function init() {
var out = document.forms[0].out;
var js = document.getElementsByTagName('SCRIPT')[0];
for (i in js) {out.value+= i+' = '+js[i]+'\n';}
}
isSameNode = function isSameNode() {
[native code]
}
lookupPrefix = function lookupPrefix() {
[native code]
}
isDefaultNamespace = function isDefaultNamespace() {
[native code]
}
lookupNamespaceURI = function lookupNamespaceURI() {
[native code]
}
isEqualNode = function isEqualNode() {
[native code]
}
getFeature = function getFeature() {
[native code]
}
setUserData = function setUserData() {
[native code]
}
getUserData = function getUserData() {
[native code]
}
DOCUMENT_POSITION_DISCONNECTED = 1
DOCUMENT_POSITION_PRECEDING = 2
DOCUMENT_POSITION_FOLLOWING = 4
DOCUMENT_POSITION_CONTAINS = 8
DOCUMENT_POSITION_CONTAINED_BY = 16
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC = 32
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> bwu...@gmail.com wrote:
>> >> Is it all?
>> > A
>> > APPLET
>> > AREA
>> > BASE
>> > INPUT type=image
>> > META (sometimes contains URLs...)
>> > everything that takes "longdesc".
>
> INPUT type=image
> At least one hit to the piggybank.
And I missed "APPLET". Adding OBJECT.
> But I'm affraid by usability same as Image -
Full ACK
> see higher in this thread.
"Higher"? :)
> Here is the property dump of SCRIPT object in Firefox 1.5 I'm wondering
> if any of properties could be checked for presence / availability
> during the script loading to emulate onreadystatechange functionality.
> Not to say I cannot do it myself - but someone may have an immediate
> answer or comment.
It is not possible to determine if a script was loaded by inspecting the
properties of a HTMLScriptElement object. What would be possible is to
determine if a certain variable was declared and holding a value different
from `undefined'. That said, "loading scripts" after the document was
loaded is still unreliable.
PointedEars
Randy Webb
>That said, "loading scripts" after the document was loaded is still unreliable.
No more unreliable than trying to load them when the page is loading.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>> That said, "loading scripts" after the document was loaded is still
>> unreliable.
>
> No more unreliable than trying to load them when the page is loading.
Nonsense.
PointedEars
VK
Randy Webb wrote:
> Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>
>
> >That said, "loading scripts" after the document was loaded is still unreliable.
>
> No more unreliable than trying to load them when the page is loading.
>
if (scriptObject.readyState == 'complete')
in IE works just fine and reliable - at least seems so, I did not check
it under all circumstances.
It is a shame that others did not implement anything so convenient and
obvious - except for XMLHttpRequest - they must be thinking that after
such glorious achievement they can take a rest for another year or two.
:-)
The previous script properties dump was irrelevant (sorry for that) as
it was for inline script. Below the properties dump for external script
for Firefox 1.5 Win98 SE
So much of useless crap they put in it - and nothing really useful.
That's still would be the best to check the state w/o any in-script
helpers, to keep the data out of implementation.
nodeName = SCRIPT
nodeValue = null
nodeType = 1
parentNode = [object HTMLHeadElement]
childNodes = [object NodeList]
firstChild = null
lastChild = null
htmlFor =
event =
charset =
defer = false
src = file:///D:/JS/external.js
type = text/javascript
ELEMENT_NODE = 1
ATTRIBUTE_NODE = 2
TEXT_NODE = 3
CDATA_SECTION_NODE = 4
ENTITY_REFERENCE_NODE = 5
ENTITY_NODE = 6
PROCESSING_INSTRUCTION_NODE = 7
COMMENT_NODE = 8
DOCUMENT_NODE = 9
DOCUMENT_TYPE_NODE = 10
DOCUMENT_FRAGMENT_NODE = 11
NOTATION_NODE = 12
offsetTop = 0
offsetLeft = 0
offsetWidth = 0
offsetHeight = 0
offsetParent = null
innerHTML =
scrollTop = 0
scrollLeft = 0
scrollHeight = 0
scrollWidth = 0
clientHeight = 0
clientWidth = 0
tabIndex = -1
blur = function blur() {
[native code]
}
focus = function focus() {
[native code]
}
style = [object CSSStyleDeclaration]
removeEventListener = function removeEventListener() {
[native code]
}
dispatchEvent = function dispatchEvent() {
[native code]
}
baseURI = file:///D:/JS/TMP1135285699.htm
compareDocumentPosition = function compareDocumentPosition() {
[native code]
}
textContent =
Thomas 'PointedEars' Lahn
> Randy Webb wrote:
>> Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>> > That said, "loading scripts" after the document was loaded is still
>> > unreliable.
>> No more unreliable than trying to load them when the page is loading.
>
> if (scriptObject.readyState == 'complete')
> in IE works just fine and reliable - at least seems so, I did not check
> it under all circumstances.
"Reliable" means it works under _all_ circumstances.
> It is a shame that others did not implement anything so convenient and
> obvious [...]
It is not. They just did not expect that people would try to add `script'
elements in order to load and execute scripts after the document was
loaded. ISTM that it does what it does if it does is merely coincidental,
which is why I am strongly recommending against it.
> The previous script properties dump was irrelevant (sorry for that) as
> it was for inline script. Below the properties dump for external script
> for Firefox 1.5 Win98 SE
It is still irrelevant, stop posting such.
PointedEars
Randy Webb
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.
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.
Randy Webb
> VK wrote:
>>Randy Webb wrote:
>>>Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>>>>That said, "loading scripts" after the document was loaded is still
>>>>unreliable.
>>>No more unreliable than trying to load them when the page is loading.
>>if (scriptObject.readyState == 'complete')
>>in IE works just fine and reliable - at least seems so, I did not check
>>it under all circumstances.
> "Reliable" means it works under _all_ circumstances.
And loading .js files is _never_ reliable as there will be circumstances
where it won't load. Remember that, it will prove beneficial to you.
>>It is a shame that others did not implement anything so convenient and
>>obvious [...]
> It is not.
What is not? The convenience of readyState? The obviousness of
readyState? Or that it is a shame? It is a shame indeed that no other
browser gives you a method to tell when a script has loaded.
> They just did not expect that people would try to add `script'
> elements in order to load and execute scripts after the document was
> loaded.
And how do you know what the programmers at MS "expected"? Or is that
more of your holier-than-thou-but-worthless thought process?
> ISTM that it does what it does if it does is merely coincidental,
> which is why I am strongly recommending against it.
Recommending against what? Using readyState or loading .js files
dynamically?
bwu...@gmail.com
Randy Webb napisal(a):
> 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.
>
Internet is unreliable.
Jasen Betts
<link rel="shortcut icon" > (and variants)
<style> (I think ICBW)
--
Bye.
Jasen
VK
Thomas 'PointedEars' Lahn wrote:
> "Reliable" means it works under _all_ circumstances.
Then let's define exactly what "reliable" would mean in this case and
what circumstances should be expected.
(pseudo-code)
Variant 1 - hardcoded kill
[remove existing node] scriptObject
[add new node] scriptObject
[assign] scriptObject.src = newURL
Does removing the node devalidate the current script context of
scriptObject - so it would be free for garbage collection?
What moment such devalidation occurs (if it does) - immediately upon
removing the node? somewhere later?
What moment we can try to access new scriptObject? When the
text/javascript input stream is closed? When interpreter finished some
tuneup job somether after? Or even while text/javascript input stream
is still open?
If newURL doesn't exists or is not reachable: do we have any formal
signs to see the trouble?
How scriptObject.defer = true affects (if it does) on anything above?
(defer is now supported by IE, FF, Opera - not sure about Safari 2.x.
Safari 1.x and Konqueror in any shall perform form are out of the loop
as hopeless cases)
Variant 2 - soft replacement
scriptObject.src = newURL1
...
scriptObject.src = newURL2
...
etc.
Same questions but getting even more tricky.
I doubt very much that there are any written standards for it - but I
can be crossly mistaken.
If I'm write though then the answers have to be found from experiments.
The most stable (wide spread) behavior should be announced as the
standard then and submitted to W3C as standard proposal - so future
browser developers could refer to it. Will it be accepted by W3C or not
is not important - there are plenty of standards which are sitting as
proposals for years.
Erratic behaviors in particular browsers/versions should be found and
fixed by JavaScript means.
Does it have any sense?
Robert
> ...
> And unreliable is not
> relative. If two things are both unreliable, then they are equally
> unreliable.
A has a 10% chance of failing, and B has a 90% chance of failing.
A and B are equally unreliable??
VK
<1135333546.1...@z14g2000cwz.googlegroups.com>
That should be clear that this is not the question of *inventing*
standards. The posed questions are connected to the core browser
functionality, therefore each existing browser with script support
already has some standard implemented in its source code - with all
if-else branches and priority flags. Just no one throught up-to-date
necessary to share it with the public. So it needs to be done by the
public themselves.
IMHO
bwu...@gmail.com
VK napisal(a):
> Thomas 'PointedEars' Lahn wrote:
> > "Reliable" means it works under _all_ circumstances.
>
> Then let's define exactly what "reliable" would mean in this case and
> what circumstances should be expected.
>
> (pseudo-code)
>
> Variant 1 - hardcoded kill
> [remove existing node] scriptObject
> [add new node] scriptObject
> [assign] scriptObject.src = newURL
>
> Does removing the node devalidate the current script context of
> scriptObject - so it would be free for garbage collection?
> What moment such devalidation occurs (if it does) - immediately upon
> removing the node? somewhere later?
I'd say, never recycle deleted object (explicitly, at least. Just let
the browser and OS handle all recycling.). Assign an unique identifier
to each imported script, so even loading the same script twice won't
result in overwriting one instance by the other. Never reuse discarded
script object. This way you don't have to worry about it anymore. You
dump it in the garbage can and don't worry if garbagemen arrive in a
moment or tomorrow, it's not of your concern. And if never, then we
have a mild memory leak. Let's first handle script loading and fix the
leak (if any) later (say, by traversing the tree of the loaded script
and deleting each leaf separately, if we have to.)
> What moment we can try to access new scriptObject? When the
> text/javascript input stream is closed?
a bet that looks safe is what is located on the bottom of the script
gets loaded last. Just add setting a marker variable to the bottom of
the file and poll it, or even trigger an event, or just launch a
predefined 'perma-script' function by a toplevel call on the bottom of
the loaded file.
--perma-script--
function loadScript(newURL)
{
[set and export new seed/mark/identifier/whatever.]
[create node]
[assign] scriptObject.src = newURL
return;
}
// now the script is loading.
function onAfterScriptLoad()
{
//now we assume the script is loaded.
}
--loadable-script--
//...
// lots of stuff here, whatever we want loaded.
//...
loaderscript.onAfterScriptLoad();
--end-of-file--
I think a pretty secure metod of caging the loaded scripts would be
loading them into dynamically created hidden iframe subdocuments.
> When interpreter finished some
> tuneup job somether after? Or even while text/javascript input stream
> is still open?
even if it is, everything we needed is already parsed and loaded.
> If newURL doesn't exists or is not reachable: do we have any formal
> signs to see the trouble?
We never get the "I'm alive" reply from the child script. We could set
a timeout to try surviving that. Worse problem if the script is
corrupted (but since we likely have access to it as literal string, we
should be able to check some hash if we want to... and if we survive
the parser error.)
> Variant 2 - soft replacement
> Same questions but getting even more tricky.
> I doubt very much that there are any written standards for it - but I
> can be crossly mistaken.
I'm not even sure if/how legal is it.
Assume script changes its own src, then continues running. A live,
active, currently running function gets deleted/garbage-collected?
Jasen Betts
>> Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>>
>>
>> >That said, "loading scripts" after the document was loaded is still unreliable.
>>
>> No more unreliable than trying to load them when the page is loading.
>>
>
> if (scriptObject.readyState == 'complete')
> in IE works just fine and reliable - at least seems so, I did not check
> it under all circumstances.
>
> It is a shame that others did not implement anything so convenient and
> obvious - except for XMLHttpRequest - they must be thinking that after
> such glorious achievement they can take a rest for another year or two.
>:-)
onload works here. (Mozilla 1.7.8)
function ha(){alert("ha!");};
function pastejs(){
s = document.createElement("script");
s.onload=ha;
s.type = "text/javascript";
s.src = "test.js";
document.body.appendChild(s);
}
Bye.
Jasen
bwu...@gmail.com
I think Randy meant - "almost". 10% is so huge unreliablity that
between it and 90% the difference is marginal. Would you pick an
airplane that falls in 90% cases or one that falls in 10% cases - or
would you rather go by bus, facing such a choice? And what is "reliable
enough"? 1%? 0.01%? There's little sense in pondering that. Either
something is completely reliable (that is, given -all- the
prerequisites it demands, it will -never- fail), or we still use it IF
we can recover from a crash gracefully and the consequences are
acceptable (say, it may fail in 90% cases, but we can freely and
automatically retry until it succeeds... then it's perfectly reliable
for us.)
Anyway, tiny proofOfConcept code. Loads js entered in the box. Works in
FF 1.5.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html><head><title>The scriptload kitchen</title>
<script type="text/javascript">
function run(url)
{
newscr=document.createElement('script');
newscr.setAttribute("src",url)
document.body.appendChild(newscr);
}
</script>
</head><body>
<form name="inp" method="post" action="#">
<input type="text" value="http://www.kurs.horsesport.pl/inne/test.js"
name="txt">
<input type="button" value="run!"
onClick="run(document.inp.txt.value);" >
</form></body></html>
Thomas 'PointedEars' Lahn
> Anyway, tiny proofOfConcept code.
That is no proof of concept whatsoever.
> Loads js entered in the box. Works in FF 1.5.
It was not debated that it works in some browsers on certain occasions
with certain pieces of code. I have written such a function long
before but attached the necessary "caveat" section to its documentation.
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
No system identifier, triggering Quirks Mode.
> <html><head><title>The scriptload kitchen</title>
No charset declaration, rendering this invalid if not served via HTTP.
But then, the document itself is already not Valid HTML 4.0.
> <script type="text/javascript">
>
> function run(url)
> {
> newscr=document.createElement('script');
^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
Undeclared global variable; calling a (DOM) method without previous
feature-test.
> newscr.setAttribute("src",url)
Not testing the return value of the (DOM) method called previously.
No need for setAttribute(), also standardized `newscr.src = ...'
suffices in all cases.
> document.body.appendChild(newscr);
> }
If, for example, I put document.write() somewhere in that script, the
document would be overwritten since it was already loaded. If we are
talking about JSON data instead, then it /may/ work.
Again: It was not debated that it is possible to append `script' elements
after the document was loaded; what was debated was that the outcome would
always be useful, and that it is possible to determine when or whether the
data was fully loaded.
PointedEars
Robert
> Robert napisal(a):
>
>>Randy Webb wrote:
>> > ...
>>
>>>And unreliable is not
>>>relative. If two things are both unreliable, then they are equally
>>>unreliable.
>>
>>A has a 10% chance of failing, and B has a 90% chance of failing.
>>A and B are equally unreliable??
>
>
> I think Randy meant - "almost". 10% is so huge unreliablity that
> between it and 90% the difference is marginal. Would you pick an
> airplane that falls in 90% cases or one that falls in 10% cases
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
bwu...@gmail.com
Thomas 'PointedEars' Lahn wrote:
> bwu...@gmail.com wrote:
>
> > Anyway, tiny proofOfConcept code.
>
> That is no proof of concept whatsoever.
It is. Proof that in -certain- cases it's possible. Means it makes
sense to move on. If it didn't work at all, ever, further debating
would be pointless. We'd have to move on to a different approach at
least.
> > Loads js entered in the box. Works in FF 1.5.
>
> It was not debated that it works in some browsers on certain occasions
> with certain pieces of code.
I think it was. Two suggested approaches, one of them I think bound to
fail ("soft loading") and the other working at least in some cases, as
proven by example.
> I have written such a function long
> before but attached the necessary "caveat" section to its documentation.
Why didn't you post it then?!?
> No system identifier, triggering Quirks Mode.
> No charset declaration, rendering this invalid if not served via HTTP.
> But then, the document itself is already not Valid HTML 4.0.
> Undeclared global variable; calling a (DOM) method without previous
> feature-test.
> Not testing the return value of the (DOM) method called previously.
> No need for setAttribute(), also standardized `newscr.src = ...'
> suffices in all cases.
Agreed. Dirty code.
Still, it worked. Can be done, point proven, purpose of the code
achieved,how - not important.
Time to move on to cleanup of the code, testing compatiblity with other
browsers and implementing further features. Your turn? Supposedly, you
have the code already.
> If, for example, I put document.write() somewhere in that script, the
> document would be overwritten since it was already loaded. If we are
> talking about JSON data instead, then it /may/ work.
There's more than one way you can break your own scripts.
document.write() works on the HTML text level. Probably this approach
(as well as innerHTML, textContent etc) would have to be replaced by
direct DOM tree calls (appendChild, createTextNode etc.)
> Again: It was not debated that it is possible to append `script' elements
> after the document was loaded; what was debated was that the outcome would
> always be useful, and that it is possible to determine when or whether the
> data was fully loaded.
Nope. In case of static text documents it wouldn't be useful, for sure.
In case of browsers not supporting Javascript it would not be useful.
Nothing is -always- useful. All we can hope for is, it will be robust
enough to be useful enough for our intended purposes. and we can learn
the level of usefulness.
So far you keep attacking whoever does a tiniest step outside the
rules, no matter what the general direction and what outcomes of their
step. Syntax nazi, standards nazi, netiquette nazi, but you seem
extremely reluctant to provide solutions yourself. Instead, whoever
says something new, you jump in, saying "I did it a long time ago,
better. You're dumb and I'm smart".
Maybe it's time to provide some actual content?
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> bwu...@gmail.com wrote:
>> > Anyway, tiny proofOfConcept code.
>> That is no proof of concept whatsoever.
>
> It is. Proof that in -certain- cases it's possible. [...]
But that was not what was to be proven.
>> > Loads js entered in the box. Works in FF 1.5.
>>
>> It was not debated that it works in some browsers on certain occasions
>> with certain pieces of code.
>
> I think it was.
No, that was not debated. Read again.
> [...]
>> I have written such a function long
>> before but attached the necessary "caveat" section to its documentation.
>
> Why didn't you post it then?!?
Why should I post something that I cannot even recommend?
>> Again: It was not debated that it is possible to append `script' elements
>> after the document was loaded; what was debated was that the outcome
>> would always be useful, and that it is possible to determine when or
>> whether the data was fully loaded.
>
> Nope. In case of static text documents it wouldn't be useful, for sure.
> In case of browsers not supporting Javascript it would not be useful.
And in case W3C DOM Level 2 HTML would not be supported as supposed or
the unspecified behavior that `script' element's contents is passed to
the script engine after the document has finished loading was not there.
And ...
> [...]
> So far you keep attacking whoever does a tiniest step outside the
> rules, no matter what the general direction and what outcomes of their
> step. Syntax nazi, standards nazi, netiquette nazi, [...]
Godwin's Law. You lose. And *PLONK*
PointedEars
VK
Thomas 'PointedEars' Lahn wrote:
> If, for example, I put document.write() somewhere in that script, the
> document would be overwritten since it was already loaded.
This is why scriptObject.defer = true has been introduced and it's
being currently supported by all browsers I can get on hold of from my
windowed viewport. That means that the Mac world as well as the Unix
branch of evolution (Linux, Free BSD end Co.) is forcely is out of my
investigation. Volunteers are badly needed from the parallel worlds but
they seem to be indifferent to the project.
In the Windows Reality I'm locked in - the statement scriptObject.defer
= true seems to be the commonly accepted way to inform the interpreter
that the code to load will not change anyhow (or nullify) the existing
DOM structure. The acceptance of this flag among all browser versions
is still a subject of further investigation.
Michael Winter
[snip]
> In the Windows Reality I'm locked in - the statement scriptObject.defer
> = true seems to be the commonly accepted way to inform the interpreter
> that the code to load will not change anyhow (or nullify) the existing
> DOM structure.
The presence of the defer attribute doesn't mean that a script won't
modify the document tree. It is a /hint/ to the user agent that the
script can be executed at its leisure; that execution can be deferred.
The use of the defer attribute wouldn't be appropriate for a script that
calls the document.write method because the output from that call is
usually meant to be inserted just after the SCRIPT element that contains
it. If such a call were deferred, the output could possibly occur
anywhere, and that its position might even change on subsequent visits
(depending if and how a user agent chooses to defer).
> The acceptance of this flag among all browser versions is still a
> subject of further investigation.
It is, and it might not even be possible to determine that a particular
browser definitely does not defer (false negatives). A simple test could
look something like:
<script type="text/javascript">
var deferred = true;
</script>
<script type="text/javascript" defer>
deferred = false;
</script>
<script type="text/javascript">
alert('Deferred: ' + deferred);
</script>
and does indeed suggest that IE will defer execution.
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
VK
Michael Winter wrote:
> It is a /hint/ to the user agent that the
> script can be executed at its leisure; that execution can be deferred.
*Any* trustwordy links about "defer" attribute? The best I've found so
far were exactly about the point: "a script with defer set to true will
deferred".
However sufficien from a "normal" point of view it would be, are there
any "abnormal" but more multiwordy comments about it?
Thomas 'PointedEars' Lahn
> Michael Winter wrote:
>> It is a /hint/ to the user agent that the
>> script can be executed at its leisure; that execution can be deferred.
>
> *Any* trustwordy links about "defer" attribute?
Yes, the HTML 4.01 Specification. It makes deferring such scripts a
possibility, not a recommendation or even a necessity.
> The best I've found so
> far were exactly about the point: "a script with defer set to true will
> deferred".
Which most certainly is from the MSDN Library or another IE-related
resource.
PointedEars
Jasen Betts
> What is not? The convenience of readyState? The obviousness of
> readyState? Or that it is a shame? It is a shame indeed that no other
> browser gives you a method to tell when a script has loaded.
mozilla has onload.
Bye.
Jasen
VK
and the quoted vot.sep. of JSON's inventor Douglas Crockford.
IMHO security issues with cross-domain script interchange is
over-appreciated. There are much more effective ways to bypass
same-domain limitations with malicious purposes. JavaScript adds
absolutely nothing extra in the pucture.
There are not any doable ways to have *full* browsing experience
*everywhere* across the Web in *absolutely secure* environment. There
are means to set security settings by domains, but this task is
accomplished on the higher level (security zones) and JavaScript per se
doesn't interfer neither affect to that.
Michael Winter
> *Any* trustwordy links about "defer" attribute?
Trustworthy? There's nothing wrong with the W3C documentation in this
regard:
defer
When set, this boolean attribute provides a hint to the user
agent that the script is not going to generate any document
content (e.g., no "document.write" in javascript) and thus,
the user agent can continue parsing and rendering.
-- 18.2.1 The SCRIPT element, HTML 4.01 [1]
particularly when Microsoft's documentation says much the same (so no
threat to your 'reality'):
Using the attribute at design time can improve the download
performance of a page because the browser does not need to
parse and execute the script and can continue downloading and
parsing the page instead.
-- Remarks, DEFER Attribute | defer Property, MSDN [2]
It might be worth mentioning that the generating "document content"
comment above needn't apply to the DOM methods that operate at a node
level. As I wrote previously, the document.write method relies on the
positioning of the SCRIPT element that calls it, whereas the other
methods can target regions of the document tree explicitly. Their only
prerequisite is that that part of the document tree has already been parsed.
[snip]
Mike
[1] <http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1>
[2]
<http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/defer.asp>
Lasse Reichstein Nielsen
> bwu...@gmail.com wrote:
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
>
> No system identifier, triggering Quirks Mode.
Actually not. The public identifier is for HTML 4.0 Strict, which
alone is enough to trigger standards mode.
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
bwu...@gmail.com
Thomas 'PointedEars' Lahn wrote:
> bwu...@gmail.com wrote:
> > It is. Proof that in -certain- cases it's possible. [...]
>
> But that was not what was to be proven.
So what exactly was?
"Mission statement:
A mechanics to get text stream into browser from any Web location
without reloading the current page. "
An external file containing stream (with some prerequisites, js syntax)
located on arbitrary location, capable of providing mostly arbitrary
data (including, by sequencing read, text stream) to the
document/application, using method other than xmlhttprequest was loaded
during runtime of already loaded document, not triggering/requiring
reload. I think it was what the whole mess is about. If I'm wrong,
please explain WHAT is to be proven.
Also,
- For serialized objects it will create unnecessary overheat plus
potential error stream.
* overhead is a cost. If the profits outweight the cost, it's fine. If
they don't, we still can develop the method and then think how to
reduce the costs.
* will 'defer' help with that?
- What would be possible is to determine if a certain variable was
declared and holding a value different from `undefined'.
* Won't 'defer' conflict with that?
- "loading scripts" after the document was loaded is still unreliable.
* given all prerequisites (Firefox [the script was written and tested
only for it]. Network connection, correct location of the files,
configuration allowing for kaunching javascript, and all the countless
other prerequisites like a user to click the button, a computer with
non-faulty hardware etc, this script is perfectly reliable. It uses
the same methods as the browser does internally for inserting nodes
into document, no matter what kind of node and no matter what time
(loading page or clicking a button) the node is inserted, so there's no
reason why it shouldn't work. And it works. And unless I missed
something serious [a prerequisite!] it will work. Thus it is reliable.
Point proven.
Would you care to explain, how is it more unreliable than sum of
unreliablity of dynamically loading any kind of content (even images)
and statically loading scripts together with all external objects on
standard page load?
> >> > Loads js entered in the box. Works in FF 1.5.
> >> It was not debated that it works in some browsers on certain occasions
> >> with certain pieces of code.
> > I think it was.
> No, that was not debated. Read again.
Many occasions when it might not work or work not as desired were
discussed. Prove all variants are true and you've proven the whole is
true. Prove one variant is false, and whole becomes doubtful, at least
reduce the set. The code for all the cases will be somehow similar to
this code, so it's a tool. It can't be used to prove things will never
fail, but can be used to find where they do and prove they do when they
do. Okay, I didn't prove anything you find interesting, doesn't make
the code useless. Of course it is dirty. I might fix it, but you say
you have cleaner, so why won't you post instead?
> > Why didn't you post it then?!?
> Why should I post something that I cannot even recommend?
You know, the empire of 3M was buitlt on fortune earned from Post-It
notes. They are an invention based on a glue invented some 80 years
earlier. The invention was archived because the author found the glue
is hopelessly weak, can barely keep two sheets of paper together.
Therefore, his reasoning was, the invention is useless. He couldn't
recommend the glue to anyone. And then someone digging in the archives
found the formula and got the idea that two sheets of paper barely
holding and easily separable is actually useful.
Post the code and maybe others will make it into something valuable and
find workarounds for the caveats.
> > Nope. In case of static text documents it wouldn't be useful, for sure.
> > In case of browsers not supporting Javascript it would not be useful.
> And in case W3C DOM Level 2 HTML would not be supported as supposed or
> the unspecified behavior that `script' element's contents is passed to
> the script engine after the document has finished loading was not there.
> And ...
and, and. Cars crash all the time. Claiming something is unreliable is
no reason not to develop it. There's no black and white, just a long
range of shades of grey. Pick one white enough for you or go back to
the caves.
> > So far you keep attacking whoever does a tiniest step outside the
> > rules, no matter what the general direction and what outcomes of their
> > step. Syntax nazi, standards nazi, netiquette nazi, [...]
> Godwin's Law. You lose. And *PLONK*
Godwin's law means losing in groups that declare it. I read the FAQ
before posting the above, found no mention of Godwin, therefore no
plonk. You're a nazi.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> bwu...@gmail.com wrote:
>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
>> No system identifier, triggering Quirks Mode.
>
> Actually not. The public identifier is for HTML 4.0 Strict, which
> alone is enough to trigger standards mode.
Indeed. That should not happen since W3C HTML 4.0 has been
obsoleted by W3C HTML 4.01 and is not a standard anymore.
PointedEars
VK
receive any data in base64 format (w/o reloading the page).
That was not the primary aim (I was thinking more about <script>
implants) but it happened to be a side effect of ruling out different
possibilities plus reading posts in this thread. The last hint came
from Lasse Reichstein Nielsen - not from the message itself but from
the bottom signature about DHTML Death Colors:
<URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
So shall we call it JSONet Project with branches
JSONet S (expoiting external style sheet idea)
and
JSONet J (exploiting script implants)
?
Proof of concept (tested under Firefox 1.5 under Windows 98 SE)
/// HTML FILE ///
<html>
<head>
<title>JSONet</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
var sid = '';
function init() {
var roof = document.getElementsByTagName('HEAD')[0];
var JSONet = document.createElement('LINK');
sid = 'jsn' + (new Date()).getTime();
with (JSONet) {
id = sid;
title = 'JSONet S';
rel = 'alternate stylesheet';
type = 'text/css';
href = 'data.css';
}
roof.appendChild(JSONet);
roof.normalize();
setTimeout(reader,500);
}
function reader() {
var out = document.forms[0].out;
var sty = document.getElementById(sid).
sheet.cssRules[0].
style.backgroundImage;
var str = sty.split(',')[1];
var b64 = str.substring(0,str.length-1);
var mes = atob(b64);
out.value = mes;
}
</script>
</head>
<body onload="init()">
<form method="post" action="">
<textarea name="out" cols="64" rows="8"></textarea>
</form>
</body>
</html>
/// CSS Sheet called <data.css> ///
.data {
background-image:
url(data:image/png;base64,SGFwcHkgTmV3IFllYXIgMjAwNiE=);
}
/// RESULT ///
base64 string contains the message "Happy New Year 2006!" which you'll
see on the page in the textarea.
VK
IE does not have HTML 4.01 in its "registered doctypes" table. So
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> may work for
switching into strict mode but only by the "Unrecognized !DOCTYPE"
rule.
Details at:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>
(after the MSDN site redesign you may need to have IE 5.5 or higher
under Windows 98 SE or higher to be able to access the information).
Lasse Reichstein Nielsen
> IE does not have HTML 4.01 in its "registered doctypes" table. So
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> may work for
> switching into strict mode but only by the "Unrecognized !DOCTYPE"
> rule.
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. It doesn't. IE6 goes into CompatMode
on this declaration, but standards mode with a system identifier,
so it treats HTML 4.01 just as HTML 4.0.
Perhaps the table is just not complete (probably because it was
written before HTML 4.01 was finalized, although I haven't checked
the dates).
VK
useful:
"Using JSON with Yahoo! Web Services"
<http://developer.yahoo.net/common/json.html>
Thomas 'PointedEars' Lahn
> "VK" <school...@yahoo.com> writes:
>> IE does not have HTML 4.01 in its "registered doctypes" table. So
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> may work for
>> switching into strict mode but only by the "Unrecognized !DOCTYPE"
>> rule.
>
> 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.
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
VK
Thomas 'PointedEars' Lahn wrote:
> Lasse Reichstein Nielsen wrote:
>
> > "VK" <school...@yahoo.com> writes:
> >> IE does not have HTML 4.01 in its "registered doctypes" table. So
> >> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> may work for
> >> switching into strict mode but only by the "Unrecognized !DOCTYPE"
> >> rule.
> >
> > 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.
>
> 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.
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?
bwu...@gmail.com
Robert wrote:
> bwu...@gmail.com wrote:
> > I think Randy meant - "almost". 10% is so huge unreliablity that
> > between it and 90% the difference is marginal. Would you pick an
> > airplane that falls in 90% cases or one that falls in 10% cases
>
> 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
You can sometimes quit the game.
Lasse Reichstein Nielsen
> Lasse Reichstein Nielsen wrote:
>> 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.
>
> 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.
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.
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/>
... 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.
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.)
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Lasse Reichstein Nielsen wrote:
>>> 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.
>>
>> 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.
>
> I don't know where you got that idea, but it is not, and never was,
> the way the DOCTYPE switching worked.
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.
That is not what you stated, so not what I replied to.
BTW: Merry Christmas! to all who celebrate it :)
PointedEars
VK
Thomas 'PointedEars' Lahn wrote:
> BTW: Merry Christmas! to all who celebrate it :)
Damn... what was good idea.
Merry Christmas!
Lasse Reichstein Nielsen
> Lasse Reichstein Nielsen wrote:
>
>> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>>> Lasse Reichstein Nielsen wrote:
>>>> 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.
>>>
>>> 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'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:news:1135504518.1...@o13g2000cwo.googlegroups.com>
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.
>> 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.
>
> That is not what you stated, so not what I replied to.
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 :)
Indeed, merry christmas to all.
/L 'and stay jolly!'
Matt Silberstein
Webb <HikksNo...@aol.com> in <cI2dnSw9BIG...@comcast.com>
wrote:
>Thomas 'PointedHead' Lahn babbled the following incoherently in
>comp.lang.javascript:
>> Randy Webb wrote:
>>>Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>>>>That said, "loading scripts" after the document was loaded is still
>>>>unreliable.
>>>No more unreliable than trying to load them when the page is loading.
>> Nonsense.
>
>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.
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.
--
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"
VK
Matt Silberstein wrote:
> Nonsense. Something can work 99% of the time, something else 1%, they
> are not equally reliable.
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.lang.javascript/browse_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.
bwu...@gmail.com
VK wrote:
> 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)
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*.
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.
Lasse Reichstein Nielsen
> 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?
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
bwu...@gmail.com
Lasse Reichstein Nielsen wrote:
> "bwu...@gmail.com" <bwu...@gmail.com> writes:
>
> 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 :)
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.