W3C home > Mailing lists > Public > public-test-infra@w3.org > July to September 2011

Re: dropping "title" column from specifications table?

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 26 Sep 2011 11:43:02 -0700
Message-ID: <4E80C7B6.7090106@inkedblade.net>
To: public-test-infra@w3.org
On 09/26/2011 10:31 AM, Linss, Peter wrote:
> Hi Mike,
> For the CSS specs, many of them have a rather long formal title and a significantly shorter name that's commonly used for them, i.e.:
> CSS 2.1: Cascading Style Sheets Level 2 Revision 1
> CSS3 Images: CSS Image Values and Replaced Content Module Level 3
> CSS Lists: CSS Lists and Counters Module Level 3
> Using the 'spec' short name is not appropriate for general UI as it really is meant to be used, as you said, as a DB key and in URIs, and given the long formal titles of some specs, having a shorter name is very helpful in the UI.
> I accept that for many specs the 'title' and 'description' fields will simply be identical.
> If it helps, consider 'title' to be a version of the URL short name suitable for UI use. (Which is sometimes more of a change than a simple transform, like 'CSS-STYLE-ATTR': 'CSS Style Attributes'.)
> While the harness doesn't make much use of the 'title' field, Shepherd does, as it has more exposure of the specs in the UI. I want both the 'specifications' and the 'sections' tables to be sharable between the tools. (In fact for a setup using both Shepherd and the harness it makes more sense to maintain the spec and section tables in Shepherd as that's the first point of exposure between tests and specs.)
> So bottom line, I really think that field is necessary and it makes sense to keep it around. The pattern of a short name and full name is also used in other tables, like 'formats'.

If that's the intended use, then maybe there would be less confusion if the
fields were titled "Full Title" and "Short Title"?

Received on Monday, 26 September 2011 18:43:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:32 UTC