Re: [O] [bug] org-inlinetask produces invalid xhtml

[Nicolas Goaziou]

Hello,

Jambunathan K <address@hidden> writes:

> The problem persists. You can put the exported html file in nxml-mode
> and do a C-c C-n to find the validation errors.

The problem is different now.

> I am attaching the two examples and the problematic html segment (marked
> with VALIDATION ERROR) here. Note that one of the examples has a list in
> the inline task.
>
>
>
> #+begin_src nxml
> <pre class="inlinetask"><b>Detector effects</b><br />
> <ol> <!-- VALIDATION ERROR HERE: Element not allowed in this context -->
>   <li>How is the Gaussian used for smearing of proper time resolution
>   derived? <a href="http://www.google.com";>Google</a> this.
>   </li>
>   <li>Why is the proper time error PDF needed? Why is
>   smearing of time resolution not enough?
>   </li>
> </ol>
> #+end_src
>
> #+begin_src nxml
> <div id="outline-container-1" class="outline-2">
>   <h2 id="sec-1"><span class="section-number-2">1</span> B oscillations </h2>
>   <div class="outline-text-2" id="text-1">
>
>     <p>This is Suvayu's example but simplified. Also see the annotation
>     within the inline task itself.
>     </p>
>     <p>
>       <span style="text-decoration:underline;">Questions</span>:
>     </p>
>
>
>     <pre class="inlinetask"><b>Detector effects</b><br />
>     <p> <!-- VALIDATION ERROR: Element not allowed in this context -->
>       Suvayu's example uses lists within inline task. Can the html export
>       engine produce valid html when the inline task has lists. But honestly
>       why does a preformatted text looks like a well-formatted html
>       list. Isn't that strange. Just uncomment the below list and see for
>       yourself.
>     </pre> <!-- VALIDATION ERROR: Missing end-tag "p" -->
>
>   </p></div> <!-- VALIDATION ERROR: Mismatched end-tag -->
> </div>
> #+end_src

I see. Contents of inline tasks are meant to be interpreted during
export. Thus, paragraphs will be marked as <p>, lists as <ul> or
whatever...

This isn't compatible with the default <pre> tag provided. I can see two
possibilities. Come up with a better default value, or provide a way to
tell to template that contents will be verbatim (or both).

I prefer the first solution, but I can't think of something simple, yet
elegant enough, for that value. Do you have any suggestion?

Regards,

-- 
Nicolas Goaziou