Deprecation plan of IE8 in SimpleUploads

tl:dr
Die IE8, Die.

Planned deprecation of support for IE8 in SimpleUploads

We're already in 2016, Microsoft has stated that old versions of IE are no longer supported, and since some time ago Windows XP is not supported either.

IE8 is too bad according to any current standard, too limited and lacks too many features, it has bad security track, it's time to put it to rest and everyone of us has to work towards that goal and obviously one thing that we can do is to claim that those old versions aren't supported in our products, so people can realize that they have to change their browser to another one that has all those missing features.

So by the end of February I'll publish a new version of SimpleUploads just to remove the little parts that tried to add some kind of support for IE8.

I'll remove right now any claim in its description about support for IE8 and I'll update shortly the demo with the new version without support for any browser that lacks the FormData feature.

If you have any concern about this change, please comment here or send me an email, but remember that you can keep using your current version as long as you want if you prefer to support IE8 instead of embracing the future.

Die XP: Another benefit of Let's Encrypt

The Let's Encrypt project is a great initiative to move towards a more secure web, removing the costs to apply a secure certificate to a site and providing an automated client to take care of renewals.

This means of course huge changes across the whole the web industry:

Other CA will be forced to drop the price of their equivalent certificates to a bare minimum or make them free also, just to try to keep on some people looking at them.

Hosting providers will have to allow everyone to use a one click install of a free SSL certificate or at least manually update their certificates unless they want their clients to move to a friendlier hosting that allows setting up SSL without paying huge fees.

Website owners now will be able to avoid one of the problems (money) to install a SSL and this will be specially important for small websites. Big companies have enough resources that the cost of a certificate is nothing to them, but for a small website it's clear that every Euro counts, so most of the people didn't think at all about paying just to say that their site now can be used with https.

Hopefully this will mean the end of self-signed certificates or expired certificates, so end users will be able to understand better the difference between a secure site and a non-secure one and so after a while people will reject "old" sites that aren't using SSL, forcing those sites to install one, pushing their hosting companies to allow install of free SSL.

The government spies will have a harder time trying to track what everyone does, and no, this won't be an improvement for terrorists because they are already able to use secure communications but in Paris it has been clear that they used normal non-secure methods.

But there's one more benefit: Most of those small sites that now are installing SSL en masse are using shared hosting, so they don't have a unique IP and that means that they rely on SNI to enable https and it turns out that no version of IE under windows XP (as well as old Android 2.x phones) don't support it, so those that still keep using the old IE8 will now face a new problem because they will have constant security warnings whenever they try to visit all these new https sites.
And this is a good thing!!!

That people keep on using that old IE. I mean, it's old, old, old. Full of bugs, full of problems, a pain for all of us that try to create modern websites if you have to keep supporting it, and now those users will feel a little of that pain (although I guess that they are already suffering from all of us that have left IE8 behind and no longer test it).

Time to ditch IE 8 and move to a modern browser.
 

Vendor Css prefixes

This post tries to explain my points of view as a web developer about the Vendor prefixes issue:

Introduction

Css prefixes for experimental features are fine. They are a clear signal that something is being tested but it's not a standard, they allow browser vendors to create new features and test them without having to wait for the approval from everyone else, they allow to check how they can be used and whether they create unexpected problems or not.

So yes to keep vendor prefixes alive.

But...

The problem is when those prefixes spread all around the web and people start using them all over the place. Then the browser vendor will argue that they can't change them as people are already relying on them, other vendors have to provide their own implementation (with their prefixes) to avoid being left behind but even if they provide those same features they see that people are testing only on the native browsers of iPhones and Androids, both based on Webkit.

And this is the current situation: non-webkit browsers areclaiming that the use and abuse of -webkit is so strong that they are being forced to support in their own engines some -webkit features.

My opinion about how to deal with it

First rule should be that no browser manufacturer is allowed to ship experimental features in release versions of their browsers. Those experimental features should be restricted only to the alphas and betas, when a final version is released, it should allow only the unprefixed version if that feature has gained traction and it has been "approved" or don't ship it at all.

