Log in   Register a New Account

Accessify Forum - Independent Accessibility Discussion Since 2003; Professional, Moderated, Web-based, Archived

New to the forum?

Only an email address is required.

Register Here

Already registered? Log In

Currently Online

No registered users are online.

Bench Tested XStandard Lite in our CMS

Reply with quote Vlad,

My company has its own CMS system with our own proprietary browser based HTML editors (one for IE another for Moz), however these editors don’t output clean xHTML code. I’ve downloaded and installed your editor into our CMS and have some results from bench testing that I’d like to hear your response on.

First off, we really like XStandard Lite not only because of the output in xHTML but also because of the drop down styles menu that allows for the import https://accessifyforum.com/files/of website specific styles. we can now enforce the styles for textual content on the user without them adding some horrendous font face, color, or size that destroys the harmony of the layout; and most importantly they can’t add deprecated or malformed code that invalidates the xHTML pages. In short, we’re seriously considering deploying our application using XStandard Lite.

Whenever we consider other third party applications to integrate within our custom applications we attempt to rigorously test that third party app. We tested your editor through a series of 21 cases that comprise extreme cases of various types of code that might appear on a webpage or be added by one of our clients. Out of these 21 cases XStandard Lite passed 9 with flying colors, failed 3, and had conflicting results or behavior in 8. To see a grid of these results go to http://filnetinc.com/test_results.gif

The two of the three cases that failed were due to importing over 100 KB of code into the editor. The first case where 218 KB was loaded IE hanged and hanged and hanged endlessly and with 450 KB a P4 Mobile processor running on XP Pro with 518 KB of Memory came crashing to a halt. We assume since this is the Lite version that you built in limitations that only allow 100 KB of code to be loaded or pasted into the editor. My question is, will the Pro version survive the loading of a file that large?

The other troubling case is the stripping out of remark or comment tags <!– some comment –> from code that is importehttps://accessifyforum.com/files/d into xstandard. i don’t quite understand why you’d choose to strip this out when the code is exported back to the cms or when the user views the source. this is critical because as any (x)html coder knows who works on a team, you need to leave clues and explanations within your code as a courtesy to help other markup monkeys that might edit it next. could you explain your rational for having <!– –> tags removed by the editor?

Lastly, the editor also, stripped out the <head></head> tag and anything inside. This is not such a big issue for our CMS system, because we allow the client to only edit the sandbox or textual content area of each webpage, not the entire page. However, I’d like to know your rational for this behavior.

Looking forward to your comments and thanks for developing a stable Xhtml editor.

Cheers,

Filnet508
Reply with quote Hi Filnet508,

Can you give us a link to download the test cases so that we can have a look at them. I can’t be sure, but there may be a bug or other issues related to a couple of them. In case of comment tags being stripped out, comments are not supported in 1.3. This feature should be added in 1.4. In regards to the <head> tag being stripped out, I need to see in what context this is being done – is it incorrectly nested?

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Vlad,

Thanks for the reply; I’ve posted a zip file to our corporate site at http://filnetinc.com/testcases_editors.zip

Please download and run the tests yourself. Its good to hear you’re going to address the comment tags, when will the new release be? If you need a beta tester just let me know, we’ll bang on it for you.

One enhancement I’d suggest for this new release would be removing the comment tag added by the editor <!– Generated by XStandard version 1.3.0.0 on 2004-09-10T11:58:21 –> . I think I speak for everyone that plans to use the editor with their CMS and depoly it to their clients, we don’t need this. My company will make sure to clearly brand the editor itself with a link to Xstandard.com within our CMS but I’d prefer not to have the branding within the code of our clients public website.

You could add this as an option if you upgrade to pro.

Cheers,

Trad Hughes (Filnet508)
Program Manager eLearning
Filnet Inc.


Last edited by Filnet508 on 10 Sep 2004 09:03 pm; edited 1 time in total
Reply with quote Hi Trad,

Looks like the tests are about the editor’s ability to import lhttps://accessifyforum.com/files/egacy markup and fix it as opposed to the editor’s ability to generate markup. that’s fine. we’re actually using tidy for this and some of this is out of our control. also, i see that all the tests are for editing entire web pages including <html>, <head> and <body> tags. The editor can handle this but it was really designed to be a content editor.

RE: case_html4tags.htm
There are 3 issues here.

Issue 1: <span> tags without attributes are removed. This is function as designed. You have the following markup:
Code:
<span>text text text</span>

This construct is void of semantics and removed because it is not a best-practice. Use something that has more semantics like:
Code:
<em class="important">text text text</em>
or even
Code:
<span class="important">text text text</span>


Issue 2: CSS rules are ignored because they are uppercase. This is function as designed. XHTML is case-sensitive so DIV {color:red} should not be applied to <div>text</div>.

Issue 3: In the process of fixing legacy markup, the editor removes the <style> element. This looks like a bug. FYI, in your test-case, the <style> element is incorrectly nested. It should be inside the <head> element.

RE: case_java.htm
Looks like you got a lot of problems on this page. First, you have an inline element <font> that contains block elements like <p>. Second, the <APPLET> element is not part of the XHTML spec. It has been replaced by <object>. Third, when fixing legacy markup, the editor removes <script> tags. This is for security reasons. So I am not sure what to make of this test.

RE: case_javascript.htm
This page test the ability of the editor to execute JavaScript. The editor does not do this and this is function as designed. When fixing legacy markup, the editor will remove the <script> tag for security reasons.

RE: case_javascript_onload.htm
You are testing the following markup:
Code:
<body onload="location.href=…">

