xhtml 1.1 anchor tags in Bobby

R

Richard Quick

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!
 
S

Spartanicus

Richard Quick said:
on this occasion the client has specified that they want xhtml 1.1

Have you told your client that as per w3c recommendation xhtml 1.1
should not be served as text/html but as application/xhtml+xml (which IE
cannot handle)?

http://www.chocolatemagazine.co.uk

Does your client find errors acceptable?:
http://validator.w3.org/check?uri=http://www.chocolatemagazine.co.uk/
http://jigsaw.w3.org/css-validator/validator?uri=http://www.chocolatemagazine.co.uk/

And is this what the layout on your site is supposed to look like?:
http://homepage.ntlworld.com/spartanicus/test/chocolate.png
 
R

Richard Quick

That's not the site I'm working on for my client. It's a personal site that
I haven't finished yet.

Thanks anyway.

If you've got an answer to my actual question, I'd very much appreciate it.
 
S

Steve Pugh

Richard Quick said:
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?

Put some content inside it. Normally you want to link to a specific
section of a page, and specific sections of a page normally have
headers. So <h2><a id="anchor">Heading</a></h2>

But, you might as well go the whole way and just use <h2
id="anchor">Heading</h2> because by dropping the name attribute you've
already dropped support for old browsers - I can't think of a single
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!

Your client is happy for the site to be Bobby friendly rather than
actually accessible? And is happy for it to be XHTML 1.1 rather than
something that works in IE? Does your client know more about web
authoring than you do? If so why aren't they doing the work
themselves?

Steve
 
R

Richard Quick

Richard Quick
http://www.chocolatemagazine.co.uk
Steve Pugh said:
Put some content inside it. Normally you want to link to a specific
section of a page, and specific sections of a page normally have
headers. So <h2><a id="anchor">Heading</a></h2>

But, you might as well go the whole way and just use <h2
id="anchor">Heading</h2> because by dropping the name attribute you've
already dropped support for old browsers - I can't think of a single
browser that supports using ids as anchors on <a> but not on other
elements.

Thanks - that's perfect.
Your client is happy for the site to be Bobby friendly rather than
actually accessible? And is happy for it to be XHTML 1.1 rather than
something that works in IE? Does your client know more about web
authoring than you do? If so why aren't they doing the work
themselves?

Hey - I'm just the hired help.
 
H

Harlan Messinger

Richard said:
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.
 
A

Andy Dingley

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.
 
A

Ashmodai

Andy Dingley scribbled something along the lines of:
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.
 
A

Adrienne

Gazing into my crystal ball I observed Ashmodai
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.
 
J

Jukka K. Korpela

Adrienne said:
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.
 
S

Spartanicus

Adrienne said:
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.

UA preference part of the accept header should be respected, it's there
for a reason. Most (all?) renderers that can handle both XHTML and Tag
soup are primarily Tag soup slurpers and have better capabilities as a
Tag soup slurper. For example Opera =<7.2x doesn't recognize character
references in X(HT)ML mode. Opera's accept header says that it *prefers*
HTML, so it should be served HTML.
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.

More importantly the renderer most people want to use
application/xhtml+xml for (Gecko) currently refuses to render anything
until the document has completely downloaded. Incremental rendering is
an essential function on the web, network & server problems frequently
cause pages to load very slowly, or not completely, for Gecko users this
results in them staring at a blank viewport when the author serves the
document as application/xhtml+xml.
 
L

Lauri Raittila

Andy Dingley scribbled something along the lines of:

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...)
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...
 
J

Jukka K. Korpela

Spartanicus said:
UA preference part of the accept header should be respected, it's
there for a reason.

Even if experience shows that's incorrect more often than not?
For example Opera =<7.2x
doesn't recognize character references in X(HT)ML mode.

Pardon? I've never heard of such a problem. But I know that Opera has
had problems with _entity_ references in XHTML. Actually even Opera
7.54 seems to fail to get entity references right if I use a DOCTYPE
that refers to my own copy of the XHTML DTD. Sounds like Opera still
handles the entity references in some kludge way.
Opera's
accept header says that it *prefers* HTML, so it should be served
HTML.

At least Opera 7.54 seems to say:

Accept: text/html, application/xml;q=0.9, application/xhtml+xml,
image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

It has the _same_ (implied) q value (of 1.0) for text/html and
application/xhtml+xml. The HTTP specification does not define the order
of values in an Accept header as significant, so I can't see what might
constitute an expressed preference here.
More importantly the renderer most people want to use
application/xhtml+xml for (Gecko) currently refuses to render
anything until the document has completely downloaded.

That's certainly an efficiency problem. But Mozilla expresses a
preference of application/xhtml+xml over text/html (using q parameter).
If you intend to serve XHTML as XHTML _at all_, then this would surely
be the place to do so.
 
S

Spartanicus

Jukka K. Korpela said:
Even if experience shows that's incorrect more often than not?

I see no justification for assuming that the majority of clients get the
preference wrong, or for ignoring the preference mechanism by only
looking for the presence of a string in the accept header as the OP
suggested.

The default assumption should be that the client's preference is
correct. Only in cases where a client's accept header is known to be
"incorrect" (applies to IE only afaik) or where following the preference
is known to have serious drawbacks such as when serving XHTML as XHTML
to Gecko should an exception be made.
Actually even Opera
7.54 seems to fail to get entity references right if I use a DOCTYPE
that refers to my own copy of the XHTML DTD.

I can't judge if that is an Opera issue. Regardless I can't see the
relevance to this thread, using a SYSTEM XHTML doctype would be a very
rare case.
At least Opera 7.54 seems to say:

Accept: text/html, application/xml;q=0.9, application/xhtml+xml,
image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

It has the _same_ (implied) q value (of 1.0) for text/html and
application/xhtml+xml. The HTTP specification does not define the order
of values in an Accept header as significant, so I can't see what might
constitute an expressed preference here.

You're right, last time I checked was with Opera 7.2 which does express
a preference for HTML:
Accept: text/html, application/xml;q=0.9, application/xhtml+xml;q=0.9,
image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
That's certainly an efficiency problem. But Mozilla expresses a
preference of application/xhtml+xml over text/html (using q parameter).
If you intend to serve XHTML as XHTML _at all_, then this would surely
be the place to do so.

Authors should not make a choice that for Gecko users will result in the
loss of such an important feature.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top