Detecting font size change

[Csaba2000]

How do I detect when the font size has been changed (especially by user action: either Ctrl+Scroll wheel or View/Text
Size)?
This is just for use on IE 5.5+, but it would be great if there was a generic solution.

Thanks,
Csaba Gabor from New York

[Richard Cornford]

"Csaba2000" <ne**@CsabaGabor.com> wrote in message
news:bi********@dispatch.concentric.net...

How do I detect when the font size has been changed
(especially by user action: either Ctrl+Scroll wheel
or View/Text Size)? This is just for use on IE 5.5+, but it would be great
if there was a generic solution.

If the font size is changed the value of the offsetWidth/Height
properties of elements that are either sized in relation to their text
contents or CSS sized with font size related units (em, ex, etc.) will
change.

Richard.

[Csaba2000]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:bi*******************@news.demon.co.uk...

"Csaba2000" <ne**@CsabaGabor.com> wrote in message
news:bi********@dispatch.concentric.net...

How do I detect when the font size has been changed
(especially by user action: either Ctrl+Scroll wheel
or View/Text Size)?

This is just for use on IE 5.5+, but it would be great
if there was a generic solution.

If the font size is changed the value of the offsetWidth/Height
properties of elements that are either sized in relation to their text
contents or CSS sized with font size related units (em, ex, etc.) will
change.

Richard.

Richard, thanks for your response, and you've answered the question that I asked, but I actually meant the question
in another way. Unfortunately, I see that it was a bit ambiguous. I'm looking for an event type of notification
somehow because I need to make some modifications based on the properties you mention.

In particular, I have a TABLE with cells whose only child is a fixed width and height SPAN. The SPAN's parent TD
element's width is fixed to allow me to set the SPAN's .style.overflow="auto". The SPAN's .style.width="100%" to
force any scroll bar to the far right. The SPAN's .style.height is fixed so that the overflow setting can do its job
(for small amounts of text the setting would correspond to 1 line. for longer text it is two lines). If the font
size is increased to the point where the text would overflow the cell (i.e. going from one to two lines), I want to
increase the SPAN's .style.height to 2 lines (something like 2.2em - but that's another issue) so that the text will
wrap, and that's why I want some event so I can know to do this updating when it's needed.

Thanks, and I hope I've made it clearer,
Csaba

[Dom Leonard]

Hi Csaba, so the power's back on?

Csaba2000 wrote:

How do I detect when the font size has been changed
(especially by user action: either Ctrl+Scroll wheel
or View/Text Size)?

This is just for use on IE 5.5+, but it would be great
if there was a generic solution.

If the font size is changed the value of the offsetWidth/Height
properties of elements that are either sized in relation to their text
contents or CSS sized with font size related units (em, ex, etc.) will
change.

Richard.

I'm looking for an event type of notification somehow because I need to make some modifications based on the properties you mention.

In particular, I have a TABLE with cells whose only child is a fixed width and height SPAN. The SPAN's parent TD
element's width is fixed to allow me to set the SPAN's .style.overflow="auto". The SPAN's .style.width="100%" to
force any scroll bar to the far right. The SPAN's .style.height is fixed so that the overflow setting can do its job
(for small amounts of text the setting would correspond to 1 line. for longer text it is two lines). If the font
size is increased to the point where the text would overflow the cell (i.e. going from one to two lines), I want to
increase the SPAN's .style.height to 2 lines (something like 2.2em - but that's another issue) so that the text will
wrap, and that's why I want some event so I can know to do this updating when it's needed.

First up, using SPAN as a block element is bad - width and height are
not legal CSS properties for inline elements. Yes IE5 supports them, but
only to fix IE specific bugs (applying borders to inline elements only
has effect in IE if the element has "layout" which is achieved by
specifying a bogus height/width attribute for SPANs), so using a DIV
within the TD satisfies requirments for both IE and valid HTML/CSS.

The answer is pure CSS in recent standards based browsers:

<td style="width:120px"><div class="special">some text goes here</div></td>

with CSS
div.special
{
width: 100%;
overflow:auto;
min-height: 1.1em;
max-height; 2.2em;
}

Unfortunately this doesn't work in Internet Explorer. A quick snoop
failed to reveal specific event notification for font size changes, but
did turn up a couple of possibilities to limit the overhead in checking:
document.onmouseover
with (IE specific) check for window.event.fromElement==null
means the mouse is re-entering the document (text size could have
changed), and
document.onmousewheel
with (IE specific) check for window.event.ctrlKey==true
means text size probably has changed (IE6 tested).

It would be remiss of me not to mention that Microsoft and other page
design software has promoted the use of absolute font sizes and page
elements dimensions for print-ready documents at the expense of screen
based accessability. I wish you luck in improving on this.

HTH,
Dom

[Richard Cornford]

"Csaba2000" <ne**@CsabaGabor.com> wrote in message
news:bi********@dispatch.concentric.net...
<snip>

... I want some event so I can know to do this updating when it's

needed.

IE 5.0+ implement an onresize handler on many elements. If an element is
CSS sized with font size relative units then the size of the element
changes when the user changes the View->Text Size setting.
Netscape/Mozilla and Opera do not implement this event handler.

I only tested this on IE 6 but this seems to work there:-

<html>
<head>
<title></title>
</head>
<body>
<div id="divA" style="width:4ex;" onresize="alert('div IE');">xxxx</div>
</body>
</html>

(Incidentally, is there any chance of you reducing the line length on
your newsreader to something around 72-80 characters? As it is your
lines are wrapped at one length and then re-wrapped to be displayed on
my newsreader, leaving every other line half as long as its predecessor.
The result is very hard to read/follow.)

