OK, its been nearly a month and so far I've been ignored. This is important; we /are not/ following the terms of our own license and this needs to be fixed ASAP.
See: http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/005119.html
I've also posted a feature request on Sourceforge, but that too has been ignored.
-- Daniel Mayer (aka mav)
Daniel Mayer wrote:
OK, its been nearly a month and so far I've been ignored. This is important; we /are not/ following the terms of our own license and this needs to be fixed ASAP.
Fixed.
'Printable mode' really should be replaced with a style sheet, though. It'd save a lot of trouble in the code, and people could just hit "print" from the regular page and get decent-looking output.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
'Printable mode' really should be replaced with a style sheet, though. It'd save a lot of trouble in the code, and people could just hit "print" from the regular page and get decent-looking output.
yes, I have been thinking about this. It would certainly be a more elegant way to do it.
There is at least one problem however: hidden URLs are written out in full in the generated printable version. There's probably CSS trickery that allows the HREF attribute to be appended to the A element, but.... it probably won't work in IE :(
Incidentally, "Table of contents [showhide javascript:toggleToc()]" doesn't make much sense in print ... ;)
tarquin wrote:
There is at least one problem however: hidden URLs are written out in full in the generated printable version. There's probably CSS trickery that allows the HREF attribute to be appended to the A element, but.... it probably won't work in IE :(
Aye, but there's the next best thing:
wikistandard.css: .exturl { display: none } /* redundant on screen */
print.css: .exturl { display: inline } /* need in print */
html: <a class="ext" href="http://blah/">foo</a> <span class="exturl">(http://blah/)</span>
Yes, lynx and Netscape 4 with JavaScript disabled will see extra URLs. Tough.
Incidentally, "Table of contents [showhide javascript:toggleToc()]" doesn't make much sense in print ... ;)
print.css: #toc { display: none }
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
wikistandard.css: .exturl { display: none } /* redundant on screen */
print.css: .exturl { display: inline } /* need in print */
html: <a class="ext" href="http://blah/">foo</a> <span class="exturl">(http://blah/)</span>
Yes, lynx and Netscape 4 with JavaScript disabled will see extra URLs. Tough.
That would require some change in the page output code. But fair enough :-)
There is another problem -- it seems a bit daft to have to specify a print version of the stylesheet of each skin. We could use another LINK in the HTML HEAD for the print stylesheet, but the problem is then that each skin has different elements that must be hidden.
I think a global print stylesheet would be best, and to do that we'd have to specify a basic page architecture common to all skins. This doesn't need to be more specific than: * all header content is in DIV id='head' * all sidebar content is in DIV id='sidebar' * all footer ... etc
A reorganisation like this might be easiest to do after we convert to a template system using "smarty".
While on the subject of stylesheets, I've been pondering something else lately. Something like image-floating styles would presumably be the same in all skin stylesheets -- at least the basics. (some future skin might want flashing green border, who knows!) Is it best to: a) paste the same class into each skin stylesheet. Future skin stylesheets must then ensure they begin from a template that has the essential classes b) create a "global" stylesheet of elements that work across all skins.
On UnrealWiki I went for option b). Particular skin stylesheets can still add rules to those classes of course, but the core stuff, eg "float:left;" is set in only one location. But it does mean every browser downloads 2 stylesheets instead of 1. Would this be a problem for our server?
if not, this is something I would like to implement.
tarquin wrote:
A reorganisation like this might be easiest to do after we convert to a template system using "smarty".
...
b) create a "global" stylesheet of elements that work across all skins.
...
this is something I would like to implement.
Yes, please work on this!
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
tarquin wrote:
A reorganisation like this might be easiest to do after we convert to a template system using "smarty".
implementing smarty is beyond my capabilities -- I'm not good enough with PHP, and I don't have a test version of Wikipedia running becuase I'm on Windows. If another developer is able to work on the PHP side of this, I can take care of converting our current skins to templates. (and I'm looking into setting up a linux box :) -- though I appreciate our PHP gurus are busy with 1001 other things. What's happened to Lighting, who first suggested this? ( http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/005004.html )
b) create a "global" stylesheet of elements that work across all skins.
this is something I would like to implement.
Yes, please work on this!
so each page have 2 stylesheets attached instead of 1 is ok -- I keep hearing about problems with Apache having too many connections -- won't this add to that?
I've set up a page on meta for all this sort of thing: http://meta.wikipedia.org/wiki/Skins if anyone can think of things that could be usefully moved to a global stylesheet, please add it to the list there.
tarquin wrote:
so each page have 2 stylesheets attached instead of 1 is ok -- I keep hearing about problems with Apache having too many connections -- won't this add to that?
HTTP connections can transfer more than one file. They'll go in the same lump.
-- brion vibber (brion @ pobox.com)
Dan, I think that article is fine -- I mean youre right -- There should be some FDL on a print, but the important thing should be branding. Wikipedia the free encyclopedia in a single article case should be fine -- anyone wanting to come back to here to get some more will run into FDL.
First bring them to the church--they lay God on them. -S-
--- Daniel Mayer maveric149@yahoo.com wrote:
OK, its been nearly a month and so far I've been ignored. This is important; we /are not/ following the terms of our own license and this needs to be fixed ASAP.
See:
http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/005119.html
I've also posted a feature request on Sourceforge, but that too has been ignored.
-- Daniel Mayer (aka mav) _______________________________________________ Wikitech-l mailing list Wikitech-l@Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
wikitech-l@lists.wikimedia.org