BoxOver - easy to use floating captions

Discussion in 'Javascript' started by Oliver Bryant, Nov 1, 2004.

  1. 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.
    Oliver Bryant, Nov 1, 2004
    #1
    1. Advertising

  2. [Mailed to OP]

    On 1 Nov 2004 12:32:46 -0800, Oliver Bryant <> 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&usermedium=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.
    Michael Winter, Nov 2, 2004
    #2
    1. Advertising

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

    "Michael Winter" <> wrote in message news:<opsgue4fsix13kvk@atlantis>...
    > [Mailed to OP]
    >
    > On 1 Nov 2004 12:32:46 -0800, Oliver Bryant <> 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&usermedium=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!
    Oliver Bryant, Nov 3, 2004
    #3
  4. On 3 Nov 2004 05:47:35 -0800, Oliver Bryant <> 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.
    Michael Winter, Nov 6, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. GrumpyDev
    Replies:
    0
    Views:
    405
    GrumpyDev
    Aug 21, 2003
  2. Andrew Crowe

    associating captions with images

    Andrew Crowe, Apr 5, 2004, in forum: HTML
    Replies:
    7
    Views:
    383
    Jukka K. Korpela
    Apr 6, 2004
  3. Kooner

    captions under photos

    Kooner, Jun 1, 2004, in forum: HTML
    Replies:
    35
    Views:
    1,237
    Mark Parnell
    Jun 30, 2004
  4. (Pete Cresswell)
    Replies:
    5
    Views:
    551
    brucie
    Oct 21, 2004
  5. Thomas Mlynarczyk

    How to mark up image captions

    Thomas Mlynarczyk, Nov 26, 2004, in forum: HTML
    Replies:
    17
    Views:
    820
    Toby Inkster
    Nov 27, 2004
Loading...

Share This Page