BNETDocs Redux

[Don Cullen]

@Don Cullen, thx for that I will probably do that (*edit just did that, account is LordVader) =)

Very neat btw how each user is able to alter the style sheet for their own preferences, that is fairly unique..
Did you create that or is it apart of a CMS or something?

Your account has just been given editing capabalities. As for the ability of users to alter the css for their own preferences, the idea was from Arta. He was going to implement it in BNETDocs, but BNETDocs never re-emerged. I thought it was a pretty good idea, so I coded it myself from stratch. So yes, I created it, and it's not a part of any CMS. The entire BNETDocs Redux system was coded from stratch.

So what you're saying is that only people that register can make the site not painful to read?  That's a bad idea right there.

Anyways, I've been poking around the CSS editor and I've noticed a few things:
1. Changes I make revert to the default after I hit the Render button.
2. The box gets big instead of scrolling.  Very annoying.
3. The site doesn't remember Open state of packet lists when using certain links.

Actually, no, what I'm saying is, each user can adjust the site to their own preferences. If you make an improvement in the CSS you think should be made as the global default, please feel free to let me know, and if it does look better, I'll gladly change the default CSS to the new CSS code.

As for your list of problems, thanks for pointing them out! I'll respond to each one in order of mentioned. For #1, yes, I had just noticed that too. I'm not quite sure why it's doing that, most of the time, it works, but in certain cases, it doesn't. It's already on my to-do list to be fixed. It's a most strange glitch... For #2, thanks for the suggestion. I originally had implemented auto-expand because it seemed like a good idea at the time, but now it's just plan annoying. So I'll remove it. Added to to-do list. For #3, yes, that's an on-going problem. I'm still working on trying to figure out a solution for it to remember the open state for all pages, no matter what link is clicked on.

Edit: Rabbit, in regards to #2 (textbox auto-expand), that has been removed. Thanks for pointing it out.

(DWORD) Protocol ID (0)(DWORD) Platform ID (DWORD) Product ID (DWORD) Version Byte(DWORD) Product language(DWORD) Local IP for NAT compatibility*(DWORD) Time zone bias*(DWORD) Locale ID*(DWORD) Language ID*(STRING) Country abreviation (STRING) Country

Only problem I've found so far is that the packet structure is not properly displayed for readability anyway. ^

Yea, it's like that for alot of the packets. The packets need to be checked and cleaned up. If you'd like to take a shot at cleaning them up, feel free to let me know. It's like what Hdx said:

Its alot of them. Its just a side effect of copy/paste. I'll poke around and fix some tonight.
~Hdx

In other words, Hdx is right. It's just a side effect of copy/paste. I wrote a program in VB that harvested the packet data from a html-based bnetdocs that I had downloaded from Ersan (it can be found at http://bnetdocs.dementedminds.net/old/ ), which in turn got automatically converted by the program into a MySQL insert statement. I then popped it into the database. What you see is the unfortunate results. It did get the data in, but not neatly.

The login page reports a SQL syntax error.

Camel, there was a server crash, and I had to restore the site from backup. You unfortunately registered right after the backup was made, so your account doesn't exist anymore. Just a friendly notice if you'd like to re-register. As for it reporting a SQL syntax error, it shouldn't be showing an error, it should just say there's no such user. Mmm. That needs to be fixed. Added to to-do list. Thanks for letting me know.

Edit: Camel, I fixed the login error that you pointed out. It shouldn't error out anymore, although you still have to recreate your account... 

As for the to-do list I keep mentioning, it can be found here:

http://bnetdocs.dementedminds.net/forums/viewtopic.php?p=11#11

Apart from that though, good job

Thanks.

[Barabajagal]

As I see you're using the display:block and display:none system, I have a way to set them all to :block if javascript isn't enabled. First off, I assume you're using a toggle function (if you call it, it sets to :none if :block, and :block if :none). You set the tables(or whatever you're setting the display of) to block by default, and then down at the bottom of the page, add a <script type="text/javascript"> calling the toggle function for all the tables, thereby setting them to :none when the page first loads if javascript is enabled.

[Don Cullen]

As I see you're using the display:block and display:none system, I have a way to set them all to :block if javascript isn't enabled. First off, I assume you're using a toggle function (if you call it, it sets to :none if :block, and :block if :none). You set the tables(or whatever you're setting the display of) to block by default, and then down at the bottom of the page, add a <script type="text/javascript"> calling the toggle function for all the tables, thereby setting them to :none when the page first loads if javascript is enabled.

