[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#772963: release-notes: cellphone friendly CSS



Hi,

On Tue, Feb 10, 2015 at 09:40:20PM +0100, Niels Thykier wrote:
> On 2015-02-10 21:08, Stéphane Blondon wrote:
> > 2015-02-05 23:23 GMT+01:00 Stephan Beck <sbeck@mailbox.org>:
> >> The first quick and dirty solution (only touching the .html file) is to suppress
> >> the second table row in the.html file.
> > 
> > The solution I provided is CSS only. If we need to change the HTML, I
> > think your second solution (removing the table) is a better one.
> >
> >> A second solution I'll work on is to replace the table with a
> >> "div id="navfooter" containing a nav element that includes anchors and images.
> >> I think it's better to use "table" only for "real" tables, not as a space
> >> structuring design element. This solution will imply changes to the .css.
> > 
> > I agree. Replacing the table (by a list for example) is a better
> > solution. I don't know how much the maintainers are ready to change
> > the rendering.
> > [...]
> 
> The main problem with changing the HTML is that it is mostly generated
> beyond our control. 

I would not say this but I agree customizing auto-generated HTML is not
for the faint hearted (including myself.)

> So far I managed to extend the existing HTML using
> "supported" hooks for the given cases, but I fear this table might not
> have such a hook.

That is what I usually do and stop.

> Provided there is a decent maintainer solution, I am happy to accept it.
>  I just do not want to end up maintaining a custom "XML -> XHTML"
> transformation only used by us (or a "handwritten HTML-post processor
> for fixing style issues").

Basically, any part of HTML generation definitions in the packaged
conversion scheme can be overridden by the user.

Normal customization xslt file in the source of documentation starts off
like:
... after some standard lines ...
<!-- Import our base stylesheet -->
<xsl:import href="file:///usr/share/xml/docbook/stylesheet/docbook-xsl/xhtml-1_1/chunk.xsl"/>

let's see it.

It import chunk-common.xsl which seems to be the one making <div>,
<table>, etc.

All you need is to create a customized chunk-common.xsl and import it to
your customization xslt file in the source of documentation before
chunk.xsl so the customized definition wins over default one.

If this approach does not work, you replace import line in your
customization xslt file with chunk.xsl file content and change its
import chunk-common.xsl line pointing to your customized definition.

I have not tried this but that is what I think possible.

But I think this is not something we should do for this late in the
freeze time.  Let's stick with simple CSS only fix for now.

Also, if Stephan Beck docbook-xml can be improved for its HTML,
submitting bug report to the upstream of docbook-xml may be good
idea.

Osamu


Reply to: