A year ago as a project to learn JavaScript and CSS, I wrote a deck planner for Magic: Duels of the Planeswalkers. One of the features was a rich HTML card list which could be posted to the Wizards.com forums. This was broken by the big forum change, and I'm investigating doing something similar or even better here. The result looked like this inside a user's post:


In this example, the cards are grouped by "Purpose", a set of custom categories that I defined in the deck planner for each deck. You can also group the cards by casting cost, type, or some other things. Within each group are subgroups based on card cost (with color banding for each subgroup). I gave each deck in the game its own color scheme.

Being able to create posts with these neat, informative deck lists became very popular in the old DotP forum. One thing I'd like to explore with you is whether we can come up with a scheme where non-DotP Magic players at these forums could somehow have the option to create fancy listings like this, without needing a third-party app like my deck planner. I'm not aware of any other forum that has something like this, so this could be a feature to make NoGoblinsAllowed really stand out in the Magic community.

A mockup of the table in HTML is here for you to inspect. Note that the prefix and postfix text is wrapped in a table to protect it from the random line breaks that the old forums used to insert, which won't be necessary here. The main things to know are that a nested table is used to put the sideboard on the side, and the color banding is done at the <tbody> level.

These forums don't support direct posting of HTML code, so we'd have to work something out using custom BB tags. I can see a few options. Once we agree on a plan, I'll design the exact tags for you.

Some phpBB questions
I would figure these out myself instead of bugging you, but the documentation is lousy, and I don't have access to an installation that I can experiment with.

Question 1 The phpBB documentation has no technical details about custom tag parsing, just examples, so I don't know exactly what the rules are. From what I understand, you define the tag something like this:
Do the = and , characters have special meaning to the parser, or can I use anything there and just expect it to be matched character by character? For example, can I use a # or | character to separate the parameters instead of a comma?

Question 2 I assume that you can't do optional parameters. In the example above, would it be possible to use the tag with one parameter?
I'm guessing that would be treated as invalid and remain unsubstituted. How about if I appended two commas with no parameter text? Would SIMPLETEXT2 and SIMPLETEXT3 become empty strings, or would that be invalid also?

Question 3 The built-in url tag takes an optional parameter -- is that a magic feature, or is it just defined as two separate custom tags, one with parameter and one without?

Question 4 The {TEXT} regex says that it accepts any characters. I assume it halts when it sees the characters for the closing tag. What if you want to use multiple {TEXT} fields -- how do you separate them? Can you define a tag like this?


Question 5 Can you execute custom code at the time a tag is being processed, so that you can do something more complex than just substituting matched parameters into an HTML template? Is this a no-no for performance reasons, or would it be ok for simple things like a quick text replacement? How do you guys implement the "deck" and "card" tags to do autocarding? Is the tag substitution done at post time and the output cached, or does the work get done every single time the post is rendered?

Question 6 Are inner nested tags fully processed before the outer tag gets parsed, or is the overall tag structure determined before any substitutions are made? For example, say I have these tags:
What happens when the user types this?
If the inner tag is fully processed first, I expect to get "((left )) ((inside)) (( right))".
If the outer matching is done first, I expect a failed match that turns into
Which one happens?



Option 1: low-level formatting codes, imitating HTML
We define some tags (prefixed with d for deck).
that just create an HTML tag. Sadly, there's no way to specify the entire style in one tag parameter, because phpBB doesn't provide a regex that will accept colon and semicolon (other than the unsafe {TEXT}). So I guess the custom tags would need a bunch of parameters to make room for all the style attributes.



This assumes that parameters can be either omitted (see Question 2 above) or given as a blank space. If fewer than 5 attributes were given, some invalid empty style attributes ":;" would be generated. I don't think that would cause problems for browsers reading the HTML, but I'm not positive. If I needed more than 5 properties, I could ask you for a {d_table_style10} with more slots. It would be nice if you could run a regex replace so that I could provide the style as one string using say ++ and +++ as separators which you could turn into colon and semicolon, so let me know if that's possible.

Pros
+ Extremely flexible.
+ I and others can use these tags to create new table formats without having to bug you for new custom tags.
Cons
- Unreadable to humans
- Not creatable or editable by users
- Take up a lot of space, stuffing posts with dozens of lines of gobbledygook in edit mode (including when quoted)
- Specifying HTML tag attributes, e.g. COLSPAN on <TD> tags, requires a new custom tag with different parameters

Option 2: low-level semantic codes, imitating XML
We could create higher level tags specific to the layout used in my tables. A motivated human being would be able to create or edit tables using these tags, although it would not be trivial.