With "approved" I don't mean that it requires a final status, just a state where other vendors agree that it can be useful, it will be (or it's already) implemented that way by them and of course there's a spec stating how does it work.

Of course this is a big problem, you'll see them screaming and kicking around before accepting this. They prefer to keep on doing their little tricks and pushing whatever it's in their heads and releasing it to the wild to give them an advantage over the competition. But the fact is that even if this is the standarized way to create propietary features, we're back to the Netscape 3 era where each browser introduced new features without caring about the other one and then that other browser had to copy and replicate the successful features of the first one.

We know that it was bad for the developers, why is that good now?

Second step:

When a browser replicates the propietary feature of another one, it should support ASAP the feature both with their own prefix as well as the unprefixed one. If the feature is not good enough or not clearly defined to support the unprefixed version then it's obvious that it doesn't make sense to support the prefix from the other browser.

That would allow web developers to start testing the prefixed version from the first vendor and if it's clear that it's good enough they can put only the unprefixed version and all the browsers will be handled at once.

Third course of action:

Evangelism on sites that teach new CSS3 features, they shouldn't generate anything with a vendor prefix, just use the standard so it can work in all the browsers.

I don't think that most of the web developers are going to write huge amounts of css by themselves, instead they will look at some generator for backgrounds, buttons, patterns and copy whatever it's there. They might not know what's a vendor prefix, they just see that they can copy that code and it works. Given that some vendors (I'm looking at you Microsoft) make it really difficult to test the new versions of their browsers, you can't expect the developers to remember to add the -ms all around because they won't notice if it works or not; they just know that they have to keep on supporting IE8 for a number of years and that it doesn't support fancy things so they won't care too much about what's next for the few ones willing to buy a new computer.

I know that almost no one will care about my opinion, but at least I hope that someone else in the whole world agrees with me that these would be good steps.

 

 

Third version for seamless replacement of textareas

Sometime ago I wrote a script that allows to use CKEditor, and at the same time keep using older scripts existing on the page that relied on reading the textarea.value (or even writing it), without having to modify them to use the CKEditor API.

The initial version worked with Firefox and Internet Explorer 8, and shortly after I added some adjustments so that Opera was also supported.

Recently a comment in that second post stated that the script gave errors in Chrome, although it tries to detect if the API that I was using is supported, but of course, webkit guys decided to implement the API but not make it available for native properties. Their statement is that treating native properties as overridable would have a negative effect on performance, and as we all know it's much more important to have a fast browser than a browser that allows the developers to do new things; unless you're in their team then you can write a new API for whatever you need and everyone else should use this API because it will change the world, you'll no longer have to use Flash because now you have this API to overcome other problems that we didn't want to fix. Besides the bug tickets commented previously, here's another one: bug 36423

Ok, enough ranting.

As I said, I've worked to find out the problems and the funny fact about this new version is that it works in Chrome but it still fails in Safari 5.1. So you can use it in your site if can restrict the browser used by your users to IE8+, Firefox 3.5+ , Opera 10+, and Chrome 12+ (I don't really know the oldest version of Firefox, Opera and Chrome where this will work, but I wouldn't expect anyone to use old versions of those browsers)

// Modify the default methods in CKEDITOR.dom.element to use .nativeValue if it's available
CKEDITOR.dom.element.prototype.getValue = function()
{
    if (typeof(this.$.nativeValue) == "undefined")
        return this.$.value;

    return this.$.nativeValue;
}

CKEDITOR.dom.element.prototype.setValue = function( value )
{
    if (typeof(this.$.nativeValue) == "undefined")
        this.$.value = value;
    else
        this.$.nativeValue = value;

    return this;
}

// Hook each textarea with its editor
CKEDITOR.on('instanceCreated', function(e) {
 if (e.editor.element.getName()=="textarea")
 {
  var node = e.editor.element.$;

  // If the .nativeValue hasn't been set for the textarea try to do it now
  if (typeof node.nativeValue == "undefined")
  {
   // for Opera & Firefox
   if (!DefineNativeValue(node))
   {
    // IE8 & Webkit
    if (!DefineValueProperty(node))
    {
     alert("Your browser is buggy. You should upgrade to something newer")
     return;
    }
   }
  }

  node.editor = e.editor;

  // House keeping.
  e.editor.on('destroy', function(e) {
   if (node.editor)
    delete node.editor;
  });
 }
});

