W3C home > Mailing lists > Public > www-amaya@w3.org > April to June 2006

Re: items re Amaya 8.8.51

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
Message-Id: <200606201257.18199.vatton@inrialpes.fr>

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 &amp;
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 &amp; 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:36 UTC