Sometimes, ads or some huge images never finish loading, but we can already run our stats pretty acurately. How long are we ready to wait?

Create tests for verifying that values are kept as declared, currently -webkit-linear-gradient is getting broken into three separate values.

http://chromeexperiments.com should show more than 57 elements in Chrome, where the shadow dom works. It should continue to report 53 in Edge where nothing shows up.

This one will be a bit more difficult as some attrs we may want to keep everything, others we may not. That said, to start let's just fetch everything within the quotes.

I have the following code in htmlUsage.js:

  // If the browser doesn't recognize the element - throw it away
    if(element instanceof HTMLUnknownElement) {
        return;
    }

This is not currently working and we need to figure out a way to make it so that we don't keep tags that aren't natively supported by the parser. Assigning to @arronei to look into this ASAP. For the time being if you could provide me with an array of specified HTML tags and we'll scope our current dataset to that until the script is updated.

$ <int> px$ <int> can be seen on the width prop

This is bad and probably contributing to our massive file size:

{
                    "name": "url%%0--%e%d%a%csvg%version%d%%%id%d%laag_%%xmlns%d%http%a%f%fwww.w0.org%f%fsvg%%xmlns%axlink%d%http%a%f%fwww.w0.org%f%fxlink%%x%d%px%%y%d%px%%d%a%%viewbox%d%%%%%%enable-background%d%new%%%%%%xml%aspace%d%preserve%%e%d%a%cg%e%d%a%%cg%e%d%a%%%cpolygon%fill%d%%aa%%points%d%%c%%c%%c%%c%%c%%c%%c%%c%%d%a%%%%c%%c%%%%%f%e%d%a%%%cpolygon%fill%d%%aa%%points%d%%c%%c%%c%%c%%c%%c%%c%%c%%d%a%%%%c%%c%%%%%f%e%d%a%%%cpolygon%fill%d%%aa%%points%d%%c%%c%%c%%c%%c%%c%%c%%d%a%%%%c%%c%%c%%%%%f%e%d%a%%c%fg%e%d%a%%cpath%fill%d%%aa%%d%d%m%cl%cc%c0.0%c0.0%cl0.0c0.0.0.0.0.0%d%a%%l0.0c0.0%c0.0%c0.0l%cc%c%c%c%c%cz%%f%e%d%a%c%fg%e%d%a%c%fsvg%e%d%a)",
                    "percentage": 0.005457621568520439,
                    "count": 1,
                    "values": [],
                    "trend": [
                        {
                            "Browser": null,
                            "UAString": null,
                            "date": "11/16/2015",
                            "percentage": 0.005457621568520439,
                            "count": 1
                        }
                    ]
                },
                {
                    "name": "url%%0--%e%d%a%csvg%version%d%%%id%d%laag_%%xmlns%d%http%a%f%fwww.w0.org%f%fsvg%%xmlns%axlink%d%http%a%f%fwww.w0.org%f%fxlink%%x%d%px%%y%d%px%%d%a%%viewbox%d%%%%%%enable-background%d%new%%%%%%xml%aspace%d%preserve%%e%d%a%cg%e%d%a%%cg%e%d%a%%%cpolygon%fill%d%%d%%points%d%%c%%c%%c%%c%%%%%f%e%d%a%%%cpolygon%fill%d%%d%%points%d%%c%%c%%c%%c%%%%%f%e%d%a%%%cpolygon%fill%d%%d%%points%d%%c%%c%%c%%c%%%%%f%e%d%a%%c%fg%e%d%a%c%fg%e%d%a%c%fsvg%e%d%a)",
                    "percentage": 0.005457621568520439,
                    "count": 1,
                    "values": [],
                    "trend": [
                        {
                            "Browser": null,
                            "UAString": null,
                            "date": "11/16/2015",
                            "percentage": 0.005457621568520439,
                            "count": 1
                        }
                    ]
                }

We need any backround image value to result in unit or url, somehow these urls are passing through.

The following shouldn't live on the walker but should live on CSS Usage object

amountOfInlineStyles: 0,
amountOfSelectorsUnused: 0,
amountOfSelectors: 0,

Currently, css variables are not being tracked. We should change the way we list properties so we can track those accurately. We also want all custom properties to be aggregated independently of their real name, which require a new normalization.

In order for easier mass aggregation, convert the json to a flat hierarchy TSV, such as:

TimeStamp    UA    URL    1    2    3    4

This would result in something like this:

10/22/2015 13:18    <UA String>    <URL>    CSS    Props    font-size    count        5
10/22/2015 13:18    <UA String>    <URL>    CSS    Props    font-size    values    em    1

On the font family usage page, you can see Unicode replacement character (��, �S, �o��, etc.) under "Distribution of popular font-family values" section -> "Show More"->the line after "oswald". Does this indicate that the crawler doesn't understand some Unicode encoding on the web pages?

