W3C home > Mailing lists > Public > www-style@w3.org > April 2013

[css21] What's the used value of left/right when overconstrained in relpos?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 29 Apr 2013 11:11:21 -0700
Message-ID: <CAAWBYDACtbXa=nxCExkYs3WMRLb1SBP=5CR6hiMOTO1Hv9X2Gw@mail.gmail.com>
To: www-style list <www-style@w3.org>
When doing relpos layout, if both 'left' and 'right' are non-auto, the
layout is overconstrained.  CSS 2.1 says to ignore the value
left/right (depending on document direction), and treat it as being
the negation of the other.

But what does this actually mean?

Specifically, CSS 2.1 says this:

"If neither 'left' nor 'right' is 'auto', the position is
over-constrained, and one of them has to be ignored. If the
'direction' property of the containing block is 'ltr', the value of
'left' wins and 'right' becomes -'left'. If 'direction' of the
containing block is 'rtl', 'right' wins and 'left' is ignored."

No mention of used values is made here, so it's unclear exactly what
it means to "become -'left'", or "[be] ignored".

We had a long-open bug (from 2009) on this issue in WebKit, and are
now trying to fix it in Blink
<https://chromiumcodereview.appspot.com/13871003/>.  The engineer
writing up the patch is assuming that the text above actually means
that the used value for left/right is the value you solve for.  That
is, in a situation like this:

.item {
  position: relative;
  left: 100px;
  right: 20px;

...the used value for 'right' would be "-100px".  (And that's what
would be returned by getComputedStyle().right.)

Note that the spec *does* require this behavior for top/bottom, using
the proper words.  When overconstrained, the used value of bottom
explicitly becomes the negation of 'top'.

However, Chrome, FF, and IE all return "20px" for 'right' in the above
example. :/  What's the right behavior?

(Also, the spec is similarly undefined when talking about abspos
overconstrained situations.  Would be nice to get an answer for that
as well, hopefully consistent with this one.)

Received on Monday, 29 April 2013 18:12:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC