firefox and innerHTML

Discussion in 'Javascript' started by bedhead, Jul 10, 2005.

  1. bedhead

    bedhead Guest

    Why doesn't a SELECT element's innerHTML reflected which option was
    selected? Works in IE. I need this functionality so that I can retain
    what choices a user made in a tabbed interface.

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://w3.org/1999/xhtml">
    <head>

    <script language="javascript">
    function callAlert(){
    var theHTML = document.getElementById('Radius').innerHTML;
    //alert(theHTML);
    }
    </script>
    <title>Untitled Document</title>
    </head>

    <body>
    <form id="myForm">
    <div id="myDiv">
    <table border="0" width="430" cellpadding="3" cellspacing="0">
    <tr>
    <td font color="#ff0000">*</font>Radius:</td>
    <td width="331" height="30" class="formData">
    <select onChange="callAlert();" id="Radius" name="Radius">
    <option value=".10" id="0">1/10 mile</option>
    <option value=".20">1/5 mile</option>
    <option value=".25">1/4 mile</option>
    <option value=".5">1/2 mile</option>
    <option value=".75">3/4 mile</option>
    <option value="1">1 mile</option>
    </select>
    </td>
    </tr>
    </table>
    </div>
    </form>
    </body>
    </html>
     
    bedhead, Jul 10, 2005
    #1
    1. Advertising

  2. On 10/07/2005 23:20, bedhead wrote:

    > Why doesn't a SELECT element's innerHTML reflected which option was
    > selected?


    The selected attribute refers to pre-selection, not whether the element
    is currently selected. Markup is static and doesn't change in response
    to user actions.

    > I need this functionality so that I can retain what choices a user
    > made in a tabbed interface.


    Read the values from object properties and reassign them later.

    [snip]

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Jul 10, 2005
    #2
    1. Advertising

  3. bedhead

    Mick White Guest

    bedhead wrote:
    > Why doesn't a SELECT element's innerHTML reflected which option was
    > selected? Works in IE. I need this functionality so that I can retain
    > what choices a user made in a tabbed interface.


    What are you looking for? The option's value, the option's text or the
    option's selected index?
    [...]
    >
    > <script language="javascript">
    > function callAlert(){
    > var theHTML = document.getElementById('Radius').innerHTML;
    > //alert(theHTML);
    > }
    > </script>


    Why not pass the select object to the callAlert function?

    <script type="text/javascript">
    function callAlert(menu){
    alert(menu.options[menu.selectedIndex].value);
    alert(menu.options[menu.selectedIndex].text);
    alert(menu.selectedIndex);
    }
    </script>

    <select onChange="callAlert(this);" id="Radius" name="Radius">

    Help?
    [...]

    Mick
     
    Mick White, Jul 10, 2005
    #3
  4. bedhead <> wrote in message news:...
    > Why doesn't a SELECT element's innerHTML reflected which option was
    > selected? Works in IE. I need this functionality so that I can retain
    > what choices a user made in a tabbed interface.


    http://jibbering.com/FAQ/#FAQ4_13

    Using the above technique, assign your form a NAME not an ID. Reading form elements does not involve
    document.getElementById or .innerHTML. Please tell all your friends and ask them to tell all their friends etc.

    --
    Stephen Chalmers
     
    Stephen Chalmers, Jul 11, 2005
    #4
  5. "Stephen Chalmers" <> writes:

    > http://jibbering.com/FAQ/#FAQ4_13
    >
    > Using the above technique, assign your form a NAME not an ID.


    I assume you refer to "id" and "name" attributes, but capitalizing
    risks confuzing with HTML data types ID and NAME
    <URL:http://www.w3.org/TR/html4/types.html>.

    Anyway, give it an "id" attribute, not a name attribute, if you are
    writing HTML 4 or later. The "name" attribute is not valid on form
    elements at all. The only reason for using the "name" attribute is to
    be compatible with Netscape 4 or its contemporaries, and in that case,
    you should still use the valid "id" attribute with the same name.

    The W3C DOM 2 HTML says that the forms collection (an
    HTMLNodeCollection) can be indexed using the elements names or id's,
    so using an "id" attribute still works.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jul 11, 2005
    #5
  6. bedhead

    Matt Kruse Guest

    Lasse Reichstein Nielsen wrote:
    > The "name" attribute is not valid on form
    > elements at all. The only reason for using the "name" attribute is to
    > be compatible with Netscape 4 or its contemporaries, and in that case,
    > you should still use the valid "id" attribute with the same name.


    1) name attributes on form tags certainly is valid html 4.01.

    2) Multiple forms can have the same name, but multiple forms may not have
    the same id. In some cases, this might be an important fact.

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
     
    Matt Kruse, Jul 11, 2005
    #6
  7. On 11/07/2005 01:06, Matt Kruse wrote:

    > Lasse Reichstein Nielsen wrote:
    >
    >> The "name" attribute is not valid on form elements at all. The only
    >> reason for using the "name" attribute is to be compatible with
    >> Netscape 4 or its contemporaries, and in that case, you should
    >> still use the valid "id" attribute with the same name.

    >
    > 1) name attributes on form tags certainly is valid html 4.01.


    Correct. They're also valid in XHTML 1.0 Transitional (but not Strict).

    > 2) Multiple forms can have the same name [...]


    No. The name and id attributes share the same namespace for most
    elements. The uniqueness constraint applies equally when using either
    attribute with a FORM element, as well as A, APPLET, FRAME, IFRAME, IMG
    and MAP elements. See a few paragraphs into section 12.2.3 - Anchors
    with the id attribute.

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Jul 11, 2005
    #7
  8. bedhead

    bedhead Guest

    Thanks for all the replies. Sorry for the confusion. This is just a
    small example. I am getting the innerHTML of a DIV tag which
    encompasses a very large form. I didn't want to get all the selected
    indexes, checked, etc... of all elements in the form and restore them
    later.

    IE actually changes the innerHTML of the DIV to reflect what the user
    selected. So, if you save the innerHTML you have their choices. I
    would like to do a similar thing in FireFox if available.

    Does innerHTML have similar functionality in FireFox? If not, is
    saving all the current choices the only way to accomplish this?

    Thanks
     
    bedhead, Jul 11, 2005
    #8
  9. "Matt Kruse" <> writes:

    > 1) name attributes on form tags certainly is valid html 4.01.


    So it is! It was just HTML 4.0 where it wasn't. It's not incorrect that
    it's for compatability with old browsers though, as they say:
    ---
    name = cdata [CI]
    This attribute names the element so that it may be referred to from
    style sheets or scripts. Note. This attribute has been included for
    backwards compatibility. Applications should use the id attribute to
    identify elements.
    ---
    For style sheets, they have to mean using the [name="something"]
    selector which IE still doesn't support (like most CSS2).

    > 2) Multiple forms can have the same name, but multiple forms may not have
    > the same id. In some cases, this might be an important fact.


    And whenever a form has both an id and a name, it must be the same :)

    I fail to see an application where multiple forms with the same
    element is the best way to do anything, but it is allowed.

    /L 'just use "id"!'
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jul 11, 2005
    #9
  10. bedhead

    RobG Guest

    bedhead wrote:
    > Thanks for all the replies. Sorry for the confusion. This is just a
    > small example. I am getting the innerHTML of a DIV tag which
    > encompasses a very large form. I didn't want to get all the selected
    > indexes, checked, etc... of all elements in the form and restore them
    > later.
    >
    > IE actually changes the innerHTML of the DIV to reflect what the user
    > selected. So, if you save the innerHTML you have their choices. I
    > would like to do a similar thing in FireFox if available.
    >
    > Does innerHTML have similar functionality in FireFox?


    No. Given that 'innerHTML' is not a public standard nor fully
    documented anywhere, whatever behaviour it has is what it has. As it is
    a Microsoft invention, you could argue that any browser that doesn't do
    what IE does has a faulty implementation.

    But IE's version has its own problems: if you serialise the select
    element with the user's currently selected options as 'selected', you
    will need to code your own reset button as the original defaults are gone.

    If you restore the page with the previously selected options being set
    as 'selected' in the HTML, you will have the same problem however you
    implement it - you will have to provide your own reset button.

    > If not, is
    > saving all the current choices the only way to accomplish this?


    Why not use display: none for non-selected tabs? The content stays in
    the page and there are no issues with restoring forms. If you do the
    layout right, with JavaScript disabled the tabs should just appear one
    above the other and have anchors to navigate between them. With JS
    enabled, they behave like tabs - hiding and showing the relevant bits.


    --
    Rob
     
    RobG, Jul 11, 2005
    #10
  11. bedhead

    VK Guest

    > I assume you refer to "id" and "name" attributes, but capitalizing
    > risks confuzing with HTML data types ID and NAME
    > <URL:http://www.w3.org/TR/html4/types.html>.


    > Anyway, give it an "id" attribute, not a name attribute, if you are
    > writing HTML 4 or later.


    Form elements without names will not be submited (even if they have
    id's set) !
    Form elements with names will be submited on form.submit() (with id or
    without) !

    It's kind of a pointless discussion because we are talking about a
    legacy structure, W3 had to include into the new standards in the way
    it was and will remain forever since Netscape 2.

    As I mentioned before it's kind of "why one child but many children and
    should we say many childs instead". In human language we have
    historical traditions. In JavaScript/HTML we have legacy pressure,
    which is sometimes more demanding than any traditions. If W3 had any
    bolls and common sense, they would simply move HTML form standards in a
    separate section (together with A, IMG, FRAME and IFRAME). But they
    prefer to act as if all standards indeed being changed with each paper
    W3 produces.
     
    VK, Jul 11, 2005
    #11
  12. "VK" <> writes:

    > Form elements without names will not be submited (even if they have
    > id's set) !


    I think you are talking about form controls (with tag names, e.g.,
    input, select, ...) and not form elements (with the tag name "form").

    Apart from that, I agree. W3C has the unappreciated job of trying to
    standardize already existing de-facto standards, with most users
    either not knowing or not caring about anything but the existing
    implementations.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jul 11, 2005
    #12
  13. bedhead

    VK Guest

    >> Form elements without names will not be submited (even if they have
    >> id's set) !


    >I think you are talking about form controls (with tag names, e.g.,
    >input, select, ...) and not form elements (with the tag name "form").


    Well, we have document.forms[0].elements[0]
    So for the term consistency <input>, <button> etc. should be called
    "form elements" (and they were for many years).

    And <form> itself is "form object" or simply "form(s)" (Occam's razor).

    Just a suggestion...
     
    VK, Jul 11, 2005
    #13
  14. On 11/07/2005 13:37, VK wrote:

    [VK:]
    >>> Form elements without names will not be submited (even if they have
    >>> id's set) !


    [LRN:]
    >> I think you are talking about form controls (with tag names, e.g.,
    >> input, select, ...) and not form elements (with the tag name "form").

    >
    > Well, we have document.forms[0].elements[0]


    Property names used in the DOM are of no concern when you're discussing
    HTML.

    > So for the term consistency <input>, <button> etc. should be called
    > "form elements" [...]


    <p>...</p>

    is a P element,

    <form action="...">...</form>

    is a FORM element, and

    <input>

    is an INPUT element. So, it is correct to refer to a form as a FORM
    element, but confusing to refer to the elements within it as form
    elements as that could be construed as many FORMs.

    The HTML Specification introduces the notion of 'controls' itself in
    section 17.2, aptly titled "Controls", so it would seem to be a very
    simple method of distinction.

    [snip]

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Jul 11, 2005
    #14
  15. Michael Winter schrieb:

    > On 11/07/2005 01:06, Matt Kruse wrote:
    > > 2) Multiple forms can have the same name [...]

    >
    > No.


    Yes, they certainly can.

    <form action="" name="foo"><p></p></form>
    <form action="" name="foo"><p></p></form>

    is perfectly Valid HTML 4.01 (Strict!).

    > The name and id attributes share the same namespace for most
    > elements.


    That is correct but does not matter here.

    > The uniqueness constraint applies equally when using either attribute
    > with a FORM element, as well as A, APPLET, FRAME, IFRAME, IMG and MAP
    > elements.


    No, it certainly does not at all.

    > See a few paragraphs into section 12.2.3 - Anchors with the id
    > attribute.


    You read the section, particularly the "ILLEGAL EXAMPLE" not in context
    or not carefully enough. `id' (ID) is not `name' (here: CDATA).
    Uniqueness in (X)HTML is only a matter when IDs are involved, i.e. two
    different elements may not have the same ID, and when name _and_ ID are
    the same, they must not be of different elements (to avoid ambiguity of
    fragment identifiers).

    Different `form' elements in one HTML document may of course have the
    same value for the `name' attribute or short: the same name. In the
    element of the `document.forms' collection and the value returned by
    the HTMLDocument.getElementsByName() method, they then make up an
    collection of their own.

    And when you think about it: not allowing the same name for different
    elements would render the getElementsByTagName() method of the W3C DOM's
    HTMLDocument interface redundant.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jul 12, 2005
    #15
  16. "Thomas 'PointedEars' Lahn" <> writes:

    > and when name _and_ ID are the same, they must not be of different
    > elements (to avoid ambiguity of fragment identifiers).


    Actually, it's the othe way around. When "id" and "name" attributes
    are both on the same element, they must be identical (with certain
    exceptions, including form controls). Otherwise, there is no
    requirement that two elements in the same namespace cannot have the
    same string as respectively name and id.


    > And when you think about it: not allowing the same name for different
    > elements would render the getElementsByTagName() method of the W3C DOM's
    > HTMLDocument interface redundant.


    Not necessarily. You can use gEBTN in different contexts, e.g., inside
    a form, where there can be elements with the same name attriubute
    (form controls). That does not preclude restricting names on form
    elements to not be identical (there is no such restriction, but gEBTN
    is not an argument against there being one :)

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jul 12, 2005
    #16
  17. Lasse Reichstein Nielsen schrieb:

    > "Thomas 'PointedEars' Lahn" <> writes:
    > > and when name _and_ ID are the same, they must not be of different
    > > elements (to avoid ambiguity of fragment identifiers).

    >
    > Actually, it's the othe way around. When "id" and "name" attributes
    > are both on the same element, they must be identical (with certain
    > exceptions, including form controls).


    Please, that is just a matter of wording.
    My wording is: if (x.A == y.B) x == y;
    Your wording is: if (x.A && x.B && !exception) x.A == x.B;

    > Otherwise, there is no requirement that two elements in the same
    > namespace cannot have the same string as respectively name and id.


    No, _IDs_ MUST always be unique.

    > > And when you think about it: not allowing the same name for
    > > different elements would render the getElementsByTagName() method
    > > of the W3C DOM's HTMLDocument interface redundant.

    >
    > Not necessarily. You can use gEBTN in different contexts, e.g.,
    > inside a form, where there can be elements with the same name
    > attriubute (form controls). That does not preclude restricting names
    > on form elements to not be identical (there is no such restriction,
    > but gEBTN is not an argument against there being one :)


    I think you just blew up my logic module, but you are probably right :)
    However, not all same-named elements can be referred to via
    HTMLCollection objects, therefore getElementsByTagName() is necessary
    as a means to refer to elements by name.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jul 12, 2005
    #17
  18. On 12/07/2005 13:51, Thomas 'PointedEars' Lahn wrote:

    > Michael Winter schrieb:
    >
    >> [Multiple forms cannot have the same name attribute value.]

    >
    > Yes, they certainly can.
    >
    > <form action="" name="foo"><p></p></form>
    > <form action="" name="foo"><p></p></form>
    >
    > is perfectly Valid HTML 4.01 (Strict!).


    Based on what criteria? An SGML validator isn't an indicator either way
    because the DTD cannot, in this instance, express the constraint because
    name attributes (with one exception) are CDATA.

    >> The name and id attributes share the same namespace for most
    >> elements.

    >
    > That is correct but does not matter here.


    Yes, I concede to an error here. The reference I made isn't appropriate,
    but that doesn't end the matter. :)

    [snip]

    > Different `form' elements in one HTML document may of course have the
    > same value for the `name' attribute or short: the same name. In the
    > element of the `document.forms' collection and the value returned by
    > the HTMLDocument.getElementsByName() method, they then make up an
    > collection of their own.


    In the latter, yes. In the former, no. Neither Mozilla (including recent
    Firefox releases), Netscape, nor Opera versions prior to 7.11 (possibly
    earlier, but definitely later than 7.03) return a collection from the
    forms collection. I would assume that Opera only changed their behaviour
    as they continued the trend to be a compromise between IE and the W3C.

    As I see it, the name attribute was introduced into HTML for the IMG and
    FORM elements (ignore the previous list) for the benefit of Netscape. It
    missed proper support for the id attribute, but had implemented name, so
    in a revision published 1999-12-04, HTML 4.0 added the name attribute
    but immediately marked it as a compatibility feature.

    The attribute, in these cases (it has actual uses with other elements),
    was always meant as an identifier analogous to the id attribute:

    "JavaScript can use the NAME attribute to differentiate different
    forms if there are multiple forms on a page."
    -- Netscape HTML Tag Reference[1]

    One can hardly differentiate if the same name is used, and as such the
    forms collection will return the first FORM element in source order in
    the browsers I mentioned above (and probably others, too).

    [snip]

    > And when you think about it: not allowing the same name for different
    > elements would render the getElementsByTagName() method of the W3C DOM's
    > HTMLDocument interface redundant.


    What's the getElementsByTagName method got to do with this? As for
    getElementsByName, the answer there is actually quite simple: the
    HTMLCollection interface is only meant to return single
    Node-implementing objects via the item and namedItem methods (and the
    property accessor equivalents). That browsers return a collection is a
    product of DOM 0, not DOM 1 or 2. As such, the getElementsByName method
    was meant to fill this void.

    Of course, I'm not, nor have I been, a member of the HTML or DOM Working
    Groups, so this is just my interpretation of events.

    Mike


    [1]
    <URL:http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1292308>

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Jul 12, 2005
    #18
  19. "Thomas 'PointedEars' Lahn" <> writes:

    > Lasse Reichstein Nielsen schrieb:
    >
    >
    > Please, that is just a matter of wording.
    > My wording is: if (x.A == y.B) x == y;
    > Your wording is: if (x.A && x.B && !exception) x.A == x.B;


    I agree with the representation of the logic, and I don't think
    it's a matter of the wording. What your wording states is not
    correct. This is valid code:

    <img id="foo" src="something.png">
    <img name="foo" src="something.png">

    but is not allowed by your wording.

    You are correct in the context of anchors (<a> elements with a name
    attribute), where the anchor name must be unique in a document, but
    name attributes on other elements does not (necessarily) become
    anchors (i.e., valid targets for fragment identifiers).

    (This is all in section 12.2 of the HTML 4.01 specification)

    >> Otherwise, there is no requirement that two elements in the same
    >> namespace cannot have the same string as respectively name and id.

    >
    > No, _IDs_ MUST always be unique.


    Absolutely, but what I tried to say was that the example above is
    allowed ("respectively" should rule out that both are "id"'s).
    The word "namespace" doesn't really make sense, though. I was
    thinking about the namespace defind by a form, but it's really
    irrelevant.


    > I think you just blew up my logic module, but you are probably right :)


    I think we are both wrong, because getElementsByTagName uses the tag
    name (duh :) and not the name attribute, so it's not really relevant.
    We were probably both thinking of getElementsByName from HTMLDocument :).

    > However, not all same-named elements can be referred to via
    > HTMLCollection objects, therefore getElementsByTagName() is necessary
    > as a means to refer to elements by name.


    .... if one should be so inclined. In XHTML documents, only form
    controls are returned by gEBN, and for most uses, the name attribute
    is only retained for backwards compatability.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jul 12, 2005
    #19
  20. Lasse Reichstein Nielsen schrieb:

    > "Thomas 'PointedEars' Lahn" <> writes:
    > > Lasse Reichstein Nielsen schrieb:
    > > Please, that is just a matter of wording.
    > > My wording is: if (x.A == y.B) x == y;
    > > Your wording is: if (x.A && x.B && !exception) x.A == x.B;

    >
    > I agree with the representation of the logic, and I don't think
    > it's a matter of the wording. What your wording states is not
    > correct. This is valid code:
    >
    > <img id="foo" src="something.png">
    > <img name="foo" src="something.png">
    >
    > but is not allowed by your wording. [...]


    Yes, it is not Valid HTML since the `alt' attribute is missing ;-)

    Seriously, you are probably right. Interestingly, the W3C Validator
    does not care about that either.

    > >> Otherwise, there is no requirement that two elements in the same
    > >> namespace cannot have the same string as respectively name and id.

    > >
    > > No, _IDs_ MUST always be unique.

    >
    > Absolutely, but what I tried to say was that the example above is
    > allowed ("respectively" should rule out that both are "id"'s).
    > The word "namespace" doesn't really make sense, though. I was
    > thinking about the namespace defind by a form, but it's really
    > irrelevant.


    ACK

    > > I think you just blew up my logic module, but you are probably
    > > right :)

    >
    > I think we are both wrong, because getElementsByTagName uses the tag
    > name (duh :) and not the name attribute, so it's not really relevant.
    > We were probably both thinking of getElementsByName from
    > HTMLDocument :).


    Oh my, yes of course! :) Sorry for causing confusion.

    > > However, not all same-named elements can be referred to via
    > > HTMLCollection objects, therefore getElementsByTagName() is
    > > necessary as a means to refer to elements by name.

    >
    > ... if one should be so inclined. In XHTML documents, only form
    > controls are returned by gEBN, and for most uses, the name
    > attribute is only retained for backwards compatability.


    No, in XHTML 1.0 _Strict_, the following elements do have the `name'
    attribute:

    meta, a, object, param, map, input, select, textarea, button.

    Only four of them can be considered form elements.

    In XHTML 1.1, the following elements do have the `name' attribute:

    - in the Applet Module: param
    - in the Basic Forms Module: input, select, textarea
    - in the Forms Module: input, select, textarea, button
    - in the Object Module: object, param
    - in the Metainformation Module: meta

    I don't care about XHTML 2.0, it is not a Recommendation (yet).


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jul 13, 2005
    #20
    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. Brad

    FireFox/innerHTML and <area> tags

    Brad, Oct 29, 2004, in forum: Javascript
    Replies:
    1
    Views:
    124
    Jeff North
    Oct 30, 2004
  2. Hoss
    Replies:
    7
    Views:
    248
  3. Replies:
    4
    Views:
    215
  4. sonic
    Replies:
    5
    Views:
    293
    Randy Webb
    Jul 11, 2006
  5. Replies:
    6
    Views:
    277
Loading...

Share This Page