W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Lack Of Definition Of A Valid Ratio (part of detailed review of common microsyntaxes)

From: Smylers <Smylers@stripey.com>
Date: Sun, 15 Jul 2007 18:16:48 +0100
To: HTML Working Group <public-html@w3.org>
Message-ID: <20070715171648.GH5621@stripey.com>

Robert Burns writes:

> I'm still learning how the <meter> and <progress> elements interact
> with these number algorithms. Its not clear to me whether improper
> fractions are re-arranged by the elements.

Don't think of them as fractions; the slash isn't taken into account at
all by the algorithms.  The content is simply two numbers, with authors
free to add in any other text that they want.  <meter> currently has
this example:

  <meter>max: 100; current: 75</meter>

Note that that's treated the same as all of these:

  <meter>current: 75; max: 100</meter>

  <meter>75 100</meter>
  
  <meter>100 75</meter>

  <meter>75/100</meter>

and therefore it happens also that this is also treated the same:

  <meter>100/75</meter>

-- but it would be really obfuscatory for an author to choose to format
it like that!

> However, from your original response, it occurred to me that an
> important use-case for preserving the denominator character would be
> if the <meter> or <progress> have the max value set themselves.

Actually that doesn't make any difference: the max attribute always
takes precedence over any content, regardless of how many numbers or
denominators are found in the content.

> Though passing 110 and % should just treated consistently with
> whatever is decided for improper fractions. In other words if improper
> fractions are rearranged then, perhaps, so too should 110%.

What's the advantage in purposefully misinterpreting 110%, when it's
clear that the author meant to use percentages?  The algorithm doesn't
go out of its way to rearrange top-heavy fractions; it's just an effect
of the flexibility of parsing two numbers from a string and ignoring the
rest of the content.

Smylers
Received on Sunday, 15 July 2007 17:17:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:47 UTC