Base64 as a src is a totally separate issue than what I’m talking about.

That will work with the current Image implementation as is on the HTML side. No 
modification necessary. I’m pretty sure the Flash implementation would need to 
convert the Base64.

As an aside:

Why are so many of the HTML classes imports wrapped in COMPILE::SWF blocks?

i.e.:

        COMPILE::SWF
        {
                import org.apache.flex.html.beads.models.ImageModel; ImageModel;
            import org.apache.flex.html.beads.models.ImageAndTextModel; 
ImageAndTextModel;
        }

On Aug 8, 2016, at 9:32 PM, Alex Harui <aha...@adobe.com> wrote:

> 
> 
> On 8/8/16, 10:39 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
> 
>> Can't we implement the url as well as the binary image using css?
>> 
>> For examle a url source:
>> <img width="16" height="16" alt="star" src="image/star.png" />
>> 
>> For example a binary source:
>> <img width="16" height="16" alt="star"
>> src="data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvC
>> chPGolfO0o/XBs/fNwfjZ0frl3/zy7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>> AAAAAAAAAAAAAAAAAAAAAAAACH5BAkAABAALAAAAAAQABAAAAVVICSOZGlCQAosJ6mu7fiyZeK
>> qNKToQGDsM8hBADgUXoGAiqhSvp5QAnQKGIgUhwFUYLCVDFCrKUE1lBavAViFIDlTImbKC5Gm2
>> hB0SlBCBMQiB0UjIQA7" />
>> 
>> Both are named source and a UrlSource would be identical to the url and a
>> BinarySource would be the base64 encoded presentation.
>> I can't see how there should be problems with mapping this to Flash
> 
> I'm missing what is "css" about this, but sure if the binary is encoded as
> a string a different ImageView could figure out what to do.  I would do it
> as a separate ImageView because I wouldn't always want to search every URL
> for "data:image/gif" just to see if it might be binary.  IMO, that is
> PAYG.  Don't force everyone to have their source strings scanned since we
> know lots of people won't need it.
> 
> I think the downside is also that each instance of the Image has to base64
> decode the string.  They can't share an instance of the decoded Blob.  So
> there can be an ImageView that requires a String, and Harbs can create a
> different ImageView that accepts a "binary" property or something else.
> We don't have to decide now.  Just make sure simple version that assumes
> non-binary string exists for simple cases, and create richer versions for
> other scenarios.
> 
> Thanks,
> -Alex
> 

Reply via email to