These would take high level parameters containing the relevant data, and hide the HTML details.
d_deck creates a <table> and takes these params
- border color
d_group creates a <tbody> with a <tr> for the heading
- group label parameter (which would have to be given in the body of the tag, as in Question 6 above
- background color
d_subgroup creates a <tbody>
- background color
- subgroup label (but there is a problem -- see below)
d_card creates a <tr> and all the contained <td> cells for a card
- card count
- card name
- card mana cost (as rich text including mc tags)
d_sideboard
- contains a bunch of text which should ideally get autocarded automatically

The subgroup label is a problem. As you can see in the example image, I stuff the subgroup label into the first cell of the first card row in that subgroup. Later cards in that subgroup show nothing in that first cell. Unfortunately, while parsing the d_subgroup tag, we can't "save a global variable" with the label for use by the d_card tags. Depending on your answer to Question 6, I think there might be a (hacky!) way to do surgery on the generated HTML for the card rows to stuff the subgroup label in. This could be a breaking issue, so if you know a clean way to do something like this, let me know.

Pros
+ Human readable
+ Somewhat human editable
+ Should take up fewer lines in a post while being edited
+ More formatting can be done via CSS instead of repeated in every post as tag-level HTML styles
Cons
- Inflexible -- the structure and formatting are baked into the tags, so if someone wants to make a different kind of table (e.g. for collectors), they need to create new custom tags
- Even in my case, I have a second format for sealed decks that breaks the large sideboard into a group of blocks by card color below the main table, so I'd need more custom tags for that feature
- The subgroup label issue mentioned above may wreck the whole idea

Option 3: the whole enchilada
The dream is to just define a tag called "fancydeck" which takes a list of card names like the "deck" tag. This would scan a card data file on the server, group and reorder the cards, and populate an HTML table with additional data about each card automatically.

Obviously this requires server-side code to run (see Question 5 above). I may be able to help with code to generate the card data file, as I have to do that myself for the deck planner.

Pros
+ Super easy and awesome
+ Best forum deck lists in existence
+ Completely human readable and human editable tag text
Cons
- May not actually be possible
- Questions about performance
- NoGoblinsAllowed staff responsible for rebuilding the card data file every month or two when Wizards releases a new card set


The plan
I guess that option 1 is the most straightforward choice. I could make it work in the deck planner with some work. If someone wants to build, e.g. a collection manager app that generates card lists with set/condition/price information, they could use these tags to build a fancy card list in the same way that I do.

Neither options 1 nor 2 will see any takeup by the community here--I would be the only one using them. It would be cool if people in the other Magic forums could make fancy deck lists too. Perhaps the post interface could gain a "fancy deck" button which pops up a small form where the user can set a few parameters and include a list of cards, and then generate the codes for a fancy card list? This could be about as easy to use as option 3, but without the performance issues. Actually building the table isn't too complicated, but again you guys would have to be responsible for maintaining an up-to-date card data file for the code to use.

Some forums (like the old Wizards forums) pop up a special tag-building UI like this when you click the "link" button, giving you an easy way to enter the URL and other properties. I don't know if this is easy in phpBB.

Whew! If I knew more about what is easy and what is hard for you folks to do with the forum software, I could ask more targeted questions. Now that you get the idea, let me know if you've got any tricks that could help. Once we settle on an approach, I'll generate the exact custom tag templates that are needed and then we can test things out. Thanks for your willingness to investigate this.

Neosilk just pointed this out to me.
I'm forwarding it to Welder.

Thanks man.

Oh, excellent. I was hoping you would stop by. Welcome!

Yeah, the phpBB documentation is so, so bad.

In general, the answers to your questions are all "it works like you would expect in a parser that uses only regular expressions". That is, it generally works, but is full of annoying inconveniences.

= and , have no special meaning. Defining tags like

works exactly as you would expect. phpbb will actually just think of it as a custom bbcode named "tag#".

1. Optional parameters don't work.
2. Using a single parameter in the tag defined above wouldn't work either, as the regular expression phpBB generates for that tag wouldn't match.
3. The regex used for SIMPLETEXT replacements is [a-zA-Z0-9-+.,_ ]+ . The + at the end means it wouldn't match the empty string, so having commas with no parameter text would also fail to match.

Note: it's very easy to change the regexes used in matching TEXT, SIMPLETEXT, etc. Adding, say, ";" to the list of characters allowed in SIMPLETEXTs is a one-character change; so too would be allowing zero-length SIMPLETEXT matches.


It's a built-in tag with special-cased behavior (like quote, code, list, etc.).

You can do separate custom tags that differ only in the parameter strings (e.g., card and card=).


Your example will work fine.

Note that the {TEXT} regex — (.*?) — is non-greedy:

1. Not with normal custom bbcodes. It's possible to fiddle with the bbcode parsing engine to add custom bbcodes with more complex behavior (this is how our dice mod works), but it's annoying and difficult.
2. The deck and card tags use a custom bbcode replacement that just wraps the input string in a <span> or <div> with a particular class. When the page loads, a Javascript function finds all instances of div/spans with the right classes and converts them into displayable things. I set things up this way for a few reasons: it's far easier than hacking in a new bbcode with complex behavior; I wanted to get it working quickly; and it moves the interesting behavior to a level that I'm more familiar with and is much simpler to debug. I do intend to move deck tags at least into PHP; the autocards require Javascript anyways to set up the nice tooltip images, so we might as well handle the rewriting into a link in JS as well.
3. Substitution is done every. single. time. a post is rendered. It's horrible and wasteful and I hate it.

Parsing goes, generally-speaking, left-to-right, so the latter. Though I did have to actually try this one out to make certain.
Result:



Options:

1. Ew ew ew. It would be easy on my end, but I really don't want to do things that way.
2. Better in concept. The subgroup label thing could be "solved" (really, worked around) by having an extra parameter for d_card that controls the label shown in that row; just set it to " " or &zwnj; or whatever if that row shouldn't get a label.
3. Obviously this would be best for users, but the resources required to fetch a information about a bunch of cards and format the deck every time a fancydeck is rendered worry me. It would probably be fine for now while the site is still quite small, but the work involved scales approximately quadratically with the number of people talking about deck lists.

Something like this is probably the best compromise between ease of use, difficulty of implementation, and resources required. The user puts in easy-to-understand stuff, it's usable for non-DotP decks while being extensible for DotP-specific info, and by handling card lookup stuff on (well, before) submitting the post means it's one-time work rather than every-time-viewed. Also, most of the work on my end would be javascript, which I'm far happier to work with than PHP.

I'll look into how to add buttons with custom behavior (like popping a window for inputting text!) to the posting interface; it shouldn't be too hard, as something very similar already exists in the "View more smilies..." link.

For input format, I'm imagining the basic format for what goes into the dialog window will be similar to that of [deck] tags:

We can separate sideboard/unused cards with some hardcoded separator, or just special-case group labels "Sideboard" and "Unused". Header/footer information (header: "A library for the [b]Izzet 2014[/b] deck [i](Dodge and Burn)[/i], etc."; footer: "Made with MysteriousMisterP's deck planner", etc.) could be handled similarly.

When the user hits the "OK" button on the dialog, it'll go out and fetch card info from a RESTful service running on nogoblinsallowed.com, compute counts for mana costs, groups, etc., and add the appropriate tag structure into the post at wherever the cursor is.

I realize that by suggesting this I'm committing to maintaining the card database, but I can handle that. Also, I've been wanting to switch to using magiccards.info for autocarding but have held off because they index cards by set/language/collector number rather than name, and there wasn't a good/pressing reason to set up a database to handle the conversion. But hey, now there is!


[edit to clarify] The input format in the fancy deck input thing isn't something you need to worry about. Your tool can spit out the [d_*] tags; the editor is just a way to make them usable for other people as well.

Also, it turns out that it is trivial to add new buttons with interestingly relevant behavior.

Thanks for the answers. I have a few more low-level questions, then I'll have another post with higher level design discussion.

Is there currently a way to attach or PM files here? I got a security rejection even for a .txt extension, but maybe I did something wrong.

To test my understanding of the parsing sequence, am I correct that the following custom tag would repeat its body text twice, once bold and once italic? That is, can BBCode be mixed into the HTML of the substitution text, and still work correctly?


Oh, this is interesting! So is it also easy to add new regexes? If you could add a {CSS} regex that matches inline style sheet strings, that has a big impact.

That's too bad. I will have some further questions related to this, in another post.



If it was possible to create a new {CSS} regex, that should remove most of the yuck factor from option 1, I think.

The subgroup label workaround you mention is of course possible, but since it breaks the semantics and exposes the implementation details, it makes option 2 pretty difficult for users trying to use the tags by hand. If option 2 isn't something users can use and is only useful programmatically, then option 2 loses some of its benefits over option 1 while still having the disadvantage of being less flexible. That's one big reason I'm currently hesitant about option 2, but it needs more thought. (But option 2 might still be less text overall, which could be important.)

I've been thinking about how to automate things as much as possible and give the user a clean experience. I agree that option 3 is unacceptable if all the work gets done at render time. However, is it possible (and reasonably straightforward) to hook into phpBB at the time a post is submitted (or previewed) and modify the post's stored code behind the user's back? Similarly, can you intercept and modify the post code shown in the edit box when the post is edited or quoted? If such a thing is possible, I have some thoughts on how to make the overall user experience much nicer. I'll post more about this later.

-----
Edit: FYI, as an example of flexibility, here is an HTML example of the output from the deck planner for a sealed deck from DotP 2014. Note that there is more structure in the sideboard listing, and there is a second table for cards in completely unused colors. This second table limits itself to 3 cells per row, for width reasons.

If we get too specific with hardcoded behavior and semantic tags, you guys will have to deal with requests for new tags every time somebody wants to do something slightly different like this. I wanted you to know that the deck planner format has evolved over its one year life with a few special case tweaks. Such changes could generate unwanted work for you if the forum hardcodes too much to begin with.

Goals
A list of user scenarios will help focus our planning. Please chime in if you think of others. Not all of these are of equal importance.

1a) User1 creates a post with 2 decks in it, and writes text before, between, and after the tables
1b) User1 edits the post and wants to modify the text
1c) User1 edits the post and wants to remove a table
1d) User1 edits the post and wants to modify a table

