Last modified: 2009-03-12 23:28:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19950, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17950 - API boilerplate that doesn't knock stars around
API boilerplate that doesn't knock stars around
Status: CLOSED WORKSFORME
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.15.x
All All
: Normal trivial (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-12 01:10 UTC by Dan Jacobson
Modified: 2009-03-12 23:28 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
example (1.54 KB, patch)
2009-03-12 01:11 UTC, Dan Jacobson
Details

Description Dan Jacobson 2009-03-12 01:10:33 UTC
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.
Comment 1 Dan Jacobson 2009-03-12 01:11:10 UTC
Created attachment 5920 [details]
example
Comment 2 Roan Kattouw 2009-03-12 08:30:35 UTC
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.
Comment 3 Dan Jacobson 2009-03-12 18:36:00 UTC
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...
Comment 4 Roan Kattouw 2009-03-12 22:56:56 UTC
(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 &lt;api&gt; , beware) to be sure.
Comment 5 Dan Jacobson 2009-03-12 23:14:23 UTC
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?
Comment 6 Chad H. 2009-03-12 23:16:17 UTC
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.
Comment 7 Roan Kattouw 2009-03-12 23:28:55 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links