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

Re: Draft Node: Fill in the Blank

From: Neil Soiffer <NeilS@dessci.com>
Date: Mon, 9 Jul 2012 11:59:55 -0700
Message-ID: <CAESRWkCaR=7a4bZANvXKctBCfnjQ9ru-a54vtHbksjajewm1-g@mail.gmail.com>
To: Paul Libbrecht <paul@hoplahup.net>
Cc: Paul Topping <pault@dessci.com>, www-math@w3.org
I'd like to remind everyone that the goal here is to provide a means to
represent blanks visually and aurally.  Once someone fills in the blank
with an answer, it is no longer a blank and the class attribute along with
the contents of the element should be changed.  The original scope of this
document does not include indicating what is a (user-supplied) answer, but
of course, it can be expanded it there is a compelling reason to do so.
One obvious way to do that is simply to use class="MathML-Answer" on the
changed element.

Using class allows one to uniformly style blanks using CSS (in an HTML
world).  With the lastest and greatess CSS, that includes audio styling
also.

    Neil


On Fri, Jul 6, 2012 at 2:37 PM, Paul Libbrecht <paul@hoplahup.net> wrote:

>
> Le 6 juil. 2012 à 18:15, Paul Topping a écrit :
> > I was thinking more along the lines of allowing separate markup for each
> purpose:
> > - Content that determines the size of the input area (ie, phantom
> content).
>
> Nice wording.
>
> > - Content to be rendered but is not intended to be part of the
> expression's overall meaning (ie, a prompt).
>
> yes
>
> > - Content representing the "answer" that is intended to be part of the
> expression's overall meaning.
>
> and that would be edited, right?
>
> > Perhaps we'd want to be able to use a single content expression for more
> than one of these purposes as an optimization. There might be
> recommendations to the user to implement JavaScript that hides or removes
> the prompt when the answer is non-empty.
>
> To the implementor, right?
>
> > What did you mean by "in-browser comparison"?
>
> If we allow several expressions associated to a blank then it also makes
> sense to allow one that allows the recipient user-agent (e.g. a web-page
> with some javascript) to compare the user-input with the one (given some
> flexibility).
>
> My concern now is whether it is good to allow multiple children. From this
> discussion it sounds unavoidable. And if we do so, how do we markup so that
> renderers that are unaware of this note still render something partially
> useful?
>
> Paul
Received on Monday, 9 July 2012 19:00:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 July 2012 19:00:27 GMT