Hello. I'm working on a layout that I need to be pixel specific. How
can I get the font to stay precisely the height I need? Specifying
line-height or font-size in px doesn't yield the results I need. The
font size scales when I change the browser's font size and the text
moves from where I need it.
33  2379 
"Dave (DreamIsle)" <da*******@gmail.comwrites:
font size scales when I change the browser's font size and the text
moves from where I need it.
That's how HTML and web browsers are *supposed* to work.
It's kind of like having to use NTSC-safe colors if you're broadcasting a
TV show in the US, or being limited to two channels if you're mastering
an audio CD. You have to work within the limitations of your chosen medium.
If you need perfect layout, you need to use a document format that supports
that, such as PDF.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
I understand that you have to work in certain limitations, but you're
full of crap if you think that that's how HTML and web browsers are
*supposed* to work. Why would one use pixels to specify a font size if
the font won't stay that size?
Sherm Pendley wrote:
"Dave (DreamIsle)" <da*******@gmail.comwrites:
font size scales when I change the browser's font size and the text
moves from where I need it.
That's how HTML and web browsers are *supposed* to work.
It's kind of like having to use NTSC-safe colors if you're broadcasting a
TV show in the US, or being limited to two channels if you're mastering
an audio CD. You have to work within the limitations of your chosen medium.
If you need perfect layout, you need to use a document format that supports
that, such as PDF.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Dave (DreamIsle) schreef:
Hello. I'm working on a layout that I need to be pixel specific. How
can I get the font to stay precisely the height I need? Specifying
line-height or font-size in px doesn't yield the results I need. The
font size scales when I change the browser's font size and the text
moves from where I need it.
Try flash.
Dave (DreamIsle) wrote:
Hello. I'm working on a layout that I need to be pixel specific. How
can I get the font to stay precisely the height I need? Specifying
line-height or font-size in px doesn't yield the results I need. The
font size scales when I change the browser's font size and the text
moves from where I need it.
Given the variation in how browsers handle font sizing, you can't get
there from here. IE handles px and pt correctly by not resizing them
(although that may be overridden). Other browsers (incorrectly) resize
everything as a favor to users because designers insist on making text too
small to read.
A workaround is to apply a style that has overflow:hidden as a rule to
the text block. At least then it may not break the pixel perfection even
though some text disappears.
Without an URL there is not much else to suggest.
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
Dave (DreamIsle) <da*******@gmail.comwrote:
Why would one use pixels to specify a font size if
the font won't stay that size?
CSS is optional by design. The author's CSS can be overridden by
higher-priority user CSS, or can be ignored altogether.
And the concept of "font" and "pixel" don't even make sense in some
browsing environments.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/
"I used to have a handle on life, but it broke."
Dave (DreamIsle) wrote:
I understand that you have to work in certain limitations, but you're
full of crap if you think that that's how HTML and web browsers are
*supposed* to work.
Said the foul-mouthed top-poster.
CSS has user stylesheets. http://www.w3.org/TR/CSS2/cascade.html#cascade
Browser font size zooming and minimum font-size specifications can be
thought of as writing a user stylesheet on the fly based on the author
stylesheet.
Why would one use pixels to specify a font size if
the font won't stay that size?
Good question. Why would one? The regulars in this newsgroup generally
recommend against it.
--
David Dorward <http://blog.dorward.me.uk/ <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Jim Moe wrote:
IE handles px and pt correctly by not resizing them
(although that may be overridden). Other browsers (incorrectly) resize
everything as a favor to users because designers insist on making text too
small to read.
Can you point me to the passage in the CSS specs where they say that
text zooming is forbidden for px and pt values? Text zooming is a
different thing than changing the default text size.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Johannes Koch wrote:
Jim Moe wrote:
>IE handles px and pt correctly by not resizing them
(although that may be overridden). Other browsers (incorrectly) resize
everything as a favor to users because designers insist on making text
too
small to read.
Can you point me to the passage in the CSS specs where they say that
text zooming is forbidden for px and pt values? Text zooming is a
different thing than changing the default text size.
BTW, Firefox does not resize text with a font-size specified in px or pt
when you change the default text size, neither does Opera.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
To further the education of mankind, "Dave (DreamIsle)"
<da*******@gmail.comvouchsafed:
I understand that you have to work in certain limitations, but you're
full of crap if you think that that's how HTML and web browsers are
*supposed* to work. Why would one use pixels to specify a font size if
the font won't stay that size?
The only browser I know of that _doesn't_ resize pixel-size-designated
fonts with its text-resize mechanism is Internet Explorer.
At least 7-8 years ago I said it is the only browser that handles this
correctly and got a lot of guff for it. Now, anyway, it seems that some
people agree.
Just for the record, Opera doesn't have a non-persistent text-resize
mechanism. It has a zoom feature.
--
Neredbojias
Infinity has its limits.
Dave (DreamIsle) wrote:
I understand that you have to work in certain limitations, but you're
full of crap if you think that that's how HTML and web browsers are
*supposed* to work. Why would one use pixels to specify a font size if
the font won't stay that size?
That's a sub-optimal manner in which to ask for help.
CSS *suggests* sizes.
Users may make overriding suggestions.
A pixel-specified font that looks good at 800*600 is going to look
pretty silly on my monster 2000*1600 display - and if I've got that
because my eyes are poor, I'm not going to be impressed by your efforts
to stop me enlarging your text so I can see it.
Pixel specification is a completely wrong-headed idea, as gets discussed
regularly here at some length. It only makes sense if you're writing for
a specific target (such as an internal page for the salesforce's pdas) -
and this group is for the www.
So - in general font sizes should be specified in ems or percentages, so
as to relate to the user's chosen text size (which presumably they
like). Occasionally you may specify size to relate to an image, for
aesthetic reasons - but the user may want (or need) to make your display
bigger or smaller, or may not have your chosen font, or whatever.
Alternatives are gif, jpg, png, flash, svg, etc (in my approximate order
of preference).
Chris
On Fri, 7 Jul 2006, Neredbojias wrote:
The only browser I know of that _doesn't_ resize
pixel-size-designated fonts with its text-resize mechanism is
Internet Explorer.
There's a CSS specification that sets out (although there's a certain
amount of vagueness involved) how px units are to be interpreted in
CSS. They aren't physical pixels as such, although in a narrow range
of rather common browsing situations they might indeed compute 1:1 as
physical pixels.
At least 7-8 years ago I said it is the only browser that handles
this correctly and got a lot of guff for it. Now, anyway, it seems
that some people agree.
If we predicate a narrow range of screen resolutions, and a normal
viewing distance, then the CSS specification does reduce to physical
pixels, and IE is behaving "to specification".
Whether "behaving to specification" is also interpreted as "correctly"
in terms of user needs is a different matter, of course. Ultimately,
CSS gives control to the user, in as much as they can disable or
overrule the author's CSS. IE *does* honour that in a sense, although
its option for getting that control is somewhat hidden away, in an
accessibility menu. Of course, once users have taken control away
from the author stylesheet, they're no longer going to get any
relative size differences which the author was hoping to specify:
they'll get no more than what their user stylesheet (or browser
default) sets out.
But when it's not being overridden by the user, IE's behaviour for px
and for pt units is closer to the specification than those other
browsers which allow px and pt sizes to be zoomed at will. One could
argue that those other browsers are being more user-friendly in the
face of hostile authoring, but in order to do that, they have to
deviate from the specification. Can't have it both ways.
The long and short is that in a general web viewing situation, where
nothing is known about the browsing situation and needs of each and
every user, it's just plain wrong to specify sizes in px units (nor in
physical pixels, nor in pt units, for that matter).
To sum up. Whether browsers behave well in the face of something that
ought not to have been used in the first place, is a different
argument than the one about specification conformance. I don't know a
single browser which really implements px units "to specification" -
because the browser simply does not have the parameters which it would
need for computing the correct display size per the CSS specification.
Dave (DreamIsle) wrote:
Why would one use pixels to specify a font size if
the font won't stay that size?
What an excellent question!
BugBear
Alan J. Flavell schrieb:
[...]
But when it's not being overridden by the user, IE's behaviour for px
and for pt units is closer to the specification than those other
browsers which allow px and pt sizes to be zoomed at will. One could
argue that those other browsers are being more user-friendly in the
face of hostile authoring, but in order to do that, they have to
deviate from the specification. Can't have it both ways.
The long and short is that in a general web viewing situation, where
nothing is known about the browsing situation and needs of each and
every user, it's just plain wrong to specify sizes in px units (nor in
physical pixels, nor in pt units, for that matter).
To sum up. Whether browsers behave well in the face of something that
ought not to have been used in the first place, is a different
argument than the one about specification conformance. I don't know a
single browser which really implements px units "to specification" -
because the browser simply does not have the parameters which it would
need for computing the correct display size per the CSS specification.
I think this is a highly ojective estimation of this really old
discussion! Apart from the often repeated religion-like points-of-view,
the persistence of this discussion shows that there are different needs
about web authoring, that are not covered appropriately yet, neither by
Microsofts proprietary inventions nor by the W3C standards resp. their
implementations in browsers.
At one side there is the need for flexible access to all informations in
a web page, independent of the browsing situation.
At the other side there is the need of many authors to comply with their
clients' corporate design, to respect at least minimal visual
principles, such as a reasonable relation of the sizes of corporate logo
and headline text. I do not think of fancy stuff here, just making a
page look well-designed.
Actually choosing px for font sizes is quite appropriate from the point
of view that images have px sizes, and the font sizes should correspond
to image sizes. The problem here is that the rendering of zoomed px
sizes is not consistent in many browsers - while text is zoomed,
container dimensions and border widths (for whatever reason) and image
sizes (due to technical limitations regarding quality) remain unzoomed
for example in Firefox.
Making pages look "good" is a *real* need for most professional web
authors, and promoting standards does IMO include developing the
standards with a spirit of satisfying all kinds of stakeholders. Blaming
authors of corporate sites for wanting to do their job, instead of
giving them the tools to do it in a way that also serves accessibility,
will just make them go on ignoring standards - which is bad for the
standards rather than for the authors[1].
Anyway, as for the OP's question, I think that the acutal situation is
not too bad:
- A majority of users, most of them having a quite average browsing
situation, use IE, which displays the page as intended by him.
- Users that really care about their browsing situation rather use a
browser that lets them change what they like to be changed - and which
displays the page as they like it. If the changes break the display in
non-IE browsers, he is free to serve IE it's own stylesheet using
conditional comments.
[1] IMO the W3C tends to be a little bit too anti-authors here. Dropping
the target attribute for example seems just missionary to me - browsers
can offer the user a selection to ignore it, or open a tab instead of a
window - so the result of dropping it is just me (and others) not caring
about the validation error resulting. Which reduces the overall
acceptance and credibility of the standards.
--
Markus
Markus Ernst wrote:
[1] IMO the W3C tends to be a little bit too anti-authors here. Dropping
the target attribute for example seems just missionary to me - browsers
can offer the user a selection to ignore it, or open a tab instead of a
window
The target attribute says nothing about the structure or semantics of
the document, so HTML is the wrong place for it. The correct tool for
that sort of behaviour is JavaScript.
Its just about using the right tool for the job.
On Fri, 7 Jul 2006, Markus Ernst wrote:
At the other side there is the need of many authors to comply with
their clients' corporate design, to respect at least minimal visual
principles, such as a reasonable relation of the sizes of corporate
logo and headline text.
I'm not sure who you think you're arguing against here.
The designer presumably has some idea of what they consider the
mainstream situation to be. They can design for the look that they
want in that mainstream situation. I'm only asking that they do it in
such a way that it behaves sensibly (i.e flexibly adapting itself) in
a wider range of situations. And, in this context, that means
refraining from sizing the content in px units, or in absolute length
units such as pt. It makes no sense IMHO to ask for something
(absolute length) which is clearly defined, and hoping that browsers
won't take it too seriously. When there's an alternative unit (em)
that *does* make sense, and which browsers have by now implemented
pretty well.
After all, if they build a fragile design, which falls apart or
otherwise becomes unusable when the text is zoomed, then the reader's
easy recourse is to turn off the styling altogether. What possible
benefit does the author get from their precious design when they force
that to happen?
Whereas, if their design adapts itself flexibly to a wide range of
browsing situations, there are far fewer readers who will have to miss
the benefits of the author's design. I'd call that a win-win
situation.
Actually choosing px for font sizes is quite appropriate from the
point of view that images have px sizes, and the font sizes should
correspond to image sizes.
Conversely, if the images are just nice adjuncts to the page, it may
make more sense to specify the size of the images in em units to match
the text. Whether that is successful can depend on the nature of the
image. See e.g http://ppewww.ph.gla.ac.uk/~flavell/...g-em-size.html
The problem here is that the rendering of zoomed px sizes is not
consistent in many browsers
Or, as I interpret it, "the problem here" is that authors persist in
trying to specify sizes in px units, when there are better ways (OK,
px sizes can be appropriate for borders, margins etc., but not for
substantive content of a web page that's intended for a general web
situation).
Making pages look "good" is a *real* need for most professional web
authors,
Again, I have to ask you who you are arguing against? Some authors
who persist in trying to achieve pixel-exact DTP on the web are
practically *guaranteeing* that their pages will look a mess to
minorities of their audience, when - if they had only worked *with*
the strengths of the medium, instead of provoking its weaknesses -
they could have had the exact look that they wanted in their
mainstream viewing situation, and *still* have looked "good" in other
viewing situations.
Johannes Koch wrote:
Jim Moe wrote:
>IE handles px and pt correctly by not resizing them
(although that may be overridden). Other browsers (incorrectly) resize
everything as a favor to users because designers insist on making text
too
small to read.
Can you point me to the passage in the CSS specs where they say that
text zooming is forbidden for px and pt values?
Eh? If text styled to be 14px is changing size when the user zooms in
and out, then it isn't being displayed consistently at 14px.
Text zooming is a
different thing than changing the default text size.
Yes, insofar as the latter continues to obey the stylesheet when fixed
font sizes are specified, while the former disobeys it.
Harlan Messinger wrote:
Can you point me to the passage in the CSS specs where they say that
text zooming is forbidden for px and pt values?
Eh? If text styled to be 14px is changing size when the user zooms in
and out, then it isn't being displayed consistently at 14px.
As I commented previously, text zooming can be thought of as
dynamically writing a user stylesheet based on the author stylesheet
(with with large font sizes).
User stylesheets take precendence. So the behaviour is correct.
Dave (DreamIsle) wrote:
I'm working on a layout that I need to be pixel specific.
I bet it doesn't need to be pixel specific.
I'm sure that _you_ need it to be pixel specific. But ask very
carefully if your users really need this - it's extremely rare that
they do. It's also extremely common for pointy-headed managers to
insists that it ought to be too.
How can I get the font to stay precisely the height I need?
In the beginning, there were pixel sizes and em sizes. Ems scaled
according to the users choice, pixels didn't. So good web designers
used ems and everyone lived happily ever after.
....Except that this only happens in fairy stories, and certainly not in
web design. As clueless web dezyners decided that the beauty of their
pixel-based, PSD-derived layouts was more important than the users
actually being able to _read_ the things, then they used pixie sizes
everywhere. After all, nested-table layouts and magic expanding images
had been good enough for their great-grandparents, so why should they
change? The dezyners thought that their designs were very beautiful,
especially when they looked at them through their Magic Macintoshes,
but when all the global village folks looked at them through their
everyday computers they were very ugly indeed - text ran outside the
boxes and the alignments were all broken and crooked. Even the glorious
bright shiny colours of the Macintoshes looked dull and dowdy on the
villager's wooden computers.
Old Granny Weatherwax had a "Change default text size" charm that her
uncle Pterry had given her. With her tired old eyes, this was a great
help to reading the web. She'd been using it since back in the days
when Sir Tim had been merely a humble squire. With these evil pixie
dezyners though, it didn't work any more.
One day a new knight rode into town, riding a fine steed, a fox with a
flaming tail (one of those new imports from Japanese mythology). There
were rumours that this knight had vanquished a huge dragon in the past
by transforming it into the fox. Or had he slain the dragon and adopted
the fox as a cub? No one was quite sure. With his fox he brought a new
charm, one that could resize text anywhere on the web. Granny
Weatherwax rejoiced, as did most of the villagers. Now they could read
the web again, the palace news and all the exciting blog entries of
life in the local monastery.
Only Yukka, the curmudgeonly old hermit grumbled a little. He saw that
the new charm was better than the evil pixie designers and their
controlling ways, and he understood _why_ the villagers were so happy
with it, but all the same he knew that this really wasn't how it was
meant to be. But no-one outside Ye Olde Usenetty listened to hermits.
In message <11*********************@p79g2000cwp.googlegroups. com>, "Dave
(DreamIsle)" <da*******@gmail.comwrites
>Why would one use pixels to specify a font size if the font won't stay
that size?
Because one is clueless, or arrogant, or both.
--
Andy Mabbett
Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
Free Our Data: <http://www.freeourdata.org.uk>
Johannes Koch wrote:
>
>IE handles px and pt correctly by not resizing them
(although that may be overridden). Other browsers (incorrectly) resize
everything as a favor to users because designers insist on making text too
small to read.
Can you point me to the passage in the CSS specs where they say that
text zooming is forbidden for px and pt values? Text zooming is a
different thing than changing the default text size.
Good point. The CSS spec is completely silent regarding the effects of
font scaling or zooming by the browser.
px is considered a relative value, but relative only to the display
device. And so is "relatively absolute"?
pt (along with in, cm, pc, etc.) is an absolute value because its height
is not related to the viewing device's physical characteristics.
en, em and % are relative to the current font-size.
None of the above really suggests what to do when text is zoomed.
In the future, then, I shall not say which is correct, only that I am
glad Firefox, et al., zoom all measures of font-size.
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
To further the education of mankind, "Alan J. Flavell"
<fl*****@physics.gla.ac.ukvouchsafed:
The long and short is that in a general web viewing situation, where
nothing is known about the browsing situation and needs of each and
every user, it's just plain wrong to specify sizes in px units (nor in
physical pixels, nor in pt units, for that matter).
Yeah, I think that's the real point. A pagemaker using pixel (etc.) font
sizes (-and expecting them to be unresizable) is just doing something
wrong, plain and simple. It may look good on a 640x480 tube and even
reasonable on a 1280x1024 screen, but what about the ol' 5120x4080
cylotherion megarez I got hooked-up in my lab? :)
It's an old argument; I still support MS's position as there might be some
one-in-a-million occasions where _I_ want that feature, but for general Web
pages, unh unh. Now for borders, padding, margins and the like....
--
Neredbojias
Infinity has its limits.
On Sat, 8 Jul 2006, Neredbojias wrote:
Yeah, I think that's the real point. A pagemaker using pixel (etc.)
font sizes (-and expecting them to be unresizable) is just doing
something wrong, plain and simple. It may look good on a 640x480
tube and even reasonable on a 1280x1024 screen, but what about the
ol' 5120x4080 cylotherion megarez I got hooked-up in my lab? :)
http://msdn.microsoft.com/workshop/a...ew/highdpi.asp
It's an old argument; I still support MS's position as there might
be some one-in-a-million occasions where _I_ want that feature, but
for general Web pages, unh unh. Now for borders, padding, margins
and the like....
Presumably, someone whose sight-impairment means they need large text
will want to make best use of their screen real-estate for doing it.
They wouldn't want borders, padding etc. to be inflated to the same
extent, and use-up space that could otherwise be used for seeing more
of the text. So yes, I'd say that specifying borders, margins etc. in
px units would be at least defensible - maybe even preferred.
Andy Mabbett wrote:
Why would one use pixels to specify a font size if the font won't stay
that size?
Because one is clueless, or arrogant, or both.
Using pixels to specifiy a font size that stays constant is entirely
correct behaviour. Remeber that Firefox's approach is understandable,
but still contrary to the standard.
The mistake is to attempt fixed-size text in anything but the very rare
cases where it's actually important. It's the intention that's wrong,
not the implementation.
I often design pages where body text is 1em (as it ought to be), but
there's a tiny nav bar or breadcrumb where the font is pixel sized, so
as to fit on some fixed design element. Usability suffers, but then
it's only a secondary nav feature and I can afford to lose it.
Andy Dingley <di*****@codesmiths.comwrote:
Using pixels to specifiy a font size that stays constant is entirely
correct behaviour. Remeber that Firefox's approach is understandable,
but still contrary to the standard.
Is it?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Alan J. Flavell schrieb:
>>At the other side there is the need of many authors to comply with
their clients' corporate design, to respect at least minimal visual
principles, such as a reasonable relation of the sizes of corporate
logo and headline text.
I'm not sure who you think you're arguing against here.
You are right; I was not arguing against anybody specifically, but tried
to suggest that the often-read discussion about pixel-sized layouts
might be taken as a hint about lacks in CSS rather than as a proof for
the stupidity of those asking. I don't mean that CSS should be developed
to make pixel-perfect layouts possible, but to give authors the means to
make flexible layouts that look as intended in "average" situations, and
adapt nicely in others. (I was actually replying to your posting because
some of your points seemed very convincing to me.)
The designer presumably has some idea of what they consider the
mainstream situation to be. They can design for the look that they
want in that mainstream situation. I'm only asking that they do it in
such a way that it behaves sensibly (i.e flexibly adapting itself) in
a wider range of situations. And, in this context, that means
refraining from sizing the content in px units, or in absolute length
units such as pt. It makes no sense IMHO to ask for something
(absolute length) which is clearly defined, and hoping that browsers
won't take it too seriously. When there's an alternative unit (em)
that *does* make sense, and which browsers have by now implemented
pretty well.
There is a really serious downside of the em unit: It is not constant
throughout a page. Elements with a width of 2em has different sizes
according to the font sizes of the parent elements.
[...]
Whereas, if their design adapts itself flexibly to a wide range of
browsing situations, there are far fewer readers who will have to miss
the benefits of the author's design. I'd call that a win-win
situation.
This is a very good point! :-)
Conversely, if the images are just nice adjuncts to the page, it may
make more sense to specify the size of the images in em units to match
the text. Whether that is successful can depend on the nature of the
image. See e.g
http://ppewww.ph.gla.ac.uk/~flavell/...g-em-size.html
Yes that matches my experience. My example was a corporate logo, which
is mostly not reasonably scalable. Also, background images are not
scalable along with the em value - even if they were scalable at all,
the em size of the element containing the background might differ from
the one containing the overlying text.
I hope we will get scriptable CSS soon, which hopefully will allow
specifying values according to the environment:
#container {
font-size:110%;
switch absoluteFontSize {
case < 12px:
background-image:url('logo_small.gif');
break;
case 24px:
background-image:url('logo_big.gif');
break;
default:
background-image:url('logo_normal.gif');
}
}
:-)
Johannes Koch wrote:
Andy Dingley <di*****@codesmiths.comwrote:
Using pixels to specifiy a font size that stays constant is entirely
correct behaviour. Remeber that Firefox's approach is understandable,
but still contrary to the standard.
Is it?
"Pixel units are relative to the resolution of the viewing device"
Note that this is the "device", not "text rendered upon this device".
Although the CSS spec is intentionally and correctly generic about
issues of rendering for specific devices, it does treat a pixel as
being derived from the display size and derived equally for lengths
applied to page elements, and to fonts. Firefox breaks this link and
allows pixel-based font sizes to scale independently of page design
elements.
It's entirely understandable and it's even "better" in terms of making
FF a more useful browser. However it does contravene the strict spec.
"Johannes Koch" <ko**@w3development.dewrote in message
news:44***********************@authen.yellow.readf reenews.net...
Andy Dingley <di*****@codesmiths.comwrote:
Using pixels to specifiy a font size that stays constant is entirely
correct behaviour. Remeber that Firefox's approach is understandable,
but still contrary to the standard.
Is it?
Inasmuch as it is changing the dimensions of a pixel only for type, yes.
From http://www.w3.org/TR/1999/REC-CSS1-1...1#length-units
"Pixel units, as used in the last rule, are relative to the resolution of
the canvas, i.e. most often a computer display. If the pixel density of the
output device is very different from that of a typical computer display, the
UA should rescale pixel values. The suggested reference pixel is the visual
angle of one pixel on a device with a pixel density of 90dpi and a distance
from the reader of an arm's length. For a nominal arm's length of 28 inches,
the visual angle is about 0.0227 degrees."
Firefox's approach to accessibility is counter-productive. Try resizing http://www.nytimes.com.
It seems to me that the best way to improve accessibility for poor-sighted
people is to upsize pixel dimensions throughout, expand the root element in
both directions as necessary, and make it easy for the viewer to scroll
about the magnified document. I live with someone who uses a magnifier to
view printed material with small type. She'd much prefer scrolling about a
magnified virtual document than have its intended size relationships utterly
destroyed by selective upsizing.
Dave
Andy Dingley <di*****@codesmiths.comwrote:
Johannes Koch wrote:
>>Andy Dingley <di*****@codesmiths.comwrote:
>>>Using pixels to specifiy a font size that stays constant is entirely
correct behaviour. Remeber that Firefox's approach is understandable,
but still contrary to the standard.
Is it?
"Pixel units are relative to the resolution of the viewing device"
Ah, yes. I thought you meant the resizing thing. The incorrect
implementation of the sentence you quoted is not FF-specific.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Andy Dingley <di*****@codesmiths.comwrote:
Johannes Koch wrote:
>>Andy Dingley <di*****@codesmiths.comwrote:
>>>Using pixels to specifiy a font size that stays constant is entirely
correct behaviour. Remeber that Firefox's approach is understandable,
but still contrary to the standard.
Is it?
"Pixel units are relative to the resolution of the viewing device"
Implementing 'px' not according to specification is not FF-specific.
Note that this is the "device", not "text rendered upon this device".
Although the CSS spec is intentionally and correctly generic about
issues of rendering for specific devices, it does treat a pixel as
being derived from the display size and derived equally for lengths
applied to page elements, and to fonts. Firefox breaks this link and
allows pixel-based font sizes to scale independently of page design
elements.
See David Dorward's post
<11**********************@s53g2000cws.googlegroups .com>.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Andy Dingley <di*****@codesmiths.comwrote:
I often design pages where body text is 1em (as it ought to be), but
there's a tiny nav bar or breadcrumb where the font is pixel sized, so
as to fit on some fixed design element. Usability suffers, but then
it's only a secondary nav feature and I can afford to lose it.
So what happens when someone configures their browser to enforce a minimum
font size that's larger than your "fixed design element"?
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/
"Good teachers are costly. Bad teachers cost more." - Bob Talbert
Darin McGrew wrote:
Andy Dingley <di*****@codesmiths.comwrote:
I often design pages where body text is 1em (as it ought to be), but
there's a tiny nav bar or breadcrumb where the font is pixel sized, so
as to fit on some fixed design element. Usability suffers, but then
it's only a secondary nav feature and I can afford to lose it.
So what happens when someone configures their browser to enforce a minimum
font size that's larger than your "fixed design element"?
Then it breaks. This isn't a perfect solution, it's a solution to text
sizing around designs (usually originating from PSDs) where there's a
design element that's rigidly fixed to a pixel size (often because
there's a "pretty" bitmap involved).
As weaning comissioning editors away from furniture bitmaps isn't
likely to happen any time soon, it's the best compromise I can achieve
today.
Dave (DreamIsle) wrote:
Hello. I'm working on a layout that I need to be pixel specific. How
can I get the font to stay precisely the height I need? Specifying
line-height or font-size in px doesn't yield the results I need. The
font size scales when I change the browser's font size and the text
moves from where I need it.
Build your entire site in Photoshop and load it all as a single JPEG.
Use image mapping for the links.
Sure, it will be a crappy site, but it will accomplish what you want.
Your choice...
--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."
Tony schrieb:
Build your entire site in Photoshop and load it all as a single JPEG.
Use image mapping for the links.
For your amusement - that's exactly what I made years ago when doing one
of my very early web projects: www.artoftype.ch. I did not have time to
redo it yet, though it is absolutely in-accessible for non-mainstream
viewing situations, search-engine hostile, a horror to maintain (and
thus never updated) - and even talks about type in the web ;-)
I still don't shut it down because it has some traffic, as you can
download some fonts for free...
--
Markus This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: R0bert Neville |
last post by:
I created a simple template with common tags, which serves as a quick
reference guide for my web development efforts. The web page renders
great in Firefox, yet becomes a mess in IE. Please review...
|
by: R0bert Neville |
last post by:
I created a simple template with common tags. It serves as a quick
reference guide for my web development efforts. The web page renders
great in Firefox, yet becomes a mess in IE. The HTML and CSS...
|
by: grogerteal |
last post by:
Hello,
I am pretty new to programming and would like someone to help me get
started on the program that I need to make.
I hope it is not hard to do, but what I would like is a simple app that...
|
by: Sangeeta |
last post by:
Hi,
I have a datagrid where columns are of some fixed pixel size. If any
column text increases the width of column, the plan is to truncate it
till its pixel width becomes less than the coloumn...
|
by: Bart Van der Donck |
last post by:
Hello,
I'm having a hard time trying to configure printed output that consists
of multiple pages. The idea is the following:
<div style="
border: 1px solid blue;
position: absolute;
top:...
|
by: ajay_itbhu |
last post by:
Hi everyone, I want to read the pixel values of 2 similar images in
bitmap format like 2 continuous frame of a video for calculating the
median. But i dont know how to read the pixel values of...
|
by: 123shailesh |
last post by:
Hello everyone,
I need some help. I have been working on it for some time but havent been able to think of any solution. Even had thought of making do without it, even though it was a major part...
|
by: ofiras |
last post by:
Hi,
I made a "Paint" program, but I couldn't find a method to paint 1
pixel using graphic state ("Graphics g =
Graphics.FromHwnd(this.Handle);")
How can I paint 1 pixel?
I guess I can make a...
|
by: ofiras |
last post by:
In bitmap, how can I find the nearest pixel (pixel
1) to a specific pixel (pixel 2) that has different color from pixel
2? Or how can I find a pixel in a specific distance from pixel 2 (like
a...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
