Well, what's the goal? Support production of non-HTML at the engine level or
at the web app level? Nothing about my proposal adds non-HTMLness to the
engine, and the web app is already pretty locked into HTML.and in desperate
need of massive cleanup anyway. Just the way that Formatter and the WikiTalk
stuff is written makes changing to XHTML hard enough, let alone something
with a different content model entirely. Adding support for CSS to the web
app would - in my opinion - add a whole lot of functionality in the very
near term (assuming someone finds the time to implement it).
Another problem with not doing it is that if you want to give users styling
options in a presentation-free environment, you have to invent an abstract
syntax for it. The FlexWiki is already pretty big for nontrivial edits
without adding more to it. Not to mention the usual problems of having to
stick to the lowest common denominator of all the presentation formats one
has to support.
In any event, I've expressed here before my opinion that supporting non-HTML
formats is probably a bad idea. I used to think it was a good idea - I
remember the discussions we had around URL design (another place where we
screwed up) - but since then I've become increasing convinced that it is
not.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Ornstein
Sent: Tuesday, September 18, 2007 12:33 AM
To: FlexWiki Users Mailing List
Subject: Re: [Flexwiki-users] CSS Feature Request
Would be the nail in the coffin of ever supposed anything as an output
format other than HTML? Seems like it.
I know it hasn't happened yet, but being able to produce output (e.g., to
WPF or a pure GUI or any of another output forms) seems like a valuable
capability. It just kills me to basically build in features that will cause
people to produce wiki content that couldn't be made to work (at least
without extreme effort) in these non-HTML (actually, non-CSS) forms.
I haven't been able to think this through but I wonder if there's at least
some kind of segregation model that says that you have to explicitly enable
HTML support in a namespace (or federation). Then if that's turned on,
these kinds of capabilities work (including the recently added ability to
generate DIVs). But if you don't turn it on explicitly then these things
throw errors (or are at least ignored). Then if we added other output forms
it would be possible to have them declare they couldn't handle such
"output-format-specific" namespaces.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Craig
Andera
Sent: Monday, September 17, 2007 1:04 PM
To: 'FlexWiki Users Mailing List'
Subject: [Flexwiki-users] CSS Feature Request
I have a feature request. I'd implement this myself, but I'm really trying
to resist the temptation to hare off and add features when I ought to be
spending time working on performance.
I think the recent comment that CSS control could be better is correct. The
work that Derek has done recently is an improvement, but having implemented
one or two customized wikis, I think it's still a pain. Here's what I'd like
to see:
Every page that renders should have (at least) the following <link> tags
referencing stylesheets:
1) The wiki default
2) The wiki override
3) The static namespace override
4) The dynamic namespace override
5) The static topic override
6) The dynamic topic override
By static, I mean "in a file on the filesystem". Having two lets me put in
my overrides in the second one, which makes it easier for me to upgrade (the
default overrides file is empty or doesn't exist). The namespace and topic
static overrides would just be a URL , probably in a property. I think we
have this now, right?
The dynamic ones are where the power comes in. I picture an aspx page like
Css.aspx that dynamically produces CSS based on the contents of either
_ContentBaseDefinition (the dynamic namespace override) or the topic itself
(the dynamic topic override). We could introduce a special syntax for
producing CSS, but I think it might be better just to use CSS itself.
For example, in your _ContentBaseDefinition, you'd do something like this:
AdditionalStyles: [
.some-class { color: Navy; font-weight: bold }
.something-else { background: grey }
]
Etc.
Am I insane? This seems like it would be really easy to do, and it would
move yet another piece of configuration *into the wiki* where it belongs. (I
think all configuration should be in the wiki, including the contents of
flexwiki.config.)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flexwiki-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flexwiki-users
