Floating point number format discordance (SVG vs CSS vs browsers)

[tshinnic]

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:   (Note: red is 'bad') Edge Chrome FireFox

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

[tshinnic]

Bugs filed against FireFox and Chrome.

• https://bugzilla.mozilla.org/show_bug.cgi?id=1380902
• https://bugs.chromium.org/p/chromium/issues/detail?id=742690

In the second bug filed I mentioned how unfortunate it would be if discussion was avoided by the browser vendors.

[DavidBruchmann]

Opera 45.0 (most recent I think) is not passing the test. Safari I can't test. Some Linux Browsers I could test later.

[longsonr]

I think it's unlikely Firefox will do this unless the definition of number (https://www.w3.org/TR/css3-values/#numbers) is changed to match.

[tshinnic]

In closing the FireFox bug report as 'wontfix' longsonr points to the definition of number in chapter "4 Basic Data Types and Interfaces" as an inconsistency within SVG.

    Real numbers are specified in one of two ways. When used in a style sheet, 
    a <number> is defined as follows:
          number ::= integer
                     | [+-]? [0-9]* "." [0-9]+
    This syntax is the same as the definition in CSS ([CSS2], section 4.3.1).

    When used in an SVG attribute, a <number> is defined differently, 
    to allow numbers with large magnitudes to be specified more concisely:
          number ::= integer ([Ee] integer)?
                     | [+-]? [0-9]* "." [0-9]+ ([Ee] integer)?

That is, that prose definition does not include the "nnn." syntax defined within the SVG grammar.

Checking the SVG2 draft I see that chapter 4 was reorganized and now points to the definition of number in CSS Values level 3, which is defined there in prose much the same as the explanation above.

It must be admitted that the smallest change to produce consistency all over is to drop "nnn." from the SVG grammar. Comments?

[fuchsia]

Repost of the comment I made in #347:

<polygon  stroke="black" fill="red"  points=" 0. 32.   32. 0.  64. 32."/> 
<polyline stroke="black" fill="none" points="96. 32.  128. 0. 160. 32."/> 

The above draws a triangle and a chevron in SVG 1.1; but draws nothing in SVG 2.

That's because, in SVG 1.1, the points attribute is defined using a bespoke grammer which allow trailing dots on numbers. Whereas SVG2 uses the CSS definition of <number-token> which prohibits trailing dots, stopping the above rendering.

Is this intentional? If so, what's the rational for changing it here and not on pathdata?

It's probably worth pointing out that SVG 1.1 is inconsistent with itself: it allows trailing dots in pathdata and the points attribute, but prohibits them on all other numbers. So

<line stroke="black" x1="288." y1="0." x2="320." y2="32."/> 

is illegal. To me that suggests permitting them at all was bug in SVG 1.1.

Compatibility table: trailing dots allowed on numbers?

Desktop Browser	points	pathdata	general number attributes
Chrome 62.0	no	no	yes
Firefox 55.0.3	no	no	no
Edge ???	yes	yes	yes
Safari 10.1.2	no	no	no

Derived by running this fiddle and seeing what renders.

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="352px" height="96px">
  <polygon stroke="black" fill="red" points="0. 32.  32. 0.  64. 32." />
  <polyline stroke="black" fill="none" points="96. 32.  128. 0. 160. 32." />
  <path stroke="black" fill="red" d="M 192. 32. 224. 0. 256. 32." />
  <line stroke="black" x1="288." y1="0." x2="320." y2="32." />

  <text x="32" y="48" dominant-baseline="middle" text-anchor="middle">polygon</text>
  <text x="128" y="48" dominant-baseline="middle" text-anchor="middle">polyline</text>
  <text x="224" y="48" dominant-baseline="middle" text-anchor="middle">path</text>
  <text x="304" y="48" dominant-baseline="middle" text-anchor="middle">line</text>
</svg>

[zed-vector]

One could ask hypothetically if it would cause a problem if the CSS syntax rule were relaxed from 'one or more' to 'zero or more' decimal digits.

