André's Blog

Today, I’ve done a little browser compatibility test:

Opera version 10.63 or higher is required:
older versions don’t implement the
onHashChange event.
The site will work fine with Opera 11 Alpha too.

Firefox 3.6 or higher is required.

older versions don’t implement the
onHashChange event.
The site doesn’t work well with early 4 betas,
but with the latest beta 4.0b6 and the nightly
builds, the site will render fine.

Chrome 6.0 will render the site fine.
Chrome 7.0 will have an issue with
the image error handling code. It’s
behaviour seems like a bug to me,
since when I do a traceback, the
object still exists in the in-browser
.onerror code, but as soon at my
ImageError() function is called,
it’s suddenly undefined. And as this
code worked with Chrome 6,
and other tested browsers like
Firefox and Opera.

As announced before, Internet Explorer
is officially unsupported. That doesn’t
mean I haven’t tried

function translate_to_msie_dialect(){
  var s = document.getElementsByTagName(“script”);
  var l = s.length;
  var i;
  for ( i = 0 ; i < l ; i ++ ) {
    var src = s[i].text;
    s[i].text = src.replace(/.textContent/g, “.text”);
  }
}

This code turns standard javascript into microsoft’s dialect,
well, as for as the .text vs .textContent concerns.

This works on Internet Explorer 8. Self modifying code
seems to be allowed in the Microsoft browser. When I
try it the other way around, and try to translate a
Microsoft-dialect script to Standard JavaScript, it fails.

Oh well… now…. let me get to the problem with this
script: it only works for in-line javascript, so code
that sits inside

As I stated before,
“Internet Explorer is officially unsupported at my website”,
as this browser, made by some company named Microsoft,
does’t comply to the W3C standards, one must develop
the site twice, once for standard complaint browsers and
once for microsoft browsers (and since it differs a lot
between versions of it’s browser, maybe even more)

As I’ve noticed with the BlaatSchaap site, Internet
Explorer has improved a little, and is since version 8
capable of *rendering* the html/css correctly. WOW!

I mean…. Internet Explorer 6 and 7. When I tell it to
draw two boxes, two divs, with a border, with the same
heigth, next to each other, they will turn op with
a different heigth, and it even differs between
version 6 and 7. I’ve had these issues when I
had this separated Radio BlaatSchaap site where
Eileen insisted on Internet Explorer support. As it
was just a static site, it was not that much trouble.
But still…. seeing what Internet Explorer managed
to put on the screen…..

Well…. now…. version 8. I am surprised it seems to
support XMLHttpRequest correctly. WOW! As in
older versions it seems, one must work with
*shiver* ActiveX stuff. A nightmare!

But, as expected, the site crashed immediately.
It was reporting errors about not being able to
obtain the language strings from the server.
So, I immediately suspected the XMLHttpRequest.
But that one turned out to behave as expected,
no, the problem seems to be in the processing
of the received XML data.

var xmldoc = http.responseXML;

var xmlstrings = xmldoc.getElementsByTagName(“strings”)[0];

for(i=0; i < xmlstrings.getElementsByTagName("string").length; i++){

var xmlstring = xmlstrings.getElementsByTagName(“string”)[i];

var objstring = new Object();

alert(xmlstring.getElementsByTagName(“lang”)[0].textContent)

objstring[“lang”] = xmlstring.getElementsByTagName(“lang”)[0].textContent;

objstring[“type”] = xmlstring.getElementsByTagName(“type”)[0].textContent;

objstring[“text”] = xmlstring.getElementsByTagName(“text”)[0].textContent;

objstring[“locked”] = xmlstring.getElementsByTagName(“locked”)[0].textContent;

strings.push(objstring);

}

This script appears to work on all modern browsers
except Internet Explorer. (Internet Explorer should be
concidered a modern browser when one looks at it’s
release date.)

