label tags rendering improperly

Patch didnt work against HEAD revision, problem was invalid line numbers, fixed, heres a new patch

Patch didnt work against HEAD revision, problem was invalid line numbers, fixed, heres a new patch

Patch was still using an old version of quiz, updated against current. ocyrus, you might be using an old version of quiz to do your patches. There have been substantial code changes since version 1.41 of multichoice.module, which your patch references.

Applied correctly, and tested correctly. I would like to raise a concern here that involves the HTML output of multichoice.module.

Here is the HTML that's being output AFTER this current patch is applied:

<div class="content">
  <div id="quiz_progress">Question <em>1</em> of <em>2</em></div>
  <br />
  <form action="/node/20" method="post" id="multichoice-render-question-form">
  <div>
    <div class="multichoice_form"><p>What is the square root of 1?</p>
      <div class="form-radios">
        <div class="form-item">
          <label class="option">
            <input type="radio" name="tries" value="1" class="form-radio" />
            <span class="multichoice_answer_text"><p>0</p></span>
          </label>
        </div>
        <div class="form-item">
          <label class="option">
            <input type="radio" name="tries" value="2" class="form-radio" />
            <span class="multichoice_answer_text"><p>1</p></span>
          </label>
        </div>
        <div class="form-item">
          <label class="option">
            <input type="radio" name="tries" value="3" class="form-radio" />
            <span class="multichoice_answer_text"><p>2</p></span>
          </label>
        </div>

Why, oh why do we have paragraphs inside of inline-classed spans inside of label tags? If we were to remove these <p> tags, it would clean up the entire structure of a quiz, and allow for even more complex theming than is currently possible.

These aren't paragraphs. They are labels. Let's not treat them as labels-with-a-paragraph-inside-it. Leaving this the way it is will result in themers creating a class for their answer-label text, and then another one for the paragraphs inside their answer-label text that refuse to pay attention to the first, and correct, CSS class.

Karl, Chip agrees with me that these p tags should go away. I did a search through all the theme functions in both the multichoice.module and the quiz.module, and I can't find what's generating this tag. I'd be more than happy to remove the offending tags, or even build a theme function for this if needed.

Did we decide on what we wanted to do about this.

I pinged kscheirer on this one. I want this <p> tag to go away, so if there are no objections from Westerson or Karl, I'd like to submit a patch that makes this happen.

no objections here.

Yeah, I was just starting to run down the check_markup() as the culprit when you posted this. I believe that the input filter which does line-break conversion is partly to blame here as well. I'll be doing some research to see if we can re-work the check_markup somehow.

Ok, it looks like we could simply use check_plain here, rather than trying to invoke an input filter. Since we're creating multichoice questions here, every question is going to be nothing but labels for radio buttons or checkboxes. I don't see any need for anyone to ever need html or more than one paragraph in a label for a multichoice question.

Can we just re-write this to use check_plain instead of leveraging the $node->body's input filtering system into this teeny tiny space?

Heres a patch that solves this issue.

Our only question is if we mind that the multichoice labels are ran against check_plain

A use case for check markup is picture questions. Right now people can use html to insert images and audio into their content. If that means that we have to live with a <p> which is generated by an input filter then so-be-it. Can we not work with the assumption that we don't know what kind of markup is contained for questions and answers?

Even if this is ugly code wise, i think this is a feature that we wish to still have.
What do you think?

I am in agreement that the

doesnt bother me at all. And that we shouldnt get rid of Drupal Functionality like this patch does. However this is done via label of a multichoice question. Can the Labels to radio boxes/checkboxes be an image?

no, but html markup such as the 'strong' tag, and links to pop up windows can still be used. i can imagine someone wanting to be able to use the strong tag or colors in their answers.

Then I think check_markup is fine with me.

Since #4 has been agreed upon, I am applying patch from #4.