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

Bug#772963: release-notes: cellphone friendly CSS



Hi, Osamu,

[...]

Is there any chance to get access to the docbook-xml
(source) file, as a draft, at least?

[...]

> 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"/>

I guess you mean "stylesheet" when you refer to customization xslt file, don't
you? You usually use the <xsl:import> element, or even the <xsl:include> element
to use external rules and declarations in your base stylesheet.
I haven't checked it with docbook-xml, but in XML the reference to the
stylesheet is usually done via

<?xml-stylesheet type="text/xsl" href="[URI].xsl"?>

(at least when we talk about a client-based transformation)
By the way, in Debian-doc, is it done client-based or server-based (using php)?

> 
> 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.

Again, I haven't checked that issue with docbook5-xml yet (I understand that
"source of documentation" refers to the docbook-xml source), but in XSLT, in the
case of template rules having the same "match" attribute, the local template
rules, which are those declared in your base stylesheet, override the imported
ones. If you want to use the imported rules in addition to those declared in
your base stylesheet, you have to use <xsl:apply-imports/>.

[...]
> 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.

Yes, I agree to that.
> 
> 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.

Well, not to use tables as a layout element is laid down in (1), (2), (3), for
instance, and it reminds me of the early st(ages) of the web when everything was
done using tables. I guess, it's a question of authoring, not one of the
docbook-xml package, but I'm not quite sure about that.

Moreover, I have decided to use the fairly new docbook5-xml which differs
considerably from docbook-xml (4.xx), well, that's what the .doc says. I will
check the possibilities for XSLT processing and (X)HTML output generation
docbook5-xml ships with, and may suggest a way for getting rid of too much
tables, or maybe not.

> 
> Osamu
> 

(1)http://www.w3.org/TR/2009/NOTE-mwbp-guidelines-20091020/ CH. 3.28
(2) http://www.w3.org/TR/2008/REC-mobileOK-basic10-tests-20081208/ Chs. 3.22, 3.23
(3) http://css4you.de (German)


Stephan



Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: