Developing in Web Forms I noticed that controls have different sizes and styles deppending on which borwser I launch the application. For instance, In IE the buttons and textboxes are thicker than those in Chrome.
Is there a way to make all of them look the same?
This is normal, many things on the web look different across browsers. If you are really committed to making them appear the same, use your own CSS rules to try and standardize the look, or implement 3rd party controls that attempt to account for this such as DevExpress or Telerik controls.
You should not try to make it all the same. You would confuse your users. chrome users do not expect to have thicker buttons. Most users have a favorite browser and they know its design. As long as you produce valid html and css, everything is fine.
From a User Interface design point of view when is it better to disable a control or to completely hide it. I have attached an example. In both case if the "Enable ASP.NET" checkbox is clicked the "Select. Net Version selector is enabled.
I would argue that it's almost always best to just disable. Hiding controls means you're leaving a portion of your functionality/configurability a mystery to the end-user. Unless there's a compelling reason to keep users in the dark, I wouldn't.
Your example of a checkbox that enables/disables or hides/unhides a dropdown box is a good one. If users aren't aware that checking the box allows them to select further options, they may never check it and find out, because they don't realize the option they're looking for is there.
Many of us, as developers, come from the "try everything" mindset when it comes to using a piece of software. Normal users don't think that way, and that's not a bad thing, either. It just means we have to keep in mind that not everybody will do what it takes to discover a piece of UI that's been hidden. Leaving it visible but disabled lets them see that there's something there for the having should they decide they want/need to use it, rather than leaving them either wondering if the software does something or never even considering that it might.
This really depends on the context of the example. In this case there is some value associated with disabling the control as it provides a visual affordance that enabling the ASP .Net checkbox will have a determinable outcome.
If the outcome of the checkbox is actually a whole series of non related suboptions or the parent control was a dropdownlist which determines which child elements become available then it would be better to hide / show only those elements that are appropriate to the current selection.
One other point, if you are describing "hiding" the controls as control.visible = false in code rather than display:none then remember that the output will actually not be rendered into the browser at all. This may be a concern if you are catering for disabled users with browsers requiring stricter accessibility requirements etc.
To me that depends on user knowledge. If the user knows what should follow I tend to give them as much information as possible so I would show it disabled. If the user is clueless as to what follows I hide as much as possible. Sometimes I do different things on user role and sometimes it depends on the average user of the application and their expected understanding of the underlying issues.
hth,
\ ^ / i l l
I prefer to disabled the control, so the user can see that he may have something to fill out. But it can be usefull to hide it if you are restricted on space.
It really depends on the situation
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"
simple question really (can hazard a guess but just need to make sure),
Just need a Yes/No answer as can't seem to claify anywhere.
Reason? Web pages for phones, where javascript support is "sketchy" among all mobile browsers, so doing away with anything javascript altogether and was wondering if there are any alternatives.
(Also before someone tells me off, I am of course implementing server-side validation by default, better if possible to validate stuff right away on the client as phone text entry isn't particulaly fun to go through multiple times. Also webpage is asp.net 2.0 & c# should that affect anything)
No, there is not.
I mean, obviously, the more involved answer is "Yes, of course, there are other types of client-side scripting systems (Flash/Silverlight/ActiveX/etc) that can do it", but in the context of your question (phones) then the answer is No.
I do suggest, however, that you may be surprised at what phones run JavaScript. Keep it basic, and keep it such that it fails gracefully (i.e. no harm comes to the functionality of the app with JS disabled) and you'll probably be surprised at the compatibility.
HTML itself allows for a very little bit of validation (the maxlength of the input forms, which is not much, as a validation).
Which means you need "more", to do real/useful validation on the client side...
, if you want something that works in almost every browser, that's accessible, that doesn't annoy the user, ...
As a sidenote : don't ever forget server-side validation !
(Yes, you said it in your question -- but it's never said too many times ^^ )
Yes — but only in an even more limited range of browsers than those which support (and have enabled) JS.
e.g. You could use client side VBScript.
No , there is nothing except for javascript for client side for client side validation for the time being.
But it seems that HTML5 has some interesting tags thet will help. http://dev.w3.org/html5/spec/forms.html
It is possible to validate HTML forms without JavaScript now. Have a look at How to validate HTML5 forms without JavaScript
Not really. HTML itself only allows to limit the maximum length of a text box, which is some sort of "validation" (by restriction).
But then again - very many mobile browsers DO run JavaScript, even "Opera Mini" does support basic (or not that basic?) things of JS. Mobile Opera has full JS support, IE - too.
There is a nice list of who-can-do-it on QuirksMode.org (here: http://www.quirksmode.org/m/table.html)
One thing I'd suggest looking at is the Mobile Device Browser File - you state that you're using ASP.NET 2.0, so provided that your server's up to date (i.e. it has .NET Framework 2.0 SP2 installed), you should be able to use it.
This will help your site determine which browser is viewing your site, what it supports in terms of controls, etc, and help you respond appropriately to the requests.
I.e. if you know in advance that the browser doesn't support JavaScript, you can remove the client side validation altogether and not send all the extra markup to the browser, making their experience of the site even cleaner.
Basically, no.
If your market includes browsers that support the new HTML5 input types, there's some very basic things you can do there: http://diveintohtml5.ep.io/forms.html
Beyond that though, Javascript is really the only real client-side option.
(It could also be done in VBScript, but only in Internet Explorer)
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...