Audit: new dom nodes table is confusing

[ebidel]

I'm not sure what the last line is telling me. It's identified two nodes, but they're not explained or lined up to anything.

[paulirish]

cc @hwikyounglee for ideas

[exterkamp]

I started to experiment on this a bit here.

The table now has three columns: Category, Element, and Count. I also parse down the element snippet to be only the HTML element type + the id or class and drop every other attribute so that it doesn't get too large.

Thoughts?

[exterkamp]

Notes from meeting:

• left align leftmost column (see report details table right-alignment is ugly #6049 )
• remove top padding from lh-code elements
• trim all element snippets in report

@paulirish how do we want to trim HTML elements? Should it be additive or subtractive? I vote additive so we can only include what is necessary instead of trying to remove as much as possible. Right now the only things I keep are:

• id="..." || class="..."
• I know you mentioned keeping aria-*="..." elements as well

[paulirish]

@exterkamps ive only seen [style] be a problem. my concern is that we'll strip some attributes that are useful. [data-*] come to mind.
but there could be others.

if we are subtractive then there's a much smaller risk that we effed up and removed important data.
and i presume it's more straightforward see that we need to remove another attribute than for people to tell us that we've excluded an attribute they need to identify the element. 🤷‍♂️

[exterkamp]

That's fair, and easier to implement. I'll strip out just style=".*" tags then.

And did we want to make the stripping of snippets more generic, or put it into some lib/ file so that all snippets can use it? i.e. the accessibility snippets

[paulirish]

And did we want to make the stripping of snippets more generic, or put it into some lib/ file so that all snippets can use it? i.e. the accessibility snippets

yah good call.