Re: Tests for Encoding spec

On Mon, Oct 19, 2015 at 5:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Oct 19, 2015 at 2:03 PM, Richard Ishida <ishida@w3.org> wrote:
> > 1. i'd be happy to change the mechanism for identifying the output of
> > encoding if i knew how.  The problem, it seems to me, with generating
> form
> > submissions is that if you are not looking at the percent escapes
> themselves
> > (ie. comparing within the document, by which time the form submission
> > parameter has been converted to Unicode) you are reliant on decoding to
> work
> > for encoding results to be reliable.  It's ok to check the odd character
> > visually by checking the web address bar, but how to do that for tens of
> > thousands of characters?  I'd be very happy to know if you have a
> > suggestion.
>
> If you use application/x-www-form-urlencoded (the default) there will
> be no Unicode involved. Just percent-encoded bytes. So if you have
> something on the server that doesn't decode for you, you should be
> able to get at the raw bytes the browser used to encode.
>
>
>
Richard, you can look at what Blink/Webkit's layout tests handle this issue:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/fast/encoding/char-encoding.html

The test only checks only a handful of code points, but I guess it can be
expanded to cover all the code points. Anyway, it can be a starting point.



> > 2. i suspect that its' actually important for the mechanism of
> converting to
> > href values to work too, so i think that this may still be something that
> > needs fixing.  If what goes into the href value is not what the user
> > expected, then that is presumably problematic.
>
> Yeah, both should definitely work in the end. Everything needs to
> become predictable for developers.
>

I agree. After sending my last email, I took a look at Richard's test and
found that out. I'll find out where href got wrong in Chrome and try to
fix.

Jungshik



>
>
> --
> https://annevankesteren.nl/
>