docbook-apps

Hi, sorry if this is a repeat message, I sent it a few hours ago and I still haven’t seen it on the list yet.
—————
Hello, I have a user guide that I am adding new features to and I want to signal the new content with a background color (like a light green or something like that).

Since all of the content for this feature is profiled with the “revision” attribute, I thought a smart way to do this would be to send the revision value through as a class and then add a css rule for the class, such as:

.feature-x {
background-color: green;
}

I think I should modify this template here:

<xsl:template match="*" mode="common.html.attributes">
<xsl:param name="class" select="local-name(.)"/>
<xsl:param name="inherit" select="0"/>
<xsl:call-template name="generate.html.lang"/>
<xsl:call-template name="dir">
<xsl:with-param name="inherit" select="$inherit"/>
</xsl:call-template>
<xsl:apply-templates select="." mode="class.attribute">
<xsl:with-param name="class" select="$class"/>
</xsl:apply-templates>
<xsl:call-template name="generate.html.title"/>
</xsl:template>


But I can’t seem to figure out what to put there that works for profiled and non-profiled content without stripping the actual class value that should be there.


Am I thinking about this the right way, or is there an even easier wa to do what I want to accomplish?


Thanks a bunch in advance,


Eric

Hi Eric,
Take a look at this doc, which describes how to use mode="class.value"
to generate custom class attribute values:

http://www.sagehill.net/docbookxsl/HtmlCustomEx.html#CustomClassValues

In your case, you would want to add a custom template starting with:

<xsl:template match="*[@revision]" mode="class.value">

and instead of just outputting the $class template param, you could add
the value of @revision.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net

On 3/18/2014 4:54 PM, Nordlund, Eric wrote:
> Hi, sorry if this is a repeat message, I sent it a few hours ago and I still haven’t seen it on the list yet.
> —————
> Hello, I have a user guide that I am adding new features to and I want to signal the new content with a background color (like a light green or something like that).
>
> Since all of the content for this feature is profiled with the “revision” attribute, I thought a smart way to do this would be to send the revision value through as a class and then add a css rule for the class, such as:
>
> .feature-x {
> background-color: green;
> }
>
> I think I should modify this template here:
>
> <xsl:template match="*" mode="common.html.attributes">
> <xsl:param name="class" select="local-name(.)"/>
> <xsl:param name="inherit" select="0"/>
> <xsl:call-template name="generate.html.lang"/>
> <xsl:call-template name="dir">
> <xsl:with-param name="inherit" select="$inherit"/>
> </xsl:call-template>
> <xsl:apply-templates select="." mode="class.attribute">
> <xsl:with-param name="class" select="$class"/>
> </xsl:apply-templates>
> <xsl:call-template name="generate.html.title"/>
> </xsl:template>
>
>
> But I can’t seem to figure out what to put there that works for profiled and non-profiled content without stripping the actual class value that should be there.
>
>
> Am I thinking about this the right way, or is there an even easier wa to do what I want to accomplish?
>
>
> Thanks a bunch in advance,
>
>
> Eric
>

<xsl:template match="*[@revision]" mode="class.value">
<xsl:value-of select="@revision"/>
</xsl:template>

Thanks Bob, this seemed to work a little, but I think it only applies my class to elements that would have already had one in the first place. Paragraphs, spans, and who knows what else completely ignore it. Also, it deletes the class attribute that would have been there for the element.

So, I tried this:


<xsl:template match="*[@revision]" mode="class.value">
<xsl:param name="class" select="concat(local-name(.), ' ', @revision)"/>


<xsl:value-of select="$class"/>
</xsl:template>

This I would have thought would concatenate the local-name and the revision, but it doesn’t seem to do anything. Maybe my xpath statement isn’t allowed in the xsl:param statement?

So, I again tried this xpath in the class.attribute template:


<xsl:template match="*[@revision]" mode="class.attribute">
<xsl:param name="class" select="local-name(.)"/>


<xsl:attribute name="class">
<xsl:apply-templates select="." mode="class.value">
<xsl:with-param name="class" select="concat($class, ' ', @revision)"/>
</xsl:apply-templates>
</xsl:attribute>
</xsl:template>

