|
|
|
| Perl: the Markov chain saw | |
| PerlMonks |
Comment on |
| ( #3333=superdoc: print w/ replies, xml ) | Need Help?? |
|
This node will only be of interest to pmdev.
This node summarizes the current modes of implementing web page style on PerlMonks. Some is done with CSS (attributes class and id), while some — entirely too much — is done using "hardcoded" stylistic controls such as <font size>, color and bgcolor. I did this research for the purpose of determining where more conversions to CSS should be done. Ultimately, we may find that not all "hardcoded" styles can be converted to CSS. For example, a few pages achieve special gradient effects by calculating and embedding color numbers. It may turn out that such color gradients will be acceptable in any user color scheme; or, perhaps, the "control" numbers (i.e. color start and end points in a gradient) can be opened up for customization in the user's Display Settings. The task of determining what code does it which way could be approached from two ends: we could search the code nodes for occurrences of the bgcolor (etc.) strings, or we could fetch actual web pages and parse them for such things. The former approach has two problems: attributes are not inserted in code in a consistent way (for example, we might find bgcolor='$color' or bgcolor = "#ff0000" or the CGI-style { -bgcolor => $bgcolor }); and more critically, there is tons of "dead code". Not only do we not care about what dead code has, but very often it is difficult or impossible to tell which of several variants is the "good" one. Therefore, I have taken the approach of fetching web pages, and parsing them for relevant attributes. Below is an index of all the nodes I used in this survey. (Please note — this is in no way an index of interesting posts! You will not find any PMDs or Meditations here! And for this purpose, "posts" includes pages in the PerlMonks FAQ and the Library.) Some node types (in particular, "posts" in the various sections, FAQ and Library) are guaranteed to have invariant format, so for those types we only need one example of each. Since the idea is to illustrate every displayable node format, we don't list nodes of "indirect" types, such as htmlcode. SuperDoc:Since every SuperDoc is unique, we list them all. (Actually, not quite all. I have excluded those to which I am not permitted access, and those which have null or broken content/functionality.) I have grouped them by functional style/role. Postable "Sections":
Mail:FullPage:
SectionContainer:SectionContainers are obsolete, but this one is interesting because it illustrates the use of the .paneled css class. Document:Documents do not have 'code', and the 'viewcode' displaytype does not work for them. AFAICT, there is no code (no dynamic content generation) behind any of these. In fact, most of the other displaytypes don't work for Document either. Therefore, these are listed for curiosity only; we couldn't fix them even if we found a problem. (Gods could, however.) We take one example of each of the following nodetypes: This list is instrumental in my ongoing work to convert the site to CSS. It serves as a test suite and a live running status of the changes made. As we make changes — often to htmlcode buried ten layers deep — we need a good way of determining that the appropriate changes are happening on the surface. At the same time, this suite tells us (or gives us a good idea, anyway) of what exactly remains to be done, with regard to replacing hard-coded stylings with CSS. For this endeavor, we need someone who understands html and css. I've got a pretty good (though far from perfect) handle on the code; but my comprehension of the subtleties of CSS is woefully inadequate. And when it comes to having a coherent web site "design", well... I'm a geek, not an artist. So here's how I plan to use this list. I'm going to suck down a copy of each page listed here, and grep through it for any css classes/ids used, as well as for any of the kind of markup we want to eliminate, i.e. hardcoded colors and the like (e.g. bgcolor, font). This tells us (a) what css elements we actually need to account for in the site css pages, and (b) what hardcoded stylings remain to be eliminated (replaced with css). We'll re-run this after each round of relevant patching. From the other side, someone needs to look at all the css nodes, and make a list of all the css classes/ids defined there, and do code searches for them. This is to build our understanding of how the site's design is currently structured; plus we'll be able to identify any styles defined but unused. Thirdly, someone needs to go to the theme nodes, and get a list of all theme "variables" defined, and find every occurrence of usage of them in (non-dead) code. This is mainly just to ensure that we don't let any fall through the cracks. Identifying which actually need to be replaced is accomplished by step 1, above. And fourthly and most importantly, someone with some sense of design and a pretty good understanding of css should define an overarching style "architecture" for the site. Ideally, we'd like to be able to make some fairly radical changes, e.g. make much less use of tables for layout.
Some relevant old PMD threads:
In the tables below, the first two list "all" occurrences of the attributes class, id, bgcolor, color, size, and style in the above list of pages. The "old" attributes (bgcolor, color, size, and style) are listed in the first table; the "new" attributes (class and id) are in the second. It's not really all, because I've excluded certain nodes which make heavy or obsequious use of color (e.g. color gradients) and other silliness which would be troublesome to reimplement in static CSS. These pages were completely excluded: notes tree, Modular Pascal's Triangle, user variables, User Settings2, Recently Active Threads Faqlet. As it is, not every node listed here really matters. For example, you can completely ignore root's default themesettings and note settings, as they are not used anywhere. Similarly, I've excluded certain CSS classes and IDs used by certain pages, such as the huge family of nnt-* classes/IDs used by Recently Active Threads, and (nearly) all generated classes/IDs, such as the node-from-* classes stuck on entries in Newest Nodes. This excluded content is shown in the tables at the very bottom. The first table shows what is still being implemented the old way. This represents work still ahead of us:This table shows what's already been implemented with CSS. In some sense, it represents the part of our job already done:Here's all the stuff that was skipped:
"many" means more than 70, which is about a third of the approx. 210 total nodes. settings from Themes:These are image file names:
These are colors:
Note: clr_highlight is still being used in colorblend (which is used in RAT by way of handle_threaded_nodes and in Big Pretty Nodelist)... but it's harmless because colorblend generates a <style> section assigning color rules to classes; it does not hard-code colors. Settings used in shownote:
To add the rule to the relevant CSS files, apply: (Recall that CSS patches require manual sync to static files.) Dark CSS already has the change. Once those are done, patch shownote to remove the use of $textbgcolor. In addition, shownote brings in the following from shownote settings:
vote settings has a bunch of html snippet crap: These are all used in voteit, which is used in a lot of places. Update: The above has been patched away. No more literal HTML in settings! Other useful info:
ar0n's homenodePetruchio's secret world...as demerphq called it, because it's largely his creation, and he's been living in this view almost exclusively ever since. He was hoping that it would be the basis for a new, cleaner Perlmonks. How does it work?The different look is achieved not simply through a different set of stylings. When the PerlMonks engine renders a node, it does so through a set of templates (specifically, htmlpages and containers). Petruchio created a new set of such templates. Then he inserted a run-time check in certain key places, so that whenever the domain name in the URL begins with "css", the engine uses his new templates to generate the HTML rather than the standard templates. No changes to index.pl (or any of the site's static engine code) were necessary. Thread: Re: Hilighting Newest Nodes 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567 1234567In reply to Restyling PerlMonks
by jdporter
|
|