You basically need two nested loops. Read all you CSS file names and search each of them in the HTML files, or, the other way around, look for code for CSS files into your HTML files, mark any CSS file used and at the end unused CSS files will not be marked.

You can save quite a bit of runtime if you store your CSS file names in a hash aat the beginning, because you can replace the inner loop by a hash lookup, which is far faster if the number of CSS files is large.

open my $filehandle, '<', $filepath or die "could not open '$filepath': $!";

while ( my $line = <$filehandle> ) { # note the below two lines could be handled more efficiently in a testaction, which # returns a true or false value to indicate if last etc, because its unnecessary to check # for every line. my @operations = grep { not $_->{done} } @{$filedef->{operations}}; last unless @operations;

I fail to see the relation between what you asked for in your original post and the code you posted. They are at best very remotely connected.

My second point is that if you're a beginner, then you most probably did not write the code you posted, and you probably also don't understand it.

So my question is: do you need a program that does what you asked for in the OP, or do you need to update the program you posted so that it does what you are looking for? The answer to this question would lead to entirely different solution.

I helped you write that code in this thread. In this case you want to add a specific test that tests if a css property is used. You could certainly figure out a way to implement this test in that code, but thats a separate problem.

I suggest you use a set of established modules to take care of parsing the css, converting selectors to xpaths, then testing if a property exists. I have had a play around and came up with the following standalone demo designed to process a single set of html and corresponding css:

Code

use strict; use warnings; use CSS; use HTML::Selector::XPath 'selector_to_xpath'; use HTML::TreeBuilder::XPath; use Data::Dumper;

This is just an example, in which the __DATA__ sections represent two different files, an HTML file and a CSS file. In your real case, you need to open these files and read their contents into the appropriate variables.

The demo I provided main purpose was to show you the three HTML/CSS modules working together, roughly in the manner you need. Accomplishing your actual task will take more than just switching input sources. When I get a moment I'll write a more concise demo, though there are a few unknowns from your original description that make it difficult to know exactly what you need.

- It has been designed with efficiency in mind. I ensure it only parses each file once, and selectors are not converted to xpaths if the selector has already been seen. But I decided against holding a tree for every html document in memory before iterating over selectors.

- CSS provides a read_file method but 1) the documentation is wrong, multiple css files should be provided as an array reference, 2) the object doesn't associate selectors with files.

- I have tried to keep the output data as informative as possible, it contains anything I thought could be relevant. As a result it is quite intricate. Importantly, if key xpath value is undefined then HTML::Selector::XPath wasn't able to convert the selector, and if key html doesn't exist then the selector doesn't exist in any of the html documents. You should simplify the output data as per your actual needs.

Code

use strict; use warnings; use CSS; use HTML::Selector::XPath 'selector_to_xpath'; use HTML::TreeBuilder::XPath; use Data::Dumper;

One of your CSS files is syntaxically invalid and the parser doesn't know how to handle it. Your options are:

- manually correct the mistake in the CSS file. - use a different parser such as CSS::Parse::Heavy ( see documentation for CSS ), it may be more forgiving. - override CSS::Parse::Lite's parse_string method to skip the iteration instead of croaking, though you run the risk of masking a cascade of problems.

1) http://www.w3schools.com/xsl/xpath_intro.asp. Xpaths are used to navigate xml type documents. An xpath represents a path to a single or set of elements. Its much like a CSS selector, but has support for other complexities, In your case, we are converting selectors to xpaths so that we can navigate the html document and check if the element(s) exist. xpath is in the output data structure because we generate them in the first iteration group ( css ), then actually use them in the second iteration group ( html ) as this is most efficient. Feel free to delete it afterwards.

2) Yes, as mentioned in my previous post, you should simplify the data structure to suit your needs. The information you request is already part of the current data structure, but perhaps not laid our how you expect. Also, be careful with terminology, don't mix selector with class. If you really are only interested in selectors that lead to classes ( direct or indirect ), you can use CSS::Selector::Parser, and check that the last array of the last array has a class atrribute. Currently the code has no knowledge of specific types of element.

3) In the $input hash, you can modify the list of properties, currently there are two, margin and width.