Opened 11 years ago
Last modified 10 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 , 10 years ago
Keywords: | mimeview added |
---|
Replying to rjollos:
- Should
KNOWN_MIME_TYPES
overrideget_extra_mimetypes
rather 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 , 10 years ago
Milestone: | → undecided |
---|
When Pygments is installed, the
html
extension is mapped to the mimetypeapplication/xhtml+xml
. You can override this by appendingtext/html:html
to[mimeviewer]
mime_map
. This will change howhtml
files are rendered throughout your Trac instance.If you were using SVN you could set the
svn:mimetype
to 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
html
extension should be different than what it is now when Pygments is installed, but I've observed the following:KNOWN_MIME_TYPES
dictionary sets the mimetype forhtml
to betext/html
: tags/trac-1.0.1/trac/mimeview/api.py@:308#L287, therefore the mimetype forhtml
istext/html
if Pygments is not installed orPygmentsRenderer
is disabled.mime_map
is being constructed, the following events occur:mime_map['html'] = 'text/html
from initial assignment ofKNOWN_MIME_TYPES
.mime_map['html'] = 'text/html
from assignment of first entry returned bypygments.lexers.get_all_lexers
.mime_map['html'] = 'application/xhtml+xml
from 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_TYPES
overrideget_extra_mimetypes
rather than the other way around?get_all_lexers
arbitrary, and should we be giving precedence to the entry with the higher index in the tuple, as we are now?