Web version?
Sorry for the 'stupid' question, but is there a web based version of the Xstandard editor. Such as something I can plug into a CMS?
I'm probably being dense, but I can't see for certain on your site...
Cheers
Phil
Share: 
you'd plug it into your CMS by changing the input templates/dialogs of your CMS to call the embed the plugin...i meant to do this a while ago for wordpress, but unfortunately - despite its reasonably nice customisation features for presentation templates, its admin interface is considerably more cumbersome to extendPatrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
sorry, still being bumb here. Does this mean there's a download and install required by the user? or is it truely web based, if you see what I mean?
Chrs
Share:
| Phil Teare wrote: |
| Does this mean there's a download and install required by the user? |
Yes, it's effectively a browser pluggin, the user does need to download it. There are a few methods they outline of making that as easy as possible for the user.
It isn't the approach I would want to take from a theoretical point of view, but I think it's the main reason that Xstandard out-performs the JavaScript based editors in terms of output, as they have to rely on cleaning up the browser based markup (which is terrible, including from Gecko).
Share:
Don't want to upset anyone (as its a great project), but as feedback, this will mean I won't be using it...
Would be great if the same idea was translated to a web-based version. Pls?
thnx for clarifying Alastaire
Share:
| Phil Teare wrote: |
| Would be great if the same idea was translated to a web-based version. Pls? |
I know what you mean, but I would bet dollars to donuts (oops, Americanism, pounds to pence?) that it's not going to happen, because it can't. Just as a note, when you say 'web-based', is a scripted editor really any different from a pluggin?
There isn't a single JavaScript based editor that can produce fully (X)HTML strict compliant code at the moment (yes they can do the basics, but you can easily get the code into a mess, and normal users manage it with stunning regularity).
The reason is (IMHO, I haven't tried to write one), because they have to rely on browsers. There is only so much clean up you can do in such a dynamic environment.
Xstandard has avoided these browser issues by being a pluggin, and the output is much cleaner for that decision.
I'm not an Xstandard cheerleader: We can't use it either until it's fully keyboard and screen reader accessible. However, in comparison to everything out there, the comparative accessibility of the product is similar.
The JavaScript based ones require particular browsers (IE/Firefox) because the other browsers don't support the necessary scripting mechanisms, and generally aren't keyboard/screen reader accessible either. And don't get me started on the Java or IE only ones!
The use of a pluggin is off-putting, but don't cut off your nose to spite your face!
(Note to self: Must start running editors through the WYSIWYG checklist.)
Share:
| Quote: |
| Just as a note, when you say 'web-based', is a scripted editor really any different from a pluggin? |
HUGE difference. In that many many more users are unable, unwilling, or unauthorized to install a plugin, compared to those who don't have javascript available. This is realy big. Not for me. I'd happily install anything I think worthy, but I'm not my target market/audience.
| Quote: |
| The use of a pluggin is off-putting, but don't cut off your nose to spite your face! |
Far from it. I'll use the most 'complete' solution whatever it may be. But bespoke plugins ,which aren't likely to be installed already (for a public website, on a public terminal) is just a dead end for me. You can't install a plugin in an internet café. You are likely to have Flash and javascript at your disposal (cross browsers). Simple as that. Sad though cos I want something just like this...
Share:
Fair enough, I just wanted to be clear that it's a practical issue, rather than a strictly accessibility or standards issue.
Although, given that 5-10% of people don't have JavaScript enabled, I'm not sure it's that much different?
Share:
| Phil Teare wrote: |
|
HUGE difference. In that many many more users are unable, unwilling, or unauthorized to install a plugin, compared to those who don't have javascript available. |
ah, i thought you wanted it for a CMS that is only accessed by a controlled number of internal users...
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
not in this case...
Like I say, I'm all for this project. I'd just love to see something more 'webby'.
Chrs for the replies guys. Vlad, whats the chances of a js/php/asp/flash version?
Wouldn't it be nice if it became the editor of choice for WordPress, Drupal, Mambo, etc...
It could have a realy important effect on spreading standards (not to belittle its current effect:) ). Are you out there Vlad?
Share:
| Phil Teare wrote: |
| whats the chances of a js/php/asp/flash version? |
Any of these would be a new project,. Still, a flash version would be nice, and another way of avoiding the cross-browser issues.
Share:
I'm not as convinced as you are that it can't be done with js. If you rely on the DOM for everything then yes, issues will ensue... But if you're going for (to the main) pure parseing of text and event catupe to markup (not assuming anything, building everything) then its entirely doable without any x-browser issues.
There's nothing that Flash has that could improve on this (I suspect at least). While its got fewer X browser quirks, its got next to no features useful for building an editor, beyond the bare minimum (and lots of prettyfication stuff, obviously). Or thats my perspective anyway.
Share:
| Phil Teare wrote: |
| Vlad, whats the chances of a js/php/asp/flash version? |
None I'm afraid. Let me explain why. Many Web browsers have contentEditable functionality built-in, which can be used to create a WYSIWYG editor. contentEditable is a black box - you cannot modify any core functionality. JavaScript editors interact with the contentEditable interface by calling a limited number of public methods.
This would be okay if contentEditable behaved in a standards-compliant way and all browser vendors implemented it in the same way. But it doesn't/ they don't. The contentEditable functionality was designed about 7 or 8 years ago and it's very much formatting-centric. Opera and Safari recently added support for contentEditable but in order to be compatible with IE and Firefox, they too built it to be formatting-centric. There is very little chance that the contentEditable interface will ever become standards-compliant because this will "break" millions of documents previously authored using this interface. Browser vendors are very sensitive to breaking backwards compatibility.
To illustrate the problem with back box functionality of contentEditable, take the same brand of WYSIWYG editor such as FCKEditor or TinyMCE and start with the following markup:
| Code: |
| <p>I <strong>like</strong> <a href="http://xhtml.com">XHTML</a>.</p> |
Then apply the font color red to the paragraph in WYSIWYG mode, in IE and Firefox.
In Firefox you get:
| Code: |
| <p><font color="#ff0000">I <strong>like</strong> <a href="http://xhtml.com">XHTML</a>.</font></p> |
In IE you get:
| Code: |
| <p><font color="#ff0000">I <strong>like</strong> </font><a href="http://xhtml.com"><font color="#ff0000">XHTML</font></a><font color="#ff0000">.</font></p> |
As you can see, same brand of editor has very different markup output. That is because contentEditable in IE and Firefox have different rules on breaking tags.
Phil, I assume you mentioned Flash because it is a plug-in that is pre-installed on many computers? I believe Flash has rich text editor functionality built-in, but I think it's formatting-centric as well.
FYI, we used to produce as JavaScript WYSIWYG editor until some of our customers started getting into trouble when they needed to change the look and feel of their sites and the markup that the editor produced was not meeting accessibility guidelines. So we realized that we needed to produce an editor that met the following design objectives:
- Must generate markup based on standards and best practices
- Must encourage authoring of semantic and accessible markup
- Must generate markup as an XML fragment with predictable parsing rules
- Must generate identical markup, regardless which browser is being used
As you can see, the design objectives of XStandard cannot be met with the contentEditable interface. This is why we had to build an editor completely from scratch in C++.
Share:
no chance of porting the c++ to AJAX then?
I know you've already said no, but it would be so good...
Cheers for the explination!
Share:
| Phil Teare wrote: |
| no chance of porting the c++ to AJAX then? |
AJAX is not a language like C++ or C# or Java. AJAX is plumbing. It's a means for a client to communicate with the server in the background (without the need for a page refresh). When someone says they built an AJAX WYSIWYG editor, they really mean that some features of the editor use AJAX like technology to talk to the server to exchange data.
XStandard actually uses "AJAX" like technology for features such as file upload, image library, markup snippet library and spell checking. XStandard uses Web Services for these features which just like AJAX, the client sends an XML message to the server and then gets an XML message back.
Share: