[filter-effects] drop-shadow can accept color before lengths

[ewilligers]

The current spec suggests the color must appear last.
https://drafts.fxtf.org/filter-effects/#funcdef-filter-drop-shadow
drop-shadow() = drop-shadow( <length>{2,3} <color>? )

However, Blink, WebKit and Firefox also accept the color first.

Regardless of the author-supplied order, Blink and WebKit serialize with the color first, and Firefox serializes with the color last.

"drop-shadow(rgb(4, 5, 6) 1px 2px)" becomes "drop-shadow(1px 2px rgb(4, 5, 6))" in Firefox.
"drop-shadow(1px 2px rgb(4, 5, 6))" becomes "drop-shadow(rgb(4, 5, 6) 1px 2px)" in Blink and WebKit.

Only Edge strictly follows the spec here, in requiring color to be last.

We could change the grammar to
drop-shadow() = drop-shadow( [ <length>{2,3} && <color>? ] )

Test PR that should be updated if this proposal is accepted:
web-platform-tests/wpt#7890

[tabatkins]

This should ideally match, in both parsing and serialization, the box-shadow property (modulo the functionality differences).

This means parsing should accept color on either side.

Serialization is trickier - per spec, color should come last, but it looks like in both Chrome and Firefox, color gets serialized first for box-shadow. The spec should presumably be changed to reflect that ordering?

[dirkschulze]

@tabatkins Background and borders does not specify a different serialisation order where color comes first for box-shadow or do I miss something?

@ewilligers I changed the syntax and length and colour values order can be changed now.

That said, the the spec should probably specify the computed value for each filter function individually. A different issue though.

[dirkschulze]

We should open separate issues for computed values and serialisation. IMO this issue is closed.