|
|
Posted by shimmyshack on 02/17/07 00:58
On Feb 16, 9:53 pm, dorayme <doraymeRidT...@optusnet.com.au> wrote:
> In article
> <1171622169.646616.165...@k78g2000cwa.googlegroups.com>,
> "Andy Dingley" <ding...@codesmiths.com> wrote:
>
> > On 16 Feb, 03:09, dorayme <doraymeRidT...@optusnet.com.au> wrote:
>
> > > This is very easy technically. This is what I do: search for
> > > instances of ids and classes in the html files by using Search
> > > and Replace functions that come with any decent text editor.
>
> > That sounds like hard work!
>
> Oh well, perhaps there are things I am missing. But I suspect -
> perhaps unfairly - that there is a Force of Unnecessary
> Complexity secretly acting on earthlings.
>
> I have done these things without much work at all, see my
> previous reply.
>
> Perhaps I need to explain more? The OP had a problem we all
> confront. Simple enough in most cases no matter how big the site.
>
> Suppose you want to know if a #navMonday css instruction can be
> safely removed from your CSS sheets. All you have to do is search
> for ' id="navMonday" ' over the folder that contains all the
> website files. It is a button press. What is hard about it? If
> the search comes up with nothing, you search for '#navMonday' and
> all instances in your css will show up and you delete them by
> hand because they are there at your fingertips (see my previous
> post). You can, when you get good at the S & R function be a
> little cleverer and get any class (as well as or instead of id)
> of this name. You can replace instances with nothing and so fix
> all up automatically. But for most situations it is so quick and
> easy, why bother your head, it is the finding not the deleting
> that takes time. I doubt many would need fancy doodle perling and
> reg exping and generally tooling about in some macho V8 flexing
> about...
>
> Come on guys, get real!
>
> --
> dorayme
I understand your point, and for a site with a few hundred pages of
html and perhaps 200 classes, finding "orphaned" classes by hand would
be possible, if not tedious.
But if your site uses any kind of DOM manipulation, then even screen
scraping won't get you knowledge of what classes come into play.
Next time you're using gmail take a look at some of those XHR
responses, you will see not only JSON but also styles (albeit in an
unorthodox way!) pushing their way into the DOM.
Using a greasemonkey extension to parse the DOM for classes wouldnt be
very much harder than using an editor's regular expression feature,
you are essential writing a macro to be performed on every page
request, or at various states of the application.
However using greasemonkey would be require it to be installed on your
system, so just inserting the code into the main web app provides a
way to have your users check your site.
You could repeatedly audit your won site every month for broken links
or whatever by simply uncommenting a single line of javascript.
Although initially complex, the technique is scalable and very fast, I
used to use a similar script back in 2004 which ran on a major site I
wrote, if a user-agent came across a broken link, it would send the
data to my home webserver, which used COM to open and navigate IE to
the spot, and highlight the link. It was a headache to get it al up
and running, but I got a real buzz from mistakes in the site, and have
been in love with weird solutions like this ever since! (I used to
play with dreamweavers site search and replace regular expression
feature until it corrupted that site in the odd place here and their,
since then it is more fun and admittedly more painful to write my own
solution and at least then if it fails I can own it!)
glad you didnt take offence!,m
Navigation:
[Reply to this message]
|