Loading ...
Sorry, an error occurred while loading the content.

Re: Bottom border on fgclass does not span popup

Expand Messages
  • Robert E Boughner
    ... white (though it does turn purple with a white background on hover) when I use my IE5.5 (haven t tried IE6 yet). I suspect that is simply because you have
    Message 1 of 20 , Apr 29 6:30 AM
    • 0 Attachment
      --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
      > ----- Original Message -----
      > From: Robert E Boughner
      > To: overlibmws@yahoogroups.com
      > Sent: Wednesday, April 28, 2004 8:40 PM
      > Subject: [OLmws] Re: Bottom border on fgclass does not span popup
      >
      > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...:
      > <snip>
      > I noticed that in both of them, the Close link content is not
      white (though it does turn purple with a white background on hover)
      when I use my IE5.5 (haven't tried IE6 yet). I suspect that is simply
      because you have used the .olclo a:link { ) and .olclo a:hover { }
      form so that you don't encompass visited and active for IE. Once you
      have clicked on the Close link, it becomes visited on subsequent
      invocations of the popup. There is no such problem when I try it with
      my Opera7 and NS7.1. They apparently use your .olclo { } rules when
      there is no explicit rule for visited.
      > Both of these examples work the same in IE6, Netscape 7.1, Opera
      7.23, and Mozilla 1.7b for me on my Windows XP Professional machine.
      > Bob,
      >
      > Is there a reason why you changed it from the a.olclo { } and
      a.olclo:hover { } form that I had used, which does also work with
      visited links for versions of IE earlier than v6.0? E.g, does that
      form have problems with any browsers I haven't tested and thus don't
      yet know about? Or did you just change it because it "ought" to work
      based on the W3C standards?
      >
      I switched because your approach didn't work in IE6.0 for me on my
      Windows XP machine but that my version did work. By that I mean that
      the hover action wasn't being applied.
    • Robert E Boughner
      ... the separator between the caption and Close link area and main text area. You might want to add that to keep the example documents in register for any
      Message 2 of 20 , Apr 29 7:27 AM
      • 0 Attachment
        --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
        > ----- Original Message -----
        > From: Robert E Boughner
        > To: overlibmws@yahoogroups.com
        > Sent: Wednesday, April 28, 2004 8:40 PM
        > Subject: [OLmws] Re: Bottom border on fgclass does not span popup
        >
        > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
        wrote:
        > Note that I've added another example in:
        >
        > http://www.macridesweb.com/oltest/CSScgBorder.html
        >
        > which uses a 4px dashed green line for the outer border and for
        the separator between the "caption and Close link" area and "main
        text" area. You might want to add that to keep the example documents
        in register for any future discussions that might come up about using
        CSS effectively with the popups.
        > This example is shown for both the Core module of overlib and the
        CSSW3C Plugin at
        >
        > http://overlib.boughner.us/MWSExamples/CSScgBorder_3.html
        >
        > Note that you'll see some differences here between browsers
        because of the way that they consider the "background". I believe the
        Mozilla based browsers are doing it correctly because the background
        should show through the gaps in the border. This isn't being done in IE6.
        > Bob,
        >
        > Thanks for pointing out the browser difference. I looked into it
        and here is what is going on. The Gecko-engine browsers will use the
        element's own style.backgroundColor for the spaces between the dashes
        if it is not null or the null string, and otherwise will use the
        parent's style.backgroundColor if it is not null or the null string.
        IE instead always starts seeking a style.backgroundColor for its parent.
        >
        > I accordingly tweaked the:
        >
        > http://www.macridesweb.com/oltest/CSScgBorder.html
        >
        > examples so that with overlibmws the popup intended to have a green
        dashed border will also have a specifiable color between the dashes
        via its parent's style.backgroundColor. I chose purple, and so the
        border has green and purple dashes for all of the supported browsers,
        and with the body's style.backgroundColor remaining pale blue.
        >
        > The equivalent tweak could be used for the "standard" v4.00 to yield
        the more desirable and consistent handling of a dashed border across
        the supported browsers (well, except NS4, which simply ignores that
        "too modern" CSS rule, but still behaves fine for the rest of the
        popup styling, such that it can validly be considered to exhibit a
        "graceful fallback" behavior).
        >
        > But it remains to be determined whether this consistent behavior
        across the supported browsers can be accomplished with your CSSW3C plugin.
        >

        The change in the CSSW3C Plugin is shown at
        http://overlib.boughner.us/MWSExamples/CSScgBorder_3.html The only
        changes that were made are shown by the Salmon colored areas in the
        bottom-most code display. All that was done was to change the
        background color for the overDiv container from #ffffaa to #c030c0;
        and made the background color for the body text area #ffffaa. For
        some reason this works totally consistently in Mozilla 1.7rc1,
        Netscape 7.1, and Opear 7.23 but not in IE6.0 and I have no
        explanation why at this time. This may be an example of potential
        bugs in IE's adherence to the standards. The tweak that you made
        could also be done in the "Standard" version of overlib, which isn't
        done in this file.
      • Foteos Macrides
        ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Thursday, April 29, 2004 9:30 AM Subject: [OLmws] Bottom border on fgclass does not span popup
        Message 3 of 20 , Apr 29 11:42 AM
        • 0 Attachment
          ----- Original Message -----
          Sent: Thursday, April 29, 2004 9:30 AM
          Subject: [OLmws] Bottom border on fgclass does not span popup
           
          --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
          <snip>
          Is there a reason why you changed it from the a.olclo { } and a.olclo:hover { } form that I had used, which does also work with visited links for versions of IE earlier than v6.0
          I switched because your approach didn't work in IE6.0 for me on my Windows XP machine but that my version did work.  By that I mean that the hover action wasn't being applied.
          Bob,
           
          I began wondering if this might be a Win9x versus NT / XP issue rather that an IE version issue, but I tried the a.olclo:hover { } form with your test file and the "standard" v4.00 (with or without your CSSW3C plugin), and that also didn't work for IE v5.5 on my Win9.x boxes, even though it does with overlibmws.
           
          Does my
           
           
          which is using the a.olclo:hover { } form with overlibmws work as intended with you IE6 on XP?  If so, then it is a library coding issue as opposed to only a platform and/or IE version issue.
           
          In any case, for your test document using v4.00 with or without your CSSW3C plugin, if you add
           
          .olclo a:visited {color: white;}
           
          it will be backward compatible with IE v5.5 on Win 9.x boxes.
           
          Fote
          --
           
        • Foteos Macrides
          ... From: Foteos Macrides To: overlibmws@yahoogroups.com Sent: Thursday, April 29, 2004 2:42 PM Subject: Re: [OLmws] Bottom border on fgclass does not span
          Message 4 of 20 , Apr 29 5:18 PM
          • 0 Attachment
            ----- Original Message -----
            Sent: Thursday, April 29, 2004 2:42 PM
            Subject: Re: [OLmws] Bottom border on fgclass does not span popup
            ----- Original Message -----
            Sent: Thursday, April 29, 2004 9:30 AM
            Subject: [OLmws] Bottom border on fgclass does not span popup
             
            --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
            <snip>
            Is there a reason why you changed it from the a.olclo { } and a.olclo:hover { } form that I had used, which does also work with visited links for versions of IE earlier than v6.0
            I switched because your approach didn't work in IE6.0 for me on my Windows XP machine but that my version did work.  By that I mean that the hover action wasn't being applied.
            Bob,
             
            I began wondering if this might be a Win9x versus NT / XP issue rather that an IE version issue, but I tried the a.olclo:hover { } form with your test file and the "standard" v4.00 (with or without your CSSW3C plugin), and that also didn't work for IE v5.5 on my Win9.x boxes, even though it does with overlibmws.
            Bob,
             
            It's been quite a while since I looked at the code for your LGFs, but when I did tonight to try to sort this out, the reason for these difference became immediately and trivially obvious.
             
            I include a class attribute for CLOSEFONTCLASS (which in the examples we set to 'olclo') in the Close anchor start tag, so overlibmws can use a.olclo:hover { } CSS rules for hovers over "anchors which have the 'olclo' class."  You do not include it in the anchor start tag, and thus can't set the rules that way.  You put it in the right table data (td) cell which contains the Close anchor, and must depend on a "cascade" to the Close anchor via .olclo a:hover { } rules.  Then, for IE (but not the Geckos or Opera7), you must include both .olclo a:link { } and .olclo a:visited { } rules.  The overlibmws users instead can set .olclo { } or a.olclo { } rules which apply to all Close anchor conditions (and merely modify them for the hover condition via a.olco:hover { } rules) across the supported browsers.
             
            So there does not appear to be anything mysterious about these behaviors if one considers the code differences.
             
            Fote
            --
             
          • Robert E Boughner
            ... a.olclo:hover { } form that I had used, which does also work with visited links for versions of IE earlier than v6.0 ... Windows XP machine but that my
            Message 5 of 20 , Apr 30 4:59 AM
            • 0 Attachment
              --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
              > ----- Original Message -----
              > From: Robert E Boughner
              > To: overlibmws@yahoogroups.com
              > Sent: Thursday, April 29, 2004 9:30 AM
              > Subject: [OLmws] Bottom border on fgclass does not span popup
              >
              > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
              wrote:
              > <snip>
              > Is there a reason why you changed it from the a.olclo { } and
              a.olclo:hover { } form that I had used, which does also work with
              visited links for versions of IE earlier than v6.0
              > I switched because your approach didn't work in IE6.0 for me on my
              Windows XP machine but that my version did work. By that I mean that
              the hover action wasn't being applied.
              > Bob,
              >
              > I began wondering if this might be a Win9x versus NT / XP issue
              rather that an IE version issue, but I tried the a.olclo:hover { }
              form with your test file and the "standard" v4.00 (with or without
              your CSSW3C plugin), and that also didn't work for IE v5.5 on my
              Win9.x boxes, even though it does with overlibmws.
              >
              > Does my
              >
              > http://www.macridesweb.com/oltest/CSScgBorder.html
              >
              > which is using the a.olclo:hover { } form with overlibmws work as
              intended with you IE6 on XP? If so, then it is a library coding issue
              as opposed to only a platform and/or IE version issue.
              >

              Yes this file seems to work as you've set it up in IE6.0 on my XP
              machine.

              > In any case, for your test document using v4.00 with or without your
              CSSW3C plugin, if you add
              >
              > olclo a:visited {color: white;}
              >
              > it will be backward compatible with IE v5.5 on Win 9.x boxes.
              >

              Your point here is well taken. I thought of adding that but I didn't
              because it didn't seem to be needed in IE6.0 on my XP machine.
              Unfortunately I don't have access to IE5.5 to test on.
            • Robert E Boughner
              ... a.olclo:hover { } form that I had used, which does also work with visited links for versions of IE earlier than v6.0 ... my Windows XP machine but that my
              Message 6 of 20 , Apr 30 5:04 AM
              • 0 Attachment
                --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
                > ----- Original Message -----
                > From: Foteos Macrides
                > To: overlibmws@yahoogroups.com
                > Sent: Thursday, April 29, 2004 2:42 PM
                > Subject: Re: [OLmws] Bottom border on fgclass does not span popup
                > ----- Original Message -----
                > From: Robert E Boughner
                > To: overlibmws@yahoogroups.com
                > Sent: Thursday, April 29, 2004 9:30 AM
                > Subject: [OLmws] Bottom border on fgclass does not span popup
                >
                > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
                wrote:
                > <snip>
                > Is there a reason why you changed it from the a.olclo { } and
                a.olclo:hover { } form that I had used, which does also work with
                visited links for versions of IE earlier than v6.0
                > I switched because your approach didn't work in IE6.0 for me on
                my Windows XP machine but that my version did work. By that I mean
                that the hover action wasn't being applied.
                > Bob,
                >
                > I began wondering if this might be a Win9x versus NT / XP issue
                rather that an IE version issue, but I tried the a.olclo:hover { }
                form with your test file and the "standard" v4.00 (with or without
                your CSSW3C plugin), and that also didn't work for IE v5.5 on my
                Win9.x boxes, even though it does with overlibmws.
                > Bob,
                >
                > It's been quite a while since I looked at the code for your LGFs,
                but when I did tonight to try to sort this out, the reason for these
                difference became immediately and trivially obvious.
                >
                > I include a class attribute for CLOSEFONTCLASS (which in the
                examples we set to 'olclo') in the Close anchor start tag, so
                overlibmws can use a.olclo:hover { } CSS rules for hovers over
                "anchors which have the 'olclo' class." You do not include it in the
                anchor start tag, and thus can't set the rules that way. You put it
                in the right table data (td) cell which contains the Close anchor, and
                must depend on a "cascade" to the Close anchor via .olclo a:hover { }
                rules. Then, for IE (but not the Geckos or Opera7), you must include
                both .olclo a:link { } and olclo a:visited { } rules. The overlibmws
                users instead can set .olclo { } or a.olclo { } rules which apply to
                all Close anchor conditions (and merely modify them for the hover
                condition via a.olco:hover { } rules) across the supported browsers.
                >
                > So there does not appear to be anything mysterious about these
                behaviors if one considers the code differences.
                >
                I believe your explanation is correct. I made that change because I
                personally feel that having the class assigned to the TD cell allows
                the user more flexibility in using CSS rather than when its assigned
                to the anchor tag as it was originally in overlib.
              • Foteos Macrides
                ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Friday, April 30, 2004 8:04 AM Subject: Re: [OLmws] Bottom border on fgclass does not span
                Message 7 of 20 , Apr 30 2:32 PM
                • 0 Attachment
                  ----- Original Message -----
                  Sent: Friday, April 30, 2004 8:04 AM
                  Subject: Re: [OLmws] Bottom border on fgclass does not span popup
                   
                  --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
                  I include a class attribute for CLOSEFONTCLASS (which in the examples we set to 'olclo') in the Close anchor start tag, so overlibmws can use a.olclo:hover { } CSS rules for hovers over "anchors which have the 'olclo' class."  You do not include it in the anchor start tag, and thus can't set the rules that way.  You put it in the right table data (td) cell which contains the Close anchor, and must depend on a "cascade" to the Close anchor via .olclo a:hover { } rules.  Then, for IE (but not the Geckos or Opera7), you must include both .olclo a:link { } and olclo a:visited { } rules.  The overlibmws users instead can set .olclo { } or a.olclo { } rules which apply to all Close anchor conditions (and merely modify them for the hover condition via a.olco:hover { } rules) across the supported browsers.
                  I believe your explanation is correct.  I made that change because I personally feel that having the class assigned to the TD cell allows the user more flexibility in using CSS rather than when its assigned to the anchor tag as it was originally in overlib
                  Bob,
                   
                  You raise the issue of overlib's "history" and that can be important to consider, but in relation to the issue of "backward compatibility"  -- i.e., the key principle of code development, that the newer, more powerful code should avoid, if at all possible, breaking existing documents which were using the earlier code.
                   
                  If you refresh your memory via the overlibmws Change History:
                   
                   
                  the overlibmws library was "born" in the summer of 2002 by virtue of my desire to improve the CSS support that had been introduced by Erik in the "standard" overlib v3.50 release.  What you are referring to above is the need, evident already way back then, that the ability to use block-level CSS rules validly for the caption and Close link area was sorely needed.
                   
                  I'm happy for users of the "standard" overlib that some support of block-level CSS rules for that area was finally added almost two years later in v4.00, but unfortunately it was done in a way that needlessly isn't backward compatible (across the full range of supported browsers) with any pre-existing documents that were using the "standard" overlib through v3.51 with the .class { } or a.class { } rules for inline-level styling of the Close link via CLOSEFONTCLASS.  Also, in considering how you had to use CAPTIONFONTCLASS and CLOSEFONTCLASS to achieve the intended styling in the examples we've been discussing, v4.00 has muddled the nomenclature for the class-based CSS styling commands.
                   
                  Instead, for overlibmws, back in the summer of 2002, use of CAPTIONFONTCLASS and CLOSEFONTCLASS specifically for inline-level CSS styling rules (about "fonts" and such) was retained -- and no pre-exiting documents which used the .class {} or a.class { } form for CLOSEFONTCLASS would have broken with any of the supported browsers.  Instead, I added CGCLASS for the block-level styling in that area, for a nomenclature consistent with that of BGCLASS and FGCLASS for block-level styling of the outer-most border and in the main text area, respectively, and with TEXTFONTCLASS specifically for inline-level ("fonts" and such) styling in the main text area.
                   
                  These issues also are important for new users, such as Matt whom I had tried to coax into discussion in this group about the CSS support  Overlib "styling" originally was written so that "commands" or their associated variables are used to set attribute values in the elements of the embedded table markup created and inserted dynamically into the overDiv positioned div (layer).  This to a large extent is like WYSIWYG HTML editors of the old school which sought to let users generate HTML documents without needing to know anything substantive about HTML markup and its W3C standards.  Matt, who is quite knowledgeable about CSS, had no pre-existing documents with overlib popups such that "backward compatibility" was not an issue in his mind.  He wanted to use "modern" CSS styling as much as possible without need to master an old-fashioned WYSIWYG HTML editor-like command structure for styling.  And even though CSS support has been a primary concern for me in overlibmws, Matt found the experience of "getting off the ground" with overlib popups in that way very frustrating (though he did achieve his objectives and appears to be happier now :<).
                   
                  For example, as I had hoped to bring out with the examples and our discussion of them, the outer-most popup border uses the BORDER command to set the cellpadding attribute value in the outer-most table start tag, not its border attribute value.  That is because the intent was to create a simple, flat, outer-most border for the popup, not a "3-dimensional" border that varies considerably and is more or less "appealing" across the supported browsers, as use of the border attribute value would have done.  The jwin library, when it was alive and kicking, did use the border attribute value, and there were regular complaints about the "ugliness" of its popup's borders.  Note that to use BGCLASS for fancy CSS outer-most borders, both Bob and I also made BORDER,0 the page default, so as to -- in fact -- make the outermost table's cellpadding 0, which I'm sure makes perfect sense to Bob as well as me, but is "counterintuitive" for new users like Matt.  Neither Erik's nor my support site as yet have adequate documentation about such matters.
                   
                  This may be interesting to Dennis Sandow (welcome aboard, Dennis) , who himself appears to favor use of the "WYSIWYG commands-based" styling instead of class-based CSS styling, and has often expressed the opinion that the FULLHTML command should be eliminated as bloat.  At a point of high frustration, Matt considered using overlibmws merely for positioning and other "behavioral" control (tootips versus stickies, mouseoff, etc.) and the FULLHTML command for use of what, in effect, were his own Layer Generation Functions (LGFs -- what create the markup inserted dynamically into the overDiv layer) that were embedded div-based instead of embedded table-based HTML markup, and were optimized for use of CSS.  Of course, Dennis keeps thinking of FULLHTML simply as an adjunct to the BACKGROUND command, as it was originally in old versions of overlib, rather than in this context.  But I've often thought about generating a "minimal" version of overlib which is stripped down to the positioning and other "behavioral" control, and uses shell (wrapper) scripts for CSS-optimized LGFs.
                   
                  Bob has in a sense begun that kind of thing via his CSSW3C plugin, which dynamically applies CSS styling rules to the overDiv positioned div, rather than restricting itself to styling embedded table markup.  But such plugins typically require somewhere between 10 to 1000 times as much code as do shell (wrapper) or other small support scripts, as I used for dynamic styling of the overDiv positioned div with overlibmwsi in:
                   
                   
                  and as Bob acknowledged could be done homologously with the "standard" overlib v4.00 core, without need for a plugin module (and we still don't know if the CSSW3C plugin could do it in a manner that also works as intended with IE browsers).
                   
                  But whether it's done via support scripts or formal plugins (or both, as alternatives offered to users based on their "comfort levels" with javascript), I think the basic issue Bob sought to address via his CSSW3C plugin is important and should be discussed, hopefully motivating enhancements of overlib based on what is brought out in those discussions.  It would be great to have LGFs which as much as possible are optimized for styling via CSS rules, and not just CSS-enabling kludges into code that started off with "WYSIWYG editor-like commands-based" styling of the popups.
                   
                  Fote
                  --
                   
                • Robert E Boughner
                  ... examples we set to olclo ) in the Close anchor start tag, so overlibmws can use a.olclo:hover { } CSS rules for hovers over anchors which have the
                  Message 8 of 20 , Apr 30 5:28 PM
                  • 0 Attachment
                    --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
                    > ----- Original Message -----
                    > From: Robert E Boughner
                    > To: overlibmws@yahoogroups.com
                    > Sent: Friday, April 30, 2004 8:04 AM
                    > Subject: Re: [OLmws] Bottom border on fgclass does not span popup
                    >
                    > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
                    wrote:
                    > I include a class attribute for CLOSEFONTCLASS (which in the
                    examples we set to 'olclo') in the Close anchor start tag, so
                    overlibmws can use a.olclo:hover { } CSS rules for hovers over
                    "anchors which have the 'olclo' class." You do not include it in the
                    anchor start tag, and thus can't set the rules that way. You put it
                    in the right table data (td) cell which contains the Close anchor, and
                    must depend on a "cascade" to the Close anchor via .olclo a:hover { }
                    rules. Then, for IE (but not the Geckos or Opera7), you must include
                    both .olclo a:link { } and olclo a:visited { } rules. The overlibmws
                    users instead can set olclo { } or a.olclo { } rules which apply to
                    all Close anchor conditions (and merely modify them for the hover
                    condition via a.olco:hover { } rules) across the supported browsers.
                    > I believe your explanation is correct. I made that change because
                    I personally feel that having the class assigned to the TD cell allows
                    the user more flexibility in using CSS rather than when its assigned
                    to the anchor tag as it was originally in overlib
                    > Bob,
                    >
                    > You raise the issue of overlib's "history" and that can be important
                    to consider, but in relation to the issue of "backward compatibility"
                    -- i.e., the key principle of code development, that the newer, more
                    powerful code should avoid, if at all possible, breaking existing
                    documents which were using the earlier code.
                    >

                    I agree with you on this point that the new approach may break
                    existing code, but I doubt very much if it affected that many people,
                    other than yourself who has always supported css styling. The old
                    way, in my thinking was totally wrong since it applied the custom
                    clases to the wrong things. They were much too narrow based and
                    that's why they were changed here. As for the use of the CSSSTYLE
                    plugin in overlib, I totally agree with you that it should be dropped
                    since you can do so much more with custom classes. However, Erik
                    feels that is should be retained because it has been requested by his
                    user base.

                    > If you refresh your memory via the overlibmws Change History:
                    >
                    > http://www.macridesweb.com/oltest/changeHistory.html
                    >
                    > the overlibmws library was "born" in the summer of 2002 by virtue of
                    my desire to improve the CSS support that had been introduced by Erik
                    in the "standard" overlib v3.50 release. What you are referring to
                    above is the need, evident already way back then, that the ability to
                    use block-level CSS rules validly for the caption and Close link area
                    was sorely needed.
                    >
                    > I'm happy for users of the "standard" overlib that some support of
                    block-level CSS rules for that area was finally added almost two years
                    later in v4.00, but unfortunately it was done in a way that needlessly
                    isn't backward compatible (across the full range of supported
                    browsers) with any pre-existing documents that were using the
                    "standard" overlib through v3.51 with the .class { } or a.class { }
                    rules for inline-level styling of the Close link via CLOSEFONTCLASS.
                    Also, in considering how you had to use CAPTIONFONTCLASS and
                    CLOSEFONTCLASS to achieve the intended styling in the examples we've
                    been discussing, v4.00 has muddled the nomenclature for the
                    class-based CSS styling commands.
                    >
                    > Instead, for overlibmws, back in the summer of 2002, use of
                    CAPTIONFONTCLASS and CLOSEFONTCLASS specifically for inline-level CSS
                    styling rules (about "fonts" and such) was retained -- and no
                    pre-exiting documents which used the .class {} or a.class { } form for
                    CLOSEFONTCLASS would have broken with any of the supported browsers.
                    Instead, I added CGCLASS for the block-level styling in that area, for
                    a nomenclature consistent with that of BGCLASS and FGCLASS for
                    block-level styling of the outer-most border and in the main text
                    area, respectively, and with TEXTFONTCLASS specifically for
                    inline-level ("fonts" and such) styling in the main text area.
                    >

                    To tell you the truth I never really tried to understand what the
                    CGCLASS command was for and I'm glad that you've mentioned it here.
                    Also I glad to see that you appreciate my CSSW3C plugin since you
                    initially discounted it when I introduced it. In a lot of ways I've
                    structured it in much the same way that I'm doing it now in v4.00 for
                    the custom classes. Or maybe I should say that that approach was made
                    me change in v4.00.

                    > These issues also are important for new users, such as Matt whom I
                    had tried to coax into discussion in this group about the CSS support
                    Overlib "styling" originally was written so that "commands" or their
                    associated variables are used to set attribute values in the elements
                    of the embedded table markup created and inserted dynamically into the
                    overDiv positioned div (layer). This to a large extent is like
                    WYSIWYG HTML editors of the old school which sought to let users
                    generate HTML documents without needing to know anything substantive
                    about HTML markup and its W3C standards. Matt, who is quite
                    knowledgeable about CSS, had no pre-existing documents with overlib
                    popups such that "backward compatibility" was not an issue in his
                    mind. He wanted to use "modern" CSS styling as much as possible
                    without need to master an old-fashioned WYSIWYG HTML editor-like
                    command structure for styling. And even though CSS support has been a
                    primary concern for me in overlibmws, Matt found the experience of
                    "getting off the ground" with overlib popups in that way very
                    frustrating (though he did achieve his objectives and appears to be
                    happier now :<).
                    >
                    > For example, as I had hoped to bring out with the examples and our
                    discussion of them, the outer-most popup border uses the BORDER
                    command to set the cellpadding attribute value in the outer-most table
                    start tag, not its border attribute value. That is because the intent
                    was to create a simple, flat, outer-most border for the popup, not a
                    "3-dimensional" border that varies considerably and is more or less
                    "appealing" across the supported browsers, as use of the border
                    attribute value would have done. The jwin library, when it was alive
                    and kicking, did use the border attribute value, and there were
                    regular complaints about the "ugliness" of its popup's borders. Note
                    that to use BGCLASS for fancy CSS outer-most borders, both Bob and I
                    also made BORDER,0 the page default, so as to -- in fact -- make the
                    outermost table's cellpadding 0, which I'm sure makes perfect sense to
                    Bob as well as me, but is "counterintuitive" for new users like Matt.
                    Neither Erik's nor my support site as yet have adequate documentation
                    about such matters.
                    >

                    Yes the use of the 3-dimensional settings in CSS can give you some
                    really, IMHO, interesting looking popups as shown in my documentation
                    page (http://overlib.boughner.us/plugins/cssw3c_commands.html) where I
                    show a normal popup that is wrapped in an overdiv container that has a
                    "pictureframe" type of border styling.

                    Bob Boughner
                  • Foteos Macrides
                    ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Friday, April 30, 2004 8:28 PM Subject: Re: [OLmws] Bottom border on fgclass does not span
                    Message 9 of 20 , May 3, 2004
                    • 0 Attachment
                      ----- Original Message -----
                      Sent: Friday, April 30, 2004 8:28 PM
                      Subject: Re: [OLmws] Bottom border on fgclass does not span popup
                       
                      --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
                      I include a class attribute for CLOSEFONTCLASS (which in the examples we set to 'olclo') in the Close anchor start tag, so overlibmws can use a.olclo:hover { } CSS rules for hovers over "anchors which have the 'olclo' class"  You do not include it in the anchor start tag, and thus can't set the rules that way.  You put it in the right table data (td) cell which contains the Close anchor, and must depend on a "cascade" to the Close anchor via .olclo a:hover { } rules.  Then, for IE (but not the Geckos or Opera7), you must include both .olclo a:link { } and .oclo a:visited { } rules.  The overlibmws users instead can set .olclo { } or a.olclo { } rules which apply to all Close anchor conditions (and merely modify them for the hover condition via a.olco:hover { } rules) across the supported browsers.
                      I believe your explanation is correct.  I made that change because I personally feel that having the class assigned to the TD cell allows the user more flexibility in using CSS rather than when its assigned to the anchor tag as it was originally in overlib
                      You raise the issue of overlib's "history" and that can be important to consider, but in relation to the issue of "backward compatibility" -- i.e., the key principle of code development, that the newer, more powerful code should avoid, if at all possible, breaking existing documents which were using the earlier code.
                       
                      If you refresh your memory via the overlibmws Change History:

                      http://www.macridesweb.com/oltest/changeHistory.html

                      the overlibmws library was "born" in the summer of 2002 by virtue of my desire to improve the CSS support that had been introduced by Erik in the "standard" overlib v3.50 release.  What you are referring to above is the need, evident already way back then, that the ability to use block-level CSS rules validly for the caption and Close link area was sorely needed.

                      I'm happy for users of the "standard" overlib that some support of block-level CSS rules for that area was finally added almost two years later in v4.00, but unfortunately it was done in a way that needlessly isn't backward compatible (across the full range of supported browsers) with any pre-existing documents that were using the "standard" overlib through v3.51 with the .class { } or a.class { } rules for inline-level styling of the Close link via CLOSEFONTCLASS.  Also, in considering how you had to use CAPTIONFONTCLASS and CLOSEFONTCLASS to achieve the intended styling in the examples we've been discussing, v4.00 has muddled the nomenclature for the class-based CSS styling commands.

                      Instead, for overlibmws, back in the summer of 2002, use of CAPTIONFONTCLASS and CLOSEFONTCLASS specifically for inline-level CSS styling rules (about "fonts" and such) was retained -- and no pre-exiting documents which used the .class {} or a.class { } form for CLOSEFONTCLASS would have broken with any of the supported browsers.  Instead, I added CGCLASS for the block-level styling in that area, for a nomenclature consistent with that of BGCLASS and FGCLASS for block-level styling of the outer-most border and in the main text area, respectively, and with TEXTFONTCLASS specifically for inline-level ("fonts" and such) styling in the main text area.
                      I agree with you on this point that the new approach may break existing code, but I doubt very much if it affected that many people, other than yourself who has always supported css styling.
                       
                      But soon thereafter ncsoft@... wrote:
                      I noticed that i'm using an old version of overlib so I've just upgraded to 4.00.

                      My closefontclass no longer works - In the example below I was using the following style

                      A:link.gridpopt , A:visited.gridpopt  {
                            color:white;
                            font-weight:bold;
                            text-decoration:none;
                            background-color:#376A0A;
                            border:1px solid white;
                            padding:1px;
                            font-family:Georgia, sans-serif;
                      }

                      This worked fine in v3.5, but does not work anymore.
                       
                      Bob,
                       
                      In quality software development, it is best to respect the principle of backward compatibility.  As I explained, your v4.00 enhancement objectives could have been met without breaking Mark's existing HTML files for earlier versions of the "standard" overlib.
                       
                      Fote
                      --
                       
                    • Robert E Boughner
                      ... examples we set to olclo ) in the Close anchor start tag, so overlibmws can use a.olclo:hover { } CSS rules for hovers over anchors which have the
                      Message 10 of 20 , May 3, 2004
                      • 0 Attachment
                        --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
                        > ----- Original Message -----
                        > From: Robert E Boughner
                        > To: overlibmws@yahoogroups.com
                        > Sent: Friday, April 30, 2004 8:28 PM
                        > Subject: Re: [OLmws] Bottom border on fgclass does not span popup
                        >
                        > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
                        wrote:
                        > I include a class attribute for CLOSEFONTCLASS (which in the
                        examples we set to 'olclo') in the Close anchor start tag, so
                        overlibmws can use a.olclo:hover { } CSS rules for hovers over
                        "anchors which have the 'olclo' class" You do not include it in the
                        anchor start tag, and thus can't set the rules that way. You put it
                        in the right table data (td) cell which contains the Close anchor, and
                        must depend on a "cascade" to the Close anchor via .olclo a:hover { }
                        rules. Then, for IE (but not the Geckos or Opera7), you must include
                        both .olclo a:link { } and .oclo a:visited { } rules. The overlibmws
                        users instead can set olclo { } or a.olclo { } rules which apply to
                        all Close anchor conditions (and merely modify them for the hover
                        condition via a.olco:hover { } rules) across the supported browsers.
                        > I believe your explanation is correct. I made that change because
                        I personally feel that having the class assigned to the TD cell allows
                        the user more flexibility in using CSS rather than when its assigned
                        to the anchor tag as it was originally in overlib
                        > You raise the issue of overlib's "history" and that can be
                        important to consider, but in relation to the issue of "backward
                        compatibility" -- i.e., the key principle of code development, that
                        the newer, more powerful code should avoid, if at all possible,
                        breaking existing documents which were using the earlier code.
                        >
                        > If you refresh your memory via the overlibmws Change History:
                        >
                        > http://www.macridesweb.com/oltest/changeHistory.html
                        >
                        > the overlibmws library was "born" in the summer of 2002 by
                        virtue of my desire to improve the CSS support that had been
                        introduced by Erik in the "standard" overlib v3.50 release. What you
                        are referring to above is the need, evident already way back then,
                        that the ability to use block-level CSS rules validly for the caption
                        and Close link area was sorely needed.
                        >
                        > I'm happy for users of the "standard" overlib that some support
                        of block-level CSS rules for that area was finally added almost two
                        years later in v4.00, but unfortunately it was done in a way that
                        needlessly isn't backward compatible (across the full range of
                        supported browsers) with any pre-existing documents that were using
                        the "standard" overlib through v3.51 with the .class { } or a.class {
                        } rules for inline-level styling of the Close link via CLOSEFONTCLASS.
                        Also, in considering how you had to use CAPTIONFONTCLASS and
                        CLOSEFONTCLASS to achieve the intended styling in the examples we've
                        been discussing, v4.00 has muddled the nomenclature for the
                        class-based CSS styling commands.
                        >
                        > Instead, for overlibmws, back in the summer of 2002, use of
                        CAPTIONFONTCLASS and CLOSEFONTCLASS specifically for inline-level CSS
                        styling rules (about "fonts" and such) was retained -- and no
                        pre-exiting documents which used the .class {} or a.class { } form for
                        CLOSEFONTCLASS would have broken with any of the supported browsers.
                        Instead, I added CGCLASS for the block-level styling in that area, for
                        a nomenclature consistent with that of BGCLASS and FGCLASS for
                        block-level styling of the outer-most border and in the main text
                        area, respectively, and with TEXTFONTCLASS specifically for
                        inline-level ("fonts" and such) styling in the main text area.
                        > I agree with you on this point that the new approach may break
                        existing code, but I doubt very much if it affected that many people,
                        other than yourself who has always supported css styling.
                        >
                        > But soon thereafter ncsoft@y... wrote:
                        > I noticed that i'm using an old version of overlib so I've just
                        upgraded to 4.00.
                        >
                        > My closefontclass no longer works - In the example below I was
                        using the following style
                        >
                        > A:link.gridpopt , A:visited.gridpopt {
                        > color:white;
                        > font-weight:bold;
                        > text-decoration:none;
                        > background-color:#376A0A;
                        > border:1px solid white;
                        > padding:1px;
                        > font-family:Georgia, sans-serif;
                        > }
                        >
                        > This worked fine in v3.5, but does not work anymore.
                        >
                        > Bob,
                        >
                        > In quality software development, it is best to respect the principle
                        of backward compatibility. As I explained, your v4.00 enhancement
                        objectives could have been met without breaking Mark's existing HTML
                        files for earlier versions of the "standard" overlib.
                        >
                        >
                        The way I look at it, this whole thing about how to have custom
                        classes incorporated is still undergoing development. I personally
                        believe that the way is was done earlier was not right and shouldn't
                        have been done that way. But if I had done what you suggest here then
                        you would have accused me of code "bloat" like you've done many times
                        in the past. I run into many "quality" software which has required me
                        to make changes in how I've done it before; this is a whole new
                        approach to how overlib works and that is the reason that it has v4.00
                        attached to it. But your point is well taken in the future versions
                        of overlib I'll try to maintain backward compatibility with v4.00 or
                        later versions.
                      • Foteos Macrides
                        ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Monday, May 03, 2004 5:41 PM Subject: [OLmws] Re: Bottom border on fgclass does not span popup
                        Message 11 of 20 , May 4, 2004
                        • 0 Attachment
                          ----- Original Message -----
                          Sent: Monday, May 03, 2004 5:41 PM
                          Subject: [OLmws] Re: Bottom border on fgclass does not span popup
                           
                          --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
                          In quality software development, it is best to respect the principle of backward compatibility.  As I explained, your v4.00 enhancement objectives could have been met without breaking Mark's existing HTML files for earlier versions of the "standard" overlib.
                          The way I look at it, this whole thing about how to have custom classes incorporated is still undergoing development.  I personally believe that the way is was done earlier was not right and shouldn't have been done that way.  But if I had done what you suggest here then you would have accused me of code "bloat" like you've done many times in the past.  I run into many "quality" software which has required me to make changes in how I've done it before; this is a whole new approach to how overlib works and that is the reason that it has v4.00 attached to it.  But your point is well taken in the future versions of overlib I'll try to maintain backward compatibility with v4.00 or later versions.
                          Bob,
                           
                          Those are really lame rationalizations.  But I'm glad to see that overnight you apparently overcame your immature emotional reactions to criticism, and in Erik's support group you forthrightly apologized to Mark for unnecessarily breaking his pre-existing HTML files with class-based CSS styling.
                           
                          Fote
                          --
                           
                        Your message has been successfully submitted and would be delivered to recipients shortly.