1. #1
    Sencha User
    Join Date
    Apr 2007
    Posts
    49
    Vote Rating
    0
    Green is on a distinguished road

      0  

    Default Feature Request: Font Sizes

    Feature Request: Font Sizes


    Apology for barging in with a feature request first up. So let me first congratulate Ext-Team for a wonderful framework (being a YUI user at the mo and having done in ExtJS in 150 lines and 2 days which took me thousands of lines and 2 weeks in YUI). I'm seriously considering getting a commercial license and/or support (still getting to grips with all the features vs my immediate needs).

    However, and although I saw a few threads already refering to font sizes, I must request a serious look/reconsider on this issue. For people without disabilities it is easy to simply discard the issue in favour of "a nice looking framework" out of the box, but for those with a disability, it will be a huge issue, if even someone whom is seriously sightimpaired could use a ExtJS developed site. Not to mention the current issue this will cause for developing under government contracts which requires to adhere to all sorts of regulations the world over (especially for disabled people).

    For those of you who already have such an issue, I contribute my ext-all.css quick and dirty addition here:
    Code:
    .x-tree-node,.ext-el-mask-msg div,.x-tabs-strip .x-tabs-text,.x-form-field,.x-form-grow-sizer,.x-form-item,
    .x-form-invalid-msg,.x-form fieldset legend,.x-small-editor .x-form-field,.ext-safari .x-small-editor .x-form-field,
    .x-btn,.x-btn button,.x-toolbar td,.x-toolbar span,.x-toolbar input,.x-toolbar div,.x-toolbar select,.x-toolbar label,
    .x-grid-hd-row td, .x-grid-row td,.x-grid-topbar, .x-grid-bottombar,.x-layout-panel-hd-text,.x-dlg .x-dlg-hd,#x-msg-box .x-dlg-bd,
    #x-msg-box .ext-mb-textarea,.x-dd-drag-ghost,.x-tip .x-tip-bd,.x-tip h3,.x-date-middle,.x-date-left,.x-date-right,
    .x-date-inner th,.x-date-inner a,.x-menu-list-item,.x-combo-list-hd,.x-combo-list-item {
        font:normal x-small verdana, arial, helvetica, sans-serif;
    }
    It is not perfect, but at least it responds to browser View->Text Size commands, unlike a default ExtJS site. The x-small font size will basically have very little impact on a default site, but will allow things to grow or shrink at least.

    DISCLAIMER: Have not tested the CSS with all the listed widgets yet, only layouts, toolbars, menus and trees with all four themes, and the tests were not without issues (primarily with real-time refreshing, i.e. live changing of browser Text Size) and a horribly looking toolbar when text is Large

  2. #2
    Sencha User thejoker101's Avatar
    Join Date
    Mar 2007
    Posts
    349
    Vote Rating
    0
    thejoker101 is on a distinguished road

      0  

    Default


    The problem is when you specify your font-sizes in a relative measurement - em, %, x-small - you don't get a consistent look across all the browsers. By specifying it in all in pixels you get the same look - everywhere.

    Furthermore, I don't think there is any reason to coddle IE6 - pretty much the only browser that can't resize font-size specified in pixels. Speaking of which, you can resize font-size in IE6 if you want, just not by default. Just go to Tools > Internet Options > Accessibility and check 'Ignore font sizes specified on Web Pages'. If you want to use a crappy browser, then it's the users job to deal with said crappy-ness. As a web developer, I'm tired of doing it for you.

    That's just my opinion though.

  3. #3
    Sencha User
    Join Date
    Apr 2007
    Posts
    49
    Vote Rating
    0
    Green is on a distinguished road

      0  

    Default


    You do make a solid point joker. Ofcourse, the issue is not limited to IE6, but indeed IE7. Which means all this will continue into the next decade.

    I guess my observation or request is born from YUI's ability to make 'theme'-wide changes to something as primary as the global font-size without adverse effects to any widget. Ofcourse, the debate then reduces to one of looks&productivity (ext) vs flexibility&"lots of work" (yui), i.e. the increase in one will always tend to decreasing the other.

    However, I will then reduce my request to relativity, i.e. if there was one font style all widgets sized relative to, it would greatly enhance flexibility. Especially theme-wise. Currently one is reduced to tally up the different widgets and manually hacking (read: appending) the style for each.

    For example, currently the ext-all.css contains text like "font:bold 12px "sans serif", tahoma, verdana, helvetica;" at least 25+ times, that is around 1250 bytes, essentially doing the same thing. Worst is, not all widgets have the fonts in the same order, some starts of with tahoma, some arial and some sans serif. So it is almost impossible to even get a global font type going across the whole site without overridding them all with another 200 odd bytes. One only needs 1 global declaration, and 25 subsequent ones stating 'larger', 'smaller' and thereby saving the whole of Ext community's site end-users, which could be millions of people downloading the ext-framework into a browser each day, at least 1KB in download each time. Not to mention enabling all developers/themes global control with a single CSS override off the whole framework's font-look&feel. Since CSS1 and definitely CSS2 gives one the power of relativity, why not use it?

    Such a small thing, so easy to implement, such a big difference. Is all I'm saying really

    PS:
    developer, I'm tired
    is idealistic and commendable. Then there is the reality that most of us must develop for a world where if we want to eat we can not prescribe

  4. #4
    Sencha User thejoker101's Avatar
    Join Date
    Mar 2007
    Posts
    349
    Vote Rating
    0
    thejoker101 is on a distinguished road

      0  

    Default


    IE7 does full page zoom, as such, it will resize pixel-based fonts, so the only issue is IE6.

    That being said, I'd agree that the font-styling could be cleaned up a bit. I'm sure this is just so far down the priority list that the Ext team won't get to it for a while.

  5. #5
    Sencha - Community Support Team JeffHowden's Avatar
    Join Date
    Mar 2007
    Location
    Forest Grove, OR
    Posts
    1,038
    Vote Rating
    1
    JeffHowden is on a distinguished road

      0  

    Default


    I'm all for relative sizes, however, I'd caution against the use of keywords as the consistency across browser just isn't there. About the closest you're going to get is to use %.
    Jeff Howden
    Ext JS - Support Team Volunteer
    jeff@extjs.com

    Any and all code samples that are authored by me and posted on the Ext forums or website are hereby released into the public domain and I release anyone or entity of liability by using said code samples unless explicitly stated otherwise.

    Opinions are mine and not necessarily endorsed by Ext, LLC. Please do not contact me directly for assistance unless requested by me.

  6. #6
    Sencha Developer
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    482
    Vote Rating
    1
    Wolfgang is on a distinguished road

      0  

    Default


    Would it be an idea to let Ext calculate the font size based on a base fontsize and to apply the resulting fontsize in px dynamically to the css classes in question? Mabye using a lookup table?

  7. #7
    Sencha User
    Join Date
    Apr 2007
    Posts
    49
    Vote Rating
    0
    Green is on a distinguished road

      0  

    Default


    I see no problem with starting of with a pixel size and then doing things (either using a lookup table) or using percentages. In fact, as wolfgang mentioned, if a specific widget is so closely intertwined with a specific size or font type, it should really be coded and not be in a CSS class where the whole purpose is to manipulate it.

    Besides, this isn't really the issue, from what I can see in the ext css, all specifications are in the range of 11px to 14px. What should really happen is to start from a common STANDARD, i.e. size and font type range, and work from there, ex. "style ext-widget" or at the very least "styles ext-mozilla, ext-ie, etc". The point being "standardization". It can honestly not be a case of messageboxes consciously being chosen to use a different font than toolbar buttons or content panes.

    The cause of all this is most likely that the widgets were developed almost in isolation along with their specific css. Combining them all into a framework bloated the resulting css and messed up any possibility of a global font standard. It is not a case of most widgets only working at some font types and not others. In fact, the majority work quite well at any size or font type.

    My vote would be for something like x-small or 11px Verdana as primary. It seems to have the least impact on the current framework and is one of the better types to use as it scales brilliantly in all directions.

    This issue is inevitable anyway. The larger and more popular the ext framework becomes, the harder it is going to get to not standardize the whole framework, and the more work it will be for the developers and contributors to add widgets which visually 'fit' in the framework without also manually adding their own font specs. My request's purpose is simply to save everyone time down the line and not wait until 500 widgets needs refining/updating because things got 'out of hand' with 15 font types being used and loaded by the browsers. On top of which also comes the previously mentioned advantages of download sizes and easier themed manipulation.

  8. #8
    Ext User
    Join Date
    May 2007
    Location
    Minnesota
    Posts
    66
    Vote Rating
    0
    IGx89 is on a distinguished road

      0  

    Default


    Anything new in this area? In my opinion also this is definitely necessary, especially with monitor pitches becoming smaller and smaller and no matching LASIK improvements

  9. #9
    Ext JS Premium Member
    Join Date
    Mar 2007
    Posts
    11
    Vote Rating
    0
    cpantel is on a distinguished road

      0  

    Default


    YUI's Fonts CSS seems to have a good cross-browser approach to this. They essentially set a base font and then subsequently use percentages to achieve the desired rendered size across multiple browsers. I think this would be a good approach in Ext.

  10. #10
    Sencha User
    Join Date
    Mar 2007
    Location
    Toronto, ON, CA
    Posts
    202
    Vote Rating
    0
    timb is on a distinguished road

      0  

    Default


    Quote Originally Posted by thejoker101 View Post
    IE7 does full page zoom, as such, it will resize pixel-based fonts, so the only issue is IE6.
    The zoom feature in IE7 is pretty buggy. I tried it in my app before seeing this post, and many things just don't work. For example, the menubar (contributed by Animal which is based heavily on the Ext menu) doesn't work, the click event doesn't work for form buttons, dynamically rendered items don't show up where they're supposed to (I can't remember which one at the moment), etc. It's just not an option to use the zoom feature in IE7.

    I developed an app using Ext that is currently in production. The main problem with it (from the users' perspective) is the font size. I'm surprised to see that it isn't easy to change this.

    I'm using border layouts with grids, forms, and the message box class. I'm going to try Green's posted code (thank you for contributing this). I'd be very happy if anyone else can contribute something to help me increase the font size for my whole app, as I need to do this ASAP (my app is in production).

    I would also love to see support for changing font sizes site wide in Ext.

    Note: My users use IE6 only, so I'd be happy with a temp solution that works just with IE6.