Because the URL in the boilerplate gets linked, it is very likely to
knock the trailing stars around in different browsers (e.g., Firefox).
Therefore one should avoid trailing stars lest they not line up,
looking ugly.
Version: 1.15.x
Severity: trivial
It works for me in Firefox 3; the pair of stars in the row with the link isn't bolded, but lines up with the rest just fine. Also, since they're in a <pre>, the rendering browser has to use a fixed-width font, which means the stars automatically line up. Browsers that don't do that are broken, and removing stars just because they look slightly out-of-place in some broken browser somewhere is just silly.
Well, I see the stars knocked left about places, Iceweasel/3.0.6 (Debian-3.0.6-1).
But OK, slightly different proportional fonts for links, whatever. Yes, in an ideal world...
Anyway, I also notice you insist on putting things like
<?xml version="1.0"?>
<api>
<error code="help" info="">
and bottom of api.php rendered output. Looks like it is unintended...
(In reply to comment #3)
Well, I see the stars knocked left about places, Iceweasel/3.0.6
(Debian-3.0.6-1).
But OK, slightly different proportional fonts for links, whatever. Yes, in an
ideal world...Anyway, I also notice you insist on putting things like
<?xml version="1.0"?>
<api><error code="help" info="">and bottom of api.php rendered output. Looks like it is unintended...
WTF?
When I view http://en.wikipedia.org/w/api.php in Firefox 3, I see something like:
<?xml version="1.0"?>
<api>
<error code="help" info=""> ...help text goes here... </error>
</api>
Which is exactly what I'm supposed to see. If you see something different, that's probably your browser's fault; check the HTML source (which has <api> encoded as <api> , beware) to be sure.
Yes, I'm just saying it looks "unprofessional", or "unintended".
What if Main_Page started like that?
It looks like we clicked "View Page Source" in our browser. Which
would be fine, except that when we hit the stars, we realize we
didn't.
If it were me, I would only write the error code, if there was an
error.
And I would write it:
Error code: help
(but is help an error?)
Or maybe api.php is not intended to be read in browsers?
It's not supposed to look pretty, it's supposed to provide basic documentation to people intending to use the API. Don't see why we're still discussing this.
(In reply to comment #5)
If it were me, I would only write the error code, if there was an
error.
And I would write it:
Error code: help
The response is formatted in pretty-printed XML because that's what you asked for (the format parameter defaults to xmlfm). There's also http://en.wikipedia.org/w/api.php?format=xml and http://en.wikipedia.org/w/api.php?format=yamlfm (the latter has the least intrusive format wrapping).
(but is help an error?)
Asking for the help page and getting it is not strictly an error, true, but we include the help with real errors as well (only in fm formats though) and we need some formatting to wrap the help text in, which is probably why the help screen was implemented this way (I didn't write it, though). Similarly, calling a command line tool with invalid arguments will result in the same output (except for an error message maybe) as using --help .
Or maybe api.php is not intended to be read in browsers?
The api.php output (not just the help, but all other output cases as well) is primarily intended to be read and parsed by bots and only secondarily to be read in browsers. We've got the pretty-print formatters to make stuff look nicer, but the formatting is always there because bots are the primary audience.
(In reply to comment #6)
It's not supposed to look pretty, it's supposed to provide basic documentation
to people intending to use the API. Don't see why we're still discussing this.
I agree; making stuff look pretty is not a top priority, and I think pretty much everything's been said about this now.