I don't have access to assign issues, but this one is for me.

Index page

• Update to Basel style graphs/charts
• Show property rank in bar chart

Individual property usage page

• Update to Basel style graphs/charts
• Need unlinked URLs on property view (top 10) and a link out to full list
• Alexa # next to URL (Bing one privately)
• [inappropriate URL](Show URL) <— maybe? legal implications?
• Future: show that one of your scanned sites uses the property
• Reduce rank section: put it up next to title, link to all properties somewhere for context?
• Call out current % and number of sites
• Flip trend graph by percentage or #
• Instead of current comparison implementation, search for properties to add them to a graph as their own lines. Use a select box to show this comparison data for all browsers or one browser at a time.
• Values section: add “All” column to table (last column?), nix the duplicative pie chart
• Page order: property trend, values, value trend, URLs

 // If the browser doesn't recognize the element - throw it away
 if(element instanceof HTMLUnknownElement) {
       return;
   }

Currently I'm throwing away unsupported elements as it results in all kinds of mess, but we should convert this to only elements that are in the HTML or SVG namespaces.

This is similar to the other, but we are getting some issues, below:

 "-webkit-gradient(linear",
 "name": "from",
 "name": "to)",

Please add unit tests for all of these.

Property Values may map to more than 100% if more than one value is included in a property, that is fine, but in this case it happens as we count some values which actually never end up in the DOM because of a lower specificity. We should fix this.

There has been a desire for us to be able to track alongside what the browser actually utilized. While this will give us the given the winner's results, it will result in expected values for units ,colors, etc; thus vastly narrowing the results but it will be beneficial to know what was actually utilized for values rather than what potentially would have been used. I think the biggest benefits here would be areas like display and other keyword/function props. One thing I do NOT want is for us to implement our own cascade, I would rather us go after a standard proposal to get that data into the OM so that we are only aggregating what the actual engine is doing, this surfaces the interop differences that we care about. The more we do ourselves the less the engine is doing, and we don't want that.

The "padding" property shows up in cases where browsers cannot unfold to longhands.
We have the data for the longhands; we should use that to "build" the shorthand data...

When importing into PowerBI, there are no columns. We can do a partial definition (since we can't name all columns due to the ability to make custom recipes) by just adding the default names of columns to the first line.

It should look something like:
Browser, UA Hash, Url, Timestamp, (blank), Logging Source, Recipe Name, (blank for the rest since it's keys and values)

calc(%

This value can be seen on the width property and shows we have a little bit more cleanup needed on the calc() parsing.

Since we'll be determining the basic selector structure for libs, let's take this a step further for property investigations and keep a generic string of the selector, here are a few examples:

#header nav ul.open      --->     #id nav ul.class
tbody:hover td                --->    tbody:hover td
.main .firstParagraph     --->    .class .class

If you want to do hashing or whatever that's fine, but combining the props with the selectors that enacted them would solve an investigation that I had to do recently for padding on tbody. Basically, in any area that the developer gets to declare their own name for something, we should use a generic term, but if it is a standards selector (~, *, tbody, :hover) then we should leave it alone.

Currently the way that that script works, we do indeed get the animation information, but we can't detail how often it was used since the selectText is undefined and we can't query the DOM from this. Due to this, we have need to setup a two pass setup where we keep track of the animation name and the keyframes that manage said animation. Then determine if the animation-name was used and then attribute the styles found inside of the keyframes to the properties and values declared within.

Currently we are creating data and then removing it later. We should make the processing steps less coupled so that we aren't duplicating data to delete later.

Found this while writing the roll up: {"name":"roboto","count":0}

During the CSSWG discussing I looked at this data and for some reason Chrome isn't reporting repeat the shorthand while Edge is. Take a look into why and possibly file a bug if necessary.

Currently finder will take JSON and stringify and just appends it in the file. This makes it so that there is cleanup necessary to iterate over the results. You should be able to stringify and append in a manner that maintains the JSON.

This is for the "Scan your own site" piece, so it isn't high pri but should be easy to add. Just add another collection where we track which selectors are NOT used on the page and keep the actual selector for usage in the report.

• getClie
• getCookie
• GetVie
• getBoundingClie
• getFlashDPCookie
• Download the clie
• get_wp_revie
• getEntrie
• geTileVie
• getting marrie
• getXMLHttpClie
• getFie
• get with my husband to look at what craft supplie
• Don't look in head tags
• Ensure that it is visible (doesn't have display: none, opacity: 0, visibility: hidden etc)
• get Toys Pusheen Bags of Holding Math Vie

Now that we're running on our "own" we need to provide the data that was provided originally via the other crawler.