298642 - Support official DHTML a11y DTD

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

A set of DTD's are being worked on for DHTML applications that will fix some of
the validation problems we are having with tabindex on many elements, as well as
remove the requirement of using a special namespace for role and state
attributre names.

This is a very important fix to get into Firefox 1.1 because of validation
requirements for a number of organizations.

Comment 1

[Aaron Leventhal]

Attachment: 1) Fix GetDocType(), 1) Use doctype to determine if we're a special XHTML app, 2) If we are, don't require namespaces on role & state attribs, 3) Capitalize role names, 4) Remove 3 unnecessary roles

Comment 2

[Johnny Stenback (:jst)]

Comment on attachment 187177 [details] [diff] [review]
1) Fix GetDocType(), 1) Use doctype to determine if we're a special XHTML app, 2) If we are, don't require namespaces on role & state attribs, 3) Capitalize role names, 4) Remove 3 unnecessary roles

r+sr=jst

Comment 3

[Mike Kaply [:mkaply]]

Comment on attachment 187177 [details] [diff] [review]
1) Fix GetDocType(), 1) Use doctype to determine if we're a special XHTML app, 2) If we are, don't require namespaces on role & state attribs, 3) Capitalize role names, 4) Remove 3 unnecessary roles

a=mkaply

Comment 4

[Hixie (not reading bugmail)]

Uh, woah, woah, hold on.

We should not be doing anything based on the presence or absense of a DOCTYPE.
That's not how namespaces work.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This patch should be backed out:
 * we shouldn't change what we support based on the DOCTYPE declaration.  The
DOCTYPE declaration should be considered optional -- it doesn't really make
sense anymore in the world of multi-namespace documents.
 * if we do anything based on the DOCTYPE declaration, it certainly shouldn't be
based on searches for "Application", but should instead be based on string equality

Comment 6

[Aaron Leventhal]