2a) Quoter1 quotes User1's post and writes some text before, between, or after the tables
2b) Quoter1 quotes User1's post and wants to remove one of the tables
2c) Quoter1 quotes User1's post and wants to modify a table with suggested changes

3a) Collector1 wants to manually create a table of cards with information like condition, sale price, and set icon

4a) Dev2 wants to write a tool for collectors that creates card tables with info like market price etc.

The scenarios suggest some goals.

• Round-trip capability. (High priority) There is a lot of value in being able to edit a table after it has been created. Users of my planner on the wizards forums could do this by going back to the planner and re-exporting the table. I later introduced a couple of methods which let other people recreate a posted table in their own instance of the planner (by encoding the list in a string, or later a hyperlink).
• Brevity. (Medium priority) On the old forums, users only saw the HTML tag soup when first pasting the code generated by the planner. After previewing, editing, or quoting a post, the table appeared as rendered HTML because wizards.com used a rich text editor for editing posts. This made it easy for humans to edit text or delete the whole table. Because NGA always displays BBCode in the edit box, users will always be faced with a huge block of unreadable tags that is bigger than the default edit box size. That makes it hard to navigate and edit the post.

Option 3 would give the best round-tripping and brevity, if it were possible.

Tag block
If we use a pop-up deck editor, then we are stuffing a bunch of formatting tags into the post. Round-trip means that we need to be able to reliably parse the post contents and present it as a simple card list again. Directly parsing the formatted output is probably not a good approach because any future changes to the formatting tags breaks the parser, which only needs to get the data. (Option 2 reduces, but does not eliminate this problem.)

