Comment 14 for bug 826441

At the moment there are a few outstanding bugs, which kalikiana and I were looking into on IRC, but for the record:
- changing font doesn't update the font-forcing css until that option is toggled (fix pending)
- user addons is not applying its stylesheet when enabled (a mere oversight)
- "alway use my font choices" is not applying its css on startup--it must be toggled first (another simple oversight)
- when multiple hash table entries are concatenated it seems that there's some corruption of the data--maybe there are some strings being used as-passed which are later freed?
- existing values of user-stylesheet-uri (such as from the previous run) will affect pages until a style rule is added, at which point it will be replaced outright; this can have odd results if styles are not added.
- there is no alternative to user-stylesheet-uri for end users (though this is not critical really; user addons mostly suffices now, though kiosk-style applications and users who want a static style would benefit from a direct replacement in MidoriWebSettings)

I don't mean to be rude, but I feel that those of these issues that pertain directly to the implementation of the style api were solved elegantly and more efficiently (c.f. code paths for adding or replacing a style) in the patch I composed. Maybe it's worth looking over more closely (in particular, the list-based caching of style string lengths and the midori-user-stylesheet-uri property)? An adaptation of that implementation to use the string-id API would be quite straightforward--perhaps maintain a list of the string ids in parallel with the numerical id list, or a hash table of string->numerical id.

Alternatively we can approach the bugs here directly, but I'm not very satisfied with the efficiency of regenerating the entire global style via repeated appends on every update.