As part of our ongoing effort to make our documentation more globally useful, instead of implying that our web content is Firefox specific, we’re going to start to get rid of our old “Requires Gecko X” banners at the tops of pages covering web standards in favor of compatibility tables. Some articles already have them, others don’t, but we’re going to start using them more.
This coming week, one of my tasks is going to be to try to create a MindTouch template that, given information about each browser or engine, will automatically lay out and generate a compatibility table. To do this, I’m going to make use of MindTouch’s support for named parameters, so that you can do something similar to this:
{{CompatTable(gecko:{version:”1.9.2″, note:”Was called -moz-foo before Gecko 2.0.”}, safari:{version:”4.0″, note:”Some notes.”}, ie:{version:8})}}
This would generate the table, automatically filling out any rows for unmentioned browsers with empty rows. For example, the table generated by the above template might do something like this:
| Browser |
Version Available |
Notes |
| Chrome |
- |
- |
| Gecko |
1.9.2 (Firefox 3.6) |
Was called -moz-foo before Gecko 2.0. |
| Internet Explorer |
8 |
|
| Opera |
- |
- |
| Safari |
4.0 |
Some notes. |
Notice that there are rows for Chrome and Opera even though they weren’t specified. This ensures that the tables site-wide will be consistently formatted. We can add new browsers to the table by simply adding them to the template, and updating articles at the appropriate times.
The main issues that need to be decided upon before actually writing this template:
- Can we simply have a “webkit” version number and figure out which version of Chrome and Safari that applies to?
- Can the same “webkit” version be used for mobile versions of Safari? I don’t think it can. Do any mobile versions of Safari have enough market share (and are different enough) to warrant mentioning explicitly, other than iOS?
By using named parameters, we can be much more flexible about leaving out bits of information, plus we can add more fields later without having to recode all past uses of the template. That said, if anyone has thoughts on additional information the template should initially be designed to support, please let me know.