I don't know how I can do this without sounding like self-advertisement,
but the things I have been doing lately have been towards an end that 
might be useful to y'all here.

I have been trying to research just what Mozilla DOES and DOES NOT support
WRT CSS and HTML. Since the mozilla documents seem to be rather..."lean",
or very inaccessible I have had to resort to digging through the source 
code (for better or for worse.) My data mining is not yet complete, but 
I am getting there. A lot of my data comes from just trying interesting
test cases in the browser itself.

I have yet to see anywhere, either on mozilla or elsewhere, any sort 
of documentation aimed at the web author that says exactly "we 
support (well, TRY to at least...) X and Y, but not Z...we also support 
A, but there are these holes:..." for Mozilla/Netscape 6. I have seen 
SOME efforts at capturing this, but nothing definitive for the 
web author that needs to know this stuff. 

>From the viewpoint of the web author, a web browser is a content delivery
platform for THEIR content, and all they care about is if the code they 
used works the way they intended on a given platform. 

By simply saying "we support HTML 4.01 and XHTML, go look at the specs 
for details", you ignore the legacy question (do you still support 
MULTICOL?(no) SPACER?(yes) and pointed discussions on the politics that
page authors should be concerned about (eg: the "quirks" mode and the ins
and outs of its use and why it exists) should be so prominent for the 
questing author to find that it is one of the first things they are 
ever presented with when investigating Mozilla's authoring capabilities.
Simple referral to the specs also ignores behavioral holes in 
comparison to those same specs. Authors need to know these things if 
they are ever going to embrace Mozilla fully as an authoring platform.

I have a site that tries to capture current and historical practice in
the popular browsers (both the good, and the bad.) I usually have a 
tough time of this, because the existing documentation is often of 
poor quality, or non-existent, or doesn't go deep enough.

I subbed to this list a while back to see what direction(s) the 
Mozilla documentation efforts take, and I am still not clear on that 
point...will there be an effort made to have a "sit-down" with web 
authors? ...To let them know just what they can do, what they 
SHOULD do, and what they should avoid?

I have tried to keep the focus of my site as a "this is what is known
to happen and not happen with browser behavior", but that is not enough,
certainly, for the (hopefully) ever-growing authoring community that 
will be well-versed in the power of authoring for Mozilla as a 
potential target.

So...since it doesn't look like this is really a focus, I bring up 
the content of my site as a possible "first volley" in 
beginning/adding to that knowledge base. If I am mistaken (which is, 
as always, VERY possible 8-}) then I guess this is just a long-winded 
way of saying "someone please point me in the right direction." 

Thanks for reading this far,
-Brian

-- 
Brian Wilson -----------------------"Those aren't Sex muffins!   -Coach
[EMAIL PROTECTED] ------------------Those aren't Love muffins! 
http://www.blooberry.com/ -----------Those are just BLOOberry muffins!"
Creator of Index DOT Html/Css: http://www.blooberry.com/indexdot/

Reply via email to