// This function alters the behavior of the .value property to work with CKEditor
// It also provides a new property .nativeValue that reflects the original .value
// It can be used with HTMLTextAreaElement.prototype for Firefox, but Opera needs to call it on a textarea instance
function DefineNativeValue(node)
{
 if (!node.__lookupGetter__)
  return false;

    var originalGetter = node.__lookupGetter__("value");
    var originalSetter = node.__lookupSetter__("value");
    if (originalGetter && originalSetter)
    {
        node.__defineGetter__("value", function() {
                // if there's an editor, return its value
                if (this.editor)
                    return this.editor.getData();
                // else return the native value
                return originalGetter.call(this);
                }
            );
        node.__defineSetter__("value", function(data) {
                // If there's an editor, set its value
                if (this.editor) this.editor.setData(data);
                // always set the native value
                originalSetter.call(this, data)
                }
            );

        node.__defineGetter__("nativeValue", function() {
                return originalGetter.call(this);
                }
            );
        node.__defineSetter__("nativeValue", function(data) {
                originalSetter.call(this, data)
                }
            );
        return true
    }
    return false;
}

function DefineValueProperty(node)
{
    var originalValuepropDesc = Object.getOwnPropertyDescriptor(node, "value");

 if (!originalValuepropDesc)
  return false;

 // Safari doesn't allow to overwrite the property (but Chrome does)
 if (!originalValuepropDesc.configurable)
  return false;

    Object.defineProperty(node, "nativeValue",
            {
                get: function() {
                    return ( originalValuepropDesc.get ? originalValuepropDesc.get.call(this) : originalValuepropDesc.value );
                },
                set: function(data) {
                    originalValuepropDesc.set ? originalValuepropDesc.set.call(this, data) : originalValuepropDesc.value = data;
                }
   }
        );

    Object.defineProperty(node, "value",
            {
                get: function() {
                    // if there's an editor, return its value
                    if (this.editor)
                        return this.editor.getData();
                    // else return the native value
                    return this.nativeValue;
                },
                set: function(data) {
                    // If there's an editor, set its value
                    if (this.editor) this.editor.setData(data);
                    // always set the native value
                    this.nativeValue = data;
                }
            }
        );
 return true;
}

// Detection, not really needed, but it can help troubleshoting.
if (Object.defineProperty)
{
    // IE 8 and updated webkits
 // Detect Safari
 if (document.head)
 {
  var test = Object.getOwnPropertyDescriptor(document.head, "innerHTML");
  // IE9
  if (!test)
  {
   if (!DefineValueProperty(HTMLTextAreaElement.prototype))
    alert("Unable to define property override on the prototype");
  }
  else
   if (!test.configurable)
    alert("Safari doesn't allow to overwrite native properties");
 }
}
    else if (document.__defineGetter__)
{
    // FF 3.5 and Opera 10
 // We try to get the innerHTML getter for the body, if it works then getting the value for each textarea will work
 // Detect old webkits
 if (!document.body.__lookupGetter__("innerHTML"))
  alert("Old webkits don't allow to read the originalGetter and Setter for the textarea value");
}
    else
{
    // detect IE8 in compatibility mode...
    if (document.documentMode)
        alert("The page is running in Compatibility Mode (" + document.documentMode + "). Fix that")
    else
        alert("Your version of IE is too old");
}

 

(null) requests from IE8

I've noticed since the release of the IE8 Beta 2 some strange request for non-existing pages: the requests are something like this "http://www.mydomain.com/(null)"

The only thing in common between those request is the user agent, always IE8 using the Trident 4 engine:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)

It might include other toolbars or add-ons, but that's the common part for all of them. Most are using XP, but there is also some Vista requests.

The only page that I've been able to find so far is this thread that is focused just in how to ignore those request, instead of trying to understand the reason why are generated.

