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.

Reply via email to