BUGS! - Page 9

Spam has been a lot less of a problem since we dumped the VBulletin based system and moved to our own ground up application. Particularly in terms of spambot registrations and activity. So I think you'll find there were myriad reasons for changing from vBulletin, not just any one single issue. If it were to be rolled up into a one-word answer though my punt would be 'support' or rather lack of it.

Out of interest how many man hours have been spent by how many people rolling your own forum code?

Interesting. I run a phpBB3 board on which spamot reg became epidemic last year but managed to kill it stone dead with the right settings.

Out of interest how many man hours have been spent by how many people rolling your own forum code?

Dani and I had our first call to discuss design probably near the end of November 2011.

I run a phpBB3 board on which spamot reg became epidemic last year but managed to kill it stone dead with the right settings.

It's not just the settings, which I'm reasonably sure could have been tweaked in vBulletin to improve matters, it's that vBulletin simply was no longer a good fit for Daniweb's needs. Every new feature was either not possible, or a constant battle. Other BB systems would suffer similar problems due to generality, which is why we decided to go with a completely custom solution in the end. Given the amount of customization already in place under vBulletin, I'm also not convinced that switching to another BB product would have been any faster or less work than writing a new one (perfectly tailored to Daniweb) from scratch.

In the editor, if I select some text then hit the Italic button it puts a * before and after the text I selected. It also makes it Bold, even though I hit Italic.

It is correct in putting an asterisk before and after the text you selected, because that is how Markdown italicizes things. It makes it bold though? Are you sure? I just tested it and it didn't do that for me. One asterisk is italic. Two asterisks are bold.

Airshow, your Ctrl+B/Ctrl+I/etc key mappings are working now :)

It is correct in putting an asterisk before and after the text you selected, because that is how Markdown italicizes things. It makes it bold though? Are you sure? I just tested it and it didn't do that for me. One asterisk is italic. Two asterisks are bold.

It's ok then -- I was confused about the asterisks and didn't pay attention to the Preview window.

When I edit this post, why does the text appear in red color in the editor? The color is ok when saved, but red in the editor.

Because they posted code not within code tags. Brackets have a special meaning in Markdown, and they are opening up a Markdown tag and never closing it.

Is there a function to hightlight some particular word in our comment...as it was earlier green/red???

No, not currently. This is actually a limitaton of the Markdown syntax, which we currently use to markup posts.

Markdown's official stance is that color should be irrelevant to the content as is just for "decoration", and Markdown is all about preserving the integrity of what's being said both in raw form and parsed form. You can emphasize a part of a post by making it bold or italicize it, or divide a post into headings or sub-headings. Color is, essentially, just a styling issue.

Markdown's official stance is that color should be irrelevant to the content as is just for "decoration", and Markdown is all about preserving the integrity of what's being said both in raw form and parsed form. You can emphasize a part of a post by making it bold or italicize it, or divide a post into headings or sub-headings. Color is, essentially, just a styling issue.

That's an inconsistent argument. How are italics, for example, any less a styling issue than color? You can emphasize part of a post with color as well, when bold or italics wouldn't make sense. One example that I've used many times in the past is red for incorrect parts of code and green for correct(ed) parts. The color is more than decoration in that case, it's critical to the post's meaning.

Besides, we already use an extended version of Markdown, so I don't see any reason why their official stance should be relevant to us. ;)

A much better argument against color would be two reasons that apply directly to Daniweb:

1. Color wasn't used very much even when we supported it.
2. When it was used, it tended to be abused.

How are italics, for example, any less a styling issue than color?

Because the Markdown language emphasizes creating HTML 5 compliant markup, which essentially means that it is entirely style-free. HTML 5 is like MVC for the web ... entire separation of content from styling. An asterisk, for example, is meant to indicate emphasis, and therefore wraps content in the <em> tag. Double asterisks are meant to indicate strong emphasis on content, and therefore wraps content in the <strong> tag. It is your web browser (rather, convention of all web browsers) that has decided that emphasized text should be rendered in italics and that strongly emphasized text should be rendered in bold.

Color is entirely styling markup and can only be achived through something like <span style="color:red">. Once you start entering the world of CSS you're dealing with styling.

Besides, we already use an extended version of Markdown, so I don't see any reason why their official stance should be relevant to us. ;)

Even though we use a DaniWeb-flavored version of Markdown, the most important rule I'm holding onto is that we won't extend Markdown in any way that is unique to us. In other words, any non-standard Markdown feature we use is also heavily used by at least a couple of other really huge Markdown-oriented sites around, such as Github. I'm really trying to go for as much standardization as possible, for the most consistent experience when posting on DaniWeb and other sites that use Markdown. It's important to me that DaniWeb posters already familiar with Markdown won't have to feel like they have to learn yet another syntax language.