I'm afraid that now that the final IE8 has been finally released the number of such bogus "(null)"  requests will increase at a very fast pace, so the only solution will be to set a rule to ignore it as just another bug in IE8 and don't get flooded with the 404 error.

Releases

I wanted to post something about several releases of different products, but I didn't have the time until now.

Let's start from oldest to the most recent.

CKFinder 1.3

This release fixes all the problems (at least for asp) known in previous versions, it's the work of several months trying to debug each and every report from the users.

Adding over that, it also includes some enhancements like ability to select the thumbnails themselves and remember the last selected folder.

ImageMap 2.1

I still need some time to update the demo page (and zip) in my server. This is update is just the job of Adam, and the parts related to the FCKeditor plugin are the ability to use Zoom and general bug-fixes and memory leaks. I'll try to really test it asap but I'm a little busy :-(

Internet Explorer 8 RC1

It seems that this release can be really tested, they have fixed lots of bug (included the two that I reported related to FCKeditor), improved performance, and I guess that we all really should test it to avoid finding two months after release that we didn't test it and it did include some regression that makes us suffer again. I don't expect any other releases shortly, just like IE7 I guess that we will have to wait a lot for something new, so this is the time for us to test it and check that it's really getting closer to the rest of the browsers. Let's hope that hopefully IE8 along the release of Windows 7 (I guess that it will be released much sooner than most of the people expects it) makes IE6 fade away.

FCKeditor 2.64

This is one of the last releases of the 2.x series of FCKeditor. It includes lots of bug fixes, I would had included even more little fixes but time is finite and it isn't possible to do everything that one would like to. This release isn't just bug fixes, it also includes support for table headers and a zero-configuration online spellchecker. If you are using any 2.6x version it's a no-brainer to update, your users will be pleased if they ever faced any of the bugs and you shouldn't have any problem to use it.

Let's remember also, that the 3.x versions are called CKEditor and you can start taking a look at it right now with the first beta that has been released, the online demo of the nightlies is available here. Almost everything is being rewritten, it isn't an easy task but the results so far are looking great.

 

Not a review of IE8beta2

Everybody will offer you a review of the new beta 2 of Internet Explorer, so I won't bother to do it as you won't read it ;-)

Instead I'll just point out that in a 5 minutes test drive I was able to make it crash constantly, so I've created a simplified testcase and filed a bug in the MS Connect.

I'm not sure about what to expect here from MS. On one hand every crasher should be taken seriously, the tab crash restoration system is very good, but anyway it's a really unexpected situation that should be handled better. I don't think that they have announced the plans for the next version, would it be a Beta3 or RC1 ?

Releasing another beta makes sense because although there have been lots of improvements in this version, it still have lots of thing to polish, opacity isn't supported, dynamic VML doesn't work, there are a bunch of crash reports. I'm not sure that many developers are going to adjust their sites at the moment in this state of things, so it won't be tested properly and there might be still some other issues that are not gonna be known. A RC should be something that can safely be renamed as the final version because all the work that it's planned has been done and there are no big issues pending, and I'm a little sceptical that they can manage to fix all the big issues without another public beta in order to test that they have been fixed and nothing new has been introduced.

For example, the editing part wasn't ready for Beta1, this new version works quite better in FCKeditor, but even using the latest nightly if you try to insert a table it's done at the start of the content, (I guess that it will fail also with other elements, but I haven't done too much research about it), and the fact is that many times the errors can't be discovered just in one session. Some parts are clear and can be tested very easily, but other times it's the interaction between some elements the one that can trigger the problem.

Another example is the wrong dimensions for the content of the dialogs, seems related to the overflow:hidden in the body of the content, but why does it affect it that way, and sometimes it's displayed properly and then it goes wrong?

Trying to apply patches in FCKeditor for a beta that might change in drastic ways for the next release doesn't make sense, what we need are nightly builds of IE8 and more detailed info about the problems that they are working on. Yes, mark as invalid any ticket in Connect regarding new features, just give as a IE8 that does work at least as well as IE7 and that aims to be as good as the rest of the browsers.