WYSINWYG as far as font sizes go...

Hangin' Around Joined: Nov 06, 2002 Posts: 32

Quick question regarding WYSIWYG. When I edit a block, say a center block - in the editor, I can clearly see that the font size is X-Large and it is Comic Sans. Yet when I save it and go back to the Home page, it is tiny again. What am I missing as far as making What I See What I REALLY get. Thanks in advance for any help on this.
Mike

Posted: Sat Mar 31, 2007 6:49 am

This is strange, but I can confirm what you are saying. I just went in and edited the first article on my test site for RN2.10, fkelly.org. I selected the text (I was testing the ampersand issue with that article) and changed it to extra large, comic sans. Saved it. Went to the home page and it was still "normal" sized. Went back into the editor and looked at source. It does have the font size and type tags around the text but for some reason it's not appearing on the home page. I'll keep looking but we may need Kguske to help with this ... though actually the editor seems to be doing what it's supposed to, it's the presentation that's not working properly.

Posted: Sat Mar 31, 2007 7:08 am

Wow. I looked further, looked at view source and in the source the text is wrapped inside the appropriate font code. That font code is in turn wrapped inside a couple of divs one of which has the class=content. I was thinking maybe the class was overriding the font so I saved the source html file and went in and edited it and took the divs out of that area. Still no joy, the comic sans isn't showing. I even edited the text a bit to be sure I wasn't seeing a cache artifact and the new text is there. Humm ... I wonder if that font might be missing from our systems. I'll be back.

Posted: Sat Mar 31, 2007 7:19 am

No, missing font doesn't have anything to do with it. I can change the font color and it works fine. I even tried wrapping the text in a h1 tag and, though the tag is there it doesn't affect the size of the font. Very odd. I even tried out IE to see if it was a browser specific issue and the same problem occurs. I also edited the opening message on my test site and the same problem occurs there as in news.

It's hard to understand how this could have slipped thru all the testing we did so I'm still looking for a different explanation.

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

Without looking at it, I'd say fkelly was on the right track regarding CSS overriding the font.

Posted: Sat Mar 31, 2007 12:37 pm

I'm not sure Kguske. Cause when I saved my page as html and went in an manually edited the styles out the font size still didn't work. And, looking up font size thru Google shows that there are a fair number of experts saying we shouldn't be using that anyway.

Manually I can get most of the font attributes to work, like color, but when I put size in it has no effect. Very strange. Maybe I will try a "pure" html document because even taking the "immediately adjacent" styles out might leave some others still in effect.

Posted: Sat Mar 31, 2007 1:03 pm

I am starting to lean towards the CSS override as well. I have two new sites that have different themes. One of them works for font sizing and one doesn't. I'm going to compare the CSS files of each and report back here on any differences.

Posted: Sat Mar 31, 2007 1:10 pm

I think the problem is that we put font sizes in style.css, so for instance we have:

font {font-family: Verdana,Helvetica,sans-serif; font-size: 10px}

in the style.css for fisubice. I suspect this is overriding any explicitly coded size.

In fact, I just edited style.css for fisubice to eliminate the size from the font class in the style file and uploaded it to fkelly.org and the size attributes in the font tag now work.

I don't know what the other implications of removing this from the style.css would be, but it does seem to fix this one problem.

Posted: Sat Mar 31, 2007 2:52 pm

I copied over the css file from a theme that allowed me to use the different font sizes and it worked flawlessly. Didn't have the time to compare the code, but I can guarantee that it is indeed the css file overriding nuke...

Posted: Sat Mar 31, 2007 3:31 pm

I have made just the one change I mentioned, removing the font-size from the style.css in fisubice and tested on fkelly.org. It seems to solve the problem. Whether the font-size should be in some other styles there is an open question to me.

Before:

Code:

font {font-family: Verdana,Helvetica,sans-serif; font-size: 10px}

after:

Code:

font {font-family: Verdana,Helvetica,sans-serif}

