<issue_start><issue_comment>Title: RGBA_S3TC_DXT1 is not opaque, and its black is 0,0,0,0.
username_0: 
<issue_comment>username_0: https://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt
<issue_comment>username_1: Kai and I looked at the spec, actually if we pass all 0 array buffers as the input of TexImage calls for s3tc, the alpha is 1, not 0.  According to WebGL1's spec in TexImage(data==null), this is the expected behavior.

I can understand that's anti-intuitive as people would expect data to be initialized to (0, 0, 0, 0).  We can definitely discuss and clarify this corner case behavior.  However, at this point, this test's behavior is arguably spec conformant, and chrome conforms to this test.  If we all agree to change the spec, then at least the 2.0.0 snapshot needs to allow both behaviors for chrome's WebGL2 to pass conformance.
<issue_comment>username_2: Initializing to (0,0,0,1) is a deliberate choice by the ARB to help developers see when they have made a mistake, i.e. that the texture is uninitialized.
<issue_comment>username_0: Please detail where it dictates this in the spec.
<issue_comment>username_1: The alpha component for a texel at location (x,y) in the block is
        given by:

            0.0,               if color0 <= color1 and code(x,y) == 3
            1.0,               otherwise
<issue_comment>username_2: Thanks @username_1.
<issue_comment>username_0: Alright, we fixed our behavior. We had an optimization for uninitialized textures that was yielding the wrong black type. With this useless optimization gone for other reasons (textureSize!), this is now passing.