This is strictly an opinion/experience question for research purposes.
I was wondering what coding standards companies have in place now for Web Developers? (Document formats, coding standards, file structures, etc.)
Obviously they all can't be listed, but some major ones would give me an idea.
I hope that company coding standards for Web Developers include W3C standards, but commercial pressures will tend to encourage whatever solution gets the job done.
I would love to be proved wrong in this regard.
The World Wide Web Consortium is the main international standards organization for the World Wide Web.
At the previous (large) company I worked for, there were three main standards that were to adhered to for front-end work:
All HTML would adhere to the HTML 4.01 Strict standards, with the following exceptions:
iframes were to be allowed due to advertising.
The start attribute was to be allowed within lists.
target="_top" was allowed to be used for framebreaking purposes.
These exceptions were codified into a custom doctype document, which is documented here. All work produced was expected to validate against this doctype.
All CSS would validate against the CSS 2.1 standard, with the exception that the * and _ prefix hacks were allowed to be used.
All JavaScript was expected to pass through JSLint without issue (strict whitespace was absolutely not turned on).
We also ran regular code reviews with the expectation that these would allow us to pull out the good work done by our developers and codify this into best practice.
The Web Accessibility Initiative (WAI) is something to be considered as well by any serious web developer: http://www.w3.org/WAI/
Try StyleCI, it supports PHP, JavaScript, CSS, Typescript, Less, SCSS and Vue.js.
You can configure StyleCI to your coding standards too and it can automatically fix your code. We use it on a bunch of projects.
Related
Is there a formal standard I can use to to rate the accessibility, especially for visually impaired people, of my MVC3 web application? If there are various standards, as I suspect, which should I give preference to for a web application primarily targeted at people with no or minimal visual impairment, but strongly wanting to offer as much as possible to visually impaired people? This is a learning management application, so wide accessibility is important.
I am trying to stick to best practices in terms of HTML and CSS semantics and such like things, documented in the handful of books I have, and I am using HTML5 validation in Visual Studio for my Razor views. What other tools can I use, preferably on the development side, before I deploy and can use the various online validators? Are the any online rating tools?
Standard (and reference list)
The W3C standard is WCAG 2.0.
The WCAG 2.0 Recommendation tries to be technologically agnostic and to apply to all kinds of websites, even web apps but the consequence is that it's rather unspecific. HTML/CSS/Script Techniques (as well as the Failure ones and Flash/Pdf/Smil if you use them) and the Understanding part are good reads.
For daily auditing I prefer to use:
AccessiWeb 2.2 reference
list,
"a methodology to verify conformance to WCAG 2.0" that "facilitates
(its) understanding and implementation".
There are references to WCAG 2.0 Success Criteria and Techniques but alas no links. Hyperlinks exist on the french version but weren't added on the english one, alas (I'll try to fix it with them this month).
The script part, essential to webapps, is again partly unspecific but that's because it's hard to be so without having 10x as tests! There are thousands of things to do with JS when there are a hundred of HTML elements.
EDIT 2014: this checklist has been updated to new techniques in HTML5/ARIA (an awesome work imho) but only in french. AccessWeb HTML5/ARIA (in french) May be translated in english in 2014 or 2015 or try an online translation service ;) 70% of tests are common with AccessiWeb 2.2 and the new tests are up to date HTML5/ARIA techniques already working in modern websites with the browsers and screen readers quoted in Annexes.
ARIA, as in Accessible RIA, is another work from W3C-WAI:
(ARIA) especially helps with dynamic content and advanced user
interface controls developed with Ajax, HTML, JavaScript, and related
technologies.
No doubt this is the future of accessible web apps but its support is a work in progress in browsers and assistive technologies. Also old screen readers'll never be compatible with ARIA and they're very slowly being replaced for newer versions because they cost A LOT (thousand(s) of USD/EUR for JAWS).
Thus webdevs must always create apps compatible with both old plain techniques (using tab key and space to access information and interact with it) and new ones (manipulating a tree with arrow keys, being informed of changes in a Live region while reading another part of the page).
ARIA is complicated, needs time and experience, etc
ARIA doesn't replace WCAG 2.0; huge improvements'll be seen with WCAG 2.0 only.
not everything is as complicated as a tree implementation. Landmark roles are very easy to add in any website for example.
If you use jQuery UI, there exists an accessible version of popular modules/scripts: http://hanshillen.github.com/jqtest/
It isn't perfect yet but it's far better than the original. In my experience, you can't mix the legacy jQuery UI scripts and these ones (though I didn't try for too long, I could easily be wrong).
Testing
I wrote about 2 useful services, Opquast and Tanaguru, in another answer. The other answer from BrendanMcK related to automated tests is a must read.
WAVE (fluffmyboner already wrote about it in the other answer) both exist as a toolbar and as a webservice. Main difference afaik: the WAVE toolbar'll analyze the DOM of your page while the webservice'll analyze the HTML+CSS sent but won't execute any JS
TAW (select inglès than WCAG 2.0) is another service for analyzing a few criteria
Wave is my go-to for accessibility validation, although I'm not too sure about what you can use to check pre-deployment.
I am really new to this so please forgive the basicness of my question...
I want to learn to design websites and I have a program which I am planning to learn (Dreamweaver CS5) using tutorials from Lynda.com. However on the tutorial it says you should have a good grasp of HTML and CSS before starting Dreamweaver.
I looked at the Lynda.com video for HTML but it is all focused on XHTML. http://www.lynda.com/tutorial/47603
Now I am a bit confused. I heard a new standard was coming in (HTML5). If I learn XHTML - does that mean that I will then have to go back at a later date and learn HTML4 so that I can then catch up and learn HTML5 or will I be able to use my XHTML knowledge and add the future HTML5 code to it?
For example there is a Lynda video on HTML5 but the author says you need a knowledge of html before you can watch it.
Do you think the Lynda.com video on XHTML/HTML is a good place to start or do I need to get a book on HTML4 instead?
If you were starting out now would you learn HTML4 or XHTML?
Thanks
XHTML, absolutely.
Last recommended HTML version was 4.x, and it's from 90s era.
Learn XHTML as much as possible, and try to use strict versions.
I agree with #Matías, if only because of it's strictness which will likely result in cleaner code in the long run. That said, porting from one html version to another shouldn't be too difficult regardless of which one you choose.
I find that when programming the use of XHTML is nice because it allows me to catch errors in my markup at compile time instead of some obscure bug showing itself way later when I modify a page.
The whole lack of XHTML 1.1 support in IE has been a pain, but there are work arounds such as XSL transformations and the such. IE9 has finally added support.
Once (X)HTML5 support becomes strong in the major browsers I intend on using XHTML5 in any web projects I do for work. Supporting legacy IE versions will still be a pain, but it will be manageable.
I would learn HTML4.01, but only because I detest XHTML.
It doesn't matter that much, making the port from (X)HTML x.xx to (X)HTML y.yy is not that hard. You'll have a few pitfalls, but that's all.
On the other hand, HTML5 is quite different and you can start learning it already. It's already happening.
Whatever you learn, make sure you learn the Strict version.
Check this out for future proofing: http://blog.twostepmedia.co.uk/css3-still-novelty-or-usable-in-everyday-web-development/
To the O/P, learn the basics of HTML4 and then get straight onto HTML5, you'll be way ahead of the pack and your websites WILL stand out :)
I would personally work on learning HTML5. By the time you get proficient at it to be good enough to professionally code websites, most of the major browser vendors will have adopted it as the standard.
Remember, web technology moves fast! What's hot today will be obsolete tomorrow, and what's in beta now will be hot tomorrow.
I found this http://headjs.com, a modernizer, here on Stack Overflow, which is used to future-proof web applications. This makes learning and using HTML5 markup a possibility today, so that as browser vendors update their applications, they'll slide right into the HTML5 functionality.
Make CSS apply only for Opera 11?
For a brief summary:
HTML 4.01 is the current standard of markup languages for the internet.
XHTML 1.0 was forked off from HTML 4.01. It introduced greater strictness in validation, more XML-like syntax (eg. <br /> instead of <br>) and XML namespaces for things like MathML (for embedding mathematical equations in pages.... very infrequently used). In theory XHTML allowed people to define their own tags.... but in practice this never happened. In actuality, the only real different it has from HTML 4.01 are the self-closing tags, a different doctype (the header at the top of HTML documents), and a few attributes on the <html> tag.
XHTML 1.1 was a natural progression from XHTML 1.0. It introduced even greater strictness, and enforced things like mime-types for served documents. However, because it declared it was XML instead of HTML, and had to be served to the browser as XML (which Internet Explorer to this day does not support), it never took off.
XHTML 2.0 was a draft recommendation that got scrapped along the way. No-one subsequently uses it.
HTML 5 is the next evolution from HTML 4.01. It adds a lot of new tags, new functionality such as local storage (meaning more web-app type applications are possible), and some other goodies. It comes in two flavours - HTML 5, which uses HTML-style syntax, and XHTML 5, which uses XHTML syntax with self-closing tags (and is not to be confused with XHTML 2, which is dead remember.) It is 'the next big thing' in web markup languages, but is still in draft stage. Some browsers are introducing support for new HTML 5 tags, but legacy browsers have no support.
HTML 5 cannot be safely used in current sites, due to the draft nature of the specification. Some sites are doing so, but those sites can possibly get the whole nature of the language yanked out from under their feet.
HTML 5 is not expected to be a formal recommendation until 2022.
In summary: The current language of the web is HTML 4.01. HTML 5 expands on that greatly, but is not ready for everyday use. And the differences between HTML 4.01 and any flavour of XML, are minimal at best.
XHTML's main benefit, as Matias said, is it's XML compatibility, and also the other way round; I regularly use an XSLT to transform an XML document into XHTML. Although XSLT can output HTML, it's HTML that's compliant with XML anyway.
Strictly speaking, there's no reason you can't write HTML5 that's totally XML compliant; for that reason alone, I'd say go with HTML5, and by writing it so that it IS XML compliant, you also get all the benefits of XHTML.
I would like to develop solid web development skills. I have some back-end knowledge (my weapon of choice is RoR), but I am absolutely terrible with HTML, CSS, Javascript, all the front-end / user interface stuff.
Do you know any good resources to develop HTMl/CSS skills? Javascript is more of a programming language, so I don't think it really fits within this question, but if you know any good resources, I'll also welcome those!
A List Apart
Smashing Magazine
CSS Zen Garden (more for inspiration than actually learning, but still)
Watch Douglas Crockford — The JavaScript Programming Language from YUI Theater to learn some javascript skills.
For HTML, i Learned a lot from HTMLDog. I don't think it is updated any more but it is all still relevant, as the HTML / CSS Spec hasn't changed since it was written.
For CSS, your first stop should be Eric Meyer's site. He literally wrote the book (four or five, actually) on CSS.
www.w3schools.com
http://www.w3.org/Style/CSS/learning
html http://www.w3schools.com/html/
jquery www.learningjquery.com
Books I could recommend:
CSS the missing manual
Head First HTML With CSS & XHTML (O Reilly)
In my experience, most of the tutorials about HTML/CSS cover its sintax, tag meanings, attributes ,etc. You can cover them in a few days, and then you can forget quickly. IMO, it is better to look for designs, then see the source in order to know how they're made. In this way, you will be able to see what you can do with tags/css combinations.
You can see some free templates at the following sites.
Open Source Web Development
Free Web Site templates
First thing that comes to me, will be to understand the reasons of those meta languages, you should understand that the separation between contents, visuals, and functionnalities must be separated.
If you know RoR, you should know about the MVC pattern. It's quite the same here.
Try to learn, why, and you will understand how.
You should also know about (x)html semantic which a must to know before doing anything.
To have a good introduction, you could give a read to the Markup Guide which explains to clients every xhtml tags.
All links given by RegDwight should be a good start.
As a javascript library, i would advise jQuery, which complete, and easy to use, with a short learning curve (but complete anyway).
So HTML 5 has been widely publicised as expected to be ready in 2022. This is a long time to wait, and the test for that readiness is that "at least two browsers to completely pass [HTML 5 test suites]"
Obviously for browsers to pass this test they have to start implementing usable HTML 5 features before that. The list of new HTML5 features supported is looking thin at the moment. But there are a couple of significant changes to existing elements such as allowing A tags to surround block level that could be very useful now.
There are sites that are using HTML 5 now, so what are the factors that will make you start, or keep you from, building sites with an HTML 5 doctype?
Myself, I'm toying with HTML5 in a couple of personal sites, but will wait a while for work sites until things like a reliable validator appear.
It helps to divide this question into several parts.
1) When should one start using the HTML5 doctype?
The HTML5 doctype causes browsers to render pages in Full Standards mode. Unless you're currently using a strict doctype, pages may display differently. So you'll need to weigh up the amount of rework required if you're converting a existing site, and you'll need to understand the difference in rendering behaviour. Secondly, the doctype will cause the w3c validator to select HTML5 as the default language to validate against. Given that HTML5 is still in draft, this means aiming at a moving target. Is validity important to you? Some features that are valid in HTML4 are not currently valid in HTML5. Should you change your markup now to remove those features, given that HTML5 may change to make those features valid again? Provided you're comfortable with this, you can start using the HTML5 doctype now.
On the other hand, on it's own, what are you gaining? If you want browsers to render in Full Standards mode, you can use a strict doctype from HTML 4.01 or XHTML 1.x. Do you need HTML5 validation given that it will pass things that may not at present be handled consistently across browsers? Be aware that any HTML5 feature that currently works in browsers, works regardless of whether you use the HTML5 doctype or not.
2) When should one start using features that are currently interoperably implemented in the major browsers, but standardised for the first time in HTML5?
You can use these now, but try to make sure that your pages are properly accessible. Canvas, for example, does not provide good support for non-sighted users.
3) When should one start using features that are current implemented in some browsers, and will be standardised by HTML5?
This depends on your target users and delivery schedules. Will your users be using a browser that supports these features by the time your site goes live? What happens if they don't? Does the page fall back gracefully? Do you care if some users can't use your site?
4) When should one start using features of HTML5 that are not implemented at all yet?
Why would you want to do that? It might be reasonable for training purposes or investigating fall back behaviour, but HTML5 is still in draft form, and it's quite possible that some features will never be implemented, or will be implemented in a totally different way to that currently described, so you could waste a lot of effort.
Summarising, what matters is not so much what's in the HTML5 draft, as what is practically usable today. The draft describes a range of features, some of which have been in browsers for years, some which are new but have support or good fall back behaviour, and some which are not currently and may never be usable.
For me, I'll be holding off until I need an HTML5 feature, and I know that that feature is implemented in a consistent and stable way across the major browsers. That will probably happen some time during HTML5's Last Call phase, or possibly during the Candidate Recommendation phase.
Already have started using it for personal and client work.
For validation I use Henri Sivonen's excellent http://validator.nu/
When IE supports it. I work in the corporate world, and IE is required.
I use the doctype now! (for some projects at least)
As for the features, things like <canvas> and <video> are cool and useful now because there are often ways to make the content available for users whose browsers don't support HTML5 yet.
Semantic page structure tags like <sidebar> and the lot don't seem very urgent to me. I'll let those sit for another year or two.
With different browsers choosing to render CSS in their own preferred way , whats the point of having a standard?
Simple stuff like creating a fluid 3 column layout that works across all browsers can be an experience in frustration. How do you deal with this or make cross-browser compatible development not so painful?
As always, there's a reason behind all this.
The standard is not broken (a standard can't be broken), just that some browsers like IE don't adhere to it completely.
This is mainly because IE was developed before any standard was created and in that time it was the best browser around, with almost zero competitors (I read that netscape was the other option and that it was much worse than IE).
Then people realized that a standard was needed, and they created it obviously not including any of IE proprietary code and features. IE was forced to choose backwards compatibility with it's previous versions, or to adhere to this new "standard", they absolutely ruled the browser market so the choice was obvious.
With new versions IE tried to be more and more standards compliant, and they say that IE8 successfully passes the ACID2 test, so the standard utopia is (slowly) coming to reality.
In the mean time, check this site -> quirksmode that contains useful cross browser information. Also try to check any articles about "IE box model" online, and stay away of padding in IE. If you also use a 3rd party javascript library (JQuery, Prototype, Dojo) you should be fine (or as fine as anyone of us can be).
Regards.
One major point of having standards is to keep us out of another browser war. You know the one where Netscape and Microsoft kept adding as many proprietary features as they could to the browsers. Cross browser development is a breeze today compared to then...
Another good reason for having standards is that you know where future versions of the browsers will be heading. Following the standards is the best prediction that you can get for how future browsers will work.
You can find a lot of cross-browser tips in this question: How can I achieve a consistent layout in all browsers?
Standards are emergent, not pre-defined. Well, at least they should be. Many developers I've talked to seem to find my view of Web standards slightly heretical, but stay with me here.
When you try to create the standard before the implementation, you have several problems:
A long delay before useful implementations appear. Nobody has a working implementation to reference, and since nobody is using any of the standard's features (since it doesn't exist yet), there is little impetus to actually implement it. A chicken-and-egg type of problem.
The potential for standards that cannot actually be implemented. Who knows for sure until somebody actually tries it? The HLA standard was a good example of this happening, to the point where the DoD had to write an "interpretations" memo that attempted to set the de facto standard by glossing over some of the errors in the actual standard.
The potential for standards that don't serve any practical need. Do people actually want this? See example at XForms, which has fallen into a weird, server-side niche. Or, I can't think of anybody I've met who found the CSS "width does not including padding" box model to be intuitive.
An inability for implementers of the standard to distinguish their products from their competitors, resulting in a stubborn desire to break with the standard in practical or lock-in-encouraging ways. See example at CORBA.
I think that the W3C learned this the hard way in recent years. Some of the most end-user visible innovation has come from a new browser war: examples would be HTML5 (several vendors), canvas (Apple), XMLHttpRequest (Microsoft's Outlook Web Access team), input range (Safari's built-in RSS reader), and the video element (Firefox)--these came from the proprietary level on up, not from the standards tower on down. And these new "standards" were forged by looking at these past individual implementations (Firefox copied Microsoft largely for XMLHttpRequest, and so on), not by some wide-eyed think tank pondering the future. (ISAPI, the Netscape plugin API, and SQL are all examples of bottom-up standards, where breaking changes are done gradually in a lock-step fashion.)
A standard should be a least common denominator that smooths over the basic differences in implementations, a pidgin language that works across all of them, and not an enumeration of Robert Lowth-style prescriptive rules about a language or system, because then you end up with rules that don't always make sense or apply a non-realistic ideal (like trying to apply Latin-based grammar rules to a Germanic-based language, like trying to apply XML-based grammar rules to an SGML-based language). Oh well, this is what we've got.
Probably the greatest defect in the CSS standard at this point is that there really isn't a good way to specify that a page was written against a particular version of the standard. We can specify DOCTYPEs for our HTML documents, why can't I indicate that a document was written for CSS 2.1? This will only become more important as we start adding more and more bizarre features to CSS that affect the actual content of the page, such as CSS's :before pseudo-elements. A future version of the standard is going to have errors one day that potentially break compatibility, and it'd be nice to let the document author ask for certain behavior rather than have browsers attempt to figure out the intent.
On the lighter side, though, now that IE8 and IE7 are out, things really aren't as bad as they were in, say, 2005. A specific IE6 stylesheet served with conditional comments can really go a long way to making a CSS/standards-based implementation feasible. The other advice is to use Google, to take the 3-column fluid layout example, and hope that someone else has done most of the troubleshooting for you.
Creating a cross-browser compatible Web site is difficult, standard or no standard. You can make it easier on yourself if you accept that there will be some differences in the way different browsers render your site. Don't be afraid of proprietary extensions by any means (it's all right to have CSS3 rounded corners for your non-IE users), but have a fall-back for when they don't exist (eh, the rounded corners aren't critical for using the site), and let your users choose how they'd like to consume your content.
The other answers to this question pretty much cover the ins and outs of why CSS isn't the problem, but as for how I deal with the cross-browser difficulties, it's normally in roughly 4 steps:
Design the site using firefox, as it has lots of useful extensions (most notably Firebug, which tells you which CSS rules are being applied, which are being over-ridden by other rules, etc.)
Check the site quickly in Safari and Opera to make sure design has no flaws there. Normally it'll work fine as - thanks to the CSS web standard - these browsers render web pages in almost identical ways
View the design in ie7 and use the *+html css filter to correct errors
View the design in ie6 and use the * html css filter to correct errors
to do points 3 and 4 yo would have something like this
.box {css rules}
*+html .box {css rules to override in ie7}
* html .box {css rules to override in ie6}
At the end of all this you will still be left with valid css that works across the major browsers.
Hope this helps
*edit - forgot to add that ietester is a great bit of software that allows you to install multuiple versions of ie on windows xp or vista: http://www.my-debugbar.com/wiki/IETester/HomePage
The standard has some shortcomings. It's also quite a difficult thing to implement. The problem is in the implementation more so than the standard.
Use things like YUI where a lot of smart people have done a lot of hard work to make these things work across various browsers.
The standard is there in the open so that the browsers who do not confirm to the standard may look and learn. The standard is important because it is the only way by which you can HOPE to make a webpage that will display correctly on all pages.
Also remember that a standard that is developed is never for the past, it is only for the future. If in the past some browsers did not confirm to the standard it doesn't mean that we should not have standard.
In fact the standard is born because the browsers were all doing their own thingie and there was then a need for the standard.
If you code to the standard the browsers will confirm to it.
Have a hope pal!
It looks to me that You are just starting with CSS. Because even though the browsers do not adhere to the CSS specification perfectly, there is a lot of safe ground that You can use with confidence. This safe ground is nowadays much larger than it used to be about ten years ago, when coding for web was really a royal pain. And new browser releases adhere to the specification more and more, which is exactly why the standard matters. It is a kind of theoretical ideal that the browsers will probably never fully achieve, but even 90–95 percent of it are quite useful in the real world.
I also wish IE would have better implementation of CSS, but once You learn the few things that behave oddly, You can code most of the usual layouts without major hiccups. Most common layouts have also been discussed to death on various CSS forums on the web and there is always some good solution readily available so that You do not have to make it up yourself.
The CSS standard is IMHO not the problem [at least not in the sense of Your question], the problem is the reality of the browser market and the software market in general. As for the frustration, it should mostly go away after You gain some experience. The limits will always be there, but there is a plenty of safe space.
That seems like a non-sequitur. Just because some browsers flout web standards does not mean there's something wrong with the standards themselves. It's a bit like saying that seatbelts are broken because some people choose not to wear them, or that drunk driving laws are pointless because some people don't obey them.
If there were absolutely no standards to conform to, then there would be no World Wide Web, period. Just like an egalitarian society is an unachievable ideal, yet striving for that unattainable ideal has produced tremendous social progress over the decades, so too have W3C recommendations and open web standards produced measurable progress over the lifetime of the web. Without standards like CSS, the interoperability which the web depends on to thrive would not exist.
Yes CSS is broken - though semantically you cannot call it a 'broken standard'. But the question is not really one of semantics.
Experience of aiding in the definition of the UNICODE standard back in the late 80s and early 90s was good training for learning how to write a standard well. I have rolled my eyes so many times W3C write standards documentation that leaves immense holes in the definitions that lead to browsers interpreting things in different ways. There are many mutally exclusive parts to the CSS standard, even in v3, that have come about because we still have to keep compatibility with pre-CSS1.
On the critical side, CSS has three mind-bendingly obvious issues that any computer scientist will tell you are both improperly designed and inconsitent.
The Box Model - there are still huge holes in this even as CSS 3 approaches.
The 'specificity' calculations. 'specificity' was implemented to patch a hole in CSS standard and then later to try and shore-up the ever conflicting rules. If stylesheets are be truely cascading then 'specificity' needs to be scrapped. Until it is CSS should be called SWISMCCS (sometimes-when-it-suits-me-CSS). Of course, in order to scrap this feature all the remaining issues with loose language in the standards need fixing - which in reality means it will never happen.
Naming conventions for classes,selector etc allow the use of characters that are a problem for dynamic processing. The most obvious is allowing '-' symbol to be used in names. If you don't understand why I would encourage you to read up and bytecode compilers and compiler language parsing.
So the answer is the CSS standard is not broken, the premise is sound, but the implementation of the standards documentation (not the browsers, the documentation) shows how conquest by committee will rarely get you something fully fit for purpose.
I suppose this was because CSS was not created for trained programmers, it was created for web-designers - a strange breed who are not really programmers and not really designers. There are real web-developers who are different, but spend less time on pretty graphics.
IMHO: CSS is broken. On the other hand, the alternatives are much worse. Better the devil-we-know. Role on the replacement for HTML.