- From: olivier Thereaux <ot@w3.org>
- Date: Thu, 21 Jun 2007 14:33:00 -0500
- To: Frank Ellermann <nobody@xyzzy.claranet.de>
- Cc: www-validator@w3.org
Hi Frank, On Jun 17, 2007, at 10:28 , Frank Ellermann wrote: > Oops, please don't do this for the "direct input" forms. It's kind > of tricky to clean a textarea with Netscape 3.x, such old browsers > assume that everybody offers "reset" buttons. I have to admit you're the first one asking to keep the reset button. Everything I could read, and feedback I know about so far was fairly adamant that keeping the button was a usability issue in itself. Mostly, I think, because the OK/Cancel button setup differs between platforms and as a result. > IMO it's one of the > rare cases where style="display:none" is acceptable. I would not personally mind that. Any objection? > IIRC you had that in a global stylesheet for "reset" buttons (?) Can't remember that, but it's not altogether improbable. > As it happens I verified that issue with an XML file, but that did > not work. Somebody proposed to add "parse mode" buttons for this > case, checking the source it's already there but commented out. It's there in the UI but there is nothing at the backend for it. I'd like to first get a working improved XML detection when a proper XML declaration is present, and see if the need for the parse mode button (which I honestly dislike) disappears. > The arrangement of the buttons is rather strange (without CSS), I > see as 1st line "full", as 2nd line the "DOCTYPE" selection plus > checkbox "only if missing", and as 3rd line the "fragment" radio > button belonging to the 1st line. > > Without CSS I actually get two DOCTYPE choices, the selection for > "full", and the simple HTML vs. XHTML for "fragment". Is that state > of the art today, accessibilty requires CSS ? Serious question, no > offense intended. I tested the UI without javascript and/or without CSS, and it seemed OK. Your two paragraphs also say "without CSS" although I suspect one is with, and one without. Would you mind sending me (or the list, if the attachments aren't too big) screenshots? Thanks. > Oops, a potential bug, I used "upload" for a *.kml file (some XML > stuff used by Google Earth). My browser has no clue what *.kml > is, it won't say "text/xml" when I upload it. The validator also > has no clue what it is, but it says: > | "This Page Is Valid (no Doctype found)" > > WTH did it validate, did this *.kml file happen to be valid SGML ? It's not really valid, IIRC KML files don't have a doctype or anything. So basically the sgml parser throws the usual two errors: * prolog can't be omitted unless CONCUR NO and LINK EXPLICIT NO and either IMPLYDEF ELEMENT YES or IMPLYDEF DOCTYPE YES and * no document type declaration; will parse without validation (and doesn't say anything after that) In XML mode, it would see that the root is not <html>, and thus consider it well-formed XML, end of the story. In SGML mode -> if the root element is <html> it would fall back on HTML 4.01 Transitional, and shoot a warning about that. -> otherwise... nothing happens. I think this is the bug we're seeing here. I'm adding a warning saying "no doctype found,and unknown root element. Aborting validation". Now for the tricky question: should it say "invalid (no doctype found)"? Validity doesn't really apply here... -- olivier
Received on Thursday, 21 June 2007 19:33:17 UTC