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]

Re: Detecting font size change

"Csaba2000" <news@CsabaGabo r.com> wrote in message
news:bi0l3r$3f2 @dispatch.conce ntric.net...[color=blue]
>How do I detect when the font size has been changed
>(especially by user action: either Ctrl+Scroll wheel
>or View/Text Size)?[/color]
[color=blue]
>This is just for use on IE 5.5+, but it would be great
>if there was a generic solution.[/color]

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]

Re: Detecting font size change

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message news:bi0rcd$edm $1$8302bc10@new s.demon.co.uk.. .[color=blue]
> "Csaba2000" <news@CsabaGabo r.com> wrote in message
> news:bi0l3r$3f2 @dispatch.conce ntric.net...[color=green]
> >How do I detect when the font size has been changed
> >(especially by user action: either Ctrl+Scroll wheel
> >or View/Text Size)?[/color]
>[color=green]
> >This is just for use on IE 5.5+, but it would be great
> >if there was a generic solution.[/color]
>
> 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.
>[/color]

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="1 00%" 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]

Re: Detecting font size change

Hi Csaba, so the power's back on?

Csaba2000 wrote:[color=blue][color=green][color=darkred]
>>>How do I detect when the font size has been changed
>>>(especiall y by user action: either Ctrl+Scroll wheel
>>>or View/Text Size)?[/color]
>>[color=darkred]
>>>This is just for use on IE 5.5+, but it would be great
>>>if there was a generic solution.[/color]
>>
>>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.
>>[/color][/color]
I'm looking for an event type of notification[color=blue]
> 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="1 00%" 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.
>[/color]
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:12 0px"><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.onmous eover
with (IE specific) check for window.event.fr omElement==null
means the mouse is re-entering the document (text size could have
changed), and
document.onmous ewheel
with (IE specific) check for window.event.ct rlKey==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]

Re: Detecting font size change

"Csaba2000" <news@CsabaGabo r.com> wrote in message
news:bi1ht0$1in @dispatch.conce ntric.net...
<snip>[color=blue]
>... I want some event so I can know to do this updating when it's[/color]
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:4e x;" 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]

Re: Detecting font size change

"Dom Leonard" <doml.removethi s@senet.andthis .com.au> wrote in message
news:5jq1b.430$ Ca5.10337@nnrp1 .ozemail.com.au ...[color=blue]
> Hi Csaba, so the power's back on?[/color]

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...[color=blue]
>[/color]
....[color=blue]
> 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.
>[/color]

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]

Re: Detecting font size change

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="backgrou nd-color:violet" contentEditable >
<TABLE border=1>
<TR>
<TD style="backgrou nd-color:gold">
<DIV contentEditable style="backgrou nd-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" <doml.removethi s@senet.andthis .com.au> wrote in message news:vmd2b.22$E F.1765@nnrp1.oz email.com.au...[color=blue]
> Csaba2000 wrote:[color=green]
> > "Dom Leonard" <doml.removethi s@senet.andthis .com.au> wrote in message
> > news:5jq1b.430$ Ca5.10337@nnrp1 .ozemail.com.au ...
> >[/color]
> ... where there are no surrounding elements,[color=green]
> > how does inline differ from block-level (or SPAN differ from DIV)?
> >[/color]
>
> 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)
>
>
>[/color]