W3C home > Mailing lists > Public > www-math@w3.org > May 2012

Re: unitless lengths in mpadded attributes

From: Bruce Miller <bruce.miller@nist.gov>
Date: Wed, 23 May 2012 13:28:23 -0400
Message-id: <4FBD1E37.1070401@nist.gov>
To: Frédéric WANG <fred.wang@free.fr>
Cc: "www-math@w3.org" <www-math@w3.org>
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;

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:44 UTC