Michael A Nachbaur wrote:
fantasai wrote:
Agreed. Is there a requirement to have the styles between
developer.mozilla.org and mozilla.org 100% identical, or can there be
some maneuvering room to accomodate the kind of content that the
developer site will contain?
There's some maneuvering room, but not enough to make major changes.
We can, however, *add* to the style sheets on www.mozilla.org.
Well, there was a long thread in the past as to what form
developer.mozilla.org should take, though, to be honest, I can't
remember all of what was discussed (or rather, so much was discussed,
that it seemed to form into a sort of white noise).
Are there any requirements, or even somewhat-hard ideas about what shape
that site will be?
The site will have XML-based references, but also many HTML-only docs.
Content will include introductory material, manuals, API references, FAQs,
etc. It will be organized primarily by topic, not by format. All docs on
XPCOM string functions, for example, should be accessible from one place
so one doesn't have to dig around in different areas for it.
Well, what I mainly meant about this was, if you have an XSL
rendering pipeline, you can choose one style or another, e.g. text-only,
full-blown graphics, printable styles, etc.
Well-coded HTML should be able to handle that without needing to alter
output formats.
And with i18n, you can translate the XSL stylesheet content and website
> content separately, so there is less work involved (theoretically).
Ok, I see what you mean.
Okay. If I can get access to those stylesheets, then that could save
me some effort.
Easily done, but what exactly are you planning to do with them?
Well, since my site's content is rendered using XSL, if I can use the
same stylesheets that render the mozilla.org website, it would simplify
the process of bringing the XML content in-sync. Potentially...I'd have
to see.
It would also ensure that the HTML I produce is as close as possible to
what is rendered on mozilla.org (instead of reverse-engineering from the
generated HTML).
The format that's being generated from the XPCOM docs isn't fixed in stone;
we can tweak it as necessary to handle additional content. The requirement
is that the output be in line with the requirements of the Style Guide, that
it be well-organized and usable, and that it pass code review by me.
I think we'll probably want to stay static, but having the XML storage
format and the XSLT match seems like a good idea.
Is there any particular reason why you'd like to have the site remain
static? Is it for performance reasons?
I believe so. We'll have to check with Myk.
One advantage of the current system is that one can easily build the
whole site at home, without running a server. How would you handle that
>> with AxKit?
Usually just a recursive "wget", or render the site through a separate
stylesheet that produces either one large document, a PDF, or something
along those lines.
That's not explaining much.
If I want to write a small reference and I wanted to see the output before
checking it in, how would I do that on my own computer without connecting
to the internet?
~fantasai
--
http://fantasai.inkedblade.net/contact
_______________________________________________
mozilla-documentation mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-documentation