This one keeps my original classes and just adds the @revision value (how come my xpath statement works now?), but again, it only works on elements that call the class.attribute mode, which many elements do not.

Furthermore, It seems like many of the templates ignore the class.value mode and just set the class to local-name(.) anyways (common.html.attributes does this for a lot of templates).

Any ideas on how to get this to work?

Eric

On 3/19/14, 9:44 AM, "Bob Stayton" <bobs@sagehill.net<mailto:bobs@sagehill.net>> wrote:

Hi Eric,
Take a look at this doc, which describes how to use mode="class.value"
to generate custom class attribute values:

http://www.sagehill.net/docbookxsl/HtmlCustomEx.html#CustomClassValues

In your case, you would want to add a custom template starting with:

<xsl:template match="*[@revision]" mode="class.value">

and instead of just outputting the $class template param, you could add
the value of @revision.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net<mailto:bobs@sagehill.net>

On 3/18/2014 4:54 PM, Nordlund, Eric wrote:
Hi, sorry if this is a repeat message, I sent it a few hours ago and I still haven’t seen it on the list yet.
—————
Hello, I have a user guide that I am adding new features to and I want to signal the new content with a background color (like a light green or something like that).

Since all of the content for this feature is profiled with the “revision” attribute, I thought a smart way to do this would be to send the revision value through as a class and then add a css rule for the class, such as:

.feature-x {
background-color: green;
}

I think I should modify this template here:

<xsl:template match="*" mode="common.html.attributes">
<xsl:param name="class" select="local-name(.)"/>
<xsl:param name="inherit" select="0"/>
<xsl:call-template name="generate.html.lang"/>
<xsl:call-template name="dir">
<xsl:with-param name="inherit" select="$inherit"/>
</xsl:call-template>
<xsl:apply-templates select="." mode="class.attribute">
<xsl:with-param name="class" select="$class"/>
</xsl:apply-templates>
<xsl:call-template name="generate.html.title"/>
</xsl:template>


But I can’t seem to figure out what to put there that works for profiled and non-profiled content without stripping the actual class value that should be there.


Am I thinking about this the right way, or is there an even easier wa to do what I want to accomplish?


Thanks a bunch in advance,


Eric

Hi Eric,
First I need to clear up one misconception. An xsl:param element at the
start of a template sets the *default* value of the param, and is used
only if that param is not already set to some value by the calling of
the template. That template is almost always applied with the class
param set to local-name(.), usually set in the 'common.html.attributes'
template. That's why this does not work:

<xsl:template match="*[@revision]" mode="class.value">
<xsl:param name="class" select="concat(local-name(.), ' ', @revision)"/>

While testing my custom template, I noticed that for para, I was only
getting the revision value, not "para" as the default class. It turns
out there is a bug/feature in the template named "paragraph" in
html/block.xsl (called by the match="para" template) that sets the class
to empty if the @role is not set. That empty value is passed as the
param to mode="class.value". Even though it is empty, it counts as the
param value and overrides the default xsl:param in the template.

I don't know why the default class for <para> is empty. Maybe someone
thought

was redundant as far as CSS coding goes, but I
don't think so because

can be generated by many elements besides
<para>.

Anyway, for your custom template, I would suggest not using the "class"
param, but instead create your own xsl:variable for the local-name and
use that:

<xsl:template match="*[@revision]" mode="class.value">
<xsl:param name="class"/>

<xsl:variable name="myclass" select="local-name(.)"/>

<xsl:value-of select="concat($myclass, ' ', @revision)"/>

</xsl:template>

That should work for para and all other cases. Let me know if there are
still elements that don't work, as there may be other exceptions in the
stylesheet.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net

