(FOR-1052) Add class attributes to the html generated by the FOAF plugin for later CSS styling

> -------- 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.yeatesoucs.ox.ac.uk>
> Reply-To: stuart.yeatesoucs.ox.ac.uk
> To: Ross Gardler (JIRA) <jiraapache.org>
> References: <3075260.1192185830580.JavaMail.jirabrutus>
>
> Ross Gardler (JIRA) wrote:
> >     [ https://issues.apache.org/jira/browse/FO
R-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'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.

Ross

On 10/12/07, Stuart Yeates <stuart.yeatesoucs.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.yeatesoucs.ox.ac.uk>
> >> Reply-To: stuart.yeatesoucs.ox.ac.uk
> >> To: Ross Gardler (JIRA) <jiraapache.org>
> >> References:
<3075260.1192185830580.JavaMail.jirabrutus>
> >>
> >> Ross Gardler (JIRA) wrote:
> >>>     [ https://issues.apache.org/jira/browse/FO
R-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.u
k/
>

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

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.yeatesoucs.ox.ac.uk>
>> Reply-To: stuart.yeatesoucs.ox.ac.uk
>> To: Ross Gardler (JIRA) <jiraapache.org>
>> References:
<3075260.1192185830580.JavaMail.jirabrutus>
>>
>> Ross Gardler (JIRA) wrote:
>>>     [ https://issues.apache.org/jira/browse/FO
R-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.u
k/

On 12/10/2007, Tim Williams <williamstwgmail.com> wrote:
> On 10/12/07, Stuart Yeates <stuart.yeatesoucs.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.yeatesoucs.ox.ac.uk>
> > >> Reply-To: stuart.yeatesoucs.ox.ac.uk
> > >> To: Ross Gardler (JIRA) <jiraapache.org>
> > >> References:
<3075260.1192185830580.JavaMail.jirabrutus>
> > >>
> > >> Ross Gardler (JIRA) wrote:
> > >>>     [ https://issues.apache.org/jira/browse/FO
R-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.u
k/
> >
>
> 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