forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Williams" <william...@gmail.com>
Subject Re: (FOR-1052) Add class attributes to the html generated by the FOAF plugin for later CSS styling
Date Fri, 12 Oct 2007 20:00:01 GMT
On 10/12/07, Stuart Yeates <stuart.yeates@oucs.ox.ac.uk> wrote:
> 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 <stuart.yeates@oucs.ox.ac.uk>
> >> Reply-To: stuart.yeates@oucs.ox.ac.uk
> >> To: Ross Gardler (JIRA) <jira@apache.org>
> >> References: <3075260.1192185830580.JavaMail.jira@brutus>
> >>
> >> Ross Gardler (JIRA) wrote:
> >>>     [ https://issues.apache.org/jira/browse/FOR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534267
]
> >>>
> >>> 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.
>
> cheers
> stuart
> --
> OSS Watch: http://www.oss-watch.ac.uk/
>

I'm not worried about bandwidth personally so from that perspective...
why not output *both* - one to preserve the information and the other
to support formatting.  Then a CSS selector could style it the same as
all the others if desired down-select to the specific if that's
required.

e.g. <td class="foaf-mbox_sha1sum-label foaf-label">Mbox SH1Sum</td>

I haven't really followed this, but from what I gathered, didn't
necessarily see it as an either/or type issue.
--tim

Mime
View raw message