i cannot comment without a link to the site in question

have you checked the wppizza/logs directory for any error logs in there (or indeed your debug.log provided you enabled debug)

in fact, it might even work by simply dequeueing the jquery-ui-[selected_style]-css and rerequeing it with a lower priority so it gets loaded before any of your other stylesheets so those (i.e your datepicker) simply overwrite the set styles
without having to check for post_id’s and whatnot

mileage will vary. really depends on what the other styles do

>On the settings page
I assume you are referring to the *order* settings page

>Can each menu item specify whether a delivery charge will be applied or not?
not natively in the plugin, however, there is the following filter you could use to substract the delivery charge if a particular item (let’s say with id 5) is in the cart
I also assume you are using “Delivery Charges per item” in the settings here

So, something like this (not tested, mileage will vary, but should give you an idea):

add_filter('wppizza_fltr_delivery_charges', 'my_prefix_delivery_charges_filter', 10, 3);
function my_prefix_delivery_charges_filter($delivery_charges, $cart_items, $general_parameters){
	global $wppizza_options;
	/* current set delivery charges per item */
	$dcpi = $wppizza_options['order_settings']['delivery_charge_per_item'];
	
	$reduce_delivery_charges = 0;
	foreach($cart_items as $items){
		foreach($items as $item){
			if($item['post_id'] == 5 ){
				$reduce_delivery_charges += $dcpi;	
			}
		}
	}

	/* substract */
	$delivery_charges = $delivery_charges-$reduce_delivery_charges;

return $delivery_charges;	
}

of course dequeueing things (or similar) on pages that – one day perhaps – have datepickers and spinners on them will break things

sure, if you want to style ui-elements with your own css instead of taking advantage of the themeroller css options, you’ll spend a lot of time doing this and – in my book – is a complete waste of time as not only are you trying to re-invent the wheel but also have to know each and every class etc etc that ui-elements use whereas if you use what exists you can sinply forget about all of that

you dont even have to know what the classes are and don’t have to ever worry about updating anything when versions or whatnot change.
For example, currently wordpress uses 1.11. One day wordpress will probably be using 1.12 or higher. If you use your own css, you’ll have to maintain it.
Do you really want to waste your time checking for this every time there might be an update to something ?

you already know this from what i can make out…?!
http://jqueryui.com/download/#!version=1.11.4

>switching the option off only disables the style and not the JS
that is correct. there is an awful lot of functionality attached to this spinner ui element which would not work if the js is not loaded

that option already exists by not including/enabling the themeroller css and adding your own css for the spinner (presumably from copying it when creating your own themeroller css) somewhere

>This is happening because the plugin loads its styles on all pages instead of loading it on pages where it is used.
that’s simply not true
it’s caused by including the themeroller style – the inclusion of which was made optional for precisely the reason that if themes already include styling for jquery ui-elements it won’t be needed

alas – from what i can see – your theme does not actually provide any styling for ui elements and it is the gdlr-hotel plugin that provides and styles the datepicker using it’s own style but only for the datepicker.

furthermore – though somewhat unrelated – the wppizza.css only ever targets it’s own distinct elements and only where strictly necessary. Wherever possible and sensible it will try to use a themes’ style

lastly, using an equivalent of “is_woocommerce” would do no such thing as it would also not load any styles on the checkout pages or in fact any page that shows the wppizza menu items or any wppizza widgets, shortcodes etc etc
(the overheads of checking a page content/sidebar to see if a particular widget/shortcode/whatnot is used are quite high and one would have to do that for every single pagecall. one of the reasons why woo doesn’t do that either one suspects)