So, I suggest that we prefix the formatting output with a special "d_begin" tag that does not render, which can contain the structured source data for easy access. When the user wants to reopen the pop-up editor, we read this data tag and simply ignore the formatting tags, regenerating them when the user commits their changes. For robustness, we probably want a "d_end" tag to make it easy to automatically select the entire block of tags. In between, we use the option 1 or option 2 tags to actually render the table.

The begin and end tags can also contain a line of === or *** to visually delimit the block of tag soup, making it a little easier for the user to visually skip over the table tags when editing post text.

I think that we don't want the source data to be human readable. If d_begin just contains the card counts and names, a user might edit the text directly without using the pop-up editor, and then be baffled when the displayed table in the post does not contain the same information. We can use the multiverse ids (MIDs) of the cards to both shorten and hide the source data. The MIDs have a many-to-one relationship to card names, so we can always recover the text. We can just use the MID of the oldest or newest printing. Instead of having "3x Flames of the Firebrand, 2x War Priest of Thune", we would have "3x370824,2x275698".

Our brevity goal is not going to be well met. If you look at the source HTML for the sealed deck output in my previous post, you'll see that it will occupy several dozen lines in the post editor window. Custom tags and a separate CSS file will reduce this substantially, but it will still be very long. This makes me sad. I can think of a couple of extreme solutions that probably aren't possible. Let me know if you can think of anything else we could try.

• Hack the post editor to suppress or shrink the tag block. A spoiler-like UI would be great.
• Hack the data flow to and from the editor. The user creating a post will simply see a list of card names, as in option 3. On save, server code finds "fancydeck" tags in the post source and generates the formatting tags needed to build the table, inserting them after the "fancydeck" tag. When the post is rendered, the "fancydeck" displays nothing, and rendering the generated tag block is inexpensive.
  
  When a user edits or quotes the post, server code again intercepts and strips the block of formatting tags before sending the text to the client. If the client saves or previews the post, the formatting block is rebuilt.
  
  This gives us the appearance of option 3, with the performance of a more ideal phpBB that was smart enough to precache rendered data. However, I know that this is a scary and nasty way to work around phpBB's limitations.

I will assume neither of these is possible--just wanted to get the idea in your brain for possible future inspiration.

Pop up editor

• An edit box for the deck title
• I suggest two side by side textareas, one for the cards that go in the main table, and one for the sideboard. For convenience, if a user pastes a list of card names into the left box and that list contains a line with only the word "sideboard", automatically split the list at that point and put the remainder in the right box. The text in the sideboard will get parsed similarly to the existing "deck" tag. The sideboard box can be initialized with [b]Sideboard[/b]
  so that users will tend to leave that heading text in place before entering the card names.
• Grouping: I can share with you my .js file that does card grouping and sorting. I have a bunch of formats available, but I think only these are needed here. My experience is that the cost_type is by far the most popular, and it would be nice if the editor can just take any old list of names and rearrange it automatically.
  
  • cost_type - group by cost, subgroup by Land/Creature/Spell/Planeswalker, sort by name (note: I prefer to put lands and X spells in their own cost groups, rather than treating the land and X as just zero)
  • type_cost - group by Land/Creature/Spell/Planeswalker, subgroup by cost, sort by name (note: the wizards.com blog entries have their own fancy deck format, unavailable to users, which groups this way)
  • custom - the user includes group labels (which may include formatting tags) in the list (anything with no numeric prefix is treated as a label). No subgrouping, so color banding is every row. No sorting is done.
  • none - no group header rows, no subgroups, sort by card name, color banding changes each row
