Wednesday, October 17, 2012

Microdata API in XML (XHTML)

After running into an issue with the Microdata API conflicting with with a script on a site, I have looked into it recently. While I do not fully understand what the usage of it is, I decided to at the very least try to learn the syntax so that I can get past that for when it becomes something relevant and in heavy usage.

So to do so, I am looking at implementing some Microdata on my website. Now the first problem I ran into was the description of the syntax conflicts with proper XML. The conflict is an attribute without a value, itemscope. So any attempt to use this results in an XML parser error (because I server the site as an xml file, not an html file). So after a quick Google search, a solution was found in the form of a solution for another problem someone was having. So to set an itemscope in xhtml, you do this.

<div itemscope="itemscope">

Like magic, the browser knows what to do. I did not realize that I have actually done with before when using selected="selected" on a dropdown before.

The idea behind this whole Microdata API seems like a nice way to organize and access data using the DOM a lot quicker without the need for items to be sibling, parent or child nodes and offering a quick named reference without a million different ID's. However due to it being new, if used a lot, there are probably going to be a lot of hack jobs to emulate the thing. All well, hope this helps anyone looking into it but don't have the desire to use regular old HTML.

Tuesday, October 16, 2012

MyBB Post BBCode Button Problem

I wanted to post this a couple days ago when the problem was brought to my attention at a forum I code for, but was too busy to get it up until now. The problem has a fix for it, here. I just want to go over quickly what is the cause of the problem and let people know it may effect Chrome and Opera. The fix was simply changing some variable names, so it wasn't anything too complicated.

So Firefox implemented something called Microdata API. This is a new thing for HTML5 that adds more information to your markup. The catch is, whether or not you are using HTML5, it still effects your site. It adds new DOM attributes that MyBB 1.6.8 is using. This particular one is itemData. That is now an object and due to the way the script was made for the post editor, it just screws it up. From what I've read, Chrome and Opera will be implementing them soon. I hope eventually it will be made to only effect HTML5 pages.

I have yet to read up how to use the Microdata API, but if you are interested, you can find notes on it here.

Monday, October 8, 2012

Legacy Support Rant

Sometimes legacy support is good. It can lead to stable ways to develop things, easier transitioning and all around make life easier. One thing I have been noticing is a very strong concern for websites to have legacy support. The problem with this legacy support is people seem to be holding off on all the cool technologies that are being made for newer web design that can make things safer, quicker and easier. While I understand it's not always best to rely on these new technologies for safety, I use them. I do not use them for the safety, but the enforced strictness that can lead to a proper and less erratic design.

When I started my adventure into learning web design, it was 2010. I was learning XHTML 1.0. Guess what? It was new in 2001, and now it was just used as common place despite development of HTML5. This really isn't a problem, but I still saw some sites using HTML 4.01. This is even older, from 1999. This may not seem like a lot of time, but in Internet time that is rather old. Other legacy support includes a fix for png transparencies because old versions of IE don't support that, checking for addEventListener in javascript because old IE used attachEvent and many other javascript, as well as css, hacks to get around issues on older browsers.

