On Sun, Apr 06, 2008 at 07:01:52PM +0000, corvid wrote:

Jorge wrote:

...

On Sun, Apr 06, 2008 at 05:07:30AM +0000, corvid wrote:

...

I took a better look at the RFC and it looks like I am wrong.

I naively assumed that since it's been on the acid site for however many years, somebody would have complained if it wasn't right, and I took relatively little care in rfc-checking.

On the other hand, I am coming to learn that RFCs are not perfectly perfect things.

The relevant RFC text: The appearance of ";base64" means that the data is encoded as base64. Without ";base64", the data (as a sequence of octets) is represented using ASCII encoding for octets inside the range of safe URL characters and using the standard %xx hex encoding of URLs for octets outside that range.

http://www.webstandards.org/action/acid2/guide/ says of the square: Also, there is a 64px by 64px red box in the background (represented by the PNG image in the data url, not reprinted in full). The red box is not visible as the background-attachment is set to 'fixed' which puts the red box outside of view.

(as opposed to saying that it's supposed to break or something)

Which in what regards to the patch, means?

a) keep b) revert

- To me, a strict reading of the RFC says revert.

- I see that http://developer.mozilla.org/en/docs/The_data_URL_scheme gives their base64 example as "data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D"

- At http://simonwillison.net/2003/Aug/11/selfContained/ Simon Proctor claimed that Mozilla didn't like the URL encoding, and Ian Hickson asserted that it was necessary.

- Ian Hickson would appear to be the guy who wrote the "data: URI kitchen" (http://software.hixie.ch/utilities/cgi/data/data), which is apparently the main datauri-maker that people use, as well as being the guy who wrote the acid2 test.

On one hand, this means that dillo will encounter the URL encoding.

On the other hand, if Hickson has any actual persuasive argument for his viewpoint, I have not found it.

OK, reverted. -- Cheers Jorge.-