[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: re: [docbook-apps] Accessibility: adding scope attribute to HTML output
Hi Michael,Understanding modes would best be accomplished by studying a good book on XSLT, so a short answer in an email message may not help much, but here goes.
Modes are used to process your document in different ways for different purposes. In DocBook XSL, the main set of templates is used to generate the actual HTML or FO output. The stylesheet uses other modes to process the same input but generate different output. It uses a mode to generate the table of contents, for example, where it processes the entire document all over again but producing different output, in this case the table of contents listing.
You can think of each mode as a different channel through which you can process your elements. Each channel has its own set of templates that can do different things to the elements it sees in order to perform different functions. Some channels do simple things like just extracting the title of an element (mode="title.markup" in DocBook XSL), and others do more complex things such as generating a table of contents for the element it processes (mode="toc"). Templates outside the current channel are ignored, otherwise things would get really scrambled.
<xsl:apply-templates mode="foo"/> is the instruction that starts you down a channel (mode). The processor will consider only instructions like <xsl:template match="some-element" mode="foo"> that have a matching mode attribute to apply to the children of the current element.
<xsl:apply-templates/> without a mode attribute is really just the "nameless" mode, the channel that includes all templates without a mode attribute. In this channel, all templates that have a mode attribute are ignored, because no mode="somename" can match an empty mode name.
Some templates with a named mode are written continue down the hierarchy of elements also by applying templates in the same mode. The mode="toc" is a good example. Each template with <xsl:template match="some-element" mode="foo"> contains a <xsl:apply-templates mode="foo"/> so the children of <some-element> are also processed in the same channel. That way the entire document's hierarchy is included in the TOC.
A template in one mode can also apply templates in a different mode to "jump channels", so to speak. That's how the "nameless" mode main channel manages to generate a table of contents, by switching to the "toc" mode using <xsl:apply-templates mode="toc"/> on the top level element. One common mistake is to be in a template with mode="foo" and use <xsl:apply-templates/>, assuming you will stay in the same mode. Nope, that jumps to the nameless mode.
I also learned early on that <xsl:apply-templates/> really means <xsl:apply-template/> (singular), because for each element being processed, the processor applies only one template among those that match. It works to find the single best match, based on import precedence, XPath rules and any optional "priority" attributes.
If the processor cannot find any template in the specified mode that matches the element, it falls back to the default template,which is to just take the string value of the element. That happens regardless of the mode. So the processor never automatically says "sorry, there is no template in that mode for that element". If you want such a message, you have to write such a template as:
<xsl:template match="*" mode="foo"> <xsl:message>Sorry, ... </xsl:template>which is what Docbook XSL sometimes does. That means if no other template matches on the current element in the specified mode, it falls back to this match="*" and offers the message, giving you a clue that some element is not being handled as expected.
So to answer your last question: --------------------------------------------- One more question about modes. If I add the following to my HTML customization layer: <xsl:template match="section" mode="class.attribute"> <xsl:attribute name="scope">col</xsl:attribute> </xsl:template>Is this template used in addition to any existing match="section" templates, or instead of any existing match="section" templates.
Or do I need a <xsl:call-template> to activate the mode template? ------------------------------------------------Your template is not used "in addition to" the template in nameless mode. Only one template is selected each time, and only from among those with that mode name. The <xsl:template match="section"> in the nameless mode would not be considered because it does not match the mode name.
The <xsl:call-template> can only be used to access templates with a name attribute. Any templates without a name attribute cannot be accessed with <xsl:call-template>. And you cannot call a mode with xsl:call-template.
The only way to activate a mode="class.attribute" template is for some other template to use <xsl:apply-templates mode="class.attribute"/>. Most of the main (nameless mode) templates in DocBook XSL do that. That's the bug here: the main template for para fails to do <xsl:apply-templates mode="class.attribute"/> in the case where there is no role attribute, and does it only when there is a role attribute.
The reason Robert Nagle's template worked for him is because he *was* using a role attribute on the para, but in his case it was to specifiy the width value. Your para elements did not have a role attribute, and so you encountered that bug.
Don't worry about the bug report. I'll go ahead and file it since I'll probably be the one fixing it. 8^)
Bob Stayton Sagehill Enterprises bobs@sagehill.net----- Original Message ----- From: "michael mclaughlin" <m_mclaug@yahoo.co.uk>
To: <docbook-apps@lists.oasis-open.org>; "Bob Stayton" <bobs@sagehill.net> Sent: Monday, September 26, 2011 4:57 AM Subject: Re: re: [docbook-apps] Accessibility: adding scope attribute to HTML outputI don't really understand modes well enough to post a bug about this. Its one of the few sections in your book that I can't follow.
I think you are saying that using modes to add an attribute to para or entry only works in the case where the element already has an existing role attribute setting?
However, Robert Nagle reported success for caption/para elements in this post: http://lists.oasis-open.org/archives/docbook-apps/201108/msg00091.html BTW, this line in your template does nothing useful.
<xsl:param name="width"
select="local-name(.)"/>
OK. It looks like this line is used to output a class element. Something I don't need for my problem.
One more question about modes. If I add the following to my HTML customization layer: <xsl:template match="section" mode="class.attribute"> <xsl:attribute name="scope">col</xsl:attribute> </xsl:template>Is this template used in addition to any existing match="section" templates, or instead of any existing match="section" templates.
Or do I need a <xsl:call-template> to activate the mode template? --- On Fri, 23/9/11, Bob Stayton <bobs@sagehill.net> wrote:
From: Bob Stayton <bobs@sagehill.net> Subject: Re: re: [docbook-apps] Accessibility: adding scope attribute to HTML output To: "mike 675" <m_mclaug@yahoo.co.uk>, docbook-apps@lists.oasis-open.org Date: Friday, 23 September, 2011, 22:03 Hi Mike, It seems that the para element is an exception for using that mode because it also has the feature of passing along a role attribute as a class attribute. If the para in question has a role attribute (of any value) and the $para.propagates.style is set to 1 (the default), then your template will work. The mode is not used otherwise. I think this is a bit of inconsistent behavior that should be looked at more closely by the developers. Could you please file a bug report on the SourceForge site to get this straightened out? The entry element has the same story, since it also has an $entry.propagates.style attribute. It did work for match="section" when I tried it, adding the width attribute to the section's div element in the output. BTW, this line in your template does nothing useful. <xsl:param name="width" select="local-name(.)"/> It creates a template parameter but never uses it. Setting width to a value of "section" is not a valid value. I think you modeled it on the class param where a value of "section" does make sense as a default. Bob Stayton Sagehill Enterprises bobs@sagehill.net----- Original Message ----- From: "mike 675" <m_mclaug@yahoo.co.uk>To: <docbook-apps@lists.oasis-open.org> Sent: Wednesday, September 21, 2011 1:28 AM Subject: Re: re: [docbook-apps] Accessibility: adding scope attribute to HTML output > > I can't seem to get this working consistently. > > I would expect the following customization to change all <para> elements to > <p width="50px"> in the HTML output. > But it has no effect. > > <xsl:template match="para" mode="class.attribute"> > <xsl:param name="width" select="local-name(.)"/> > <xsl:attribute name="width">50px</xsl:attribute> > </xsl:template> > > Neither does using "section" as the match. > Nor informaltable/tgroup/thead/row/entry, which is one of the elements I > want to change. > However, if I match for "itemizedlist", 50px turns up in the <ul> HTML > element. > > Is it OK to use a simple xpath, such as "section" for matching elements? > > > Robert Nagle wrote: >> >> 1. Yes, all you have to do is add it to your customization layer. You >> will need to replace caption/para with an xpath statement that >> corresponds to the table element(s) you want to customize. (and >> remember if you are not using the vanilla docbook xsl but the >> namespace xsl (i.e., docbook-ns), you will need to preface everything >> with d: in the xpath statement. So caption/para would be >> d:caption/d:para ). >> >> 2. For my example at >> http://lists.oasis-open.org/archives/docbook-apps/201108/msg00091.html >> , my source code would say either: >> >> <caption> <para> Hello </para> </caption> >> >> Or >> >> <caption> <para role="50x"> Hello </para> <caption> >> >> Your output after you applied the transformation would be (I think) >> >> <div class="caption"> >> <p width="50px">Hello </p></div> >> >> I gave two examples. In one example I made the assumption that you >> would hardcode the values of width in the XSL customization layer -- >> so you wouldn't need to put it in the xml source code. In the other >> example, I assumed that you would grab the values from the role >> attribute in the <para> element in source. >> >> However, if the value of the scope attribute is always going to be >> "col", I don't see any reason why you couldn't hard code it in the XSL >> customization layer. others may disagree about this. >>>> -- >> ---------- Forwarded message ---------->> From: mike 675 <m_mclaug@yahoo.co.uk> >> To: docbook-apps@lists.oasis-open.org >> Date: Mon, 19 Sep 2011 01:58:03 -0700 (PDT) >> Subject: [docbook-apps] Accessibility: adding scope attribute to HTML >> output >> >> To meet accessibility requirements, we need to add the scope attribute to >> the >> HTML output for our tables. >> >> Our tables are marked up in DocBook XML, CALS style. >> >> Every <th> needs to be <th scope="col"> >> >> The first <td> in a <tr> needs to be <td scope="row"> >> >> Any ideas on where to start on this. >> I guess I need to cusomize the html/table.xsl stylesheet. >> >> >> >> >> Robert Nagle >> 6121 Winsome Ln #56C, Houston TX 77057-5581 >> (H) 713 893 3424/ (W) 832-251-7522 Carbon Neutral Since Jan 2010 >> http://www.robertnagle.info >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org >> >> >> >> -- > View this message in context:> http://old.nabble.com/Accessibility%3A-adding-scope-attribute-to-HTML-output-tp32493408p32503723.html > Sent from the docbook apps mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]