I am writing an internet site.
I want that my internet site will be runnable at any browser (Chrome, IE, Safari).
For the client side. what is the best practice for writing a site, that can be runnable at any browser? (or probably, most of them)
What I do generaly:
Use the http://validator.w3.org/ for validating html or css.
Use the http://www.jslint.com/ for validating javascript.
Questions:
There are some headers on css, that related to broswer support -
what shall I put on css.
Should I avoid using, i.e 1px, and instead use : 1em (or relevant ratio) on my css file.
How far can I go for support (i.e IE 5 is old enough, that doesn't worth the time I may spend to support that browser? (I need
to know how much it is used arround the world).
I need some guidelines for best practice, and that my site can be runnable at most browsers.
Any suggest will be appreciated.
Thanks :)
Let me cover your questions one by one:
There are some headers on css, that related to broswer support - what shall I put on css.
You should definitely be using a CSS "reset". There are a number of these available, but the basic idea is to get rid of the differences between the default behaviours of various browsers. See this question for more on which one to use.
Should I avoid using, i.e 1px, and instead use : 1em (or relevant ratio) on my css file.
px and em both have their place. They're both good to use. em is better in some cases for making your site scalable, but there are plenty of good reasons to use px, and it's also perfectly valid to use them both in the same site. My advice: use whatever works best for you in any given situation.
How far can I go for support (i.e IE 5 is old enough, that doesn't worth the time I may spend to support that browser? (I need to know how much it is used arround the world).
You're right, IE5 is long forgotten. Most people I know have also now dropped support for IE6 and IE7. Both of them are down to virtually zero usage in most countries. If you have a specific need to support them, you will know about it already; if not, drop them. They are both missing some important features, and dropping them will make your life a lot easier as a developer.
For Safari, you'll need to support a few versions, as people with Macs often don't upgrade their OS and may be stuck on a lower Safari version.
For Chrome and Opera, you only need to support the current version.
For Firefox, you need to support back to FF17 (the current extended support version).
You should also consider mobiles. You need to make your own decisions about this; there's a lot of mobile devices out there, and a wide range of browsers and versions.
I need some guidelines for best practice, and that my site can be runnable at most browsers.
Use sites like http://CanIUse.com to check browser compatibility for any specific features you want to use. If you need to use a feature that isn't supported in some browsers, you may still be able to use it by making use of a polyfill script. But don't use too many.
Related
I've done some searching around and I can't seem to find any command line utilities out there that will allow me to evaluate accessibility on web pages.
Essentially I want to automate the process of wget'ing a large number of websites and evaluating their accessibility.
So I would have a cron job that would get all of the necessary pages and then run the evaluation software on them. The output would then be parsed into a website ranking accessibility.
Does anyone know of anything that may work for this purpose?
Thanks!
If only accessibility evaluation were that simple... Unfortunately, what you're looking for isn't reasonably possible.
The main issue is that it's not possible to evaluate for accessibility by programatic/automated means alone. There's certainly some things you can check for and flag, but it's rare that you can say that they are either in error or correct with 100% accuracy.
As an example, take the issue of determining whether an IMG has suitable ALT text. It's impossible for a tool to determine whether the ALT text is actually meaningful in the overall context of the page: you need someone to look at the page to make that determination. But a tool can help somewhat: it can flag IMGs that don't have ALT attributes; or perhaps even flag those that have ALT attributes that look like filenames instead of descriptive text (a common error). But if there is already ALT text, it can't say for sure whether the ALT is correct and meaningful or not.
Similar with determining whether a page is using semantic markup correctly. If a tool sees that a page is not using any H1 or similar headers and only using styles for formatting, that's a potential red flag. But if there are H1's and other present, it can't determine whether they are in the right meaningful order.
And those are just two of the many issues that pertain to web page accessibility!
The issue gets even more complicated with pages that use AJAX and Javascript: it may be impossible to determine via code whether a keyboard user can accesses everything they need to on a page, or whether a screenreader user will understand the controls that are used. At the end of the day, while automated tools can help somewhat, the only way to really verify accessibility in these cases is by actual testing: by attempting to use the site with a keyboard and also with a screenreader.
You could perhaps use some of the existing accessibility tools to generate a list of potential issues on a page, but this would make for a very poor rating system: these lists of potential issues can be full of false positives and false negatives, and are really only useful as a starting point for manual investigation - using them as a rating system would likely be a bad idea.
--
For what it's worth, there are some tools out there that may be useful starting points. There is an Accessibility Evaluation Toolbar Add-On for Firefox, but it doesn't actually do any evaluation itself; rather it pulls information from the web page to make it easier for a human to evaluate it.
There's also the Web Accessibility Evaluation Tool (WAVE); again, it focuses on making accessibility-relevant information in the page more visible so that the tool user can more easily perform the evaluation.
Also worth checking out is Cynthia Says, which does more of what could be called 'evaluation' in that it generates a report from a web page - but again its only useful as a starting point for manual investigation. For example, if an IMG tag has empty ALT text - which is recommended practice if the image is purely cosmetic or is a spacer - then the generated report states "contains the 'alt' attribute with an empty value. Please verify that this image is only used for spacing or design and has no meaning." - so it's flagging potential errors, but could flag things that are not errors, or possibly miss some things that are errors.
For other information on Web Accessibility in general, I can recommend the WebAIM (Accessibility In Mind) site as a good starting point for everything Web Accessibility related.
+1 to #BrendanMcK answer ... and for the part that can (and should (*)) be automated, I know of Tanaguru and Opquast.
Tanaguru is both a SaaS and free software. Based on checklist Accessiweb 2.1 (that follows closely WCAG 2.0), it can audit pages or thousands of them. You can try it for free here: http://my.tanaguru.com/home/contract.html?cr=17 > Pages audit
I never installed it on a server, there's a mailing list if you've difficulties installing this huge Java thing
Opquast is a service that you can try for free for a one page audit but otherwise isn't free.
It'll let you audit your site with quality checklist (the Opquast one), a brand new "Accessibility first step" (aimed to problems so obvious that they should be corrected before contacting an accessibility expert) and also accessibility checklist Accessiweb and RGAA (both are based on WCAG 2.0 but I don't think that RGAA has been translated from french to english).
EDIT 2014: Tenon.io is a fairly new API by K. Groves that is very promising
(*) because it's tedious work like checking if images, area and input[type="image"] lack alt attribute ... That is work better done by computers than by people. What computers can't do is evaluating if alt, when present, are poorly written or are OK.
I'm a Linux user, and I have been very hesitant to use Glade to design GUIs, since the xml files it produces can easily be modified. I know it doesn't sound like a major issue, but what if it's a commercial app that you just don't want people changing?
I use Mac OS X every once in a while, and I figured out that they use files called ".nib"s for GUIs. I think they're essentially the same type used in Nextstep and Openstep (there's even a Linux app which lets you edit these files). Anyway, these files are included in the application bundle, and according to some people, are completely editable. This person claims he even successfully edited Keynote's interface.
Now, why would that be possible? Is it completely okay for the end user to change the interface? Or is it better to have the GUI directly in the compiled application code, like traditional GTK apps?
OS X nib files are one option; the other option is to do things programmatically. For android, XML files can define the GUI or program code can do it. In Windows WPF, the UI is made in XML. Firefox/Mozilla? XUL, another XML-based UI language.
Most modern GUI toolkits have either both of these options or even just defining UIs in files.
But even binaries are modifiable. With a good binary reverse engineering tool, it's wide open. The only way to be really certain is to do what Apple did with iOS, and run signed code; the entire bundle is signed by a key and can't be run if modified.
This isn't a problem for most everyone. Why do you care if the UI is modified? The underlying code isn't, so functionality can't be added or modified.
As a corollary (and a little off-topic) something that you might have a valid concern about is stuff a little more like this.
I don't really see a problem with it. If a user messes up his UI, then it's his problem. Think of it like moddable games. Users always loved them, and in the end, most games benefit from it. There is usually nothing secret about an application's user interface. If there is, you could always do some sort of encryption.
As others have said, you can also add checksums if you just want to disallow editing.
The xml specifies little more than what the interface looks like. Without the compiled-in event handling code, it's pretty much useless. My opinion is customers change it at their own risk, and you might actually get some free useful improvements out of their hacks.
If you're really paranoid about people changing it, you could always add an MD5 digest verification step or something when you load the xml, or compile the xml string into a header file, but that defeats many of the benefits.
The theming engine can make substantial-looking changes to your GUI, as can tools like Parasite. Updating the Glade layout — at their own risk — is much safer than either of those.
What's wrong with users customizing the UI anyway?
I have an email account whose sole purpose it is to store interesting and useful links to programming articles, code, and blog posts. It has become a little knowledgebase of sorts. I can even do a search on it, which is pretty cool.
However, after using this account for a couple of years, I now have 775 links, and it has become this big blob of amorphous information, most of which I have never looked at again. I take comfort in the fact that, if I really needed to, I could find something in there again, if I even remember putting it in there in the first place. But it has developed a "smell," if you will.
How are you organizing your programming library of cool stuff? Do you have a system or tool, and is it better than the way I'm doing it?
I would use something that is made for storing bookmarks. I use delicious.com for all of my bookmarks. The tagging system works perfectly for technology sites because you can tag each page with a specific language or tech abbreviation. This coupled with the Delicious Bookmarks plugin will make it very easy to tag sites and get back to them.
Use one word or abbreviations for languages: java c# vb.net python
Use acronyms for technologies: wpf wcf
I used to use the standard bookmark system in the browser but since I bounce around through various machines and browsers throughout the day I started to use bookmark synchronizers. Both Foxmarks and the one that google came out with. But neither I was completely satisfied with. Plus delicious has a great web interface to it as a decent api to extend for your own purpose.
IMHO, using Evernote to store this information is great.
1) you can go back and search through it easily
2) organize by tags and "notebooks collections"
3) available on multiple platforms (even mobile)
4) available as browser plugins (for direct archiving in-browser)
The only drawback is it's copy-paste functionality is a little lacking (it sometimes doesn't import/display the CSS styles correctly).
Otherwise, it's a great alternative to store web "bookmarks" (and also archive the content at the same time).
When a new specification comes out (like HTML 5) it can be tempting to begin using its enhancements; however, how do you deal with the fact that not all browsers will be up to snuff with the latest and greatest specs? Surely, it's no fun having to code the same thing twice. While we can take advantage of things that degrade gracefully, isn't it just easier to use what's available to all of today's common browsers? What's your practice (or waiting period) for adopting new specs?
In the case of HTML5, I will probably no adopt it for any "core" functionnaly of a website before the required functionnalities are supported by the webbrowers used by something like 90% of my users -- which means, unfortunatly, not that soon for any "general" site :-(
Maybe when something like 80% of my users support the most imteresting parts, I'll start using those, and degrade gracefully for the others, though...
But you're not always the one deciding : your clients are often the ones who choose... And if they're stuck with IE6 because of company-policy and the like... and yes, there are too many users stuck on IE6, without the ability to upgrade / use anything else.
For instance, take the new <video> tag : how will you convince your clients that you should use it in their website, when they already have some embeded flash stuff that works just fine for more users than the ones who would be able to read the <video> tag ?
HTML5 is a special beast. A lot of times it simply specifies the common behaviour as implemented by the browsers, which means there are parts you are free to use just now. If you for example use the simple doctype or encoding declaration, you should be fairly safe as far as browsers go. Some other parts add behaviour that does not really need to be supported by the browser much, for example the custom data attributes. Yet some other parts of the specification can be easily implemented by javascript if the browser does not support them. In this sense you can adopt the advanced form handling, dropping the javascript solution once all the supported browsers implement it natively. So there’s definitely not a single answer that would help you, and more so in the case of HTML5.
Also see many of the questions under the html5 tag here on SO.
I won't use HTML 5 (which i really want to) until firefox and IE support it. Since most of my development is corporate internal, all that matters to me is IE. But externally, chrome (which is furthest along here) has the least amount of market share. If both firefox and IE support it, I am good.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've often read that corporations will save millions once Internet Explorer 6 is finally laid to rest, but reading quotes like that make me wonder just how much time people are spending on IE6 development. I'll be happy once IE6 goes, but I've found that if I write valid HTML and CSS, use a JavaScript framework, keep the transparent images issue in mind, and don't try to over-complicate my design, I only need to write a few lines of IE6-specific CSS, which usually takes about 10-15 minutes. So I'm curious, how much time, effort, and money do you or your corporation spend on preparing your sites for IE6? Also, at what point will you drop IE6 support? If you've already dropped support, what has been your experience in terms of saved time and money and what has the switch done to your conversion rates and customer satisfaction?
According to some - browser - statistics, IE6 market share is still bigger than Chrome, Safari and Opera together, nearly as much as IE7.
Unless you target a very specific market (indeed check your stats to know for sure), neglecting to make your site looking at least decent with IE6 seems a bit foolish today...
I won't take the road to tell visitors what browser to use, for sure!
I'm already phasing it out. Every second spent on debugging for an outdated (7+ years old!!) browser is a second wasted in my books. What I've started doing is when an IE6 user first comes to the site (determined by cookies and some dodgy browser sniffing), I pop up an alert informing them that they are using an old browser which does not support much of the functionality required by many of today's web sites. I inform them that their experience might be slightly downgraded by continuing, but that can be easily alleviated by upgrading to a modern web browser (even if it sucks).
Don't go out of your way to make it crappy for them (though they might deserve it), but don't go out of your way (with non-standard CSS hacks etc) for these users either. There's only one way they'll learn.
I don't like it but I still support it. For small sites it isn't a problem, just make stuff work in Firefox first, then IE7, and IE6 last. I've used IE6-only css a number of times, and those only had a few rules in them.
For a larger project with complex layouts, I have wasted a lot of time on IE6. I'd be very happy to drop it entirely if it was impossible to provide one of my major features on it. So far, it's close enough that I'm still supporting it.
According to what I read online, about 1/4 people still use it, so it's probably not wise to drop support.
http://www.w3schools.com/browsers/browsers_stats.asp
Use your own judgement, based on your application and what you think you can expect from your users. I do not believe that a typical web user will upgrade/switch their browser just for one site. I think those people who have not upgraded from IE6 by now will never be motivated to do so. The number of IE6 users is dropping, but I think we'll be waiting for them to replace their computers rather than upgrade their browsers.
At my job all of our projects are for large corporations that aren't willing to drop support for a browser with such a large market share. Also, the designs we have are dictated to us by a third party design company so, even conforming to standards, there are still issues with complex designs in IE 6.
I would say for any given page about 5%-50% of the CSS development time is devoted to IE 6, depending on who the developer is and how complex the design is. The more experienced the developer and the simpler the design the better your odds are at hitting that 5% mark :) But even myself, with a good amount of IE 6 web-dev experience, have spent 3 hours on CSS for a page only to spend another 3 hours ironing out small quirks in IE 6.
Another thing that comes up is that certain markup + CSS approaches that seem so intuitive and simple in more modern browsers don't work at all in IE 6. If you go down one of these paths, you generally have to start from scratch once you realize that your code that works beautifully in FF and IE 7 doesn't have a chance in IE 6. More lost time...
I agree with the rest of you that if you can control your project and don't care about the IE 6 market, by all means forget about it. Unfortunately, some of us don't have that luxury quite yet.
We've already dropped it, but it depends on who you're marketing to. Only other companies will ever see our product, so we can be fairly certain they're at least using an operating system that can support IE7. If you're marketing to the entire internet then you may want to make certain that nothing breaks for a while yet.
Depends on the project. If I write the code conforming to web standards usually I don't have many issues.
If I'm using a template downloaded from the web, it often spells out very clear in bold letters: "manifest destiny is a bitch. don't trade blankets with anyone."
Unfortunately, I have a bunch of friends in other businesses that are sticking with IE6, and don't have a plan to upgrade.
They don't like the tabs in IE7, they don't want to go with another browser, etc, etc, etc.
There is enough of this that filters back to me, that I continue to test against IE6, and will do so for the indefinite future. Doesn't make me happy...just do it.
The vast majority of our internal corporate users are still on IE6. Until the powers-that-be decide to push out an update with IE7 or IE8 we will continue to support IE6 as our primary browser.
As far as I know, there are no immediate plans to upgrade.
Zero. Dead and gone as far as I'm concerned.
Really, you should be answering this question for yourself.
If you don't have a decent web log statistics package such as AWStats, then there's the first thing you need to do.
Otherwise, decide how much time you spend supporting IE6, and see what percentage of your users that is. If the time-to-customers ratio doesn't balance out, then you can decide to ditch IE6. Another factor to consider is how important your product is to your customers. If you're working on Salesforce.com, you can probably assume that they'll be willing to upgrade if you prompt them to do it. If you're talking about a server that injects ads into webpages, then you'll probably be at their mercy of browser choice.