RE: Draft Node: Fill in the Blank

Comments below.

> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@hoplahup.net]
> Sent: Friday, July 06, 2012 2:38 PM
> To: Paul Topping
> Cc: Neil Soiffer; www-math@w3.org
> Subject: Re: Draft Node: Fill in the Blank
> 
> 
> 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?

Yes.

> > 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?

Yes.

> > 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).

So this would be the "correct answer" typically, right? I imagine that some won't want to use that as it would be open to cheating by anyone that can View Source on the page. Still, that's probably not a reason to omit it.

> 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?

Can we not tell page authors to use CSS in the page source HTML to hide those parts that should not be visible?

Received on Saturday, 7 July 2012 19:35:04 UTC