BoxOver - easy to use floating captions

[Oliver Bryant]

I just finished developing a javascipt component allowing floating
captions to appear over HTML elements.

If anyone wants to check it out you can see specs and download it from
http://boxover.swazz.org.

There is a demo there as well.

[Michael Winter]

[Mailed to OP]

On 1 Nov 2004 12:32:46 -0800, Oliver Bryant <wa****@gmail.com> wrote:

I just finished developing a javascipt component allowing floating
captions to appear over HTML elements.

If anyone wants to check it out you can see specs and download it from
http://boxover.swazz.org.

First of all, apologies to the OP. I'm mailing you as I'm not sure if
you're still watching this group.

Secondly, the presentation is nice, but there are a couple of important
comments I would like to make.

One huge problem with this is that the title attribute is thoroughly
raped. For your script to work, the author must enter text that meets a
specific format. However, how will that be dealt with by accessibility
devices like Braille and screen readers, or users with Javascript disabled
but browsers that render the title content?

Authors that are required by law to produce accessible sites (a growing
number) might like your script, but they will be completely unable to use
it. The text for the caption can be specified by the content of the title
attribute, but that should be it.

I also think you should be more selective when applying the effect. Every
element with a title attribute seems over-the-top.
The web site

- You should validate your HTML and CSS.

See the results for each at:

<URL:http://validator.w3.org/check?uri=http%3A%2F%2Fboxover.swazz.org%2F>
<URL:http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fboxover.swazz.org%2F&us ermedium=all>

- Similar to above: please advocate good development practice.

1) <SCRIPT SRC="BoxOver.js"></SCRIPT>

The SCRIPT element requires the type attribute. Update the snippet to:

<script type="text/javascript" src="BoxOver.js"></script>

2) <DIV style="BORDER: #558844 1px solid;WIDTH:200px;HEIGHT: 75px">

Pixels values should be avoided for dimensions that are related to text.
Instead, use ems, which are proportional to the height of the current font.

3) Uses: ALT and TITLE replacements

This code is *not* a replacement for the alt attribute. The alt attribute
is a replacement used when the image, form control, applet, or client-side
image map area cannot be rendered. It should not be implied that alt is
for providing tool-tips. That's the job of the title attribute.
The script

- You don't use feature detection.

The first few lines of code look like (wrapped):

document.all ? window.attachEvent('onload',init)
: window.addEventListener('load',init,false);

However, what does document.all have to do with support for
window.attachEvent? Yes, IE supports document.all and the attachEvent
method, but other browsers do support document.all but probably not
attachEvent.

See <URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>
for more information.

- You pollute the global namespace.

Anyone that has written non-trivial code in any language will tell you
that global variables, especially in library code, are a bad idea. If
anyone happens to use a variable name that matches one of yours, its
likely that either their script, or yours, will break.

It's also quite curious that in some cases, you choose global scope when
it should clearly be local.

You might want to read a post I recently made on c.l.js
<URL:http://groups.google.com/groups?threadm=opsgt8lmmvx13kvk%40atlantis>
in the thread "Define prefix MM to function". That link may not be active
yet.

- Overuse of the style object.

To be honest, I fail to see why you're applying the bulk of your styles
though script when they could be applied through a class or id selector in
a style sheet. Furthermore, there are several instances where you specify
length values, but you fail to include a unit. This is invalid and
conforming browsers should ignore those declarations.

- Bad use of parseInt.

See the FAQ notes regarding type conversion, particularly the section,
"parseInt with a radix argument":
<URL:http://www.jibbering.com/faq/faq_notes/type_convert.html>.

- Declaring variables without using var.

Related to an earlier point, you introduce some variables without using
the var keyword. Most of these should only be local, so the var keyword
must be used in such cases. However, I (certainly) regard it as good
practice that all variables, global or not, should be declared with the
var keyword.

One last, much more minor point:

curNode.hasbox='true';

seems a little odd. Why not use a boolean?

I wouldn't call this list exhaustive, but it would certainly resolve the
majority of problems. I haven't for example, examined the positioning code
moveMouse() in any great detail.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Oliver Bryant]

Hi Michael.
Thanks for taking the time and effort to review the component so
thoroughly.

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message news:<opsgue4fsix13kvk@atlantis>...

[Mailed to OP]

On 1 Nov 2004 12:32:46 -0800, Oliver Bryant <wa****@gmail.com> wrote:

I just finished developing a javascipt component allowing floating
captions to appear over HTML elements.

If anyone wants to check it out you can see specs and download it from
http://boxover.swazz.org.
First of all, apologies to the OP. I'm mailing you as I'm not sure if
you're still watching this group.

No worries about the mail, I am still watching the group though ;)
Secondly, the presentation is nice, but there are a couple of important
comments I would like to make.

