6:23 a.m.
Has anyone here noticed that the css declarations removes the
capabilities of various docbook elements?
For instance, I have some data that I have put into a table. I followed
all semantics of the CALS table attributes that docbook utilizes. Yet, I
am unable to successfully alter the table attributes and their
appropriate values to achieve the desired outcome --- because of html
attribute inclusion by css.
i.e.
<table id="entities" frame="all"><title>Demonstration
Entities and
Relationships</title>
<tgroup cols="3" align="left" colsep="0"
rowsep="0">
<thead>
...
Now this should result in the following:
A framed table with three columns, all aligned to the left, and all rows
and columns NOT seperated.
But instead I get a framed table with a header background color of
#a9a9a9, a body background color of #dcdcdc, all aligned to the left,
and all rows and columns ARE seperated.
To do this, i should have declared so using the bgcolor and border
attributes. This breaks the element.
Thomas
7:39 a.m.
On Wed, 2005-05-18 at 06:23 -0500, Thomas Jones wrote:
Has anyone here noticed that the css declarations removes the
capabilities of various docbook elements?
For instance, I have some data that I have put into a table. I followed
all semantics of the CALS table attributes that docbook utilizes. Yet, I
am unable to successfully alter the table attributes and their
appropriate values to achieve the desired outcome --- because of html
attribute inclusion by css.
i.e.
<table id="entities" frame="all"><title>Demonstration
Entities and
Relationships</title>
<tgroup cols="3" align="left" colsep="0"
rowsep="0">
<thead>
...
Now this should result in the following:
A framed table with three columns, all aligned to the left, and all rows
and columns NOT seperated.
But instead I get a framed table with a header background color of
#a9a9a9, a body background color of #dcdcdc, all aligned to the left,
and all rows and columns ARE seperated.
To do this, i should have declared so using the bgcolor and border
attributes. This breaks the element.
I'll be the first to say that I am not a genius about DocBook
interactions with XSL and CSS. But I thought that it's generally not a
good idea to declare things like color and other presentation details in
the DocBook source, since those are expected to be transformed into a
common style outside the DocBook source, such as through CSS. The
result of the source should be a presentation that is consistent
throughout a project. In other words, the project doesn't really
benefit from me making chartreuse and magenta tables, since it doesn't
give that "Fedora look" (whatever that might be). Therefore we have CSS
that makes the HTML look the way we think it should, across the board.
Anyway, this is how I understood things, but again, I pretty much just
scribble and wield a red pen here. Am I way off base here, or is it
just that we have failed to cover guidelines on using some of this
DocBook markup?
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
8:34 a.m.
Paul W. Frields wrote:
On Wed, 2005-05-18 at 06:23 -0500, Thomas Jones wrote:
><snip>
>
I'll be the first to say that I am not a genius about DocBook
interactions with XSL and CSS. But I thought that it's generally not a
good idea to declare things like color and other presentation details in
the DocBook source, since those are expected to be transformed into a
common style outside the DocBook source, such as through CSS. The
result of the source should be a presentation that is consistent
throughout a project. In other words, the project doesn't really
benefit from me making chartreuse and magenta tables, since it doesn't
give that "Fedora look" (whatever that might be). Therefore we have CSS
that makes the HTML look the way we think it should, across the board.
Anyway, this is how I understood things, but again, I pretty much just
scribble and wield a red pen here. Am I way off base here, or is it
just that we have failed to cover guidelines on using some of this
DocBook markup?
I agree. Docbook is for content not presentation.
Upon reviewing the DB specifications it seems that the table element has
been split into db.cals.table and db.html.table. Guess this shows my
"old school" docbook experience..huh? ;)
However, Docbook still allows for all the elements that i mentioned.
Navigate to the following pages for reference to the attributes that i
mentioned:
http://www.docbook.org/tdg5/en/html/cals.table.html
http://www.docbook.org/tdg5/en/html/html.table.html
According to DB, they(being the attributes) should be available.
I am not trying to be a pain here; I am just trying to shed some light
on descrepancies with the current system. Which btw, i did check the
documentation-guide previously and it makes no mention of any of these
issues.
I agree with Paul alot of these have not been covered in the guidelines.
Personally, I think there should be a high-level driver generated that
redeclares these changes that you want. Given my experience in dtd
alteration, I would volunteer my help in generating such a driver file.
But thats if you editors see fit to need such a document.
Otherwise, we are just shooting from the hip.
6:59 p.m.
On Wed, 2005-05-18 at 08:34 -0500, Thomas Jones wrote:
However, Docbook still allows for all the elements that i mentioned.
Navigate to the following pages for reference to the attributes that i
mentioned:
http://www.docbook.org/tdg5/en/html/cals.table.html
http://www.docbook.org/tdg5/en/html/html.table.html
According to DB, they(being the attributes) should be available.
If the CSS overrides a legitimate DocBook XML attribute, on the face of
that I would call it a bug. If you have a patch for the CSS (or XSL,
when that happens), you can file a bug against the fedora-docs module.
I am not trying to be a pain here; I am just trying to shed some
light
on descrepancies with the current system. Which btw, i did check the
documentation-guide previously and it makes no mention of any of these
issues.
You are correct in raising the issue. There are certainly some bugs in
our toolchain, as well as definicencies in the Documentation Guide.
Bugs, patches, and offers of help are accepted and tabled until after
the FC4 release. Just so no one thinks we're ignoring the problems with
the tools and Doc Guide. :)
I agree with Paul alot of these have not been covered in the
guidelines.
Personally, I think there should be a high-level driver generated that
redeclares these changes that you want. Given my experience in dtd
alteration, I would volunteer my help in generating such a driver file.
But thats if you editors see fit to need such a document.
Otherwise, we are just shooting from the hip.
I _think_ this is, in spirit, what Tommy is talking about. For
consistency and making our job easier, using our own DTD that is a
subset of the standard DTD could make good sense. If I am understanding
the suggestion from both of you correctly. Is that what you mean by a
"high-level driver" file?
I want to do some research to understand the issues more.
Unfortunately, it will have to wait until _after 30 May. :) If we file
bugs now while the ideas are fresh, they will be waiting to deal with in
a few weeks.
Thanks for the help,
Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
10:53 a.m.
Uttered "Paul W. Frields" <stickster(a)gmail.com>, spake thus:
Anyway, this is how I understood things, but again, I pretty much
just
scribble and wield a red pen here. Am I way off base here, or is it
just that we have failed to cover guidelines on using some of this
DocBook markup?
I believe we have some implicit assumptions that need to be made
explicit:
1) No, repeat NO, style information within the XML files; leave that to
the CSS stylesheet. As you say, this gives us a uniform
appearance for all the FDP documentation.
BTW: this is exactly my point in suggesting we have our own
minimal DTD that takes the tags outlines in Tammy's
Documentation-Guide, exactly as written there. Keeps folks from
getting clever.
2) We expect to render PDF output as black/white/greyscale. Yeah, it
looks generic, but it is real cheap to print versus 3-256 color
printing.
I think this is all it would take to clarify matters.
Cheers
1:25 p.m.
Tommy Reynolds wrote:
Uttered "Paul W. Frields" <stickster(a)gmail.com>, spake
thus:
>Anyway, this is how I understood things, but again, I pretty much just
>scribble and wield a red pen here. Am I way off base here, or is it
>just that we have failed to cover guidelines on using some of this
>DocBook markup?
>
>
I believe we have some implicit assumptions that need to be made
explicit:
1) No, repeat NO, style information within the XML files; leave that to
the CSS stylesheet. As you say, this gives us a uniform
appearance for all the FDP documentation.
BTW: this is exactly my point in suggesting we have our own
minimal DTD that takes the tags outlines in Tammy's
Documentation-Guide, exactly as written there. Keeps folks from
getting clever.
2) We expect to render PDF output as black/white/greyscale. Yeah, it
looks generic, but it is real cheap to print versus 3-256 color
printing.
I think this is all it would take to clarify matters.
Cheers
I agree --- this is why I attempted to bring it to everyones attention.
Although it seems as though it was already; just not in current
discussion. If you review my example, I wanted no post-processing
attributes; but found that they were there none the less. This lead me
to further investigate the issues at hand because I knew I did not
declare such. I was simply stating that there was a discrepancy.
I think it would benefit everyone to explicitly declare and mitigate
these issues within the documentation at a minimum; if not redeclaration
of the markup language. The brashest of comments still does not remove
the probability of authors stumbling upon similar, if not the same,
issues. IMHO, all chances for uncompliance should be removed within a
dtd structure.
However, I do not fully understand what you exactly mean by a minimal
dtd? Are you referring to a custom subset of DB? Or another entity
altogether that I am not familiar with? ;)
6911
days inactive
6911
days old
5 comments
4 participants
participants (4)
-
Karsten Wade -
Paul W. Frields -
Thomas Jones -
Tommy Reynolds