On 3/19/2014 5:19 PM, Nordlund, Eric wrote:
> <xsl:template match="*[@revision]" mode="class.value">
> <xsl:value-of select="@revision"/>
> </xsl:template>
>
> Thanks Bob, this seemed to work a little, but I think it only applies my class to elements that would have already had one in the first place. Paragraphs, spans, and who knows what else completely ignore it. Also, it deletes the class attribute that would have been there for the element.
>
> So, I tried this:
>
>
> <xsl:template match="*[@revision]" mode="class.value">
> <xsl:param name="class" select="concat(local-name(.), ' ', @revision)"/>
>
>
> <xsl:value-of select="$class"/>
> </xsl:template>
>
> This I would have thought would concatenate the local-name and the revision, but it doesn’t seem to do anything. Maybe my xpath statement isn’t allowed in the xsl:param statement?
>
> So, I again tried this xpath in the class.attribute template:
>
>
> <xsl:template match="*[@revision]" mode="class.attribute">
> <xsl:param name="class" select="local-name(.)"/>
>
>
> <xsl:attribute name="class">
> <xsl:apply-templates select="." mode="class.value">
> <xsl:with-param name="class" select="concat($class, ' ', @revision)"/>
> </xsl:apply-templates>
> </xsl:attribute>
> </xsl:template>
>
> This one keeps my original classes and just adds the @revision value (how come my xpath statement works now?), but again, it only works on elements that call the class.attribute mode, which many elements do not.
>
> Furthermore, It seems like many of the templates ignore the class.value mode and just set the class to local-name(.) anyways (common.html.attributes does this for a lot of templates).
>
> Any ideas on how to get this to work?
>
> Eric
>
> On 3/19/14, 9:44 AM, "Bob Stayton" <bobs@sagehill.net<mailto:bobs@sagehill.net>> wrote:
>
> Hi Eric,
> Take a look at this doc, which describes how to use mode="class.value"
> to generate custom class attribute values:
>
> http://www.sagehill.net/docbookxsl/HtmlCustomEx.html#CustomClassValues
>
> In your case, you would want to add a custom template starting with:
>
> <xsl:template match="*[@revision]" mode="class.value">
>
> and instead of just outputting the $class template param, you could add
> the value of @revision.
>
> Bob Stayton
> Sagehill Enterprises
> bobs@sagehill.net<mailto:bobs@sagehill.net>
>
> On 3/18/2014 4:54 PM, Nordlund, Eric wrote:
> Hi, sorry if this is a repeat message, I sent it a few hours ago and I still haven’t seen it on the list yet.
> —————
> Hello, I have a user guide that I am adding new features to and I want to signal the new content with a background color (like a light green or something like that).
>
> Since all of the content for this feature is profiled with the “revision” attribute, I thought a smart way to do this would be to send the revision value through as a class and then add a css rule for the class, such as:
>
> .feature-x {
> background-color: green;
> }
>
> I think I should modify this template here:
>
> <xsl:template match="*" mode="common.html.attributes">
> <xsl:param name="class" select="local-name(.)"/>
> <xsl:param name="inherit" select="0"/>
> <xsl:call-template name="generate.html.lang"/>
> <xsl:call-template name="dir">
> <xsl:with-param name="inherit" select="$inherit"/>
> </xsl:call-template>
> <xsl:apply-templates select="." mode="class.attribute">
> <xsl:with-param name="class" select="$class"/>
> </xsl:apply-templates>
> <xsl:call-template name="generate.html.title"/>
> </xsl:template>
>
>
> But I can’t seem to figure out what to put there that works for profiled and non-profiled content without stripping the actual class value that should be there.
>
>
> Am I thinking about this the right way, or is there an even easier wa to do what I want to accomplish?
>
>
> Thanks a bunch in advance,
>
>
> Eric
>
>
>

On 03/18/2014 06:54 PM, Nordlund, Eric wrote:
> Hi, sorry if this is a repeat message, I sent it a few hours ago and I
> still haven’t seen it on the list yet.

Hi Eric,
One approach would be to match text nodes that have an ancestor with the
desired attribute. The following example adds a
around all text that has an ancestor element with role="highlight". I
then use css to add the yellow highlight to .remark:

<xsl:template match="text()[ ancestor::*/@role = 'highlight' and
not(ancestor::d:programlisting) ] | xref[ ancestor::*/@role =
'highlight' and not(ancestor::d:programlisting)]" priority="10">class="remark"><xsl:apply-imports/></xsl:template>