That's pretty much how I was going to do it. The problem here is, I'm not very good at javascript.

This is the javascript function that shows/hides the particular div's:

Code Select Expand

function showhide(a,id){
if (document.getElementById){
obj = document.getElementById(id);
if (obj.style.display == "none"){
obj.style.display = "";
a.innerHTML = "HIDE";
UpdateLinks("rem");
pagecode = pagecode + getcode(id);
UpdateLinks("add");
} else {
obj.style.display = "none";
a.innerHTML = "SHOW";
UpdateLinks("rem");
pagecode = replaceAll(pagecode, getcode(id), "");
}
}
}

I'm not precisely sure how to make javascript go crawling through the div's to close them upon page load. When an user clicks on the 'SHOW' link, this is what that link would look like:

Code Select Expand

a href="#" onclick="showhide(this, 'Battle.net Messages'); return(false);"

[Barabajagal]

That's a bit excessive....

Code Select Expand

  <script type="text/javascript">
   function showHide(inID)
   {
    if (document.getElementById(inID).style.display == 'none')
    {
     document.getElementById(inID).style.display = 'block';
    }
    else
    {
    document.getElementById(inID).style.display = 'none';
    }
   }
  </script>

Then, you just call showHide("IDNAME") for every object that can be set...

[Don Cullen]

Actually, I overhauled the javascript code. You can see it in action at:

http://bnetdocs.dementedminds.net/?op=sandbox

Feel free to look at the source code for the javascript. Basically, the new javascript code takes a hit at two previously reported problems:

1. if javascript was disabled, packet groups were nonaccessible
2. structure of the packet groups were not persistent across pages in certain situations (ex: after form submission)

If you look at the sandbox, you'll see both problems have been solved (to test persistence, just open a few random groups, then click refresh). To test accessibility if js is disabled, disable it in your browser, and hit refresh.

Now those two are no longer problems. But here's a very strange situation. If you open a few groups (doesn't matter what), then click refresh, and look at the first group, you'll see the packets are gone and have been replaced by a simple + character... It's driving me insane, I can't find any problem with my code, I've debugged it over and over and over and still can't find the problem.

BTW, the new function I ended up using was:

Code Select Expand

function toggle_visibility(id) {
        var e = document.getElementById(id);
if(e){
        if(e.style.display == 'block'){
e.style.display = 'none';
forgetid(id);
        } else {
e.style.display = 'block';
rememberid(id);
}
}
    }

That pretty much does the toggle, AND enables memory persistence. If you'd like to see the memory persistence code, just look at the javascript source when you look at the sandbox. If you can find the glitch that's been driving me crazy, PLEASE LET ME KNOW! Before I either go bonkers, commit suicide, or end up being committed in the local mental hospital...

Edit: You can see the javascript source at:

http://bnetdocs.dementedminds.net/js/standard.js

[Hdx]

If I may make a suggestion.
Move the CSS to a 2nd file. it'll save a ton of bandwidth if you are using a browser that supports caching.
Do the default as a file, and then the custom.. have them cascade
~Hdx

[Don Cullen]

If I may make a suggestion.
Move the CSS to a 2nd file. it'll save a ton of bandwidth if you are using a browser that supports caching.
Do the default as a file, and then the custom.. have them cascade
~Hdx

Good idea, that. Added to to-do list. Thanks.

[Joe[x86]]

Joe, you misunderstood Andy. Andy was talking about the left side navigation menu that was listing all of the packets -- it was originally an extremely long list. That was on the old BNETDocs.

No, I understood him perfectly. Maybe I worded a response in a way that was misunderstood?

[Don Cullen]

x86] link=topic=16970.msg171841#msg171841 date=1187830548]

If you're going to make a new documentation site, make the big ol mile long packet list a frame that only loads ONCE and has a vertical scroll. That's the most annoying part of bnetdocs ever.

I expressed this to Arta a while ago. Apparently his reason is that he doesn't want it to cache in case he adds new packets. Perhaps if it expired after 1 hour or so? Does HTTP have that feature?

x86] link=topic=16970.msg171939#msg171939 date=1188007166]

Joe, you misunderstood Andy. Andy was talking about the left side navigation menu that was listing all of the packets -- it was originally an extremely long list. That was on the old BNETDocs.

No, I understood him perfectly. Maybe I worded a response in a way that was misunderstood?

Ahh... You mean, Arta was worried that the frame itself that would have been intended to contain only the packet groups would be cached, thereby losing out on new packets. I misunderstood. I apologize for the confusion.

