Modify

Opened 6 years ago

Closed 4 years ago

#3918 closed enhancement (wontfix)

WikiTicketCalendarMacro should close surrounding paragraph tags to produce valid XHTML

Reported by: martin@… Owned by: rjollos
Priority: normal Component: WikiTicketCalendarMacro
Severity: normal Keywords: valid HTML
Cc: hasienda Trac Release: 0.10

Description

Because the trac wiki formatter puts the output of macros in paragraph tags all block output of macros isn't valid XHTML. One fix of this is to let the macro close and reopen the surrounding paragrah, see Trac #5467.

  • WikiTicketCalendarMacro.py

    old new  
    141141
    142142        # building the output
    143143        buff = StringIO()
     144        buff.write('</p>') # close surrounding paragraph
    144145        buff.write('''\
    145146<style type="text/css">
    146147<!--
     
    300301            buff.write('</tr>\n')
    301302   
    302303        buff.write('</tbody>\n</table>')
     304        buff.write('<p>') # re-open surrounding paragraph
    303305               
    304306        table = buff.getvalue()
    305307        buff.close()

Attachments (0)

Change History (7)

comment:1 Changed 5 years ago by rjollos

  • Owner changed from mcomb to rjollos
  • Summary changed from WikiTicketCalendarMacro should close surrounding paragraph tags to produce valid XHTML to [Patch] WikiTicketCalendarMacro should close surrounding paragraph tags to produce valid XHTML

Reassigning ticket after changing maintainers.

comment:2 Changed 5 years ago by hasienda

  • Keywords 0.11 added

Since this was fixed in Trac trunk according to aforementioned Trac ticket, this is only relevant to get fixed for 0.11 branch AFAIK.

comment:3 Changed 5 years ago by martin_s

IMHO they didn't fixed it, but just added a workaround. They surrounding paragraph is only closed when the code returned by the macro starts with a div or table tag, which isn't always the case. The details can be found in the mentioned Trac ticket.

But you are right, the ticket is targeting (now) the 0.11 branch. A 0.12 branch should make sure that there is a div tag around the returned code. Best practise would be to add a specific class attribute to it as well.

comment:4 Changed 4 years ago by hasienda

  • Cc hasienda added; anonymous removed

Thanks for the confirmation on the subject.

The dedicated div was introduced along with other changes in trunk with changeset [8163] and will get into the next 0.12 release as well.

comment:5 Changed 4 years ago by hasienda

I run the W3C validator against a wiki test page from my 0.12 development system: 177(!) errors

The doctype setting is 'XHTML 1.0 Strict', but only after forcing to eval as 'HTML 4.01 Transitional' I get 7 errors related to an issue remaining with WikiTicketCalendarMacro's code by now.

I'm with you in that we souldn't introduce invalid (X)HTML with the plugin, but from now the whole issue is a moot point as long as Trac/Genshi doesn't generate a valid page.

comment:6 Changed 4 years ago by hasienda

After adding a dedicated div around the whole macro output I see two obsolete pairs of '<p></p>' before and after that div now. While I know, that this is produced by the simple workaround from changeset:3008 3008 I would have expected, that such nonsense is stripped by Genshi or other means.

comment:7 Changed 4 years ago by hasienda

  • Keywords valid HTML added; 0.11 removed
  • Resolution set to wontfix
  • Status changed from new to closed
  • Summary changed from [Patch] WikiTicketCalendarMacro should close surrounding paragraph tags to produce valid XHTML to WikiTicketCalendarMacro should close surrounding paragraph tags to produce valid XHTML

After [8263] the supposed patch doesn't apply anymore.

Due to HTML generation by Genshi this should be enough to ensure valid (X)HTML now, at least as far as Genshi will do it right.

If you still have issues I suggest improving Genshi and posting your complaint/recommendation over there, preferably with a patch.

Add Comment

Modify Ticket

Action
as closed The owner will remain rjollos.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.