Ctrl++ not changes display of input type=radio and checkbox

RESOLVED DUPLICATE of bug 4821

Status

()

Core
Layout: Form Controls
RESOLVED DUPLICATE of bug 4821
12 years ago
10 years ago

People

(Reporter: Steve, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

The Firefox Homepage claims: "Firefox is as big or small as you want."
radio/checkbox-elements are diffcult to aim at for older people if they aren't
resizeable by Ctrl++.


Reproducible: Always

Steps to Reproduce:
1. open page with form-elements input type=radio/checkbox
2. Press Ctrl++ or Ctrl+-

Actual Results:  
radio/checkbox are always displayed at same size

Expected Results:  
resize input type=radio/checkbox just like input type=button !

even CSS font-size and vertical-align is ignored

Comment 1

12 years ago
*** Bug 307197 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

12 years ago
specification:
CSS vertical-align of input type=radio/checkbox doesn't work in a td-tag without
any text. If text is added to the td-tag vertical-align works fine.

Comment 3

12 years ago

*** This bug has been marked as a duplicate of 158303 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE

Comment 4

12 years ago
This can't be a duplicate of bug 158303. That bug is about XBL form controls 
which are disabled in Firefox, see about:config, nglayout.debug.enable_xbl_forms
 .

Updated

12 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Version: unspecified → 1.7 Branch
So we _could_ do this by defining sizes for these in em instead of pixels (and setting the font-size to the current pixel values).

That would make the sizes be affected by minimum font size prefs, of course.  And by _text_ zoom (what this bug is about).  It's not clear to me why text zoom should zoom non-text.

David, thoughts?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: 1.7 Branch → Trunk
(Reporter)

Comment 6

12 years ago
(In reply to comment #5)
> So we _could_ do this by defining sizes for these in em instead of pixels (and
> setting the font-size to the current pixel values).

It works if both width and height is set in em (Firefox 1.0.7). This should be the default !
 
> It's not clear to me why text zoom should zoom non-text.

.. because radio/checkbox make no sense without text. And therefore it should be handled as text.
Another reason is that other non-text objects like "input" (type=button) are correctly affected by the text-zoom, because they depend on text like radio buttons do.

> David, thoughts?

Related suggestion:
The drop-down button of the "select" tag (width is always the same) and the sliders e.g. of a "textarea" should be zoomed as well.
Steve, if you want full-page zoom there is already a bug on implementing it.  Meanwhile, we're talking about _text_ zoom.  Scrollbars are very clearly NOT text, and neither, in my opinion, are radios and checkboxes.  The idea of text zoom is to deal with the numerous crap sites out there that think that an 9px font for the main body text is a good idea, not as a general accessibility measure.

If your problem is that the marketing literature does not match reality, I suggest you file a bug on the website requesting that the marketing literature be fixed accordingly.
(Reporter)

Comment 8

12 years ago
(In reply to comment #7)
> Steve, if you want full-page zoom there is already a bug on implementing it. 

Please tell me the corresponding Bug#. If this bug includes my suggestions I will close my Bug-report #307196 immediately.

> Meanwhile, we're talking about _text_ zoom.  Scrollbars are very clearly NOT
> text, and neither, in my opinion, are radios and checkboxes.  The idea of text
> zoom is to deal with the numerous **** sites out there that think that an 9px
> font for the main body text is a good idea, not as a general accessibility
> measure.
> 
> If your problem is that the marketing literature does not match reality, I
> suggest you file a bug on the website requesting that the marketing literature
> be fixed accordingly.

I am definitivly not interested in philosophical discussions. There is no use in text-only zoom because other non-text objects (and even other text) can overlap the zoomed text and make it unreadle.

Another reason to handle radios and checkboxes as text is that you can bind them to a text using the "label" tag.

 
> Please tell me the corresponding Bug#.

It's the one and only hit from searching on "full page zoom", for what it's worth.  Any reason not to use the search page?  Bug 4821.

> I am definitivly not interested in philosophical discussions.

Then we have a fundamental problem, since you're asking for a change of philosophy.

> There is no use in text-only zoom

Many users disagree and find it quite useful.  Any HTML page that's actually somewhat fluid (like designed to deal with a variety of font sizes) works fine with it.

You may as well claim there is no use in the "minimum font size" preference or any sort of font size preferences, since all your arguments apply to them.

In any case, I'll bet that what you really want is bug 4821.

(Reporter)

Comment 10

12 years ago
(In reply to comment #9)
> > Please tell me the corresponding Bug#.
> 
> It's the one and only hit from searching on "full page zoom", for what it's
> worth.  Any reason not to use the search page?  Bug 4821.

Thanks for the Number, Boris.
The reason I asked you for the number is that the search page finds more than 200 bug-reports for the keywords "full page zoom" not containing Bug#4821. Even the advanced search says: "full page zoom" is not a known keyword.
If you could explain how you found the corresponding Bug#4821 that a Bugzilla newbie like me learns how to use the search page correctly ?
 
> Then we have a fundamental problem, since you're asking for a change of
> philosophy.

You claim the "text zoom" affects only text. But that conflicts with zooming all other types of the "input" tag (except "radio" and "checkbox") even if they contain no text. From a "users" point of view this is inconsequent !

> In any case, I'll bet that what you really want is bug 4821.

Enhancement#4821 is about full zooming of the complete contents of a browser-window. If implemented it would solve my problems. Since this bug isn't solved for 4 years I assume there is no chance that it will be solved in near future :(

But I still think zooming radios and checkboxes by default would be a useful and easy to implement enhancement of the existing "text zoom".

Is there anyone responsible for the implementation of "text zoom" who agrees with me ? If there is no chance of realizing this, feel free to resolve this bug as duplicate of bug#4821.
> Even the advanced search says: "full page zoom" is not a known keyword.

I suggest searching summaries, not keywords (keywords come from a specific short list; summaries describe the problem).  I agree that the simple search give lots of hits for this, but that's because it does an OR search on the terms, not an AND search.  Searching on "+full +page +zoom" gives many fewer results, with the "right" one listed first (it's second in the "full page zoom" list).  My apologies for not pointing out that the search is only simple when using the advanced search in this case.

> even if they contain no text.

But they're sized in terms of the text size.

*** This bug has been marked as a duplicate of 4821 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.