Reimplement Messages bubbles using SVG instead of PNG about framework7 HOT 19 CLOSED

Hi there,
Your example looks good and of course it should be definitely reworked to SVG, but let's discuss it. We have used a bit different technics with you, you add this "tail" as a colored SVG image, but i've tried to achieve something like mask. The problem with your technic is we can't add such tail to image. Images are already supported, you can try to type this in message field and hit Send:

<img src="https://pbs.twimg.com/media/BixUKelCAAEX4qM.png">

But at the moment it has no "tail". With your technic we can't do that. So what i see now:
Your pros:

• we can easily colorize it
• it don't depends on messages container background, so we can change it without problems

Your cons:

• Can't be applied to image
• Paddings and border radius looks a bit over, but this probably easily configurable by changing SVG curve, right?

My pros:

• potentially could be used with image, but we will need to use a lot of :after/:before pseudos
• we can change background of message without changing inline SVG color, and we can use image backgrounds for messages

My cons:

• png image looks not clear and smooth
• by changing messages container background we also need to change this "masks"

So we need somehow to get the best from our solutions. I was thinking about using -webkit-mask with SVG masks, but i am not sure that it is possible

What do you think:)

from framework7.

About flex box. I think you mean fallback syntax for older browsers. Yes, please help!:) These flex-box differences drive me crazy)

from framework7.

I updated the gist using -webkit-mask-box-image. That was a very good idea, it makes a lot of things possible. Here's the updated demo

I'll adjust the radius of the corners next. Easy to do.

from framework7.

@ptb that is fantastic!) Exactly what we need, the only thing need to be fixed is a border radius. I mean when have for example one character in bubble, bubble should look like a circle

from framework7.

I took a screen shot with a one character message from my iPhone 5, and this is the result:

With the current code (not yet in the gist) this is what it is rendering as:

Are you saying it should be narrower than the real iOS? For simplicity, the SVG masks handle the shape of both the round bubbles and the the ones with "tails", that way they match without adjusting margins or padding, etc. If you want it "rounder", the min-width can simply be changed to 40px (or removed altogether), but it was set to match Apple's implementation.

from framework7.

Hmm, just checked, you are right, for some reason i was sure that they are round as circles:) Ok, so now they are perfect. Will you make a PR or you want me to merge it manually?

from framework7.

I'll make a PR. :-)

from framework7.

Ok, by the way, could we unescape svg's url or it is required? I checked and seems to work fine, and it saves almost half size:)

from framework7.

I percent encoded it based on David Bushell's recommendation, but according to him, it "only works on Safari and Chrome". Since -webkit-mask-box-image will only work on Webkit-based browsers anyway, it seems like it won't be an issue. I tested it as a background-image on Firefox 28 and it didn't have a problem either. I don't have a copy of IE readily available to test.

I changed the data URI of one of the images to see if I could make it break. I tried uploading the page to a web server configured to serve the file as ISO-2022-JP, and it still displayed correctly. (Granted all of the characters in the content are in the ASCII character set, so it shouldn't be an issue anyway.) Even though it is not to spec (RFC 2397 and RFC 3986), I think you're right and it should just be used unescaped.

Also, dbushell.com says that base64 encoding is always smaller, but he's wrong. When sending the page over the wire, it (should be) sent as gzip. Since the content is text, gzip is able to compress it much more than if it was base64 encoded.

from framework7.

And I tried validating it without percent encoding on http://validator.w3.org and http://jigsaw.w3.org/css-validator/ and neither of them had a problem with it.

from framework7.

I agree, let's keep it unescaped and without base64

from framework7.

Anyway, each bubble size is around just 200 bytes. Base64 will not help us a lot here, so let's keep it plain

from framework7.

I updated the gist.

from framework7.

Looks great, right? I think you can pull it

from framework7.

Are you opposed (or know more than I do why it might be a bad idea) to simplify the CSS class naming for messages? I made the proposed changes here. Basically, shorten the class names and use the semantic HTML elements instead of <div> as recommended in the HTML5 working draft?

from framework7.

It is simple. We can't use <p> tag for a few reasons:

1. It is a pretty common tag that dev probably will use in text/content formatting, and we always have some default styles for such tags in css like:

p {
  color:red;
  font-size:20px;
  margin: 1em 0;
} 

And the worst thing here is that many still use such things:

p {
  /* Hmm, for some reason color was not applied, let's do this important: */
  color:red !important;
  font-size:20px;
} 

And such thing could broke many things. And i guess no one will do such commong css rules for just <div> tags
So from this point usage of DIV tags is more safe.

2. We can't put anything inside of P tag except inline elements. We do framework and we don't know what user will want to put there, it maybe UL list or few P tags inside. With P for bubbles it will not work. So using DIV tag also allows flexible layout inside of bubbles

from framework7.

The same could happen with short classnames as "sent" or "received", and i sure that someone could use "pic" class in their custom layouts. So using such scoped classes is also more safe here

from framework7.

I didn't even think of <p> not being appropriate except for inline elements. Good call.

from framework7.

I think we can close this issue for now

from framework7.