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
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 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.
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
Uttered "Paul W. Frields" stickster@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
Tommy Reynolds wrote:
Uttered "Paul W. Frields" stickster@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:
- 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.
- 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? ;)