Closed Bug 267459 Opened 20 years ago Closed 20 years ago

Can't set unicode-bidi on form controls.

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: smontagu, Assigned: smontagu)

Details

Attachments

(3 files, 4 obsolete files)

Form controls ignore the unicode-bidi CSS property.
Attached file testcase (obsolete) —
OS: Windows XP → All
Hardware: PC → All
Attached patch Possible patch (obsolete) — Splinter Review
Attached patch More comprehensive patch (obsolete) — Splinter Review
Attachment #164402 - Attachment is obsolete: true
Attachment #164996 - Flags: superreview?(bzbarsky)
Attachment #164996 - Flags: review?(bzbarsky)
Assignee: dbaron → smontagu
Attachment #164385 - Attachment is obsolete: true
Comment on attachment 164996 [details] [diff] [review]
More comprehensive patch

I'd like to see a clear description of exactly what setting unicode-bidi on
each form control is supposed to accomplish before any patches go in here.

>Index: layout/html/document/src/forms.css
>+*|*::-moz-button-content,
>+*|*::-moz-scrolled-content,

-moz-scrolled-content is not a forms thing.  Any rules affecting it belong in
ua.css and need to be tested for their effect on other scrollable things (eg
divs with overflow).

>+*|*::-moz-display-comboboxcontrol-frame,
>+optgroup:before,

Why are we changing optgroup:before but not changing options?  This is where
that clear description comes in.

>+textarea > .anonymous-div,
>+input[type="text"] > .anonymous-div,

What about inputs with no type specified or an invalid type specified?	Those
will all become text inputs, but won't match these rules.

>+input[type="file"] > input[type="text"] {

Why is the text part of the file input somehow different from the button part? 
Again, this is where a clear plan would help.
Attachment #164996 - Flags: superreview?(bzbarsky)
Attachment #164996 - Flags: superreview-
Attachment #164996 - Flags: review?(bzbarsky)
Attachment #164996 - Flags: review-
(In reply to comment #5)
> (From update of attachment 164996 [details] [diff] [review])
> I'd like to see a clear description of exactly what setting unicode-bidi on
> each form control is supposed to accomplish before any patches go in here.

Well, I'd like to have seen a clear description of exactly what anonymous boxes
and pseudoclasses underly each form element before writing the patch, instead of
having to trawl through code and layout debugger output, and customize the
latter to tell me what I needed to know.

If such a description exists somewhere, it would be better to refer to it here
than add extensive descriptions in an obscure corner of the code. If it doesn't,
perhaps I'm now in a good position to write it. Where do you think would be a
logical and discoverable place to put it?
The fact that such documentation doesn't exist is a sign that our form controls
were never designed well enough to have CSS applied to them (even though that
was the express purpose of rewriting the form controls).  So perhaps the real
answer is that form controls should work "correctly" out of the box, and
'unicode-bidi' should never apply?

But I'll stop trying to close the barn door 5 years after the horse got out...
(That said, what's the use case for making 'unicode-bidi' apply?  I find it hard
to imagine wanting to make text inputs work different ways for different
controls?  Or at least hard to imagine it being good for the user...)
(In reply to comment #8)
> (That said, what's the use case for making 'unicode-bidi' apply?  I find it hard
> to imagine wanting to make text inputs work different ways for different
> controls?  Or at least hard to imagine it being good for the user...)

Example: http://www-306.ibm.com/software/webservers/hats/

This is a Web-based interface to 3270 and 5250 host applications. Applying
unicode-bidi to form controls is required to emulate the behaviour of these
applications on legacy terminals.
(In reply to comment #5)

> >+input[type="file"] > input[type="text"] {
> 
> Why is the text part of the file input somehow different from the button part? 
> Again, this is where a clear plan would help.

This is based on the presupposition that there is no way to change the text in
the button anyway (other than editing properties files). If this is wrong then
we probably need to add the button part as well.
Attached patch Patch with commentary (obsolete) — Splinter Review
How is this for an opening bid?
Attachment #164996 - Attachment is obsolete: true
On further thought, I think we probably don't want to include input[type="file"]
in this after all. On the contrary, we should probably do something like:

input[type="file"] > input[type="text"] {
  direction: ltr !important;
}

for parity with places in chrome where file names can be entered, which have (Or
should have) |class="uri-element"|
It looks like we may want to always inherit bidi-override into
moz-scrolled-content...
It looks like inheriting bidi-override into ::-moz-scrolled-content should
always happen (and that should be in ua.css).

> Well, I'd like to have seen a clear description of exactly what anonymous
> boxes and pseudoclasses underly each form element before writing the patch

I think we would all have preferred it if the form control design were
documented (or existed, even).

> If such a description exists somewhere

Not to my knowledge.

There's an added quirk here; we're likely to change some of these
pseudo-elements around; aaronlev wants to eliminate the button-content stuff,
last I checked.

> Where do you think would be a logical and discoverable place to put it?

Linked somewhere off the layout project page on mozilla.org?  Or perhaps just
inside forms.css like you did...

As for file inputs, people use "direction: rtl" (without bidi override) to
create the effect of filenames cropped on the left, not on the right... this
apparently works in IE and all that.  :(

Modulo the file input and scrolled content issues and general concerns that
David has, the patch looks much better!
(In reply to comment #14)
 
> As for file inputs, people use "direction: rtl" (without bidi override) to
> create the effect of filenames cropped on the left, not on the right... this
> apparently works in IE and all that.  :(

They do? Ugh! I'm sure you don't need me to tell you that that is total abuse of
the property. It will break horribly (in IE as well) if the filename contains
RTL characters. 
Yeah, I know...
Attachment #165134 - Attachment is obsolete: true
Comment on attachment 165440 [details] [diff] [review]
Addressed those issues

As I said on IRC, I'll add to :-moz-column-content as well.

I think all bz's concerns are now addressed.
Attachment #165440 - Flags: superreview?(bzbarsky)
Attachment #165440 - Flags: review?(dbaron)
Comment on attachment 165440 [details] [diff] [review]
Addressed those issues

sr=bzbarsky if David is OK with this....  Add some comments to
-moz-scrolled-content and -moz-column-content explaining why this is needed,
ok?
Attachment #165440 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 165440 [details] [diff] [review]
Addressed those issues

I'm not sure exactly what the goal is here, but r=dbaron.
Attachment #165440 - Flags: review?(dbaron) → review+
Attachment #165440 - Flags: approval1.8a5?
Comment on attachment 165440 [details] [diff] [review]
Addressed those issues

this can land when we open for 1.8a6
Attachment #165440 - Flags: approval1.8a5? → approval1.8a5-
Fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
QA Contact: ian → style-system
You need to log in before you can comment on or make changes to this bug.