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
If "naively" creating custom tag mappings, you may run into this exception:
Uncaught RangeError: Maximum call stack size exceeded
at Object.code (myHtml5Preset.ts:160:12)
at myHtml5Preset.ts:72:72
at k8 (utils.js:7:33)
To reproduce, create a tag-rule that generates "itself as child". For example, for parsing within CKEditor 5, we need to represent [code] as <pre><code>. If we naively adapt the code from HTML5 Preset for Blockquote:
The problem: As parents are processed first, the newly created code will be processed afterward, so that we end up in an endless loop resulting in the RangeError given above.
Workaround:
As the above "naive mapping" may be a result of not fully understanding the internal processing in BBob, the suggestion is to actually "fix" this issue by documenting this possible workaround as "best-practice":
This workaround tricks the processing order by creating an intermediate node htmlCode, that is resolved once the children of <pre> created by the original code rule are processed.
The text was updated successfully, but these errors were encountered:
If "naively" creating custom tag mappings, you may run into this exception:
To reproduce, create a tag-rule that generates "itself as child". For example, for parsing within CKEditor 5, we need to represent
[code]
as<pre><code>
. If we naively adapt the code from HTML5 Preset for Blockquote:BBob/packages/bbob-preset-html5/src/defaultTags.js
Line 82 in 3575982
We end up with a rule like this:
The problem: As parents are processed first, the newly created
code
will be processed afterward, so that we end up in an endless loop resulting in theRangeError
given above.Workaround:
As the above "naive mapping" may be a result of not fully understanding the internal processing in BBob, the suggestion is to actually "fix" this issue by documenting this possible workaround as "best-practice":
This workaround tricks the processing order by creating an intermediate node
htmlCode
, that is resolved once the children of<pre>
created by the originalcode
rule are processed.The text was updated successfully, but these errors were encountered: