Also sprach Aryeh Gregor:

 > > http://www.princexml.com/howcome/2009/wikipedia/ref/

 > This looks good overall.

Thanks.

 > 1) A problem we often tend to have with this kind of thing is that
 > users write lots of custom CSS and JS that depends on the exact
 > elements used, which breaks if we change the markup.  For instance, I
 > find the following rules in the English Wikipedia's custom stylesheet:
 > 
 > sup.reference:target {
 >     background-color: #DEF;
 > }
 > /* stop references with groups from line-breaking */
 > sup.reference a {white-space: nowrap;}

The selectors would have to be rewritten to match the revised markup:

  a.ref:target { background-color: #DEF }
  a.ref { white-space: nowrap }

 > <http://en.wikipedia.org/wiki/MediaWiki:Common.css>
 > 
 > These would break if we got rid of the <sup>, on the English Wikipedia
 > and possibly on tons of other wikis as well.  This makes me reluctant
 > to do that.

It's easy enough to rewrite, and the worst-case scenario is a minor
stylistic change for some users. In the best case, the markup and the
style sheet are changed in sync.

 > 2) I notice you used "font-size: 85%; vertical-align: 35%" instead of
 > the CSS2.1 recommended value for sup, "font-size: 83%; vertical-align:
 > sup".  Is there any particular reason for this?  

Indeed, CSS 2.1 proposes [1]:

  sup { vertical-align: super }

However, with this value, some legacy browsers (IE6/IE7) place the
footnote call slightly higher than Wikipedia currently uses. So, the
35% value was chosen as it seems to result in "pixel-perfect"
renditions. I would be equally happy with the "super" value. 

The 85% value is semi-arbitrary, I've changed it to 83% which seems to
work equally well.

[1] http://www.w3.org/TR/CSS21/sample.html

 > Specifically, one important objective for such a change would be
 > that line-spacing shouldn't be changed, and I'd have to test that
 > in various browsers to avoid regression there.

Yes.

 > 3) Some of the changes you recommend actually aren't software issues,
 > but customizations by the particular wiki's sysops.  In particular,
 > the extra <span>s around the square brackets are specific to enwiki:
 > 
 > http://en.wikipedia.org/w/index.php?title=MediaWiki:Cite_reference_link&action=history
 > 
 > So is the <b>:
 > 
 > http://en.wikipedia.org/w/index.php?title=MediaWiki:Cite_references_link_one&action=history

Interesting. No good reasons are given. Hmm.

 > In the default software, they don't exist.  To get rid of them, you'd
 > want to make a suggestion on wikien-l, the enwiki Village Pump, or a
 > similar forum.  wikitech-l is mostly for the developers and sysadmins,
 > who can't really affect what particular communities choose to do in
 > this sort of thing.

Thanks for pointing me in the right direction.

 > 4) The reason we have an <a> inside a <sup> turns out to be because in
 > wikimarkup, you can't give custom attributes to <a>.  The markup used
 > for the message is wikimarkup, which simply cannot achieve your
 > suggested HTML output.  We'd have to move this to raw HTML to allow
 > it, which would mean hardcoding it into the software, since we don't
 > like to give sysops access to output raw HTML (to reduce the chance of
 > invalid markup -- they can add arbitrary JS anyway, so XSS isn't
 > really an issue).  This would probably annoy people, since they've
 > already customized it.  Or we'd have to add support for explicit <a>
 > to wikimarkup -- maybe a good idea, but also a bigger project.

I'm happy to be put in the "bigger project" category -- I'm here for
the long term -- centuries :-)

 > I do like your proposed markup, and think it would be great if we
 > could move to simpler and more semantic markup overall, but it's not
 > clear to me how to best go about implementing most of it.  I've at
 > least removed the empty title="" attribute, in r49075.  Of the rest,
 > some I can't do: it's up to enwiki sysops.  And one bit (giving
 > attributes to the <a> element) wouldn't work at all without some
 > potentially significant unrelated changes.  But it would be nice if we
 > could move more in this direction, definitely.

Thanks for your considered reply.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howc...@opera.com                  http://people.opera.com/howcome

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to