Hopefully it gets better next version. But I will write my
website according to the W3C standards. If some 
American company decides to invent their own ‘standards’,
then that is not my problem. My site is standards complaint,
if your browser is not, don’t blaim be. 


Oh yes, some people will say, but those n00bs don’t
know better, and will use what’s pre-installed. Well,
exactly that *is* the problem why that damn piece 
of junk is so popular. And it’s also why the EU 
government forced Microsoft so implement a browser
selection program into their Operating System,
I think it’s called ‘Windows’

Oh…. enough ranting about Microsoft now… back
to randing about Internet Exploders crappy JavaScript
implementation. So, for some reason, it doesn’t execute
the script above according to what it’s told to do.


 After debugging a bit, it seems to go wrong at the
last step.   .textContent is *NOT* supported
by Internet Explorer. After googeling a bit I found
http://www.hiteshagrawal.com/javascript/javascript-parsing-xml-in-javascript

text
Returns the text content assigned to the tag elements. This property cannot be used for reading attribute content. Also this property can only be used for Microsoft Browsers
Syntax:
xml_object.current_pointing_node.text

textContent
Returns the text content assigned to the tag elements. This property cannot be used for reading attribute content. Also this property can only be used for Mozilla, Firefox, Opera Browsers
Syntax:
xml_object.current_pointing_node.textContent

So, appearently in Microsoft JScript it’s called text and
in standard ‘rest-of-the-world’ JavaScript it’s called
textContent. Do you get my problem with Microsoft?
Do you get what I mean with non-standard-complaint?

Yes, I have been complaining about Firefox before,
but that’s still different, because, the other browsers
were supporting an extra feature, but didn’t implement
a feature completely different, and with a little tweak,
the code ran in all standards-complant browsers.

With this Microsoft Browser, I will litterly need to do a
if (microsoft) then {……text} else {…..textContent}

*and* I will need to make this change *everywhere*
where I am parsing XML data. And since I’m developing
a site that is fully AJAX driven, XML parsing in JavaScript,
this will be a pain in the ass to make it Microsoft-compatible,
and will increase the size of the scripts as well, and so
increase the load times of the site as well.

So, I stick to my statement I’ve made years ago:
Microsoft Browsers are not supported my site.

So, the audio tag, I did give them another try, I didn’t
change my html/js codes, but I’ve updated my firefox.
Chrome is still the same version.

Now, like a miracle, they decided to play music,
even though they refused to do so yesterday.

So, Opera, Firefox and Chrome are capable of
playing IceCast2 streams using the Audio tag
after all.

Yet, it’s not perfect. Chrome’s tab crashed after
an x amount of time. It did so every time I let it
play the stream. Firefox doesn’t show any crash
message, but simply stops playing after an x
amount of time. So even though they passed
the first test, it seems, Opera is still the only
browser with acceptable support for streaming
music.

Next: XMLHttpRequests, their security is rather
script. A request MUST go to the same protocol,
same domain, same port. Since the IceCast2 server
is server it’s current song xml data on a different
port then the webserver, the request will fail.

Flash has a solution to allow connections do a
different port. You need to set up a server
listening on port 843. Since this port is below 1024,
you must have root access to the server to set it up.
See the link below for more information:
http://www.adobeursurvey.com/devnet/flashplayer/articles/socket_policy_files.html

In the past, I’ve been looking, wihtout success, for a
simular feature in JavaScript. Yesterday, I’ve discovered
JavaScript requires a different approach. The server
you are requesting must set a header that tells JavaScript
it’s allowed to proceed with it’s request.
See the links below for more information:
https://developer.mozilla.org/En/HTTP_access_control
http://www.w3.org/TR/cors/

I should take a closer look at the IceCast2 configuration
if it’s possible to insert a header, or else I can modify it’s
source code to include that header. I’ve been doing
some IceCast2 source patching before since there was
a bug in it’s ShoutCast compatibility code. I think I’ve
mentioned it before in my blog. I think it was something
like it was sending one newline in stead of two.