• Dark, Medium, and Light colors for the header and odd/even subgroup banding. Can be color picker popups or just textboxes for HTML color text. Default value is "default" which leaves the coloring up to the CSS defaults we create, and does not pollute the tag output with color values.
• Text color for group headers (can just be a checkbox to switch from black to white when the dark color is very dark)

I wrote a card management app for my own use to manage the data used by the deck planner, and it uses a side-by-side textarea arrangement for the starter vs unlockable cards in each deck. I've found it useful because vertical space is more precious than horizontal space. A nice quality of life feature is to display the count of cards in each section. If a user types up their card list and notices that the numbers are not 60 and 15, then they immediately see that there's a mistake. Not at all a required feature, but a cute little thing to consider.

Option 1 or 2?
If you can define a {CSS} regex, then I'm leaning toward option 1 for the formatting tags because of the flexibility.

In a later post I will mock up a full card table using both approaches, and maybe also a CSS file. Seeing the full tag text may clear things up in our minds.

There is another problem that has occurred to me. I've grown fond of using the little box characters to give a visual count of cards, rather than just having a plain text number. (See the example image in the first post.) However, there's no simple way for a custom tag to turn a {NUMBER} parameter into that many instances of a character in the replacement text. If we have to specify the card count field as {TEXT} with the box characters, the idea of "semantic" option 2 tags takes another hit. Can you think of a way to do this in the phpBB engine? I guess this could also be done in client side JS, but I don't want to keep piling things onto client code every time I hit a snag. Also, my DotP output doesn't include basic lands in the table, but for general use we'd need to NOT use box characters if the number is above say 8. So this is kind of a pain if not done in JS.

For the custom colors used by my deck planner (and also by the pop-up editor if you choose to expose that property), there are two ways to go. First, each tag that creates a <tbody> has a variant version that accepts a background color. If custom colors are used, these tags are used and each one has an explicit color specified. That's going to be a couple dozen instances per table.

A second possibility is to have the top-level deck tag emit a <style> tag at the top of the table with the custom colors in it. To make this work, we'd need a way to generate a unique ID on the <table> that the stylesheet could reference, so that only that table has its colors changed. Is there any way to generate the ID using phpBB? If not, client-side JavaScript could scan for these special <style> tags, insert an ID in the stylesheet text, and apply that ID to the <table> tag that immediately follows. (Someday we'll all get to have scoped stylesheet support in our browsers...) This is more awkward to implement, but it shortens the emitted code somewhat.


Tweaks
There are a couple of special case tweaks I've inserted into the planner over its history to improve the output quality.

Open my deck planner and switch to the Dimir 2014 deck. First, group both tables by Type. Note that within each group, the first subgroup always gets the gray color, then the blue. Now group both tables by cost. The 5 cost group in the starter deck shown on the left has only spells. I have written a special test for when the subgroup is by type so that consistent colors are always used for each type subgroup category. You can add or remove a creature in the 5 group, but the Spells category will always be blue. I find that keeping this consistency across groups makes the table much easier to scan. You can use the dev tools to force that 5 cost spells group to be gray, and you'll see that it becomes difficult to quickly see where the creatures vs spells are in the deck.

The second tweak is visible in the Rainbow 2013 deck. The card Progenitus has a mana cost that is 10 symbols long. I've written code to break very long costs over multiple lines, so that the table doesn't become too wide. In a post with avatars using up space on the left and the sideboard on the right, we need to control the table width.

I think tweaks like this add important usability. But we need some flexibility in the tag system we design to make these and future tweaks possible.

Presumably we'll use nth-child selectors to do the <tbody> banding in the CSS (when using the default colors). The special case for type can be handled in a few ways.

• Emit extra tags that generate an empty <tbody> for missing Type subgroups
• Use a data-subgroup-label attribute on the emitted <tbody>, and have the CSS test for values of "Land", "Creature", "Spell", "Planeswalker"
• Emit tags that generate HTML with inline styles for the colors, when the subgroups are by Type

Depending on whether we use option 1 or 2, and the exact details of the tags, some of these may be difficult or impossible.

For the line breaking of long costs, I guess that the tags need to take the cost as rich text with mc tags already applied, rather than plain text that gets automatically wrapped with mc. Then the deck editor can generate the line break in the appropriate place.

For whatever reason .txt is not in phpbb's default list of allowed attachment extensions; I added it.


*Sigh*. I'm afraid not. Following the general principle of "phpbb doesn't work the way you want it to", built-in tags are processed before custom tags. The result is: [b]Some text.[/b][i]Some text.[/i].


Astonishingly (for anything phpbb-related), yes, it's quite simple to add new regexes. We'd still need a regex to use but that shouldn't be hard. Off the top of my head

should be good enough for most things (but is certainly far from perfect).

[edit] phpbb, please stop stripping out my backslashes.


Agreed.


Yes, you can hook into the code that runs when a post is submitted, modifying what gets put into the database. Right now it adds UIDs to bbcodes, removes too-deeply-nested quotes, sanitizes the input for database storage, and possibly other things. I'm not very familiar with how to hook into this part of things.


Given that the blob stored in the database has to get translated back to what the user expects to see, I'd say yes, it's possible. I don't know how to do it (yet!), however.

Argh, have to run (work in five hours, should probably sleep). I'll get to the rest later.

But first, an idea that may be of interest:
The dice-rolling mod we have is designed to keep players from cheating: re-rolling until they get a good result, quoting/copying good rolls, etc.. It does this by replacing normal dice codes — [dice]3d6[/dice] — with special forms that are linked to that specific post — [dice]{post_id}:{roll_idx}[/dice] — on post submission. So, when editing or quoting, the third dice roll in post 1234 would get shown as [dice]1234:2[/dice]. It works by setting up a separate sql table containing all dice rolls, with associated post id and roll indices.

We could probably do something similar with fancydecks to clean up the posting editor — set up a table containing all fancydecks submitted, along with UIDs, and only show e.g. [fancydeck]{ID}[/fancydeck] when editing or quoting.

LOL

LOL

LOL



You seem like a nice enough person, and I wouldn't want to condemn a nice person to mucking about with phpBB internals,

... but ...

The fact that the forums are already mucking about with transforming post text is pretty exciting! It's starting to sound like [fancydeck] might, just maybe, be possible. On the one hand, not having to create a pop-up editor partly pays for the effort in learning how to do the post transformation, but on the other hand you'd find it much more fun to build a little UI in JS rather than hacking PHP, so still not so great for you.

For now I'll press forward with the examples of option 1 and 2 so we can examine the the code text, since it seems we'll need something like that underlying the tables even if option 3 turns out to work.

I just had a thought about tag parameters. Can you use capturing groups in a custom regex, or do you think it would be straightforward to add? If so, then perhaps we could work around phpBB's limitations and define tags with optional parameters. I'm thinking something like
This would generate an invalid color entry in the inline style if the color was omitted (icky), but that shouldn't have any effect on how the HTML renders. Anyway, another random idea for you to keep in the back of your mind.

OK, here we go with a first draft of the tags for the different options. I'll use a sealed deck from the planner as the example, since that's the most complex output that currently exists.


I'm going to assume that there's no way to do optional parameters, so multiple variants of some tags will be needed.

For readability I'll give meaningful names as tag parameters rather than {SIMPLETEXT1} and so on. The {} regexes to use in the actual tag definition should be obvious in most cases.

Regarding optional parameters (namely class and style), I think the value to future users in being able to specify these on the tags is worth some tag proliferation. Since omitting a tag is very awkward--requiring a comma and dummy space, or something like that--it seems that the best option is to define tags for all 4 combinations of those two parameters. So we'd have tag, tag:c, tag:s, and tag:cs. We need at least two variants anyway to support no params and both params, so 2 more doesn't seem that bad. We don't need an ID param because posts can be quoted, which would create duplicate IDs on the page. The only other attribute that I need is <td colspan=5>, which will just get a separate custom tag.

I am using comma to separate multiple parameters, even though the style parameter can contain commas itself (in font-family). I hope that putting the style always as the last parameter is OK, but there might be problems with greedy matching. We can easily change the parameter separators to a pipe, but for now I'll stick with the standard = and , notation that other tags use.

Class names used:

• fancy-deck-title formats the <p> with the deck title
• fancy-deck on a <table> applies the card list styles
• fancy-deck-wrapper clears formatting and padding on the wrapper <table>
• fancy-deck-sideboard on a <td> applies the sideboard text styles

In both options 1 and 2, we can prefix the table with a <style> tag to override the colors, so they don't have to be repeated as inline styles. To make this work, the <table> needs an additional unique class for the stylesheet selectors to reference. Creating these classes and ensuring that the <style> and <table> agree on the class is done differently for the two options. Note: we can't use IDs because the table may be quoted in another post, which would result in two <table> tags having the same ID on a single forum page.

The square bullet character ■ used for card counts is &#x25A0;. If we use options 1 or 2, users have to generate this character by hand. Perhaps we can invent a way to turn a decimal number into repeats of this character, but we would need a safeguard that leaves the number in decimal if greater than 8 or so.



Option 1
These tags are generic HTML equivalents that can be used to generate any HTML table. They are customized for the deck tables by adding classes. Custom colors are either done using a style tag as shown in the example, or by applying inline styles to all the tbody tags.

