Skip to content

C.4.2 out-of-range flag values note is invalid/unsupported, should be dropped #324

Closed

Description

@tshinnic

In arguing elsewhere for a strict implementation of the SVG 1.1 F.6 Elliptical arc implementation notes I noted two points that 'everyone' gets wrong:

  • rx/xy values forced to absolute value, and
  • nonzero flag values forced to '1'.

Now I see that the grammar for SVG2 has dropped the insistence on rx/ry being nonnegative numbers. This is wonderful as:

  • previously the grammar contradicted the implementation notes,
  • the browsers got it right anyway, and
  • everybody else (many software libraries/modules) got it wrong as they read only the grammar and not the implementation notes.

Now 'everybody' might have a reason to believe the implementation notes when they say:

If rx or ry have negative signs, these are dropped; the absolute value is used instead.

 
However, for my second nit, I see that SVG2 C.4.2. Out-of-range parameters still insists that

Any nonzero value for either of the flags fA or fS is taken to mean the value 1.

while the grammar still insists on flag::=("0"|"1").

Now in fact browsers do insist on flag values of '0' or '1'. And the SVG 1.1 test suite insists on flag values of '0' or '1', which is what the browsers probably copied.

The C.4.2 note carried over from SVG 1.1/1.0

Any nonzero value for either of the flags fA or fS is taken to mean the value 1.

should be dropped as it was never implemented by at least the major browsers, which chose to support the stated grammar and the expected test results.

Activity

  1. boggydigital commented on Jun 11, 2018

    @boggydigital
    Contributor

    Not blocking updated 2.0 CR publication - assigning 2.0 Recommendation milestone to clean this up before 2.0 REC

  2. svgeesus commented on Aug 5, 2018

    @svgeesus
    Contributor

    Agreeing that this non-implemented and contradictory constraint should simply be dropped.

  3. self-assigned this
    on Aug 5, 2018
  4. added a commit that references this issue on Aug 5, 2018
    19a857a
  5. AmeliaBR commented on Aug 5, 2018

    @AmeliaBR
    Contributor

    Yes, this seems to be a simple "match reality" change.

    (Even though I personally wish that the grammar allowed you to recreate behavior described for SMIL animation, and supported in-between values that round to 0 or 1. But the grammar & the major implementations win out.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions