- From: Jeremie Patonnier <jeremie.patonnier@gmail.com>
- Date: Sun, 10 Jun 2018 15:23:34 -0700
- 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>
- Message-ID: <CAEi838=ZrNiTV0+huUZtuVSE1KaTHu0n4Wo+O2xn4hXPLk2ZdQ@mail.gmail.com>
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). Best -- Jeremie ............................. Web : http://jeremie.patonnier.net Twitter : @JeremiePat <http://twitter.com/JeremiePat>
Received on Sunday, 10 June 2018 22:24:38 UTC