[Webkit-unassigned] [Bug 120058] Add an MathMLSelectElement class to implement <maction> and <semantics>

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=120058





--- Comment #12 from Frédéric Wang <fred.wang at free.fr>  2013-09-17 02:41:12 PST ---
(In reply to comment #11)
> > Source/WebCore/mathml/MathMLSelectElement.cpp:86
> > +        if (actiontype != "tooltip" && actiontype != "statusline") {
> 
> Is this intentionally case sensitive? I’d like to see test coverage for this; many attribute values are non-case-sensitive.

> There need to be more test cases. I don’t see any test cases that cover a selection attribute that has, say, leading whitespace or any of the many other cases. It’s possible this function should be skipping whitespace or using toStrictInt rather than toInt but it’s test cases that would make that clear. I also don’t see any test cases that demonstrate that a value for selection larger than the number of children means that the last child is selected, even though that's what the code does.

The list of possible values for actiontype is open-ended, so this is not constrained by the RelaxNG schema. However, most MathML attributes are case insensitive (except color names, for compatibility with HTML) so I think that's what we want here.

The selection attribute is defined to be xsd:positiveInteger

http://www.w3.org/TR/xmlschema-2/#positiveInteger

so strictly speaking I'm accepting invalid values, here. However, the MathML spec says that:

"For most numerical attributes, only those in a subset of the expressible values are sensible; values outside this subset are not errors, unless otherwise specified, but rather are rounded up or down (at the discretion of the renderer) to the closest value within the allowed subset. The set of allowed values may depend on the renderer, and is not specified by MathML."

so I've tried to make <= 0 values fallback to 1, > Nchildren fallback to Nchildren and non-integer values being rounded (I think that's what toInt does).

Regarding whitespaces, the spec does not prohibit them clearly (although the RelaxNG schema probably does):

"Since some applications are inconsistent about normalization of whitespace, for maximum interoperability it is advisable to use only a single whitespace character for separating parts of a value. Moreover, leading and trailing whitespace in attribute values should be avoided."

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.