xhtml 1.1 anchor tags in Bobby

Hi,

xhtml 1.1 doesn't allow the name attribute, so anchor tags should look like
this:

<a id="anchor"></a>

Bobby seems to think this is an empty link tag, and therefore fails the page
for having links that don't make sense out of context.

Anyone know a workaround to this?

BTW - I know all the arguments about Booby not being the be-all and end all.
I normally just use it as a tool to check if I've forgotten anything, but on
this occasion the client has specified that they want xhtml 1.1 that
validates AAA with Bobby. Grrrr!

--
Richard Quick
http://www.chocolatemagazine.co.uk

Richard Quick wrote:

BTW - I know all the arguments about Booby not being the be-all and end all.

Booby? :-)

Richard Quick wrote:

Hi,

xhtml 1.1 doesn't allow the name attribute, so anchor tags should look like
this:

a id="anchor"></a

Bobby seems to think this is an empty link tag, and therefore fails the page
for having links that don't make sense out of context.

Anyone know a workaround to this?

Don't use <A> at all for this. Assign the ID to the HTML element to
which you actually want HREFs to lead. For example, instead of

<a id="summary"></a>
<h2>Summary</h2>
<p>...</p>

use

<h2 id="summary">Summary</h2>
<p>...</p>

This won't work in prehistoric versions of Netscape and IE, but if
you're determined to use XHTML you probably don't care much whether it
works in those browsers anyway.

On Wed, 25 May 2005 12:34:47 +0100, "Richard Quick"
<richard.quick (AT) chocolatemagazine (DOT) co.uk> wrote:

the client has specified that they want xhtml 1.1 that
validates AAA with Bobby.

Upgrade the client. Teach them why 1.1 is a bad idea. Even if you must
go for XHTML 1.0, 1.1 is a terrible idea these days and for the
forseeable future.

Secondly educate them on why Bobby is so broken as to be barely useful
as a measure of accessibility.

Mainly though, I'd ditch 1.1 in favour of 1.0 strict.

Andy Dingley scribbled something along the lines of:

On Wed, 25 May 2005 12:34:47 +0100, "Richard Quick"
richard.quick (AT) chocolatemagazine (DOT) co.uk> wrote:


the client has specified that they want xhtml 1.1 that
validates AAA with Bobby.


Upgrade the client. Teach them why 1.1 is a bad idea. Even if you must
go for XHTML 1.0, 1.1 is a terrible idea these days and for the
forseeable future.

Secondly educate them on why Bobby is so broken as to be barely useful
as a measure of accessibility.

Mainly though, I'd ditch 1.1 in favour of 1.0 strict.

I wouldn't say XHTML 1.1 is harmful, IF the browser is capable of
processing the right MIME type.

If you want to stick to XHTML 1.1 (with an XHTML MIME type, i.e.
application/xhtml+xml), I'd recommend a degree of browser sniffing
(sniff for explicit support of that MIME type -- MSIE claims it supports
anything, so wildcards can be ignored -- and yes, I know sniffing is
considered a Bad Thing) and sending a HTML 4.01 Strict representation --
which is easily possible with server-side scripting (if the markup is
authored appropriately, a generic search-and-replace can turn an XHTML
1.1 valid page into a HTML 4.01 Strict valid one without problems) -- if
the MIME type is not (explicitly) supported.

If you are not going to change the MIME type accordingly or can't
provide a HTML 4.01 Strict representation, ditch XHTML altogether.
Educate your client in regards to XHTML support in browsers (MSIE
doesn't support XHTML, its tagsoup processor merely allows it to guess
at XHTML passed to it with the HTML MIME type text/html) and why XHTML
isn't currently any superior to HTML in the real world.

XHTML Transitional (because Strict would be heresy in this case) with an
HTML MIME type is not much better than using non-standard HTML with an
HTML MIME type.
If you need to use an HTML MIME type, use HTML markup too.

--
Ashmo

Gazing into my crystal ball I observed Ashmodai
<ashmodai (AT) mushroom-cloud (DOT) com> writing in
news:d92f32$vjq$02$1 (AT) news (DOT) t-online.com:

If you want to stick to XHTML 1.1 (with an XHTML MIME type, i.e.
application/xhtml+xml), I'd recommend a degree of browser sniffing
(sniff for explicit support of that MIME type -- MSIE claims it
supports anything, so wildcards can be ignored -- and yes, I know
sniffing is considered a Bad Thing) and sending a HTML 4.01 Strict
representation -- which is easily possible with server-side scripting
(if the markup is authored appropriately, a generic search-and-replace
can turn an XHTML 1.1 valid page into a HTML 4.01 Strict valid one
without problems) -- if the MIME type is not (explicitly) supported.

Look at HTTP_ACCEPT header, and if it supports application/xhtml+xml,
then serve it such. I serve IE6 text/html because its HTTP_ACCEPT header
does not include application/xhtml+xml.

The only caveat is that for some browsers that do support the mime type,
if there is an error in the markup, the page will not render except for
the error. Therefore, make sure the page is marked up correctly _before_
it goes on a production server.

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Adrienne <arbpen2003 (AT) sbcglobal (DOT) net> wrote:

Look at HTTP_ACCEPT header, and if it supports
application/xhtml+xml, then serve it such. I serve IE6 text/html
because its HTTP_ACCEPT header does not include
application/xhtml+xml.

So you mean you _ignore_ the browser's proud declaration "I swallow
everything", i.e. "*/*", as in

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*

It does not explicitly mention application/xhtml+xml. But neither does
it mention text/html. Thus, on the basis of the Accept string, you have
no more justification for sending text/html than you have for sending
application/xhtml+xml.

My point is just that you are really doing some browser sniffing, not
acting on the basis of the Accept header by the protocol. It would
actually be safer to try to recognize (guess) from the User-agent
and other identifying headers whether the browser is one of the
programs known to handle XHTML 1.1 in some tolerable way.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

in alt.html, Ashmodai wrote:

Andy Dingley scribbled something along the lines of:

Secondly educate them on why Bobby is so broken as to be barely useful
as a measure of accessibility.

Does it still exist? I though it was replaced some gimmick that works
even worse. I evaluated my homepage twice, and got different results. It
is static page... (and it expires my sessions within 2 seconds, so I
never actually see what warnings are...)

Mainly though, I'd ditch 1.1 in favour of 1.0 strict.

I wouldn't say XHTML 1.1 is harmful, IF the browser is capable of
processing the right MIME type.

Well, as such situation is rare, and as even more rare is that support is
as good as XHTML1.0 as text/html, let alone real HTML4, I would think it
is harmful.

If you want to stick to XHTML 1.1 (with an XHTML MIME type, i.e.
application/xhtml+xml), and sending a HTML 4.01 Strict representation --
which is easily possible with server-side scripting -- if
the MIME type is not (explicitly) supported.

Do this so that you serve html4 strict by default with text/html, and
XHTML1.1 with application/xhtml+xml only if text/html is not
accepted[1], and I agree. Of course, atm latter is futile, but if you
already have it, it won't need much altering.

[1] You could be also trust browser if it says that it supports
application/xml+xhml better (using q values), but FF does that, and afaik
still doesn't have incremental rendering for it...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Support me, buy Opera:
https://secure.bmtmicro.com/opera/bu...tml?AID=882173