[Clipart] new site design in progress

[Jonadab the Unsightly One]

Bryce Harrington <bryce at bryceharrington.com> writes:

> Do you need javascript for a form that allows adding additional keyword
> lines?  I think I've got an example kicking around...

If you have Javascript that inserts additional form elements, that
would be nearly ideal.  What I do have (see submit-compact.inc in CVS;
this is not currently in use anywhere on the site because I've not
tested it adequately yet) is a version that just uses one field and
adds more keywords separated by commas; that's better than what I had
before (which is currently still in use on the site), so at minimum
I'll eventually move the upload forms to that, once I get it tested
and stuff, unless you have something better -- such as Javascript that
actually inserts additional form elements.

> Some other comments...  in the file types, can you make the values all
> of consistent case?  Currently some are all caps, others are lower.  

The reasoning I was using went something like this...  the ones that
are ALL CAPS are filetypes that are traditionally spelled that way,
for one reason or another.  (PNG and SVG are acronyms, for example; I
have no idea why ZIP is traditionally spelled in ALL CAPS, but it has
been since the days of PKZip 2.04).  Others, such as "tarball", would
feel very wrong in all-uppercase.

I have no objection per se to making it more consistent, though.
Should I make them all lowercase, including s/PNG/png/ and s/SVG/svg/?

> Also, another idea to kick around...  Javascript can be externally
> referenced like css files, which could allow the client to cache them.
> For js that doesn't change very often, that could save bandwidth and
> performance, so if you can think of ways to put large chunks of the
> needed code into separate .js files, that would be worthwhile -
> especially for anything that goes on the front page.

Javascript pulled in from external .js files has to be referenced from
within the HTML head element in order to work in a decently
cross-browser fashion.  (That's also the only reliable way to have
global variables (which fortunately we don't need).)  The entire head
element is part of shell.php, however, so we can't _easily_ include
things there that most of the site doesn't use.  I could modify
OpenClipart::Web to make additional substitutions into the shell (it
already substitutes in a title, if you specify one, into the title
element), but if we go very far in that direction we may just about as
well ditch the one-big-fat-shell approach entirely and go to a more
flexible approach, such as separate (wellformed XML snippet) includes
for the stylesheet/icon links, logo/header, navbar/menu, and footer.

For now, I think the approach we have is mostly working.  In
submit-compact.inc the Javascript is only 116 bytes in a single
onchange attribute, so it really doesn't seem necessary to break that
out to a separate file.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/