[svgwg] Issue: Floating point number format discordance (SVG vs CSS vs browsers) marked as Agenda+

dirkschulze has just labeled an issue for https://github.com/w3c/svgwg as "Agenda+":

== Floating point number format discordance (SVG vs CSS vs browsers) ==
Summary:
  - SVG path grammar defines a number text format not found in CSS
  - some browsers only support the more restrictive CSS number formats
  - a sample set of SVG files did find uses of all the SVG formats
  - but the 'missing' format may not be used widely
  - what do with this discordance?
  - (added images for Edge/Chrome/FireFox)
  - (added codepen link for reviewing problem)


Having familiarized myself with the SVG grammar for floating point numbers I was surprised when a browser balked at drawing a manually-typed path that included a coordinate number "-41."

The SVG specs from 2011 and 2001 permit a full set of text representations for floating point numbers: "0", "0.0", ".0" and "0."  In comparison, CSS permits only three formats, "0", "0.0", ".0", explicitly omitting 
the format "0.". 

>From testing SVG path strings in browsers it would seem that both FireFox and Chrome have opted to implement only the CSS definition of floating point numbers.  They do not permit numbers of the form "0." as required by SVG.  Microsoft's Edge, the more recent implementation of SVG, *does conform* to the SVG spec and implements all four formats.  (the status of Safari is unknown to me)

.
Now the format "nn." could be considered a 'degenerate' or redundant form, having the obvious equivalent representations "nn.0" and "nn".  If the smallest set of formats was desired, then ".0" is replaceable by "0.0", resulting in only two formats needed, "nn" and "n.n"  But if providing representations that minimize number text lengths is desired, then ".0" is justified whereas "0." is not.  Perhaps this latter reasoning - text length - was used in the CSS specification for deciding which formats to include?

.
A hopelessly inadequate sample set of 22K SVG files was examined to see which floating point number formats were in use in the wild.  This file set *did* contain numbers of the form "nnn."  However, and 
significantly, these were found in only one file which is *internal* to the Inkscape application.  These numbers are never presented to a web browser.

Again, this sample set is not a valid cross-section of SVG files.  However, it is _possible_ that SVG files in the wild really have  restricted themselves to the smaller set of number formats supported across web browsers.  That the web has likely once again worked-around incomplete implementations is not surprising.

.
Some browsers have not implemented the now 16 year-old SVG specification.  Similarly amazing is that the SVG test cases, and currently the  W3C Web Platform Tests, never tested something as fundamental as the specified SVG number formats.

.
**The question of what to do now remains.**  Should SVG insist on application support for a simple number format, which requirement has been published for 16 years?   Or should the 'guideline' be invoked that specifications should drop those things not implemented by more than one application in a compatible manner?

.
Images from [Codepen demo](https://codepen.io/tshinnic/full/XgOvVP/):   (Note: red is 'bad')
Edge ![svg_svg2_fp_number_grammar_issue_edge](https://user-images.githubusercontent.com/842881/28194088-6e3e6f90-6807-11e7-9cba-d0a914ae9733.png) Chrome ![svg_svg2_fp_number_grammar_issue_chrome](https://user-images.githubusercontent.com/842881/28194094-79f4cb5e-6807-11e7-943a-82a75c310b43.png) FireFox ![svg_svg2_fp_number_grammar_issue_firefox](https://user-images.githubusercontent.com/842881/28194107-8bc31552-6807-11e7-891a-653fe58fccee.png)

.
Notes:

1) SVG number format definition:
    https://www.w3.org/TR/SVG/paths.html#PathDataBNF
            (then search for "floating-point-constant")

2) CSS floating point formats definition:
  https://www.w3.org/TR/css3-values/#numbers
  https://drafts.csswg.org/css-syntax-3/#typedef-number-token
  https://drafts.csswg.org/css-syntax-3/#number-token-diagram
>      When written literally, a number is either an integer,
>      or zero or more decimal digits followed by a dot (.)
>      followed by one or more decimal digits and optionally
>      an exponent composed of "e" or "E" and an integer.
(and this does not allow "123." )

3) Codepen test for number format support
      https://codepen.io/tshinnic/full/XgOvVP/

See https://github.com/w3c/svgwg/issues/331

Received on Thursday, 10 May 2018 16:37:08 UTC