I have a Firefox extension that supports Firefox 3+, and SQLite database is important for my extension. I saw on the MDN that the API might change and it`s "unfrozen", should I be worried about it?
The API is currently "unfrozen", which means it is subject to change
at any time; in fact, it has changed somewhat with each release of
Firefox since it was introduced, and will likely continue to do so for
a while.
This warning is probably outdated, it has been added to the original version of the document years ago and hasn't been updated since. Fact is, starting with Firefox 4 all APIs are unfrozen and could change. But that shouldn't really be a reason to worry. As SQLite access goes, the API seems pretty mature by now and Mozilla developers are mostly tweaking performance without introducing breaking changes. The most important change was the introduction of asynchronous API in Firefox 3.5 and the deprecation of the synchronous API. But as long as you only use asynchronous API you should be on the safe side (I cannot imagine that you really need to support the ancient Firefox 3.0 release, I guess that you actually meant Firefox 3.6).
For something so widely used I doubt it but it's easy enough to write code to work around that and keep your addon backwards compatible (at least in javascript). What I ended up doing is abstracting away methods that did change and wrapping them in my own calls that would do something like
if (methodInFF3) doFF3Method();
else doNewMethod();
or something like that. This way when things changed I only had to change the code in one place instead of many but then again the first time it happened I had to change the code everywhere. For SQLite I probably wouldn't worry too much though but that's just me, just make sure that when a new release comes out you check the docs to see if anything has been changed and you should be fine.
Related
Firefox 5 introduced auto-updating. I noticed that my installation of FF5 has already updated itself to version 6.
Does this mean that, like older versions of Chrome, Firefox 5 doesn't really need to be included in my cross-browser testing battery? Or is there a way some users may prevent it from updating that I should worry about?
Though it "auto-updates", I'm always given the choice to do so.
For instance, I often don't install the update until I know my add-ins (especially FireBug) are not flagged as being disabled with the new version. This, among other contingencies, may suggest to keep FF5 support.
Always include Firefox 5 cause there are plenty of developers and users that somehow have disabled the auto update feature for whatever reason they have.
The user can, as said by Brad, always make the choice to update or not. They could edit some registry values or just using about:config, so always include FF5, etc..
You should look at the statistics when making such decisions. At this point, only 12% of Firefox users are using Firefox 5, with 55% being on Firefox 6. For comparison: Firefox 3.6.x is still being used by 20% of the users, Firefox 4 by 5% of the users.
I think that once the old branches (especially Firefox 3.6) expire you will indeed be able to concentrate on the latest Firefox release. The current tendency is that the previous release becomes irrelevant two weeks after its successor is released. While there will always be some who turn off auto-updates, the numbers are pleasantly low.
Source of statistical data: https://addons.mozilla.org/en-US/statistics/addon/1865. Feel free to compare with other sources.
Does this mean that, like older versions of Chrome, Firefox 5 doesn't really need to be included in my cross-browser testing battery?
If you are going to support older version you should always test it with older versions.
Auto-update can be disabled on most (/ all?) platforms.
I would say for your applications sake that you use AT LEAST one previous version of the popular browsers as well as their current addition when testing. Many people take awhile to update or never update. A large portion of the business world still uses IE6 for instance.
If you are maintaining a production site, perhaps monitor your web analytics to see what percentage of your users are lingering on FF5. That'll determine how best to serve your users.
As for the topic of auto-update taking hold, there could be any number of reasons why users lag. I declined to update to FF6 on my local machine the first few times it offered to, for fear of a few beloved developer plugins breaking. Unnecessarily cautious, in this case...
Firefox has a checkbox in preferences that lets you disable updates if desired. So yes, users can turn off updates.
I’m wondering why no web browser supports the XInclude standard for XHTML.
This standard exists for almost five years, and I think it would be very useful for the web.
For example, you could XInclude the static parts of your web site, such that the browser will only need to download the part which have changed when the user is browsing the site. Moreover (but I may be wrong) this does not seem to be very difficult to support, in comparison to standards like SVG or MathML.
(sorry for this question without real answer, I will not mind if it is closed)
There is an old open bug on the Mozilla bug tracker asking for XInclude support with a patch in which some problems are discussed:
a satisfactory XInclude implementation requires XPath, XPointer, xml:id and other specs to be implemented first,
most of the time XInclude can be simulated by the document() XSLT function,
loops must be detected and this is hard to do,
it is not well understood how the DOM changes made by XInclude's documents should be encapsulated into events and propagated.
Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.
I'm having trouble finding any resource for adding ctrl-z undo capability to a Flex RichTextEditor control (a lack it apparently shares with other Flex text controls). I'm baffled that it's not in the native forms because it's such a fundamental capability, available in even standard browser text controls I believe.
Any mention of this issue on the Flex sites (there are several) conflict; one says the issue is "Closed" and the resolution is "External" (whatever that means).
Does anyone have any insight to offer? I've got an app the heavily requires extensive text editing. Flex in general works nicely, but this trivial lack is just about fatal, as anyone would imagine.
An example using the Flight Framework to easily implement undo/redo can be found here: http://www.xtyler.com/code/163
I've read elsewhere -- in fact, in the answers to one of my questions on SO -- that the issue is not going to be resolved in Flex 3. Which seems to be correct since we are in 3.2 or maybe even beyond that, and there's no undo in sight.
I was brave/stupid enough to implement an undo-redo in this component myself. At that time I was working on Windows. Now I'm on OSX and I realize just how non-cross-platform my solution is. The very statement of the problem (adding ctrl-z undo capability) is a large part of the problem (OSX has control AND this Apple key thing). Now I have to check how much work it would be to make the thing cross-platform... could be trivial.
By amazing coincidence, just today I've been thinking about NOT using the RichTextEditor but rather something external (FckEditor comes to mind) because the RTE leaves so much to be desired (hence I arrived at your question). I've worked with the RTE a ton and gotten it to do a lot of what I want, but I still wonder why they didn't "finish" this component...
Flex 3 controls do not natively support undo/redo. Here are a couple of libraries that may be of interest to you:
flexundoredo
as3undohistory
Short version: What is the cleanest and most maintainable technique for consistant presentation and AJAX function across all browsers used by both web developers and web developers' end-users?
IE 6, 7, 8
Firefox 2, 3
Safari
Google Chrome
Opera
Long version: I wrote a web app aimed at other web developers. I want my app to support the major web browsers (plus Google Chrome) in both presentation and AJAX behavior.
I began on Firefox/Firebug, then added conditional comments for a consistent styling under IE 6 and 7. Next, to my amazement, I discovered that jQuery does not behave identically in IE; so I changed my Javascript to be portable on FF and IE using conditionals and less pure jQuery.
Today, I started testing on Webkit and Google Chrome and discovered that, not only are the styles inconsistant with both FF and IE, but Javascript is not executing at all, probably due to a syntax or parse error. I expected some CSS work, but now I have more Javascript debugging to do! At this point, I want to step back and think before writing piles of special cases for all situations.
I am not looking for a silver bullet, just best practices to keep things as understandable and maintainable as possible. I prefer if this works with no server-side intelligence; however if there is a advantage to, for example, check the user-agent and then return different files to different browsers, that is fine if the total comprehensibility and maintainability of the web app is lower. Thank you all very much!
I am in a similar situation, working on a web app that is targeted at IT professionals, and required to support the same set of browsers, minus Opera.
Some general things I've learned so far:
Test often, in as many of your target browsers as you can. Make sure you have time for this in your development schedule.
Toolkits can get you part of the way to cross-browser support, but will eventually miss something on some browser. Plan some time for debugging and researching fixes for specific browsers.
If you need something that's not in a toolkit and can't find a free code snippet, invest some time to write utility functions that encapsulate the browser-dependent behavior.
Educate yourself about known browser bugs, so that you can steer your implementation around them.
A few more-specific things I've learned:
Use conditional code based on the user-agent only as a last resort, because different generations of the "same" browser may have different features. Instead, test for standards-compliant behavior first — e.g., if(node.addEventListener)..., then common non-standard functions — e.g., if(window.attachEvent)..., and then, if you must, look at the user-agent for a specific browser type & version number.
Knowing when the DOM is 'ready' for script access is different in just about every browser. A good toolkit will abstract this for you.
Event handlers are different in just about every browser. A good toolkit will abstract this for you.
Creating DOM elements, particularly form controls or elements with attributes, can be tricky with document.createElement and element.setAttribute. While not standard (and kinda yucky), using node.innerHTML with strings that contain bits of HTML seems to be more reliable across browser types. I have yet to find a toolkit that will let you use element.setAttribute to add a 'name' to a form element in IE.
CSS differences (and bugs) are just as important as JS differences.
The 'core' Javascript features (String, Date, RegExp, Array functions) seem to be pretty reliable and consistent across browsers, especially relative to the DOM/CSS/Window functions. There's some small joy in the fact that the language isn't entirely different on every platform. :-)
I haven't really run into any Chrome-specific JS bugs, but it's always one of the first browsers I test.
HTH
Chrome is actually a little different to Safari, it uses a completely different javascript implementation and problems have been reported with both prototype and jquery. I wouldn't worry about it too much for now, it's still an early beta version of the browser and such inconsistencies will probably be treated as bugs. Here's the bug report.
One "silver bullet" you may consider turning to is Google Web Toolkit (GWT).
I believe it supports all the browsers you are interested in, and gives you the ability to code your UI in a Java-compatible IDE such as Eclipse. The advantage of this is you can use IDE tools for code completion and compile-time error checking, which greatly improves development on large-scale UI projects.
If you use GWT UI components, it will hide a lot of browser-specific nastiness from having to be dealt with, but when you compile, will create a compact, deploy file for each browser platform. This way you never download any IE-specific code if you are viewing the app in Firefox. You will also have a client-side stub generated which will load the appropriate compiled bundle of JS. To sweeten the deal, these files are cacheable, so perceived performance is generally improved for returning visitors.
The landscape has evolved considerably to accommodate cross-browser development. jQuery, Prototype and other frameworks exist for cross-browser Javascript. CSS resets are good for starting on a common blank canvas for all browsers. BluePrint and 960 are both CSS frameworks to help with layouts using CSS grid layouts techniques that seems to be getting very popular these days.
As for other CSS quirks across the different browsers, there is no holy grail here and the only option is to test you website across different browsers and use this awesome resource and definitely join a mailing list to save up soem time.
If you are working on high volume production site then you can use a service like browsercam.com in the end game to ensure the site doesn't break horribly in some browser.
Lastly, don't try to make the site look the same in every browser. Your primary design should target IE/FF and you should be okay with reasonable compromises on others. Use the graded browser chart to narrow in on browser support.
As for best practices, starting using wireframes on blank paper or a service like Balsamiq mockups. I am still surprised how many developers start with an editor instead of a wireframe but then again I only switched a year back before realizing how big a time saver it is. Have clean seperation of layout (HTML), presentation (CSS) and behaviors (Javascript). There should be no styling elements in HTML, no presenation in Javascript (use .addClass('highlight') instead of .css({'background-color': 'red'});).
If you are not familiar with any of the bold terms in this post, Googling them should be fruitful for your web development career and productivity.
If you're starting from a base reset or framework and have accounted for IE and it's still all freaky, you may want to recheck the following:
Everything validates? CSS and HTML?
Any broken links to an included file (js, css, etc?). In Chrome/Safari, if your stylesheet link is busted, all of your links might end up red. (something to do with the default 404 styling I think)
Any odd requirements of your js plugins that you might be using? (does the css file have to come before the js file, like with jquery.thickbox?)
For UI, check out Ext.
It's great as a standalone library, though it can also be used with jQuery, YUI, Prototype and GWT.
Samples: http://extjs.com/deploy/dev/examples/samples.html
I've found four things helpful in developing JavaScript applications:
Feature detection
Libraries
Iterative Development using Virtualization
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
Feature Detection
Use reflection to ask if the browser supports the desired feature. If you want to know what event handling a browser supports, you can if(el.addEventHandler) for W3C compliance, if(el.attachEvent) for the IE-type, and finally fall back on el.['onSomeEvent'].
ONE BIG BUT!
Browsers sometimes lie about what features they support. I can't remember, but I ran into an issues where Firefox implemented a DOM feature, but would return false if you tested for that feature!
Libraries
Since you're already working with jQuery, I'll save the explanation. But if you're running into problems you may want to consider YUI for it's wonderful cross-browser compatibility. They even work together.
Iterative Development with Virtualization
Perhaps my best advice: Run all your test environment's at once. Get a Linux distro, Compiz Fusion and a bunch of RAM. Download a copy of either VMWare's VMWare Server or Sun's Virtual Box and install a few operating systems. Get images for Windows XP, Windows Vista and Mac OS X.
The basic idea is this: Compiz Fusion gives you 4 Desktops mapped onto a Cube. 1 of these desktops is your Linux computer, the next your Virtutual Windows XP box, the one after that Vista, the last Mac OS X. After writing some code, you alt-tab into virtual computer and check out your work. Plus it looks awesome.
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
These three sources provide most of my information for JavaScript development. The Definitive guide is perhaps the best reference book for JavaScript.
Douglas Crockford is a JavaScript guru (I hate the word) at Yahoo. Lookup his series "Douglas Crockford Theory of the DOM", "Douglas Crockford Advanced JavaScript", "Douglas Crockford Theory of the Dom", and ""Douglas Crockford The Good Parts" on Yahoo! Videos.
John Resig (as you know) wrote jQuery. His website at ejohn.org contains a wealth of JavaScript information, and if you dig around on Google you'll find he's given a number of presentations on defensive JavaScript techniques.
... Good luck!
Just so you've got one less browser to worry about, Chrome uses the same rendering engine as Safari. So if it works in Safari, it should work exactly the same in Chrome.
See this post on Matt Cutts' blog.
Google Chrome uses WebKit for rendering, which is the same rendering engine as Apple’s Safari browser, so if your site is compatible with Safari it should work great in Chrome.
Update: Looks like this is now out-dated info. Please see Vox's comment on this answer.
If your very top priority is exactly consistent presentation on all the browsers listed with no disparities, you should probably be looking at AS3 and Flex.
Personally, I use Mootools as a simple lightweight javascript framework. It is simple to use and supports all the browsers above (except Chrome, but that seems to work too as far as I can tell).
Also, to ensure consistency across the browsers, I get a feature/style/behaviour/etc. to work in one browser first (usually Firefox 3 with firebug), then immediately check to make sure it works in all the other browsers (leaving IE6 for last). If it doesn't, I inveset the time to fix it right away, because otherwise I know I won't have time later (in my experience, getting things to work cross-browser takes about 50% of my dev. time ;-) )
Validating your javascript with a "good parts" + browser on JsLint.com makes it less likely to have JavaScripts behaving differently in FF, Safari etc.
Otherwise - using standards and validating your code as well as building on existing techniques like jQuery should make your site behave the same in all browsers except IE - and there's no magic recipe for IE - it's just bugs everywhere...