- From: Neil Soiffer <NeilS@dessci.com>
- Date: Mon, 9 Jul 2012 11:59:55 -0700
- To: Paul Libbrecht <paul@hoplahup.net>
- Cc: Paul Topping <pault@dessci.com>, www-math@w3.org
- Message-ID: <CAESRWkCaR=7a4bZANvXKctBCfnjQ9ru-a54vtHbksjajewm1-g@mail.gmail.com>
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 UTC