!require has no effect on input width

[jabowery]

Load this with ?log=1 and note #query[width] has a value of 0.

<span id="spanner"></span>  
<input id="query"  type="text" value="" />
<style type="text/gss">
        @h (#spanner)(#query) in(::window) ; 
        #query[width] > 100 !require;
</style>

[hfossli]

Isn't this underconstrained? Can't the width be any value above 100?

[jabowery]

Yes. However it ends up being 0 which is below 100.

I deliberately minimized the amount of code for the bug report. The original code is "under" constrained only in the sense that virtually all constraint programming is under-constrained precisely so it can be adaptive.

[hfossli]

Would you rather have the value to be 100000000 or 2725152848 or 28171? It won't choose 100 unless you add

#query[width] == 0 !weak

[Inviz]

Try >= ?

[hfossli]

🙌

[jabowery]

I revised the bug report to include in(::window) (which was in the original code that I simplified for the bug report). Perhaps this will avoid the confusion over the notion of "underconstrained".

Note that this does provide the engine with an upper bounds on #query[width] when ::window[left] == #spanner[right] == #query[left] == 0

[Inviz]

your vfl is not bound to edges of the window. in(::window) dows nothing in this case. Use vertical pipes at the boundaries

[jabowery]

@h (#spanner)(#query)| in(::window); didn't work.
@h |(#spanner)(#query)| in(::window); didn't work.
@h |(#spanner)(#query)|; didn't work.
@h (#spanner)(#query) in(::window)|; kind of worked except it disabled the ?log=1 URL debugging argument.

I saw nothing in the vfl documentation permitting the last syntax that (kind of) worked.

Am I looking in the wrong place for vfl syntax?

Does the absence of debugging despite the presence of ?log=1 rise to the level of a bug?

[Inviz]

first two are correct. Make sure you get GSS to know width of your elements (by constraining them or binding them to intrinsic width).

[jabowery]

Thanks for clarifying your suggested work around. However, prior to filing this bug report, I had already found a number of workarounds.

Even your workaround is inadequate (or is still insufficiently clear). For example, the phrase "know the width" is either inconsistent with constraint programming (permitting a range of values doesn't specify the value and is the entire point of constraint programming) or, if "know" means "know both the upper and lower bound", this should work with or without the vertical bar and/or the in(::window):

@h  (#spanner)(#query)|  in(::window); 
        #query[width] > 100 !require;
        #query[width] < ::window[width];

A glossary is needed in the GSS documentation. "Determined" (or the more pedantic "critically constrained") clearly denotes constraint to a single value. "Underconstrained" apparently means something other than "unconstrained on at least one of the two bounds". "Adequately Constrained" is unclear since it doesn't mean "known upper and lower bounds". Moreover, the normal use case for constraint programming, which is "Adequately Constrained", whatever that means, with upper bound > lower bound, apparently has no technical term at all -- unless one uses the awkward phrase "adequately constrained but not determined".

[Inviz]

> and < do not apply constraints actually, I believe. So try >= and <=. Something like this:

#query[width] <= ::window[width] ;
#query[width] >= 100;
#query[width] == 100 !weak; // which to prefer - smaller or bigger by default
#spanner[width] >= 0; // dont let spanner subtly collapse to negative width