Does CSS actually need to specify 'one or more', or is that just how someone wrote it because it made sense to them at the time? Could "nn." conceivably in the future be used in CSS to mean something other than "nn.0"? Is the rule intended to avoid the misinterpretation of "nn." as being an integer?

Syntax rules should not arbitrarily prevent one from doing slightly unexpected things that are entirely harmless. In so far as it may be considered relevant, programming languages do not seem generally to take exception to "nn.".

Of course the likelihood of changing CSS makes this more a philosophical matter really.

[tabatkins]

Is this intentional?

Not particularly. It was just an attempt to move to an easier parser. Some minor differences aren't unexpected. Who's outputting numbers with a trailing . in their attribute values?

If so, what's the rational for changing it here and not on pathdata?

Pathdata is way messed up, with all sorts of weird parsing quirks that aren't compatible with CSS parsing, and which tooling absolutely takes full advantage of to minimize the weight of large paths. Switching it to CSS-based parsing would be a massive, frustrating, confusing effort, and I'm not even 100% sure it can be done with perfect fidelity. (As a simple example, h1v2 is a valid pathdata describing two commands each with a single argument. Under CSS parsing, it's a single ident token, which would have to be manually ripped apart back into commands.)

It's probably worth pointing out that SVG 1.1 is inconsistent with itself: it allows trailing dots in pathdata and the points attribute, but prohibits them on all other numbers.

Interesting. This makes me more convinced that, absent any notable breakage as a result of this, we shouldn't worry about the change.

---

@zed-vector CSS specified its number syntax this way long ago. It's how people actually write numbers; the fact that some programming languages allow 1. doesn't have any big impact here, because nobody does that. It's just a consequence of the way their grammar was put together, and someone going "eh, what's the harm".

I doubt there's anything actually problematic about allowing it today - for that to be the case, it would require a number followed by a . for some other purpose (a class selector?), and a minifier relying on current parsing rules to safely concat them into 1.foo. I don't think that happens anywhere right now, and I doubt it would happen in the future.

So there's probably no web-compat that would stop us from making the change. But there's also no particular reason for us to make the change. It would come with costs for browsers (in parser work and testing work), but with basically no benefit to browsers or authors. This is distinct from the change to the points attribute, where there is still a cost, but the benefit is that the browsers can delete some custom parsing code and just reuse the existing CSS parser, and authors have a more consistent syntax story between points and all the other numeric attributes in the platform.

[fuchsia]

@tabatkins I'm not worried about breakage; it's already broken in practice. What I'm after is consistency and a standard that matches up to browser behaviour.

That doesn't, however, mean we need to switch to the CSS parser for pathdata; we can just tweak the existing grammar. If you haven't seen, I've created #346 which fixes a bunch of other issues with the grammar. So if the WG wants, I'll update the PR to drop trailing dots from numbers as well. It's certainly sounding as if the door is open, even if I'm pulling when I should be pushing.

But, throwing crazy at the wall, finding some way of using the CSS parser on pathdata would simplify the maintenance of SVG. Pulling apart tokens is one possibility. But maybe the CSS parser needs to grow an entry point for consuming pathdata. Or maybe there's some other way to use CSS syntax. But the current "EBNF" is at it's limit: it's forcing people to write <number># from first principles, including whitespace. It will do for now. But, long term, a more sophisticated grammar would make it easier to extend pathdata without introducing bugs. And CSS is the obvious syntax, if we make it work.

[tabatkins]

But, throwing crazy at the wall, finding some way of using the CSS parser on pathdata would simplify the maintenance of SVG. Pulling apart tokens is one possibility. But maybe the CSS parser needs to grow an entry point for consuming pathdata.

That entry point would basically be a completely separate parser. CSS text is tokenized, then parsed into structures. Pathdata is fundamentally incompatible with CSS tokenization rules.

I do want to have a version of pathdata that's compatible with CSS; the current approach means that the CSS path() function has to literally take a string, like path("M0,0H10"), to avoid it getting parsed all wonky. But that would mean a grammar that would not be compatible with current pathdata in the wild. (It would almost certainly be a subset of the current pathdata grammar, but a lot of optimizations that today's tooling does to the value would no longer be allowed.)

