Bug 23935 - Proposal: New syntax for constraints

I prefer the current syntax.  It is more compact and makes back-off easier.  Furthermore, it makes the semantics of 'best effort' values like min/max/mid easy to understand, at least in the case of optional constraints.  Suppose we have optional constraints  "prop1 max, prop2 max, prop3 max".  This would  mean:  set prop1 to the largest value you can, the set prop2 to the largest value you can without changing prop1, then set prop3 to the largest value you can get without changing  prop1 or prop2.  The ordering of the constraints specifies the ordering of the optimizations.

The use of max/min/mid in mandatory constraints is trickier, because mandatory constraints are unordered.  But  it's not clear that these values are useful in mandatory constraints, given that  their semantics has to be something like:  any value that the UA picks satisfies the constraint, but the UA SHOULD pick the largest/smallest/middlingist value that it can find.  So in mandatory constraints max/min/mid will never fail, and the app won't be able  to control the order in which they are applied (that's  up to the UA).   It's harmless to use these values in mandatory constraints, but sophisticated developers will realize that they work better as optional constraints.


-          Jim