Re: [w3c/FileAPI] Define WebKit's underlying file changes behavior (#47)

> I was assuming "clips" means that if the new size is larger, the previous (smaller) size is used, so the results appear clipped; i.e. the byte size of the result matches the initial file.size seen. So that's not the case in non-WebKit?

You assumed right, and only WebKit does that. (I previously said all browsers did that, but I was deceived by a wrong testcase that uses `file.slice()`, sorry.)

>What if the new size is smaller? i.e. does the result have the smaller size, or are padding bytes seen?

WebKit returns smaller sized results (as seen in `assert_less_than_equal`). I wonder whether the padding bytes would break anything.

>Is the string clipped or are the bytes clipped before decoding? i.e. for text() and friends, if the string ends with an incomplete UTF-8 sequence, do we see U+FFFD at the end? I'm going to guess yes, but we should test.

Bytes, and yes, U+FFFD per the "replacement" behavior of decoding.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/47#issuecomment-1133179325
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/issues/47/1133179325@github.com>