One huge problem with this is that the title attribute is thoroughly
raped. For your script to work, the author must enter text that meets a
specific format. However, how will that be dealt with by accessibility
devices like Braille and screen readers, or users with Javascript disabled
but browsers that render the title content?
Couldn't work out if you were taking the piss here to start. I have
the deepest regard for handicapped people in any form, but I have no
idea how a Braille screen reader works and quite frankly don't think
that this is a major consideration when talking about a javscipt
component.
Authors that are required by law to produce accessible sites (a growing
number) might like your script, but they will be completely unable to use
it. The text for the caption can be specified by the content of the title
attribute, but that should be it.
Boxover is very similar to a component called overlib. Overlib is
currently used on sites like NASA and HP - sites which would be under
the highest of scrutiny. So I disagree, people will be able to use
it. In my experience the most important factor is how many browsers a
javascript component will work under.
I also think you should be more selective when applying the effect. Every
element with a title attribute seems over-the-top.
This is a good point. I will include a modification which will check
for a keyword siginifying whether a caption should appear or not.

The web site

- You should validate your HTML and CSS.

See the results for each at:

<URL:http://validator.w3.org/check?uri=http%3A%2F%2Fboxover.swazz.org%2F>
<URL:http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fboxover.swazz.org%2F&us ermedium=all>

- Similar to above: please advocate good development practice.

1) <SCRIPT SRC="BoxOver.js"></SCRIPT>

The SCRIPT element requires the type attribute. Update the snippet to:

<script type="text/javascript" src="BoxOver.js"></script>
I think this is being overly pedantic. I've never had a problem with
not including the type attribute. From a theoretical (and possibly
legacy) standpoint, sure. But on the field this works in all browsers
I've seen.
2) <DIV style="BORDER: #558844 1px solid;WIDTH:200px;HEIGHT: 75px">

Pixels values should be avoided for dimensions that are related to text.
Instead, use ems, which are proportional to the height of the current font.
Admittedly I don't have any experience with the "em" unit. However I
have designed tons of websites and the "px" unit has never done me any
wrong. But I'm not in a fair position to compare the two.
3) Uses: ALT and TITLE replacements

This code is *not* a replacement for the alt attribute. The alt attribute
is a replacement used when the image, form control, applet, or client-side
image map area cannot be rendered. It should not be implied that alt is
for providing tool-tips. That's the job of the title attribute.
My apologies. I was originally considering making the component
configurable through the ALT tag as well. I have modified the site.

The script

- You don't use feature detection.
Of course I use feature detection. How does it work in different
browsers then?
The first few lines of code look like (wrapped):

document.all ? window.attachEvent('onload',init)
: window.addEventListener('load',init,false);

However, what does document.all have to do with support for
window.attachEvent? Yes, IE supports document.all and the attachEvent
method, but other browsers do support document.all but probably not
attachEvent.

See <URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>
for more information.
The code in this component works in all major browsers. I did it
myself and I know it works. The browser detection at this link checks
all sorts of things indirectly.

I believe that checking the actual existence of a property or object
is better - you don't have to rely on some derived browser value
earlier and then use a redundant condition which separates code for
each of the browsers. This uses more code and relies on you having
detected the correct browser earlier. Checking the object directly
and then loading the appropriate object into a variable which can then
manipulated with the same logic is better in my opinion.
- You pollute the global namespace.

Anyone that has written non-trivial code in any language will tell you
that global variables, especially in library code, are a bad idea. If
anyone happens to use a variable name that matches one of yours, its
likely that either their script, or yours, will break.

It's also quite curious that in some cases, you choose global scope when
it should clearly be local.
I'm sure people will tell me all sorts of things - but they normally
apply to the general case. I designed this with low CPU usage in mind
and it is a hell of a lof more efficient using global variables.
Using local variables means recreating them each time an event is
fired - javascript is already pretty inefficient as a language. My
reasons for using global variables are justified with regards to
performance.
You might want to read a post I recently made on c.l.js
<URL:http://groups.google.com/groups?threadm=opsgt8lmmvx13kvk%40atlantis>
in the thread "Define prefix MM to function". That link may not be active
yet.

- Overuse of the style object.

To be honest, I fail to see why you're applying the bulk of your styles
though script when they could be applied through a class or id selector in
a style sheet. Furthermore, there are several instances where you specify
length values, but you fail to include a unit. This is invalid and
conforming browsers should ignore those declarations.
The reason is simple. When somebody downloads boxover I want the
default manifestitation to look nice and be as easy to use as
possible. One souce file, one <script> tag, and altering a title
attribute - easy as that. Using classes would mean an extra
stipulation for the user to consider when setting it up (I couldn't
find any way to define a class inside the component source).
The component is designed so that a user can apply a style class to
any caption if they desire - but that might be out of scope for some
users so I thought defaulting to a nice looking default was best.
- Bad use of parseInt.

