You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2007/10/12 16:37:28 UTC
(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 <st...@oucs.ox.ac.uk>
> Reply-To: stuart.yeates@oucs.ox.ac.uk
> To: Ross Gardler (JIRA) <ji...@apache.org>
> References: <30...@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'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
Re: (FOR-1052) Add class attributes to the html generated by the FOAF plugin for later CSS styling
Posted by Ross Gardler <rg...@apache.org>.
On 12/10/2007, Tim Williams <wi...@gmail.com> wrote:
> On 10/12/07, Stuart Yeates <st...@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 <st...@oucs.ox.ac.uk>
> > >> Reply-To: stuart.yeates@oucs.ox.ac.uk
> > >> To: Ross Gardler (JIRA) <ji...@apache.org>
> > >> References: <30...@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.
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
Re: (FOR-1052) Add class attributes to the html generated by the FOAF plugin for later CSS styling
Posted by Tim Williams <wi...@gmail.com>.
On 10/12/07, Stuart Yeates <st...@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 <st...@oucs.ox.ac.uk>
> >> Reply-To: stuart.yeates@oucs.ox.ac.uk
> >> To: Ross Gardler (JIRA) <ji...@apache.org>
> >> References: <30...@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
Re: (FOR-1052) Add class attributes to the html generated by the
FOAF plugin for later CSS styling
Posted by Stuart Yeates <st...@oucs.ox.ac.uk>.
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 <st...@oucs.ox.ac.uk>
>> Reply-To: stuart.yeates@oucs.ox.ac.uk
>> To: Ross Gardler (JIRA) <ji...@apache.org>
>> References: <30...@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/