Sony BMG — Coding Suggestions

General Conventions

File names should be entirely lowercase to avoid any issues with case sensitivity. Naming should take advantage of modern file systems equipped with support for long file names and use that feature to it's fullest, spelling out any wording in full to avoid unintuitive abbreviations. To avoid excessive name lengths, names should be limited to two words or less. The lead developer on a project has two options for word separation:

Directory Organization

While Sony BMG sites have historically used a relatively flat directory structure, it is important for efficiency's sake to introduce a level of organization to the many files that often comprise a site. The top-level tier of this organization should differentiate file types in the following manner:

Stylesheet File Organization

For a site comprised of many different layouts it will not be uncommon to have up to (and sometimes even more) two thousand lines of style properties. While certain strategies exist for flagging sections for easy access via a text editor's search feature, the ideal way is to take advantage of the @import style property and break files up.

Stylesheets should first be split into those destined for screen-based mediums (computers, TVs, phones, etc.) and those destined for print. As printer stylesheets should simplify a site's design greatly, multiple files should not be necessary. For screen, a master file that imports any additional files should be used. These additional files will vary depending on a site's complexity. This master stylesheet should also include a site's style precedents (element styles found on 2 or more sections). Links, layout (see below), navigation, and form style precedents should be placed in their own respective files, as the amount of rules necessary for these elements usually demand their own dedicated files. Style precedents within a section, in addition to any page-specific styles, should be placed in stylesheets dedicated to sections.

Nested Site Model

For sites with multiple stylesheets, it is not uncommon to find the following sorts of naming conventions:

One-off Site Model

This will more likely be used for splash pages, contest entry pages, and other standalone sites that consist of several pages or less. If the master stylesheet contains over 150 lines, it's time to break some of those styles out and into separate files. Breaking out should be limited however, passing the 150 lines mark doesn't necessarily mean it's time to switch to the Nested model. Instead, focus on the types of styles that clearly have the most bloat in your master stylesheet (those that consist of 100 lines or more).

For Further Reference

Browser Support

In order to maximize developer efficiency and maximize the experience for the vast majority of the network (90% or higher), browser support should be more limited than it has historically been. Older browsers may have access to content, but this access may be limited.

Sony BMG sites must be feature complete in the following browsers:

Browsers built on the Mozilla rendering engine with QA'ed support for:

Other browsers to consider (though not necessarily supported) include:

Older browsers such as Netscape 4.x or earlier versions of Internet Explorer should not be tested for, and treated on an "as-is" basis. At a minimum these browsers should be able to access the markup of a site.

For Further Reference

Progressive Enhancement

The adoption of new technologies should not prohibit access to core content. The best way to accomplish this is through a strategy known called Progressive Enhancement. Fundamental to this is the idea of implementing new technologies in an unobtrusive way. First and foremost this means to pull in CSS and Javascript from external files. The lack of support for @import in CSS in older browsers like Netscape 4.x immediately disables CSS in that browser. For Javascript there are a number of techniques (such as object detection) to allow functionality to be applied to older browsers more selectively. Some functionality demands more sophisticated browser detection techniques, but that should be seen as a last resort as such techniques tend to be unreliable.

Overall this strategy pays off in a big way in multiple areas:

In addition to functionality, design should also be seen from this perspective. To insist a web page must look precisely the same across all platforms and mediums is to deny the realities the web presents. Instead, avoid being locked into those confines and deliver additional design value as possible. For example, Internet Explorer lacks support for certain advanced CSS selectors, while Firefox and Safari have extensive support. One real-life example of this is that IE 6 and below is unable to change any element other than a link's appearance when hovered over. Firefox, Safari, and IE 7 on the other hand fully support for the :hover selector. Another example is Safari's support of multiple background images (to be included in the CSS 3 specification). This alone enables rounded corners and dynamic sizing without any Javascript workarounds or junk markup. It's only a matter of time before Mozilla gains this. If these kinds of elements are not integral to the experience, why cripple more advanced browsers? Browsers are a constant evolution (with an exception of Internet Explorer, a sad reality that will hopefully change for the better). An analogy to this reality in print might be constant advances in paper. Even though most designs can be printed on a variety of papers, the better the paper is, the better the result.

For Further Reference

Contents