See the FAQ notes regarding type conversion, particularly the section,
"parseInt with a radix argument":
<URL:http://www.jibbering.com/faq/faq_notes/type_convert.html>.
Fair enough. That is a good article - thanks for the link. I
normally use parseInt to ensure that mathematical expressions are
evaluated correctly, e.g. so that 1 + 1 = 2 and not 11 (if it
considers + to indicate concatenation of strings rather than numerical
addition). I don't like that fact that the article refers to it as
inefficient. This I will look in to.
- Declaring variables without using var.

Related to an earlier point, you introduce some variables without using
the var keyword. Most of these should only be local, so the var keyword
must be used in such cases. However, I (certainly) regard it as good
practice that all variables, global or not, should be declared with the
var keyword.

One last, much more minor point:

curNode.hasbox='true';

seems a little odd. Why not use a boolean?
Yeah quite right. I should have used boolean. Must have been one of
those late nights ;)
I wouldn't call this list exhaustive, but it would certainly resolve the
majority of problems. I haven't for example, examined the positioning code
moveMouse() in any great detail.
Mike

I reckon the list is pretty exhaustive!

In conclusion, I appreciate your criticisms but I think that some are
unjustified. I spent hours on this component looking at all possible
trade offs. It has been designed to work in all major browsers -
Opera, IE, firefox, mozilla at very little CPU. These were my
strongest considerations when coding.

Thanks again for the in depth look you took into the component. I'll
be sure to ask your opinion on javascript matters in the future!

[Michael Winter]

On 3 Nov 2004 05:47:35 -0800, Oliver Bryant <wa****@gmail.com> wrote:

[snip]

One huge problem with this is that the title attribute is thoroughly
raped.
[snip]

Couldn't work out if you were taking the piss here to start.
Not at all.
I have the deepest regard for handicapped people in any form, but I have
no idea how a Braille screen reader works and quite frankly don't think
that this is a major consideration when talking about a javscipt
component.
It doesn't concern the script, but the HTML required to use it. What do
you think someone is supposed to make of the CSS properties, for example,
that can be specified when the title attribute is rendered by the user
agent? Reading out "cssheader=[color: #005A9C;]" is nonsense. Even for
able users that have scripting disabled, what are they supposed to with
that when it's displayed?

This is what I was referring to: you destroy the intended functionality of
the attribute. Now I'll grant that it's not the most important of
attributes, but that isn't much of an excuse.

[snip]
The SCRIPT element requires the type attribute. Update the snippet to:

<script type="text/javascript" src="BoxOver.js"></script>

I think this is being overly pedantic.

Really? You have a problem with writing valid HTML?

[snip]

Pixels values should be avoided for dimensions that are related to
text. Instead, use ems, which are proportional to the height of the
current font.

Admittedly I don't have any experience with the "em" unit. However I
have designed tons of websites and the "px" unit has never done me any
wrong. But I'm not in a fair position to compare the two.

Font sizes should be specified with a relative unit, such as em or
percent. It's another accessibility issue. Because of this, it obviously
doesn't make sense to use absolute units to position things as the font
size might not be what you expect. Using em will account for the variation
in font dimensions that can occur between different families, and the same
families on different platforms, as 1em is always the height of the font.

[snip]
Of course I use feature detection. How does it work in different
browsers then?
You use it in two locations, as far as I can tell, and its effectively the
same code.

Feature detection is exactly the same in every browser. Perhaps you should
read the article I linked to again more closely.

[snip]

See <URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>
for more information.

The code in this component works in all major browsers. I did it myself
and I know it works. The browser detection at this link checks all
sorts of things indirectly.

That document does not perform browser detection. It shows some common
browser detection patterns, then immediately states why they're reckless
and unreliable. As I said, I think you should read it more closely.
I believe that checking the actual existence of a property or object is
better
Which is precisely what the document describes, but it's not what you do.
The vast majority of methods and objects used are never tested for support.

[snip]
Checking the object directly and then loading the appropriate object
into a variable which can then manipulated with the same logic is better
in my opinion.
Excellent. Now do it.

[Regarding globals]
I'm sure people will tell me all sorts of things - but they normally
apply to the general case. I designed this with low CPU usage in mind
and it is a hell of a lof more efficient using global variables.
The variables I'm considering have no application whatsoever outside the
scope of their respective functions. Making them global is not any
quicker, can lead to script clashes, and serves no actual purpose.
Using local variables means recreating them each time an event is fired
- javascript is already pretty inefficient as a language.
Don't confuse the language with its implementations.
My reasons for using global variables are justified with regards to
performance.

Local variable initialisation is trivial, time-wise. It's no excuse to
resort to bad practice.

[snip]

<URL:http://groups.google.com/groups?threadm=opsgt8lmmvx13kvk%40atlantis>

Out of interest, did you read that (only some of it is relevant to this
subject)?

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.