The present HTML output looks like a mess, we should tidy up this a little. Why not reduce the number of tab spaces for example?
This would look like this:
Description
Related Objects
Event Timeline
How does this "bug" affect accessibility?
Also, HTML is meant to be interpreted by machines, not humans. If you want to look at the generated HTML, you can prettify it with any online tool, or just open the developer tools of your browser
I added it to the accessibility group because there's no HTML-related bugs tag on Phabricator yet. It has been present on Bugzilla. Unfortunately, I don't know how to create this tag here. Such tag would apply to many bugs, like T13555. Could you help me with this?
And towards the bug itself.
I think keeping the code plain and understandable for humans is very important, best example is a wikicode. If the data becomes a mess, we lose control on it. There's no reason to allow MediaWiki to produce such mess. Less tab space will also reduce the entire page size, which is important as well. This also will help with writing CSS themes for Wikipedia, for example.
Here's good article on it: http://webdesign.about.com/od/xhtml/a/aa012003a.htm
I added it to the accessibility group because there's no HTML-related bugs tag on Phabricator yet. It has been present on Bugzilla. Unfortunately, I don't know how to create this tag here. Such tag would apply to many bugs, like T13555. Could you help me with this?
See https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects
And towards the bug itself.
I think keeping the code plain and understandable for humans is very important, best example is a wikicode. If the data becomes a mess, we lose control on it. There's no reason to allow MediaWiki to produce such mess. Less tab space will also reduce the entire page size, which is important as well. This also will help with writing CSS themes for Wikipedia, for example.Here's good article on it: http://webdesign.about.com/od/xhtml/a/aa012003a.htm
This article is for project where humans create plain HTML pages that other humans should maintain. In MediaWiki, HTML is not generated by humans, but by PHP. Humans create PHP code that in turn renders HTML, so humans don't need to maintain plain HTML.
That's very different from Wikicode, that needs to be maintained by humans, and thus is desirable to be well structured to ease readability.
As I said, if you want to write themes for Wikipedia, use the developer tools of your browser. And if we want to save bandwith (which is a valid concern), then the request should be to eliminate all the formatting whitespace, making the generated HTML more more of a mess.
This output isn't caused by the parser. Typically, in the interest of saving bandwidth, none of the HTML should be indented. This is something the client-side should do (Or not, since you shouldn't need the plain HTML). Modern browsers can indent a file for you, or do this automatically.
The issue is further complicated by how the indentation is created in MediaWiki through the skin system. Previously, before SkinMustache and mustache based skins were a thing, Skins outputted the HTML as a giant concatenated string; some parts outputted HTML directly, meaning there was some control about indentation, but those often didn't line up.
With mustache, source files are indented, but individual components are not, and those, especially when generated through nested templates or Html classes in PHP cannot possibly account for consistent indentation.