- From: Irene Vatton <Irene.Vatton@inrialpes.fr>
- Date: Tue, 20 Jun 2006 12:57:18 +0200
- To: Nick Levinson <nick_levinson@yahoo.com>
- Cc: www-amaya@w3.org
On Saturday 17 June 2006 20:25, Nick Levinson wrote: > If you ever update 8.8.51 for Win98 and/or if these > are relevant to your later-platform version, here are > critiques: > > 1. I look forward to complete compliance, although I > assume that's difficult. I'm trying to find full > support for ACSS or SSML so I can test my new pages, > and so other browser makers will be inspired to follow > in your footsteps. But I know that's a lot to ask. Amaya is not an aural editor and we don't plan to implement Aural Cascading Style Sheets (ACSS) and Speech Synthesis Markup Language. > > 2. During startup, the status bar says "Finished!". > The time to say that is when it has executed > everything, including loading the default home page, > and is ready for the next input. Likewise when > "Finished!" is displayed at times other than startup. > Otherwise, I think I can do the next step, when I > can't. Yes, "Finished!" says that files (document and images) are now loaded, but the formatter needs more time to complete the document display. > 3. A progress bar for page loading would be useful. It > took about 10-14 hours to partly load a 100K page of > XHTML with no scripts and only minutes of multitasking > but lacking alt attributes for many <img> tags (the > text rippled every few minutes and shorter pages took > a lot less to load). Loading was necessarily by > forcing a character coding, ISO-8859-1, the same > coding declared inside the file. Loading may or may > not have finished; the screen saver was still not on > after 14 hours. I ended the task, restarted Amaya, > reopened the document, and noted that after it loaded > the text above the fold (quickly above the fold) it > then wrote each <img> tag (probably all defective in > lacking alt attributes because the images are > essentially invisible to users, being paragraph > spacers). Yes, as you seem interested in ACSS, you could understand that an image without alternate information is disturbing. If your image is just a space, just say that it is a space alt=" ". The better way to generate spaces between paragraphs is to use CSS rules like p {marging-top: 2em} > Each of these <img> tags took roughly 5-6 > minutes to write (it paints <img> tags in 2 passes but > the first pass may be quick before it unpaints them > and paints them again). There should be 138 of the > tags, which comes to roughly 11 1/2 hours to closer to > 14 hours. I don't know if anything else has to be > written or calculated after the <img> tags that would > add notable time. The machine has adequate RAM, 64MB, > unless Amaya has special requirements I missed, so a > time estimate would be helpful for a long file. I'm curious to check this page. Could you send me a pointer. > 4. The list of errors is incomplete. Fixing one error > may lead a new one to appear, not caused by the fix. > Apparently, the culprit is "mismatched tag". In one > instance, it reported </div> as an error (probably as > mismatched tag). That's fine, and I added the opening > tag and saved (ignoring earlier errors); but then I > closed the source code and error windows and reloaded > the page (forcing 8859-1) and it reported a bad token > several lines after the </div>, a token it hadn't > mentioned the first time. If the W3C philosophy is to > stop reporting errors until some others are fixed, > this impedes page design if we opt to code a spot a > certain way or can't identify the bad coding suggested > by the errors list but want to know of other errors > below it. I understand that tags that are not > understood by a user agent are to be ignored, and > meseems that an extra opening or closing tag should > simply be ignored. In your case, I suggest you "discard" errors. Amaya will try to fix a maximum of errors then you could save the fixed document with "Save As" either as an HTML or as an XHTML document. > 5. The "mismatched tag" error may refer to an error in > tagging nested within. I had text within an invisible > table cell, thus I had "<td> . . . <p> . . . . </p> . > ... . </td>, except that I was missing the closing </p>. > However, Ayama instead reported </td> as mismatched. > Likewise, when Amaya reported </span> as a mismatched > tag, I was actually lacking </abbr> within <span> . . > ... <abbr> . . . </span>. Perhaps there's a better way > for Ayama to report the inner tagging as erroneous. The error is detected by the XML parser. The management of closing tags is completely different with an XML parser and a HTML parser. Amaya moves automatically to the HTML parser when this kind of error is detected. > 6. I've also seen a "mismatched tag" error at </td> > when I couldn't find an error. Within that table cell, > I had a large volume of text, in one case as a single > <p> . . . </p> enclosing several <br /> tags. > Likewise, a </p> was reported as mismatched, but I > couldn't identify what was allegedly missing, all the > enclosed tags being matched, apart from one <br />, > which isn't supposed to be. > > 7. In one instance, I suspect "mismatched tag" > referred to a nonstandard attribute in the opening > tag. The attribute, profile="[value]", is given by the > Dublin Core organization's website and is useful, so > I'll continue using it. A Dublin Core attribute can be added provided the namespace is declared. > 8. I've crashed it a few times via alt-space-x, which > should maximize the window via the menu at the left > end of the title bar, and once with just alt-space (I > was going to test another command by keyboarding but > didn't get a chance before the crash). That menu works > fine via the cursor, the maximize button works, and > alt-space-x works on Notepad. The crash symptom is the > standard warning about the program having committed an > illegal act and being shut down. Alt-space-x is not an Amaya shortcut. Shortcuts are displayed in menu entries. > 9. It crashes when (a) the main window was moved (so > the maximize button could be reached) and maximized by > the maximize button, (b) a file is being displayed, > (c) its source code is open and maximized by the > maximize button or is closed after being open, (d) its > parsing error list is open or closed as long as there > was a parsing error list and it was open, (e) I go to > the main window, and (f) I select another file and > click the dialog button to open it. (The file likely > would have had to be opened by forcing character > coding ISO-8859-1; that step would've been next.) The > window turns unavailable, alt-tab does nothing, and > clicking on menus or the close button yields only a > click sound. The end-task dialog lists it but does not > claim that it is not responding. I end the task and > start Amaya again. However, if I had closed both the > source code and the parsing errors list before opening > a new file, I can proceed. Recapping regarding the > child windows, either one or both being open leads to > the problem, but if both are closed before trying to > open another file the problem does not follow. On the > other hand, if I edit the source code and save it, > closing the child windows is not necessary to seeing > the revised object-code page. I cannot understand and then explain the majority of your problems. > 10. It reports "&" in a name attribute value as an > invalid token and not well-formed, but not > consistently. In one value, it reported the second "&" > but not the first (they were nonconsecutive); in > another, it skipped the "&" altogether but reported a > similar error at the end of the name value, where I > could not identify a nonalphabetic character or a > wrong kind of quotation mark. & are not allowed within element and attribute values. You should us & You seem to write HTML by hand without knowing constrains of this language. If you insert a '&' in the broswer view of Amaya, it automatically transform it into & in the source view. > 11. When forcing a character set is required, I'd like > to know which character/s offended Amaya or if my > UTF-8 declaration was misworded or inconsistent with > file content (Amaya refuses an attempt to force as > UTF-8 and prefers that I force as ISO-8859-1). As I know, by default Amaya proposes to created ISO-8859-1 encoded documents. The "Force character coding" command is just here to reread a loaded document when it's not readable with the current document encoding. See "Note about character sets" in Help > Browsing > 12. The Yahoo email login page (http://mail.yahoo.com) > is mangled in Amaya. Maybe their page is nonstandard, > and Yahoo doesn't support Amaya, but the page was so > mangled I switched browsers. I'll use Amaya for page > trials, since it looks good for that purpose. The CSS support is not complete in Amaya. We're working on this support. > 13. I assume page rendering is not meant to implement > all the coding, in order for Amaya to serve its > purpose as a test bed for other aspects. Type size > from CSS, for example, is not rendered. If that's > intentional, it's not a priority for me, since other > browsers can be used to test that aspect. > > 14. A minor convenience would be an alt-character > choice for Force a Character Coding. Normally you should not use this command, but select the right encoding in Preferences > Publishing > Charset for new documents or in the "Save as" command. > I'm running it on Win98SE on a Compaq Armada 7800 > model 6300/T/8000/V/0/1 with 64MB RAM and the > resolution at 1024x768. > > -- Nick > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- Irène. ----- Irène Vatton INRIA Rhône-Alpes INRIA ZIRST e-mail: Irene.Vatton@inria.fr 655 avenue de l'Europe Tel.: +33 4 76 61 53 61 Montbonnot Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex - France
Received on Tuesday, 20 June 2006 10:59:08 UTC