MantisBT 1.3.x to produce XHTML strict output

Work is well underway towards modernising the user interface of MantisBT. The first step being taken towards this goal is to ensure that MantisBT 1.3.x produces XHTML strict page output. Bug #12545 tracks progress towards removing deprecated HTML 4 (and earlier) features from MantisBT page output and replacing them with modern equivalents. For instance, the old <font>, <b>, <u>, <i>, etc elements of HTML 4 are very much deprecated. This bug report also tracks progress towards ensuring that MantisBT page outputs produce well formed XHTML (so that pages can be parsed using XML tools).

Note that the 1.3.x branch now uses the application/xhtml+xml MIME type where the browser supports rendering XML documents. The XML specifications state that if malformed XML is detected during the parsing of an XML document, a critical error should be produced and the parsing immediately terminated. This will make it much easier for errors in the output XHTML markup to be detected and fixed (both in the core and within plugins).

User interface breakages are expected in the 1.3.x branch while the user interface is being modernised. We’re trying to create semantic output from MantisBT complete with class and ID attributes to allow for precise CSS styling of page outputs. Ultimately this will allow us to remove the dedicated “print” pages from MantisBT and instead just use separate on-screen and print stylesheets. This is easier for users, easier for MantisBT developers, easier for plugin authors and less prone to errors and discrepancies.

If you would like to assist with modernising the MantisBT interface we’d very much like to hear from you. Experience with XHTML and CSS are required – as well as a good understanding of how to write semantic and meaningful markup. There is a lot of work to complete and it generally has to be performed by hand on a page-by-page basis.

This entry was posted in MantisBT. Bookmark the permalink.

