Bug 127720 – CSS 2.2: Support scientific notations for all numbers in CSS

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Dirk Schulze]

CSS 2.2 will support scientific notations for all number values. We support scientific numbers for SVG in the CSSParser. We should do for all values now:

See line 11711 in CSSParser.cpp:

#if ENABLE(SVG)
        // Use SVG parser for numbers on SVG presentation attributes.
        if (m_context.mode == SVGAttributeMode) {
            // We need to take care of units like 'em' or 'ex'.
            SrcCharacterType* character = currentCharacter<SrcCharacterType>();
            if (isASCIIAlphaCaselessEqual(*character, 'e')) {
                ASSERT(character - tokenStart<SrcCharacterType>() > 0);
                ++character;
                if (*character == '-' || *character == '+' || isASCIIDigit(*character)) {
                    ++character;
                    while (isASCIIDigit(*character))
                        ++character;
                    // Use FLOATTOKEN if the string contains exponents.
                    dotSeen = true;
                    currentCharacter<SrcCharacterType>() = character;
                }
            }
            if (!parseSVGNumber(tokenStart<SrcCharacterType>(), character - tokenStart<SrcCharacterType>(), yylval->number))
                break;
        } else
#endif
            yylval->number = charactersToDouble(tokenStart<SrcCharacterType>(), currentCharacter<SrcCharacterType>() - tokenStart<SrcCharacterType>());

[Simon Fraser (smfr)]

http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html#s.4.1.1d

[Dirk Schulze]

(In reply to comment #0)
> CSS 2.2 will support scientific notations for all number values. We support scientific numbers for SVG in the CSSParser. We should do for all values now:
> 
> See line 11711 in CSSParser.cpp:
> 
> #if ENABLE(SVG)
>         // Use SVG parser for numbers on SVG presentation attributes.
>         if (m_context.mode == SVGAttributeMode) {
>             // We need to take care of units like 'em' or 'ex'.
>             SrcCharacterType* character = currentCharacter<SrcCharacterType>();
>             if (isASCIIAlphaCaselessEqual(*character, 'e')) {
>                 ASSERT(character - tokenStart<SrcCharacterType>() > 0);
>                 ++character;
>                 if (*character == '-' || *character == '+' || isASCIIDigit(*character)) {
>                     ++character;
>                     while (isASCIIDigit(*character))
>                         ++character;
>                     // Use FLOATTOKEN if the string contains exponents.
>                     dotSeen = true;
>                     currentCharacter<SrcCharacterType>() = character;
>                 }
>             }
>             if (!parseSVGNumber(tokenStart<SrcCharacterType>(), character - tokenStart<SrcCharacterType>(), yylval->number))
>                 break;
>         } else
> #endif
>             yylval->number = charactersToDouble(tokenStart<SrcCharacterType>(), currentCharacter<SrcCharacterType>() - tokenStart<SrcCharacterType>());

It is of course easy to remove the if (m_context.mode == SVGAttributeMode) check, but I don't know how it impacts performance. This might need to be checked. In SVG (where we use this code all of the time) the code never stood out on performance measurements though.

[Dirk Schulze]

Created attachment 227348 [details]
Patch

[Build Bot]

Comment on attachment 227348 [details]
Patch

Attachment 227348 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/4916819403997184

New failing tests:
media/controls-strict.html
media/audio-controls-rendering.html
fast/filter-image/parse-filter-image.html
media/controls-without-preload.html
fast/css/round-trip-values.html
css3/filters/filter-property-computed-style.html
css3/filters/filter-property-parsing.html
fast/css/large-value-csstext.html

[Build Bot]

Created attachment 227362 [details]
Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-13  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 227348 [details]
Patch

Attachment 227348 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/4507389566910464

New failing tests:
media/controls-strict.html
media/audio-controls-rendering.html
fast/filter-image/parse-filter-image.html
media/controls-without-preload.html
fast/css/round-trip-values.html
http/tests/media/track/track-webvtt-slow-loading.html
css3/filters/filter-property-computed-style.html
media/controls-after-reload.html
css3/filters/filter-property-parsing.html
fast/css/large-value-csstext.html

[Build Bot]

Created attachment 227368 [details]
Archive of layout-test-results from webkit-ews-04 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-04  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Daniel Bates]

Comment on attachment 227348 [details]
Patch

r- given that this patch caused some changes to how CSS floating point numbers are parsed given that we always use parseSVGNumber() regardless of the mode we are in.

[Myles C. Maxfield]

(In reply to comment #8)
> Comment on attachment 227348 [details]
> Patch
> 
> r- given that this patch caused some changes to how CSS floating point
> numbers are parsed given that we always use parseSVGNumber() regardless of
> the mode we are in.

I don't understand this rationale. The spec has changed (and both Firefox and Chrome have updated to match it) to specify that CSS floating point numbers ::should:: parsed regardless of the mode we are in.

[Myles C. Maxfield]

Created attachment 278652 [details]
WIP

[Myles C. Maxfield]

Created attachment 278653 [details]
Reduction

[Myles C. Maxfield]

*** Bug 154506 has been marked as a duplicate of this bug. ***

[Myles C. Maxfield]

<rdar://problem/25511333>

[Michael Herzog]

Is somebody working on this bug? I always need an annoying workaround for Safari when developing 3D web applications with three.js (see https://github.com/mrdoob/three.js/issues/7802) or with plain CSS 3D transforms (using matrix3d).

Indeed, a fix would be nice!

[Simon Fraser (smfr)]

This will be fixed in the new CSS parser (bug 161916 and others).

[Michael Herzog]

The reduction test still fails with r205937.

[Simon Fraser (smfr)]

I didn't mean that commit would fix it, only that it will get fixed eventually when the new CSS parser is enabled.

[Michael Herzog]

Oh, i see ;)

So...when gets the new CSS parser enabled? Is there something like a schedule or a target release for this feature? I'd like to verify the implementation with the given reduction test as soon as it's available in webkit nightly.

[Dean Jackson]

Maybe in a month or so. Not within the next few weeks. There are a lot of little pieces to get going.

[Michael Herzog]

Sry for asking this but when can we expect a status update for this issue?

[Dean Jackson]

This is now fixed. However, it's just waiting on the new CSS parser to be enabled by default. This should happen in the coming days or week.

[Michael Herzog]

Thanks for fixing this!