docbook-apps

Hello,

This is a two part question.

1. When I create chunked XHTML my tags do not seem to
translate to XHTML. The ID are missing, and the links don't work. Is there a
way to solve this without changing the way I link items in DocBook?

2. In every part of my chunked document the text reacts to any "hovering" of
the mouse. This should not happen, not all of the text is a link.

Here is a sample of the output XHTML code:

Lillian,
Regarding question #2, my team ran into this same problem last week and found it only occurred in Firefox 3.x (not in Firefox 2.x and not in IE-we didn't check other browsers). Part of the problem is that Firefox 3.x expects *valid* XHTML (while earlier versions didn't). And, I guess the XHTML output from DocBook (using Saxon 6.5.5, at least) is not valid XHTML with respect to closing anchor tags. Our quick fix was to switch to outputting HTML instead of XHTML. A co-worker who investigated this problem says there's an add-on for Saxon that makes it generate XHTML, but I don't know much beyond that.

HTH!
cheri


From: Lillian Sullam [mailto:lsullam@bruxton.com]
Sent: Wednesday, October 01, 2008 2:59 PM
To: docbook-apps@lists.oasis-open.org
Subject: [docbook-apps] in XHTML output

Hello,

This is a two part question.

1. When I create chunked XHTML my tags do not seem to translate to XHTML. The ID are missing, and the links don't work. Is there a way to solve this without changing the way I link items in DocBook?

2. In every part of my chunked document the text reacts to any "hovering" of the mouse. This should not happen, not all of the text is a link.

Here is a sample of the output XHTML code:

2008/10/1 Lillian Sullam <lsullam@bruxton.com>:
> 2. In every part of my chunked document the text reacts to any "hovering" of
> the mouse. This should not happen, not all of the text is a link.
[...]
> I have a feeling this has to do with the tag being closed with a "/"
> instead of , but why is this happening?

I think you're right, and you'll see the behaviour you describe if
your browser is interpreting the file as plain HTML rather than XHTML.
In plain HTML the closing tag is mandatory, and I guess the
browser is treating the

Andy Smith <andy.docbook@zambezi.org.uk>, 2008-10-02 06:49 +0100:

> 2008/10/1 Lillian Sullam <lsullam@bruxton.com>:
> > 2. In every part of my chunked document the text reacts to any "hovering" of
> > the mouse. This should not happen, not all of the text is a link.
> [...]
> > I have a feeling this has to do with the tag being closed with a "/"
> > instead of , but why is this happening?
>
> I think you're right, and you'll see the behaviour you describe if
> your browser is interpreting the file as plain HTML rather than XHTML.
> In plain HTML the closing tag is mandatory, and I guess the
> browser is treating the

Ian Hicks' name appears as co-author on several W3 standards. His
enlightening discussion <http://www.hixie.ch/advocacy/xhtml> of the perils
of serving XHTML to browsers (notably IE) that don't handle it persuaded me
to prefer serving HTML:
http://www.hixie.ch/advocacy/xhtml

Stephen



2008/10/2 Michael(tm) Smith <smith@sideshowbarker.net>

> Andy Smith <andy.docbook@zambezi.org.uk>, 2008-10-02 06:49 +0100:
>
> > 2008/10/1 Lillian Sullam <lsullam@bruxton.com>:
> > > 2. In every part of my chunked document the text reacts to any
> "hovering" of
> > > the mouse. This should not happen, not all of the text is a link.
> > [...]
> > > I have a feeling this has to do with the tag being closed with a
> "/"
> > > instead of , but why is this happening?
> >
> > I think you're right, and you'll see the behaviour you describe if
> > your browser is interpreting the file as plain HTML rather than XHTML.
> > In plain HTML the closing tag is mandatory, and I guess the
> > browser is treating the

You may also be able to get around the problem using a[href]{} in your
css instead of just a{}:
http://article.gmane.org/gmane.text.docbook.apps/19015/

David


>
Original Message-----
> From: Michael(tm) Smith [mailto:smith@sideshowbarker.net]
> Sent: Thursday, October 02, 2008 2:21 AM
> To: Andy Smith
> Cc: DocBook Apps
> Subject: Re: [docbook-apps] in XHTML output
>
> Andy Smith <andy.docbook@zambezi.org.uk>, 2008-10-02 06:49 +0100:
>
> > 2008/10/1 Lillian Sullam <lsullam@bruxton.com>:
> > > 2. In every part of my chunked document the text reacts to any
> > > "hovering" of the mouse. This should not happen, not all
> of the text is a link.
> > [...]
> > > I have a feeling this has to do with the tag being
> closed with a "/"
> > > instead of , but why is this happening?
> >
> > I think you're right, and you'll see the behaviour you describe if
> > your browser is interpreting the file as plain HTML rather
> than XHTML.
> > In plain HTML the closing tag is mandatory, and I guess the
> > browser is treating the

