Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1956 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

CSS tag displayed verbatim on page when using tabber widget and kid.outputformat="xhtml-strict default" set

Reported by: martin.vejmelka Owned by: anonymous
Priority: low Milestone: 1.1
Component: TG Widgets Version:
Severity: normal Keywords:


<style type="text/css">.tabber{display:none;}</style> is displayed as first thing in the page. When using kid.outputformat="html default", that's ok. When kid.outuputformat is xhtml or xhtml-strict the thing happens.

I've also tried to create new working environment (tg-admin quickstart) with only tabber component used and xhtml-strict set.

Even when the error occurs (the strange string is displayed), the tabber component works fine. For me the only solution was to use html output instead of xhtml.

I have tried it on:

  • Linux Fedora 9 and Firefox 3
  • Linux Fedora 9 and Opera 9.50
  • Windows and MSIE 6
  • Windows and Firefox

The server was on Fedora 9


example.tar.gz Download (89.5 KB) - added by martin.vejmelka 11 years ago.
minimal project demonstrating problem

Change History

comment:1 Changed 11 years ago by Chris Arndt

Can you please provide a full code example (controller, widgets and templates and configuration) that exhibits the problem? The best would probably to upload a Tarball with a minimal(!) project.

comment:2 Changed 11 years ago by Chris Arndt

  • Summary changed from <style type="text/css">.tabber{display:none;}</style> displayed in document when kid.outputformat="xhtml-strict default" set to CSS tag displayed verbatim on page when using tabber widget and kid.outputformat="xhtml-strict default" set

comment:3 Changed 11 years ago by martin.vejmelka

I've just created new project: tg-admin quickstart (every question was answered simply by pressing enter key).

Edited files:

  • example/example/config/app.cfg (added kid.outputformat="xhtml-strict default")
  • example/example/controllers.py (tabber initialization)
  • example/example/templates/welcome.kid (sample tabber at bottom page)

Details in enclosed tar.gz file...

Changed 11 years ago by martin.vejmelka

minimal project demonstrating problem

comment:4 Changed 11 years ago by Chris Arndt

I looked into this today and the problem seems that with kid.outputformat = 'xhtml' HTML-special chars (<>&) in the JavaScript code displayed in JSSource widgets gets escaped, whereas with kid.outputformat = 'html' it does not get escaped.

The Tabber widget uses a JSSource widget to inject a JS snippet that puts a STYLE tag via document.write(...) into the page which hides the tabber div until the JavaScript that formats the tabs is loaded. It can't simple use a CSSSource widget to insert the CSS snippet, because then the tabber div would be hidden completely for browser with JS switched off but CSS support on. When the JS code gets escaped by kid, the STYLE is correct anymore.

I see only a partly solution to the general problem:

Use $[XML(src)} instead of plain $src in the template of the JSSource (and CSSSource) widget, but this may lead to XHTML documents that are not valid. I also tried to wrap the JS code in <![CDATA[ ]]>, but Kid annoyingly strips this, probably assuming that the tag contents will be properly escaped anyway.

Or a workaround:

Just set hide_on_load=False when creating the Tabbert widget.

Questions left:

  • How does ToscaWidget handle this? Looking at the source-code, the TW JS/CSSSource widget have the same simple template.
  • Does the same problem occur when Genshi is used as the widget template language (TW only)?


comment:5 Changed 11 years ago by Chris Arndt

  • Milestone set to 1.1

comment:6 Changed 11 years ago by chrisz

Whether the CDATA should appear or not was actually a long discussion on the Kid trac (see  here). To sum up, it is completely correct for Kid to leave it away in XHTML documents if the contents are XML-encoded which they are. The problem here is a completely different one, namely that XHTML documents were delivered by TG with a content type of "text/html", so they were interpreted as HTML, not XHTML, no matter what the doctype says. I fixed that in r5323 and this seems to solve the problem for me. Can you check again with this fix?

comment:7 Changed 11 years ago by Chris Arndt

  • Status changed from new to closed
  • Resolution set to fixed

Yes, this seems to fix the problem. There is still a problem with XHTML output since the output still has a meta tag that specified the content type as text/html but this doesn't affect this ticket so it will be handled in ticket #1963.

Note: See TracTickets for help on using tickets.