ZMI: IE6 TextArea width bug: fix on tap for 2.6?
I was wondering if there was any consensus on how best to fix or compensate for the unfortunate behaviour of IE6 with regards to the width calculation of textarea boxes. For anyone who hasn't seen it, the full-width texareas that are everywhere in the ZMI suddenly started pushing the width out in IE6, causing the horizontal scrollbar to become active, and generally making ZMI editing life miserable. Would it be possible to include in 2.6 (or 2.5.1, even better) a user preference, sitewide configuration setting, or other means of suppressing a few pixels/percent of that default width? I'm loathe to apply a massive search-replace to put "95%" in my local ZMI source, and IE6 must be a common enough platform for Zope users to warrant a workaround. I wouldn't hold my breath that MS would fix IE or anything sensible like that. It would be a shame to slow the whole thing down with browser detection logic for this one bug, unless that opened up the door for some of the Javascript/DHTML editors as a per-user preference for editing certain metatypes.
There's a couple good starting points for looking at this stuff... http://www.alistapart.com/stories/fear4/ http://www.alistapart.com/stories/dao/
From: "Jeff Kowalczyk" <jtk@adelphia.net> Date: Sun, 17 Mar 2002 16:12:44 -0500 To: <zope-dev@zope.org> Subject: [Zope-dev] ZMI: IE6 TextArea width bug: fix on tap for 2.6?
I was wondering if there was any consensus on how best to fix or compensate for the unfortunate behaviour of IE6 with regards to the width calculation of textarea boxes. For anyone who hasn't seen it, the full-width texareas that are everywhere in the ZMI suddenly started pushing the width out in IE6, causing the horizontal scrollbar to become active, and generally making ZMI editing life miserable.
Would it be possible to include in 2.6 (or 2.5.1, even better) a user preference, sitewide configuration setting, or other means of suppressing a few pixels/percent of that default width? I'm loathe to apply a massive search-replace to put "95%" in my local ZMI source, and IE6 must be a common enough platform for Zope users to warrant a workaround. I wouldn't hold my breath that MS would fix IE or anything sensible like that.
It would be a shame to slow the whole thing down with browser detection logic for this one bug, unless that opened up the door for some of the Javascript/DHTML editors as a per-user preference for editing certain metatypes.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
I agree, though the problem would not have even occured if someone had not put in the style="width:100%". IE's width=100% attribute works ok, it's just the style and stylesheet handling that blows. There is already a way (In fact two ways) to define the width of text entry boxes, please can the style="width:100%" be completely removed? Thanks Adrian... -- The difficulty of tactical maneuvering consists in turning the devious into the direct, and misfortune into gain. - Sun Tzu ----- Original Message ----- From: "Jeff Kowalczyk" <jtk@adelphia.net> To: <zope-dev@zope.org> Sent: Sunday, March 17, 2002 9:12 PM Subject: [Zope-dev] ZMI: IE6 TextArea width bug: fix on tap for 2.6?
I was wondering if there was any consensus on how best to fix or compensate for the unfortunate behaviour of IE6 with regards to the width calculation of textarea boxes. For anyone who hasn't seen it, the full-width texareas that are everywhere in the ZMI suddenly started pushing the width out in IE6, causing the horizontal scrollbar to become active, and generally making ZMI editing life miserable.
Would it be possible to include in 2.6 (or 2.5.1, even better) a user preference, sitewide configuration setting, or other means of suppressing a few pixels/percent of that default width? I'm loathe to apply a massive search-replace to put "95%" in my local ZMI source, and IE6 must be a common enough platform for Zope users to warrant a workaround. I wouldn't hold my breath that MS would fix IE or anything sensible like that.
It would be a shame to slow the whole thing down with browser detection logic for this one bug, unless that opened up the door for some of the Javascript/DHTML editors as a per-user preference for editing certain metatypes.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
participants (3)
-
Adrian Hungate -
Jeff Kowalczyk -
marc lindahl