But yes, your bullet points 1 and 2 also hold true, and they were my original rationale to agree to go with Markdown in the first place even though I knew color would be a limitation going in.

<addition>

For example, you'll notice that all of our custom Markdown features are exactly the same as Github's, with the exception that we currently don't support fenced code blocks because they proved to be just way too buggy for right now. (http://github.github.com/github-flavored-markdown/)

The other big site that currently uses Markdown is Stack Overflow. Jeff Atwood from SO wrote an article back in '09 that illustrates how they use Markdown, with a point-by-point of explanation of what changes they share with Github and what they don't. (http://blog.stackoverflow.com/2009/10/markdown-one-year-later/)

Essentially, here are the differences from standard Markdown:
Github, SO, and DaniWeb all have the same modification to the way emphasis works
Github, SO, and DaniWeb all auto-link URLs in the same way, unlike standard Markdown
Github and DaniWeb are altered to treat hard line breaks as <br />, while SO functions like standard Markdown
Github supports the non-standard fenced code blocks, which SO doesn't, and DaniWeb tried to do (unsuccessfully)

A ridiculous amount of thought was put into each non-standard feature we implement.

Not the fault of anybody here but ....

Because of the arbitrary decision in HTML.dot to provide <bold></bold> and <italic></italic> (later <strong></strong> and <em></em>), the folks at Markdown thought it OK to provide for bold and italic styling. Maybe because we never had <red></red> and <green></green> tags, Markdown denies us red and green styling, despite the fact that it may be useful.

More doctrine than logic methinks.

Airshow ... <b> and <i> are NOT the same thing as <strong> and <em>.

<b> and <i> are font-style tags defined in the first versions of HTML (HTML 2.0 I believe, but I could be wrong.). They were created to be used for styling.

The <em> and <strong> elements were introduced in HTML 4.01 as a means of denoting emphasis and strong emphasis within content, and NOT just for styling purposes.

When XHTML 1.0 came around in 2000, it marked the beginning of using CSS and beginning to separate content from styling. However, the <b> and <strong> tags, and their italicized counterparts, coexisted. The <b> tag was meant to be used when the sole purpose was to embolden a word or phrase for stylistic purposes. The <strong> tag was meant to be used when you wanted to use markup to denote a particular word or phrase as being important and needing emphasis, and this was factored into the page's SEO (as Google used the tags as a directive of what the content author considers important, similar to how they do with the <h1> tags).

The latest incarnation, HTML 5, takes this a step further to actually deprecate the <b> and <i> tags since they were created just for styling purposes, and styling should no longer be mingled with content. The <em> and <strong> tags should be used because they are used specifically to denote important text and therefore don't exist for styling reasons.

Ok, I assume this is the right place to put this...

bizzarly, I can't seem to access my post due to a 404 error. I got the email saying some activity on the post, clicked the link and got the error. Also get it when trying to view from the topic listing. Other posts in that and other topics seem fine. Not sure if its something about that post in particular or if its some client/proxy/caching issue (will update if I manage to get in).

post in question is http://www.daniweb.com/web-development/javascript-dhtml-ajax/threads/420946/readonly-checkbox

update: actually now I get the 404 when going to the javascript/dhtml topic forum

Wow, that was a major screw-up on my part! Fixed!!!

Looks like automagic Code block does not now anymore understand Python. It does not handle triple single quote multiline strings. http://www.daniweb.com/software-development/python/threads/421219/py2exepy2app-and-docx-dont-work-together#post1797192

I'm confused. I'm not sure what you mean. Do you mean something changed recently?

I am still working on getting the language-specific tags to work, like with the VB comment issue.

I do not know if ''' worked before as I mostly have used """" for multiline strings, I wanted to test specific Python syntax but that is not possible without fenced blocks, which we do not use anymore.

Here with those fenced syntax blocks and it does not work if there is apostroph in doc string.

''' This is 
docstring 
of
many lines!
'''
# Here OK as 6 quotes -> pairs

''' doc string which isn't
without apostroph
'''
# this is thought to be  inside string?

Yes, I will get python-specific syntax working soon. Sorry!

Airshow, your Ctrl+B/Ctrl+I/etc key mappings are working now :)

Supercool beyond belief Dani.

Airshow ... <b> and <i> are NOT the same thing as <strong> and <em>. ...

It's OK, I know all that stuff like the back of my hand. I was paraphrasing.