Appearently, Blogger didn’t post the full
text I typed for some reason….

I will have to rewrite everything again.

Some additions to the audio tag story
and about cross domain scripting.

So, opera, chrome and firefox will handle the
radio stream correctly now. So, it might still
be usable after all. The caching problem might
be fixed by patching IceCast2’s http response
headers. I was thinking about patching them
anyways, as I’ve been looking into some
headers related to the XMLHttpRequest
javascript object.

As, for security reasons, cross site scripting is
not allowed. The XMLHttpRequest is very
strict about his. Must be same domain and port.
Same server different port, or a subdomain is not
allowed. I have been looking at this before,
without success. Even a redirect by HTTP
header doesn’t get around this

When using flash, one must run an application at
the server that listens on port 843.
( see http://www.adobeursurvey.com/devnet/flashplayer/articles/socket_policy_files.html )
Due it listens on a port below 1024, one must
have root access to the webserver to set this up.

I have been looking for a simular thing for
JavaScirpt without success, but I found our
JavaScript takes a totally different approach.

I’ve found out about this by looking at Chrome’s
JavaScript console. It turnes our, the receiving
HTTP server is supposed to set a certain header
to tell JavaScript it’s allowed to do a cross site
XMLHttpRequest. See:
https://developer.mozilla.org/En/Server-Side_Access_Control
http://www.w3.org/TR/cors/

I’ve been scripting all day again. Improved some
error handling for example, when I catch an error
I will first try to display it using the ‘soft’ dialog
produced by JavaScript, and only if it fails, do a fallback
to JavaScripts alert();

There is some more errror handling to be implemented.
Since I’ve used a ‘template’ to implement the XMLHttpRequests,
I currently only do a readyState=4 && status=200 check.
I should add a check for different statuses, to see if the
server is reporting some kind of error. And some more error
handling issues.

But another problem I am running into, the old site,
where all scripting happens on the server, it was no
problem determining the users preferred languages.
There values are available in the HTTP Request header
“Accept-Language”. I found a nice PHP script, that handles
it more efficient then the current script.
( http://www.thefutureoftheweb.com/blog/use-accept-language-header )
But now, I want to do it using JavaScript. I have been
googling around a bit, and with little success. It seems
the only thing I can detect is the users browser langauge.
I might use that in stead, but, the Accept-Language header
represents the settings the user had made about the
language he wants to see, and in which order. It will
most likely consist of multiple languages (for non-Americans)

I mean, I can always ‘fall-back’ to English, but I would like
the site to be displayed in the native language if supported.

So, I might do, rather inefficient, have a PHP script return
these values back to the browser for parsing. I mean, I am
doing Client-side scripting now,

or I might look at the browsers language. But imagine a
user using an icelandic browser, with configured

Accept-Langauge :  is, nb; q=0.9, nn; q=0.8, sv; q=0.7 en; q=0.6

Sp, according to this Accept-Language string, the site
should check if Icelandic content is available, if not then
Norwegian Bokmål, if not then Norwegian Nynorsk,
if not then Swedish, if not then English.

This information is not available when I just look at
the browser langauge, which means, I see Icelandic,
I know I don’t have a translation, I fall back to English,
while the user has configured he would like Norwegian
Bokmål as first alternative.

Or, even imagine a user who’s browser langauge is not
his first langauge in his Accept-Language list?

Just some thoughts… BlaatSchaap… and it’s
planned ‘reblog’ feature. Since I’ve been suspended
from Tumblr, this feature has moved up in the feature
priority list.

I am thinking about two kinds of reblogs. A regular reblog,
which will be accessible through the regular access sceme.
(public, frinds only, or specific friendlists)

Still… doing this creates the situation of having a
‘facebook’ and a ‘tumblr’ on one site. There is a
reason there is an ‘unwritten rule’ not to link your
Tumblr on Facebook. For this reason, I am thinking
about an anonymous public accessable reblog.

Well… how will it work… on FaceBook, we have
this ‘like’ feature. I am thinking about, on BlaatSchaap,
‘liking’ a photo will add it to a reblog.
See it like an album of ‘liked’ photos across the site.

Well.. what about external images, as you can
enter an url on Tumblr to add to your tumblrblog.

So, I am thinking about downloading them to the
server and keeping the original URL as source
on the server.

Even more, support for RSS feeds might be added
as well, as I’ve mentioned before… well… the idea
is to display the content of the RSS feeds you’ve
subscribed to and then you can click the photos
you wish to add to your reblog. Basically the same
as following someone on Tumblr itself.

The thing I’ll have to think about, is reblogging
between anonymous and regular reblogs, as
with a regular blog, I will just display the username,
but for an anonymous blog, I will display the blogname.
I am thinking what will happen when a user changes
the type between regular and anonymous.

BlaatSchaap ‘live’

I’ve been blogging quite a bit about my experiences
while working on it. Let’s see…. what has been done,
what is still on the todo list:

Translation tool:

• in-line translator works so far 
• add voting feature
• not ‘in-line’ translator 
• option to delete a translation by the original translator

Other features to be implemented

• Views for photo albums
• Views for video albums 
• Photo uploading
• Video uploading
• Video converting
• Friends list manager
• Access list manager
• Automated backups
• Profile editor
• Account editor
• ‘Wall’ implementation (possible ‘port’ of the oldbeta implementation)
• New photo script enforcing the new access schema 
• Forums 
• Notifications
• Messaging support 
• Sending email notifications 

Possible features to implement:

• OpenID login
• OpenID provider
• OpenSocial Application Support (container)
• Blog (Regular text blog)
• ReBlog (Tumblr style) (with possible anonymous function)
• Facebook connect login 
• Email hosting (username@blaatschaap.be)
• BlaatNET (Communication Server)
• ‘facebook-style’ chatbar
• XMPP
• IRC

Am I missing something?

Appearently my Tumblr account has been suspended.
I assume this is because of reblogging copyrighted
material, since I recently started reblogging images
with a site logo on them. In the past I used to ignore
those, and I think it would have been better if I hadn’t
changed my mind about them.
A number of the people I used to follow on Tumblr
has been suspended as well. I will continue to follow
some of the people still alive on Tumblr using
the RSS feed Tumblr offers.

Apart from that, I am planning to add Tumblr-like
functionality to BlaatSchaap ‘live’ anyways. I had
been thinking about this before, and I was planning
to add an ‘export to Tumblr’ feature. (if possible,
I haven’t looked into their API yet) I guess, no
exporting anymore ;) Importing should still be
possible through RSS feed. But this will be a
general RSS feed feature, not Tumblr specific.

So, I’ve mentioned Firefox and SVG Problems.
From the information I’ve read it should be fixed
in 4.0b7. I am running a nightly build of beta 8.
In this nightly build, you can use the img tag to
load an svg image, but it doesn’t auto resize if a
fixed size is written in the svg file. A problem I’ve
encountered before in my SVG tests.

So, what to do: Open the SVG file and look for
something that looks like

width=”500.00000px”
height=”500.00000px”

and replace it with

viewBox=”0 0 500 500″

Then firefox 4.0b8 will resize the image to the
size you’ve specified in the img tag.

Of course we don’t expect all firefox users to
run the latest beta, so, how will be to a fallback
to png?

I added a little javascript, which works for Firefox 4.0b6.
I will still have to test it for the latest regular build, but
I assume it will work too.

I am using this little JavaScript function

function SVGPNGImage(img){
    var src= img.src;
    src= src.replace(“.svg”, “.png”);
    img.onerror=undefined;
    img.src = src;
}

And the HTML will be like

In this example we assume  we have both

/images/sheep.svg
/images/sheep.png

on our server.