(In reply to comment #5)
> This patch should be backed out:
>  * we shouldn't change what we support based on the DOCTYPE declaration.  The
> DOCTYPE declaration should be considered optional -- it doesn't really make
> sense anymore in the world of multi-namespace documents.
>  * if we do anything based on the DOCTYPE declaration, it certainly shouldn't be
> based on searches for "Application", but should instead be based on string
equality

It is perhaps hasty that I used a substring comparison but the issues that this
would affect seemed small because this is only affecting how the accessibiltiy
module approaches role and state attributes -- whether or not they are namespaced.

I can back out that part of the change, but I would later like to change it to a
string equality comparison when we have official word from W3C on what that will
be. The doctype just won't be optional for this type of XHTML application. How
else will there be to know that the role and state attrbibutes are legal in the
current application/xml+xhtml namespace? Open to suggestions. I am aiming for
forward and backward compatibility here.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

DOCTYPEs should NOT be connected to what features are supported.  That just
doesn't make sense for multi-namespace documents.  The ability to write a DTD
doesn't give you any more power over the XHTML1 namespace.  If you have a good
enough reason to change what we consider to be in the XHTML1 namespace, then it
should happen unconditionally.

Comment 8

[Aaron Leventhal]

(In reply to comment #7)
> DOCTYPEs should NOT be connected to what features are supported.  That just
> doesn't make sense for multi-namespace documents.  The ability to write a DTD
> doesn't give you any more power over the XHTML1 namespace.  If you have a good
> enough reason to change what we consider to be in the XHTML1 namespace, then it
> should happen unconditionally.

Okay. So, I will post a patch to change this immediately back or give me a day
or two to find out what the others at IBM working on this come back with to respond.

Comment 9

[Aaron Leventhal]

(In reply to comment #5)
>  * we shouldn't change what we support based on the DOCTYPE declaration.  The
> DOCTYPE declaration should be considered optional -- it doesn't really make
> sense anymore in the world of multi-namespace documents.

Aha, I see what you mean now. That is why none of the validators can validate
XHTML when it contains xforms etc.? The doctype cannot tell it about the
namespaced content within, correct?

So does validation itself make sense in the world of multi-namespaced documents?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #9)
> So does validation itself make sense in the world of multi-namespaced
> documents?

For DTD validation, basically, no.

Comment 11

[Aaron Leventhal]

We're looking at 2 different options to support valid content using DHTML a11y.

1. Create a profile such as this one, but including DHTML a11y:
http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/
I believe this could be used to make DHTML a11y validate with XHTML 1.0.

2. Work within the appropriate W3C wg to create an XHTML 1.1 module for DHTML a11y:
http://www.w3.org/TR/xhtml-modularization/
I have been told this has the advantage of allowing the role and state attribute
names to be used without namespace prefixes.

If we use #2, I now understand we cannot use doctype-based switching to
determine whether the attributes will be namespaced. However, how would I
determine this? If an XHTML 1.1 module is created, should I then just allow the
role and state attributes in the XHTML 1.1 namespace? How would I determine if I
am in XHTML 1.0 vs. 1.1 without looking at the doctype? I don't think we can use
modularization to fix the validation problems of 1.0.

Apologies if I'm missing obvious stuff. I'm definitely a newbie at XHTML
modularization and mixed namespace issues.

Comment 12

[Hixie (not reading bugmail)]

> We're looking at 2 different options to support valid content using DHTML 
> a11y.

Whether the content can be validated or not is completely separate from what the
browser should do. They are unrelated concepts. It is quite reasonable to create
a DTD that would help authors check for validity when using these attributes,
but these attributes must work (or not work) independent of whether the DOCTYPE
is present or absent.

To draw a parallel: We don't check for the presence of an XHTML DTD at the
moment before supports the "class" attribute on elements in the XHTML namespace.


> If we use #2, I now understand we cannot use doctype-based switching to
> determine whether the attributes will be namespaced. However, how would I
> determine this?

Either the feature should always be in the XHTML namespace, or it should always
be in some other namespace. The feature should not change from one namespace to
another based on anything.


> How would I determine if I am in XHTML 1.0 vs. 1.1 without looking at the 
> doctype?

You don't. You do not need to.


Incidentally, can you give us a link to the spec that defines this stuff? I'd
like to make sure the WHATWG specs don't clash with it.

Comment 13

[Aaron Leventhal]

(In reply to comment #12)
> Whether the content can be validated or not is completely separate from what 
> the browser should do.
Understood. Just giving the full story. Trying to understand how we can have
these new attributes within XHTML, which can be validated at authoring time, not
within the browser. The validation issue affects how we write our DTD, which
affects whether these attributes will be in a separate namespace or in the XHTML
1.x namespace. I'd prefer the latter, but I'm not sure what the precise method
for making that happen is.

> Either the feature should always be in the XHTML namespace, or it should 
> always be in some other namespace. The feature should not change from one
> namespace to another based on anything.
Do you mean xhtml 1.x or any XHTML including XHTML 2? I read what you say above
and it almost sounds like you're saying that anyt feature that gets added to
XHTML 2 should work without a namespace in XHTML 1.x. That doesn't seem right.
The role attribute is currently in the xhtml2 namespace. So right now you have
to use something like xmlns:x2=".../xhtml2" and then x2:role="foo".

> Incidentally, can you give us a link to the spec that defines this stuff? I'd
> like to make sure the WHATWG specs don't clash with it.
http://www.mozilla.org/access/dhtml/
The examples work but will be cleaned up before we offer them up for public
consumption. The w3.org docs haven't been updated in a while, so the mozilla.org
is more up to date. The folks involve understand that what they do needs to be
backwards compatible with what Firefox has in 1.1, where possible. No one wants
to kill the one implementation of this stuff.

Comment 14

[Aaron Leventhal]

Attachment: Backout Doctype-based switching for DHTML a11y

Comment 15

[Hixie (not reading bugmail)]

> Do you mean xhtml 1.x or any XHTML including XHTML 2?

Any mention of "the XHTML namespace" was referring to XHTML1. Sorry for the
ambiguity.

Comment 16

[Mike Kaply [:mkaply]]

Comment on attachment 187533 [details] [diff] [review]
Backout Doctype-based switching for DHTML a11y

a=mkaply

Comment 17

[Mike Kaply [:mkaply]]

Comment on attachment 187533 [details] [diff] [review]
Backout Doctype-based switching for DHTML a11y

oops

Comment 18

[Aaron Leventhal]

Backed out the part of the patch related to doctype switching.

Comment 19

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381