The purpose of this PR is to validate "srcset ranges." A srcset
"range" is defined by it's begin, end, and tol.
If tol is less than 0.01 (one percent) then it is invalid.
If begin > end, then begin is invalid.
No restrictions have been explicitly applied to end; this is to
allow for flexibility when the maximum end is greater than 8192.
This PR also seeks to establish validation/error semantics for srcsets.
The question to be answered here in review is:
Is this a sensible way of handling invalid input?
Doing things this way means we do not have to throw exceptions. The
rationale is this:
alert callers to an error state without affecting global process state
For instance, it seems likely that callers would rather deal with missing
images and empty srcset strings than with an exception that crashes
an app.
In short, an empty string means our code doesn't "pretend" things are
okay while failing gracefully within a larger application.
Update:
After some discussion, we have chosen to throw exceptions in these
exceptional cases. I am closing this PR and reopening another that
reflects this decision.
After some discussion, we have chosen to throw exceptions in these
exceptional cases. I am closing this PR and reopening another that
reflects this decision.
The purpose of this PR is to validate "srcset ranges." A srcset "range" is defined by it's
begin
,end
, andtol
.If
tol
is less than0.01
(one percent) then it is invalid.If
begin > end
, thenbegin
is invalid.No restrictions have been explicitly applied to
end
; this is to allow for flexibility when the maximumend
is greater than 8192.This PR also seeks to establish validation/error semantics for srcsets. The question to be answered here in review is:
Is this a sensible way of handling invalid input?
Doing things this way means we do not have to throw exceptions. The rationale is this:
For instance, it seems likely that callers would rather deal with missing images and empty srcset strings than with an exception that crashes an app.
In short, an empty string means our code doesn't "pretend" things are okay while failing gracefully within a larger application.
Update: After some discussion, we have chosen to
throw
exceptions in these exceptional cases. I am closing this PR and reopening another that reflects this decision.