![]() ![]() Imagine an example where a dialog is used to represent something that causes a side-effect (e.g. ![]() I understand that it doesn't match the ideology that TinyMCE is trying to do here but for one-off style tweaks it avoids creating fully custom UI element just for some visual tweak. I think TinyMCE should support adding custom class to the dialog so I can apply custom style to specific dialog only. Note that hack this would add that class to all dialogs if multiple are open. Once I'm finished testing/converting things over to 5.x I'll see what else is left. The lack of flexibility for DOM editing does concern me going forward but I haven't given editing the skin files a proper shot yet. ![]() So far I've been able to handle all of the changes that 5.x has thrown at us fairly effectively, and the new dialog system is fairly clean. I do like the flexibility of HtmlPanel, but at the same time I know it's gonna cause issues since people are going to try to use it to make custom controls and realize that that's not gonna work out for them. I used HtmlPanel to force "whitespace" to wrap so that that label would flow properly, but if that's a bug then that's not a valid use case. Our workflow just isn't designed to deal with including TypeScript in here, and having a copy/submodule of tinymce just for editing a few things in the skin is a bit hefty for what we wanna do with it. We only deal with the compiled versions, that might be where the majority of our issues come from. I will concede that my use case here is very specific (with changing the font of a single label, for instance), and I did find a valid workaround (using an htmlpanel for instance), but I think the label/flex issues should still be looked at. all this stuff that is not exposed any more or would require a fairly large amount of work (from what I can see anyways I could be wrong about this one) to get these in there, whereas with the old system I could edit the DOM directly if I absolutely needed to (albeit at that point I am accepting that tinyMCE support isn't gonna help me if I'm messing with things), either by adding a class/ID to the dialog so I can style it via CSS or, in a last ditch effort, rely on inline styles (which I really don't want to use) on specific elements. I use flex for all of our projects now as well, but the main thing with flex that comes up is that I constantly run into cases where I need to manually adjust the flexing of elements, their wrap conditions, their basis. I love the idea of the new dialogs, don't get me wrong flex is amazing, but it seems like it's being used entirely wrong here if some of the elements aren't flexing or wrapping at all. See my other ticket about editing the "charmap" plugin to add more tabs to it there's no explicit height or anything in the plugin itself, but it still seems to snap to that height. This doesn't seem like an edge case to me, just that the dialogs were only designed with the built-in dialogs in mind and not taking what end-users are going to do with them into account. I don't really want to edit the skin JS or add a new control type just to make a label wrap onto more lines. I had to kind of do a workaround hack to change "white-space" to "normal". I assume you are creating the modal as per the documentation link you provide, if so, then the buttons parameter let you specify the buttons to add to the modal and the actions of said buttons, like this: your label has more than a few words of text, it just flows off of the side of the dialog. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |