Deprecate [*] and use [li][/li] instead

These RFCs were either rejected or have been replaced by an alternative proposal. They will not be included in phpBB.
User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Deprecate [*] and use [li][/li] instead

Post by brunoais »

Let's see...
Currently the lists are made as:

Code: Select all

[list=1]
Wtf item
[*]Item1
item1
[*]item2
[*]item3
[/list]
Well... I'm makin' a parser that follows XML parsing rules. I have ways to parse this but they consume a butload of resources with checking and verifying, etc...
So, what I'm asking is to make the [li][/li] the new official BBCode for a list item and deprecate (not remove yet) the [*] as the official BBCode for the list item.
By making this I can optimize the parser such that it parses list items much much faster and without the need of extra logic in the list BBCode.
The problem is that the only way I found to properly parse the [*] is to break the parsing flow and to make further testing and recovering from misplaced [*] specially made for that tag. You bet that all that is a pain for the parser (not for me, the programmer).

Anyway, if one has a good idea about how the tag [*] can be taken care of, then pls do tell. I'm unable to come up with good ideas for parsing, for now.
Anyway, we may also use [*][/*], if you think it's better.

Senky
Extension Customisations
Extension Customisations
Posts: 315
Joined: Thu Jul 16, 2009 4:41 pm

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by Senky »

Using WYSIWYG editor, it would be much much easier for users to use it (even without noticing it), so I am +1.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by MichaelC »

+1
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
Vinny
Style Customisations
Style Customisations
Posts: 129
Joined: Thu May 20, 2010 4:01 am
Location: Brazil
Contact:

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by Vinny »

+1

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by nickvergessen »

Keep in mind, that we need to be able to parse [*] anyway

It does not really make a lot of sense to introduce a second thing for it.
Also what should happen to text outside of [li] but inside of
  • , so your "wtf-item" will still be a case you need to handle?

    Also keep in mind, that Users that write posts, might not know, what [li] is about. So I think using
  • would be the better idea. In fact, you can already use [/*] now iirc. So no problem for me adding that to the default button output. However as
  • still needs to be parsed, even without
  • I don't really see much advantage here.
Member of the Development-TeamNo Support via PM

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by brunoais »

The problem is the XML-like parsing. The general parser does not have the concept of a tag that is not closed.

Before you tell anything about that, note that it has the concept of a self-closing tag.
By using opening and closing tag, the general parser can deal with this and solve the nesting problems.
What's between the [/li] and [li] is just rubbish that is ignored as [list] only allows [li]'s (or [*]'s) as its children.

Textually, from the POV of the user, there's no advantage, but there's a whole bunch of advantage in the parser itself as it simplifies the parser for both tags necessary to make the list.

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by nickvergessen »

currently I use
  • [.list]
to move things one tab in sometimes.

But I don't see a problem in parsing [*] as </*><*> and [/list] as </*></list> if a [*] was added and reverting that on editing, because the current way is much easier for the user. Also IIRC thats what the parser does right now?

Speaking of XML-like parsing. One idea of the new parser was to allow things like

Code: Select all

[b]bold [color=#008000]bold+color[/b] color[/color]
(just want to ensure that you got that?)
Member of the Development-TeamNo Support via PM

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by MichaelC »

brunoais wrote:Textually, from the POV of the user, there's no advantage, but there's a whole bunch of advantage in the parser itself as it simplifies the parser for both tags necessary to make the list.
You still need to support parsing [*]
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by brunoais »

nickvergessen wrote:currently I use
  • [.list]
to move things one tab in sometimes.
It's part of the "spec" I was given to make sure that the output of this is compliant to HTML5 and xHTML.
In order to follow that, the parser I'm developing must not allow that.
nickvergessen wrote: But I don't see a problem in parsing [*] as </*><*> and [/list] as </*></list> if a [*] was added and reverting that on editing, because the current way is much easier for the user. Also IIRC thats what the parser does right now?
That was the idea. Even though it requires more extra twist in it. And I was trying to get rid of that "preparser" that exists in the parse_message class... Guess I'll make an exception.
nickvergessen wrote: Speaking of XML-like parsing. One idea of the new parser was to allow things like

Code: Select all

[b]bold [color=#008000]bold+color[/b] color[/color]
(just want to ensure that you got that?)
Oh!... Oh... Eh... When I asked about the rules I was supposed to follow, I wasn't told about that. Besides, no1 opposed to me when I wrote the rules I was going to follow when making the parser.
It's easy to make the changes for it to do that but I'll try going through the hard path to make it as performance efficient as it can be. Anyway, eh... It will cost in processing... I'll do my best to apply that in a fallback before failing to parse those. As it is currently, one of those two would fail to parse and would be ignored. I believe it would be the color tag.
Any other surprises to the spec I developed that no1 rejected... until now?
MichaelC wrote:
brunoais wrote:Textually, from the POV of the user, there's no advantage, but there's a whole bunch of advantage in the parser itself as it simplifies the parser for both tags necessary to make the list.
You still need to support parsing [*]
Yes, but it would be as a fallback. So the processing flow would evolve differently.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC] Deprecate [*] and use [li][/li] instead

Post by Oleg »

Replacing * with li and requiring a closing [/li] seems very annoying.

You still have to support [*], therefore I'm assuming the performance difference being discussed applies only when [*] is used? How big is this difference exactly? I'm sure it's not enough to matter.

Please leave [*] alone.

Post Reply