V3: Environment and browser information

[Frederico Caldeira Knabben]

We should have an object in API that could be used to identify the current browser and special OSs, like Mac. It should be compatible with our ​Browser Compatibility Specifications.

[Frederico Caldeira Knabben]

The CKEditor prototype implements this feature under the CKEDITOR.env object, defined in the "core/env.js" file.

[Alfonso Martínez de Lizarrondo]

The detection of Gecko is based on the build date, and as we've found earlier it's not always reliable because an old version might get some patches and so it's build date is newer. We should use the rv: field unless there's some problem with it. (and the date that is being checked looks like the old Mozilla 1.4 or something like that, quite old)

In order to be forward compatible, we should remember to try to avoid using these properties as long as it's possible to detect just the bug that we want to workaround as Hallvord reminded in ​http://dev.opera.com/articles/view/a-browser-sniffing-warning-the-trouble/ . I mean: if we want to use window.foobar, then test for that feature, instead of hardcoding right now that only browser X and Y does support it, because the newer version of Z might also support it.

So we could have in the CKEditor.env object also a "features" section, that does try to detect the main issues and use those instead of the classic and generic "if (FCKBrowserInfo.IsIE)" (because then we need to have IsIE6, IsIE7, IsIE8...)

[Martin Kou]

I've changed the prototype code to check for the rv: string in Gecko.

[Frederico Caldeira Knabben]

Martin's changes look good. I've just made a small simplification to the regex with [2341].

[Frederico Caldeira Knabben]

Replying to alfonsoml:

In order to be forward compatible, we should remember to try to avoid using these properties as long as it's possible to detect just the bug that we want to workaround as Hallvord reminded in ​http://dev.opera.com/articles/view/a-browser-sniffing-warning-the-trouble/ . I mean: if we want to use window.foobar, then test for that feature, instead of hardcoding right now that only browser X and Y does support it, because the newer version of Z might also support it.

That's the way we already do it (see ​CKEDITOR.tools.globalEval for an example). But you are correct to remember to keep it in mind.

I've coded ​CKEDITOR.tools.htmlEncode by using the "failure test" (not "feature test") idea, which we can also consider. We must also consider the impact in the code size that it brings.

So we could have in the CKEditor.env object also a "features" section, that does try to detect the main issues and use those instead of the classic and generic "if (FCKBrowserInfo.IsIE)" (because then we need to have IsIE6, IsIE7, IsIE8...)

I see the feature test thing as something to be done inline, when implementing a feature. It's not clear to me how CKEDITOR.env could be involved on this. Maybe an example could help me on that.