You would add this to your customization layer.

This can add a bunch of spans, but does the job without needing to muck
around in a bunch of templates.

Regards,
David

> —————
> Hello, I have a user guide that I am adding new features to and I want
> to signal the new content with a background color (like a light green or
> something like that).
>
> Since all of the content for this feature is profiled with the
> “revision” attribute, I thought a smart way to do this would be to send
> the revision value through as a class and then add a css rule for the
> class, such as:
>
> .feature-x {
> background-color: green;
> }
>
> I think I should modify this template here:
>
> <xsl:template match="*" mode="common.html.attributes">
> <xsl:param name="class" select="local-name(.)"/>
> <xsl:param name="inherit" select="0"/>
> <xsl:call-template name="generate.html.lang"/>
> <xsl:call-template name="dir">
> <xsl:with-param name="inherit" select="$inherit"/>
> </xsl:call-template>
> <xsl:apply-templates select="." mode="class.attribute">
> <xsl:with-param name="class" select="$class"/>
> </xsl:apply-templates>
> <xsl:call-template name="generate.html.title"/>
> </xsl:template>
>
>
> But I can’t seem to figure out what to put there that works for profiled
> and non-profiled content without stripping the actual class value that
> should be there.
>
>
> Am I thinking about this the right way, or is there an even easier wa to
> do what I want to accomplish?
>
>
> Thanks a bunch in advance,
>
>
> Eric
>

I'm no expert, but I would have thought this would work (in the
customization layer):

<xsl:template match="d:*[@revision]" mode="class.value">
<xsl:value-of select="'feature-x'" />
</xsl:template>

--Tim



On Wed, Mar 19, 2014 at 3:31 PM, David Cramer <david@thingbag.net> wrote:

> On 03/18/2014 06:54 PM, Nordlund, Eric wrote:
> > Hi, sorry if this is a repeat message, I sent it a few hours ago and I
> > still haven't seen it on the list yet.
>
> Hi Eric,
> One approach would be to match text nodes that have an ancestor with the
> desired attribute. The following example adds a
> around all text that has an ancestor element with role="highlight". I
> then use css to add the yellow highlight to .remark:
>
> <xsl:template match="text()[ ancestor::*/@role = 'highlight' and
> not(ancestor::d:programlisting) ] | xref[ ancestor::*/@role =
> 'highlight' and not(ancestor::d:programlisting)]" priority="10">> class="remark"><xsl:apply-imports/></xsl:template>
>
> You would add this to your customization layer.
>
> This can add a bunch of spans, but does the job without needing to muck
> around in a bunch of templates.
>
> Regards,
> David
>
> > ----------
> > Hello, I have a user guide that I am adding new features to and I want
> > to signal the new content with a background color (like a light green or
> > something like that).
> >
> > Since all of the content for this feature is profiled with the
> > "revision" attribute, I thought a smart way to do this would be to send
> > the revision value through as a class and then add a css rule for the
> > class, such as:
> >
> > .feature-x {
> > background-color: green;
> > }
> >
> > I think I should modify this template here:
> >
> > <xsl:template match="*" mode="common.html.attributes">
> > <xsl:param name="class" select="local-name(.)"/>
> > <xsl:param name="inherit" select="0"/>
> > <xsl:call-template name="generate.html.lang"/>
> > <xsl:call-template name="dir">
> > <xsl:with-param name="inherit" select="$inherit"/>
> > </xsl:call-template>
> > <xsl:apply-templates select="." mode="class.attribute">
> > <xsl:with-param name="class" select="$class"/>
> > </xsl:apply-templates>
> > <xsl:call-template name="generate.html.title"/>
> > </xsl:template>
> >
> >
> > But I can't seem to figure out what to put there that works for profiled
> > and non-profiled content without stripping the actual class value that
> > should be there.
> >
> >
> > Am I thinking about this the right way, or is there an even easier wa to
> > do what I want to accomplish?
> >
> >
> > Thanks a bunch in advance,
> >
> >
> > Eric
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>