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
