Modify Rules is meant just for source editing so the bug actually is that it is enabled for the "dynamic nodes" -> html.navigator.

OTOH we could possibly do something similar also for the dynamic elements - via the webkit API (if possible - ccing Honzas). Although in such case the changes would be just temporary as not persisted anywhere. Do we need/want this?

But why can't I use this dialog box to define CSS rules for dynamically generated DOM elements? Why wouldn't they be persisted? Wouldn't we just be writing the CSS rule to file?

Primarily the "Modify Rules" action and the dialog is aimed for association of html element with existing css rule, either class or id. It adds class or id attribute to the element's source.

It can also create the rule in a selected stylesheet if it doesn't exist, but it will be empty and you need the RuleEditor to actually add content to the created rule. So for css rules creation I'd primarily use the RuleEditor.

So for the DOM-only elements there's no place where to store the class or id attributes and hence just a part (secondary) of the functionality would work.

Does that make some sense? I understand one may look at it from a different point of view and thus have expectations like you have.

Yes, I think it would still make sense to allow this, even if it's just for a part of the functionality. In that case, I guess the Selector field should be read-only. And one of the selector type may need to be disabled if either class or id are not present on the element.

BTW, in the scenario when I only want to create the rule without changing the element itself, I discovered bug 219016.

Should be done to 7.3 still, though this can hardly be considered as bug.

still works bad in 7.4 using DOM view - the action is enabled for dynamic elements, but then the changes are applied to the closest static element found.