Results 1 to 4 of 4

Thread: Ext JS embedded styling is god-awful

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Sencha User
    Join Date
    Jun 2012
    Vote Rating

    Default Ext JS embedded styling is god-awful

    What happened to SoC?

    This is a fantastic framework in every respect bar one.

    Feature request: Abstract.Component: senchaStyling: on/off

    Stuff like this:
    Hard-coded width's in components (textboxes, labels, everything) makes it an absolute nightmare to create self-styled forms. I even found a width=18px, not even a style attribute (textbox error icon).
    SASS, whilst great for building the framework is not an end-user tool IMO. Trying to fathom dependencies is nigh on impossible. I thought I would start with nothing css-wise and add the bits I needed - Lordy, what you have to bring to get a simple alert window on screen (core, window, qtip, frame, header, form, focus, messagebox etc). How many divs can a window need!? Oh, look, now form is in there and boom, there goes my styling.This is absolutely typical of a framework that has so many options, the html output is a nasty splat.

    I'm having to override labelable templates, yank styles out of ext.css using deleteRule and fiddle fiddle fiddle to get my styles right because of x-this and x-that flippin well eveywhere.

    I have wasted man-weeks on this single issue and it is near as damn it the thing that will make me down tools and jump to a-nother JS-lib.

    Someone invented CSS and MVC to separate style from code and markup, but here I am battling against this very problem those things were meant to solve.

    Rant over.

  2. #2
    Sencha - Sr Software Engineer mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Gainesville, FL
    Vote Rating



    Thank you for your honest comments, we take every comment/suggestion/etc we can get into account. My reply is for discussions.

    First thing is about SASS. In my apps (Ext JS 4 and ST 2) and even other things I have done outside of the frameworks I have enjoyed using SASS. The ability to do math, nest classes, use mixins and all the stuff SASS brings to the table is great for me, just my personal opinion that using SASS has made changing colors and icons and such maks a lot of sense to me. Changing a couple variables and the theme can change drastically. I do agree that the classic blue theme is a little dated these days and something that we will be doing better in the future.

    Hard coded sizing. What needs to be taken into account is where the sizes are coming from. Does a component have the width config set to something or did the style come from a layout? If you are inspecting the DOM and see it in the style attributes it doesn't necessarily mean that the width config is set somewhere but it may be the calculated width from a layout. If it comes from a layout then everything is fine and working as it needs to be but if a width config is set then it should really be evaluated if there is something else we can do I would agree with that. Apart from sizing, I would agree that anything style should go in CSS but sizing (includes some things like border, margin and padding) needs to be defined in JS to allow the layouts to properly calculate sizing for components or else you would end up with multiple browser reflows. You would have to inject the DOM elements, get sizes for everything and calculate sizes and then size everything so you have 2 writes and a read for all the components and can drastically affect performance especially in older IEs.

    The HTML markup created is a hard one. If you want something to be configurable it often will mean that extra markup is going to be created to support everything you can do and it's hard to find that middle ground especially since the configurability is at a state where it's at. I think it's something that could be improved but out of scope for 4.1 and 4.2 is already scoped out so it may be a while to be able to do anything about this and may not even make it into 4.x at all at this point. I would like to say that performance is something we take very seriously and something we fight to improve on a daily basis and will always keep fighting. HTML markup is part of that performance fight.

    I would actually be very interested in what you needed to do that you had to spend a large amount of time on. But working on client code I understand if you cannot share anything.
    Mitchell Simoens @LikelyMitch
    Sencha Inc, Senior Software Engineer
    Learn BBCode and use it!

    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2

    Think my support is good? Get more personalized support via a support subscription.

    Need more help with your app? Hire Sencha Services

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Sencha User
    Join Date
    Mar 2008
    Vote Rating

    Default Nightmar(n)ytimesDream


    1. self-styled forms have always been a problem in ExtJs (maybe due to our ignorance), but becomes easier and easier each time a release comes.

    2. Too many divs ? I do agree. Also SPANs. Just today, I almost posted something like : "why buttons have 2 SPANs when I do not need any icon before label ? Maybe developers have good reasons... Would I need a noIconAtAll:true. I would need something like that for every f..king really good stuff ExtJs offers. Performances could be better...

    3. widths (them again...) seem fixed in DOM, but according to Mitchell they depend on layouts. So let them (layouts) doing their job. You can even align with them. Very useful.

    4. You can (unfortunately) consider you'll need the whole ext.js library if you want to build complex apps

    5. Too many options ? I (really) do agree.
    And bugs rely on this options confusion. But end-users and developers are responsible of that.
    You (and I) need something but not always. And a border not as dark as that, please. A bit sharper and padded 1px right... oups, I need a toolbar on my window ? docked bottom, dockable and hideable, but just with visbility:hidden. This is really a nightmare. And particularly for extjs dev team. But this should be enhanced. Some things like 'icon,iconcls,iconalign' could become icon:{url:'',cls:'',align,''}. What about regrouping Css for buttons : 'iconCls,arrowCls,baseCls,cls,componentCls,disabledCls,focusCls,menuActiveCls,overCls,pressedCls', but this may become a worth nightmare.

  4. #4
    Sencha User
    Join Date
    Jun 2012
    Vote Rating


    All good points and I understand why we are where we are.

    Layouts alone I find tough enough. When you do put enuf grey matter into them and finally work out their intricacies, they work really nice, but sometimes I just don't want to use them - for forms there seems no way out, even 'auto' ends up putting 100% widths in (based on it guessing or using a default of 150px for the TD and then telling the input to span 100% aarrghhg no please!). Did u try this on a label, when you are brilliantly given before and after class and style inject options, but the label spans 100% to a fixed width of say 200px for its surrounding TD, the widths of these extras are not taken into account if they live in css.). Troubleshooting that and trying to force changes is awful.

    In the end I've created my own control extensions that are all wrapped inside a formContainer so that I can better size them, even then the default is 'hbox' and you end up with these horrendous absolute containers with width 20k px! aargh, go away!

    I was so far down the line and I wasn't throwing in the towel, because I'm loving models and mvc and form binding, and great validation...but tbh the amount I wasted in styling was twice as much than if id just simply stuck to what I knew with jQuery and jQuery.validator and hard-coded forms and a bit of ajax/json.

    I'd like a "no layout" form layout, that lets me specify a template and in that template I'll use lableEl, a bodyEl and an errorEl, which simply gets set with the labelText, just the html for the input control and the errorMsg. No extra containers, no wrappers, no hard styles, no classes and certainly no tables.

    As for SASS, I like it as a tech, I built my website with it and HAML to give them a go. Both good fun to use, but I personally think the reusability it offers up is overrated I don't actually think it saved me any time nor gave me that much maintability - not enough to warrant the extra training required for team members, the majority of which have never heard of it. Its a lot to ask on top of what is a very steep nuancy learning curve in Ext JS itself.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts