Re: making better ad hoc use of class attribute values

At 12:39 -0500 UTC, on 2007-08-31, Robert Burns wrote:

> On Aug 31, 2007, at 10:59 AM, Sander Tekelenburg wrote:
>
>>
>> At 12:39 +0100 UTC, on 2007-08-31, Philip Taylor (Webmaster) wrote:

[... mark up to indicate ship names and such]

>> I'm inclined to think that @class is 'good enough' for this. UAs
>> can make the
>> class value available to users (that they don't is just a UA bug
>> IMO). And
>> authors can provide a legend to their sites, that explain class names.
>> Authors can suggest a presentation, and users can choose to
>> override that
>> with user CSS. The latter seems reasonable to me at least in cases
>> where a
>> site is visited regularly by a user, and the site's author has
>> bothered to
>> use descriptive class names and to provide a legend explaining them.
>
> I really like this suggestion. It would be great if browsers exposed
> the class attribute values to users through some mechanisms.

Btw, note that users can already do this with something like

*[class]:before {content: " " attr(class) ": "; color: #000; background:
#ff9; font-style: italic}

In pratice that is too disruptive, because most sites use truckloads of
(semantically) meaningless class names and rely too much on pixel precise
lay-out. So a more selective, less disruptive mechanism is needed.

[...]

> I also think a separate specification should provide a way to specify
> in plain language the mapping between semantics and the current
> presentation. In this way, authors would use explicit markup to
> describe in human language how a class value was being used. [...]
>
> [...] Placing the
> burden for this on CSS, it could be accomplished something like
>
> @selectorHeading {
>      .bigissue: "'Known issues"
> }
>
> @selectorDescription {
>     .bigissue: ''There are some spec-wide issues that have not yet
> been addressed: case-sensitivity is a very poorly handled topic right
> now, and the firing of events needs to be unified (right now some
> bubble, some don't, they all use different text to fire events, etc)."
> }

That's a very nice idea.

I'm not really happy about burdening CSS with this though. It's not really a
presentational issue, and makes things CSS-dependant. I think it might be
possible to keep this within the realm of HTML:

What about <link rel="legend">? It could point to a file that in some defined
format provides expansions of class names. Essentially this would just be a
definition list, so it would appear that the format we need might in fact
already exist: just a HTML file containing a definition list...

What this might still lack is something to clearly mark the status of such a
document and its contents:

[1] The document providing the legend should perhaps *itself* indicate that
it is a legend (because it might not always be retrieved through <link>). I'm
not sure how.

[2] Would a legend have to be limited to contain only expansions of class
names? (That would be simplest.) If not, probably each definition would need
explicit markup to indicate whether it applies to a class, or an id, or
something else.

pros:
- Such a file would be easy enough to author (just a HTML file with at least
one definitionlist, linked to through the same mechanism authors already use
for Style Sheets)
- No need for authors to ensure that every class name is given a definition
(some class names are meaningless)
- Freedom for authors to inlude more definitions than just for class names,
if they'd feel a need to.
- Backwards compatible with all UAs since HTML 2, assuming they ever bothered
to provide support for <link>. (Quite a few by now actually; see
<http://www.euronet.nl/~tekelenb/WWW/LINK/>. Basically all except Safari.)
- Easy for authoring tools to auto-generate: they'd only need to provide the
author with a list of all class names of the site, allowing him to enter
descriptions.
- Authors wishing to do extra work for users of UAs that don't support <link>
or users who haven't yet discovered <link>, could add a plain link: <a
rel=legend>. (The only problem is that when you provide a link to one
document through both <link> and <a> that will confuse users of
<link>-capable UAs. But that's a general issue with <link> that we'll still
have to discuss. (I think ideally <link>-capable UAs should present <a rel=>
both 'in place' and in the chrome, together with other <link>s. That way
authors can safely provide only the one <a rel>, omitting the <link>))
- No CSS dependancy

cons
- Might conflict with existing content using rel=legend


HTML5 UAs could provide access to such information in 2 basic ways:
[1] by supporting link, as they do now
[2] by presenting the expansion 'in place', either by default (but probably
not by factory default), or on a per case basis, upon the user's request. (A
practical implementation could be through the contextual menu, or through a
tooltip :))

What this approach lacks is Robert's idea of supplying both a short and a
long description for a class. While that would be nice, it would require
something more complicated than a simple definition list indicated through
rel=legend. It would be nice to be able to keep it simple, and I don't think
it is absolutely essential to have both a short and long description. The
class name itself can hopefully function as the short form.

>    .big-issue { voice-family: 'female'; description:"spoken in a
> female voice; }
>    .big-issue { color: #E50000; background: white; border: solid red;
> padding: 0.5em; margin: 1em 0; description:"surrounded by a solid red
> border";}

Yeah, that would be nice :) But you'd have to define that it would need to be
suppressed whenever the rule is overriden by user CSS. I suspect that might
be complicated, because often only parts of a rule will be overridden...

Therefore I think that for <link rel=legend> the spec should include a note
warning authors to provide a 'presentational neutral' description.

But in general I do like the idea of allowing descriptions with CSS rules. I
don't think it's absolutely necessary in this case (providing users with
descriptions of class names), but it seems worth it to suggest it to the CSS
WG.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Saturday, 1 September 2007 14:48:24 UTC