You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With explicitCharkey: false (default), parsing results are predictable:
<x>y</x> -> { x: 'y' }
<x></x> -> { x: '' }
<x> </x> -> { x: ' ' }
<x>\n</x> (newline) -> { x: '\n' }
With explicitCharkey: true, parsing results can be surprising:
<x>y</x> -> { x: { _: 'y' } } (ok)
<x></x> -> { x: '' } (bad, no _)
<x> </x> -> { x: ' ' } (bad, no _)
<x>\n</x> (newline) -> { x: '\n' } (bad, no _)
When users set explicitCharkey: true, they probably expect an _ property in all objects. Currently, they have to distinguish the case where an element contains only whitespace from other cases and use different code to access the text content.
The text was updated successfully, but these errors were encountered:
With
explicitCharkey: false
(default), parsing results are predictable:<x>y</x>
->{ x: 'y' }
<x></x>
->{ x: '' }
<x> </x>
->{ x: ' ' }
<x>\n</x>
(newline) ->{ x: '\n' }
With
explicitCharkey: true
, parsing results can be surprising:<x>y</x>
->{ x: { _: 'y' } }
(ok)<x></x>
->{ x: '' }
(bad, no_
)<x> </x>
->{ x: ' ' }
(bad, no_
)<x>\n</x>
(newline) ->{ x: '\n' }
(bad, no_
)When users set
explicitCharkey: true
, they probably expect an_
property in all objects. Currently, they have to distinguish the case where an element contains only whitespace from other cases and use different code to access the text content.The text was updated successfully, but these errors were encountered: