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)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
People
(Reporter: smontagu, Assigned: smontagu)
Details
Attachments
(3 files, 4 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dbaron
:
review+
bzbarsky
:
superreview+
asa
:
approval1.8a5-
|
Details | Diff | Splinter Review |
Form controls ignore the unicode-bidi CSS property.
Assignee | ||
Comment 1•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Comment 2•20 years ago
|
||
Assignee | ||
Comment 3•20 years ago
|
||
Attachment #164402 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #164996 -
Flags: superreview?(bzbarsky)
Attachment #164996 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•20 years ago
|
Assignee: dbaron → smontagu
Assignee | ||
Comment 4•20 years ago
|
||
Attachment #164385 -
Attachment is obsolete: true
Comment 5•20 years ago
|
||
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-
Assignee | ||
Comment 6•20 years ago
|
||
(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?
Comment 7•20 years ago
|
||
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...
Comment 8•20 years ago
|
||
(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...)
Assignee | ||
Comment 9•20 years ago
|
||
(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.
Assignee | ||
Comment 10•20 years ago
|
||
(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.
Assignee | ||
Comment 11•20 years ago
|
||
How is this for an opening bid?
Attachment #164996 -
Attachment is obsolete: true
Assignee | ||
Comment 12•20 years ago
|
||
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"|
Comment 13•20 years ago
|
||
It looks like we may want to always inherit bidi-override into
moz-scrolled-content...
Comment 14•20 years ago
|
||
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!
Assignee | ||
Comment 15•20 years ago
|
||
(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.
Comment 16•20 years ago
|
||
Yeah, I know...
Assignee | ||
Comment 17•20 years ago
|
||
Attachment #165134 -
Attachment is obsolete: true
Assignee | ||
Comment 18•20 years ago
|
||
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 19•20 years ago
|
||
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 20•20 years ago
|
||
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+
Assignee | ||
Updated•20 years ago
|
Attachment #165440 -
Flags: approval1.8a5?
Comment 21•20 years ago
|
||
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-
Assignee | ||
Comment 22•20 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 23•15 years ago
|
||
Flags: in-testsuite+
Updated•15 years ago
|
QA Contact: ian → style-system
You need to log in
before you can comment on or make changes to this bug.
Description
•