W3C home > Mailing lists > Public > www-svg@w3.org > June 2018

Re: Rectangle height and width

From: Jeremie Patonnier <jeremie.patonnier@gmail.com>
Date: Sun, 10 Jun 2018 15:23:34 -0700
Message-ID: <CAEi838=ZrNiTV0+huUZtuVSE1KaTHu0n4Wo+O2xn4hXPLk2ZdQ@mail.gmail.com>
To: Steven Pemberton <steven.pemberton@cwi.nl>
Cc: David Dailey <ddailey@zoominternet.net>, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, www-svg <www-svg@w3.org>
2018-06-10 3:26 GMT-07:00 Steven Pemberton <steven.pemberton@cwi.nl>:

> On Sat, 09 Jun 2018 18:42:24 +0200, Amelia Bellamy-Royds <
> amelia.bellamy.royds@gmail.com> wrote:
> While I agree with you both that it would be a mathematical convenience to
> define negative width/height as an inversion of the rectangle, but I think
> it is far too late to change this now. The restriction on negative numbers
> has been there since the beginning and is supported universally.
FWIW I'm 100% in an agreement with Amelia on this.

> By lifting the restriction you don't introduce any incompatibilities: old
> SVG files still render properly;

This is a big assumption that need to be back up by some data. Because SVG
have a certain behavior (a negative value will not render a rect), some
authors can relay on it. Especially because SVG can be scripted, we have to
assume that some author haven't bother to clamp negative values and assume
that their rect will not render.

> Furthermore, with SVG 2 conversion of width and height to presentation
> attributes with matching CSS properties means that we need to match the
> syntax used for the CSS properties, which have the same restriction.
> Matching the syntax doesn't require matching the semantics surely.

This is a hard topic. It could be possible to have a different behavior
between using a value in an attribute and using a value in a property. The
trick is that having different behavior for what will be perceived as the
same things by authors will be confusing and it is not desirable. On the
other hand, it is true that negative values have a perfectly valid
semantic. For that reason I would encourage you to bring that topic to the
CSS WG to discuss the opportunity to make the syntax more flexible to
accommodate that use case (be warned that the discussion will be tough as
no one will be super eager to change the CSS syntax without a very careful
real world analysis to make sure nothing will break).

Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>
Received on Sunday, 10 June 2018 22:24:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:14 UTC