1. #1
    Ext JS Premium Member neongrau's Avatar
    Join Date
    Mar 2007
    Posts
    249
    Vote Rating
    0
    neongrau is on a distinguished road

      0  

    Question HTML changes in 4.1 vs. 4.0.x

    HTML changes in 4.1 vs. 4.0.x


    can someone please explain the motivation in moving towards TABLE layouts in 4.1 where previous ExtJS versions had clean DIV constructs?

    For years webdevs were preaching that TABLE layouts are the most evil and unprofessional thing.


  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,633
    Vote Rating
    817
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    I'm not sure why people have something against <table>. It has provided us with a more consistant layout cross-browser.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    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 - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    4,800
    Vote Rating
    167
    slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold

      0  

    Default


    consistant layout cross-browser > webdev sermons

  4. #4
    Sencha User
    Join Date
    Apr 2008
    Posts
    20
    Vote Rating
    1
    gilfeather is on a distinguished road

      0  

    Default


    This was done so that developers have something to work on? Without change projects might get done and then what?

    It was rather glib to just redo all of the field layouts sometime after 4.1A1. I didn't see much fanfare or explanation. We were just left to figure it out, do some reverse engineering, and then modify all of our css, style settings, and class properties. For those of us who also had custom field layouts,etc. it was just more non-productive work.

    At some point Sencha will figure out that they are writing a commericial production level framework that people pay for and use to increase their own productivity. Constant churning just to keep up with seemingly arbitrary framework changes is very worisome. Despite Sencha's protestations of improvement it does not seem to be getting better. YMMV

  5. #5
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,633
    Vote Rating
    817
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    A lot happened between PR1 and beta 1 including the introduction of a form layout to Ext JS 4.

    Looking at the release notes for 4.1.0 beta 1 there is a heading "Fields and Their Layouts" and within it:

    In 4.0 and 4.1 PR1 field layouts were a rather complex balance of positioning, floating and measurement with subtle timing dependencies. In Beta 1, field layouts have been modified extensively to allow the browser to do much more of this work. To support IE6 this required the use of tables. There are still some calculations required, typically around height, but this approach eliminated lots of calculation and measurement that we previously had to perform on each field, the cost of which added up quickly.
    We have been forthcoming that layouts changed dramatically and this was actually the reason for an early PR release back in Oct 2011 so that people would see where the framework was going. We said that custom layouts will most likely break and we were sorry for this but sometimes things like this has to happen for the better of the framework, we don't want to break code but admittedly performance wasn't where we wanted it and this is the route we choose to improve performance.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    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.

  6. #6
    Ext JS Premium Member neongrau's Avatar
    Join Date
    Mar 2007
    Posts
    249
    Vote Rating
    0
    neongrau is on a distinguished road

      0  

    Default


    For me IE6 isn't supported anymore and i got the ok to ignore it, IE7-8 is enough hassle to support.

    My personal concern is that on older machines with Firefox being the slowest of the bunch. Will not respond well to get more TABLEs thrown at him. From my experience nested table constructs makes Firefox slow. This may not get noticed on current intel i3/i5/i7 but alot on Pentium4/Centrino and even Core(2) Duos.

    Yesterday i tested my app against 4.1RC1 and when i inspected the broken Inputs and SearchFields i was pretty shocked to see the lightweight of 3-4 DIVs being replaced with a massive blob of nested TABLE markup.

    Although i could not see or feel any speed improvement in IE or Chrome, and my only problem the misplaced and wrong-sized LoadMasks weren't even fixed i'm wondering for what gain i'll be looking into migrating to 4.1.

    I don't envy you guys for having to support IE6, i know a bunch of your customers require it.
    But IMHO you should think about encapsulating IE6 support with a special build and an extra set of CSS. So those that don't need it anymore don't have to suffer with sub-optimal trade-offs.

    Maybe charge a premium for those IE6 builds since you have to invest a lot of more work fo it.

  7. #7
    Sencha - Ext JS Dev Team evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    16,662
    Vote Rating
    584
    evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute

      0  

    Default


    It's not really IE6 that's the problem. Pretty much all versions (even up to 9) have a whole bunch of issues where the solution is mostly the same across the board. The versions get better as time progresses, but to support IE6 when you're already supporting 7 isn't that much of a big deal.

    Then there's quirks vs standards mode... ugh!
    Evan Trimboli
    Sencha Developer
    Twitter - @evantrimboli
    Don't be afraid of the source code!

  8. #8
    Ext JS Premium Member neongrau's Avatar
    Join Date
    Mar 2007
    Posts
    249
    Vote Rating
    0
    neongrau is on a distinguished road

      0  

    Default


    Lack of alpha transparency in IE6 is the biggest problem and the hassles with poor CSS selector support. But yeah, even IE9 is still a horrible tool to work with and IE10 won't be the cure either. I wish they'd cancel IE altogether and start fresh with a new browser

    These days i try to leave out useless eye-candy on IE wherever possible. Shadows and rounded-corners are made with CSS3, if the browser can't do that - so be it. If the function is still there the IE users can live with pointy edges and plain looking boxes. Eye-candy and snappy performance is just a Browser download away.

  9. #9
    Ext JS Premium Member
    Join Date
    Sep 2009
    Posts
    164
    Vote Rating
    1
    michael melsen is on a distinguished road

      0  

    Default this is a serious problem for us (and other people supporting wcag 2)

    this is a serious problem for us (and other people supporting wcag 2)


    Hi guys,

    "can someone please explain the motivation in moving towards TABLE layouts in 4.1 where previous ExtJS versions had clean DIV constructs?"

    if this is true this could cause serious problems in supporting WCAG 2.0. One part of WCAG which is used to support accessibility is, states that the use of table elements should be used :

    "to present tabular information in a way that preserves relationships within the information even when users cannot see the table or the presentation format is changed. Information is considered tabular when logical relationships among text, numbers, images, or other data exist in two dimensions (vertical and horizontal). These relationships are represented in columns and rows, and the columns and rows must be recognizable in order for the logical relationships to be perceived." see http://www.w3.org/TR/WCAG20-TECHS/H51.html

    so when table elements are used instead of divs to make up widgets and stuff, this could cause screenreaders to read this layout stuff too.

    On WCAG's site:

    "Suppose that a Web page is laid out using a table with 9 columns and 22 rows. The screen reader speaks the content of the cell at Column 1, Row 1 followed by the cells in columns 2, 3, 4 and so on to column 9. However, if any cell contains a nested table, the screen reader will read the entire nested table before it reads the next cell in the original (outer) table. For example, if the cell at column 3, row 6 contains a table with 6 columns and 5 rows, all of those cells will be read before Column 4, Row 6 of the original (outer) table. As a result, the meaningful sequence conveyed through visual presentation may not be perceivable when the content is spoken by a screen reader." see http://www.w3.org/TR/WCAG20-TECHS/F49.html

    can someone confirm if the use of table layouts interferes with the wcag rules?

    regards,

    Michael

  10. #10
    Sencha User
    Join Date
    Jul 2011
    Posts
    12
    Vote Rating
    0
    stan.cristian88 is on a distinguished road

      0  

    Default


    I just came to this forum to post exactly the same question. Ok, I undestand you need to support IE6 and maybe the change to the table layout was a good thing for this. But I was using a custom layout that extended table because it was the lightest and fastest (rendering a window with column layout vs table was 2-3 time slower on firefox).
    So if this was a really necessary step, then anyone has a suggestion what should I do so in the next version I would be able to use this layout?
    The requirement is that there are some form items (textfields, combos, radios, etc) arranged in 2 columns - and some on just one (big textareas). Of course the first option was to use column layout, but it was really slow. Table layout was much faster but the items had a fixed width - it has to be relative to the layout column size and change on resize window. So I just made an override to the method renderItems and before callParent, I just iterated all the items and did this:
    Code:
          var totalWidth = this.getLayoutTargetSize().width;
          ...
          item.width = Math.floor(totalWidth/2) - this.customMargin;
    Of course that now with the new table in table inception this will not work. I would be grateful if somebody has a suggestion with an easy fix.