16 Responses to MantisBT 1.3.x to produce XHTML strict output

  1. Marcel says:

    Just curious, but wouldn’t HTML5 be more appropriate given that work is to be discontinued on XHTML2 by the W3C in favour of HTML5?

  2. Marcel says:

    I mean you can still have XHTML within the HTML5 standard obviously, but is there a reason why XHTML instead of just XML based HTML5?

  3. Mike Reinstein says:

    I think modernizing is a great idea! However, I don’t think xhtml is the way to do this. xhtml is headed towards deprecation, as the xhtml standard 2 is not being ratified by the w3c. The best bet for modernization (at this point) is html 4.01 strict/transitional. In the near future, html5 is the modern standard to strive towards.

    here’s a link to Ian Hickson’s explanation on the background of this issue:
    http://hixie.ch/advocacy/xhtml

    hope this helps! By the way, thanks for a great product; I use mantis for my personal projects @ home.

    -Mike

  4. David Hicks says:

    Thanks for the feedback so far. I should have clarified that the ultimate aim is a move towards XHTML5. That is, HTML5 output which is XML compliant.

    The current 1.3.x master branch checks the HTTP “Accept” header sent by the client to see if the browser accepts application/xhtml+xml as a MIME type. We then adjust the “Content-Type” server header accordingly. Thus pages still render OK in Internet Explorer where XHTML is not supported at all.

    Much of Ian’s explanation seems to focus on XHTML strictness being hard for legacy applications to accomplish. MantisBT 1.3.x no longer has any inline tags and we’re working to remove tags. Scripts and stylesheets should be stored in separate files that are included with or tags. It’s not too hard to learn the specifics of writing well formed XML either (just a few rules to follow). Therefore I’m not too concerned about the “difficulty” of XHTML.

    It’s quite easy to spot problems with the output of MantisBT pages when the browser is required by XML standards to terminate rendering on the first error. If we go down the route of using PHPTAL (XML based templating) we can then easily use standard XML tools to validate MantisBT templates for correctness. XML tools can also make it easier to work with MantisBT pages/templates in general.

  5. lance says:

    Is there a way to export the “notes” in a mantis issue as one of the fields exported?

  6. mbear says:

    “We’re trying to create semantic output from MantisBT complete with class and ID attributes to allow for precise CSS styling of page outputs. Ultimately this will allow us to remove the dedicated β€œprint” pages from MantisBT and instead just use separate on-screen and print stylesheets.”

    Actually, if you’re emitting HTML you may not need to add a lot of ID’s and Classes for CSS to work. (note that my examples are based on version 1.0.5, which is what we’re using at work so you may have already changed the code to do what I suggest.)

    For example, instead of “td.category” and “td.row-category” you could just emit a TH element with the appropriate SCOPE attribute. (TH scope=”row” and TH scope=”col”, respectively.)

    When viewing the “Notes” section of a defect, you could eliminate the “TR TD.spacer” construction completely. Just use CSS to set that. You may also be able to remove the tr.bugnote class as well.

    div#bugnotes_open table {width:100%;}
    div#bugnotes_open table tr td.spacer{display:none;}
    div#bugnotes_open table tr td{border-top:0.5em solid white;}

    That same HTML Table can benefit from TH tags. Use them where 1.0.5 uses “td.bugnote-public” with a scope=”row” attribute. (This is the part of the line with the commenter’s name, date, and the edit/delete button.)

    Then you can use this CSS:
    div#bugnotes_open table tr th{classes assigned to td.bugnote-public}

    Have a good one!

  7. YH says:

    is there a timeline for the 1.3.x release?

  8. ATNZ says:

    Any chance you can include some screenshots in addition to the roadmap of issues, as I can’t get the 1.3 beta downloaded and installed in our environment.. πŸ™ and I want to be able to tell people what’s coming πŸ™‚

  9. Anon says:

    Would love to see a move to a template engine for customisation πŸ™‚

  10. CP says:

    @David Hicks

    IE doesn’t support XHTML *at all*? What, IE 5? IE 6+ handle XHTML in an acceptable (albeit flawed) manner. Web developers have found solutions around it, but why even support IE 6 at all? Almost no one uses it.

    Moreover, it’s not like MantisBT uses a complex cutting edge design. Checking for accepted MIME types is hilariously superfluous. HTML is HTML is HTML. If it doesn’t render correctly, fix the HTML/CSS/JS.

    I agree with everyone else as well. XHTML strict is old news. You’re about 10 years behind schedule. If you’re going to create compliant HTML, work on (X)HTML5, don’t waste your time with ancient standards.

    Try to be innovative, and cutting edge. But don’t use bulky software to manage your template. Humans can read/write XML, that’s how it was designed, and (X)HTML5 is easy to make compliant.

    /rant

  11. David Hicks says:

    @CP:

    Internet Explorer prior to version 9 did not understand what to do with documents served with a MIME type of application/xhtml+xml. See http://en.wikipedia.org/wiki/Internet_Explorer#Standards_support

    There is a huge difference between setting the MIME type in a meta tag and setting the MIME type in the HTTP Content-Type header. The Content-Type header dictates how the browser will parse and process the document. The meta tag tends to be used for informing validators/etc that the document should be treated as XHTML for validation purposes.

    Browsers treat HTML and XHTML quite differently for parser error handling and certain aspects of JavaScript support, amongst numerous other things. Checking for accepted MIME types is therefore very important because some browsers don’t have proper XML parsers and therefore don’t know what the application/xhtml+xml MIME type is.

    Note I refer to XHTML instead of XHTML5. WhatWG’s HTML standard is now versionless.

  12. ATNZ says:

    Any update on when v1.3.x will be released or will there be another 1.2.x release? some idea of roadmap and timing would be really helpful.

  13. Suman says:

    Hi, I used Mantis during my freelancing times … and I loved it. But I always wanted it to look good. That is god 3/4 years back. After I joined regular job I didn’t have time to do freelancing and also never used mantis these days.
    Now I am again back doing some part time freelancing work and would need to use a bug tracker again.
    The first tool I wanted to look at is Mantis. But I found that although quite a few years have passed but the UI has not changed.
    Then I found this post and since I do Ui development for living I will be interested in contributing to Mantis UI.

    I do not know how to contact you guys so I am dropping the note here.

    suman

  14. David Hicks says:

    Hi Suman,

    Victor sent an email to you CC’d to the developer mailing list. I’ve copied it below for anyone reading along:

    Hi Sumank,

    Looking forward for your contributions. I’ve added mantisbt-dev mailing list which is used for developers to collaborate. Here are also some pointers:

    1. Git repository was recently moved to Github, so you can fork it and start contributing patches:
    https://github.com/mantisbt/mantisbt

    2. Developer’s manual – not yet updated to reflect github move
    http://www.mantisbt.org/docs/master-1.2.x/en/developers.html

    3. IRC channel – http://www.mantisbt.org/support.php

    Please share your thoughts so that we can align your contributions with planned work or work in progress.

  15. David Hicks says:

    Assistance with the UI will be most appreciated. The most useful form of assistance at the moment would be creating mockups (either sketches, images or full designs in HTML/CSS). Feel free to be as creative as you like with designing the interface. Feel free to include information that doesn’t exist in the current version of MantisBT. The idea is that the backend can be rewritten to provide the data needed by the frontend.

    An alternative to this approach of all-out UI redesign is to sign up to Github and submit UI related patches against the ‘master’ branch. Because this branch changes frequently it is best to make changes in small batches and submit them for inclusion as quickly as possible. This saves hassle with merging changes in the master branch that conflict.

    Once again, new contributions are warmly welcomed. If you would like further information or want to share some ideas, the developer mailing list (mantisbt-dev@lists.sourceforge.net) is a good place to start. There are a number of MantisBT developers keen to help πŸ™‚

  16. ATNZ says:

    Any update on when v1.3 will be released? Would it be better putting effort into getting v1.3 done, rather than splitting effort between v1.2.x given that it’s fundamentally stable and does the job? and so focus all effort on the v1.3.x platform? Just my 2c worth…

Comments are closed.