On 12/23/2010 10:39 AM, Marius Dumitru Florea wrote: > Hi Sergiu, > > On 12/23/2010 05:14 AM, Sergiu Dumitriu wrote: >> On 12/21/2010 02:45 PM, Marius Dumitru Florea wrote: >>> Hi devs, >>> >>> Following >>> http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made >>> some improvements and now I have this >>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig >>> . I'd like to include it in XE 3.0. >>> >>> WDYT? >> >> Some nitpicking: >> > >> Enable or disable the WYSIWYG/Source tabs. [ ] Yes [ ] No >> ^ This isn't a yes/no question. How about: >> 1. [ ] Enable the Source tab >> 2. [ ] Display WYSIWYG/Source tabs >> 1 says that only the WYSIWYG mode is enabled, while 2 says that both >> modes are enabled, just that there's no UI to switch between them, but >> either one can still be displayed by other means (JS scripting or field >> configuration). Personally I prefer the wording of 1, even if 2 is the >> actual implementation, since it's more user friendly. > > The actual configuration name is "Source editor enabled". Isn't this > equivalent to "Enable the Source tab" you are proposing? I avoided "tab" > in configuration name because (1) it refers to an UI implementation > detail and (2) it can also mean the white space "tab" character. > > "Enable or disable the WYSIWYG/Source tabs" is the hint. "Display the > WYSIWYG/Source tabs" sounds indeed better.
Indeed, my bad. The current title is good, but the hint should be changed. >> >> Inputs: I'm not sure a text input is the best element here, can't a >> select be used? > > plugin, menu bar and tool bar inputs are autosuggest enabled. You should > be able to open the list with all the suggestions by pressing down arrow > key but there is a bug in scriptaculous that prevents this. I have a > patch for it. Didn't see an autosuggest when I tried it, so I assumed there isn't one. I tried typing "a" and waited for suggestions, but nothing popped up. I tried now with "s" and indeed I got some suggestions. So, to make it better, we should try to fix the bug with the down arrow (tried that as well but it didn't work), and maybe display a "no results" when there aren't any items that match the current input. > I can't replace the tool bar input with a select because you can place > macro shortcuts like "macro:foo" on the tool bar and "foo" macro might > not be available when you configure the WYSIWYG editor. OK. >> >> Lists: I think that "Drag and drop to change the order" is not a very >> useful tooltip, is it possible to have an item description instead? If >> not possible yet, something to keep in mind for the future. > > I agree that this is something to add in the next iterations. Right now > the editor doesn't support plugin/feature description. > >> >> Yes/No radio buttons: Usually checkboxes are better for this. You can >> see this proposed in the forms standard as well: >> http://incubator.myxwiki.org/xwiki/bin/Standards/FormVerticalUsage#HFormExamples > > Using checkboxes was my initial intent but: > > * display method generates a PRE tag which is a block level element thus > technically invalid inside a DT (promoted by the form standard) This MUST be fixed in the platform. > * I wanted to write the class sheet using only wiki syntax, i.e. without > HTML and for checkboxes, unlike for the rest of the input fields, the > use of the LABEL HTML element is kind of required (you should be able > check/uncheck by clinking on the label). Well, we should use labels for all the fields anyway. It fails WCAG validation if inputs don't have an associated label. In the future we should have a {{field}} macro which generates the right syntax. For the moment I'd say that you should use the {{html}} macro, keeping in mind that once the platform advances it should be refactored. >> >> Font sizes: I agree that pt is the better unit here. Even though px is >> the standard unit on the web, the WYSIWYG is mostly trying to emulate >> Office applications, where the pt is the preferred unit. > >> >> >> Overall, this looks very nice. +1 for committing it. >> >> Referring to the other thread about committing the forms standard in the >> platform, I'm planning to do that in the coming days. How do we make >> sure we're not overlapping? > > I copied the form styles in a style sheet extension object. I can drop > this object after you commit the form styles in the skin. OK, this is the best approach. I did the same for the sharepage feature. > Something we need to take care is the class name on the form element. In > some cases the form element is not accessible (edit and inline modes) > and thus we can't add the "xform" class name. I must have the form > styles applied on my class sheet when in inline edit mode. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