If a custom stylesheet is used to set colors, the person or app that generates these tags is responsible for generating a unique class for the <table> and using the same class in the stylesheet selectors. A simple date and time string should be good enough to prevent distinct tables from ever having the same class. (Quoting the table will duplicate the class, but that's OK because both instances should look the same anyway.)

A single post can easily have over 255 table cells in it. Since I use nested tables to put the sideboard on the side, the wrapper table needs to use a different custom tag for its <td>s. For the numerous interior <td>s, we use a custom tag that does not support nesting, so that the 255 limit is not reached.



Note that this example is slightly more complex than would really happen. I've included the extra sideboard table that only applies to the sealed deck format in my planner (not something you need on the forums). I've also included the d_data tag that the forums would use for round-trip capability (which my planner would probably not create). We would never have both in the same table, but I've included both here.




Option 2
Since we're leaning toward option 1, I've left this example missing for now, but I can mock something up if there's interest.

Option 3
There's just one tag:


The {TEXT} is a list of text lines which are treated as card counts and names, or as group labels, as described below. Any lines after a line containing only the word "sidebaord" (case-insensitive) is bumped to the sideboard section, and the lines are treated just like the [deck] tag does.

The grouping parameter takes these values. For any value other than "custom", we treat every line as a card name, and lines without a numeric prefix are treated as a count of 1 for convenience.

• cost (the default) Groups cards by CMC, subgroups by creature/spell/planeswalker/land, sorts subgroups by name. I prefer to give lands a CMC of "Land" and spells with X in the cost a CMC of "X", rather than the official method of treating them as zero. I think that reflects the actual play curve better.
• type Group by creature/spell/planeswalker/land, subgroup by CMC, sort by name.
• custom Uses lines not prefixed by a number as group labels. Subgroup by CMC. Sort by name.
• none

The other parameters are all colors.

We can't use :nth-child selectors to do color banding because the group structure is not reflected in the HTML structure (you can't nest <tbody> tags). So the color banding relies on applied styles of "odd" and "even" to each subgroup tbody, and "header" on the tbody for the group header. When the subgroups are by type, we use the classes "Creature", "Spell", "Planeswalker", and "Land" to make the colors consistent across groups.

I guess that the deck title would not be part of the tag in this case. The user would just type a title before the fancydeck tag using normal formatting commands.

The tag is intercepted at post save and code as in option 1 is created. There would not be any d_data tag as in the example above since the round-trip information we need is in the fancydeck tag itself.

On edit, the generated tags are stripped, so that the user only ever sees the original fancydeck tag that they created.

Option 3a
Instead of a fancydeck tag, the user must use a pop-up list editor. The editor generates code as in option 1 above.

In this case the d_data tag is included to hold the source data. Also, the deck title is entered in the editor and included in the generated output.

Unfortunately, using this option means that the user sees a few dozen lines of junk in the post for every included table. The d_begin and d_end tags with their lines of **** help the user a tiny bit as they try to skip over the unreadable tag soup.

Hm, I suppose I should be a bit more professional about my feelings for php[bb]. I don't actually mind diving into the internals and making it do what we want — it's kind of fun, and that is basically my job here — but I do reserve the right to complain about the poor decisions and awful behavior I find.


This would be difficult given the simplicity of the phpbb post editor (a simple textarea).

Hmmmm. This is probably possible; I'm not certain on all of the details but given work could probably hash it out.

The editor stuff all looks reasonable to me.

I'm on board with option 1 over option 2 at this point as well.


Re: counting boxes: There are a bunch of ways of varying ugliness and difficulty to do this. A custom [box] bbcode that takes no parameters and produces &#x25A0; and a {CARD_COUNT} regex that accepts (&#x25A0|[0-9])+ are the first to come to mind.


Can you use CSS classes instead? A couple more lines in our theme's css seems cleaner, and 'class="foo"' is shorter than 'background-color: #f00f00;'.


Yeeeess? I think this should be possible by hooking the on-submit message parser to add an "id=" parameter to d_tables that don't have one already. Timestamps should provide sufficient uniqueness.


Not a problem. What I'm happiest doing should be the least of our concerns.

I agree that [fancydeck] might be possible.


I set up this regex and custom tag. When I tried to submit a post using it, the message parser crashed. Not kidding.

Looking at the code, this sort of thing isn't going to work. When you create a custom bbcode and replacement, it generates a regex to match that tag as well as the corresponding replacement. Part of this is escaping certain characters that are obnoxious in regexes, including $.

[edit] Oh wow more stuff to look at. Yeah, that option1 output looks pretty ugly, but it should be reasonably straightforward to set up a deck editor that consumes/produces that output. I would say "in the next two days" but my life is kind of crazy right now and setting time estimates is the last thing I want to do at the moment.

Also, massive thanks for all the work/thought you've put into this. I really appreciate the effort (though I feel like I am maybe not holding up my end of things as well... ).

Quick note: I'm still working on that last post with the example tags. I didn't mean to submit it yet--I must have clicked the wrong button by accident.

