On 12/10/2007, Tim Williams <[EMAIL PROTECTED]> wrote:
> On 10/12/07, Stuart Yeates <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > >> Reply-To: [EMAIL PROTECTED]
> > >> To: Ross Gardler (JIRA) <[EMAIL PROTECTED]>
> > >> References: <[EMAIL PROTECTED]>
> > >>
> > >> 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.

Well if we don't care about bandwidth and we are to output both then
lets at least do it in a way that preserves the information in a
useful way (Stuarts valid argument for having class information). I
feel sure there is a sensible microformat for FOAF data (XFM I think
is the nearest thing, but I'm no expert).

I'll apply the patch with the modifications I suggest but create an
issue to add microformat data to the output HTML.

Ross