Product Ideas Portal

Ability to add a module from a CSS selector that has been previously created or from a new selector on the "Add Module: Capture Node" screen


Currently in AST we are unable to add a module from a CSS selector. 


Allowing us to add a module from a previously created CSS selector (from the Create a New Element Filter screen) will allow us to capture parts of pages (e.g headers/footers) and create new modules out of them. The functionality already exists to ignore nodes created in the Ignore Elements section of the Add Module: Capture Node, screen so hopefully this functionality can be recycled to create new modules from these same CSS nodes. Furthermore, it would be fantastic if on the Add Module: Capture Node screen, we could have the ability to add a module from a new CSS selector we find on the page. This way we don't have to rely on previously created nodes and can capture a new module from a new CSS selector right on this screen without having to first create a node.  This could use a CSS Selector field just like we have on the Create New Element Filter screen. 

 [Business Impact] 

It will take more time for testers to capture parts of pages and adding this fix will save testing time. In my experience capturing a module from with the Node Selector button does not always work as I tend to experience glitches with the green border not capturing the correct part of the page. This can be very time consuming and often takes a couple of tries to get right.  Using the DOM Selector button is more effective but depending on the length of the DOM, I often find this solution time consuming as well. I am a big fan of the CSS Selector field as this allows us to quickly capture sections of pages and even has a test feature that allows us to confirm that we have the correct section of the page selected. 

  • Jennifer Arango
  • Dec 3 2019
  • Needs Clarification
  • Attach files
  • Mitchell Evan commented
    5 Dec, 2019 04:39am

    Hi Zahra, I'm trying the "Search HTML" function in the AST DOM tree as you suggested. I see that it performs a case-sensitive filter of a text copy of the DOM tree and jumps to the first match. So you're right, I can search the DOM tree for a known id value, but this usually won't solve the problem because most nodes in most websites don't have ids.

    However, this gives me an idea...

    1. In the AST DOM tree, use "Search HTML" to find a longer substring of the DOM, such as <div role="presentation" class="ms-FocusZone css-97"
    2. Scroll through the AST DOM window to see if my substring is unique.

    Or (faster than scrolling)...

    1. In the AST DOM tree dialog, press Ctrl+F to find a substring of the DOM with browser search.

    I'll try these workarounds for a while when necessary, and I'll see if they help speed up node capture in the wild.

  • Admin
    Zahra Safavian commented
    5 Dec, 2019 03:17am

    Team, I agree this could be a great feature. A while back when the Element Filters were added to AST, I asked for this feature and it turns out it was more complicated than it seemed. I will check with the dev team again, but I suspect they will ask the same question I have in mind -- aside from personal preference, would this feature add functionality that the existing Search feature in the DOM tree does not have? For example, if you were using the browser's DOM inspector to find the element and capture the CSS selector, could you not use that to look up the element ID and search for it in the AST DOM tree UI? Any additional details you can provide will be helpful. Thanks!

  • Mitchell Evan commented
    3 Dec, 2019 11:25pm

    > on the Add Module: Capture Node screen, we could have the ability to add a module from a new CSS selector we find on the page


    This would be great. It's true AST already has node capture and DOM capture; however, I've sometimes spent 15+ minutes trying to traverse up the AST DOM tree in a complex page. It can be very tricky without the visual feedback of the page itself, and the AST DOM tree has a limited number of ancestors. In these cases it would be much faster for me to copy the CSS selector path from the browser's full DOM inspector. This enhancement would also reduce the pressure on our product team; rather than perfect all edge cases of complex node selection in AST, rely on the browser DOM inspector more.

  • Kevin Murphy commented
    3 Dec, 2019 09:27pm

    Tagging on to this: It would be also great to allow multiple elements in the DOM as the selector. Case in point if I wanted to capture both the footer and the DIV right above it in the DOM, there is no way to do that. But I could write a CSS query such as "#notreallyTheFooter, footer" and capture both. 



    content stuff goes here

    <div id="notreallyTheFooter">Quasi Footer</div>

    <footer>Real footer</footer>