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

Re: Rectangle height and width

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 11 Jun 2018 09:32:47 -0700
Message-ID: <CAAWBYDBFfLGFZ+-yRg4Eqa0PQi3LeuT-6xHt-ZQAtYOvuG8_JA@mail.gmail.com>
To: steven.pemberton@cwi.nl
Cc: ddailey <ddailey@zoominternet.net>, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, www-svg <www-svg@w3.org>
On Sun, Jun 10, 2018 at 3:30 AM Steven Pemberton
<steven.pemberton@cwi.nl> wrote:
> But it's a restriction, not a feature. You don't support a restriction, but adhere to it. By lifting the restriction you don't introduce any incompatibilities: old SVG files still render properly; however, by lifting it you do add new possibilities, and make life easier for SVG authors.

Not always the case. There may be SVG files in the wild which are
currently using this syntax and (accidentally) *relying* on it being
invalid, so that making it valid would suddenly mess up the image.
(This isn't uncommon in CSS.)

>> 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.

Semantics are at a later stage; Amelia is saying that the 'width'
property rejects negative values as a parse error immediately. CSS
isn't capable of applying different syntaxes based on what element a
property is applied to (because that information isn't available at
CSS-parse time), so either (a) *all* instances of 'width'
syntactically reject negative values (the current state), or (b) we
change CSS to allow negative 'width' values but deal with them somehow
as an error case at a later stage of the rendering pipeline, or (c) we
back off from the general "make as many SVG attributes as possible
into presentation attributes" effort, so that the width of a <rect>
can't be specified in CSS.

Received on Monday, 11 June 2018 16:33:26 UTC

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