# Styling RSS w XLS notes
XML files can include both xml-stylesheets (XSLT) and normal stylesheets (CSS).
XSLT files are transformations, and allow you to process an XML doc into an HTML doc (among other things).
In this case, it doesn't matter if we import the CSS here or via /rss/rss.xsl -- it gets applied either way.
The XSLT will output HTML for us, but the HTML content from the RSS feed (i.e., the bodies of posts) must be unescaped.
There's a special attribute (`disable-output-escaping`) which will do that.
However, we need to run some JS, too, because not every browser supports decoding html like that.
* firefox does not seem to support `disable-output-escaping="yes"`, so it requires the JS in rss.js
* chrome does support `disable-output-escaping="yes"`, so don't remove those attrs
The JS works by testing `#cometestme`, and then (if needed) looping over elements matching `[name=decodable]` and basically `el.innerHTML = el.textContent`.
Note, `disable-output-escaping="yes"` is a legacy feature from XSLT v1.0; the new way to do it is with character maps.
When I tried those, they didn't seem to work in firefox (which is when I tried the original JS).
IDK if chrome support character maps, but if it does, then that is a good update to implement. TODO I guess.
Handeling Death in the NVB<p>It occured to me that there is an unsolved problem with the NVB: death.</p>
<p>When a voter dies, if there is no connection between their physical death and their cryptographic identity; it continues to live on. This brings up a new-ish toxic market: dead people's ID. In short, since they don't expire they essentially become a 'vote for hire' if they can be recovered. Artificially inflating the voting pool in this way would almost certainly be to the long term detriment of the quality of governance we are obliged to accept (or is it? I presume yes for the moment).</p>
<p>So, one way to address this is for votes to 'time out'. Let's take a situation like the following:</p>
<p>Voters are empowered once every three months, and many at once. The empowerment of their ID only lasts 1 year at a time (or w/e). During that 1 year they are free to transfer away the right to vote to other identities. Particularly, they can do so through (synchronised?) CoinJoin operations. In this way, provided they only partake with members of their own pool, they can maintain relative anonymity while still linking their identity to only one large batch of people so an expiry date is maintained. The transaction they create will maintain constant voting rights and contstant expiry date. Mismatching expiry dates cause the whole transaction to be flagged as invalid.</p>
<p>That sort of situation would largely solve the problem. People who die are known and thus can't validate, so their token expires.</p>
<p>Aditionally you can choose your pool by timing when you register, or abstaning (by letting your token expire for a 3 month period or w/e, then revalidating for another block).</p>
<p>I guess people can also elect to be empowered instantly but this isn't the default and will lead to less privicy. Political active people are good candidates for going straight away, but those valuing secret ballet are encouraged to wait.</p>
https://xk.io/n/2012