PDA

View Full Version : YUI reset-fonts-grids-min.css breaks yiu-ext grids



Wolfgang
16 Dec 2006, 3:20 AM
Hello,

When using the css from yui "reset-fonts-grids-min.css" it breaks yui-ext especially the grid when using borderlayout.
This happens also when the yui style is loaded before the yui-ext.css style.

The behaviour is slightly different in IE6 and Firefox 1.5.
For example, using complex.html from yui-ext, IE does not render all columms of the grid in east after load, but renders when one item is clicked. But then resizing does not work proper.
In Firefox, it looks ok.

Another effect: when adding a grid to the center region via the panel, it fails in bot FF and IE.

I am not sure wether to treat this as a bug, but since "reset-fonts-grids-min.css" is used in most yui projects i might be worth to mention.



Regards

Wolfgang

jack.slocum
16 Dec 2006, 9:55 AM
Including grids.css i na layout page isn't a great idea because of this line:
body{text-align:center;}

It then expects you to use a grids container to override it. You could override that manually on a lower stylesheet. I'm not sure about the rest of it.

yui-ext.css includes a very slightly customized reset-min.css already.

hunkybill
16 Dec 2006, 2:13 PM
I have noticed some issues with borderlayout+grids when using YUI grid.css. So far, it has not resulted in too much pain, although that is more due to me turning a blind eye to IE and some details. The amount of CSS is boggling to make a 'simple' app, something a lot of CSS evangelists might not want to hear.

Not that this is the fault of Yahoo, Jack Slocum or anyone else for that matter... but when you fire up YUI, yui-ext and then throw down BorderLayout, Grids, Basic Dialog, and then try and customize or debug.. it gets pretty hairy pretty fast. And that's after Jack adopted some nice CSS styles!

My example currently driving me nuts involves in-place editing grids. Excellent way to replace typical forms. A simple grid in a Content Panel with in-place text editing has a nice blinky cursor in the input box. Works fine. I have a toolbar button click that shows a LayoutDialog with a layout inside it, and a grid there with some editable properties.. and while I can colorize the input box, change the font, border it, etc. etc.. I cannot for the life of me get a cursor in there... and that sucks for editing text. I followed the lead by making sure to define the .ygrid-col-# {} classes for each grid too...

Long story short.. sometimes I feel like I have no choice but to manually cut the generated DOM nodes out and go through the CSS hierarchy to try and figure out where the disconnect is.. knowing full well this could be one of a million silly things, like a browser bug.. etc... All that.. just for a blinking cursor in a text box.. and meanwhile.. there are ten thousand other more important things to design, develop, test, wire up....

And then you have the clients... why is making a web page taking so long... :) it's just a web page isn't it :)....

Wolfgang
16 Dec 2006, 2:35 PM
Hello,

@jacksloc
Thank you for the hint with grid.css, i'll take care of this.

@hunkybill
So much truth in what you wrote. Actually i try to build a prove of concept implementation of an existing and working application using yui and this _fantastic_ yui-ext framework.

Borderlayout and grids give a look and feel that is really close to a native gui application.
But, what has been some lines of well structured php code before, turns into little "javascript monster" :wink: .Since i am used to work with php and perl but not javascript, this is still a challenge.

Regards

Wolfgang

jack.slocum
17 Dec 2006, 1:49 PM
FYI, I finally tracked down the cause of the FF missing cursor and a workaround is in the svn trunk. No code changes neccessary. :)

hunkybill
17 Dec 2006, 6:51 PM
Right on! I disemboweled my LayoutDialog with a PropsGrid in it.. and found the <input> tags were embedded in class .ygrid-wrap. I was so excited to try the suggested workaround of putting overflow:auto in there.. only to find that done. Sigh.. and hearing Gecko team talk of waiting for FF3.0 for the fix, that's depressing. I updated my SVN YUI, did a build, copied yui-ext in, plus the css resources from SVN.. same problem. Not sure what's up with that. LayoutDialog looks good. PropsGrid loads nice. Columns and data are there. Validation works.. only the damn FF cursor is AWOL...

jack.slocum
18 Dec 2006, 10:15 AM
I found out the problem is still there on FireFox 1.5 PC. Everywhere else is fixed. It's a start.

hunkybill
18 Dec 2006, 1:24 PM
Hi,

