forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Yeates <>
Subject Re: (FOR-1052) Add class attributes to the html generated by the FOAF plugin for later CSS styling
Date Fri, 12 Oct 2007 19:32:36 GMT
Ross Gardler wrote:
>> -------- Original Message --------
>> Subject: Re: [jira] Commented: (FOR-1052) Add class attributes to
>> the html generated by the FOAF plugin for later CSS styling
>> Date: Fri, 12 Oct 2007 12:31:35 +0100
>> From: Stuart Yeates <>
>> Reply-To:
>> To: Ross Gardler (JIRA) <>
>> References: <3075260.1192185830580.JavaMail.jira@brutus>
>> Ross Gardler (JIRA) wrote:
>>>     [
>>> Ross Gardler commented on FOR-1052:
>>> -----------------------------------
>>> Why are these class attributes so fine grained?
>>> Instead of:
>>> +            <td class="foaf-mbox_sha1sum-label">Mbox SH1Sum</td>
>>> +            <td class="foaf-mbox_sha1sum-value">
>> [...]
>>> Wouldn't it be better to have:
>>> +            <td class="foaf-label">Mbox SH1Sum</td>
>>> +            <td class="foaf-value">
>> The value of mbox_sha1sum, unlike all the other values is a SHA1
>> hash, which every interfaces uses a  monospaced font for.
> OK, so that makes sense for the SHA1 vlaue to have its own class, but
> what about everything else?
>> This was the motivating example for this entire patch, but there are
>> other uses, which rely (as this one does) on the fact that the data
>> type of the value is fixed by FOAF/DOAP and there is the opportunity
>> to add CSS styling or javascript to make the value more useful.
> The problem I see is that you are creating quite a maintenance problem
> here. The way you have things if a new row were added to the FOAF
> table then users would have to add a new CSS style to their site in
> order to have it rendered correctly. In the majority of cases the
> content will need to be rendered the same, regardless of the row.
> It would therefore make sense to create a default rendering, such as:
> <table class="foaf-data">
> and then override it as necessary, ie, in the SHA1 row.

I agree that is a good idea.

> I'm not a big fan of putting classes on something just for the sake of
> it, it bloats the HTML generated. Although that is probably a
> throwback to when I was stuck with a 9.6k modem ;-)
> What do you/others think? I could apply your patch with the addition
> of the table level class (allowing defaults that can be overidden), or
> I can strip out the classes that are not used.
> Either way, I don't see the value of the different classes for the
> labels, so unless I've missed something I'll stip those out of the
> patch.

I'll declare my biases up-front: I'm using to styling TEI-derived
docs where every tag (mainly divs, spans, etc) have class defined
which reflects the tags from which they were transformed. This is
why I took that approach I did.

I had assumed (possibly incorrectly) that preserving information was
the right thing to do.

OSS Watch:

View raw message