[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Ripping out a@name generating code from the stylesheets [was:<link linkend> in XHTML output]
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] <link linkend> 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 <a> tag being > > closed with a "/" > > > > instead of </a>, 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 </a> closing tag is mandatory, and I guess the > > > browser is treating the <a.../> as an opening tag (and acting as if > > > there's a closing tag later in the document) rather than an empty > > > element. > > > > Yep, because browsers don't parse text/html content as XML -- > > they parse it as HTML, and in the HTML syntax that browsers > > support, <a.../> means the same thing as <a...> (the HTML > > parsers in browsers pay no attention to that slash). > > > > That's just one of several reasons why it's not a good idea > > to serve XSLT-generated output@method=xml content as text/html. > > > > [...] > > > If you use the stylesheets' HTML rather than XHTML output I think > > > you'll get closing tags and results that will generally be > > OK with the > > > text/html content type. > > > > I think that's the best advice in general. For most cases, > > there is zero harm in generating HTML content from XSLT using > > output@method=html and much good in that it will prevent the > > <a.../> problem, and others too. > > > > --Mike > > -- Michael(tm) Smith http://people.w3.org/mike/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]