Mark Fletcher wrote:
> If an @href is to be shown, I would think it should be the @href of the
> target element. Can this be fixed?
This is already the case, unless the source of the conref has its own
href attribute. Example:
[1] Source topicref is
<topicref href="foo.dita"/>
[2] Set its conref attribute to "bar.ditamap#x/y", where
"bar.ditamap#x/y" is
<topicref id="y" href="gee.dita"/>
[3] XXE transcludes <topicref href="foo.dita"/> but you'll still see in
XXE href="foo.dita" as CSS generated content.
This is the correct behavior[*]: a topicref which is the source of the
conref must not have an href attribute because this href attribute would
``have priority'' over the href attribute of the conref target.
> Which leads to a question. I've tried overriding the selector that
> provides this content (topicref:before) with this one:
>
> topicref[conref]:before {
> content: "";
> }
>
> but it's never used. Is there something peculiar about how the @conref
> attribute is handled by CSS?
>
A topicref having a conref attribute is immediately transcluded (i.e. at
document load time). The transcluded topicref no longer has a conref
attribute and therefore the above CSS rule cannot be applied. Once
again, this is the correct behavior[*].
---
[*] Ask the DITA gurus! we've just ``reverse-engineered'' the DITA OT
1.2.2 XSLT style sheets which handle transclusion.