This is all fine and dandy, however I feel people really need to move on with this stuff. I should not need to worry about support for IE5 when IE9 is already out and available for free to anyone who already has Windows. Also, with Firefox, Chrome and Opera all being free and well up-to-date with all the latest web technologies, there should not be a problem. The newer browsers are becoming more consistent (although some do things I don't like, mainly webkit) and are supporting newer and better technologies that are removing the need for flash and Java applets, which is a good thing. Why is this good? Because they can be even more of a mess to work with and they crash or lag my browsers so often that it just irritates me to no end. Some flash and java apps are cool, like flash games, some programs I used in school on blackboard and I've even seen an online photo editing program that was way better than MS Paint.

My main problem is there is a time and a place when to use each technology. When done correctly, you get a very nice website, good experience and overall ease of use with everything. When they've gone wrong is when I go to a site with about 50 flash apps all overlapping and clipping each other, lag so bad everything on the site stutters when I try to scroll and my bandwidth cluttered by pages of CSS hacks just so they could kind of get the site to look normal despite the flash apps breaking it because you can't style them with CSS and have to rely on the design of flash to work it all out.

Web design needs to start letting go of legacy support. I made my website in XHTML5 served as XML, and not all browsers can open an XML file. Also, I'm using CSS3 and "use strict" in my javascript.

Outside of web design, I see people use old code in their programs. Things that have better ways of doing them that were made. Just looking at code in a broad spectrum, even today, most business programs are still COBOL programs. I tried learning COBOL. The need to write things out in caps, count spaces so code can run correctly and in general lack simple control structures and functions that I use in other programming was a nightmare. However, in contrast, old languages like Lisp still have their place. There are some old languages out there that when I see, I have a fascination with them because of how old they are and some have things you just can't do with really anything else. You can emulate it, but its true nature only resides in itself (mainly looking at lisp and their macros).

Legacy can be fun, interesting and great for learning. However, looking at things practically, we keep things alive for far to long. There can even be an argument made about IPv4.

I suppose what I am getting at is legacy, while it is cool and useful, should not be supported so heavily in the mainstream to this point of reliance. Push for some progress, it's not abandoning the old ideas, it is simply making them better. So update once in a while.

Saturday, October 6, 2012

Strange stuff in Python (mutable objects)

I was fiddling around with Python trying to finish up a project when I noticed something strange. Now if you did not know, any mutable object you pass in Python passes a pointer to the object rather than a copy. While this does not seem all too interesting, this leads to the ability to pass something like a dictionary to a function and that function can then alter the dictionary. Thus anything after that that accesses it will see the changes, value returned or not.

Another thing about Python is global variables are stored as a dictionary, which can be obtained using the globals() function, keep in mind it returns a dictionary which means it points to the actual object, not just cloned data. Okay, so now what can we do with this? Well the globals updates whenever a global object is created, including variables. So what happens if we assign a variable to point to the globals? We get something like this (on idle).

>>> x = globals()
>>> x
{'__builtins__': <module '__builtin__' (built-in)>, '__file__': '/usr/bin/idle-python2.7', '__package__': None, 'x': {...}, '__name__': '__main__', 'main': &tl;function main at 0x1b6a410>, '__doc__': None}
>>> x["x"]
{'__builtins__': <module '__builtin__' (built-in)>, '__file__': '/usr/bin/idle-python2.7', '__package__': None, 'x': {...}, '__name__': '__main__', 'main': <function main at 0x1b6a410>, '__doc__': None}
>>> 

So what you should notice is that x and x["x"] appear the exact same because they are the exact same thing. We can dive forever into this and we will always get the same result. So what would happen if we did something that while during execution altered this? If you did not know, creating a variable in a loop in Python does not make the variable local to the loop like it would in C, it creates a global (something I hate but have learned to live with by just reusing a garbage variable that I won't use anywhere else). So the end result gives us this.

>>> for a in x: print a

__builtins__

Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    for a in x: print a
RuntimeError: dictionary changed size during iteration
>>> 

Okay, so now things get interesting because we can break stuff. So let's see that again.
>>> for a in x: print a

a
__builtins__
__file__
__package__
x
__name__
main
__doc__
>>> 

Okay, so what just happened? Well, since the first call to a created the global a, the size changed. But now when we run it again, a already exists so the size does not change. Despite the values changing, it does not care as long as the length of the item is not modified. This means even in this case, we can still alter the dictionary mid-loop so long as we do not change the length. Try this out yourself then view x. You should find that a is now the last item from the loop. In fact, prior to the RuntimeError, a was still assigned the variable, meaning we can also track the value when the loop terminated. Now let's delete a from there and get a little craftier to see what happens.
>>> del a
>>> while 1:
 try:
  for a in x: print a
 except RuntimeError:
  print "Failed at " + a
 else:
  break

 
__builtins__
Failed at __builtins__
a
__builtins__
__file__
__package__
x
__name__
main
__doc__
>>> 

Now like magic, you see it failed and tried again. Now let's try one more thing, promise it's the last thing to try for now, and this one is weird. I also have no idea what happens so I ran it twice. Check it out.
>>> del a
>>> while 1:
 try:
  for a,b in x.items(): print a,b
 except RuntimeError:
  print "Failed at " + a + "=" + b
 else:
  break

 
__builtins__ <module '__builtin__' (built-in)>
__file__ /usr/bin/idle-python2.7
__package__ None
x {'a': 'x', 'b': {...}, '__builtins__': <module '__builtin__' (built-in)>, '__file__': '/usr/bin/idle-python2.7', '__package__': None, 'x': {...}, '__name__': '__main__', 'main': <function main at 0x1b6a410>, '__doc__': None}
__name__ __main__
main <function main at 0x1b6a410>
__doc__ None
>>> 

So what happened? To be perfectly honest, I have no idea what is going on, but it seems either the unpacking or the function call somehow changes the flow enough that no failure occurs. I do not know that much about the guts of Python and maybe this information is completely useless and well know. Either way, I found it interesting and if you have any cool ideas of what can be done with this or maybe know a bit more about how it works than I do, let me know.

Tag Cloud

.NET (1) A+ (2) addon (6) Android (3) anonymous functions (5) application (10) arduino (1) artificial intelligence (2) bash (4) c (7) camera (1) certifications (4) cobol (1) comptia (4) computing (2) css (2) customize (16) encryption (2) error (19) exploit (17) ftp (3) funny (2) gadget (2) games (2) Gtk (1) GUI (5) hardware (6) haskell (15) help (8) HTML (6) irc (2) java (5) javascript (21) Linux (19) Mac (4) malware (2) math (8) network (9) objects (2) OCaml (1) perl (4) php (9) plugin (7) programming (42) python (24) radio (1) regex (3) security (25) sound (1) speakers (1) ssh (3) story (1) Techs from the Crypt (2) telnet (2) tools (14) troubleshooting (5) Ubuntu (4) Unix (4) virtualization (1) web design (14) Windows (7) wx (2)