This comment has been bothering me for a couple of days.
First of all, inline styles are no more inappropriate in HTML than
"goto" statements are in C. There are clear and unambiguously correct
usages for both, even though they may not fit your particular project,
problem set, or coding style. Your statement is true for a limited set
of circumstances, but when you're writing a tool for public use, you
can't assume that everyone else's problem set is the same as yours.
Second, and more importantly, this associated flaw in the Spark markup
language represents a deviation from the way Spark is supposed to
work. In other words, it's a bug. "Spark loves your HTML like a
kitten" as Lou put it. You're supposed to be able to drop in normal,
valid HTML and expect it to almost always render correctly. However,
Spark fails spectacularly at this in a significant percentage of
cases. If the code uses inline styles and starts a line with an ID
selector (which, for all the banter about coding style, is still very
common), then your page will blow up with an extremely unhelpful error
message. That's not the way Spark was intended to work. And it's
clearly happening quite frequently to new users.
The proposed solution--modifying your HTML to avoid the bug--isn't a
solution. It's a workaround. And it's crappy.
As an analogy, imagine Spark is instead a C# compiler, but for some
reason it left out the implementation of the bit-shift ("<<" and ">>")
operators. Now when someone points this out, you could chide them and
say that bit manipulation has no place in managed code, or you could
argue that a user could just rewrite his code to use division and
multiplication instead. But that doesn't change the fact that your
compiler is, from the user's perspective, broken. It doesn't perform
as a reasonable user would expect, and instead chokes on what the user
expects is perfectly valid code.
This problem has been brought up several times. It's been solved
several times. And the solution has been mentioned here several times.
And what's more frustrating is that the solution is so stupidly
simple, but each new user has to re-discover and re-implement it on
his own. Spark has a coding land-mine. And it's so easy to fix.
The simple solution is to set the default StatementMarker to "#
" (with a trailing space). This fixes CSS issue because putting a
space between the # and the identifier is not valid CSS, and won't
occur "in the wild". Furthermore, users already commonly put a space
between the # and their C# code, because it makes the code easier to
read. A line like "#if (x==1)" apparently looks wrong, like it's a
preprocessor command; while "# if (x==1)" is apparently a bit easier
on the eyes because that "#" isn't crowding the code. And the
Intellisense still works. All win, no lose.
So why not make that the default? It's easier on the newcomers because
their HTML will work, and people who are used to the old way can
always set the StatementMarker back if they want to.
-Tyler
On May 14, 7:25 am, Rob G <
robertgreyl...@gmail.com> wrote:
> If you did this, then you would lose the semantic meaning that the "#"
> symbol gives to CSS anyway. You may as well just put "html #breadCrumb"
> instead and Spark will ignore is anyway, but the bigger issue here is that
> it's bad ju-ju to put your styles in-line regardless, and even if you have
> to, you can get around it as pointed out by James.
>