I am wondering if its a good idea (if I want consistency across a multiplatform build) to include a css reset, or perhaps a css normalize library?
My concerns are of course, application speed, load time and memory usage, and the goal is of course UI consistency across platforms...
Overview
CSS reset is a must, Cordova / Phonegap all use the phones native browser so Windows Phone this is an Internet Explorer wrapper, android it's now a Chrome wrapper (old version use their own browsers wrapper), iOS uses what ever version of safari mobile for that version of iOS all of witch have more support for HTML5 so there could be differences. this means you need to reset so you have a base that is the same for all devices / browser the same as a Desktop website. but performance entirely relies on what your doing if you just use a small basic reset it will be less but then even a big one it's would you notice it anymore then not having it.
CSS Reset
So we know browsers have slight differences in CSS Engines Default Font's and stuff so we use a reset to prevent that this is the same for Mobile browsers (thats what cordova/phonegap use) so a reset is always recommended however, even if your building a cordova/phonegap mobile application for both iOS and Android is a royal pain in the arse Android support loads of Device Sizes iOS only has a few. but these sizes can cause massive problems not to mention the DDPI you have to use as the DPI varies so much.
Performance
There is a slight performance drop, not that you would see under any messurement it unless you include a massive CSS Reset system like http://getbootstrap.com/css/ that would add a bit of a performance hit but would you notice it if its 0.5 seconds your javascript takes longer from phonegap to init(), however look at bootstrap first if there is stuff in there that you would be using it would be worth it just to save development times i'm constantly using the alerts from http://getbootstrap.com/components/. there are small ones like http://html5doctor.com/html-5-reset-stylesheet/ if thats all your wanting.
Sources
The Internet it's full of tutorials telling you to implement a reset! https://www.google.co.uk/search?q=Phonegap+use+CSS+Reset&oq=Phonegap+use+CSS+Reset&aqs=chrome..69i57j69i60l3.3494j0j7&sourceid=chrome&es_sm=0&ie=UTF-8
You want facts ok stop using Phonegap/Cordova most of what it does is implements or utilizes HTML5! HTML5 is a work in progress so should not be used! http://www.w3.org/TR/html5/
ME: 5 Years of Mobile Development including developing parts of the Windows Phone 7 Phonegap. while being a developer for one of the Platform Preview applications. so i was building parts of phonegap for WP7 before most users new that WP7 was coming out.
Absolutely. If you're developing the app for multiple platforms then it sounds like a great idea. Though I have no doubt you'll still encounter differences across platforms.
I can't see how it would affect application speed/load times/memory usage.
While developing the app for cross platforms there are lots of issue regarding the css . It will be better to reset the css . But there are still issues regarding the performance .
This article might be helpful to you http://www.informit.com/articles/article.aspx?p=1915792&seqNum=6
Yes, you should!!
I've developed cross platform apps.
and each time I've used CSS reset.
I'm not sure about the exact context of a Phonegap app as I've never actually worked on one, but generally from a performance point of view any CSS reset shouldn't have an impact at all.
However, my opinion is that more often than not you shouldn't even bother with a full-fledged CSS reset targeting a bunch of specific elements and properties - you often end up overwriting them further down the stylesheet anyway.
A simple universal selector margin/padding reset is all I use today, which I supplement with my favourite box model tweak.
* {
margin:0;
padding:0;
box-sizing:border-box;
}
Maybe 10 years ago someone would tell you that the universal selector is slow, and it could've been true then, but using it on its own has been proven to be absolutely harmless today.
The rendering/layout engines of pretty much every recent browser are so quick anyway, not to mention the fact that even low end mobile devices nowadays are equipped with multi-core CPUs.
I wouldn't even call it micro optimisation, that's how negligent the impact is.
Now if you were to use div.header * - that's much more expensive, but probably still not something to lose sleep over if you don't have a few thousand elements on the page.
Have a read and test it for yourself.
I'm trying to make a version of my website optimize to Blackberry devices, however I lack of information regarding this devices and google seems not to be helping.
Have anyone create website optimize for blackberry before? or know any kind of post or information that could help?
I don't know if media queries could help since those devices seems to open screen standard resolutions.
From Optimizing A Web Site For BlackBerry Devices:
If you thought targeting Web sites to
work with several different browsers
was difficult enough, try throwing
BlackBerry support in the mix.
Designing a Web site to work with
BlackBerry handheld devices can be
frustrating because the BlackBerry Web
browser has fewer capabilities than a
standard Web browser. This lack of
features greatly affects design
strategy because slower download
speeds and limited screen size must
now be factored in.
The first thing you should do when
optimizing a site to support
BlackBerry devices is download and
install the official BlackBerry
Device Simulator and BlackBerry
Email and MDS Services Simulator
Package. The device simulator and
simulator package emulate the
functionality of actual BlackBerry
products and allow you to access and
test a Web site in a virtual
environment.
When you first open a site in
emulation, you'll probably notice the
BlackBerry's CSS support is limited
and your site may not look so great.
Since most front-end developers are
trained to be reactive, your initial
solution maybe to attach another
stylesheet, target the handheld medium
and adjust the classes and ids in that
stylesheet accordingly. Unfortunately,
the BlackBerry disregards both screen
and handheld media style declarations.
In fact, many of the useful style
declarations that could create a
loophole for the lack of media
support—including display:none and
visiblility:hidden—won't work on a
BlackBerry. For a complete list of
supported CSS declarations, refer to
the BlackBerry Content Developer
Guide.
So what's the solution? The real trick
to optimizing a Web site for
BlackBerry devices (without any hacks
or work-arounds) is using well-formed
XHTML in conjunction with CSS and
omitting unnecessary layout elements
using the screen medium. This focus on
semantically correct XHTML to drive
your layout may not look pretty on the
BlackBerry, but it's advantageous for
several reasons. For starters, since
you're dealing with a limited amount
of screen space and relying on what
equates to dial-up connection speeds
you want to keep the majority of your
display content for the BlackBerry as
text-based. Secondly, the well-formed
code will result in better overall
search engine optimization because
you're using code standards that are
friendlier to the search engine
indexing process. Finally, the focus
on semantics will make the site
scalable and rid you of any worries
associated with the consequences of
adding text, modifying links or
changing the appearance of an element
in your stylesheet.
With full-featured browsers integrated
into the latest generation of
handhelds (Safari on the iPhone, IE in
Windows Mobile devices) aesthetics
support on mobile devices is vastly
improving. Either way, good coding
standards promote graceful degradation
and a provide a certain level of
future proofing that ensures users can
view a Web site no matter how outdated
or cutting-edge their device is.
In order to test CSS in different browsers, do I have to result to installing each browser on my development system? Isn't there a useful program where you can just load an html+css file and view how it's rendered in different modern browsers?
If you're after a professional solution, take a look at Litmus.
Nope, you have to have those browsers installed in some form, although there is software such as IE Tester which will allow you to open tabs as IE5.0 - IE8. There are also online services such as:
https://browserlab.adobe.com/index.htm
Free Service
Limited # of browsers Available
http://crossbrowsertesting.com
Paid Service
http://browsershots.org/
Free Service
Supports INSANE # of browsers
It can take a long time - I've had it take an hour to return screen shots during peak usage. Can be as fast as 2 minutes for a dozen browsers.
Which will let you view your site in multiple browsers.
If you want 3 engines in one browser check Lunascape.
Additionally for all Internet Explorer versions you have IEtester.
I want to be able to create links looking like buttons with dynamic text and graphic bakground, these buttons also have to change their apperance on mouse over/mouse down and when subpage which button corresponding to is currently opened ame as mouse down)
I want to avoid using
- java script/jquery
- server-side generated images
- flash
Ny first choice was CSS, technology called sliding-doors. Everyting was great until i tested my site on non-windows machine. And it seems that there is poblem with rendering same font of different platforms. I suspect that problem is connected with way of rendering of fonts of different systems or maybe somethuiing elese, anyway on MAC (and possibly on machines running linux) it looks like this
http://img196.imageshack.us/img196/3598/45257410.png
on windows it looks slightly different and in some way worse
http://img168.imageshack.us/img168/3590/41024479.png
If it is possible to get the same effect?
What other choices do i have?
I considered using CSS sprites, and manipulating button-link size and background position only but this including creating a wide image with all buttons in certain language with all three states.Is that way would be efficent? Is there any serious directions to not use this way of creating buttons?
Thanks in advance for any suggestions
MTH
Fonts are machine dependent. Outside of the basic ones, you cannot depend on a machine having the font you want. You need to have 3-4 roughly equivalent fonts, that you list for any given font in your css. List them most prefered to least (left to right) for your font-family. Machines will also display even some common fonts slightly differently.
Also remember that while you will often pull your site up side by side in both IE and Firefox, on Mac and Linux, your users almost never will. It doesn't need to look the same in all browsers, it just needs to look good in all browsers.
You're basically asking for rich functionality without any of the rich functionality platforms (javascript, flash, etc.)
I realize this doesn't answer your question, I'm trying to step it back a bit. Image rollover without any of the above platforms is hard, but possible. But it will probably require that you give up on the site being exactly the same in all browsers and just go for "good"
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...