(If that pathdata above was passed to CSS literally, like path(M0,0H10), that would parse as an ident token with the value M0, a comma token, then a dimension with the value 0 and the unit H10.)

[fuchsia]

I admit, I hadn't thought about unit suffixes. I had thought about M0.0 being split at the decimal point. And, in arcs, 000 can be three numbers while anything beginning 2-9 can be an illegal token, depending on how many numbers you've seen already; I'm reconciled to having to reparse numbers in arcs when that could be an issue.

But, forgetting about arcs, and working from Draft 25.

• Equip the tokeniser with a tokenising-pathdata flag.

• In "consume a numeric token" (4.3.3): have the tokeniser return the \<number-token> immediately after consuming it, when tokenising-pathdata is set. The token has to be returned as a string because of the aforementioned arc issues. (Or we add a state var that tracks how deep into an arc argument you are.)

• In "consume an ident-like token" (4.3.4): if the string consumed is "path" and it's followed by a LEFT PARENTHESIS then set the tokenising-pathdata flag and return an appropriate token.

• In "consume a token" (4.3.1):

  • Amend the U+0029 RIGHT PARENTHESIS ()) rule so that it clears the tokenising-pathdata flag.
  • And amend the name-start code point rule so it becomes:
  • If tokenising-pathdata is set, return a \<pathdata-command> token whose value is the code-point.
  • Otherwise reconsume the current input code point, consume an ident-like token, and return it.

I've probably screwed up the details or misunderstood something, but isn't that outline enough? Only returning numbers as strings strikes me as egregious. If the CSS parser grows an entry point that sets the tokenising-pathdata flag, then the whole SVG pathdata grammar can be condensed to:

