Opened 17 years ago
Closed 16 years ago
#5647 closed defect (fixed)
Wiki page with macro is not valid XHTML.
| Reported by: | Blackhex | Owned by: | ebray |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.11.2 |
| Component: | wiki system | Version: | devel |
| Severity: | minor | Keywords: | |
| Cc: | blackhex@… | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
Trac: trunk (r5790)
This should be probably reported as separated bugs but they are connected and very minor.
In attached file check.html is result of XHTML validation of file page.html. First error is probably cause by missing DTD inclusion. Second is caused becase [[ViewTopic]] macro returns block content and wiki formater formats returned content of IWikiMacroProvider implementator inside <P> element. Is it possible to not generate that macro content inside <P> element?
And the last and most disturbing problem for me is that in Firefox or Konqueror page.html is not displayed properly. Page rendering is stopped right after <TEXTAREA/> tag. Try just open it in Firefox to see what I mean. When I change manually <TEXTAREA/> tag to <TEXTAREA><TEXTAREA/> tags problem don't occurs. Maybe it's kind of bug in Firefox and Konqueror, maybe it's bug in my code but I don't see any obvious problem. If it isn't, is it possible to change formatter to return complete tags instead of short ones as it used to be in 0.10?
Attachments (4)
Change History (16)
by , 17 years ago
comment:1 by , 16 years ago
I was just going to make a MailingList post about this very issue, but it looks like there's a ticket. Has anyone thought of a way to render a macro containing block-level elements outside the containing <p>? I'd argue there is no good way outside of some ugly hack using ITemplateStreamFilter. Perhaps the macro API could be expanded somewhat to allow specifying whether a macro will be rendered as a block-level or inline element.
comment:2 by , 16 years ago
Nevermind—I realize now that the wiki formatter *should* close <p> tags before rendering a <div> or <table>. However, there is at least one macro in Trac (namely, TicketQuery with format=table) where this is not handled correctly, since the formatter is checking for an Element object, and in this case gets a Stream.
by , 16 years ago
| Attachment: | ticket-5647-r7499.patch added |
|---|
Here's a simple patch that adds a slightly more flexible check for div or table (that isn't a code block).
comment:3 by , 16 years ago
One more validation issue with the [[TicketQuery(format=table)]] macro. The generated html starts out like this: <div xmlns="http://www.w3.org/1999/xhtml"> Odd, considering that when the same template is included in query.html, the xmlns attribute is stripped, but not when used in the macro. Is this a known bug in Genshi?
comment:4 by , 16 years ago
When macros are always put in <p> tags then the following convention could be using:
macros which return block content produce a leading closing
</p>and a trailing opening<p>.
Future implementation of the wiki formatter could then check if the returned text starts with </p> and avoid the <p>'s altogether: not printing own tags and stripping the surrounding ones of the macro.
comment:5 by , 16 years ago
| Milestone: | → 0.11.2 |
|---|---|
| Owner: | changed from to |
Ouch no, the macros should certainly not return invalid XHTML.
As ebray said, the macro API could be expanded somewhat to allow specifying whether a macro will be rendered as a block-level or inline element. In the meantime, we could cope with this issue like suggested by attachment:ticket-5647-r7499.patch.
Feedback on that patch from the original reporter would be welcomed.
comment:6 by , 16 years ago
The one problem I've found with that patch (but haven't fixed yet) is that neither _code_block_re or _block_elem_re account for the possibility of leading whitespace. This can occur if, for example, the macro's template is for whatever reason a fully formed XHTML document. For example:
<html xmlns="..." xmlns:py="..." py:strip=""> <body py:strip=""> <div> ... </div> </body> </html>
In this case the macro will be rendered with the leading whitespace before the first <div>, and thus won't be matched by either RE. Shouldn't need anything more than a \s* after the ^ in each RE though.
comment:7 by , 16 years ago
I think that _code_block_re was anyway for a very narrow case (when the <div>...</div> is in one single line), so probably only the new _block_elem_re should be smarter about that, something like:
_block_elem_re = re.compile(r'^\s*<(div|table)(?:\s+[^>]+)?>', re.MULTILINE)
comment:8 by , 16 years ago
Ah, yes. Multiline too. And perhaps even IGNORECASE (if it's properly formed that shouldn't be necessary, but it can't hurt).
comment:9 by , 16 years ago
| Summary: | Wiki page with macro is not walid XHTML. → Wiki page with macro is not valid XHTML. |
|---|
Any chance to get an updated patch?
comment:10 by , 16 years ago
Odd. I meant to submit one this morning, but apparently I just left the tab open before actually clicking 'Add attachment'. Must have gotten distracted by something.
by , 16 years ago
| Attachment: | ticket-5647-r7601.patch added |
|---|
Updated patch for latest trunk with slightly more flexible RE. Also removed a seemingly superfulous unicode() call.
comment:11 by , 16 years ago
Patch looks fine, I'll test it.
However I just read again the ticket, and regarding comment:2, I think we should do better in that case, i.e. look into the Stream.
comment:12 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Patch committed, part of [7618:7620].
Result of XHTML validation.