more thoughts on Dan's idea

CSL Development
1

So thinking more about this more, I could imagine a user experience
something like:

User adds some basic information about the style (field, type, etc.)

Wizard uses that information to present user with a handful of
previewed choices; user chooses closest match.

The “closest match” view allows users to choose among a few more
specific options.

Upon choosing that match, user can either keep things as is and
proceed to saving the style (in which case the style is likely to be a
dependent style), or choose to “edit” it, which would present the UI
Dan is talking about. That way, the hairy stuff like names and dates
and macro order are likely to be correctly configured, so that the
user is only tweaking things like punctuation.

In any case, a lot of options here. The key decision is whether we
start with the macro-based approach.

Bruce

2

That seems like a possibility. If we were going with my approach, those
"choices" could just be hard-coded HTML strings, since that would be the
actual input to the tool.

(This is where I should probably add the caveat that I’m not sure if the
process I describe would actual work�it just seems like an interesting
idea. One of the main questions is how much HTML markup you would need
to represent all the concepts implied by CSL’s formatting options. But
even a limited amount of markup could probably get you close, even if a
few subtler things had to be tweaked by hand in the resulting XML�and a
csledit.xul-style live preview, with more reference data than you would
use initially, could even be an optional, advanced final step.)