Re: Why not max/min-font-size? & extend them to other properties of sizes

>Ok, I now know how to access the traditional Firefox menus after finding
>this page [1] since I knew what to search for. I never knew of the 'Zoom
>Text Only' feature. I still can't find the 'Zoom Text Only' feature in
>IE. I do use Windows.

Sorry my bad. IE doesn't have it. It only has default text sizes in the
range of [12,13,16,18,21] pxs (as computed from their pt size equivalent).

>Agree but using pt is very unwise for not paged media since you can not
>know someone DPI setting [2].

Agree, I only meant pt as reference to what scales or not from the default
rem unit when a default user's font-size other than Medium/Normal is used.

>I believe the problem is not with 'Zoom Text Only' but rather layouts
>that have a height set in pixels. If you view my CSS Class site (see
>below), 'Zoom Text Only' does not break the site unless you hit 'Zoom
>Text Only' five times or have a minimum font size of 26px.

Your design is pretty fluid and leave a lot of empty room, with no
responsive design constraint, so there isn't' much harm in your case.

My point of reference is a tightly integrated header layout like
drbrucelevine.com, where the 'branding' header text section is carefully
fit and already fairly big enough to read. And where a minor 'Zoom
Text Only' breaks the page flow in an undesired manner.

I locked that container's size deliberately regardless of the user's
default font size setting, with '16px' set at the (header) container level.
However I can't prevent it to break under 'Zoom Text Only' in FF/Safari
*unless* I apply a 'px !important' rule for each text nodes.
(since !important pixel rule are not affected by 'Zoom Text Only').
But applying '!important' px rules is far from being an attractive option.

I technically can use Javascript using the detected 'Zoom Text Only' scale
and dynamically rescale. But I'd much prefer a css solution to avoid
the text from overflowing its initial container.

I don't know if users use 'text zoom only' much enough to care. Personally
I use it more and more on Safari for sites that have main/article fonts way
too big now. (as in 22-24px, which is extremely annoying to read)

I suspect that 'text zoom only' will be much more needed in the age of RWD
than the regular zoom, which isn't the same people use to expect:
With a responsive design on desktop (unless the author decide to limit a
site's width dynamically once rendered) a zoom is now a viewport rescale.
So a 'text zoom only' seems much more useful to the RWD context.

>I am still wondering what issue you have with max/min-font-size. I
>myself do have issue since again I see it as an attempt to force
>something onto users by authors who to not cater for all users. That's
>why normal zoom became a standard among browsers.

I don't have any particular issue with max/min-font-size.

I am just saying that if it happens, I suggest it to be specced in a way
in which the 'Zoom Text Only' feature should be prohibited to increase any
font-size beyond a 'max-font-size' or decrease a font below a
'min-font-size' to give more layout control for this particular annoyance.

For instance if you have already large buttons, it makes little sense for
'Zoom Text Only' to increase those further at the risk of breaking things.

While I am receptive to the essence of your objection or concerns.
That sentiment also prevents authors who (mostly) know what they are doing,
to achieve an optimal layout for the benefit of all users, while being
quite aware of all constraints and accessibility issues at stake.

If you looked at my layout with a 'large' default font, without my
'16px' restraint, having the header all broken up would be a pretty bad
user experience. So limiting font size with good reasons has its use.

At the same rate, vw and vh units equally prevent font scaling or will doe
much weirder things at various screen sizes if you are not extremely
careful. Or you can always do damage with an !important rule. Having this
feature won't really change the status quo much in this regard.

Received on Sunday, 29 June 2014 05:21:51 UTC