<pathdata> = [<pathdata-command> [<number>#]*]*

Plus some rules for handling legacy elliptical arc arguments.

The arity and legality of commands can be handled at a higher level, just as you would in any programming language; it's not the role of grammar to name functions and specify their argument count.

---

Another suggestion I made was to give the SVGPathElement a property that returns the pathdata in a normal form: e.g. fully whitespace separated tokens. It doesn't have to be animated and it should stop at the first invalid number; i.e. it reflects what's actually drawn. Web programmers would love it because they could reliably parse pathdata by doing pathdata.split(' '). And it would create a subset of pathdata that bridges to the CSS norm. This may turn out to be a more practical solution that the above.

[tabatkins]

While I could theoretically do a special-case tokenization on path(), like I do for url(), I don't see any particularly good reason to do so. (And url() is a legacy case that I wish I could remove!) Just wrapping the content in " characters, and doing the actual parsing of the pathdata separately, does the same thing without any special-casing at all.

If I don't special-case on path(), I can't do it at all - allowing pathdata in any place would mean the tokenizer having to be aware of the context in which it is tokenizing, which is a layering violation. (And if I could do that, I'd have a dramatically easier time with <an+b> and <urange>.)

The CSS-ified version of path will look something like path(M 0 0, H 10) - path commands separated from the numbers, all numbers separated by whitespace, and the commands themselves separated by commas, all per standard CSS grammar patterns. Like I said, this is a subset of currently valid paths, but is completely friendly to the tokenizer.

[fuchsia]

I'm not going to argue for context-sensitive tokenisation, given pathdata is already marred by it.

The benefits of a special casing pathdata would be for the SVG standard not to include a low-level parser and for CSS standards not having to clone the SVG grammar; the gain is for the web collectively. But I respect your choice and won't press that further.

However if you are going to do the higher level logic then maybe the solution is for SVG to provide a legacy parser that can hand off to your logic. Or for SVG to provide an algorithm that rewrites legacy pathdata into your canonical form.

FWIW your CSS-ified form seem fine for human readers, and web devs could do something like pathdata.split(',').map( cmd => cmd.trim().split(/\s+/) ), even if it's a sod for char-by-char parsers I tend to write. Are you going allow multiple path segments in a "command" (e.g. L 0 0 1 1) or require a separate command for each (i.e. L 0 0, L 1 1)? What about commands where closepath has been used to fill in missing coordinates? For example Q needs four coordinates as arguments, but Q 1 1,Z is legal under SVG 2, while Q 1 1, M 1 1 isn't. Are you going to handle that in the grammar? Will you allow the trailing Z in the command (as Q 1 1 Z, M 1 1) or require it be a separate command?

[tabatkins]

The benefits of a special casing pathdata would be for the SVG standard not to include a low-level parser and for CSS standards not having to clone the SVG grammar; the gain is for the web collectively.

Which spec the parser lives in doesn't make a difference; both technologies are being implemented by the same browser. There's no benefit to moving it from one place to another.

maybe the solution is for SVG to provide a legacy parser that can hand off to your logic.

It already does so, essentially.

Or for SVG to provide an algorithm that rewrites legacy pathdata into your canonical form.

This is a levelling violation - the data has already been parsed by SVG at this point, the syntax is no longer relevant. The data is already in a nice parsed format inside the browser, usable by any part of the system. (And that is indeed what happens - we don't have totally separate notions of "SVG path data" vs "CSS path data", it's just "path data"; there just happens to be a particular parser that can transform strings into path data, specified by SVG.)

web devs could do something like pathdata.split(',').map( cmd => cmd.trim().split(/\s+/) )

Actually they can't. ^_^ Common problem with trying to do data-structure manipulation on the string level - you need to only split on top-level commas, but commas can appear inside of functions that are being used as values. (There's no reason for webdevs to do any of this parsing on their own, anyway; that's what we now have the Typed OM for.)

---

Now for some responses on my syntax sketch:

Are you going allow multiple path segments in a "command" (e.g. L 0 0 1 1) or require a separate command for each (i.e. L 0 0, L 1 1)?

Dunno. I think it's better to have them be separate commands; particularly when there's more than two arguments, it gets really difficult to immediately see the boundaries between commands otherwise. It's just a few characters extra for much improved readability.

What about commands where closepath has been used to fill in missing coordinates? For example Q needs four coordinates as arguments, but Q 1 1,Z is legal under SVG 2, while Q 1 1, M 1 1 isn't. Are you going to handle that in the grammar? Will you allow the trailing Z in the command (as Q 1 1 Z, M 1 1) or require it be a separate command?

Hadn't thought about it yet, but a trailing Z sounds like it might be reasonable. I'll run thru the possibilities when I actually write this out as a proper proposal.

[fuchsia]

I think we're talking at cross purposes. I'm supposing that we're going to end up with two definitions of pathdata (one in the SVG standard and another in CSS) written in two different languages. I wanted to avoid that -- not least because the EBNF is unmanageable and it's now the only place SVG 2 uses EBNF at all.

With that in mind, I'll just clarify a few other points:

maybe the solution is for SVG to provide a legacy parser that can hand off to your logic.

It already does so, essentially.

The idea here was that the pathdata grammar should be written once, using the rules in CSS Values and Units module. But that SVG would use its own legacy, layer-violating tokeniser instead of the one in the CSS Syntax Module.

This is a levelling violation - the data has already been parsed by SVG at this point, the syntax is no longer relevant. The data is already in a nice parsed format inside the browser, usable by any part of the system.

And the thinking here was to operate on strings coming from the "d" attribute before parsing. So we'd define an algorithm that would insert spaces, commas, and whatever else was needed to transform valid SVG-pathdata into valid CSS-pathdata.

Again, the end game is to allow the SVGWG to make changes to the grammar using the rules in CSS Values and Units rather than hokey XML-EBNF. So this transform would be a way of specifying the legacy quirks, and not necessarily something browsers need actually do in practice.

(There's no reason for webdevs to do any of this parsing on their own, anyway; that's what we now have the Typed OM for.)

The Typed-OM will be a godsend when it ships! But there's still a need to get at the individual segments of a path's d attribute.

Dunno. I think it's better to have them be separate commands;

That's the choice that makes me feel warmest and fuzziestest. Hopefully that intuition is a product of experience.

[dirkschulze]

In addition to <number> values and path data, there is <transforms> as well. All three have different parsing rules in the spec.

Path data as well as transforms have a more relaxed grammar than <number> and are consistent with each other.

• transforms: https://codepen.io/krit/pen/rvdOQX
• path data: https://codepen.io/krit/pen/wjmzzQ
• number attributes: https://codepen.io/krit/pen/JvLrbv (x, y, width and height)

Relaxed Syntax	Number Attributes	Transform	Path Data
Adobe Illustrator	yes	yes	yes
Edge	yes	yes	yes
Safari	yes	no	no
Chrome	yes	no	no
Firefox	no	no	no

The parsing code for path data and transforms in WebKit is the same. Adapting the code to the relaxed syntax is straight forward and I do have an experimental build.

If Edge is not willing to change their source code to the less flexible parsing rules then I'll land the patch in WebKit. Blink seems to use SkParse::FindScalars now so can't simply adapt the code from WebKit.

I also care about consistency and interoperability. However, I am not sure how compatible CSS numbers can get to SVG numbers and IMO it is fine to have a difference between the two number types as long as the number parsing is consistent between all SVG attributes.

If we allow a difference then I'd vote for the relaxed syntax.

[fsoder]

Blink seems to use SkParse::FindScalars ...

No, it uses the CSS parser, a separate ParseNumber and a separate ParseNumber for the cases listed. (SkParse::FindScalars is some disabled functionality in Skia.) I'd suspect that the CSS parser fast path has a bug... (try for instance adding a space at the end of the attribute.)

That parenthesis aside though, I think Blink would be more interested in siding with Gecko here. (Hoping that the fastpath can be fixed.)

AFAICT, WebKit consciously changed to the stricter rules in https://trac.webkit.org/changeset/26540/webkit (and it's not unlikely that the remaining leniency shares the same underlying cause with Blink.)

[dirkschulze]

@fsoder Looking at the bug report https://bugs.webkit.org/show_bug.cgi?id=15468 the goal was not to align with CSS number parsing but to fix existing bugs in number parsing. It probably was an accidental mistake to not follow the spec.

[longsonr]

given that Firefox is consistent with CSS it's unlikely to change.

[dirkschulze]

@fsoder Here the code from Blink which is still identical to the code in WebKit: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/svg_parser_utilities.cc?sq=package:chromium&l=90

So Blink definitely does not use CSS parsers for the transform attribute and as far as I can see path data isn't either.

Blink also supports 1.e2 which is not supported on <number> in SVG nor <number> in CSS (but is on SVG transforms and path data in the spec). You are right that both, Blink and WebKit, have a compatibility/quicks mode for CSS parsing. I am fine if this gets specified and addresses the current behavior which is the relaxed syntax on transforms and path data as it seems to be used for pure length/number based attributes.

I checked adding a space after 10. and it indeed fails parsing in WebKit and Blink. Given that 1.e2 works, this seems to be a bug though.

Adobe Illustrator is not going to be more restrictive on parsing numbers in any of the number-taking attributes. There is a huge number of SVG files that get produced for print or set top boxes and never gets opened in a browser and authoring tools have to take those into account too.

[fsoder]

Yes, that's exactly what I wrote in my previous comment:

...the CSS parser, a separate ParseNumber and a separate ParseNumber for the cases listed.

That 1.e2 (and 10.) is just a bug plain and simple - illustrated for non-SVG at [1] - and has nothing to do with "SVG attribute mode" (which I guess you're thinking of) in the WebKit/Blink CSS parser(s). Also, adding a trailing space after 1.e2 will make that fail as well, indicating it's the same issue there. Not that that is what's interesting here though.

[1] https://jsfiddle.net/10aumthz/

[dirkschulze]

@fsoder The fast path code you mention does detect that the value might be valid but (in the trailing wsp case) not all characters get parsed. The following actual parsing fails because of the the unparsed characters after tokenization process. W/o trailing whitespaces, even the actual parsing process passes. So there is a bug for sure. The bug can still get interpreted in two ways since the intention is not documented.

That said, the table above is still valid with bugs in WebKit and Blink, intentional or not. There are still at least 2 implementations that intentionally parse 1.e1 or 1. as valid values in all three cases.

At least transforms and path data, as currently speced, require those numbers to be parsed as valid and there are at least 2 implementations that intentionally support this.

Adobe Illustrator won't change the behavior to the more strict parsing behavior because of potential non-web content created for printing and set-top boxes in all 3 cases but definitely not for transforms and path data. (There is no reason to change since the same numbers that are valid in Firefox are parsed to the same numbers with the relaxed syntax.) Authoring tools simply have a different audience than browsers and need to be more conservative on adding restrictions. Removing restrictions (most of the time) is easier.

If Firefox is not willing to adapt the relaxed syntax, then:

• We need to differ between a strict (CSS value mode) and quirks mode. All implementations supporting the quirks mode must parse strings that are valid in strict mode to the same values as the strict mode would but are able to parse additional content.
• Firefox accepts that it won't be fully compatible to the spec text in some minor edge cases.

IMO both solutions aren't ideal. The only other way, from the comment from @longsonr, is to support 1.e1 and 1. for CSS numbers as well. That would certainly be a decision of the CSS WG and not the SVG WG. (Note that I do not want to mix the discussion about numbers with making SVG path data parsable with CSS Syntax. As noted above, this might not be possible anyway.) CC @tabatkins

[fuchsia]

However, I am not sure how compatible CSS numbers can get to SVG numbers and IMO it is fine to have a difference between the two number types as long as the number parsing is consistent between all SVG attributes.

SVG 2 is spec'd to use the CSS parser pretty much everywhere. (See section 8.9) And the transform property is set to use the CSS-transforms 1. (See section 8.5)

[css-meeting-bot]

The Working Group just discussed floating point differences of numbers between CSS and SVG.

resolution: Use CSS numbers, allow UAs to implement SVG 1.1 numbers but strongly discourage to use them

The full IRC log of that discussion

<krit> topic: floating point differences of numbers between CSS and SVG
<liam> github issue: https://github.com/w3c/svgwg/issues/331
<krit> https://github.com/w3c/svgwg/issues/331#issuecomment-388108799
<krit> liam: noticed in a bug in arc and there was no definition when to floating point numbers are the same.
<krit> AmeliaBR: I'd not base number equality on the number format but on the mathematical value.
<krit> krit: question: do we want to align numbers for all uses in all attributes.
<krit> AmeliaBR: general we should align
<krit> AmeliaBR: trailing dot is not adding anything
<krit> AmeliaBR: trailing dot is commonly used in programming though not a reason to have it in CSS/SVG.
<krit> s/AmeliaBR/krit/
<krit> chris: Probably not a real world problem.
<krit> krit: do we need to align specs and implementation? What about UAs that continue to want to support them?
<krit> krit: FF already clearly stated that CSS and SVG number must use the same format for their implementation. So either CSS supports SVG numbers as well or they won't implement.
<krit> chris: Use CSS numbers, allow UAs to implement SVG 1.1 numbers but strongly discourage to use them
<krit> liam: hard to test... but in this case maybe the best.
<krit> resolution: Use CSS numbers, allow UAs to implement SVG 1.1 numbers but strongly discourage to use them
<krit> AmeliaBR: who is doing it?
<krit> krit: I'll take the action but it might take some time.
<krit> resolution: Same applies to SVG transform attributes in CSS Tansform

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

[css-meeting-bot]

The Working Group just discussed Number format discordance.

The full IRC log of that discussion

<AmeliaBR> Topic: Number format discordance
<AmeliaBR> GitHub: https://github.com/w3c/svgwg/issues/331
<AmeliaBR> Dirk: One of the open issues that I think we still need to decide on is the number format one. Although I don't see that on the list.