Size BBCode 'nesting' problem

[excaliburj]

Sorry if this has already been addressed. This applies to 2.0 RC3 (and, obviously, current code on this site).

If using 'unitless' size value in the size BBCode, this is the displayed (and, I think, expected) behavior:

Code Select Expand

Normal - [size=3]At size 3 - [size=4]Up to 4 - [size=5]Up to 5 - [/size]After 5 (s/b 4) - [/size]After 4 (s/b 3) - [/size]back to normal.
Normal - At size 3 - Up to 4 - Up to 5 - After 5 (s/b 4) - After 4 (s/b 3) - back to normal.

But when using units, display is not what I believe would be expected:

Code Select Expand

Normal - [size=12pt]At size 12pt - [size=18pt]Up to 18pt - [size=24pt]Up to 24pt - [/size]After 24pt (s/b 18pt) - [/size]After 18pt (s/b 12pt) - [/size]back to normal.
Normal - At size 12pt - Up to 18pt - Up to 24pt - After 24pt (s/b 18pt) - After 18pt (s/b 12pt) - back to normal.

Investigation shows that BBCode parsing has a specific 'disallow_children' restriction on further 'size' entries within a 'size' span. But only for size when a unit is given. As far as I can see, except for prevention of nesting URIs within URIs, this is the only place where 'disallow_children' seems to be used.

Is it really meant to have this be OK:

Code Select Expand

Normal - [size=3]At size 3 - [size=24pt]Up to 24pt - [/size]After 24pt (s/b 3) - [/size]back to normal.
Normal - At size 3 - Up to 24pt - After 24pt (s/b 3) - back to normal.

And this disallowed:

Code Select Expand

Normal - [size=24pt]At size 24pt - [size=3]Now at 3 - [/size]After 3 (s/b 24pt) - [/size]back to normal.
Normal - At size 24pt - Now at 3 - After 3 (s/b 24pt) - back to normal.

Is there an actual purpose to this restriction or should it be removed?

[vivid]

reference:
//http://www.simplemachines.org/community/index.php?topic=396767.0

[excaliburj]

So, it got fixed in the development version.

And apparently, the disallow_children was removed.

Of course, that's only an assumption because not a single team member bothered to comment or point to a bug tracker entry.

Thanks a bunch.

[Aleksi "Lex" Kilpinen]

Unitless Size tags were not parsed correctly in RC2 - I'm unsure if it got fixed in RC3 or after RC3.

[excaliburj]

When I posted this originally, it was not fixed here on this site.

The original post did not display correctly.

It was fixed in the build used here - not in RC3.

[excaliburj]

And it was NOT the unitless which were displaying incorrectly.

It was the size code WITH units which had the 'disallow_children' limitation on it.

This limitation has obviously been removed.

[Aleksi "Lex" Kilpinen]

Oh, sorry - it seems I didn't read your post carefully enough, anyway - good that it's fixed now, right?

[Norv]

There was no bug tracker entry. (not all issues are tracked, though many are)

But yes, this was just solved in the development version, you're right, excaliburj. It will be in RC4.

Thank you for the report and discussion.

[vivid]

There was no bug tracker entry. (not all issues are tracked, though many are)

But yes, this was just solved in the development version, you're right, excaliburj. It will be in RC4.

Thank you for the re

Hi Norv,

This issue still unsolved now we are in v2.0rc4.

[Norv]

vivid, can you please tell:
Can you replicate it on an unmodded RC4?
Can you replicate it on this forum?