Previously setting element content like "Barnes & Noble" would result in error.
So I added appropriate encoding using @xmlEncodeSpecialChars@
Encode XML special characters when setting element content
Encode XML special characters when creating elements with content
What if you actually intend to inject xml entities as content and have them not be escaped? Maybe .text() implies things are escaped?
My only concern with this patch as it is, is that it changes the behavior of the .text(str) function call which technically makes it a breaking change. When you say "Barnes & Noble" results in an error, what do you mean?
@shtylman I understand your concern, however current behavior is just crash (just try to run tests from my patch without patching library).
I believe there should be something more appropriately named for injecting raw XML, e.g. innerXml property.
I assume it's because the "&" needs to be encoded. I'm not in a position to test right now. The simplest thing to do would be to expose the encoding method. Then the user can decide if they want it or not. The problem with doing this kind of thing automatically is them you expose people to double encoding problems.
Given that the current behavior is just to crash, that seems like a problem. I am inclined to say that the text function should encode by default (much like setting text in html elements). And another method would be for non encoded. The problem with providing a separate method to encode is that no one will use it cause it just means you have to use it everywhere you call text if you want encoded text.
@polotek @shtylman Another important point is that getter of text property returns decoded characters, so to match its behavior setter should encode. So prior to my fix property was just inconsistent.
For attributes, we're using xmlEncodeEntitiesReentrant. I'm not sure how that relates or if it fully covers encoding in attributes. We should write a test for that too and fix it if it's also failing.
@polotek xmlEncodeEntitiesReentrant does too much – it also replaces all non-ASCII stuff with entities (at least per its docs).
I have pushed your fixes to master. They will be deployed with the next version. Thanks.