@MikeW Now you have me confused. Your original flow showed problems with the </> Class option in the ui-button and ui-text-input nodes but now you are mentioning the 'textInputwidget. I'm not sure if @Jbudd jumping in talking about theTypedInput` widget may have confused you???
The TypedInput widget is a jQuery widget that can be used when someone is creating a node. It is used in the 'xxxx.html' file. The ui_text_input is a node-red dashboard widget. (This is another case where a term is being overused ('flow' is another example of an overused term)
This is something different from the </> Class option not being picked up.
This confusion could be resolved by making sure you use the name of the node. i.e. ui_text_input vrs TypedInput vrs 'TextInput'
The patch I created does fix some issues with the </> Class option in the ui_text_input node but I now see there are more issues. As for the ui_button widget, it has a 'color' and 'background' option in addition to the new </> Class option and they take precedence ovet the '</> Class' options. I did not attempt a fix for it.
@dceejay @Steve-Mcl
Looking at this again, I think the issue is with (1) how CSS works, (2) how the dashboard creates classes for the page, groups, cards and widgets (3) other options effecting CSS in existing widgets - like the 'color' and background options in the ui-button widget and (4) the addition of </> Class option to the dashboard widgets.
I understand the idea of the </> Class option (I was one of the peoplewanting it) is to provide an easy way to apply a change to a single instance of a ui-widget, but in some cases, it doesn't create a CSS selector that it specific enough to override other CSS selectors that are created. The dashboard theme options are taking precedence.
For example take the ui_text_input. There are the CSS selectors that apply are applied based on the dashboard theme style. Then there are other selctors that are applied when you start to type in data. However the </> Class option just uses the selector you enter which is no where nearly specific enough to override all the cases that apply.
I think the option has opened a can of worms that is going to cause users confusing until the dashboard is rewritten. Users who want to change the defaults are still going to have to use a browser inspector's tool to examng each widget they want to effect and write CSS selectors specific enough to address the area tehy want to change. You know, kind of like what they've been doing all along. 
