Keep Track Of The Latest Pandora Development!


Thanks for your suggestions, dflemstr and TrashyMG!

I don't currently have much time to play with this, so for now I just expanded the <span/> tag. Maybe it's causing to the rest of page to get deleted while it searches for the "other tag" ... who knows. If it starts working, please tell me.

I'll try to apply dflemstr's other suggestions on maybe Monday or Tuesday.
 
Alec  said:
Thanks for your suggestions, dflemstr and TrashyMG!

I don't currently have much time to play with this, so for now I just expanded the <span/> tag. Maybe it's causing to the rest of page to get deleted while it searches for the "other tag" ... who knows. If it starts working, please tell me.

I'll try to apply dflemstr's other suggestions on maybe Monday or Tuesday.

Tried on IE, seems to work now. Obsessively monitoring when away from home/work/school, here I come!
 
Last edited by a moderator:
benji_stein said:
Tried on IE, seems to work now. Obsessively monitoring when away from home/work/school, here I come!

Great! :)
 
Last edited by a moderator:
I have a few questions about this though (I'm not a web developer, so sorry if these questions are stupid)

dflemstr said:
2. It's good that you try to be XHTML compliant and use "/*<[CDATA[*/...", but the way you use it right now might cause problems, because XHTML-compliant browsers will see an unmatched close-comment tag (some don't merge the "/*" text node and the CDATA node). I personally recommend that you do "//<[CDATA[\n..." instead.
From my understanding, the CDATA tag is tells the XML parser to take the contents literally, and not search for any tags until it reaches the closing "]]>" tag. So, because for the XML parser, Javascript is just data, it wouldn't care about the "/*". On the Javascript side, the js parser sees the "/*" tag and ignores everything up to the closing "*/" tag, and does not care about whether it contains CDATA or not. Isn't that how it works?

dflemstr said:
4. You don't use "getTime()" on the second Date object
So you're saying the proper way is to do:
new Date(document.getElementById('updated_date').innerHTML)).getTime()?

dflemstr said:
5. You don't use semicolons, but the open-paren before the time "select chain" should save you in this case. But still...
Should I use semicolons? I thought Javascript was like bash in that regard, where you need a semicolon only if you have two things on one line.
 
Last edited by a moderator:
Alec  said:
I have a few questions about this though (I'm not a web developer, so sorry if these questions are stupid)
np, the XML standard is a mess; I don't understand half of it myself
(</disclaimer>)
Alec  said:
From my understanding, the CDATA tag is tells the XML parser to take the contents literally, and not search for any tags until it reaches the closing "]]>" tag. So, because for the XML parser, Javascript is just data, it wouldn't care about the "/*". On the Javascript side, the js parser sees the "/*" tag and ignores everything up to the closing "*/" tag, and does not care about whether it contains CDATA or not. Isn't that how it works?
Yes excatly, but the problem here lies elsewhere.
The archetypical standards-compliant XML parser, roughly speaking, has 4 types of nodes:
  • nodes (that contain *multiple* other nodes/elements e.g. <a><b/><c>...</c>...</a>)
  • elements (that only contain data (single text nodes) e.g. <a href="hello">hello</a>)
  • text nodes (raw text e.g. hello)
  • comments (e.g. <!-- hello -->)
The names for the kinds of elements (and their number, granularity etc) vary between parsers.
Now, the problem that many old XML parsers have is that they don't merge adjacent text nodes. So, if we study this snippet for a second:
Code:
<script type="text/javascript">/*<![CDATA[*/
window.onload=function(){/*omitted*/}
//]]></script>
Strictly speaking, we can say that the "script" node contains two text nodes: one raw text node and one CDATA text node.

A standards-aware XML parser would parse this as the following tree:
  • node("script")
    • elem("@type")
      • text("text/javascript")
    • text("/**/\nwindow.onload=function(){/*omitted*/}\n//")
However, faulty XML parsers will not perform the optimization of merging the two text nodes, and will spit out this tree instead (note: two text nodes):
  • node("script")
    • elem("@type")
      • text("text/javascript")
    • text("/*")
    • text("*/\nwindow.onload=function(){/*omitted*/}\n//")
Both are sent to the ECMAScript parser. The first snippet doesn't make sense (it's just an open-comment token) and is discarded. The second snippet contains a close-comment ("*/") token without an open-comment token and is also discarded (remember: this is the kind of parser we expect to find in IE; no fault tolerance). So, no Javascript gets loaded.
Now, let's say that we use this instead:
Code:
<script type="text/javascript">//<![CDATA[
window.onload=function(){/*omitted*/}
//]]></script>
The faulty parser now reads:
  • node("script")
    • elem("@type")
      • text("text/javascript")
    • text("//")
    • text("window.onload=function(){/*omitted*/}\n//")
