macheide (macheide) wrote in xxcustomization,

More Toward a Policy on Localized Font Size Customization

Replacing <font> with <span> is a relatively easy switch for font color. So for example, the comment link FAQ override for the Tabular Indent style, which uses <font> can be easily upgraded; and customization support questions dealing with comment links for Tabular Indent ought similarly to use <span> versus <font>.

With font size, the upgrade might be slightly more complicated. The old SIZE attribute of the font tag seems to presuppose a 12-point font. On that basis, the <font size="1"> of the comment link FAQ override for Punquin should be usually replaced with <span style="font-size:.65em"> if the user's page is to remain the same after the override (with the exception of new text) as before the override. However, if the user likes smaller font size overall and has used a global head override to switch to 10-point as the overall font size, then to make a comment link override that will only change the text, not the relative size, the tag should be <span style="font-size:.75em">. (Side note: Technically, the template for the Default style uses <font size=-2">, which has the same effect as >font size="1"> and behaves similarly for the potential <span> replacements. But for Notepad, the original comment links had no re-sizing at all, so technically the current FAQ would yield not only a text change if 'only' the words were modified, but a size change as well.)

So far, when I've seen customization support that uses the <span> tag, the advice usually presumes explicit re-setting of the size in the particular area of focus, such as with <span style="font-size:11pt"> instead of using the relative 'em' setting. In those cases, if the user eventually were to re-size the font for the entire journal, each such local setting might need independent attention, versus the dynamic relative re-sizing of the old <font size="n"> tag or the new <span style="font-size:--em"> approach. If that's how it needs to be, so be it; but then it might not be a bad idea to at least alert the user that you've not simply replaced an obsolete code with a new one, but you've also changed the way they're controlling their page.

Of somewhat more headache to me is that although I really want to make the <font> obsolescence an acknowledged policy for customization support, there's that <font size="1"> sitting there in the comment link FAQ code for Default, Punquin, and Notepad. And as I've noted, it's got to be rather discomfitting to some support volunteers to have their screened responses rejected when the FAQ and the style templates themselves use <font> heavily. So if I pull together a proposed change to the FAQ, do I presume the standard 12-point and replace <font size="1"> with <span style="font-size:.65em">? That might work for general FAQ, with any detailed assistance to depend on individual overrides about as much as we already do, even though we're eventually bound to run across users who have first done a global head override setting global font size, then find that using a comment link override can inadvertantly change more than the text. And obviously, any change from <font size="1"> in the Punquin template itself to <span style="font-size:.65em"> could unintentionally make a blanket change to scores of users' pages.

And I'm completely clueless about how much of all this might be browser-specific or platform-specific.

I know this can feel a bit like going in circles, and sooner or later I'm just going to make the no-<font> a general policy, recommend changes to FAQ, and then recommend changes to the style templates, probably in that order, and just be prepared for the inevitable ruffles here and there. Just, it's so easy to reject <font> responses, but not so easy to say what the general rule of thumb should be for the proper replacement.
  • Post a new comment


    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment