I'd like to do some tinkering with the Wikipedia skins and maybe come up with a couple of different layouts, but the HTML seems to be scattered across several different PHP files. Is there a recommended easy way to do this (ideally in a WYSIWYG HTML editor like Dreamweaver)?
(Sheldon Rampton sheldon.rampton@verizon.net): I'd like to do some tinkering with the Wikipedia skins and maybe come up with a couple of different layouts, but the HTML seems to be scattered across several different PHP files. Is there a recommended easy way to do this (ideally in a WYSIWYG HTML editor like Dreamweaver)?
You can certainly design and lay out Wikipedia pages using any tool you like, and just point the developers to them when you're done with a suggestion to implement you design. If it aligns with our goals (that is, it's conformant HTML, works across browsers and OSs, is not a performance penalty, etc.), then we're like to do it.
Lee Daniel Crocker wrote:
(Sheldon Rampton sheldon.rampton@verizon.net): I'd like to do some tinkering with the Wikipedia skins and maybe come up with a couple of different layouts, but the HTML seems to be scattered across several different PHP files. Is there a recommended easy way to do this (ideally in a WYSIWYG HTML editor like Dreamweaver)?
You can certainly design and lay out Wikipedia pages using any tool you like, and just point the developers to them when you're done with a suggestion to implement you design. If it aligns with our goals (that is, it's conformant HTML, works across browsers and OSs, is not a performance penalty, etc.), then we're like to do it.
It would be nice if designers could simply upload an HTML template & a CSS file. (or CSS files plural -- I've discovered alternate stylesheets. see devedge.netscape.com with Mozilla / Opera to see!)
The system that was set up on the test server of having the combined HTML & CSS in a wiki pages is unfeasible. when designing by hand, one tends to refresh the browser every minute or so. having to save the wiki page & wait for a reload would really drag things out; plus combining CSS & HTML in a single document means I lost 1/2 of the syntax highlighitng in TextPad :(
(Sheldon Rampton sheldon.rampton@verizon.net): I'd like to do some tinkering with the Wikipedia skins and maybe come up with a couple of different layouts, but the HTML seems to be scattered across several different PHP files. Is there a recommended easy way to do this (ideally in a WYSIWYG HTML editor like Dreamweaver)?
On Sun, 2003-03-23 at 13:46, tarquin wrote:
It would be nice if designers could simply upload an HTML template & a CSS file.
Tarquin, Sheldon: could you create some sample HTML template files & CSS sheets in the form you'd *like* to be able to work with? Then we can see about making the code talk to it.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Tarquin, Sheldon: could you create some sample HTML template files & CSS sheets in the form you'd *like* to be able to work with? Then we can see about making the code talk to it.
This is just a very rough mockup. I've devised some substitution syntax :-) -- see the comments in the html.
couple of neat tricks: 1. the sidebar width scales with browser font size changes (we currently don't) 2. use of a body class for article / meta namespace means we can do things like put the header of non-article pages in italics
I'm assuming that substitutions is done in 2 phases: some of the substitutions can be made when the template is uploaded & then cached by the server as HTML. This would be all the things which are language-dependent but the same throughout a particular language, eg * the "From Wikipedia, the free encyclopedia." text * some of the links such as "Recent Changes" * the GFDL notice
It's a bit messy having "{MainLinks, suffix:"<br>"}", because I can't see what the list is going to look like in my browser. One option would be to use the same syntax as Apache's SSI, but the (big!) downside to that is that I have to load my page through Apache every time I make changes, which is quite a bit slower than loading from the file direct. I'll scratch my head & see if I can come up with something slightly better for lists of links ...
(tarquin tarquin@planetunreal.com):
This is just a very rough mockup. I've devised some substitution syntax :-) -- see the comments in the html.
I don't see any use for a template system at all. It's just a performance penalty for no gain in either flexibility or capability.
What I'm interested in seeing is a /complete page/, fully rendered, with all text, markup, and style elements. We can then implement that in the structure we already have which is quite powerful.
couple of neat tricks:
- the sidebar width scales with browser font size changes (we
currently don't) 2. use of a body class for article / meta namespace means we can do things like put the header of non-article pages in italics
Those sound useful; if you can integrate that into the existing stylesheets, so much the better.
Lee Daniel Crocker wrote:
(tarquin tarquin@planetunreal.com):
This is just a very rough mockup. I've devised some substitution syntax :-) -- see the comments in the html.
I don't see any use for a template system at all. It's just a performance penalty for no gain in either flexibility or capability.
Suppose I'd like to make improvements to the current skins -- how do I get HTML & CSS that I can work with? I can find the CSS files for the existing skins in the stuff I got from CVS, but everything else is in PHP. Where is the actual HTML made and how can I see it?
What I'm interested in seeing is a /complete page/, fully rendered,
with all text, markup, and style elements.
You mean a Wikipedia page that's just like one I would save from my web browser?
Those sound useful; if you can integrate that into the existing stylesheets, so much the better.
From what I can tell from Skin.php, the current system shoves a "bgcolor" => "#FFFFDD" into the HTML's BODY tag Change that to shove a class= ... as in my notes: "class" => "article" and "class" => "meta" presumably
(tarquin tarquin@planetunreal.com):
Suppose I'd like to make improvements to the current skins -- how do I get HTML & CSS that I can work with? I can find the CSS files for the existing skins in the stuff I got from CVS, but everything else is in PHP. Where is the actual HTML made and how can I see it?
Well, yeah, it's in PHP; what gets rendered within the article text is handled by the doWikiPass2() function of OutputPage.php, which makes calls out to the skin to render links and some other things. The stuff before and after the article text is produced by the skin directly.
Skin.php is subclassed by the individual skins.
What I'm interested in seeing is a /complete page/, fully rendered,
with all text, markup, and style elements.
You mean a Wikipedia page that's just like one I would save from my web browser?
Exactly. If that shows me some tricks that would useful, then I can code them up.
Those sound useful; if you can integrate that into the existing stylesheets, so much the better.
From what I can tell from Skin.php, the current system shoves a "bgcolor" => "#FFFFDD" into the HTML's BODY tag Change that to shove a class= ... as in my notes: "class" => "article" and "class" => "meta" presumably
That (or something like it) is probably a good idea. I'm only a bit concerned that I want to have styles that apply to the body text of articles regardless of namespace, but I suppose I can use the DIVs for that.
Lee Daniel Crocker wrote:
Exactly. If that shows me some tricks that would useful, then I can code them up.
Well if I were to design a skin from scratch, you'd code the entire thing into PHP from my HTML? egad! I figured using templates would shunt part of the work onto the page designer's lap, that's all.
Those sound useful; if you can integrate that into the existing stylesheets, so much the better.
From what I can tell from Skin.php, the current system shoves a "bgcolor" => "#FFFFDD" into the HTML's BODY tag Change that to shove a class= ... as in my notes: "class" => "article" and "class" => "meta" presumably
That (or something like it) is probably a good idea. I'm only a bit concerned that I want to have styles that apply to the body text of articles regardless of namespace, but I suppose I can use the DIVs for that.
?? The css has 3 blocks: body { /* these style rules apply to all articles */ } body.article { /* just sets the white colour for articles */ } body.meta { /* just sets the yellow colour for meta-pages*/ }
This is why it's called *cascading* stylesheets. :-D I think we have a communication problem! You speak PHP, I don't. I speak CSS, and I'm not sure you do.
(tarquin tarquin@planetunreal.com):
The css has 3 blocks: body { /* these style rules apply to all articles */ } body.article { /* just sets the white colour for articles */ } body.meta { /* just sets the yellow colour for meta-pages*/ }
This is why it's called *cascading* stylesheets. :-D I think we have a communication problem! You speak PHP, I don't. I speak CSS, and I'm not sure you do.
Yes, I understand CSS just fine, I just hadn't looked specifically at yours yet to see what you were doing. And it /is/ a nuisance that you can't have multiple classes on a single element, even though you can do a lot without them. I never saw a line of PHP before I wrote the wiki code, so if I can learn it well enough to write the whole thing, you should be able to learn enough to make modifications without too much work.
Lee Daniel Crocker wrote:
Yes, I understand CSS just fine, I just hadn't looked specifically at yours yet to see what you were doing. And it /is/ a nuisance that you can't have multiple classes on a single element, even though you can do a lot without them. I never saw a line of PHP before I wrote the wiki code, so if I can learn it well enough to write the whole thing, you should be able to learn enough to make modifications without too much work.
Sorry if I offended -- I only meant to say we have areas of knowledge
There are quite a few tricks to work around the problem of single classes. For example, there's no need to give the "From Wikipedia, the free encyclopedia." paragraph a class. We can access it by either:
h1 + p { /* first P after an h1 but I'm not sure how IE supports this */ } or div.masthead p { /* if we made a top div */ }
with E[foo="bar"] you can do matching on arbitrary tags, but again, support is patchy.
(tarquin tarquin@planetunreal.com):
Sorry if I offended -- I only meant to say we have areas of knowledge
No problem--I agree, I'm not a CSS guru by any means.
There are quite a few tricks to work around the problem of single classes. For example, there's no need to give the "From Wikipedia, the free encyclopedia." paragraph a class. We can access it by either:
h1 + p { /* first P after an h1 but I'm not sure how IE supports this */ } or div.masthead p { /* if we made a top div */ }
with E[foo="bar"] you can do matching on arbitrary tags, but again, support is patchy.
Yep, that's another problem with CSS--I've tried to make the stylesheets I created as simple and widely-supported as possible, and the fallbacks reasonable. That's why I want to see a complete working page before I think about coding anything--I want to see exactly what it looks like on a wide set of browsers first, then make the code produce it.
tarquin wrote:
Lee Daniel Crocker wrote:
What I'm interested in seeing is a /complete page/, fully rendered,
with all text, markup, and style elements.
OK, a possible (and working!) *source* (template) is at http://test.wikipedia.org/wiki/Wikipedia%3AOmniCologneBlue which renders something very similar to CologneBlue.
To view a *rendered* page, choose the "Omni" skin in your user settings. To change the rendereing, edit [[Wikipedia:OmniCologneBlue]] accordingly.
Magnus
Speaking of skins, I've been hoping for a stylesheet that is more suitable for the 'advanced' user - something that makes it easy to do things as quick and efficiently as possible.
I've created a full finished page, and put it out on my webserver. All of the CSS is in this one file (instead of linking against the standard CSS file, which I can't edit.)
Here are some notes, but I got tired of writing them down after a while:
1) a.stub has identical elements in both the HTML and the external CSS file. [removed one] 2) #quickbar a.new is broken (CC2200 should be #CC2200) [fixed] 3) JabbaSkript is removed. 4) CSS is in alphabetical order (tons easier to read and much clearer). 5) Removed the pull-down and Go button from topbar. 6) Removed bgcolor from <body> 7) Removed Main Page, Recent changes, Edit this page, and Older versions from the topbar. 8) Removed the <p> under "From Wikipedia, the free encyclopedia." 9) Removed Wikipedia logo. 10) Abolished 'article' CSS section (the article is the content, isn't it?) 11) Moved 'footer' out of 'content' section. ...
Anyways, here is where you can take a look: Original: http://www.twoevils.org/files/wiki/Rabbit.html Revamped: http://www.twoevils.org/files/wiki/Rabbit-minimal.html
It uses CSS2 heavily, and so it probably won't render in any non-compliant browser (which is fine for 'alternative' skins, I hear).
On Wed, 26 Mar 2003 14:55:56 -0600, Nick Reinking nick@twoevils.org wrote:
Speaking of skins, I've been hoping for a stylesheet that is more suitable for the 'advanced' user - something that makes it easy to do things as quick and efficiently as possible.
I've created a full finished page, and put it out on my webserver. All of the CSS is in this one file (instead of linking against the standard CSS file, which I can't edit.)
Here are some notes, but I got tired of writing them down after a while:
- a.stub has identical elements in both the HTML and the external CSS
file. [removed one] 2) #quickbar a.new is broken (CC2200 should be #CC2200) [fixed] 3) JabbaSkript is removed. 4) CSS is in alphabetical order (tons easier to read and much clearer). 5) Removed the pull-down and Go button from topbar. 6) Removed bgcolor from <body> 7) Removed Main Page, Recent changes, Edit this page, and Older versions from the topbar. 8) Removed the <p> under "From Wikipedia, the free encyclopedia." 9) Removed Wikipedia logo. 10) Abolished 'article' CSS section (the article is the content, isn't it?) 11) Moved 'footer' out of 'content' section. ...
Anyways, here is where you can take a look: Original: http://www.twoevils.org/files/wiki/Rabbit.html Revamped: http://www.twoevils.org/files/wiki/Rabbit-minimal.html
It uses CSS2 heavily, and so it probably won't render in any non-compliant browser (which is fine for 'alternative' skins, I hear).
Nice, but your fixed div at the top is too short for my default font size, so the text is truncated. You probably need to set the div height in ems. And I prefer lower contrast than black on white.
Richard Grevers wrote:
On Wed, 26 Mar 2003 14:55:56 -0600, Nick Reinking nick@twoevils.org wrote:
Anyways, here is where you can take a look: Original: http://www.twoevils.org/files/wiki/Rabbit.html Revamped: http://www.twoevils.org/files/wiki/Rabbit-minimal.html
It uses CSS2 heavily, and so it probably won't render in any non-compliant browser (which is fine for 'alternative' skins, I hear).
Nice, but your fixed div at the top is too short for my default font size, so the text is truncated. You probably need to set the div height in ems.
Yup. And have you applied styling to the form buttons? I think it's best to let the browser supply the user's OS default widgets, so they *look* like things that perform actions. I miss the wikipedia logo too :(
On Wed, Mar 26, 2003 at 11:14:23PM +0000, tarquin wrote:
Richard Grevers wrote:
On Wed, 26 Mar 2003 14:55:56 -0600, Nick Reinking nick@twoevils.org wrote:
Anyways, here is where you can take a look: Original: http://www.twoevils.org/files/wiki/Rabbit.html Revamped: http://www.twoevils.org/files/wiki/Rabbit-minimal.html
It uses CSS2 heavily, and so it probably won't render in any non-compliant browser (which is fine for 'alternative' skins, I hear).
Nice, but your fixed div at the top is too short for my default font size, so the text is truncated. You probably need to set the div height in ems.
Yup. And have you applied styling to the form buttons? I think it's best to let the browser supply the user's OS default widgets, so they *look* like things that perform actions. I miss the wikipedia logo too :(
Alright, I will remove styling from the buttons. I couldn't get them to look right, anyways. As for the logo, I can put that back in, I was just trying for a page that loads as quickly as possible. Every page loaded without the image is one less 304 generated on the server. :)
Now, if we had a Wikipede... ;)
On Thu, Mar 27, 2003 at 10:43:14AM +1200, Richard Grevers wrote:
On Wed, 26 Mar 2003 14:55:56 -0600, Nick Reinking nick@twoevils.org wrote:
Speaking of skins, I've been hoping for a stylesheet that is more suitable for the 'advanced' user - something that makes it easy to do things as quick and efficiently as possible.
I've created a full finished page, and put it out on my webserver. All of the CSS is in this one file (instead of linking against the standard CSS file, which I can't edit.)
Here are some notes, but I got tired of writing them down after a while:
- a.stub has identical elements in both the HTML and the external CSS
file. [removed one] 2) #quickbar a.new is broken (CC2200 should be #CC2200) [fixed] 3) JabbaSkript is removed. 4) CSS is in alphabetical order (tons easier to read and much clearer). 5) Removed the pull-down and Go button from topbar. 6) Removed bgcolor from <body> 7) Removed Main Page, Recent changes, Edit this page, and Older versions from the topbar. 8) Removed the <p> under "From Wikipedia, the free encyclopedia." 9) Removed Wikipedia logo. 10) Abolished 'article' CSS section (the article is the content, isn't it?) 11) Moved 'footer' out of 'content' section. ...
Anyways, here is where you can take a look: Original: http://www.twoevils.org/files/wiki/Rabbit.html Revamped: http://www.twoevils.org/files/wiki/Rabbit-minimal.html
It uses CSS2 heavily, and so it probably won't render in any non-compliant browser (which is fine for 'alternative' skins, I hear).
Nice, but your fixed div at the top is too short for my default font size, so the text is truncated. You probably need to set the div height in ems. And I prefer lower contrast than black on white.
I could never figure out how to set high in ems, when you were going to have inline buttons. I would do that if I could. Maybe just set it to like 2 or 3ems, and deal with it.
As for contrast, I will probably change that. It was just a quick mockup. :) You can have hot pink text on a yellow background. :P (j/k)
If you want redesign wikipedia's look or add a skin, here's what I consider to be the basic requirements. Others may want to add to or quibble with these, but I consider them important to the point where I would not be likely to implement anything that violates them:
- All output, both inside the article text and outside, must be fully W3C-compliant HTML 4.0 for now, and XHTML 1.0 at some point in the future.
- Markup should be as economical as possible for performance.
Within the article text itself:
- The text of the article must be rendered as actual text with appropriate semantic labeling, so that it is readable on all browsers, including text-only browsers like Lynx, speech browsers for the blind, etc. The HTML code within the article should be the same on all skins. No visual markup should be used.
- Style elements should be contained in an externally linked stylesheet, using valid CSS (preferably mostly CSS 1, but CSS 2 where the effect can't be achieved otherwise). Styles should be attached to elements within the article based on element classes and unique IDs.
- JavaScript should not be used with the article text.
- Article text must not depend on any system-specific features like non-standard symbol fonts.
- Article text should be in high-contrast colors that are not so overly loud they induce eye strain, and serifed fonts are preferred for readability.
Outside the article text (sidebars, etc.) things can be a bit more relaxed:
- JavaScript can be used for "extra" functionality (like form validations) as long as the site is still usable by those that don't have JavaScript or have it turned off.
- Site should render reasonably on Netscape 4.X, Gecko-based browsers (Mozilla, Netscape 7, Galeon...), KHTML-based browsers (Konqueror, Safari...), MS Internet Explorer 4+, and Lynx. It's OK if some non-vital features won't render on some browsers, especially Netscape 4.X and Lynx, as long as users of those browsers can still view and edit articles and otherwise interact with the site normally.
- Text in sidebars, forms, etc., should be readable but doesn't have to face the same constraints as article text: for example louder colors and sans-serif fonts are fine.
On Mon, 24 Mar 2003 14:31:52 -0600, Lee Daniel Crocker lee@piclab.com wrote:
- Article text should be in high-contrast colors that are not so
overly loud they induce eye strain, and serifed fonts are preferred for readability.
<Klaxon sound>
From my personal experience I strongly disagree with this. I side with the
various research studies which show that whilst serifed fonts provide better readability on paper, sans-serif is more readable on screen. In addition, typefances with metrics that depart considerably from the norm (such as verdana) are best avoided. (My personal favourite is Trebuchet, which I use for nearly everything).
Perhaps the best solution is that font-family preference should be left entirely to the user?
(Richard Grevers dramatic@xtra.co.nz): On Mon, 24 Mar 2003 14:31:52 -0600, Lee Daniel Crocker lee@piclab.com wrote:
- Article text should be in high-contrast colors that are not so
overly loud they induce eye strain, and serifed fonts are preferred for readability.
<Klaxon sound> From my personal experience I strongly disagree with this. I side with the various research studies which show that whilst serifed fonts provide better readability on paper, sans-serif is more readable on screen. In addition, typefances with metrics that depart considerably from the norm (such as verdana) are best avoided. (My personal favourite is Trebuchet, which I use for nearly everything).
Perhaps the best solution is that font-family preference should be left entirely to the user?
The user will always be free to have his browser substitute his own stylesheets. If a Sans font is clean and readable on screen, that's good too--that particular point is a suggestion, not a firm requirement. Trebuchet is nice--do you know if there's any free equivalent? I tend to use Lucida fonts myself which are easy to find, but I think Bitstream recently donated some more modern ones to the public we might want to look into. I certainly don't want us to standardize on anything that only looks good on Windows machines.
On Mon, Mar 24, 2003 at 04:10:14PM -0600, Lee Daniel Crocker wrote:
(Richard Grevers dramatic@xtra.co.nz): On Mon, 24 Mar 2003 14:31:52 -0600, Lee Daniel Crocker lee@piclab.com wrote:
- Article text should be in high-contrast colors that are not so
overly loud they induce eye strain, and serifed fonts are preferred for readability.
<Klaxon sound> From my personal experience I strongly disagree with this. I side with the various research studies which show that whilst serifed fonts provide better readability on paper, sans-serif is more readable on screen. In addition, typefances with metrics that depart considerably from the norm (such as verdana) are best avoided. (My personal favourite is Trebuchet, which I use for nearly everything).
Perhaps the best solution is that font-family preference should be left entirely to the user?
The user will always be free to have his browser substitute his own stylesheets. If a Sans font is clean and readable on screen, that's good too--that particular point is a suggestion, not a firm requirement. Trebuchet is nice--do you know if there's any free equivalent? I tend to use Lucida fonts myself which are easy to find, but I think Bitstream recently donated some more modern ones to the public we might want to look into. I certainly don't want us to standardize on anything that only looks good on Windows machines.
Personally choosing a font, or relying on one, is universally considered a Bad Idea(tm). If you want a sans font, fine - specify that you want a sans font in the stylesheet. Forcing a particular font is just a bad idea - usually the UA will know which font is best.
Lee Daniel Crocker wrote:
- Site should render reasonably on Netscape 4.X, Gecko-based
browsers (Mozilla, Netscape 7, Galeon...), KHTML-based browsers (Konqueror, Safari...), MS Internet Explorer 4+, and Lynx. It's OK if some non-vital features won't render on some browsers, especially Netscape 4.X and Lynx, as long as users of those browsers can still view and edit articles and otherwise interact with the site normally.
The default skin, yes. But user-selectable skins shouldn't be afraid to ONLY parse for standards-compliant browsers -- provided we *say so loudly* in the preferences selection.
Lee Daniel Crocker wrote:
If you want redesign wikipedia's look or add a skin, here's what I consider to be the basic requirements. Others may want to add to or quibble with these, but I consider them important to the point where I would not be likely to implement anything that violates them:
- All output, both inside the article text and outside, must
be fully W3C-compliant HTML 4.0 for now, and XHTML 1.0 at some point in the future.
We need to close our <P> tags before we validate!
- All output, both inside the article text and outside, must
be fully W3C-compliant HTML 4.0 for now, and XHTML 1.0 at some point in the future.
We need to close our <P> tags before we validate!
Only for XHTML, and we aren't there yet. The pages should validate as HTML 4.0 Transitional now, modulo any bugs that may have been introduced since I last did that (I know of one I'm working on).
On Fri, Mar 28, 2003 at 01:14:11PM -0600, Lee Daniel Crocker wrote:
- All output, both inside the article text and outside, must
be fully W3C-compliant HTML 4.0 for now, and XHTML 1.0 at some point in the future.
We need to close our <P> tags before we validate!
Only for XHTML, and we aren't there yet. The pages should validate as HTML 4.0 Transitional now, modulo any bugs that may have been introduced since I last did that (I know of one I'm working on).
I don't believe closing your <p> tags violates 4.01, and it moves us closer to XHTML. As such, it seems like a damned good idea to me. :) What annoys me more is how ugly our HTML looks. I'll admit; ugly HTML is not wrong, but it is pretty distasteful. Kind of like playing gothic rock at a funeral. :P Could we settle on a standard look for our HTML? I see things like this all the time (pulled out of rabbit):
<SCRIPT TYPE="text/javascript"> (capitalization suckiness) <a href="....." class='internal'> (mixed quotes) #quickbar a.new { color: CC2200; ) (invalid, but possibly parsed) <table width='98%'> border=0 cellspacing=0> (mixed/missing quotes)
Can we just settle upon lowercase tags and double quotes around all attributes?
(Nick Reinking nick@twoevils.org):
<SCRIPT TYPE="text/javascript"> (capitalization suckiness) <a href="....." class='internal'> (mixed quotes) #quickbar a.new { color: CC2200; ) (invalid, but possibly parsed) <table width='98%'> border=0 cellspacing=0> (mixed/missing quotes) Can we just settle upon lowercase tags and double quotes around all attributes?
I did settle on lowercase tags--somebody else added that SCRIPT, which I'd love to remove as soon as I figure out what it's there for. Quotes are trickier: I can't just change them all unilaterally because they are chosen based on the possible values of the attribute: i.e., those that might possibly contain single quotes are put in doubles, and vice versa. Though admittedly, some of them are just chosen to make the PHP code easier (i.e., when HTML is part of a PHP string, single quotes are used just because it's easier to read "='internal'" than "="internal"".
A future version of the software will produce a DOM for each page rather than straight HTML, and then a module will produce various outputs from the DOM. That's a ways off.
On Fri, Mar 28, 2003 at 01:36:50PM -0600, Lee Daniel Crocker wrote:
(Nick Reinking nick@twoevils.org):
<SCRIPT TYPE="text/javascript"> (capitalization suckiness) <a href="....." class='internal'> (mixed quotes) #quickbar a.new { color: CC2200; ) (invalid, but possibly parsed) <table width='98%'> border=0 cellspacing=0> (mixed/missing quotes) Can we just settle upon lowercase tags and double quotes around all attributes?
I did settle on lowercase tags--somebody else added that SCRIPT, which I'd love to remove as soon as I figure out what it's there for. Quotes are trickier: I can't just change them all unilaterally because they are chosen based on the possible values of the attribute: i.e., those that might possibly contain single quotes are put in doubles, and vice versa. Though admittedly, some of them are just chosen to make the PHP code easier (i.e., when HTML is part of a PHP string, single quotes are used just because it's easier to read "='internal'" than "="internal"".
A future version of the software will produce a DOM for each page rather than straight HTML, and then a module will produce various outputs from the DOM. That's a ways off.
Oh, and one other thing. It seems to me that it could be good to shorten the name of some of the styles. I mean, it may seem silly to shorten 'internal' to 'int' and 'external' to 'ext', but hear me out. Say, these appear 20 times on the average page (probably low, they appear 55 times on Rabbit.)
Average monthly bandwith usage: 20 * 5 * 200000 * 30 / 1048576 = ~ 572.2MB/month
20 = average appearances of 'internal' and 'external' 5 = character difference (5 bytes) 200000 = hits/day 30 = days in a month 1048576 = bytes in a MB
(Nick Reinking nick@twoevils.org):
Oh, and one other thing. It seems to me that it could be good to shorten the name of some of the styles. I mean, it may seem silly to shorten 'internal' to 'int' and 'external' to 'ext', but hear me out. Say, these appear 20 times on the average page (probably low, they appear 55 times on Rabbit.)
I'm not at all resistant to that idea--also, making the internal links use relative URLs should tighten things up as well.
On Fri, 28 Mar 2003, Lee Daniel Crocker wrote:
(Nick Reinking nick@twoevils.org):
<SCRIPT TYPE="text/javascript"> (capitalization suckiness)
I did settle on lowercase tags--somebody else added that SCRIPT, which I'd love to remove as soon as I figure out what it's there for.
That's for the optional 'enhanced recentchanges', I believe. It should be moved to a .js file and only referenced when using said enhanced recentchanges.
Quotes are trickier: I can't just change them all unilaterally because they are chosen based on the possible values of the attribute: i.e., those that might possibly contain single quotes are put in doubles, and vice versa.
Better IMHO to always use htmlspecialchars() to escape attribute values that aren't guaranteed to be safe (like integers that you've just calculated). Reduces the nasty-mistake potential.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org