- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 11 Jun 2018 09:32:47 -0700
- 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. ~TJ
Received on Monday, 11 June 2018 16:33:26 UTC