It is very nice that the issue is under investigation. I am sure there will be a Eureka moment at some point, hopefully without too much work!!

Thanks!!

brian.moeskau
18 Dec 2006, 9:18 PM
"The amount of CSS is boggling to make a 'simple' app, something a lot of CSS evangelists might not want to hear. "

I couldn't let that pass without a comment... Yes, modern layouts take a lot of css. But the alternative is simply moving it all into html tags/attributes, or to have simple, uninspired layouts. Not sure that would be any better. I think the real issue is not the quantity of the css, but simply the struggle of muddling through a large body of code you didn't write, trying to make sense of it all when you have to make a change. The css itself is a good thing though :)

-Brian

hunkybill
18 Dec 2006, 10:22 PM
I think the real issue is not the quantity of the css, but simply the struggle of muddling through a large body of code you didn't write, trying to make sense of it all when you have to make a change. The css itself is a good thing though

I wrote my first game in TRS_DOS Basic on a 1 MHZ Z-80 with 4K RAM in or around 1980... I wish I had CSS back then too, instead of PEEK and POKE.. It's true that sometimes it can be hard to decipher other peoples code. I am not having trouble understanding CSS so much as that I still think there is room for improvements if small teams of enthusiasts are to deliver useful apps of any substance.

After all that debugging... turns out I simply blew time on a FF bug. My fault, me bad!! Should have ignored the problem, but that is not in my nature. When it is something out of almost all our hands, in the end, that is the worst thing. The constantly moving gold standard. As we progress (these YUI-ext layouts are fantastico!!), we run into things like browsers with thousands of known bugs that cannot render 100% correct agreed upon standard HTML, even after three or four years of time has passed. Surely as a .Net developer you've experience a few things about IE that maybe bug you?

Not sure there exists another domain where the pace of change is so obviously an integral part of the whole process of working. Cheers!!

brian.moeskau
18 Dec 2006, 10:28 PM
"Surely as a .Net developer you've experience a few things about IE that maybe bug you? "

That's a joke right? A FEW things? :) I don't even use IE anymore, except as a test client prior to rolling out releases.

"I wrote my first game in TRS_DOS Basic on a 1 MHZ Z-80 with 4K RAM in or around 1980..."

GW-BASIC on an Atari PC with a 8088 processor probably around 1984 or so for me. Yeah, I think we're both on the same page :)

jamaljohnson
19 Apr 2007, 2:37 PM
I found out the problem is still there on FireFox 1.5 PC. Everywhere else is fixed. It's a start.

Hey Jack,
I'm seeing this problem in FF2 concerning dialogs that have textfields in them.
A way I had worked around it previously was to wrap the textfield in a div with some overflow settings:



<div class='dlg-input-wrap'><input type='text'/></div>

/* so input fields get blinking cursor */
.dlg-input-wrap{
overflow: auto;
overflow-x: hidden;
}


And that seemed to fix things. Is that something similar to what you had done before? And are you seeing this issue in FF for dialogs with input fields? I am specifically using the prompt dialog. Thanks...

jack.slocum
19 Apr 2007, 3:01 PM
The overflow auto workaround doesn't always work for the missing cursor (1/2 the time). I have found that this works most of the time:

dialog.on('show', function(){ dialog.el.appendTo(document.body); } );

The problem (2nd one) is when the z-index of the element is not the same order as it is in the DOM. This hack moves it to the last position when it is shown which fixed it for me.

JL
14 May 2007, 7:15 AM
hello,
in the context of what i'm currently working on, i couldn't get that to work Jack. however, doing this worked (i know you said it won't always, but for what i'm working on it does):



Ext.extend(Ext.form.DialogTextField, Ext.form.TextField, {
onRender : function(ct, position){
Ext.form.DialogTextField.superclass.onRender.apply(this, arguments);
this.el.wrap( {tag: "div", cls: "dlg-input-wrap"} );
}
});


do you recall the instances in which your method works and this one doesn't and vice versa? thank you....

JL
14 May 2007, 7:40 AM
hmmm... this seems to break tabbing through fields, ugh...

JL
16 May 2007, 7:20 AM
if anyone is interested, i added this to the above div wrapper and all is good (so far ;))



onfocus: "this.childNodes[0].focus();"