Add proper quotes

[adon-at-work]

@maditya please review

I addressed the problems stated in #21 with an approach that centralizes a single place to capture and treat attribute values.

c.c @yukinying @neraliu

[maditya]

can we document what each bit/byte is reserved for? That'll help us when we add new actions going forward.

[adon-at-work]

i believe its documented a few lines later. e.g., DerivedState.TransitionName.DQ_ATTR = 0x01;, and DerivedState.TransitionName.WITHIN_DATA = 0x10; with comments there
can you pls share how it should be better improved? :)

[adon-at-work]

on a second thought, are you expecting something like 0x01 refers to the least significant bit (from right to left, first bit), 0x02 refers to the second, 0x04 refers to the third, and 0x08 refers to the fourth one, so and so forth?

[adon-at-work]

@maditya , i made this PR really out of my curiosity. would love to see how such an impl will perform, and how cleaner the coding can be, if I load a single transition with multiple actions. i like your original approach too. so, just feel free to co-edit/fork this branch, copy anything to yours, or we could co-edit your branch. :)

let's also discuss (perhaps in the standup meeting) how or whether we should balance optional tags, as described in dd4ae8b#diff-9c568acf92dc1a69fdd058c41195c719R139

[yahoocla]

CLA is valid!

[adon-at-work]

@maditya, the example above is what triggered me to ignore self-closing solidus.

but then i encounter some html samples of optional tags, that may require extra balancing logics

<select><option>123<option>abc</option></select>
<table><tr><td>123<tr><td>abc</td></tr></table>

our current balancing logic will produce:

<select><option>123<option>abc</option></option></select>
<table><tr><td>123<tr><td>abc</td></tr></td></tr></table>

while it looked very ugly, as one properly expects the following, but it worked out to produce the same DOM in Chrome:

<select><option>123</option><option>abc</option></select>
<table><tr><td>123</td></tr><tr><td>abc</td></tr></table>

[adon-at-work]

@yukinying, a2d4026 is the patch using the "incremental" bit encoding to represent different actions. In particular, the higher group actually do not actually look incremental (i.e., 0x08, 0x10, 0x18, ...). Unless we give up the forth bits to make it like 0x10, 0x20, 0x30, ..., which ultimately isn't much more space efficient than the original. that will become 4046a9e
I personally think the first one is a little bit ugly, and I liked the original better. both worked. just let me know which is gd so that we can go ahead. thanks :)

[yukinying]

We would like to keep the design simple and straightforward, so the ideal implementation is to keep lower group and higher group in separate variable. It's fine to compress lower group and higher group together in a variable, but I don't like the idea of converting them to bitwise flag. Those variables are supposed to store state number rather than flags.

[adon-at-work]

tiny cleaned up. git rebased to master

[adon-at-work]

Further to #22 (comment), I think a2d4026 is meant to show the ugliness. 4046a9e is what we now prefer, therefore, having both lower and higher groups to be sequential.
But when we one day really run out of spaces, and have to encode a lot of actions (not states actually, notice that here the table[prevState][nextState] gives an action), we might have to fall back to encode using the ugly way.

I didn't realize this during our prior discussion but only when I implement it. So, let's see if we've any new thoughts/inputs to this problem. If not, we can stick with the 4046a9e as discussed.