Created attachment 58908 [details]
Test case based on the app template.

Try adding <para> tags in the blockquotes:

<blockquote><para>An example of a <link linkend="docbook-extip">tip</link> was given.</para></blockquote>

Not sure whether this is actually a bug or whether its a docbook thing ;) - can someone clarify?

Perhaps I'm trying to use blockquote in a place it shouldn't be used.

The context of this problem is the file gnome-docu/gdp/gdp-handbook/docbook.xml
In the section 'Links and References', there are examples of DocBook markup and the text they produce.
The example markup is a programlisting element, within the para.
The example result was inline text, which I sought to separate from the body text.

blockquote is perhaps wrong for this, but screen produces a box with horizontal scroll, and computeroutput doesn't do anything at all.

If you're showing block-level examples of DocBook markup, you should be using programlisting.  The name "programlisting" is unfortunate, seemingly indicating that it's only useful for "programs".  And hey, maybe that's how some DocBook consumers treat it.  But my stance is that you should use programlisting for any block of text following some syntax.

So the blockquote thing isn't actually a bug, now that I've double-checked.  The blockquote element is supposed to hold other block-level stuff.  Typically, you'll just put a para element inside it.  What's causing the behavior you see is a line like this:

select="*[name(.) != 'title' and name(.) != 'attribution']"

That won't select text nodes.  And to be fair, text nodes shouldn't be there.  But I do have a general stance of being lenient in the stylesheets, so we could easily change this to

select="node()[name(.) != 'title' and name(.) != 'attribution']"

That will select text nodes.

(In reply to comment #4)
> If you're showing block-level examples of DocBook markup, you should be using
> programlisting.  The name "programlisting" is unfortunate, seemingly indicating
> that it's only useful for "programs".  And hey, maybe that's how some DocBook
> consumers treat it.  But my stance is that you should use programlisting for
> any block of text following some syntax.

The bit in question is output rather than input, so it's not actually following syntax. It's just display text, what you might see on the screen. It's also not wrapping, which makes it scroll horizontally and looks odd. There's 'computeroutput' in DocBook, but yelp does nothing with it. And that would probably not wrap either.

But I'm going off-topic a bit here, and I agree that the original report is not a bug.

Colsing as NOTABUG then.