Proactive chat code = one serious mess!

[twhiting9275]

So, after a bit of a break from the mess that is kayako, I hath returned. The first thing I noticed? The "proactive chat" mess has serioiusly messed up my own website.

Thankfully, this can be removed (via templates), but come on now. Something MUCH better should be come up with for this

<table width="450" height="200"  border="0" cellpadding="1" cellspacing="0">
  <tr>
    <td bgcolor="#3894E5"><table width="450" height="200"  border="0" cellpadding="0" cellspacing="0">
      <tr>
        <td align="left" valign="top" bgcolor="#EDF4FF"><table width="100%"  border="0" cellpadding="0" cellspacing="0">
          <tr bgcolor="#FFFFFF">
            <td height="29" colspan="2" align="center" valign="top"><img src="<{$themepath}><{$product}>.gif"></td>
          </tr>
          <tr align="center" bgcolor="#3894E5">
            <td height="1" colspan="2" valign="top"><img src="<{$themepath}>space.gif" width="1" height="1"></td>
          </tr>
          <tr align="center">
            <td colspan="2" valign="top"><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><br>
              <br>
              <{$language[proactivemsg]}><br>
              <br>
              </font><br>
              <br></td>
          </tr>
          <tr>
            <td width="47%" align="center" valign="top"><a href="javascript:doProactiveRequest();"><font color="#FF3300" size="4" face="Trebuchet MS, Verdana, Arial, Helvetica, sans-serif"><{$language[proactivechatnow]}></font></a> </td>
            <td width="53%" align="center" valign="top"><a href="javascript:closeProactiveRequest();"><font color="#6666FF" size="4" face="Trebuchet MS, Verdana, Arial, Helvetica, sans-serif"><{$language[proactivenothanks]}></a></font></td>
          </tr>
        </table></td>
      </tr>
    </table></td>
  </tr>
</table>

Tables, tables? What, are we going back to 2002 here? TABLES?
Oh wait, my own website uses tables!

What does this do? This causes everything to go crazy with my site. So, it's "disallow proactive" (by removing it), or have the site look like ****? Isn't there a friendly medium here?

Yes, I know, it's all template based, and I can redesign it, but, frankly, I shouldn't have to. Luckily I have the talent to find out what caused this, but, again, this shouldn't have to be passed onto customers to debug and do.

[supportskins]

The code indeed is a little messy but you should not have any real problems modifying it if you are comfortable with working in HTML. I see no reason why it should screw up your website as the proactive chat box is a popup.

[twhiting9275]

That's just the point. it isn't "just a popup". Anyone who looked at those attachments would see that.

When inserted into another table, that code doesn't just become messy, it becomes deadly to a website. Again, all you have to do is look at the screenshots to tell this.

Anything that can do THAT to a website should never, ever be put into public distribution. I don't really know why it's causing that, nor, honestly should I HAVE to. Hell, I shouldn't have had to go this far into debugging a "professional" application! The only reason I DID was because it made my website look like complete trash.

It's not MY job to write proper code for kayako, or to beta test their stable releases here, that's their own job.

[Jamie Edwards]

Hi there,

Actually, if you inspect the complete DOM when the popup comes up you will see that it is infact wrapped in a <div> layer (zindex 500). If it is messing up your website, it is probably because you are using positioning in incorrect ways.

If the HTML used for the chat request was breaking simple HTML in the way you describe, we would have 100s if not 1000s of complaints about the same thing, but we do not.

If you believe I am mistaken (I may well be) do get back.

<div id="proactivechatdiv" style="display: block; float: left; position: absolute; top: 191px; left: 415px; width: 450px; height: 400px; z-index: 500;"> 

[twhiting9275]

Yeah, go ahead, blame the customer instead of fixing your code! Why should I not expect this from you by now.

The point is that this causes issues. I've shown proof of this in these screenshots. Rather than fix the problem (your code), you've chosen to ignore it and pass it off to the customer. That's professionalism for you, right there!

This only affected certain positions (ie just above the main page), so I doubt it's a DOM thing. However, regardless, should it REALLY be up to the customer to debug this ****? I mean come on now, my time is worth more than that! If nothing (and I do mean nothing) has caused this problem in over a year with this website, wouldn't it be quite obvious that the problem isn't with the website itself, but with your code!

The problem itself is the code, and how it is displayed to the browser, nothing more. Every other "live chat" system I've used has had the same "do youneed assistance" junk, every other one has done just fine in that same exact spot, yet yours does not. Hrrm, is the world wrong and kayako's right, or is it the other way around? I'd say, definitely the other way around.

While this is only a minor problem, still, it's disrespectful of your customers to continue on with the same old same old attitude of "it's your website". In this case, your code affects my own tables in a way that they are critically impaired, whereas nothing else has ever done this! I'd hardly call that "my website".

[Jamie Edwards]

I'm not simply trying to pass the blame off onto you. I know that Kayako's HTML does not validate according to today's standards (so understandably it is hard for me to be "the one to talk").

However, the 'invalid' areas of our HTML are only minor and do not affect rendering of pages across browsers. Looking at your HTML, even if the HTML used by us for the small popup layer was entirely valid XHTML, it would still break your page in the same way.

On looking over your HTML, it is in fact the DOM which is being broken because you have not defined any positioning attributes for your structural (layout) <divs>, so the browser simply does not know what takes prescedence and in relation to what.

If you pass the fragment through a W3 validator, you will see the template code you posted above is valid (bar accessability standard related elements such as "alts" and so on).

