- From: <bugzilla@jessica.w3.org>
- Date: Fri, 11 Oct 2013 15:24:20 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13154
--- Comment #24 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #23)
> > The problem with comma-delimited microsyntax for multiple values is that the
> > comma is a restricted character and so will be percent-encoded.
>
> Actually comma isn't percent-encoded,
It seems the specification and implementation do not always match :)
> ...but more importantly, a server should always apply the query-decoding
> logic, because there's nothing semantically different between
>
> http://example.com?a=A+
>
> ...and:
>
> http://example.com?%61=%41%20
>
>
Yes, the query or form data must always be decoded but introducing a new
microsyntax imposes a second phase of decoding. First doing the standard
decoding, then decoding the microsyntax.
The problem here is that the new microsyntax has no form of escaping, so the
encapsulated syntax is limited in its character set.
It would be better not to create a new over-the-wire syntax and just split
prior to encoding and use the syntax and escaping already available and
universally deployed and supported.
> > This makes deducing the individual entries a lot more difficult than if they
> > are already split before encoding, a new microsyntax must be incorporated
> > and decoded instead of just fetching a value by key from the query/form data
> > set.
>
> If you have the query/form data set already decoded such that you can just
> fetch its value, then it'll already be %-decoded, and you can just split on
> commas.
Exactly. There is another phase to being able to retrieve the values.
It is more difficult to perform 'deconstructive' techniques (parsing) rather
than 'constructive' techniques (collection building) over discrete items.
'Deconstruction' is a complex and error prone process, whereas it is
(virtually) impossible to create an in-memory collection of objects from
discrete items in error.
>
> > This problem is excaserbated when viewed with email (as oppsed to a purely
> > numeric range value) as example. I assume this might be one reason why the
> > email syntax has been restricted over the RFCs.
>
> Not sure what you mean here. Posting the form by e-mail would just have
> something like:
>
> range=1,54
>
> ...which seems quite readable to me.
>
>
Sorry, i wasn't referring to an email html client but to the <input
type="email" multiple> control.
Due to the complexity of the email syntax in RFC 5322 it would be impossible to
use conforming email addresses with the comma-delimited microsyntax for
multiple values. This must be the reason why RFC 5322 has a willful violation,
as otherwise it would be impossible to parse, and a far cry from doing a
simple:
String[] addresses = emails.split(",");
If this is the case, then it is a bad decision to violate RFC 5322 just in
order to construct a new comma-delimited microsyntax for over-the-wire encoding
when there is already a standard method with full support for doing so.
Why should some email addresses be un-submittable just to support sending
multiple email addresses as a single parameter?
The comma-delimination seems more apt to support an ability to create a
backwards-compatible text control which could be hacked by well informed
individuals such that they could still enter multiple email addresses into an
old browser and have them processed the same on the server. I think this is a
poor consideration for imposing a new microsyntax across the client-server
barrier. It is leaking a client implementation detail into the server.
> > The <input type="file" multiple> uses the same query/form encoding as
> > <select>, this a preferable standard approach. Can the same implementation
> > also be applied to 'range' and 'email'?
>
> type=file is a special case. It has hard-coded logic all over the place, it
> can't be set to a value when you create the form, and it generates
> attachments in the output. This is quite different from anything else and
> not really a model I think we should follow.
Sure type="file" is a strange anomalous case requiring lots of special logic,
but the <select> element also uses the same encoding model so it would seem
that type="email" is the anomalous example in this case.
The value representation (so setting initial 'range' handle positions) does
require some consideration. If the new microsyntax for value="" is limited in
scope to the client (one way server->client only) then it shouldn't pose any
problems. Constructing the 'range' HTML requires generating its specific syntax
already, so whatever value representation is chosen it still requires some
level of custom server-side code. I can't really think of a more concise
expression of the element's state, nor a better expression for being set from
within JS. (The best alternative being considered is the use of <option
value="" selected>).
But, forcing the value representation into query/form encoding is unnecessary,
doesn't introduce any gains over the encoding, and requires the server to have
prior knowledge of what element was used to capture the data. See on for the
examples.
>
> The other problem with using multiple values in the type=file style is what
> happens with cases like this:
>
> Choose the ranges you want to cover:
> <input name=ranges type=range multiple>
> <input name=ranges type=range multiple>
> <input name=ranges type=range multiple>
> <input name=ranges type=range multiple>
> (button to add more...)
>
> With the comma-based proposal, you end up with:
>
> ranges=1,4&ranges=6,9&rangles=14,44&ranges=80,90
>
> ...but with the type=file-style system you end up with:
>
>
> ranges=1&ranges=4&ranges=6&ranges=9&rangles=14&ranges=44&ranges=80&ranges=90
>
> ...which, while still _technically_ unambiguous, is much less obvious and
> easier to screw up.
The choice of param names is key here, there is nothing preventing or requiring
the use of that structure.
The power of the encoding model comes from being able to replace the example
above with:
<label>Enter 1st range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>
<label>Enter 2nd range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>
<label>Enter 3rd range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>
<label>Enter 4th range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>
Or with this:
<label>Enter 1st range:</label>
<select name=ranges required=2 multiple>
<option value=0>
...
<option value=100>
</select>
...
To me, that's pretty powerful UI.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 11 October 2013 15:24:25 UTC