Summary

John Vandenberg/Archive/2008-4

“ I see value in maintaining a template interface to this functionality; a number of reasons, really. First would be flexibility; the template provides a point of control, i.e. options for the future. Second, using client-side css is better than server-side parser functions in a lot of circumstances. When someones copy-pastes text off the screen that has been somehow UPPERED, what should they get? With the css approach, they get the, presumably, mixed-case that was passed to the template; with the parser function, they get ALL-CAPS, all the time. ”
Source: Wikisource

John Vandenberg/Archive/2008-4

“ At present we cant add CSS to Commons.css for every work, otherwise it would become very big. Additions to the global CSS need to be generic, so that they are features that can be used by many works. Perhaps we need a big discussion about this on WS:S, to investigate current CSS inline usage and enhance the global CSS to minimise inline CSS. Document specific style sheets hasnt been widely discussed, and it would depend on a software enhancement, or perhaps a mediawiki extension already exists. I dont have time to run a bot elsewhere. ”
Source: Wikisource

John Vandenberg/Archive/2008-4

“ I think you are assuming that the span tags would be added before the templates are called. For starters, I am pretty sure that the templates are evaluated first, and then the HTML is added. But, I dont care whether the templates or HTML conversion happens first at the moment - if we are going to get a dev to add build something specifically for our Page: namespace, they are going to have to do it in the way that works for our needs. The main issue is we dont yet know our needs; we need to think it through and come up with something that works. ”
Source: Wikisource

Get perspective with Kwize: daily news enlightened by great literature

Follow on X Follow on Facebook