[twhiting9275]

On looking over your HTML, it is in fact the DOM which is being broken because you have not defined any positioning attributes for your structural (layout) <divs>, so the browser simply does not know what takes prescedence and in relation to what.

You , again, fail to see the point. Why must it be made over and over again?

EVERY OTHER PROGRAM handles that webpage without an issue. From providesupport to supporttrio to phplive. That spot, their code, it's all the same. EVERYONE ELSE handles this just fine. They all do the same thing!

The problem isn't the "code", but the placement of the code, and how your code interacts with tables. It's a mess, period. If I place it underneath the center area, it's fine. However, that's NOT where I want it. I want it right on top, where it is! Your code attempts to take over that spot, quite literally. Even as is.

Yes, even as is, your code is ignoring basic html tags. When told to <center>, it stays there and tells html to go to hell, seriously! When placed LAST in the set of "buttons", it adds it's own mess of lines and the like. This is 100% your code here, not my site. Come on now!

[supportskins]

I understand to an extent agree that the code is not perfect but it is not that difficult to modify it to meet your requirements. We do it for our clients on daily basis and have had no issues as yet.

[twhiting9275]

I understand to an extent agree that the code is not perfect but it is not that difficult to modify it to meet your requirements. We do it for our clients on daily basis and have had no issues as yet.

That's just the point!

The CLIENT shouldn't have to go in and tweak something in a template here, and I'm not going to spend my time , or my money to do KAYAKO'S job for them.

So what if this works in a "plain" html page. The fact is that the table is broken, by me? No, by kayako! THEY should take care to fix their problems!

[Jamie Edwards]

I'm afraid I have to (as respectfully as possible) disagree with you, here.

EVERY OTHER PROGRAM handles that webpage without an issue. From providesupport to supporttrio to phplive. That spot, their code, it's all the same. EVERYONE ELSE handles this just fine. They all do the same thing!

The only reason why other solutions work is because they happened to use HTML code that happened to work with your page's HTML that is fundamentally broken.

I do not think you are properly understanding the interaction of document objects. With regards to the <center> tag and SupportSuite's HTML, it is not the HTML that we implemented that is stopping <center> from working, it will most likely be something else. Not to mention, <center> is depreciated in HTML 4.01 and completely is unavailble in XHTML DTD. See here: http://www.w3schools.com/tags/tag_center.asp.

It is not the tables inside the proactive template that are interfering with your own - the only interference that is happening is that the proactivediv object is being given placement precedence over everything on your page by the browser because you have not defined any sort of positioning precedence for your own div objects.

Please understand that it is nearly impossible for us to tailor the HTML to work with all browsers (which it does) and to work with potentially broken-code pages, because that potential number of 'broken code' cases is infinite.

I will attempt to think up a way of making the popup compatible with your page for you, but all in all this is not a fault of the HTML in SupportSuite and our code is working as designed.

[twhiting9275]

The only reason why other solutions work is because they happened to use HTML code that happened to work with your page's HTML that is fundamentally broken.

As is kayako's code

How do I know this?
Well, I caved in and decided to revamp things, reworking the site. I've been after doing away with tables for a while now, and forcing standards upwards.
While it's not done, this much is known

#1:
At the base code, it's validated XHTML 1.1 strict compliant, aside from one thing

So, what breaks the "standards"? Well, take a look through this and I think you can guess:

<!-- Begin SupportSuite Javascript Code -->
<script language="javascript" src="https//domain.com/support/visitor/index.php?_m=livesupport&_a=htmlcode&departmentid=0"></script>
<!-- End SupportSuite Javascript Code -->

Yes, this is the code generated by kayako itself for "website chats". The problem? Well, let's see here:

#1:
& should never be used, the proper html replacement should be used instead.

#2:

# Error Line 97, Column 141: required attribute "type" not specified.

The solution is just as easy for this one. Define the script type

The problem is that most people aren't going to do either of those two steps, so they must be done for them, ie: the code output must be valid. It's not.

Now I don't deny the old page probably has a few (ok, so validator says 50, not too bad) errors to it, but, again, the problem isn't as much the errors, but the tables. Placement of the code proved that. If it was on top, it acted all wierd. If it was on bottom (in the main area), it did not. Essentially, it was trying to take control of the table, which it should never do.

Of course, those are probably broken in 4.0.1 as well, I haven't run the test through there.

[Jamie Edwards]

twhiting9275,

If you use DIVs properly on your site and set proper positioning attributes, you won't have this problem.

[twhiting9275]

Originally Posted by Jamie Edwards

twhiting9275,

If you use DIVs properly on your site and set proper positioning attributes, you won't have this problem.

Whatever man, whatever.
This has NOTHING to do with <divs> and NOTHING to do with "proper positioning attributes". it has EVERYTHING to do with the default code.

Of course, this is so typical here. Blame the user for your own code, ignore the fact that your own code is not standards compliant by all means, and attempt to overwrite the user's preferences.

Is it THAT hard to write code on your own end that is STANDARDS COMPLIANT and won't break the user's code? Apparently so! Apparently, it's easier to just blame your client for your own inability to handle things properly and make them do your job for you.

[Jamie Edwards]

I say again, the code that is called into the DOM when a request is called is fully semantically standards compliant - you can test this yourself using the validator at w3.org.

[craigbrass]

If you still have a problem, I suggest you take this up with Varun (CEO). You can contact him by email -> varun.shoor <!at!> kayako.com.