In atto, the plugin for font-size changes has not been working since Moodle 2.7.
https://moodle.org/plugins/pluginversions.php?plugin=atto_fontsize
This plugin has been broken for a long time and there appears to be little work to remedy the situation. In MDL-48121 the lack of text sizing and colouring options was reported, yet the issue was closed without a solution.
I appreciate attempts to maintain accesibility for the atto editor for non-sighted users, however, the inability to readily control font colours, background colours, and font sizes is something I am receiving constant complaints about. Of course, there is a workaround available in letting those complaining users use TinyMCE but doing so means some of the really cool features in Atto (such as autosave - so awesome!) become unavailable. Also switching between editors requires editing the users' profiles which is troublesome for many.
So, who's with me? Are there others out there who want font size, colour, and bgcolour options in the atto interface? Should we make a new issue on the tracker and all get together and vote for it?
Moodle community, what say you?
Thanks for reminding me of this problem, Adam. This is what I just posted in MDL-48121 in response to the closing of this issue and an insistance that this is not a bug:
"This is a huge bug--it is a regression worthy of downgrading to 2.7 in my mind. It immediately caused a dozen teachers at my university to say they hate Moodle upgrades and to never do an upgrade again. The HTML editor is the primary authoring tool for teachers in the absence of any other authoring tools for this LMS. Ten of thousands of teachers are using the HTML editor to build courses and font size/font color are absolute necessities. This change was not given due consideration among teachers--maybe among developers--and certainly not from any one I have talked to that uses Moodle. Every one has returned to TinyMCE as an editor. But Atto is the future, and Atto can be improved. It should be improved immediately and should have been improved before its release. Re-open this issue and keep closer to teachers, not developers when making decisions like this."
I think the key point is that Moodle teachers do not use outside tools for authoring. They use the HTML editor for authoring. It is simple and powerful. I wish we had a brilliant authoring tool like other LMSs do or even could make multimedia quizzes in a commercial tool like Captivate, Camtasia, or Storyline. But we don't have that (and please don't suggest SCORM). Let's make the core Atto as good as TinyMCE and better.
Agree 100% Don
I have argued in any number of threads that many real users require the power that a full fledged editor like TinyMCE provided. Web designers, developers may disagree, but the users tend to complain loudly when those functions are not readily available.
TinyMCE3 as in Moodle is outdated and ATTO is the way HQ decided to move forward and while I didnt agree with that I do understand it. One of the reasons I didn't agree with it is these missing functions that are a vital part of many users' experience. Atto is extendable through plugins, but so many of these essential plugins are still not available several moodle versions later (and some that were are broken) and it remains my opinion that ATTO, while it will be a huge step forward is not suitable as the core default editor until the number of usable, stable plugins meets those requirements.
Despite being outdated, this lack has meant that we still work with TinyMCE as our default editor.
I'd love to see ATTO functioning the way it has been envisaged, I just think its not there yet as it lacks those key plugins that users actually want/need.
"This is a huge bug--it is a regression worthy of downgrading to 2.7 in my mind..."
Bit over dramatic IMHO. What's the point of having theme designers if you allow all and sundry carte blanche when it comes to formatting text? There's a reason people pay for graphic designers in the publishing world be it print, web or multi media based. As a person that has to fix the mess some people make I'm glad Atto has been cut back to basics.
That said, I agree with choice therefore IMHO it should be made easier to define custom style sheets over and above the default and basics such as font size and colour should be Moodle HQ plugins.
Hi Just,
Not overdramatic in the slightest. Being in a similar context to Don, I have seen the way teachers will latch on to something like this and be demotivated to use the entire system as a result. Is this fair? Hell no! Is it the reality? Hell yes!
Also, as a moodle admin, I sympathize with graphic designers who made it all pretty, just so a teacher can come in and change a font size (shock horror - run for your lives)! Still, the purpose for Moodle is education, not the flattery of a designer's ego. Teachers often NEED to be able to resize text. It is a simple fact of education. If this weren't the case, my inbox would be complaint-free, and we wouldn't be having this conversation.
Half-agree with you on the style sheets, but CSS can be quite tricky for an mech engineering prof.
Thanks Don,
I also added the below comment to the tracker today (ran out of time yesterday).
I too agree with Don. I administer a Moodle that is used by a growing number of faculty (40 out of 80 at the moment). The lack of ability to do a simple font-resize is exactly the kind of demotivating factor that makes my job difficult. I know it doesn't negate all the other awesome stuff Moodle can do, but in the minds of newcomers to the platform, it can be the straw that breaks the camel's back.
Please deliberately bring back font-size to atto. The number of complaints I have had ever since it stopped working is stressing me out. You wouldn't want my hair to go grey, would you?
Cheers!
Is not the semantic paragraph styles markup of Atto enough? This offers several levels of heading in addition to standard paragraph and preformatted (e.g. code) styles. These will render with different font sizes etc depending, of course, on your theme/CSS setup.
Heading (large)
Heading (medium)
Heading (small)
Pre-formated
Paragraph
Although not enabled by default, font colour and background colour buttons can be added to the Atto toolbar by adding fontcolor and backcolor to the Atto toolbar configuration. In:
Site administration > Plugins > Text editors > Atto HTML editor > Atto toolbar settings > Toolbar config:
Change:
style1 = title, bold, italic
to, say:
style1 = title, bold, italic, fontcolor, backcolor
If required, there is also a 3rd-party Atto plugin for font colour:
https://moodle.org/plugins/view/atto_morefontcolors
Hi Geoffrey,
> Is not the semantic paragraph styles markup of Atto enough?
No, this is not enough!
I and all of my teachers know of the styles dropdown in atto. However, this formatting limits users to making headers and the like when all they want to do is make the font a bit bigger. In your own examples, the headings are rendered in orange. That is a compulsory change in colour linked to the change in size. What if I want all the text big, with one word highlighted in red and another in blue? As a language teacher, this is not an uncommon practice (it's awesome for highlighting grammatical features).
So, in short, no, it's not enough!
Also, the third party plugins you mentioned in have severely restricted colour palettes (actually not such a big problem, but the option to add more colours would be nice). These plugins are great, BUT, font-resize is broken and has been for quite some time. At least I'd like to know if and when it's planned on being fixed.
The users (teachers, students and in response admins) are requesting that font-size be added to atto. Why is this request being so hastily dismissed?
I view Atto as a good editor that supports both web standards and Moodle Themes. Allowing a theme to govern the overall look and feel has positive benefits. BTW, the font tag itself is no longer supported in html5. Browsers will still render it but it is better to use other presentational tools, especially those that have a semantic dimension, than font-size.
Therefore, I do not think the lack of font-size control is necessarily a "bug".
When I want to deviate from those standards, I switch editors or create my page offline and cut&paste.
Hi Douglas,
There is a plugin that purports to change font size in atto. It doesn't work. That's what I'd call a bug LOL.
As you said, using the font tag would make little sense. However, there is more than one way to skin a font-size. Maybe one of the better ways would be to use CSS in the paragraph tags, or even in a span or div tag.
As Don said, Atto is the future. I'd rather not have to deviate from the future and am sure none of the teachers or students using our Moodle are keen on downgrading to TinyMCE either. Furthermore is the question of future compatibility. If you rely on TinyMCE, and that ceases to be core, you'll essentially be stuck.
The decision to remove font-size editing capabilities from Atto was a decision that should be made by a Moodle site admin (if the plugin actually worked, this is where we'd be); the choice shouldn't be limited to either like it or lump it.
Hi Adam,
I have switched the default to Atto on my site, which does not seem to be a problem for teachers that are new to the system. If theywant to use different font sizes, I ask why, and suggest using TinyMCE to do this. I know that TinyMCE will not be there forever, but at that time there will probably be another solution. It may not be at all compatible with the TinyMCE tags, but that is the inherent problem with font specification. In any case, I do not feel a need to make changing font size any easier than it currently is. Oddly, I do not get complaints from students that fonts are not available.
If any of this does make your hair turn gray, you could try uninstalling your hair colour plugin or removing gray as a option if life were only as easy as Moodle.
I think everyone would like an option that works, but it really is not as easy as switching one on. There actually has been considerable work getting a more working solution recently. There were several contributed patches that should make some of the filtering that Atto does much less aggressive and perhaps more useful in the future. (both contributor and integrator/testors deserve thanks)
The font-size plugin above is broken because Atto was changed in the past to filter out the tags because they are not compliant with HTML5. This is also a potential problem with external tools pasting into Atto. Not all will work, and may produce code which does not look consistent across devices or themes.
I understand the frustration that we are having with teachers expectations, but I do not want to see a short term fix that results in Atto producing non HTML5 compliant code that will be difficult to deal with the future, or that students will have difficulty reading on their devices.
Thank you Daniel for this explanation of the problems getting a working, HTML5 compliant solution up and running. Up until now, the only info I could find regarding a fix for the resize plugin is that 1) Moodle HQ decided to remove it from core 2) the plugin has a bug in it and 3) ....... (silence). There has been no word on when or even if work was proceeding to fix the bug.
I'm tempted to take a swing at it myself, though I'm a total newbie in development. It would be good for me to gain some insight into the problems facing the development teams I'm sure.
Eric suggested using a filter to convert font tags to css in Atto. This seems promising to me. I would encourage him and help him with testing if possible. He seems to have the expertise and motivation in this area.
With a commercial product, a salesman may tell you the are working on a problem that you are concerned about only to find out years later it is vaporware. With open source you may have to wait until there is a real idea and consensus on how to proceed.
With a commercial product, a salesman may tell you the are working on a problem that you are concerned about only to find out years later it is vaporware. With open source you may have to wait until there is a real idea and consensus on how to proceed.
Actually, HTML5's major brief, for the first time in an version upgrade to HTML was that it supported all existing tags, HTML5 shouldn't break anything. So it does support the font tag, but prefers to use css to control it. As more developers get used to this, then I expect that by HTML7, the font tag will be deprecated but still accessible. Backwards compatibility was a huge issue for the HTML5 developers.
As for Atto, the reality is it lacks a range of plugins it really needs to be the powerful tool it can become. My suggestion is to revert to TinyMCE, use that until the plugins become available. For these things, a plugin that controls font sizes, another that controls colours, another that controls headings may mean more work for developers, but it is the Users that are important, not the whims of the devs. And using different sizes of fonts and colours is not just handy for language teachers, it is very useful for Science as well, History, English, Geography, Digital Photography and Maths. I know, I have taught all these at one time or another and used this same technique to highlight important things for students.
Right now, I have returned to University to continue my Maths studies and the Uni's Moodle is not yet used by the Maths Faculty in this way, but with a little encouragement from me, I hope it will. Who knows...
Daniel,
the whole Atto plugin was using wrong approach ... and you could fix it
The problem is that modern editors should never output <font> tags - they were deprecated already in HTML4 and are not supported in HTML5 ( http://www.w3schools.com/tags/tag_font.asp ). Font tags were used in old HTMLArea editor and TinyMCE 2 long time ago but TinyMCE 3.0 has using span tags instead of font tags. Because TinyMCE has http://www.tinymce.com/wiki.php/Configuration3x:convert_fonts_to_spans enabled by default it outputs tags like
<span style="font-size: large;">testing</span>
that work fine and are not stripped by Atto.
the whole Atto plugin was using wrong approach ... and you could fix it
The problem is that modern editors should never output <font> tags - they were deprecated already in HTML4 and are not supported in HTML5 ( http://www.w3schools.com/tags/tag_font.asp ). Font tags were used in old HTMLArea editor and TinyMCE 2 long time ago but TinyMCE 3.0 has using span tags instead of font tags. Because TinyMCE has http://www.tinymce.com/wiki.php/Configuration3x:convert_fonts_to_spans enabled by default it outputs tags like
<span style="font-size: large;">testing</span>
that work fine and are not stripped by Atto.
Daniel,
attached the debug file to show how to change the plugin.
The "evil" command in original plugin is in
_changeStyle: function(e, size) {
document.execCommand("fontSize", false, size);
}
that creates font tags. It can be simply changed to
_changeStyle: function(e, size) {
document.execCommand("insertHTML", false, '<span style="font-size:'+size+'">'+document.getSelection()+'</span>');
}
The original plugin has 7 values/names for font-sizes X-Small...XXX-Large and in previous insertHTML command variable size needs to give callbackArgs: size.name (not value)
A more advanced font-size plugin could handle other values as well http://www.w3schools.com/cssref/pr_font_font-size.asp
Hi Mauno,
Last night, I started working on a new plugin based on atto_fontsize that I just called atto_cssfontsize. I'll try using the new _changestyle function you defined here and get back to you later.
I also was looking at the fontcolor plugin for atto. The _changestyle funtion there addresses the CSS directly.
_changeStyle: function(e, color) {
this.get('host').formatSelectionInlineStyle({
color: color
});
}
});
Maybe, I could build and release the plugin myself? That's a scary thought, but I'll try putting my best "newbie" foot forward. Your post, and the code therein, will be invaluable no doubt.
Thanks and thanks in advance to the community for help when I get stuck!
Hi Mauno, Adam et al.
I started looking at this too, then discovered that it had already been done!
https://github.com/papillon326/moodle-atto_fontsize
From my own quick tinkering, using CSS percents rather than xx-small, x-small, medium, large etc also seemed to give more consistent results. Specifically, I found medium gave a slight increase in the displayed font-size, whereas 100% kept the font-size the same.
My only slight variation on Papillon326's solution would be to use slightly larger percentage for the smallest font sizes e.g. 63%, 75%, 89%, 100%, 120%, 150%, 200% (A compromise taken from http://style.cleverchimp.com/font_size_intervals/altintervals.html).
Thank you Geoffrey so much for this!
Naturally, the timing for this post arriving is less than 5 minutes after I finished writing my own plugin based on the old font tag plugin.
https://github.com/adamjenkins/atto_cssfontsize
Mauno, I used your _changestyle function and it worked like a treat! THANK YOU!
The differences between my plugin and papilon's is that mine uses the CSS font-size values x-small, small, medium, large etc rather than percent values.
A huge thanks too to Justin Hunt! Without his help, I would have been stuck for a LONG time.
Writing my first plugin has been an AWESOME learning experience. I never thought I'd be doing this, but now I'm feeling the power!
Thanks to all!
Adam
Glad you are enjoying Moodle development, it is rather addictive!
If I have seen further it is by standing on the shoulders of giants.
In a similar vein, if at a slight tangent, I have also 'borrowed' some of the code ideas from other Atto plugins to style the drop down menu of the Atto Title (Heading) plugin.
So:
text: M.util.get_string(style.text, component),
becomes:
text: '<' + style.text + ' style="line-height:0.5">' + M.util.get_string(style.text, component) + '</' + style.text + '>',
With the result shown on the right:
This is an interesting idea and does look more consistent with the font plugin, but does this work well across browsers. Is having block elements within a drop down something that browser are required to handle in the specification?
So far works with recent versions of Firefox, Chrome and Opera. Will test IE and Safari when I get the chance.
Not entirely sure about block elements in drop downs (though lists are block elements).
Using style="line-height:0.5" was a quick fix to make the menu more compact by reducing the spacing between the block element entries.
As an alternative, would using style="display:inline" avoid any potential block element issues? It does also minimise the spacing between the menu entries.
The inline display style should work well. As long as text in in the text everything should be ok. I am hoping that blockquote will be add to the menu this week, but the freeze is coming so I don't think that your issue can really be added before 3.0.
+1 for blockquote
Actually, although this all works nicely with Moodle 2.7, it's not quite right for Moodle 2.8. The Heading (large) h3 menu entry displays smaller than it should.
Seems there is (in Moodle 2.8) an additional CSS class, .moodle-dialogue h3, with font-size: 14px which overrides the 'default' h3 font-size: 24px (using Clean theme).
Does not seem to be an equivalent .moodle-dialogue for h4, h5, pre, blockquote or p. So, these behave as expected.
Back to some head-scratching...
I think this is from MDL-46250. That rule probably should be prefixed with filepicker class
Thanks Daniel
MDL-46250 is indeed the cause.
As a workaround, I have added a styles.css file to the Atto Title plugin. Also, transferred the display:inline to this file.
So, the JavaScript is now changed to just :
text: '<' + style.text + '>' + M.util.get_string(style.text, component) + '</' + style.text + '>',
and styles.css is:
.atto_title_button .dropdown-menu h3 {
font-size: 24px;
display: inline;
}
.atto_title_button .dropdown-menu h4 {
font-size: 20px;
display: inline;
}
.atto_title_button .dropdown-menu h5 {
font-size: 16px;
display: inline;
}
.atto_title_button .dropdown-menu pre {
font-size: 13px;
display: inline;
}
.atto_title_button .dropdown-menu blockquote {
font-size: 14px;
display: inline;
}
.atto_title_button .dropdown-menu p {
font-size: 12px;
display: inline;
}
If, necessary, styles.css can be tweaked to match a particular theme. Screenshot attached.
In reply to Geoffrey Rowland
Re: WANTED: A font-size option in Atto that works.
by Geoffrey Rowland -
...and, in my hands, works with Chrome, Firefox, Opera, Safari and IE 9, 10 & 11.
> Is having block elements within a drop down something that browser are required to handle in the specification?
Not exactly sure what you mean here. Unlike the Papilon plugin, I used the inline <span> tags for the dropdown menu. Of course these are rendered inside <li> tags, but I was assuming that is standard behaviour.
Any recommendations for improvement?
This is only really a concern with what Geoff was doing with the title plugin. The font sizes are already displayed in inline style.
Ahh, right!
I knew I was getting the wrong end of the stick somewhere. Thanks for clearing that up!
Congratulations Adam, but we are not done yet we are not done just yet. We have a number of approaches. Which one is the right one has to be judged on performance and usability. Do they do what is expected in all user situations and with all browsers.
I tried Adam's latest and the one Geoff referenced with Firefox and found the following problem with using formatSelectionInlineStyle:
- Type some text
- Click in the middle of the text so that the cursor appears in the text
- Change font size with the plugin dropdown
- Type more text
Expected: result: Last text has new size.
Actual result: Last text has old size.
The older code of Adam using insertHTML actually performs correctly in this test, but will create empty spans in the html if nothing is typed.
There may be other issues too - for example if you manage to select part of non closed html tags into your "text selection". Or people may discover some browser specific issues (IE etc)
Some issues can be checked or stripped when you save editor content - see https://tracker.moodle.org/browse/MDL-49564
Anyway this is a good start.
The insert HTML method will not work if there are unclosed tags. The formatSelectionInlineStyle should work fine in that case because the rangy.CssClassApplier class breaks and clones nodes properly to make this work. It might work to be possible to combine the two methods using insertHTML iff this.get('host').isCollapsed.
An alternate method I tried was enabling styleWithCss for the execCommand in the original plugin. This seems to work in Chrome, but Firefox still seemed to use font tags for me. MDL-46955 is resolved as Eric last suggets it could be accept to rely on cleaning the fonts when the browser does not properly support styleWithCss.
Can confirm this behaviour using formatSelectionInlineStyle
In my hands, similar behaviour also holds for the Atto font color and background color plugins that also use formatSelectionInlineStyle.
Had not noticed it before as I usually enter text, then select the section that I want to change before applying the new font size, colour etc.
So, not sure it is a 'show stopper' though it would be good to have behaviour that was as consistent as possible.
> Can confirm this behaviour using formatSelectionInlineStyle
Yes, I found the same thing. However, as this is consistent with the behaviour of several other plugins for atto, my thoughts are that this isn't a big issue. It's probably more important to have consistency within atto than to have consistency with non-atto word processors.
Cheers!
In reply to Geoffrey Rowland
Re: WANTED: A font-size option in Atto that works.
by Mauno Korpelainen -
Thanks Geoffrey!
That plugin does exactly what this kind of plugin should do and it could be modified further to allow (any) % based font sizes.
Personally I feel happy to learn from each case like this where people find different solutions to common problems
_changeStyle: function(e, size) {
this.get('host').formatSelectionInlineStyle({
fontSize: size
});
}
seems to be the preferred "Atto way" of adding formats and it creates nice span tags.
Hi Mauno,
Yes, this was what I was planning to do before seeing your elegant code. Given that as you say it does appear to be the preferred way of doing things, I have changed my version of the plugin to the changeStyle function that goes straight for the CSS.
Both ways worked perfectly, so it matters little. Your way worked first for me!
Thanks again!
https://github.com/adamjenkins/atto_cssfontsize
Hello everyone on this thread,
I have just created a tracker issue for the font-resize bug in atto.
https://tracker.moodle.org/browse/MDL-49752
Please consider going to the tracker and voting for this issue. Also, you may want to encourage any other moodlers you know who are inconvenienced by this bug to vote too. The more the merrier!
Cheers!
Well, now there is A font-size option in Atto that works.
The plugin in the plugins database has been updated with code that changes the CSS rather than adding <font> tags. Feel free to install and play!
https://moodle.org/plugins/view/atto_fontsize
Thanks to everyone! Nice team effort here