The first text node now contains valid ECMAScript (A complete one-liner comment) and the second text node too (→ there are no random comment tokens in the way). The code thus parses successfully.
Alec  said:
So you're saying the proper way is to do:
new Date(document.getElementById('updated_date').innerHTML)).getTime()?
Yes. As it is now, you're subtracting an object from an integer. You should subtract an integer from an integer instead.

Alec  said:
Should I use semicolons? I thought Javascript was like bash in that regard, where you need a semicolon only if you have two things on one line.
Javascript has the following parsing rules:
  • Tokenise the file by splitting it up by semicolons
  • If one statement doesn't compile, replace the first occurence of '\n' by ';' and try again.

There are a number of pitfalls with this approach, especially when some parsers become overzealous when it comes to semicolons (an error at the end of a script can trigger the insertion of semicolons at every line in the file). Examples:
  1. If you have stuff that spans over multiple lines and that has an unfortunate structure. E.g.:
    Code:
    if(true)
    {
      alert("You have found the truth!")
    }
    ...becomes:
    Code:
    if(true); //if true do nothing
    {//start new scope block
      alert("You have found the truth!"); //invoke alert function
    };//end scope block
  2. If you have long expressions that chain in an awkward way:
    Code:
    var x = 1 + 2 + 3
     + 5 - 4 - 17
     - 2
    Becomes:
    Code:
    var x = 1 + 2 + 3; //evaluate to 6 and store in x
     + 5 - 4 - 17; //evaluate to -16 and discard
     - 2; //evaluate to -2 and discard
  3. etc...
It's better to just use semicolons and be on the safe side of the standards compliance border.
 
Last edited by a moderator:
Thanks for the detailed explanation, dflemstr :)

I've made the changes you suggested.
 
Multiplex said:
Could you stalk notaz, too, please?

As I said earlier, I'm tracking only the core team involved in the production, those whose comments could answer the question "Where is my Pandora?" :)

If you would have asked me to add him during the "Wifi crisis," I would have added him, but thankfully it's over now and he no longer has any information related to the shipping. If there are some important news from him, it would surely be covered by the Pandora Press!
 
Last edited by a moderator:
atomicthumbs said:
are pandorapress links from this still 403ing
I was wondering why they were 403ing, so I came here to see if anyone else had the same issue. The link from Alec's page (which 403s) is the same URL as when we go through PandoraPress directly (which does work).
 
Last edited by a moderator:
slygamer said:
atomicthumbs said:
are pandorapress links from this still 403ing
I was wondering why they were 403ing, so I came here to see if anyone else had the same issue. The link from Alec's page (which 403s) is the same URL as when we go through PandoraPress directly (which does work).

It does for everyone. For some reason, by about a week ago, PandoraPress started sending all requests containing my site in the referrer to the 403 page. You can just press the browser "Go" button and it will then load the page normally.
 
Last edited by a moderator:
*bump* TrendMicro on my work PC is blocking this now. It won't say whether it's malicious or work has simply blocked it. But they haven't blocked any other sites I visit. Odd.
 
Hmm, that was on my secondary work PC (on site), and on my main PC back in the office it's fine. :) They're all set up the same in theory, so I don't know what the story is. Ah well, I'm happy just to have access again, on all but one PC.
 
Yeah, WOT (web-of-trust) lists the site as untrustworthy. But I figure that if it's got Gruso's seal of approval, it must be ok.
 
Can we get a link to this on Pandorapress or the Information Index? I'm using it every day, and I keep having to dig out this thread for the link.

Maybe a proper domain name that forwards? Or put the script up on Pandorapress? Or have a pandorapress url forward to it (eg. www.pandorapress.net/log)??
 
ashdjones said:
Can we get a link to this on Pandorapress or the Information Index? I'm using it every day, and I keep having to dig out this thread for the link.

Maybe a proper domain name that forwards? Or put the script up on Pandorapress? Or have a pandorapress url forward to it (eg. www.pandorapress.net/log)??

+1

It'd be nice to have an easy way to find it on computers where I don't have it bookmarked. :)
 
Last edited by a moderator:
Back
Top