The size of the option 1 example is roughly what to expect, but I've been discovering little details and tweaks that are still needed, so don't take the tag code as a final suggestion yet.

I have completed my tag post above (but no option 2).


I agree, I was being a bit snarky. It's a major project that tons of people are using, which is awesome. It's pretty frustrating to keep getting bitten in so many edge cases, though.

Sorry if I wasn't clear. The basic defaults would definitely be given in a CSS file (see my previous post). But my deck planner uses different colors for every new deck that comes out, and users might want to use custom colors as well. Those were the situations I had in mind when I described our two options for applying color styles. It will be glorious to be able to use CSS for the export output instead of inline formatting on every tag like I had to do at wizards.com!

Ouch!


I don't think there's any rush at all. I've been doing a brain dump in my long posts because I already thought through a lot of these issues in designing the deck planner. Take your time. I expect the forums will be fairly dead over the next 6 weeks anyway.

It's great that you've been willing to invest work into this. If it succeeds, I hope many users will be happy.

Most of my contribution is happening now in the design phase. Once the time comes for development the work will be almost all yours. I remember that it was a bit of a pain to do all the card grouping and sorting in the planner. If you use JavaScript, I can send you my card grouping class and maybe that will save you some effort.

Once you've had time to digest what's been said so far, let me know if anything still looks fishy. At some point I can go back over all the posts and generate a list of the remaining decisions and maybe a work item list too. The thread has gotten long enough that it's a bit hard to keep track of everything that's been said.

Unrelated post that doesn't deserve a thread:

I suggest adding parameter info to the help text for the card, code, and hr tags. I didn't know about code=null or hr=3 until I saw you use them in this thread.

Yeah, better tip line text is a good idea. I've also been meaning to write up a post going over what bbcodes and options are available. Some day...

A quick post to make sure I understand where things are -- there's still no rush at all, I just want to make sure you're not waiting for anything from me.

As I see it, we've settled on either option 3 (fancydeck tag with behind the scenes option 1 tags), or option 3a (pop up editor that inserts/parses a blob of option 1 tags in the user's post). You're going to investigate whether option 3 is possible, or whether you want to settle for 3a.

Once you make that decision, I can help by writing a precise specification and a list of work items and open questions. Hopefully that will save you some time. Then I guess the remaining work will all be yours, unless some of my existing JS code can be of use to you.

Again, no hurry! Because I think there will still need to be some tweaks to the tag design I posted above, I didn't want you to implement it all without further discussion. So let me know when you decide between the two choices and I'll try to wrap up all the fine details.

Yeah, the ball's definitely in my court at this point. I'll try to make some time this weekend to look at the phpbb code and figure out what's feasible.

I have a vague hope of getting this done by the end of the month as a sort of New Years' present to the boards, but that's the only deadline-like thing at this point.

Thanks again for putting this much thought and effort into this. I really appreciate it.

I may be gone for a little while mid-month. Once you decide between options 3 and 3a, I'll try to get my writeup done as quickly as I can so you can power through the coding and remaining decisions.

Ugh ugh ugh, I am so bad at estimating when I'll have time for stuff. Sorry about all the delays.

I've started mapping out exactly what transformations are applied to post text on submission, editing/quoting, and display. It is a huge pain and is, naturally, documented nowhere I've been able to find. Should be able to finish tomorrow evening, at which point I will have enough information to make an informed decision on 3 vs. 3a.

After reviewing how phpbb posting works*, I'm confident that the ideal fancydeck format — Option 3 — is feasible.

There are functions to hook into:
- post submission, so we can modify what goes into the database
- post editing/quoting, so we can clear up the database content for display to the user
- post previewing/in-thread post display, so we can make it look awesome

Nearly all of the work will happen on post submission: it will pull out card data, group things, etc., and basically produce the horrible nastiness that option 3a would have thrown into the post editor.
Editing/quoting will just pull out the card names from the awful mess.
Preview/display will (obviously) produce the nice HTML.

... I guess most of that was obvious, it just wasn't clear that all the necessary hooks were present. But they are! Hurrah!

* looking at what I've written, it turns out a lot of my digging wasn't needed for this. But hey, I learned a ton that will no doubt be helpful later.

That's great news! I'll start working on a spec post to spell out exactly what needs to be done.

One question: will you be using JavaScript or PHP on the back end? If you use JS, I can include some code snippets and JSON examples from what I've done in the deck planner, and maybe that will be a helpful starting point.

[edit] Second question: are you familiar with Magic terminology like CMC and Supertype, or did you come to the site from a different game? If you're not a Magic person, I'll try to explain the Magic jargon in detail when necessary.

<<empty post for formatting experimentation>>











































xxxxxxxxxxxxxxxxxx

XXXXXXXXXXXXXXXXX

cost

(24) (24) (24)

(28) (28) (28)

(24) (24) (24)

and smilie

A card Unsummon.
A deck:
2 x Counterspell
3 x Grizzly Bears