Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: CSS interference

    Looks like we cannot reproduce this. Please provide another test case to reproduce this issue.
  1. #1
    Ext JS Premium Member
    Join Date
    Feb 2008
    Location
    Feuerthalen, Switzerland
    Posts
    30
    Vote Rating
    0
      0  

    Default CSS interference

    First of all I want to tell you that Im a really big fan of extjs and ext4 looks very impressive!! Good job!

    We have a problem with the ext builtin css styles. It was a problem in ext3 but it is seams that in ext4 it becomes even bigger.

    Normally we work with the html5 doctype <!DOCTYPE HTML> that forces every common browser (ff, safari, ie4-9, ) to use the same boxmodel. Ext4 seams to automatically apped a calss to the body that changes the box model for the whole page (box-sizing: border-box. We use ext within our ContentManagementSystem which has to run parallel to the custom templates of our customers. The CMS is ext-window-based and runs directly on the customers content pages and does not have a separate backend. That is why we have to implement the ext CSS parallel to our customers CSS and that is why the global Style-Definitions in ext are interfering with our custom CSS styles. It is very unsexy to specifically overwrite every ext-CSS-Definition.

    If we specifically overwrite all ext css the way we need it, for example within our content-area (like #content strong { ... }), it is no longer possible to have ext components (like buttons) in the same container as our content because that would break the ext components layout.

    It isnt just the box model, it is the other CSS definitions as well for example all browsers render b-Tags and strong-Tags bold, thats as it is and no one has to define those tags in his CSS because it is not necessary. Since ext makes all those tags to look like normal unstyled text everyone using ext has to specifically define those standard tags aswell.

    Why dont you just leave all global CSS as it is, add a class to all ext components like x-component and then make CSS definitions affecting only those classes?

    That means your styles would change from this:
    .ext-forced-border-box,
    .ext-forced-border-box * {
    box-sizing: border-box;
    -moz-box-sizing: border-box;
    -ms-box-sizing: border-box;
    -webkit-box-sizing: border-box;
    }

    ... to something like this:
    .ext-forced-border-box .x-component,
    .ext-forced-border-box .x-component * {
    box-sizing: border-box;
    -moz-box-sizing: border-box;
    -ms-box-sizing: border-box;
    -webkit-box-sizing: border-box;
    }

    This would solve all interfearence problems in most environments.

  2. #2
    Sencha User Phil.Strong's Avatar
    Join Date
    Mar 2007
    Location
    Olney, MD
    Posts
    1,953
    Vote Rating
    65
      0  

    Default

    Seems like your talking about the reset that extjs performs. This is pretty standard and in fact super important for Sencha to be able to deliver cross browser compatibility.

  3. #3
    Sencha User
    Join Date
    Apr 2012
    Location
    Austin, Texas
    Posts
    4
    Vote Rating
    1
      0  

    Default

    Reset in general has been in Ext since the beginning and is not going to change. It's required for consistent x-browser layouts.

    Regarding the border-box rules, those definitely need to be scoped to the Ext components only, even for our new sandboxing to work correctly. Having those scoped to * was simply an oversight and will be fixed before 4.0 ships.

  4. #4
    Sencha User
    Join Date
    Mar 2007
    Location
    Haarlem, Netherlands
    Posts
    1,243
    Vote Rating
    11
      0  

    Default

    We will set up scoping for the resetting css to just apply to Ext components before the final release. It just hasn't made it in in time for the preview release.

  5. #5
    Ext JS Premium Member
    Join Date
    Feb 2008
    Location
    Feuerthalen, Switzerland
    Posts
    30
    Vote Rating
    0
      0  

    Default

    Thank you for your comments and for moving my issue to the bugs section ... obviously it is on the right place here.
    It would be great if this "reset" would be affecting the ext components only Im looking forward to the final release of ext version 4!

    If you are changing the css in that manner it would be great if you could restrict not only the box-model to the ext-components but also the other "reset"-styles that were affecting the whole page in ext3 on line 7 in ext-all.css:
    html,body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,input,p,blockquote,th,td{margin:0;padding:0;}img,body,html{border:0;}address,caption,cite,code,dfn,em,strong,th,var{font-style:normal;font-weight:normal;}ol,ul {list-style:none;}caption,th {text-align:left;}h1,h2,h3,h4,h5,h6{font-size:100%;}q:before,q:after{content:'';}

    I mean, why should anyone want his "strong"-tags do render with "font-weight:normal;" or the headings (1-x) to render with "font-size:100%;" that should be restricted to the ext-components and not to the "global styles".

  6. #6
    Sencha User
    Join Date
    Mar 2007
    Location
    Haarlem, Netherlands
    Posts
    1,243
    Vote Rating
    11
      0  

    Default

    When I said scoping the resetting CSS I meant both the .box styles and the html, body etc etc. So yes, they will be scoped as well

  7. #7
    Ext JS Premium Member sebsei's Avatar
    Join Date
    May 2007
    Location
    Copenhagen, Denmark
    Posts
    69
    Vote Rating
    0
      0  

    Default

    Hi Tommy

    Has this really been fixed in Beta1?

    I'm seeing the following lines in ext-all-debug.css:

    Code:
    /* line 131, ../themes/stylesheets/ext4/default/core/_reset.scss */
    .x-border-box .x-reset,
    .x-border-box .x-reset * {
      box-sizing: border-box;
      -moz-box-sizing: border-box;
      -ms-box-sizing: border-box;
      -webkit-box-sizing: border-box;
    }

  8. #8
    Sencha User edykstra's Avatar
    Join Date
    Feb 2009
    Posts
    98
    Vote Rating
    2
      0  

    Default

    Hello,

    I am still seeing issues with this in 4.0.2a. Am I mistaken (and the root cause of my issue is something else) or am I correct? Will it be fixed in the next public release and when is that?

    Thanks,

    Eric

  9. #9
    Sencha User
    Join Date
    Aug 2011
    Posts
    2
    Vote Rating
    0
      0  

    Default

    This is still a bug in 4.0.2a; The border-box model should be applied to the components only (as stated above), but it is applied to *everything*.

  10. #10
    Sencha User edykstra's Avatar
    Join Date
    Feb 2009
    Posts
    98
    Vote Rating
    2
      0  

    Default

    Hey - thanks for the confirmation. Any idea what the best work-around is?

Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 7
    Last Post: 15 Feb 2010, 12:35 PM
  2. [FIXED][3.0rc2] xhtml incompatibility fixed
    By menasce in forum Ext 3.x: Bugs
    Replies: 4
    Last Post: 1 Jul 2009, 6:10 AM
  3. Interference with two AJAX requests
    By Crusy in forum Ext 3.x: Help & Discussion
    Replies: 5
    Last Post: 9 Jun 2009, 7:54 AM
  4. [2.0b1][FIXED] WindowManager z-Index bug (fixed in RC1)
    By dafimoto in forum Ext 2.x: Bugs
    Replies: 8
    Last Post: 1 Jul 2008, 3:42 AM
  5. [FIXED] TextArea has fixed height?
    By gslender in forum Ext GWT: Bugs (1.x)
    Replies: 4
    Last Post: 29 Apr 2008, 8:11 PM

Posting Permissions

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