One of the pain points we see on web projects is the divide between client side and back end development. This pain might show itself in a number of ways:
- Small changes in the HTML cause lots of tests to fail
- Small changes to visual layout require large changes to the HTML which then causes the above
- Developers say the work is done but it can’t be signed off as it looks terrible or doesn’t work in certain browsers
- CSS or QAs want developer to add ID attributes to lots of elements so they can target them more easily
So if we are working in a world where we don’t have the ideal but still need to get the job done what can we do to reduce the pain?
Well the technique I have used on a number of teams is to come up with a “HTML contract”. An example might be as follows:
- Everyone must make the HTML as semantic as possible
- IDs are deprecated in favor of class attributes. Just use more specific CSS selectors to target elements
- Developers will liberally add class attributes with semantic names even if they don’t need them immediately (QAs and CSS will use them even if you don’t)
- CSS / Designers can add class attributes if needed but can not remove class attributes without pairing with a dev/QA.
- QAs are to use hand written XPath expressions in tests that match the domain and make extensive use of contains(@class, ‘someClassName’) and descendant:: rather than IDs or specifying HTML tags
Some more general tips that I find help:
- Converting tables to divs is really no better apart from download size. Use divs to group things or as the root element for a control, use lists for lists of things, tables for tabular data etc.
- When you have a CSS issue keep deleting rules until you work out which rule is causing the problem then rebuild the rules up.
I post some examples in my next post