David Cramer <dcramer@motive.com>, 2008-10-02 09:13 -0500:

> You may also be able to get around the problem using a[href]{} in your
> css instead of just a{}:
> http://article.gmane.org/gmane.text.docbook.apps/19015/

That reminds me: Wasn't there some discussion a while back about
the DocBook Project revising the stylesheets so that they never
output a@name at all? I think all browsers in wide use today
understand @id just fine and don't need a@name. Or is there some
other reason for keeping the a@name stuff that I'm missing?

--Mike

> >
Original Message-----
> > From: Michael(tm) Smith [mailto:smith@sideshowbarker.net]
> > Sent: Thursday, October 02, 2008 2:21 AM
> > To: Andy Smith
> > Cc: DocBook Apps
> > Subject: Re: [docbook-apps] in XHTML output
> >
> > Andy Smith <andy.docbook@zambezi.org.uk>, 2008-10-02 06:49 +0100:
> >
> > > 2008/10/1 Lillian Sullam <lsullam@bruxton.com>:
> > > > 2. In every part of my chunked document the text reacts to any
> > > > "hovering" of the mouse. This should not happen, not all
> > of the text is a link.
> > > [...]
> > > > I have a feeling this has to do with the tag being
> > closed with a "/"
> > > > instead of , but why is this happening?
> > >
> > > I think you're right, and you'll see the behaviour you describe if
> > > your browser is interpreting the file as plain HTML rather
> > than XHTML.
> > > In plain HTML the closing tag is mandatory, and I guess the
> > > browser is treating the

Michael(tm) Smith wrote:

> That reminds me: Wasn't there some discussion a while back about
> the DocBook Project revising the stylesheets so that they never
> output a@name at all? I think all browsers in wide use today
> understand @id just fine and don't need a@name. Or is there some
> other reason for keeping the a@name stuff that I'm missing?

If you are delivering your HTML generated from DocBook to QNX operating
system @id is of no use ;-)

Not very common case, but I few months ago I did very extensive
customization of stylesheet to output very small HTML subset supported
on that operating system.

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Jirka Kosek <jirka@kosek.cz>, 2008-10-02 17:08 +0200:

> Michael(tm) Smith wrote:
>
> > That reminds me: Wasn't there some discussion a while back about
> > the DocBook Project revising the stylesheets so that they never
> > output a@name at all? I think all browsers in wide use today
> > understand @id just fine and don't need a@name. Or is there some
> > other reason for keeping the a@name stuff that I'm missing?
>
> If you are delivering your HTML generated from DocBook to QNX operating
> system @id is of no use ;-)
>
> Not very common case, but I few months ago I did very extensive
> customization of stylesheet to output very small HTML subset supported
> on that operating system.

To me, that would suggest we make the a@name output a user option,
but change the default to be to not to output it anymore.

--Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

>
Original Message-----
> From: Michael(tm) Smith [mailto:smith@sideshowbarker.net]
> Sent: Thursday, October 02, 2008 10:55 AM
> To: Jirka Kosek
> Cc: David Cramer; DocBook Apps
> Subject: Re: [docbook-apps] Ripping out a@name generating
> code from thestylesheets [was: in XHTML output]
>
> Jirka Kosek <jirka@kosek.cz>, 2008-10-02 17:08 +0200:
>
> > Michael(tm) Smith wrote:
> >
> > > That reminds me: Wasn't there some discussion a while
> back about the
> > > DocBook Project revising the stylesheets so that they
> never output
> > > a@name at all? I think all browsers in wide use today
> understand @id
> > > just fine and don't need a@name. Or is there some other
> reason for
> > > keeping the a@name stuff that I'm missing?
> >
> > If you are delivering your HTML generated from DocBook to QNX
> > operating system @id is of no use ;-)
> >
> > Not very common case, but I few months ago I did very extensive
> > customization of stylesheet to output very small HTML
> subset supported
> > on that operating system.
>
> To me, that would suggest we make the a@name output a user
> option, but change the default to be to not to output it anymore.
>
> --Mike

Elsewhere in the thread I mentioned previously, Brett Leber had asked
about dropping a@name:

http://thread.gmane.org/gmane.text.docbook.apps/18971/focus=19025

He links to an article on the subject, but that site is down for me. In
his post, he quotes from the article: "Note that Netscape 4 does not
properly support this, neither do some mobile browsers. In the case of
the latter, at least, we can expect them to add support for this in the
foreseeable future, whereas those who still have to support Netscape 4
will be less fortunate."

David

David Cramer <dcramer@motive.com>, 2008-10-02 11:09 -0500:

