1. #1
    Ext User
    Join Date
    Mar 2010
    Posts
    1
    Vote Rating
    0
    agrotron is on a distinguished road

      0  

    Question Bloated HTML

    Bloated HTML


    Dear ExtJS people,

    I am very new to ExtJS and the documentation didt help me with my question:

    Is there a standard way to replace the html generated by ExtJS for its widgets?

    Maybe its the most save way to generate such a table forrest to be sure it looks the same in all browsers, but I would really like to be able to make some kind of lighter-weight "skin" for ExtJS components.

    Sure, its no markup that is send so the browser and thus should not affect accessability/SEO stuff, but the DOM generated that way can become really huge and the responsiveness of the UI can suffer from that. Even on not so slow machines.

    Another point is the ability to tune the visual appearance. There are so many elements with classes wrapped around any little widget. That makes it really annoying to change the visual style with css. Think of the bright future with actually working browsers that allow you to do amasing stuff using css3 etc :-)


    I am thinking about this stuff because I was at T3BOARD10 with the TYPO3 people starting to work on the UI for TYPO3 v5...

    Greetings!

  2. #2
    Ext JS Premium Member stever's Avatar
    Join Date
    Mar 2007
    Posts
    1,406
    Vote Rating
    6
    stever will become famous soon enough stever will become famous soon enough

      0  

    Default


    Most widgets have a template (look at the source of the button, for example) that you can override. I have an experimental one that uses different html for different browsers.

  3. #3
    Sencha User
    Join Date
    Mar 2007
    Location
    London, UK
    Posts
    143
    Vote Rating
    0
    albeva is infamous around these parts albeva is infamous around these parts

      0  

    Default


    I think ExtJS does a pretty good job at balancing the generated "bloat". Compare it to other widget frameworks and you will find that despite seemingly excessive html it still outperforms most other toolkits

    But to be pedantic I think there are ways to optimize the generated code, but at the cost of increased complexity in supporting various browsers as in some cases you would need to generate different html. So writing user extensions / plugins would become potentially a nightmare as you can't be sure of the underlying representation.

  4. #4
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,496
    Vote Rating
    44
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    It gives you what you ask for.

    If you use Panels for everything, you'll get some extra DOM. Panels can do a lot. Top toolbar, bottom toolbar, header, footer, fbar etc.

    If you just need a Container, just use a Container. It's just a div.

    you only get bloat if you use the wrong Component for the job.

    And if you overnnest.

  5. #5
    Sencha User
    Join Date
    Apr 2008
    Posts
    99
    Vote Rating
    0
    Bulle Bas is on a distinguished road

      0  

    Default


    Animal, I do not agree. Saying that nesting panels inside panels gives more bloat is true, but it doesn't mean that the standard components generate clean code.

    For example, the standard exts tree seems to build code

    Code:
    <ul class="x-tree-root-ct x-tree-arrows" id="ext-gen5">
    	<div class="x-tree-root-node">
    	<li class="x-tree-node" id="ext-gen8">
    	<div unselectable="on"
    		class="x-tree-node-el x-unselectable  x-tree-node-expanded"
    		ext:tree-node-id="1" id="extdd-1"
    	><span class="x-tree-node-indent"></span><img
    		class="x-tree-ec-icon x-tree-elbow-end-minus"
    		src="data:image/gif;base64,R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="
    	><img unselectable="on" class="x-tree-node-icon"
    		src="data:image/gif;base64,R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="
    		id="extdd-2"
    	><a tabindex="1" href="" class="x-tree-node-anchor" hidefocus="on"><span
    		unselectable="on" id="extdd-3"
    	>ABSOLUTE ROOT</span></a></div>
    	
    	...etc
    That's a div inside an ul. I cannot imagine that this is ok according to w3c.
    The bigger the dom, the less maintainable.

  6. #6
    Sencha - Community Support Team edspencer's Avatar
    Join Date
    Jan 2009
    Location
    Palo Alto, California
    Posts
    1,939
    Vote Rating
    7
    edspencer is a jewel in the rough edspencer is a jewel in the rough edspencer is a jewel in the rough

      0  

    Default


    In almost all cases the 'bloated' HTML is required to make Ext JS work across all of the browsers we support. There are instances we've identified where we can reduce the number of DOM elements created, and we're doing so where we find them.
    Ext JS Senior Software Architect
    Personal Blog: http://edspencer.net
    Twitter: http://twitter.com/edspencer
    Github: http://github.com/edspencer

  7. #7
    Ext JS Premium Member stever's Avatar
    Join Date
    Mar 2007
    Posts
    1,406
    Vote Rating
    6
    stever will become famous soon enough stever will become famous soon enough

      0  

    Default


    Quote Originally Posted by Bulle Bas View Post
    That's a div inside an ul. I cannot imagine that this is ok according to w3c.
    The bigger the dom, the less maintainable.
    I'm pretty sure this is done to handle IE6's broken CSS implementation that doesn't allow child selectors or handle multiple-class-on-the-same-object css rules. The alternative is to make the CSS more complex. That is, double all the CSS rules, making IE6 variants that handle the above more complex html, and another set for the more streamlined html. In fact, I would use the IE6 type html and css for all browsers before IE9/Firefox3.6/etc. And have the streamlined version for these newer ones (which have border-radius, and all that good stuff).

    In fact, you could make support for the older browsers an override file. Thus you wouldn't need to include it when sending to an iPhone, for example.

  8. #8
    Sencha User
    Join Date
    Mar 2007
    Posts
    160
    Vote Rating
    0
    alindsay55661 is on a distinguished road

      0  

    Default


    Quote Originally Posted by stever View Post

    In fact, you could make support for the older browsers an override file. Thus you wouldn't need to include it when sending to an iPhone, for example.
    Great idea, move the bloat into its own file. Then users who don't need support for it can exclude it.

  9. #9
    Ext JS Premium Member thomasf's Avatar
    Join Date
    Feb 2008
    Location
    Vienna
    Posts
    63
    Vote Rating
    0
    thomasf is on a distinguished road

      0  

  10. #10
    Ext JS Premium Member stever's Avatar
    Join Date
    Mar 2007
    Posts
    1,406
    Vote Rating
    6
    stever will become famous soon enough stever will become famous soon enough

      0  

    Default


    Quote Originally Posted by alindsay55661 View Post
    Great idea, move the bloat into its own file. Then users who don't need support for it can exclude it.
    Yeah, I think things could be done in a matter that supports "Year 2010" browsers or "CSS3" browsers as the slim and fast default. Much HTML bloat is due to the needs of CSS cross browser, and that could be done through extra files (one JS and one CSS).