Editors should not execute JavaScript. Function as designed.


RE: case_javascript_onload_search_engines.htm
See case_javascript_onload.htm

RE: case_lots_of_text.htm
This might be a Tidy problem. We’ll look into this.

RE: case_lots_of_text_half.htm
This might be a Tidy problem. We’ll look into this.

RE: case_metatags.htm
Interesting test. You have <meta> elements inside the <html> element, the <body> element and outside the <html> element. In other words, everywhere expect where they are suppose to be which is the <head> element. In any case, <meta> element is removed from the <head> when it is not suppose to be. This is a bug.

RE: case_metatags_redirect.htm
See case_metatags.htm

RE: case_remarks.htm
Comments are not supported in version 1.3

RE: case_stylesheet.htm
This is a bug, when fixing legacy markup, the editor should retain the <style> and <link> tags. Note, your nesting of these elements is incorrect. They should be inside the <head> element.

Trad, if you would like to beta test the next point release, sign-up from our web site.

Thanks for reporting the bugs.

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Vlad,

Thanks for going through our test cases. Two things to mention on those that I should have prefaced before I gave out the zip file, one is that if we were to deploy the Xstandard editor to most of our clients today, they primarily have websites coded using the 4.01 transitional HTML standard and we needed to see how it would handle the code. That’s the primary reason for all of the legacy markup in the test cases. The testing has helped us determine that we can’t deploy this editor to those clients with websites that are 4.01 Transitional and only to clients with new xHTML valid websites, which is fine.

The other thing is that we did intentionally add code that was malformed or in the wrong location within the web page document for our case studies. The reason being that our clients have been know to do silly things like adding meta tags to the body of a webpage, or adding code outside the <html></html> tags. That’s real world when you give an HTML editor to clients whose document publishing experience is limited to MS word.

Hope my comments have been constructive and helpful, keep up the good work. I would suggest that you consider deploying a bulletin board like this one within the Xstandard website along with a bug tracking application similar to bugzilla.

Cheers,

Trad


Last edited by Filnet508 on 10 Sep 2004 09:03 pm; edited 1 time in total
Reply with quote Hi Trad,

Thanks for putting this into context. When you need a faster response, contact our technical support directly at support [at] xstandard.com – we offer free support for the Lite version too.

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Hi Vlad,

Vlad Alexander wrote:

Issue 1: <span> tags without attributes are removed. This is function as designed. You have the following markup:
Code:
<span>text text text</span>

This construct is void of semantics and removed because it is not a best-practice. Use something that has more semantics like:
Code:
<em class="important">text text text</em>
or even
Code:
<span class="important">text text text</span>



I disagree with this. If there is a more semantically correct element to use, then obviously that should be used in preference to a span, but the XHTML specification allows the use of the span without attributes. The span element is used to act as a selector for CSS, and sometimes it is best practice not to specify a class to keep the weight of the page down.

Where all spans within #foo are to use the same rule.

Code:

#foo span


is preferable as a selector to

Code:

#foo span.bar


If the XHTML document contains several spans in #foo, specifying a redundant class in each will unnecessarily increase the weight of the page.

Even if you’re arguing for being future proof, where unforeseen spans will be required in #foo, they could be overridden with a class as an exception.

Juicy Studio
Reply with quote Hi Gez,

So what you’re saying is that in some circumstances, the nesting of <span> tags adds semantics to content. In other words, “location” matters.

The test we use to see if XStandard generates semantic markup is “can the markup be re-purposed en-mass, without ambiguities, using existing XML technologies like DOM or XSLT?” So, say you have a repository of 1,000 documents, can they be transformed to another vocabulary, can sections be moved or removed, etc, without ambiguity.

If we permit <span> tags without an “id” or a “class” attribute, I am not sure if this markup would pass our test. Because most users use XStandard to generate document fragments, location of where the <span> tags are used within an entire document can be different and hence introduces ambiguity.

Gez, I agree with you that in some circumstances a <span> tag without “id” or “class” attribute may be feasible. However, should XStandard encourage the use of this construct?

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Hi Vlad,

Vlad Alexander wrote:

However, should XStandard encourage the use of this construct?


I don’t see it as XStandard enouraging the use of this contruct. Should XStandard disallow an element to be used as defined by the XHTML specification?

I take your point about being able to re-purpose markup, but isn’t that the document architect’s responsibility?

Juicy Studio
Reply with quote Hi Gez,

We did some research and there are a few experts in the field that use this construct including http://csszengarden.com. I guess we’ll have to think about ways to support this in the future.

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Was there ever a resolution to this? I use <span>blah</span> for image replacement, and can’t have it removed.

www.brucelawson.co.uk
Web Evanglist, Opera, WaSP Accesibility Task Force
Study the Web Standards Curriculum

International Lothario (retired)
Reply with quote
brucelawson wrote:
Was there ever a resolution to this? I use <span>blah</span> for image replacement, and can’t have it removed.

Yes, this construct is supported.

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Thanks Vlad; good news!

FYI: I started another thread with a feature request for the insert alt text dialogue box

www.brucelawson.co.uk
Web Evanglist, Opera, WaSP Accesibility Task Force
Study the Web Standards Curriculum

International Lothario (retired)
Reply with quote
brucelawson wrote:
I started another thread with a feature request for the insert alt text dialogue box

I’ve asked the developer responsible for the upload feature to see if this is feasible. I should be able to respond to that thread in a couple of hours.

Vlad Alexander
XStandard Development Team
http://xstandard.com

Display posts from previous:   

All times are GMT

  • Reply to topic
  • Post new topic