i was wondering what would be the best way to code a browser plugin that is for multiple browsers.
Due to the fact that each browser uses other ways of implementing plugins there should be a library or something with the basic functionality and a wrapper for each browser. So, to be more precise, with which language the library should be programmed?
The plugin shall implement functions like: Retrieving files from another server (via SSH) and sound playback.
Regards
macs
It's all about common denominators when you're doing cross-platform stuff. You need to pick the things that you know will work on all your targets. This will require some research on your part. I know this answer is a bit vague, but you don't state exactly which list of browsers you wish to support. Is it just Firefox, IE, and Safari? Opera as well? These are things you have to think about.
That said, your best bet is to pick a language that is supported by each browser you wish to target.
Related
Every now and again I get asked to install something like this on a customer web server, or we're asked if we support BrowserHawk (which we don't).
I'm wondering if Modernizr is something I can point my customers at and tell them to use instead?
I've not used Browserhawk (in fact, I'd never heard of it until now), so please don't take my opinion as infallible.
However, I do know about browsecap.ini, and having taken a few moments to read the Browserhawk website, I'm fairly certain it's also a server-side browser detection tool.
If that's the case, then the answer is 'Yes'. Current best practice says to avoid using server-side browser detection, and to use client-side feature detection instead. And this is exactly what Modernizr does.
Feature detection allows you to do much finer-grained tuning of your site according to what the user's browser is capable of, rather than simply blocking users who have (or don't have) a particular browser. It also allows you to implement specific fall-back solutions for specific features, if required.
Detecting the user's browser from the server-side is a problem because of the rapid pace of change in the browser market; you would need to be constantly updating your browser detection script to cope with new versions.
In addition, users of slightly more unusual browsers or browser shells may not be detected properly by a browser detection script, so they may have trouble with sites that use it, even though their browser should be capable of displaying the site. Also, some users may not provide the user-agent string required to correctly detect their browser; it is blocked by some proxies, firewalls, etc, and some browsers also allow it to be modified, so it can be spoofed easily if a user wants to.
But having gone to lengths to promote feature detection over browser detection, I need to point out one exception to all of this, and that's IE.
Older versions of IE have a lot of bugs. This is different to simply having missing features, because you can't actively check for bugs so easily. If you're having specific issues with IE bugs, then it is legitimate to do browser detection to avoid them. (feature detection is still valid if you're only worried about what the browser supports, rather than actual bugs)
But even in this case, a tool such as browsercap.ini or Browserhawk is unnecessary. IE helpfully supports Conditional Comments which allows you to add specific code for IE without having to go out of your way to detect it.
My question is borne out of my confusion on (still incomplete, with existing features still evolving?) HTML5 support in different browsers, all the resources available on how to implement existing features and simple practicality.
1) How do you go about implementing HTML5 only features in your web-site? Do you do some kind of browser/version check at first access and notify user that he should install some other browser (though cumbersome and uncomfortable to the user)?
2) Is there a way to check availability of HTML5 features in user's browser dynamically (version X of Chrome does not support it, next might and it should work then) and easily without some significant computing overhead and significant coding?
3) Assuming the answer to 2) is yes, what to do about changes in spec that might occur in the future? (The check would say fine, the browser does implement e.g. WebGL, but my implementation would run into errors as there would be some changes between the spec I had used during development and spec that was enhanced in the W3C process and would make my implementation incompatible)
to start using html5, make sure that the first line in your html is <!doctype html> this tells the browser that you are speaking in the language of html5
this google-hosted html5 shiv helps to ensure that the new html5 tags work in older browsers and as someone already pointed out, you can and dare I say it, should use modernizr to test the browser's CSS rendering capabilities
This is just something you need to keep abreast of yourself unfortunately ;) The way I look at it, if the spec changes in a big way, lets say they decided to remove the <article>, there will be a lot of chatter online and you are likely to read about it
I recommend that you take a look at html5-boilerplate. It's a A rock-solid default for HTML5 awesome.` It's a starter kit with template html, CSS and Javascript files for building an html5 website.
This is useful: http://www.modernizr.com/
As for 3: I think that's just a risk of using a technology before it's out of spec.
Take a look at modernizr, it's a js library that will do various feature detection tests and gives you a way to query whether or not to use a particular feature. You can also load specific js files with modernizr.load based on whether a feature is supported in the browser.
http://www.modernizr.com/
Tutorial: http://www.alistapart.com/articles/taking-advantage-of-html5-and-css3-with-modernizr/
I imagine there must be out there a website that collects information about HTML 5 feature and what browsers version started to support them.
This might be a good way to decide based on your website profile, if you can apply that HTML 5 feature without a fallback for your visitors.
Do you know such a site/resource ?
For example I want to know what browsers support the multiple upload feature for inputs and what browser version was the first.
Update
I'm not pleased with the sites suggested so I'm opening a bounty.
Suggestions so far: Html5Test, Caniuse, modernizr.com, QuirksMode
Update 2
Some people don't understand the question. I need to implement the multiple upload feature. I know from analytics what browser are they using ( I know this is not 100% correct ).
I'm willing to sacrifice some of the visitors by not offering some advance features but I need to understand how big is this procent. I'm NOT trying to DETECT in anyway the browser. It's a similar approach with other sites that dropped IE 6 support.
So please don't talk about bad practice.
Try to look at Html5Test or caniuse.
If it's server side, you can analyze user agent to find out if client's version supports HTML5. Wikipedia is your friend.
If it's client side, there's Modernizr library.
A quick search gave me this interesting result (reproduced in several blogs): http://www.findmebyip.com/litmus/
And you can may also want to take a look at this list of how to detect each feature: http://diveintohtml5.ep.io/everything.html
Here is another website, quite incomplete but verbose and "work in progress" as of March 2011, so it might be worth keeping an eye on: http://html5accessibility.com/
This one is off topic, but since I found it, I add it. CSS compatibility in IE browsers (very extensive): http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx
And here you can find info specific to the gecko engine: https://developer.mozilla.org/en/HTML/HTML5
And, of course, MDC has compatibility tables for each feature, but separated in different pages, not as a table, e.g.: https://developer.mozilla.org/en/HTML/Element/input
http://www.modernizr.com/
HTML5Test.com collects the information but they don't give detailed reports for perusal.
A good reference site for some stuff is http://www.browserscope.org/ but that doesn't go into a lot of detail with HTML5 specific support
Another source of related stuff is http://w3c-test.org/html/tests/reporting/report.htm which is creating a set of HTML testing tools that can be run.
You or someone who wanted to create this information could use these tests and then store the UA String of each browser that hit the site with the results of each test.
Then you could just find the earliest version of each browser type that a feature successfully run on.
I think this information is stored in the databases of the sites mentioned but they just don't display it which sort of sucks. Maybe try emailing them and suggesting they add these reports.
Take a look at caniuse.com, it’s exactly what you are searching for.
QuirksMode is also a great resource, and there is an entry for multiple files input.
My vote is for:
http://www.findmebyip.com/litmus
Which i found via this blog:
http://www.deepbluesky.com/blog/-/browser-support-for-css3-and-html5_72/
You should try this website. I hope this is what you were looking for.
I am learning how to program and my goal is to build a simple functional prototype...I'm at the very beginning.
I am not concerned with the visual design at this stage, other than as it relates to being able to demonstrate the functionality.
My question is: do I need to worry about ironing out cross-browser bugs in the HTML/CSS, or can I do development on a single browser? (Perhaps a better way of asking this is does the back-end programming have any effect on which browser is displaying it).
If you are at the very beginning and only want a functional prototype, do not worry about cross browser HTML/CSS. In fact forget the CSS altogether and focus on printing just standard HTML. Since the visual design will change, focus on the content, styles can always be applied and switched later.
If you need Javascript/AJAX stuff I would recommend using a library like JQuery that has already solved many cross browser problems for you.
The back-end stuff "Perl, PHP, Python, etc" shouldn't care about the browser as it is simply printing text for the browser to render as it will.
The back-end programming will affect the way a given browser displays your page and there might well be two schools of thought on whether you should be picky about the browser compatibility issues.
On the one hand, if you're just finding your feet in web development it might be asking too much to expect to have a standards-perfect, cross-browser site or application every time. It might be better to focus on actually accomplishing a finished result and learning as much syntax and technique as possible.
On the other hand, it might be argued that it's a good idea to get into the habit of adopting good practices now and recognising the sorts of things that are going to give you headaches... probably when you view your page in Internet Explorer. This takes more time to reach a finished product, but it would teach you good habits up-front.
Really it comes down to your own approach and preferences. Do you want to be detail-oriented and turn out a polished result in a longer period of time, or would you prefer to just get to the finish line and identify issues on a case-by-case basis?
Do car prototypes have a working stereo, leather upholstery, chrome rims, dice, and other random stuff which does not demonstrate the functionality of the newly-designed car?
My rule of thumb is that if it takes you more than 10 minutes to make it look acceptable to others (I'm completely fine with a disgusting design when prototyping), you're spending too much time on the aesthetics and less time on the actual clockwork.
What good does a "pretty-looking" site do if it has no functional layout?
This depends on both your audience and on your tooling. If you are trying to support all users on all browsers, then you will certainly need to do testing on those browsers (although actively developing on those browsers may not be necessary), whereas if you only need to support WebKit-based browsers (Chrome, Safari) or WebKit-based browsers and Firefox, that is less testing that you need to do.
It also depends on your tooling. For example, if you are writing directly in HTML and CSS, then you are much more likely to run into browser compatibility issues. However, if you use a tool such as GWT, which can generate browser-specific output automatically, there are fewer such issues to deal with.
Note that you can use Selenium (aka WebDriver), to automatically test your code on multiple different browsers, even if you only actively develop within a single browser environment. That way, you can know if you've broken something, but not have to constantly manually test in multiple browsers.
While browsing with Chrome, I noticed that it responds extremely fast (in comparison with IE and Firefox on my laptop) in terms of rendering pages, including JavaScript heavy sites like gmail.
This is what googlebook on Chrome has to say
tabs are hosted in process rather than thread.
compile javascript using V8 engine as opposed to interpreting.
Introduce new virtual machine to support javascript heavy apps
introduce "hidden class transitions" and apply dynamic optimization to speed up things.
Replace inefficient "Conservative garbage colllection" scheme with more precise garbage collection scheme.
Introduce their own task scheduler and memory manager to manage the browser environment.
All this sounds so familiar, and Microsoft has been doing such things for long time.. Windows os, C++, C# etc compilers, CLR, and so on.
So why isn't Microsoft or any other browser vendor taking Chrome's approach? Is there a flaw in Chrome's approach? If not, is the rest of browser vendor community caught unaware with Google's approach?
Chrome's approach is difficult to write, and requires forethought from the developers. IE and Firefox are both attempting to move to a process-per-tab model, but due to backwards compatibility are not able to transition quickly. Chrome, being an entirely new browser build on a clean rendering engine (WebKit), was easier to write in this way.
They have crossed over from a web browser as a tool to view web pages, to a tool optimized to work for web applications. There may be some flaws in this initial release, but they are changing the game.
IE8 uses a similar individual process per tab module, though they do not use a single process per tab, but instead spread all tabs across a process pool.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
Thats actually a WebKit feature, Chrome just inherited it.
Virtually all of these features existed in other browsers before Chrome. IE8 had process isolation for tabs. Firefox / Safari had most of the JavaScript stuff. Most browsers do their own memory management.
Chrome has a few unique features (hyperrestricted render processes, etc) which are difficult to put into other browsers due to add-on/application compatibility concerns.
The primary thing Chrome has going for it is an extremely hardcore focus on minimalism and high-performance. By focusing on these as their competitive advantages, they can appeal to users who find this area of focus compelling.
As time passes, I'm sure you will see the homogenization of features as the browsers attempt to one-up each other.
In the meanwhile, I still stick with Firefox over Chrome for the simple reason that Firefox is (i) non-profit and has a (ii) huge addon community.
Addons such as NoScript and AdBlockPlus are almost essential for me.
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
Yeah. I mentioned this on uservoice and got declined because the current size is evidently the default under webkit. Every other site I've tried with Chrome that uses textboxes to compose content manages to have a decent sized font. The default definitely doesn't work, but there's obviously some way to override it. Jeff needs to fix this!
Edit:
Jeff was nice enough to point out how to fix this problem yourself.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
I also wanted to point out that Google completely built Chrome from the ground up, with the exception of using webkit, so they have some of the advantages of not having to not deal with old-code. And of course there is the INSANLELY cool/smart developers.
The biggest chink I've found is its lousy proxy support compared to IE, FF and Opera. So it's pretty much useless at work, render pages at random, and requesting authentication for the proxy, where the others pass it seamlessly.
That said on my home machine it works great, if it wasn't for the OTT EULA I'd use it now.
thing2k
One "flaw" about Chrome is that it uses more memory upfront than all of the other browsers. I'm just guessing that this is due to the overhead associated with all the separate tab management.
After it's been open for some time, however, it doesn't use more memory than other browsers.
Many companies play a game of "What's the least we can do to get the leg up?" Marketing creates a laundry list of features needed to be better than the competitors. Project management ensures engineers stick to those features for fear that the project will exceed the time allocated... which of course it will. There's not a whole lot of room in such a system for a big picture leap-ahead. The incremental improvements you see in products, and browsers, is a consequence.
You have to keep in mind that Microsoft primary business is Rich environement (GUI) Application. Web tool is a threat to them as it is platform independant (not promoting they main product).
Of course the IE team probably had figured something like that but... Microsoft definetly won't invest a lot of money in IE if what they are selling is a Rich application platform.