Opened 11 years ago
Last modified 11 years ago
#11641 new defect
html5 support for "export" links in trac wiki
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | undecided | 
| Component: | wiki system | Version: | 1.0.1 | 
| Severity: | normal | Keywords: | html5 export wiki mimeview | 
| Cc: | Ryan J Ollos | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
I am attempting to link from my wiki to web documentation within the source (git) repository. This works as expected if the documents are xhtml, but not if the file is html5.
For example, adding the following code to the wiki [export:path/to/index.html] creates a link to that file within the git repository which is displayed as expected when the html file has the following header:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head>
However, an error occurs when the html document has a html5 header:
<!DOCTYPE html> <html lang="en"> <head>
The error message (within the browser) is browser dependant, however, the error message printed in firefox:
"XML Parsing Error: mismatched tag. Expected: </link>...."
suggests that trac may be attempting the parse the html5 document as xml?
Note that it is necessary to set [browser] render_unsafe_content = yes in order to enable rendering of html documents in this way.
Attachments (0)
Change History (3)
comment:2 by , 11 years ago
| Keywords: | mimeview added | 
|---|
Replying to rjollos:
- Should
 KNOWN_MIME_TYPESoverrideget_extra_mimetypesrather than the other way around?
Depends if we see KNOWN_MIME_TYPES as the basic set of built in defaults (that plugins can extend and override), or the set of strictly hardcoded entries (that plugins can extend but not override).
Unless there are good reasons to "lock" them all, I would prefer defaults that can be overridden by plugins. As special tweaks can hopefully easily be done using [mimeviewer] mime_map. I was a bit surprised that this setting is not empty by default. (It contains the same three examples(?) since it was introduced in [3345].)
comment:3 by , 11 years ago
| Milestone: | → undecided | 
|---|



  
When Pygments is installed, the
htmlextension is mapped to the mimetypeapplication/xhtml+xml. You can override this by appendingtext/html:htmlto[mimeviewer]mime_map. This will change howhtmlfiles are rendered throughout your Trac instance.If you were using SVN you could set the
svn:mimetypeto achieve the same result on a per-file basis, but as far as I know Git does not provide this feature.You can see the list of mimetype mappings on the TracSyntaxColoring#SyntaxColoringSupport page, or using the
[[KnownMimeTypes]]macro anywhere wiki text is allowed.I'm not sure if the default behavior for documents with the
htmlextension should be different than what it is now when Pygments is installed, but I've observed the following:KNOWN_MIME_TYPESdictionary sets the mimetype forhtmlto betext/html: tags/trac-1.0.1/trac/mimeview/api.py@:308#L287, therefore the mimetype forhtmlistext/htmlif Pygments is not installed orPygmentsRendereris disabled.mime_mapis being constructed, the following events occur:mime_map['html'] = 'text/htmlfrom initial assignment ofKNOWN_MIME_TYPES.mime_map['html'] = 'text/htmlfrom assignment of first entry returned bypygments.lexers.get_all_lexers.mime_map['html'] = 'application/xhtml+xmlfrom assignment of second entry returned bypygments.lexers.get_all_lexers. This is the mimetype that is used unless overwritten by an entry from[mimeviewer]mime_map: tags/trac-1.0.1/trac/mimeview/api.py@:893-910#L892.I have a few thoughts:
KNOWN_MIME_TYPESoverrideget_extra_mimetypesrather than the other way around?get_all_lexersarbitrary, and should we be giving precedence to the entry with the higher index in the tuple, as we are now?