Richard.

[Csaba2000]

"Dom Leonard" <do*************@senet.andthis.com.au> wrote in message
news:5j*****************@nnrp1.ozemail.com.au...

Hi Csaba, so the power's back on?
Yes, thanks. For me it came on the next morning (Friday) just before 8am.
However, neither my land line (which had worked during the power
outage) nor my cell phone worked on Friday. My DSL, however, on
the same line that my land line comes in on, was up all Friday. I'm
thinking of getting a VoIP phone... .... First up, using SPAN as a block element is bad - width and height are
not legal CSS properties for inline elements. Yes IE5 supports them, but
only to fix IE specific bugs (applying borders to inline elements only
has effect in IE if the element has "layout" which is achieved by
specifying a bogus height/width attribute for SPANs), so using a DIV
within the TD satisfies requirments for both IE and valid HTML/CSS.

Thanks for your response Dom. I only saw the responses today. This
is one of those delayed response posts I suppose. Using Richard's
response, I have gotten everything working as I wanted. But I found
your comment above highly interesting and I'd like to understand it better.

In my mind, I've always thought of DIV and SPAN as pretty much the
same thing. I understand one is "block level" and the other is "inline",
but how does this affect me (that is not a facetious question)? What
I mean is what properties do they differ on that I am likely to notice?
Where I'm coming from on this is that if I have to use one of these
elements at all, it is typically to wrap the entire innerHTML of the parent
element in a SPAN/DIV for some reason (for example, to make a TD
contentEditable or to change button text when access keys are
involved). So in this case, where there are no surrounding elements,
how does inline differ from block-level (or SPAN differ from DIV)?

I'm likely remembering wrongly, but I think I started using SPAN cuase
it seemed like in cinched up tighter, but it could just as easily be a
false memory. Anyway, further thoughts on this topic are welcome.

Regards from New York,
Csaba Gabor

[Csaba2000]

Hi Dom,

Thanks for your explanation about SPAN vs. DIV.
I appreciated the effort very much.

I remembered a bit more why I started using SPANs
so much. Consider the following table:

<DIV style="background-color:violet" contentEditable>
<TABLE border=1>
<TR>
<TD style="background-color:gold">
<DIV contentEditable style="background-color:silver">
foo
</DIV>
</TD>
</TR>
</TABLE>
</DIV>

The outer contentEditable allows you to change all the
table elements and resize the entire table width or height.

Both the outer and inner DIV have an extra line at the bottom.
If you change the inner DIV to SPAN or remove the contentEditable
(in which case its text can still be edited, but it can't be resized - only
the outer table can be resized), then the inner extra blank line
disappears.

If you remove the outer contentEditable, then both extra lines
disappear and the text of the inner element may be modified, but
nothing is resizeable. If the outer DIV is, instead, a SPAN then
the width of the SPAN is the width of the table.

So the point is that if you want to use an inner DIV with contentEditable
you will wind up with extra lines in your table. SPAN is a much tighter fit.

Regards,
Csaba Gabor from New York

"Dom Leonard" <do*************@senet.andthis.com.au> wrote in message news:vm**************@nnrp1.ozemail.com.au...

Csaba2000 wrote:

"Dom Leonard" <do*************@senet.andthis.com.au> wrote in message
news:5j*****************@nnrp1.ozemail.com.au...

... where there are no surrounding elements,

how does inline differ from block-level (or SPAN differ from DIV)?

Discussion may be a bit OT, but the difference can certainly bight
script operation so I'll try and be brief:

<cite W3C CSS2 recommendation>
Inline-level elements are those elements of the source document that do
not form new blocks of content; the content is distributed in lines
(e.g., emphasized pieces of text within a paragraph, inline images, etc.).
</cite>

To be obvious about it, take a SPAN defining a background color for
highlighting. Content of the SPAN will highlighted - even if it line
wraps during layout - without extending to setting the background color
of the block within which it resides. Consequently there is no
self-evident sense in setting the width of a SPAN and doing so is not
sanctioned under CSS rules.

Looking at the DTDs for HTML documents, SPAN is an %inline element which
may only contain inline content. Hence it is invalid to use a SPAN
around block elements - whether DIV, P or whatever - to set style
properties of the inner block or blocks; a block container, such as a
DIV, should be used for the same purpose. On this subject P (paragraph)
elements may only contain inline content and, like SPAN, must not be
used as containers for block elements.

The major relevence to javascript is that invalid HTML can cause failure
of DHTML effects originated in script in a browser dependent manner. For
example, one browser might treat a SPAN enclosing blocks as a block
element and "work" when (SPAN style is) manipulated by script, whilst
another might automatically terminate the SPAN as soon as it encounters
a block element (before the end SPAN tag is reached) and silently "fail"
script operation. The risk is that limited testing might not uncover
serious errors in pages intended for the WWW.

Although it is possible to set the "display" property of an inline
element to "block", the is cautioned against in the HTML spec.
Additionally I would not expect it to affect parsing of the document
tree in terms of nodes and their permitted children.

Obviously if a web-app is designed for a restricted audience using one
brand of browser, then working around quirks and proprietary extensions
of the browser may not be at issue. Given a choice between a proprietary
extension and a standards based method of doing the same thing,
however, <personally> I would choose the standards based method.

HTH,
Dom
==============================
CSS2 spec: http://www.w3.org/TR/REC-CSS2
HTML 4.01: http://www.w3.org/TR/html401
(links for download archives within pages)