4 Answers
4

There are several advantages to writing proper HTML and using semantic tags. Instead of asking yourself "How should this look?" Ask yourself "What does this mean?".

What does it mean for a text to be red? Does it mean <em>phasized text? Maybe <strong> text? You can always apply the style="color: red;" on top of that (or even better, with a classname).

What are the advantages?

<font> is deprecated. Today it's still supported, mainly due to idiots who want their sites to run with IE5.5, but that may not be the case in the future. One day, <font> might just stop working altogether. Its behavior is currently undefined in latest versions of HTML, and will lead to unpredictable variations between browser implementations, and between browser versions.

Using proper elements (<em>, <strong> as opposed to <span> or <font>) makes machines understand your text better. That's good for accessibility, SEO, and a bunch of other things that entities which are not actual human readers do.

Using proper elements makes your site look better by default. Say a client does not use CSS, he's on a very old phone, or just uses some obscure browser. <em> shows up as italicized, <strong> shows up as bold. <span> shows up completely normally.

Other than that, if you're already defining all of the CSS rules in your template engine, why not use HTML to begin with? There's no point in complicating things with yet another syntax. Write valid, proper HTML from start to end, and be done with it.

I wouldn't want to complicate code needlessly, but I suspect that if the project grows bigger in future I will eventually end up building mobile apps, and there will be literally thousands of texts that will need coloring and stuff. If I put them as HTML then I would need to parse html into other languages which I suspect would be a bit harder than that simple little syntax. Other than that thank you for this little reminder, I seem to have forgotten about html tags other than span and div.
–
php_nub_qqJun 7 '14 at 15:28

5

@php_nub_qq: Actually, parsing HTML is a thoroughly solved problem. Lookup DOM (it's language agnostic, it doesn't apply just for JavaScript or PHP or whatever). Parsing your custom syntax would prove harder. Especially if you want to add functionality to it, which would result in monster regex. Don't do it to yourself, HTML scales better.
–
Madara UchihaJun 7 '14 at 15:55

1

@php_nub_qq And if your custom syntax has any nesting like HTML does, you're going to run into the same problems trying to parse it with regex as there are with HTML.
–
IzkataJun 8 '14 at 21:02

In this case, neither system you have is best. The best thing is to remove the styling from the local element, and apply it using CSS classes, in which case, span would be fine, but not with a style attribute, but with a class attribute.

Also, your solution is very, very limited. You have already identified the problem with your regex where it does not accomodate [ and ] in the 'value' content, but what about the opposite problem, spaces in the first part of the style? For example, how do you set a span with the font style: font-family: Gill Sans Extrabold, sans-serif;?

In practice, there is normally no difference between span and font if you do not use any of the specific attributes of font but only a style attribute. In principle, the difference is that span has no meaning whatsoever beyond turning a piece of text to an inline element, whereas font additionally means that some font styling is applied to the text. However, when none of the attributes size, face, and color is used, font does not say anything about font styling.

There is nothing you can win by using font in the case described. There is hardly anything to lose either, though various theoretical possibilities can be presented.

It would be a different matter if you used the attributes of font in addition to or instead of CSS styling and/or other presentational markup. If you generated <font color=red><b>...</b></font>, then the text would be in bold and in red even when CSS has been disabled. This is relatively theoretical, though, and the downside is that many people would blame you for not using “proper markup” by their standards.