The text in the input field becomes centered. Possible cause: The "td" element which is the parent to the "textarea" element has the "align" attribute set to "center". This is hardly the desired effect of this attribute, the text should be left-aligned (as it is in Netscape 4.7 / Opera 3.62 / IE 5).
Still looking at what might be causing this one - CC'in Mike in case he knows, but I'm seeing it on NT too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: "textarea" seems to inherit ' align="center" ' from parent "td" → "textarea" seems to inherit ' align="center" ' from parent "td"
This is probably being inherited because align=center is mapped into text-align css attribute in MapAttributesInto for nsHTMLTableCellElement. Somehow it looks like this css is getting inherited into the table. Handing of to Mike and CC'ing Pierre in case he has some insight.
Assignee: clayton → mjudge
Component: Layout → HTML Form Controls
Summary: "textarea" seems to inherit ' align="center" ' from parent "td" → textarea inherits align="center" from parent td
Text fields should not inherit the text-align property. Their alignment should be reset to the default for the current direction ('ltr' or 'rtl'). Reassigned to rods.
Assignee: mjudge → rods
I think this is an editor issue, reassigning
Assignee: rods → beppe
giving this one to Simon to see if he can help resolve the issue
Assignee: beppe → sfraser
Target Milestone: --- → M18
Huh? This isn't anything to do with me.
Assignee: sfraser → beppe
Reassign to firstname.lastname@example.org. This is fallout from Ender-Lite. The old heavy-weight text widgets had a similar problem, but email@example.com fixed it.
Assignee: beppe → mjudge
Perhaps this fix should be either: 1) quirks-mode only, or 2) in ua.css, so the author can override it if desired
SImon I gave it to you for load balancing of the bugs, but that's ok
beppe: my sloughing off of this bug was probably a bit premature. But now that ender-light is on, I don't think that there is any editor-specific code that deals with styling the text field contents; this should all happen within layout. So I think this bug needs to go back to them.
I'm taking it back. I'll look into DBaron's suggestion of fixing it in ua.css. Note to self: check the result when editing centered static fields in Composer.
Assignee: mjudge → pierre
FWIW, This also impacts Zope pretty badly - it renders the textareas that are used heavily almost unusable.
David & Ian: I propose to fix this by adding a '-moz-default' value to the 'text-align' property in order to reset the alignement (left or right) according to the direction (ltr or rtl). Instead of using '-moz-default', we could also support 'default' and ask the WG what they think. In html.css, the INPUT element defines 'text-align:left'. A cheap way of fixing the bug would have been to do the same thing for TEXTAREA elements and let the i18n folks deal with the problem in r-t-l systems.
Status: NEW → ASSIGNED
-moz-default sounds good to me, we should also suggest it for CSS3.
Whiteboard: Suggest fix to WG.
Fix checked in: html.css nsCSSKeywordList.h nsCSSProps.cpp
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
How is this different from Bug 46987? If it isn't, this has regressed.
I'm running M17 of the missing build id, but help/about gives me Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m17) Gecko/20000807 this wasn't checked into the m17 branch or something? I still have this problem and yeah, bug 46987 looks awful familiar
Change QA contact to firstname.lastname@example.org
QA Contact: petersen → ckritzer
Updating QA contact.
QA Contact: ckritzer → bsharma
Verified Build 2001081303 os:win95,mac8.6,winNT
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.