No, frames will not be implemented, I just don't feel comfortable making use of them. While I can see the logic behind using them, I'd rather not.

This page pretty much summarizes why I don't feel comfortable with frames:

http://www.yourhtmlsource.com/frames/goodorbad.html

But I most definitely will be making use of Andy's idea of merging two packets of same name but different directions into one line, two links (example: SID_NAME (C->S) (S->C)). That should cut down the size of the list by half. I'll explore other possibilities if suggested.

Rabbit, good news. Your concern about the site requiring javascript has been addressed, and that should no longer be a problem, as the packet groups are expanded by default. Also, the issue of the packet groups' structure not being 100% persistent across pages has been fixed. The javascript code handling it has been overhauled. Now the packet structure will be persistent for as long as the browser remains open, regardless of if the user navigates across pages via links or form posts/redirections, even if the user navigates to another website entirely, and eventually returns back to the site, the structure will remain persistent. The only time the structure will be reset is when the browser instance itself is closed. Thanks for pointing out those two issues!

[Barabajagal]

In that case, use the CSS overflow property, so you can just scroll the list without scrolling the rest of the page.

[Don Cullen]

In that case, use the CSS overflow property, so you can just scroll the list without scrolling the rest of the page.

You can do that yourself in the CSS Theme editor. Just do something like:

Code Select Expand

#packets {
height:300px;
overflow: auto;
}

Or for a specific packet group only, you can do something like:

Code Select Expand

#Battle_net_Messages { /* Sets overflow for the Battle.net Messages packet group */
height:300px;
overflow: auto;
}

#BNLS_Messages { /* Sets overflow for the BNLS Messages packet group */
height:300px;
overflow: auto;
}

You even could go as so far as to completely eliminate specific packet groups you have absolutely no interest in, for instance, the D2GS messages:

Code Select Expand

#D2GS_Messages {      /* Removes the D2GS Messages packet group from nav menu */
display: none;
}

Edit: I just tested for myself, and apparently the CSS render defaulting to the original contents is still existent... I'll get started on fixing this problem now, and when it's fixed, I'll let you know in this thread.

[Barabajagal]

I have no interest in signing up. I'm just suggesting what should be default appearances. It's not nice to your users to make them scroll the whole window.

[Don Cullen]

I understand your view and your concerns, Andy. If you explore most of the popular sites out there, you'd see they make the user scroll. It's an accepted necessity for scrolling. I don't like scrolling much myself, but I can see where there'd be need for it if there was alot of content.

And besides, that's why I implemented div toggling -- to reduce scrolling, and that's also why I'll be using your idea of:

- Instead of listing every single packet twice for S>C and C>S, just make two links per line like so:
[0x00] SID_NULL (S>C) (C>S) [Suggested by Andy AKA Reality Ripple]

Those two in combination will reduce scrolling by a considerable percentage. While I doubt you and I will ever agree on whether scrolling should be a necessity or to be avoided at all costs, I respect your opinion, and thank you for your input.

[Barabajagal]

You'll also notice following W3C standards, designing sites for any screen size, and allowing text-based browsers to view sites well are also not very common. That's not an excuse. If you can find a better way to do something, do it.

[Don Cullen]

I agree on following W3C standards, and would if I was an elite coder. As for text-based browsers, those are obsolete. If anyone is still using a text-based browser, they badly need to jump up into the present and out of ancient history.

Take PHP for example. They don't continue to support PHP v1.0. There's a reason.

Take ANYTHING out there. They don't support early versions, and strongly encourage users to upgrade to current, or at the very least, close to current versions. Those that attempt to continue to be backwards compatible regardless of the sanity of it, tend to buckle in the end and abandon earlier versions. It's called being sane and not being blindly stubborn. Even in California, it's illegal to drive vehicles that emit alot of smog (read: ancient vehicles that aren't up to par to smog standards) and repeated violations will get the vehicle impounded. Whether it was the user's preference towards that particular vehicle means nothing to the government. It's not their problem. The law specifically states: either fix the smog problem, or if the vehicle is too ancient (aka incompatible with being smogged), trade it in for another vehicle.

The concept is similar with browsers: if the browsers aren't compatible with the majority of sites out there, and they aren't upgradable, it's time to trade 'em in for a more compatible browser. That's reality.

Refusal to adhere to modern standards isn't a valid excuse for coders to have to bend over and try to please them. Text-based browsers? While I respect their preferences to use text-based browsers, but, damn. Talk about the dark ages. While I admire your stance, I have to say I disagree with it.