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

Dom.getStyle reports some negative margins in Safari

Expand Messages
  • Satyam
    I found an issue which I cannot understand. I m trying to find how much space is available in a container. I read the width of the container, and then I
    Message 1 of 7 , Dec 2, 2008
    • 0 Attachment
      I found an issue which I cannot understand.

      I'm trying to find how much space is available in a container. I read
      the width of the container, and then I subtract the margins of the
      intended content. I use Dom.getStyle to read 'width' (of the container)
      and 'marginLeft' and 'marginRight' of the content. In Firefox and IE
      everything is right. In Safari, 'marginLeft' and 'marginRight' give me
      negative values, which I have never set anywhere. Actually, I am
      explicitly setting margins, like this:

      .content { margin: 0px 0px 0px 20px; }

      and when doing so, marginLeft correctly reports '20px' while marginRight
      reports '-20px'.

      This only happens in Safari.

      Well, actually, Firefox reports 'false' for some of those margins set to
      "0px". Who said, 0px is false? I can fix this one by doing:
      (parseInt(Dom.getStyle(someEl,'marginLeft'),10) || 0)
      which doesn't make me happy, but it works.

      I can also fix the negative values by assuming 0 when it is negative and
      the overall numbers would fit, but I would rather know what's up.

      Thanks

      Satyam
    • Matt Sweeney
      ... Hi Satyam, I ran some tests with Dom.getStyle, and am getting the correct results across the A-grade for all margins, set via CSS as you ve specified. As a
      Message 2 of 7 , Dec 2, 2008
      • 0 Attachment
        Satyam wrote:
        > I found an issue which I cannot understand.
        >
        > I'm trying to find how much space is available in a container. I read
        > the width of the container, and then I subtract the margins of the
        > intended content. I use Dom.getStyle to read 'width' (of the container)
        > and 'marginLeft' and 'marginRight' of the content. In Firefox and IE
        > everything is right. In Safari, 'marginLeft' and 'marginRight' give me
        > negative values, which I have never set anywhere. Actually, I am
        > explicitly setting margins, like this:
        >
        > .content { margin: 0px 0px 0px 20px; }
        >
        > and when doing so, marginLeft correctly reports '20px' while marginRight
        > reports '-20px'.
        >
        > This only happens in Safari.
        >
        > Well, actually, Firefox reports 'false' for some of those margins set to
        > "0px". Who said, 0px is false? I can fix this one by doing:
        > (parseInt(Dom.getStyle(someEl,'marginLeft'),10) || 0)
        > which doesn't make me happy, but it works.
        >
        > I can also fix the negative values by assuming 0 when it is negative and
        > the overall numbers would fit, but I would rather know what's up.
        >
        > Thanks
        >
        > Satyam
        >
        >
        Hi Satyam,

        I ran some tests with Dom.getStyle, and am getting the correct results
        across the A-grade for all margins, set via CSS as you've specified.

        As a sanity check, compare what you are seeing from Dom.getStyle with
        what getComputedStyle reports (getStyle uses computedStyle when no
        inline style is available).

        Something like:
        if (window.getComputedStyle) {
        var demo = document.getElementById('demo'),
        computed = getComputedStyle(demo, '');

        console.log(computed.marginTop);
        console.log(computed.marginRight);
        console.log(computed.marginBottom);
        console.log(computed.marginLeft);
        }

        Also, what other styles are being applied to the content element?

        Thanks,

        Matt
      • Satyam
        Hi Matt In http://satyam.com.ar/yui/2.5.0/progressbar/test/ you can see the actual case, simplified as much as possible. In the logger window I log the values
        Message 3 of 7 , Dec 3, 2008
        • 0 Attachment
          Hi Matt

          In http://satyam.com.ar/yui/2.5.0/progressbar/test/

          you can see the actual case, simplified as much as possible. In the
          logger window I log the values of the margins under the category
          'satyam' so they can be filtered out easily:

          [line 261] YAHOO.log(Dom.getStyle(barEl,'marginTop') + ' ' +
          Dom.getStyle(barEl,'marginRight') +
          ' ' +Dom.getStyle(barEl,'marginBottom') + ' '
          +Dom.getStyle(barEl,'marginLeft'),
          this.get('direction'),'satyam');

          In IE and FF I get:

          BT 532ms (+14) 14:53:18:
          satyam
          20px 0px 20px 0px
          TB 518ms (+13) 14:53:18:
          satyam
          20px 0px 20px 0px
          RL 505ms (+12) 14:53:18:
          satyam
          0px 20px 0px 20px
          LR 493ms (+-54) 14:53:18:
          satyam
          0px 20px 0px 20px

          In Safari:

          BT 462ms (+5) 14:53:30:
          satyam
          20px 0px 20px 0px
          TB 457ms (+5) 14:53:30:
          satyam
          20px 0px 20px 0px
          RL 452ms (+5) 14:53:30:
          satyam
          0px -20px 0px 20px
          LR 447ms (+-15) 14:53:30:
          satyam
          0px -20px 0px 20px


          You can visualize the difference in the Progress bars. The green area is
          the bar, the orange is the background. Some of the masks used for the
          progress bar have caps at the ends and that is why I set margins to the
          bar, so it doesn't slip under those caps.

          The two letters in the log above refer to the direction the bar grows.
          LR is Left to right, TB is top to bottom and their reverse. As you can
          see in both horizontal bars, the right margins are returned as negative
          by Safari. I get the same result if I skip loading
          reset-fonts-grids.css or base.css and drop all other extra page
          formatting around the progress bar.

          Thanks

          Satyam


          Matt Sweeney wrote:
          > Satyam wrote:
          >
          >> I found an issue which I cannot understand.
          >>
          >> I'm trying to find how much space is available in a container. I read
          >> the width of the container, and then I subtract the margins of the
          >> intended content. I use Dom.getStyle to read 'width' (of the container)
          >> and 'marginLeft' and 'marginRight' of the content. In Firefox and IE
          >> everything is right. In Safari, 'marginLeft' and 'marginRight' give me
          >> negative values, which I have never set anywhere. Actually, I am
          >> explicitly setting margins, like this:
          >>
          >> .content { margin: 0px 0px 0px 20px; }
          >>
          >> and when doing so, marginLeft correctly reports '20px' while marginRight
          >> reports '-20px'.
          >>
          >> This only happens in Safari.
          >>
          >> Well, actually, Firefox reports 'false' for some of those margins set to
          >> "0px". Who said, 0px is false? I can fix this one by doing:
          >> (parseInt(Dom.getStyle(someEl,'marginLeft'),10) || 0)
          >> which doesn't make me happy, but it works.
          >>
          >> I can also fix the negative values by assuming 0 when it is negative and
          >> the overall numbers would fit, but I would rather know what's up.
          >>
          >> Thanks
          >>
          >> Satyam
          >>
          >>
          >>
          > Hi Satyam,
          >
          > I ran some tests with Dom.getStyle, and am getting the correct results
          > across the A-grade for all margins, set via CSS as you've specified.
          >
          > As a sanity check, compare what you are seeing from Dom.getStyle with
          > what getComputedStyle reports (getStyle uses computedStyle when no
          > inline style is available).
          >
          > Something like:
          > if (window.getComputedStyle) {
          > var demo = document.getElementById('demo'),
          > computed = getComputedStyle(demo, '');
          >
          > console.log(computed.marginTop);
          > console.log(computed.marginRight);
          > console.log(computed.marginBottom);
          > console.log(computed.marginLeft);
          > }
          >
          > Also, what other styles are being applied to the content element?
          >
          > Thanks,
          >
          > Matt
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          > ------------------------------------------------------------------------
          >
          >
          > No virus found in this incoming message.
          > Checked by AVG - http://www.avg.com
          > Version: 8.0.176 / Virus Database: 270.9.12/1824 - Release Date: 02/12/2008 9:31
          >
          >
        • Matt Sweeney
          Satyam, As a sanity check, compare what you are seeing from Dom.getStyle with what getComputedStyle reports (getStyle uses computedStyle when no inline style
          Message 4 of 7 , Dec 3, 2008
          • 0 Attachment
            Satyam,

            As a sanity check, compare what you are seeing from Dom.getStyle with
            what getComputedStyle reports (getStyle uses computedStyle when no
            inline style is available).

            Something like:
            if (window.getComputedStyle) {
            var demo = document.getElementById('demo'),
            computed = getComputedStyle(demo, '');

            console.log(computed.marginTop);
            console.log(computed.marginRight);
            console.log(computed.marginBottom);
            console.log(computed.marginLeft);
            }

            This will tell us whether the issue lies within Safari or YUI. As
            Dom.getStyle is a simple pass-through for inline style/computed style,
            my hunch is that it is a Safari issue.

            In order to determine what other things may be impacting Safari's
            margins, boil this down to the bare layout (HTML and CSS) and see what
            values Dom gives you. Not using tables for layout may help, as the
            table layout algorithm may be impacting the margin collapsing.

            Thanks,

            Matt

            Satyam wrote:
            > Hi Matt
            >
            > In http://satyam.com.ar/yui/2.5.0/progressbar/test/
            >
            > you can see the actual case, simplified as much as possible. In the
            > logger window I log the values of the margins under the category
            > 'satyam' so they can be filtered out easily:
            >
            > [line 261] YAHOO.log(Dom.getStyle(barEl,'marginTop') + ' ' +
            > Dom.getStyle(barEl,'marginRight') +
            > ' ' +Dom.getStyle(barEl,'marginBottom') + ' '
            > +Dom.getStyle(barEl,'marginLeft'),
            > this.get('direction'),'satyam');
            >
            > In IE and FF I get:
            >
            > BT 532ms (+14) 14:53:18:
            > satyam
            > 20px 0px 20px 0px
            > TB 518ms (+13) 14:53:18:
            > satyam
            > 20px 0px 20px 0px
            > RL 505ms (+12) 14:53:18:
            > satyam
            > 0px 20px 0px 20px
            > LR 493ms (+-54) 14:53:18:
            > satyam
            > 0px 20px 0px 20px
            >
            > In Safari:
            >
            > BT 462ms (+5) 14:53:30:
            > satyam
            > 20px 0px 20px 0px
            > TB 457ms (+5) 14:53:30:
            > satyam
            > 20px 0px 20px 0px
            > RL 452ms (+5) 14:53:30:
            > satyam
            > 0px -20px 0px 20px
            > LR 447ms (+-15) 14:53:30:
            > satyam
            > 0px -20px 0px 20px
            >
            >
            > You can visualize the difference in the Progress bars. The green area is
            > the bar, the orange is the background. Some of the masks used for the
            > progress bar have caps at the ends and that is why I set margins to the
            > bar, so it doesn't slip under those caps.
            >
            > The two letters in the log above refer to the direction the bar grows.
            > LR is Left to right, TB is top to bottom and their reverse. As you can
            > see in both horizontal bars, the right margins are returned as negative
            > by Safari. I get the same result if I skip loading
            > reset-fonts-grids.css or base.css and drop all other extra page
            > formatting around the progress bar.
            >
            > Thanks
            >
            > Satyam
            >
            >
            > Matt Sweeney wrote:
            >
            >> Satyam wrote:
            >>
            >>
            >>> I found an issue which I cannot understand.
            >>>
            >>> I'm trying to find how much space is available in a container. I read
            >>> the width of the container, and then I subtract the margins of the
            >>> intended content. I use Dom.getStyle to read 'width' (of the container)
            >>> and 'marginLeft' and 'marginRight' of the content. In Firefox and IE
            >>> everything is right. In Safari, 'marginLeft' and 'marginRight' give me
            >>> negative values, which I have never set anywhere. Actually, I am
            >>> explicitly setting margins, like this:
            >>>
            >>> .content { margin: 0px 0px 0px 20px; }
            >>>
            >>> and when doing so, marginLeft correctly reports '20px' while marginRight
            >>> reports '-20px'.
            >>>
            >>> This only happens in Safari.
            >>>
            >>> Well, actually, Firefox reports 'false' for some of those margins set to
            >>> "0px". Who said, 0px is false? I can fix this one by doing:
            >>> (parseInt(Dom.getStyle(someEl,'marginLeft'),10) || 0)
            >>> which doesn't make me happy, but it works.
            >>>
            >>> I can also fix the negative values by assuming 0 when it is negative and
            >>> the overall numbers would fit, but I would rather know what's up.
            >>>
            >>> Thanks
            >>>
            >>> Satyam
            >>>
            >>>
            >>>
            >>>
            >> Hi Satyam,
            >>
            >> I ran some tests with Dom.getStyle, and am getting the correct results
            >> across the A-grade for all margins, set via CSS as you've specified.
            >>
            >> As a sanity check, compare what you are seeing from Dom.getStyle with
            >> what getComputedStyle reports (getStyle uses computedStyle when no
            >> inline style is available).
            >>
            >> Something like:
            >> if (window.getComputedStyle) {
            >> var demo = document.getElementById('demo'),
            >> computed = getComputedStyle(demo, '');
            >>
            >> console.log(computed.marginTop);
            >> console.log(computed.marginRight);
            >> console.log(computed.marginBottom);
            >> console.log(computed.marginLeft);
            >> }
            >>
            >> Also, what other styles are being applied to the content element?
            >>
            >> Thanks,
            >>
            >> Matt
            >>
          • Gopal Venkatesan (गोपाल वे
            ... Satyam- I guess this issue might be related to this bug here. https://bugs.webkit.org/show_bug.cgi?id=13343 -- Gopal Venkatesan http://g13n.in/ Note: if
            Message 5 of 7 , Dec 3, 2008
            • 0 Attachment
              On Wed, Dec 3, 2008 at 6:15 AM, Satyam <satyam@...> wrote:
              > Hi Matt
              >
              > In http://satyam.com.ar/yui/2.5.0/progressbar/test/
              >
              > you can see the actual case, simplified as much as possible. In the
              > logger window I log the values of the margins under the category
              > 'satyam' so they can be filtered out easily:
              >
              > [line 261] YAHOO.log(Dom.getStyle(barEl,'marginTop') + ' ' +
              > Dom.getStyle(barEl,'marginRight') +
              > ' ' +Dom.getStyle(barEl,'marginBottom') + ' '
              > +Dom.getStyle(barEl,'marginLeft'),
              > this.get('direction'),'satyam');
              >
              > In IE and FF I get:
              >
              > BT 532ms (+14) 14:53:18:
              > satyam
              > 20px 0px 20px 0px
              > TB 518ms (+13) 14:53:18:
              > satyam
              > 20px 0px 20px 0px
              > RL 505ms (+12) 14:53:18:
              > satyam
              > 0px 20px 0px 20px
              > LR 493ms (+-54) 14:53:18:
              > satyam
              > 0px 20px 0px 20px
              >
              > In Safari:
              >
              > BT 462ms (+5) 14:53:30:
              > satyam
              > 20px 0px 20px 0px
              > TB 457ms (+5) 14:53:30:
              > satyam
              > 20px 0px 20px 0px
              > RL 452ms (+5) 14:53:30:
              > satyam
              > 0px -20px 0px 20px
              > LR 447ms (+-15) 14:53:30:
              > satyam
              > 0px -20px 0px 20px

              Satyam-

              I guess this issue might be related to this bug here.

              https://bugs.webkit.org/show_bug.cgi?id=13343

              --
              Gopal Venkatesan
              http://g13n.in/

              Note: if you see question marks (?????) after my name in the From
              header, then your mail tool is not Unicode enabled!
              You should see my name (Gopal Venkatesan) in Hindi (गोपाल वेंकटेसन)
            • Satyam
              Matt, getComputedStyle reports the same, see: http://satyam.com.ar/yui/2.5.0/progressbar/test/ It is the same code with both the Dom.getStyle and
              Message 6 of 7 , Dec 3, 2008
              • 0 Attachment
                Matt,

                getComputedStyle reports the same, see:

                http://satyam.com.ar/yui/2.5.0/progressbar/test/

                It is the same code with both the Dom.getStyle and window.getComputedStyle, for the 'LR' item, the computed style shows as 'LR C' (for 'lr computed'). All formatting is off, even the logger looks awful, though you can still click on the categories to filter only the 'satyam' category.

                See another message by Gopal Venkatesan, he found the bug report for this:

                https://bugs.webkit.org/show_bug.cgi?id=13343


                And if that isn't it, it is quite close.

                Satyam




                Matt Sweeney wrote:
                > Satyam,
                >
                > As a sanity check, compare what you are seeing from Dom.getStyle with
                > what getComputedStyle reports (getStyle uses computedStyle when no
                > inline style is available).
                >
                > Something like:
                > if (window.getComputedStyle) {
                > var demo = document.getElementById('demo'),
                > computed = getComputedStyle(demo, '');
                >
                > console.log(computed.marginTop);
                > console.log(computed.marginRight);
                > console.log(computed.marginBottom);
                > console.log(computed.marginLeft);
                > }
                >
                > This will tell us whether the issue lies within Safari or YUI. As
                > Dom.getStyle is a simple pass-through for inline style/computed style,
                > my hunch is that it is a Safari issue.
                >
                > In order to determine what other things may be impacting Safari's
                > margins, boil this down to the bare layout (HTML and CSS) and see what
                > values Dom gives you. Not using tables for layout may help, as the
                > table layout algorithm may be impacting the margin collapsing.
                >
                > Thanks,
                >
                > Matt
                >
                > Satyam wrote:
                >
                >> Hi Matt
                >>
                >> In http://satyam.com.ar/yui/2.5.0/progressbar/test/
                >>
                >> you can see the actual case, simplified as much as possible. In the
                >> logger window I log the values of the margins under the category
                >> 'satyam' so they can be filtered out easily:
                >>
                >> [line 261] YAHOO.log(Dom.getStyle(barEl,'marginTop') + ' ' +
                >> Dom.getStyle(barEl,'marginRight') +
                >> ' ' +Dom.getStyle(barEl,'marginBottom') + ' '
                >> +Dom.getStyle(barEl,'marginLeft'),
                >> this.get('direction'),'satyam');
                >>
                >> In IE and FF I get:
                >>
                >> BT 532ms (+14) 14:53:18:
                >> satyam
                >> 20px 0px 20px 0px
                >> TB 518ms (+13) 14:53:18:
                >> satyam
                >> 20px 0px 20px 0px
                >> RL 505ms (+12) 14:53:18:
                >> satyam
                >> 0px 20px 0px 20px
                >> LR 493ms (+-54) 14:53:18:
                >> satyam
                >> 0px 20px 0px 20px
                >>
                >> In Safari:
                >>
                >> BT 462ms (+5) 14:53:30:
                >> satyam
                >> 20px 0px 20px 0px
                >> TB 457ms (+5) 14:53:30:
                >> satyam
                >> 20px 0px 20px 0px
                >> RL 452ms (+5) 14:53:30:
                >> satyam
                >> 0px -20px 0px 20px
                >> LR 447ms (+-15) 14:53:30:
                >> satyam
                >> 0px -20px 0px 20px
                >>
                >>
                >> You can visualize the difference in the Progress bars. The green area is
                >> the bar, the orange is the background. Some of the masks used for the
                >> progress bar have caps at the ends and that is why I set margins to the
                >> bar, so it doesn't slip under those caps.
                >>
                >> The two letters in the log above refer to the direction the bar grows.
                >> LR is Left to right, TB is top to bottom and their reverse. As you can
                >> see in both horizontal bars, the right margins are returned as negative
                >> by Safari. I get the same result if I skip loading
                >> reset-fonts-grids.css or base.css and drop all other extra page
                >> formatting around the progress bar.
                >>
                >> Thanks
                >>
                >> Satyam
                >>
                >>
                >> Matt Sweeney wrote:
                >>
                >>
                >>> Satyam wrote:
                >>>
                >>>
                >>>
                >>>> I found an issue which I cannot understand.
                >>>>
                >>>> I'm trying to find how much space is available in a container. I read
                >>>> the width of the container, and then I subtract the margins of the
                >>>> intended content. I use Dom.getStyle to read 'width' (of the container)
                >>>> and 'marginLeft' and 'marginRight' of the content. In Firefox and IE
                >>>> everything is right. In Safari, 'marginLeft' and 'marginRight' give me
                >>>> negative values, which I have never set anywhere. Actually, I am
                >>>> explicitly setting margins, like this:
                >>>>
                >>>> .content { margin: 0px 0px 0px 20px; }
                >>>>
                >>>> and when doing so, marginLeft correctly reports '20px' while marginRight
                >>>> reports '-20px'.
                >>>>
                >>>> This only happens in Safari.
                >>>>
                >>>> Well, actually, Firefox reports 'false' for some of those margins set to
                >>>> "0px". Who said, 0px is false? I can fix this one by doing:
                >>>> (parseInt(Dom.getStyle(someEl,'marginLeft'),10) || 0)
                >>>> which doesn't make me happy, but it works.
                >>>>
                >>>> I can also fix the negative values by assuming 0 when it is negative and
                >>>> the overall numbers would fit, but I would rather know what's up.
                >>>>
                >>>> Thanks
                >>>>
                >>>> Satyam
                >>>>
                >>>>
                >>>>
                >>>>
                >>>>
                >>> Hi Satyam,
                >>>
                >>> I ran some tests with Dom.getStyle, and am getting the correct results
                >>> across the A-grade for all margins, set via CSS as you've specified.
                >>>
                >>> As a sanity check, compare what you are seeing from Dom.getStyle with
                >>> what getComputedStyle reports (getStyle uses computedStyle when no
                >>> inline style is available).
                >>>
                >>> Something like:
                >>> if (window.getComputedStyle) {
                >>> var demo = document.getElementById('demo'),
                >>> computed = getComputedStyle(demo, '');
                >>>
                >>> console.log(computed.marginTop);
                >>> console.log(computed.marginRight);
                >>> console.log(computed.marginBottom);
                >>> console.log(computed.marginLeft);
                >>> }
                >>>
                >>> Also, what other styles are being applied to the content element?
                >>>
                >>> Thanks,
                >>>
                >>> Matt
                >>>
                >>>
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                > ------------------------------------------------------------------------
                >
                >
                > No virus found in this incoming message.
                > Checked by AVG - http://www.avg.com
                > Version: 8.0.176 / Virus Database: 270.9.13/1825 - Release Date: 02/12/2008 20:44
                >
                >
              • Satyam
                ... I think this is it, you are right. Thanks Satyam
                Message 7 of 7 , Dec 3, 2008
                • 0 Attachment
                  Gopal Venkatesan (गोपाल वेंकटेसन) wrote:
                  > Satyam-
                  >
                  > I guess this issue might be related to this bug here.
                  >
                  > https://bugs.webkit.org/show_bug.cgi?id=13343
                  >
                  I think this is it, you are right. Thanks

                  Satyam
                Your message has been successfully submitted and would be delivered to recipients shortly.