- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 01 Oct 2008 08:57:43 +0900
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: W3C WAI-XTECH <wai-xtech@w3.org>, www-validator Community <www-validator@w3.org>, HTML WG <public-html@w3.org>
Henri Sivonen さんは書きました: > > On Sep 30, 2008, at 11:24, Steven Faulkner wrote: > >> Members of the development community are asking for a way to check >> their HTML+ ARIA documents for conformance and one that does can be >> used to check all flavours of (x)HTML without all ARIA associated code >> being flagged as non conformant. > > Which is correct behavior, because ARIA markup is not valid according > to HTML 4.01 or XHTML 1.0. ARIA markup isn't valid according to the > current HTML5 draft, either, but HTML5 isn't done yet. > >> The experimental HTML5+ARIA checker developed by Henri Sivonen does >> this, but it is limited to the HTML5 doctype. > > I'm not convinced that the HTML5 doctype is a real problem in itself, > although I can see how it is problematic that HTML5 as currently > drafted doesn't make upgrading existing markup templates smooth by > obsoleting some popular attributes (such as the border attribute on > <img> and align attribute on <td>). > >> It also flags issues based on a set of rules, defined by Henri, on >> what constitutes conformant HTML5+ARIA (for example role="document" >> is not allowed) [2]. > > I made up rules myself, because neither the ARIA spec nor the HTML5 > spec was addressing ARIA in HTML integration in a satisfactory way. > The rules I made up were meant as an executable proposal to move this > issue forward. I got some feedback from individual PFWG participants, > but I didn't get feedback that could be considered as indication of > what PFWG intends to do about document conformance in the context of a > concrete host language. > > (Aside: After I made the executable proposal about HTML5+ARIA, I have > answered to inquiries about SVG+ARIA saying that it doesn't make sense > for me to give SVG+ARIA the same treatment of me making stuff up > before getting some sort of indication whether the PFWG agrees that > the general approach I proposed makes sense.) > >> Can we build ARIA checking into the W3C validator so that ARIA >> conformance can be checked seemlessly with HTML whatever the version? > > HTML 2.0, HTML 3.2 and HTML 4.01 are what they are, and they don't > allow ARIA markup--just like they don't allow <video>. > > Can we solve the practical problem here without backporting newer > markup features piecemeal and pretending (via "errata" or otherwise) > that old HTML specs allowed something they didn't allow? Surely the > label "HTML5" vs. "HTML 4" in the validator UI isn't the practical > problem? > > On Sep 30, 2008, at 12:26, David Dorward wrote: > >> The HTML Working Group is chartered to "maintain and produce incremental >> revisions to the HTML specification"[1], which I would imagine HTML 4.01 >> + ARIA would fall under. I imagine you would raise the matter with them >> and see if they would be willing to work with the WAI to publish a small >> Recommendation which makes reference to ARIA and HTML 4.01, defines a >> Doctype and includes a DTD. > > HTML 4.01 is so broken in so many ways that I think it doesn't make > sense to divert resources to put out individual fires. > > A bit over a year ago, I was advised against putting effort into > maintaining the HTML 4.01 and XHTML 1.0 functionality of Validator.nu. > I didn't take the advice back then, which is regrettable, because now > people ask me to put more and more effort into that dead end instead > of the users just using the HTML5. > > That is, it seems that people recognize that Validator.nu offers > better technology (datatype checking, etc.) compared to DTD-based > validation but, yet, shy away from HTML5 validation and instead want > the same improvements in schemas that are labeled HTML 4.01 or XHTML 1.0. > > Instead of changing the HTML 4.01 and XHTML 1.0 schemas to be even > further away from what those specs (vaguely) said while keeping them > labeled HTML 4.01 and XHTML 1.0 for marketing reasons, I would prefer > to find out what makes the HTML5 definition of validity impractical > for authors, remove those blockers and then talk about HTML5 > validation instead of pretending that HTML 4 validation changed to > include new stuff. > > If we make one-off HTML 4 + Foo validation targets, but where do we > stop? Should we also have an HTML 4 + <canvas> validation target and > an HTML 4 + <video> validation target? > > On Sep 30, 2008, at 11:44, David Dorward wrote: > >> Steven Faulkner wrote: >>> Can we build ARIA checking into the W3C validator so that ARIA >>> conformance can be checked seemlessly with HTML whatever the version? >>> >> That wouldn't really make sense. It would be more logical to create an >> HTML 4 + ARIA DTD and validate against that. > > Such a DTD could have holes that ARIA could drive through with error > messages removed, but DTDs are inadequate for actually validating > ARIA--i.e. detecting ARIA errors. > >>> People seem to want a form of checking provided by the W3C that will >>> tell them (for example) that their HTML code is valid and their ARIA >>> code is valid. >>> >> If it has ARIA in it, then their HTML (by any current W3C recommendation >> that I know of) isn't valid. > > Right. > >> You can't fix this problem at the tool level, you need to address it >> at the standards level. > > Exactly. Asking people to produce the tools when the relevant working > groups don't work jointly on an actual normative conformance > definition doesn't really make sense. Or it makes sense on the > prototyping level but then what you get is the validator developer > making stuff up. > > On Sep 30, 2008, at 12:25, Gez Lemon wrote: > >> It doesn't resolve the whole issue of ensuring that ARIA is used >> correctly with a native markup language, but if the ARIA specification >> is available in a machine readable format (such as what attribute >> values are valid for a particular attribute, and what attributes can >> be used with particular roles in RDF), we could build a basic >> validator to ensure at least the ARIA part is used according to its >> specification. > > In my experience, the RDF definition was not useful when implementing > the HTML5+ARIA prototype. I looked at the English prose and the tables > instead. > > On Sep 30, 2008, at 12:38, Jason White wrote: > >> Yes, but unless the validator includes a Javascript interpreter and a >> DOM >> implementation, all that can be checked are the Aria attributes of the >> document prior to the execution of scripts that modify it. >> >> Anything involving live regions or Javascript functions that change >> states or >> properties would largely escape any lesser validator. Maybe the >> validator >> needs to be written as a user agent extension that can verify >> correctness as >> changes are made. > > The validator doesn't need to run in the same process as the browser. > It would be sufficient for a browser to serialize a snapshot of the > DOM and send it over to another process for validation (e.g. over > HTTP). Currently, one can approximate this with bookmarklets and > Validator.nu. However, there is a problem that currently Validator.nu > supports input in the text/html and XML serializations, but neither of > those can express all the possible DOM trees, so to make things work > for all possible DOMs, a new format and a SAX parser (in Java) for it > on the Validator.nu side and a serializer in JavaScript for the > browser side would be needed. > > I have gotten inquiries about putting Validator.nu inside the browser > process. I think that embedding a JVM in the browser process would be > unnecessarily heavyweight. If someone wishes to pursue the in-process > path with Validator.nu, I suggest using the compiler from Google Web > Toolkit as a means of taking Java code and loading it onto the > JavaScript VM of the target browser. > > On Sep 30, 2008, at 14:10, Michael(tm) Smith wrote: > >> I would think it'd be doable to add support in validator.nu >> experimental support for validating XHTML 1.0 and HTML 4.01 >> documents containing ARIA markup. > > It's possible to backport the ARIA stuff to the legacy schemas, but > wouldn't it make more sense to forward port this stuff from HTML4 that > keeps people from upgrading to HTML5 as their validation target? > >> But I think it might be worthwhile to have a discussion with Henri >> about whether those rules can or should be adjusted. > > They can be adjusted. I was trying to poke the relevant working groups > into saying how by showing an executable proposal. > >> And/or we should discuss the idea of actually >> defining a spec for HTML 4.01 + ARIA, without reference to DTDs or >> perhaps without reference to any normative formal schema language >> at all. > > I think we should instead put that effort into producing proper spec > text defining conformance criteria for HTML5 + ARIA. > > On Sep 30, 2008, at 14:22, David Dorward wrote: > >> Michael(tm) Smith wrote: >>> That said, there's nothing blocking anybody interested in pursuing >>> the idea of producing a DTD for HTML 4.01 + ARIA and negotiating >>> with the validator.w3.org maintainers to add support for it. >> A DTD is a DTD. The validator works with DTDs, explicit support doesn't >> need to be added. (Although, if its popular, it might be worth adding it >> to the local catalogue (for speed) and the list of possible Doctype >> overrides). > > Aside: Validator.nu allows user-provided RELAX NG and Schematron > schemata. And this functionality, btw., is used within at least one W3C working group for a specialized, multilingual, XHTML-based document format. See http://www.w3.org/2007/02/japanese-layout/docs/aligned/#documentgeneration http://www.w3.org/2007/02/japanese-layout/docs/aligned/check Felix > > On Sep 30, 2008, at 15:07, Aaron M Leventhal wrote: > >> We do need a solution soon. This keeps coming up. >> >> I think W3C should drive this, since developers want the official W3C >> stamp of approval. > > Perhaps past emphasis on a W3C stamp of approval is part of the > problem.His > >> W3C can use a multi-pronged solution: >> 1. Short term: create new DTD and ask W3C to host it. It can be >> considered "beta" for now. It needs to include HTML 4 + tabindex >> changes (allow negative numbers and on any element) + WAI-ARIA. >> 2. Medium term: DTD's are of limited value, and W3C can utilize >> something that provides more in-depth checking. Perhaps Validator.nu, >> but certainly at least looking at Henri's approach > > The W3C is already hosting an instance of the Validator.nu software as > a back end to a development version of the W3C Validator. > > If you use the HTML5 doctype, you can get the same ARIA validation at > http://qa-dev.w3.org/wmvs/HEAD/ that you can get at > http://html5.validator.nu/. > > Why promote a less expressive DTD approach? > >> Getting around validation by inserting content via script is >> happening. I'm seeing developers recommend that ARIA is inserted >> dynamically onload, just for that reason. Seems not to be useful. > > Agreed. > > On Sep 30, 2008, at 15:39, Michael(tm) Smith wrote: > >> I'd suspect that the >> difficult part is getting agreement about what exactly the >> specific validity constraints in the DTD should be. I mean, I get >> the impression from the message that Steven cited that there's not >> agreement on the schema that Henri made. > > Right. The problem of the spec missing can't be fixed by switching to > legacy validation technology. :-) > >> > > Furthermore, trying to get the W3C Validator to add a new DTD would > presumably involve putting a non-standard doctype on the documents to > be validated. If authors were willing to do that, why wouldn't they be > willing to use the doctype <!DOCTYPE html> if the validity definition > of HTML5 were tweaked along the lines I suggested in > http://lists.w3.org/Archives/Public/public-html/2008Aug/0958.html > > On Sep 30, 2008, at 16:11, Michael(tm) Smith wrote: > >> I think having a normative spec for ARIA is HTML 5 is absolutely >> something that the HTML WG needs to produce. > > Hopefully together with the PFWG. > >> But having a spec of HTML 4.01 + ARIA is not. > > Agreed. >
Received on Tuesday, 30 September 2008 23:58:30 UTC