RE: Draft Node: Fill in the Blank

I sure you are right but that doesn't seem like an argument for not
handling it in the representation. It is up to the author to worry about
keeping answers secure. 

 

Let me also restate my objection to using class names for stuff like
this. It doesn't sound legitimate to me.

 

Paul

 

From: neil.soiffer@gmail.com [mailto:neil.soiffer@gmail.com] On Behalf
Of Neil Soiffer
Sent: Monday, July 09, 2012 12:11 PM
To: Paul Libbrecht
Cc: Paul Topping; www-math@w3.org
Subject: Re: Draft Node: Fill in the Blank

 

 

	> 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



I think a significant number of sites that use MathML for evaluation
would not consider sending the answers along with the problem as a
reasonable solution.  There are many ways to hide the answer from being
viewed in the user's browser (CSS, or XML-annotation are two people
mentioned already), but users can view the source and copy/paste the
MathML into one of many editors to see the answer.  So those solutions
are easily defeated and probably not acceptable.

If you do want to do that, there is no reason you can't wrap the
proposed solution (class="MathML-Blank") inside of a semantics element
and use annotation-xml for anwsers as you proposed for the answers.  I'm
not recommending that for the reasons above.

    Neil