I will use the size as the example option. With the size where does the price come from? Is the price of the item only based on the size, or does the size add to the price of the item? Also, are you storing the price that goes along with the size in your size table? I'm curious about this info because I want to help you come up with a strategy that you will understand and that works well for you so that you can get this implemented the way you need it to be.
If the size is stored with the price and this is the price of the item for that size then you would have a size select list with the size as the label, and the id as the value. When the user selects the size and adds the item to the cart you will have another size recordset on the page that is filtered by the size the user selected. This second size recordset is the key, if you can filter the recordset for the size that the user selected you can get back all of the other info for that record including the price to charge.
You can then make use of price that comes from this recordset directly in your add to cart server behavior along with the size itself. So this way a user makes a single size selection when adding the item to the cart and you can get back multiple values for that size including the price, so there is no need for the user to make multiple selections for the same item. This is also a more secure method that storing the price in a form element or select list, if it is in a form element of any type a crafty user could alter the code on the page before it is submitted or with javascript to alter the price of the item. If you are getting the price from a record in your db you can eliminate this possibility.
Please post back with some more info about your setup and how it is going to work and include any questions about any part that was mentioned here.