Hello, Yahoo! just released a new version of their User Interface Library (http://developer.yahoo.com/yui). The funky part? The new version contains some high-level components like a WYSIWYG editor, a Color Picker, a popup calendar, etc. One of the many demos: http://developer.yahoo.com/yui/examples/editor/cal_editor.html It might be well worth a look ... so I figured I'd pass this tidbit along. :) -- Dries Buytaert :: http://buytaert.net/
Javascript based rich editing is broken. In safary, you get <span style="apple-xyz"> instead of <strong>, in Opera you get instead of spaces when you type text that contains non-latin characters (a bug reported years ago which still isn't being dealt with). With all this, I don't think that JS-based rich editing should go into core; I personally think that a flash based editor would be best, if only there existed one. Other visual enhancements of YUI are fancy, but not even close to necessary. YUI is also much heavier than jQuery. -- hex, out.
On 8/2/07 9:39 AM, Dries Buytaert wrote:
Hello,
Yahoo! just released a new version of their User Interface Library (http://developer.yahoo.com/yui).
The funky part? The new version contains some high-level components like a WYSIWYG editor, a Color Picker, a popup calendar, etc. One of the many demos: http://developer.yahoo.com/yui/examples/editor/cal_editor.html
It might be well worth a look ... so I figured I'd pass this tidbit along. :)
I can feel the debate over a '#wysiwyg' property in formapi coming... I will say, I like their CSS layouts for quickly putting together a skeleton theme, but these features all have established counter-parts in our world (tinymce, farbtastic, and whatever Ted ended up calling his calendar widget). So, what's the excitement? Thinking of core inclusion for some of it? Or just more contrib modules? Does the TinyMCE vs. HTMLArea vs. FCKEditor debate need a new player in the mix? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
James Walker wrote:
I can feel the debate over a '#wysiwyg' property in formapi coming...
I would support an "#formatted" property to indicate that a textarea contains HTML, but how a particular Drupal installation handles that should be flexible. It would be equally useful for invoking WYSIWYG or a Quicktags-style toolbar.
Yeah, I'm in favor of such a flag. I think that to make it really effective, though, some sort of fQuery-like mechanism should be a part of core. Otherwise we'll have everyone and their brother writing semi-broken tree-walkers to scan for '#wysiwig textareas that are followed by a button element...' and so on. ;) --Jeff On Aug 2, 2007, at 9:02 AM, David Strauss wrote:
James Walker wrote:
I can feel the debate over a '#wysiwyg' property in formapi coming...
I would support an "#formatted" property to indicate that a textarea contains HTML, but how a particular Drupal installation handles that should be flexible. It would be equally useful for invoking WYSIWYG or a Quicktags-style toolbar.
Jeff Eaton wrote:
Yeah, I'm in favor of such a flag. I think that to make it really effective, though, some sort of fQuery-like mechanism should be a part of core. Otherwise we'll have everyone and their brother writing semi-broken tree-walkers to scan for '#wysiwig textareas that are followed by a button element...' and so on. ;)
Note that I think we should go one step farther, and create a special version of textarea that automatically has the filter format attached to it. Right how, attaching the filter format to a textarea is kind of annoying.
On 8/2/07, Earl Miles <merlin@logrus.com> wrote:
Jeff Eaton wrote:
Yeah, I'm in favor of such a flag. I think that to make it really effective, though, some sort of fQuery-like mechanism should be a part of core. Otherwise we'll have everyone and their brother writing semi-broken tree-walkers to scan for '#wysiwig textareas that are followed by a button element...' and so on. ;)
Note that I think we should go one step farther, and create a special version of textarea that automatically has the filter format attached to it. Right how, attaching the filter format to a textarea is kind of annoying.
+1. I wrote a patch for this at one point which was just a #format attribute for textareas. http://drupal.org/node/125315 -- Neil Drumm http://delocalizedham.com
Op vrijdag 03 augustus 2007, schreef Neil Drumm:
Note that I think we should go one step farther, and create a special version of textarea that automatically has the filter format attached to it. Right how, attaching the filter format to a textarea is kind of annoying.
We already have all the ingredients: * theme hooks * alter hooks To allow modules such as FCKeditor, Widgeditor et al, to make "new" #types. Just see the #type => date and #type => weight. Those are either composed or prefilled with several HTML items. So we have long abandoned the idea that a #type should have an HTML counterpart. The way I see it, a wysiwyg area is simply a variation of the textfield, but still a completely new #type. I really don't see why we cannot have an #type => wysiwyg or #type => filtered_text and so forth. It would be more consistent, with #type => autofill, for example. But more important, it would not open the door to a wildgrowth of #something. Next up would be a #datepicker, #image-add-button, #allow-weblinks-inserted and so forth. I am /not/ saying there is the same demand for such wild and arbitrary namespaces, I am merely trying to illustrate the idea of adding new namespaces to change a form element into something else, is IMO a bad design. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On 02 Aug 2007, at 15:57, James Walker wrote:
I will say, I like their CSS layouts for quickly putting together a skeleton theme, but these features all have established counter- parts in our world (tinymce, farbtastic, and whatever Ted ended up calling his calendar widget). So, what's the excitement? Thinking of core inclusion for some of it? Or just more contrib modules? Does the TinyMCE vs. HTMLArea vs. FCKEditor debate need a new player in the mix?
I specifically decided not to draw any conclusions. I think it's worth keeping an eye on, that's all. At the minimum, it can be a source for ideas and inspiration. :) -- Dries Buytaert :: http://www.buytaert.net/
participants (8)
-
Bèr Kessels -
David Strauss -
Dries Buytaert -
Earl Miles -
hex -
James Walker -
Jeff Eaton -
Neil Drumm