Re: unitless lengths in mpadded attributes

Unitless attributes were not allowed in mpadded in MathML2:
http://www.w3.org/TR/MathML2/chapter3.html#presm.mpadded

And I understood the goal was to deprecate unitless values.
http://www.w3.org/TR/MathML3/chapter2.html#fund.units
"A number without a unit is intepreted as a multiple of the default 
value. This form is primarily for backward compatibility and should be 
avoided, prefering explicit units for clarity."

In particular unitless values can lead to ambiguities:
http://lists.w3.org/Archives/Public/www-math/2012Jan/0030.html
http://lists.w3.org/Archives/Public/www-math/2012Jan/0031.html

For "0" (and those with  no effects "+0" and "-0") it is generally clear 
what we want. But similarly to my comment about mglyph, I think people 
would expect width="20" to behave like width="20px" not like "2000%" as 
it is recommended for length values.

Maybe it would be better (for both length and mpadded values) to do as 
in CSS: only allow unitless for "0" (or at least for backward 
compatibility, allow but deprecate it for length values):

http://www.w3.org/TR/css3-values/#lengths

Indeed, a relative "0" or an absolute "0" mean the same, whatever the 
unit. And in mpadded, "+0" and "-0" also mean "do not change size", 
whatever the unit or percent.

FYI, Mozilla only implements the unitless "0" (and maybe "+0" and "-0") 
but this has recently be removed to align on the MathML3 spec.

On 22/05/2012 22:11, Bruce R Miller wrote:
> On 05/21/2012 05:54 PM, Karl Tomlinson wrote:
>> Can get clarification of these questions in the context of mpadded
>> attributes, please?
>>
>> 1. Are unitless lengths valid attribute values?
>> 2. Is "0" a special case where no unit is valid?
>>
>> In the attribute table, the description
>> '( "+" | "-" )? unsigned-number (("%" pseudo-unit?) | pseudo-unit | 
>> unit | namedspace )'
>> has no "?" following the second set of parentheses, indicating
>> that there must be something following the unsigned-number.
>
> Indeed we had intended the "?" to allow unit-less values as we do with 
> other
> length-like attributes --- a few paragraphs later in the text you
> cited describes that case --- but in the heat of sorting out reference 
> & default
> values, we left off the "?" in the regular expressions.
> (and in the schemas generated from them).
>
>> That seems reasonably clear that the answer to both my questions
>> is "no", but there are some possible hints elsewhere in the spec
>> that unitless values might be valid, so I want to check that I am
>> not missing something.
>
>> The default for both lspace and voffset is "0".
>
> Odd that we managed to mangle that as well; a unitless "0"
> shouldn't have been used as the default in either case!
> (it would be either invalid or circular!)
>
>> I guess it's quite feasible to have a default that is not a string
>> that can be specified as a valid value, but it feels a little odd.
>>
>> Would it be clearer to specify the default value as "0em", as it
>> was in MathML2?
>
> Indeed.
>
>> In the text "Each format begins with an unsigned-number, which may
>> be followed by a % sign (effectively scaling the number) and an
>> optional pseudo-unit, by a pseudo-unit alone, or by a unit
>> (excepting %)", would it be clearer to replace "which may be followed"
>> with "followed"?
>>
>> In the text "the resulting length is the product of the number
>> (possibly including the %) and the following pseudo-unit, unit,
>> namedspace or the default value for the attribute if no such unit
>> or space is given", would it be clearer to replace "if no such unit
>> or space is given" with "if % is specified with no pseudo-unit"?
>
> I think this is correct as it stands, but was intended to describe
> the case where the entire percent|unit|pseudo-unit|namedspace clause
> was optional.
>
>> http://www.w3.org/Math/draft-spec/chapter3.html#presm.mpadded
>
> The correction is now in the editors draft.
> Thanks for bringing this up, and your attention to detail!
>
> bruce
>
>
>
>


-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

Received on Wednesday, 23 May 2012 06:37:28 UTC