Re: unitless lengths in mpadded attributes

On 05/23/2012 02:38 AM, Frédéric WANG wrote:
> 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

While it may seem contradictory, we were indeed attempting
to discourage use of unit-less lengths, while allowing them
in more places!  Unit-less-ness was the tricky part of making
lengths more consistent --- the overall goal being to
reduce, not increase, ambiguity and to give authors (& implementors)
fewer simpler rules that applied across the board, rather than
having to check the documentation for every specific attribute
to see what special cases applied.

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

The problem is that people (at least me! :> ) also expect width="20"
to not mean randomly different things: 20pixels sometimes, 20 times
a default others. Several attributes (minsize,maxsize,linethickness...)
already had the latter interpretation in MathML 2, and some people
apparently find that useful.

> 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

That would be backwardly incompatible (in general)

> unit. And in mpadded, "+0" and "-0" also mean "do not change size",
> whatever the unit or percent.

Actually, the attributes for mpadded are not, strictly,
just "length" since they have the extended format with pseudo-units.
Moreover, they already allow expressions such as width="2width",
they really don't _need_ the extension to allow unitless values.
So, I personally wouldn't have a huge problem requiring some
sort of unit thing in the mpadded attributes.

Whatever makes the spec "better"! :>


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

For all lengths, or just for mpadded?

Thanks for your comments;
bruce

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

Received on Wednesday, 23 May 2012 17:29:50 UTC