I looked at the Nukenews theme too and tried the same fix out. The font size was not showing up (in other words being overridden by the style) before I made the change and it is showing up after.

We probably need to make the same change to other themes but I'd want Raven and/or Montego and others to look at this first and see if they see any problems and/or if we should remove the font-size from td body p etc.

Posted: Sun Apr 01, 2007 6:20 am

I was going to suggest removing references to the css file, or temporarily making it empty. But it seems you've confirmed that's where the issue is.

As for removing the font size from the CSS, another option is to create additional classes with the appropriate font size and specify those in the content, rather than overriding the font size.

Posted: Sun Apr 01, 2007 6:57 am

The only thing that concerns me is if font requires the use of an explicit size in CSS to validate - I'll have to check on that.

Creating a new font class would seem to be the best option as you said Smile

Posted: Sun Apr 01, 2007 7:09 am

Let us know Guardian. Kguske, yes, that would work but I was trying to keep the "size" of the fix down. If we can fix this problem by just removing one attribute from one class in each style.css where it occurs that would seem to me to be desirable short term. Users would need very little PHP expertise to make those changes themselves and the probability of fouling up "other things" would be minimized.

Many references on the web state that we shouldn't be sticking in font-size="whatever" tags outside of classes in our documents anyway. But straightening that out is probably something we should build into the next release. I think that right now the wysiwyg editor puts such codes in when a user choses a font size but I'd need to double check to be sure.

registered · Posted: Sun Apr 01, 2007 10:13 am

Maybe the WYSIWYG editor should be configured to wrap text in its own classes for size and colors (e.g. span tags). Font tags are evil, according to the latest dogma. Wink

Then we could add a wysiwyg.css link to header.php.

Posted: Mon Apr 02, 2007 2:41 pm

Danger, Will Robinson!

That would be a good deal of work and it would likely cause conflicts with most themes...

Posted: Mon Apr 02, 2007 5:29 pm

And removing font sizes from all themes isn't a lot of work? Wink

I don't know how hard it is to make the editor spit out span tags with classes instead of font tags...but is it that bad?

And then the classes in wysiwyg.css would be suitably named so as to not conflict with existing themes.

E.g.

span.wysiwyg-large { font-size: large; }
span.wysiwyg-xlarge {font-size: x-large; }

I'm just rambling but that is my idea. It's using CSS they way it was supposed to be IMHO.

Posted: Mon Apr 02, 2007 5:38 pm

I could remove font sizes from all themes style.css files in ... oh ... probably a half hour and have them back to the svn in that time too. We would want to run thru and test them all that way but I don't think there would be complications. Famous last words (:

However, users who have the problem bothering them probably have enough information at this point to make their own adjustments (a.k.a. hacks). There are really two issues in my mind at this point:

1. Why did we stick font-size into those classes in the css in the first place? And is that a good idea? They go beyond just the "font" class to a bunch of others. I'm not a css expert by any means but that just doesn't look like a good idea to me and it permeates the themes.

2. How difficult is it to adjust the editor as Gremmie suggested and is that the best approach.

We are relatively early in a new release cycle and coming up with the "best" solution at this point takes priority. I think.

Posted: Mon Apr 02, 2007 5:42 pm

If the wysiwyg editor continues to spit out font tags, then folks with custom themes are likely going to run into the same problem. If the wysiwyg editor emits span tags with classes, and the classes have unique enough names, I can't imagine their theme being able to override the editor, and it will work for everyone.

Posted: Mon Apr 02, 2007 6:11 pm

If you use FireFox, you can trying this setting in includes/FCKeditor/fckconfig.js:

Code:

FCKConfig.GeckoUseSPAN   = true ;

registered · Posted: Mon Apr 02, 2007 6:39 pm

Hopefully the editor is smart enough to not try and SPAN across a block tag... can you spell compliance issue? Sad

(My God, I sound more and more like Steph with each passing day... )

Posted: Mon Apr 02, 2007 7:07 pm

The problem with that setting is that it gives different results for IE and FF.