> Elsewhere in the thread I mentioned previously, Brett Leber had asked
> about dropping a@name:
>
> http://thread.gmane.org/gmane.text.docbook.apps/18971/focus=19025
>
> He links to an article on the subject, but that site is down for me. In
> his post, he quotes from the article: "Note that Netscape 4 does not
> properly support this, neither do some mobile browsers. In the case of
> the latter, at least, we can expect them to add support for this in the
> foreseeable future, whereas those who still have to support Netscape 4
> will be less fortunate."

I guess I would wonder how many people really still have to
support Netscape 4. And I would suspect that mobile browsers that
don't support addressing of @id as a fragment identifier are
likely to run into a number of other problems displaying content
generated from stylesheets (since we've never put any other
consideration into whether output from them will be usable in
low-end/legacy mobile browsers).

--Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

Michael(tm) Smith wrote:

> To me, that would suggest we make the a@name output a user option,
> but change the default to be to not to output it anymore.

In principle I have nothing against going from a@name to @id. But is
this effort worth it (there are many places where IDs are generated)?
What are the benefits of using @id instead a@name except fractionally
shorter HTML code?

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Jirka Kosek wrote:

> In principle I have nothing against going from a@name to @id. But is
> this effort worth it (there are many places where IDs are generated)?
> What are the benefits of using @id instead a@name except fractionally
> shorter HTML code?

Just moving forward Jirka.
(And saving a few characters :-)

Low priority, but yes, I think its worth it.


regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Jirka Kosek <jirka@kosek.cz>, 2008-10-02 18:17 +0200:

> Michael(tm) Smith wrote:
>
> > To me, that would suggest we make the a@name output a user option,
> > but change the default to be to not to output it anymore.
>
> In principle I have nothing against going from a@name to @id. But is
> this effort worth it (there are many places where IDs are generated)?
> What are the benefits of using @id instead a@name except fractionally
> shorter HTML code?

For one, to help people avoid the problems they run into with
browsers when they serve documents as text/html that contain

2008/10/2 David Cramer <dcramer@motive.com>:
> You may also be able to get around the problem using a[href]{} in your
> css instead of just a{}:
> http://article.gmane.org/gmane.text.docbook.apps/19015/

Using "a:link" and "a:visited" (or just ":link" and ":visited") has
the same effect as "a[href]" but is more widely supported. The ":link"
and ":visited" pseudo-classes are part of CSS1 and as far as I know
all CSS browsers support them. Attribute selectors like "[href]" were
introduced in CSS2 and, as the message you linked says, aren't
supported by old versions of Internet Explorer and various other
browsers.

I forgot to mention in my previous message that if you want to style
all links you need to use both ":link" and ":visited" - ":link" only
affects unvisited links.

Andy

>
Original Message-----
> From: andy.m.smith@gmail.com [mailto:andy.m.smith@gmail.com]
> On Behalf Of Andy Smith
> Sent: Thursday, October 02, 2008 11:25 PM
> To: DocBook Apps
> Subject: Re: [docbook-apps] in XHTML output
>
> 2008/10/2 David Cramer <dcramer@motive.com>:
> > You may also be able to get around the problem using
> a[href]{} in your
> > css instead of just a{}:
> > http://article.gmane.org/gmane.text.docbook.apps/19015/
>
> Using "a:link" and "a:visited" (or just ":link" and
> ":visited") has the same effect as "a[href]" but is more
> widely supported. The ":link"
> and ":visited" pseudo-classes are part of CSS1 and as far as
> I know all CSS browsers support them. Attribute selectors
> like "[href]" were introduced in CSS2 and, as the message you
> linked says, aren't supported by old versions of Internet
> Explorer and various other browsers.
>
> I forgot to mention in my previous message that if you want
> to style all links you need to use both ":link" and
> ":visited" - ":link" only affects unvisited links.

Ok, so I guess the only problem left is a:hover. If the content contains
, then all the text after anchor gets the styling from
the a:hover. Or is there a way to make a:hover affect only links? But
this would only affect people who have to use a:hover and xhtml
together. If they can use the html output of the xsls, there's no
problem.

Thanks,
David

2008/10/3 David Cramer <dcramer@motive.com>:
> Or is there a way to make a:hover affect only links?

Yes, use "a:link:hover" and "a:visited:hover" (or just ":link:hover"
and ":visited:hover").

Andy

I didn't know you could combine them like that.

Thanks for the info,
David

>
Original Message-----
> From: andy.m.smith@gmail.com [mailto:andy.m.smith@gmail.com]
> On Behalf Of Andy Smith
> Sent: Saturday, October 04, 2008 3:49 AM
> To: DocBook Apps
> Subject: Re: [docbook-apps] in XHTML output
>
> 2008/10/3 David Cramer <dcramer@motive.com>:
> > Or is there a way to make a:hover affect only links?
>
> Yes, use "a:link:hover" and "a:visited:hover" (or just ":link:hover"
> and ":visited:hover").
>
> Andy
>
>