Jakub Anderwald

As you can see, I joined Flattr beta.

If you don’t know it yet, have a look. It’s a flat rate (hence the name) donation system, where you pay some flat amount of money every month and it’s distributed to authors of things you “flatter” that month. To flatter a thing, click the orange / green button underneath each blog post.

Let’s see how it developes, but it might be “the way”.

Opera browser celebrates its 15th birthday today.

Their “new’ website look is hillarious.

I’m a heavy usenet (newsgroups) user. I find it way faster than any other communication / collaboration method.

There’s one downside to using “fat clients” – every message is fetched from the server when you read it. It might have been a good solution when dialups ruled, but nowadays it would be much easier to just download everything and read afterwards – you wouldn’t have to wait a second or two for every message to be transferred. Unfortunately, you have to use tricks with “offline mode” to force such behaviour on regular usenet readers (e.g. Mozilla Thunderbird).

At some point in time I said “enough” to loosing those seconds and started looking for solution. I found one – I’ve set up a local proxy news (nntp) server. Yes, it sounds complicated and serious, but it’s not.

Messages download instantly and I can save a lot of time this way.

Just download hamster news server, copy folder to c:\program files (or wherever you keep your software) and run the main EXE. That’s it.

Apart from super-fast message reading, you also get resiliency to server failures – if one server fails, hamster will download messages from another server and you won’t have to change anything, won’t loose your read / ignored threads information etc.

Go to configuration -> News configuration, Newsserver tab and add at least one news server.

Then to News-Pulls and add your news groups, so hamster will fetch them.

Go to configuration -> Local users & passwords, add a local user to connect from the news client and a password.

Basically that’s it – play aroung with options a bit. Once you’re familiar with the menus and configs, it’s time to start using the server.

Click Online -> All servers. Hamster will fetch your newsgroups and all messages – it might take a while.

Then start your favorite news reader and add a new server, with localhost as address. You should be able to subscribe to the groups you’ve selected on hamster.

Now, let’s make hamster automatically download messages when it stays idle. Unfortunately, I didn’t find any setting for that – but hamster has a scripting interface itself – let’s use it!

Go to script -> Manage Scriptcs and Modules, add a new script. Let’s call it Fetch.

Edit it and put the following code inside:

#!load hamster.hsm
### begin script ###

#!hs2

 HamWaitIdle
 HamNewsJobsClear
 HamNewsJobsPostDef
 HamNewsJobsPullDef
 HamNewsJobsStart

 HamWaitIdle

### end script ###
quit

Now, go to Configuration -> Automation, Actions tab and for Startup and EveryHour events set to run Fetch.hsc script.

That’s it. You have your own local news server operation in less than hour.

I would suggest to make it auto-run on Windows startup. It, sort of, makes sense ;)

This is kind of trivia, but not everyone knows how to do it.

There’s nothing more annoying than attending a meeting, then having somebody have to leave their presentation to go to a YouTube page, wait for the video to buffer up and finally watch it with mediocre-quality laptop speakers.

And of course, the video has to hickup by some Murphy’s law, no matter how long you wait for most of it to buffer.

Luckily, there’s a simple way to embed a whole YouTube video in a PowerPoint presentation. Just follow this guide.

Due to ASP.NET’s requirements with regards to server side controls being in one big FORM tag, I started looking at nesting FORM tags in one (X)HTML document.

Formalities

First, let’s have a look at the official documents.

HTML 4 specification says
A form can contain text and markup (paragraphs, lists, etc.) in addition to form controls.

DTD says that FORM element can contain aby block element apart from another FORM
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT | BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->

However, following the nesting path, there should be no problem in using some block element and nesting another FORM within that. Let’s take DIV for example.
<!ELEMENT DIV - - (%flow;)* -- generic language/style container -->
<!ENTITY % flow "%block; | %inline;">
We can see that DTD officially forbids only nesting FORM directly within another FORM. It doesn’t say anything about nesting FORMs within block elements, within other FORMs, or even deeper within the DOM tree.

But let’s see how does it work in the real world.

Experiments

Let’s try this practically. We’ll use the standard W3 validator and Firefox DOM inspector to examine site content at each step.

Attempt 1 – the obvious

First, we’ll use a simple XHTML document with one FORM tag.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
      </fieldset>
    </form>
  </body>
</html>

Of course, validator says it’s a correct document.

Within the DOM tree, we can see our FORM successfully.

Attempt 2 – wrong

Now, let’s add another FORM within the first one

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
      </fieldset>
      <form action="#" method="post" id="inner-form-1">
        <fieldset>
          <input type="text" id="inner1-input" name="inner1-input"/>
          <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
        </fieldset>
      </form>
    </form>
  </body>
</html>

As expected, validator says it’s incorrect – true, we cannot nest FORM directly within a FORM.

If we look at the DOM tree in a browser, we see how the browser is trying to glue both FORMs together

Attempt 3 – theoretically correct

Now, let’s put the inner FORM within a block level container. This markup is correct according to specification and DTD.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
        <form action="#" method="post" id="inner-form-1">
          <fieldset>
            <input type="text" id="inner1-input" name="inner1-input"/>
            <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
          </fieldset>
        </form>
      </fieldset>
    </form>
  </body>
</html>

Validator indeed says the document is OK.

Let’s try the DOM inspector.

What happens? The browser is still gluing the two forms together, although the markup is correct. This is something, that should not happen. Let’s experiment a bit more

Attempt 4 – the quirks begin

Now, let’s add some more properly marked up nested forms and see what happens.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
        <form action="#" method="post" id="inner-form-1">
          <fieldset>
            <input type="text" id="inner1-input" name="inner1-input"/>
            <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-2">
          <fieldset>
            <input type="text" id="inner2-input" name="inner2-input"/>
            <input type="submit" id="inner2-submit" value="Submit inner form 2"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-3">
          <fieldset>
            <input type="text" id="inner3-input" name="inner3-input"/>
            <input type="submit" id="inner3-submit" value="Submit inner form 3"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-4">
          <fieldset>
            <input type="text" id="inner4-input" name="inner4-input"/>
            <input type="submit" id="inner4-submit" value="Submit inner form 4"/>
          </fieldset>
        </form>
      </fieldset>
    </form>
  </body>
</html>

Again – validator says it’s fine.

Let’s see what DOM insepctor tells us this time.
.
Now we can see some weird behaviour here. The browser is gluing the first inner form, but processes the other forms properly

Conclusions

Despite the fact that nesting forms is theoretically possible, browsers do not render it properly. A workaround needs to be used. On the other hand, specifications can be updated to clearly prohibit nesting FORM tags.

Workaround

The basic workaround is to nest additional, unnecessary form, just for this bug’s sake. Say, for 1 main and 2 nested forms, you would create such document then

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
        <form action="#" method="post" id="nested-form-bug"></form>
        <form action="#" method="post" id="inner-form-1">
          <fieldset>
            <input type="text" id="inner1-input" name="inner1-input"/>
            <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-2">
          <fieldset>
            <input type="text" id="inner2-input" name="inner2-input"/>
            <input type="submit" id="inner2-submit" value="Submit inner form 2"/>
          </fieldset>
        </form>
      </fieldset>
    </form>
  </body>
</html>

Then you just have to hide the dummy form

#nested-form-bug {
	position: absolute !important;
	left: -2500px !important;
	width: 20px !important;
}

Validator still treats is as valid document.

In the DOM tree, we get what we want – 3 forms, 2 nested into the container form.

To do

1. A validator bug is already reported.
2. Check if it’s browser-consistent
3. Check what browsers are sending to server for such nested forms