Re: New draft of manual style
Joshua Slive [EMAIL PROTECTED] writes: 1. There was one main reason I stopped developing the wacky style: complexity. If felt it was over-complex both visually and particularly the css and html code. The css code had the advantage that it was externally developed and maintained at style.tigris.org, but I still didn't like using something that seemed difficult to maintain. Oh, I didn't know that. My comment was solely on look and feel, so I completely agree with your suggestion #2 below. 2. Let's try to determine exactly what about the original style people like better. Perhaps we can combine the two in a way that will work. Some suggestions: b) Side-menu listing important stuff seperate from text rather than having the menu integrated from the text. I like this, but I'm not sure how much it is about the cool factor. It also leads to the obvious disadvantage of having to put the whole darn page in a table, which is annoying but very common for modern sites. As Michael pointed out, it can be done with only css. If implementing it doesn't end up in complex html and css, I'd like to see it done. Module docs looks much better if directives is listed on side-menu. c) Smaller font. As I mentioned in the original discussion, smaller fonts tend to look more modern and professional, since almost all major websites now use a less-than-default font size. Of course, it is silly to contradict what the user set as their default font, but since almost all sites do it, small can almost be considered the default. I don't have strong opinion about this. Either one is fine with me. -- Yoshiki Hayashi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STATUS] (httpd-docs-1.3) Wed Aug 28 23:45:32 EDT 2002
Apache HTTP Server 1.3 Documentation Status File. Last modified: $Date: 2002/07/05 03:23:41 $ If you are interested in helping accomplish some of the tasks on this list or otherwise improving the documentation, please join the apache-docs mailing list by sending an empty message to [EMAIL PROTECTED] For more information on how to contribute to the Apache Documentation Project, please see http://httpd.apache.org/docs-project/, and http://apache-server.com/tutorials/ATdocs-project.html for an excellent tutorial on how to get started with making your contribution. -- Translations * We appear to have people working on translation into the following languages. These may just be the 'it worked' page, but if so the authors of those should perhaps be contacted to help do the rest.. :-) Note that this list is NOT identical to that for the 2.0 documentation project! [Should we attempt to get a known-current authorlist together? --jsl] - Catalan (.ca) - Czech Republic (.cz) - German (.de) - Danish (.dk) - Estonia (.ee) - Greek (.el) - Spanish (.es) - French (.fr) - Hebrew (.he.iso8859-8) - Italian (.it) - Japanese (.ja.jis) - Korean (.kt.iso-kr) - Luxembourgish (.lb) - Dutch (.nl) - Norwegian (.no) - Polish (.po.iso-pl) - Portuguese (.pt) - Portuguese [Brasilian] (.pt-br) - Russian (.ru.cp-1251, .ru.cp866, .ru.iso-ru, .ru.koi8-r, .ru.ucs[248]) - Swedish (.se) - Chinese (.zh) New User documentation == * Adding more documentation for new users - I believe that we'll need to get more info on what is missing, ie. user feedback and whatnot. --jsl Documentation improvements == * Improving the security docs - More content and better organisation. * General cleaning and improving of module docs * Making the directive definitions less terse (i.e., adding more examples and details to the definitions of the directives) - We'll need to audit these and find out which ones need munging, as some of it looks ok. --jsl * Making site-specific enhancements easier, including a documented and robust way for 3P module docco to be added -- and have it survive a server docco upgrade - This could be something a simple and hackish as a manual/extra/ directory (a la the 1.3 src/modules/extra/ directory) and a script in the support directory that scans the files there and updates the manual indices. (We do something like that now for httpd.conf file with apxs [LoadModule, etc.].) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STATUS] (httpd-docs-2.0) Wed Aug 28 23:45:38 EDT 2002
Apache HTTP Server 2.0 Documentation Status File. Last modified: $Date: 2002/07/27 15:45:43 $ If you are interested in helping accomplish some of the tasks on this list or otherwise improving the documentation, please join the apache-docs mailing list by mailing to [EMAIL PROTECTED] For more information on how to contribute to the Apache Documentation Project, please see http://httpd.apache.org/docs-project/, and http://apache-server.com/tutorials/ATdocs-project.html for an excellent tutorial on how to get started with making your contribution. -- - doc-project webpage should be updated to recommend subscription to the CVS mailing list. - XML - The xsl transformations could be greatly improved to a) look better and b) use proper CSS+html rather than the horrible hack that Joshua did. - Is there a way to get Ant+Xalan to validate the documents when transforming? - Rewriting of the remainder of the manual into xml is in progress. - modules docs - mod_suexec: very little documentation - mod_proxy: updates for 2.0 - mod_status: updates for 2.0 - mod_example: updates for 2.0 - man pages - Some of the man pages need to be updated for 2.0. At least the httpd man page appears to be outdated, and perhaps other. After this is done, the manual/programs/ versions can be regenerated using the program in the site-tools repository. - MPM documentation - Each MPM needs to have a documentation file in manual/mod/ which lists the directives it provides, and some details about its operation. Status: Initial outlines done. Much more details need to be filled in. - Non unix/windows MPMs still need to be completed. - the perchild directives in threaded/worker need docs - Individual docs will need some cleanup. Status: What docs still need to be touched here? - misc/custom_errordocs.html needs to be updated to essentially describe how the international error docs included in 2.0 work - misc/perf-tuning.html - needs major rewrite for 2.0 - misc/tutorials.html - mostly not relevant to 2.0 - misc/stopping.html - misc/rewriteguide.html - needs cleaning in 1.3 and 2.0 - misc/known_client_problems.html - mostly ancient - New build process. - install.html has had a first-pass rewrite, but many things have changed in the build system since it was written. - Documentation of new features. - This will probably require more input from new-httpd, since not many people here follow the development process close enough to know what is going on. - API documentation Status: Ben Laurie has written some hooks documentation - Translations - We need a webpage describing the basics of how to go about translating the apache docs. Things like naming conventions, reviewing standards, and perhaps some standard comments to put at the top of each doc (english version, auther, reviewer). We appear to have people working on translation into the following languages. These may just be the 'it worked' page, but if so the authors of those should perhaps be contacted to help do the rest.. :-) Note that this list is NOT identical to that for the 1.3 documentation project..! [Should we attempt to get a known-current authorlist together? --jsl] - Catalan (.ca) - Czech Republic (.cz) - German (.de) - Danish (.dk) - Estonia (.ee) - Greek (.el) - Spanish (.es) - Estonian (.et) - French (.fr) - Hebrew (.he.iso8859-8) - Italian (.it) - Japanese (.ja.iso2022-jp, .ja.jis) - Korean (.ko.euc-kr) - Luxembourgish (.lb) - Dutch (.nl) - Norwegian (.no) - Polish (.po.iso-pl) - Portuguese (.pt) - Portuguese [Brasilian] (.pt-br) - Russian (.ru.cp-1251, .ru.cp866, .ru.iso-ru, .ru.koi8-r, .ru.ucs[248]) - Swedish (.se) - Chinese (.zh) [Need this clarified --jsl] New User documentation == * Directory Handling (mod_dir/mod_autoindex/etc) * Sections (Directory/Files/Location) - I think this should be a priority. A rewrite of /sections.html would be a good place to start. That document is too technical and insufficiently verbose for the average user. * public_html - tutorial covering what is involved in helping users set up web serving out of their home directory. Documentation improvements == * Improving the security docs - More content and better organisation. * General cleaning and improving of module docs * Making the directive definitions less terse (i.e., adding more examples and details to the definitions of the directives) - We'll need to audit these and find out which ones need munging, as some of
Re: cp-1251 output encoding ([TRANSLATION] new_features.xml - translated into Russian)
Yes, koi8-r is widely spreaded and it would be even better for me to use this encoding scheme. But I didn't understand if I should do it again, so I send the translated file in koi8-r. Any suggestions or guidelines are desired:) Translator: Ilia Soldis [EMAIL PROTECTED] Reviewer: Ivan Shvedov [EMAIL PROTECTED] ?xml version='1.0' encoding='KOI8-R' ? !DOCTYPE manualpage SYSTEM ./style/manualpage.dtd ?xml-stylesheet type=text/xsl href=./style/manual.en.xsl? manualpage relativepath href=./ titleïÂÚÏÒ ÎÏ×ÙÈ ×ÏÚÍÏÖÎÏÓÔÅÊ × Apache 2.0/title summary põÌÕÞÛÅÎÉÑ:/p /summary section id=core titleõÌÕÞÛÅÎÉÑ × ÑÄÒÅ ÓÅÒ×ÅÒÁ/title dl dtstrongíÎÏÇÏÐÏÔÏÞÎÏÓÔØ × UNIX/strong/dt ddîÁ UNIX ÓÉÓÔÅÍÁÈ, ËÏÔÏÒÙÅ ÐÏÄÄÅÒÖÉ×ÁÀÔ ÐÏÔÏËÉ (ÎÉÔÉ) ÓÔÁÎÄÁÒÔÁ POSIX, Apache ÔÅÐÅÒØ ÍÏÖÅÔ ×ÙÐÏÌÎÑÔØÓÑ × ÇÉÂÒÉÄÎÏÍ ÍÎÏÇÏÐÒÏÃÅÓÓÏ×Ï - ÍÎÏÇÏÐÏÔÏÞÎÏÍ ÒÅÖÉÍÅ. üÔÏ ÓÐÏÓÏÂÓÔ×ÕÅÔ ÕÌÕÞÛÅÎÉÀ ÒÁÓÛÉÒÑÅÍÏÓÔÉ ÓÉÓÔÅÍÙ ÄÌÑ ÍÎÏÇÉÈ, ÎÏ ÎÅ ×ÓÅÈ ÓÐÏÓÏÂÏ× ËÏÎÆÉÇÕÒÁÃÉÉ./dd dtstrongîÏ×ÁÑ ÓÉÓÔÅÍÁ ÓÂÏÒËÉ/strong/dt ddóÉÓÔÅÍÁ ÓÂÏÒËÉ ÂÙÌÁ ÐÏÌÎÏÓÔØÀ ÐÅÒÅÐÉÓÁÎÁ É ÔÅÐÅÒØ ÏÓÎÏ×Ù×ÁÅÔÓÑ ÎÁ autoconf É libtool. üÔÏ ÄÅÌÁÅÔ ÓÉÓÔÅÍÕ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ Apache ÂÏÌÅÅ ÐÏÈÏÖÅÊ ÎÁ ÐÏÄÏÂÎÙÅ ÓÉÓÔÅÍÙ ÄÒÕÇÉÈ ÐÒÏÇÒÁÍÍÎÙÈ ÐÒÏÄÕËÔÏ×./dd dtstrongíÎÏÇÏÐÒÏÔÏËÏÌØÎÁÑ ÐÏÄÄÅÒÖËÁ/strong/dt ddApache ÔÅÐÅÒØ ÉÍÅÅÔ ÓÐÅÃÉÁÌØÎÕÀ ÉÎÆÒÁÓÔÒÕËÔÕÒÕ, ÓÐÏÓÏÂÎÕÀ ÏÂÓÌÕÖÉ×ÁÔØ ÒÁÚÌÉÞÎÙÅ ÐÒÏÔÏËÏÌÙ. íÏÄÕÌØ mod_echo ÂÙÌ ÎÁÐÉÓÁÎ × ËÁÞÅÓÔ×Å ÐÒÉÍÅÒÁ ÜÔÏÍÕ./dd dtstrongìÕÞÛÁÑ ÐÏÄÄÅÒÖËÁ ÏÔÌÉÞÎÙÈ ÏÔ UNIX ÐÌÁÔÆÏÒÍ/strong/dt ddApache 2.0 ÔÅÐÅÒØ ÒÁÂÏÔÁÅÔ ÂÙÓÔÒÅÅ É ÎÁÄÅÖÎÅÅ ÎÁ ÏÔÌÉÞÎÙÈ ÏÔ UNIX ÐÌÁÔÆÏÒÍÁÈ, ÔÁËÉÈ ËÁË: BeOS, OS/2 É Windows. ó ××ÅÄÅÎÉÅÍ ÎÏ×ÙÈ ÓÐÅÃÉÆÉÞÎÙÈ ÄÌÑ ËÁÖÄÏÊ ÐÌÁÔÆÏÒÍÙa href=mpm.html ÍÕÌØÔÉ-ÐÒÏÃÅÓÓÎÙÈ ÍÏÄÕÌÅÊ/a (MPMs) É ÂÉÂÌÉÏÔÅËÉ Apache Portable Runtime (APR), ÜÔÉ ÐÌÁÔÆÏÒÍÙ ÔÅÐÅÒØ ÐÏÄÄÅÒÖÉ×ÁÀÔÓÑ Ó ÐÏÍÏÝØÀ ÉÈ ÓÏÂÓÔ×ÅÎÎÙÈ API, ÞÔÏ ÐÏÚ×ÏÌÑÅÔÓÑ ÉÚÂÅÖÁÔØ ××ÅÄÅÎÉÑ ÚÁÞÁÓÔÕÀ ÐÏÌÎÙÈ ÏÛÉÂÏË É ÐÌÏÈÏ ÒÁÂÏÔÁÀÝÉÈ POSIX - ÜÍÕÌÉÒÕÀÝÉÈ ÓÌÏÅ×./dd dtstrongîÏ×ÙÊ API ÄÌÑ Apache/strong/dt ddAPI ÄÌÑ ÎÁÐÉÓÁÎÉÑ ÍÏÄÕÌÅÊ ÚÎÁÞÉÔÅÌØÎÏ ÉÚÍÅÎÉÌÓÑ × ×ÅÒÓÉÉ 2.0 íÎÏÇÉÅ ÉÚ ÐÒÏÂÌÅÍ ×ÅÒÓÉÉ 1.3, Ó×ÑÚÁÎÎÙÅ Ó ÐÏÒÑÄËÏÍ ÓÌÅÄÏ×ÁÎÉÑ ÍÏÄÕÌÅÊ É ÉÈ ÐÒÉÏÒÉÔÅÔÁÍÉ, ÄÏÌÖÎÙ ÉÓÞÅÚÎÕÔØ. ÷ ×ÅÒÓÉÉ 2.0 ÍÎÏÇÏÅ ÉÚ ÐÏÄÏÂÎÙÈ ×ÅÝÅÊ ÄÅÌÁÅÔÓÑ Á×ÔÏÍÁÔÉÞÅÓËÉ, É ÔÅÐÅÒØ ÐÏÒÑÄÏË ÓÌÅÄÏ×ÁÎÉÑ ÍÏÄÕÌÅÊ ÏÐÒÅÄÅÌÑÅÔÓÑ ÐÏÓÒÅÄÓÔ×ÏÍ ÓÐÅÃÉÁÌØÎÙÈ ÐÒÏÇÒÁÍÍÎÙÈ ËÒÀÞËÏ× (hook), ÏÔÞÅÇÏ ÎÁÓÔÒÏÊËÁ ÓÅÒ×ÅÒÁ ÓÔÁÎÏ×ÉÔÓÑ ÂÏÌÅÅ ÇÉÂËÏÊ. ôÁËÖÅ ÂÙÌÉ ÄÏÂÁ×ÌÅÎÙ ÎÏ×ÙÅ ×ÙÚÏ×Ù ÆÕÎËÃÉÊ, ËÏÔÏÒÙÅ ÐÒÅÄÏÓÔÁ×ÌÑÀÔ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ×ÏÚÍÏÖÎÏÓÔÉ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÍÏÄÕÌÅÊ, ÉÚÂÁ×ÌÑÑ ÏÔ ÎÅÏÂÈÏÄÉÍÏÓÔÉ ×ÎÅÓÅÎÉÑ ËÁËÉÈ - ÌÉÂÏ ÉÚÍÅÎÅÎÉÊ × ÑÄÒÏ ÓÅÒ×ÅÒÁ./dd dtstrongðÏÄÄÅÒÖËÁ ÐÒÏÔÏËÏÌÁ IPv6/strong/dt ddîÁ ÓÉÓÔÅÍÁÈ, ÇÄÅ ÐÒÏÔÏËÏÌ IPv6 ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ ÂÁÚÏ×ÏÊ ÂÉÂÌÉÏÔÅËÏÊ Apache Portable Runtime, Apache ÐÏ ÕÍÏÌÞÁÎÉÀ ÐÏÌÕÞÁÅÔ ×ÏÚÍÏÖÎÏÓÔØ ÓÌÕÛÁÔØ IPv6 ÓÏËÅÔÙ (sockets). ÷ ÄÏÂÁ×ÏË Ë ÜÔÏÍÕ ÄÉÒÅËÔÉ×Ù directive module=mpm_commonListen/directive, directive module=core NameVirtualHost/directive É directive module=core VirtualHost/directive ÍÏÇÕÔ ÒÁÂÏÔÁÔØ Ó ÁÄÒÅÓÎÙÍÉ ÓÔÒÏËÁÍÉ, ÚÁÄÁÎÎÙÍÉ × ÆÏÒÍÁÔÅ IPv6 (Ô.Å. ÎÁÐÒÉÍÅÒ Listen [fe80::1]:8080)./dd dtstrongéÓÐÏÌØÚÏ×ÁÎÉÅ ÆÉÌØÔÒÏ×/strong/dt ddíÏÄÕÌÉ Apache ÔÅÐÅÒØ ÍÏÇÕÔ ÂÙÔØ ÎÁÐÉÓÁÎÙ ËÁË ÆÉÌØÔÒÙ, ÏÂÒÁÂÁÔÙ×ÁÀÝÉÅ ÐÏÔÏËÉ ÄÁÎÎÙÈ, ËÏÔÏÒÙÅ ÐÒÉÈÏÄÑÔ ÉÌÉ ÉÓÈÏÄÑÔ ÉÚ ÓÅÒ×ÅÒÁ. üÔÏ ÐÏÚ×ÏÌÑÅÔ, Ë ÐÒÉÍÅÒÕ, ÄÁÎÎÙÍ, Ñ×ÌÑÀÝÉÍÓÑ ÒÅÚÕÌØÔÁÔÏÍ ÒÁÂÏÔÙ CGI-ÓËÒÉÐÔÁ, ÂÙÔØ ÏÂÒÁÂÏÔÁÎÎÙÍÉ SSI ÆÉÌØÔÒÏÍ INCLUDES, ÐÒÅÄÏÓÔÁ×ÌÑÅÍÙÍ ÍÏÄÕÌÅÍ mod_include./dd dtstrongóÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ ÎÁ ÒÁÚÎÙÈ ÑÚÙËÁÈ /strong/dt ddóÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ, ÐÏÓÙÌÁÅÍÙÅ ÂÒÁÕÚÅÒÕ, ÔÅÐÅÒØ ÐÒÅÄÓÔÁ×ÌÅÎÙ ÎÁ ÎÅÓËÏÌØËÉÈ ÑÚÙËÁÈ É ÉÓÐÏÌØÚÕÀÔ SSI ÔÅÈÎÏÌÏÇÉÀ. ïÎÉ ÍÏÇÕÔ ÂÙÔØ ÌÅÇËÏ ÏÔÒÅÄÁËÔÉÒÏ×ÁÎÙ ÁÄÍÉÎÉÓÔÒÁÔÏÒÏÍ ÐÏÄ Ó×ÏÉ ÎÕÖÄÙ./dd dtstrongõÐÒÏÝÅÎÎÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ/strong/dt ddíÎÏÇÉÅ ÚÁÐÕÔÁÎÎÙÅ ÄÉÒÅËÔÉ×Ù ÂÙÌÉ ÕÐÒÏÝÅÎÙ. îÁÉÂÏÌÅÅ ÓÂÉ×ÁÀÝÉÅ Ó ÔÏÌËÕ Port É BindAddress ÂÙÌÉ ÕÂÒÁÎÙ; ÄÌÑ ÐÒÉ×ÑÚËÉ Ë IP ÁÄÒÅÓÕ ÉÓÐÏÌØÚÕÅÔÓÑ ÔÏÌØËÏ ÄÉÒÅËÔÉ×Á Listen; ÄÉÒÅËÔÉ×Á ServerName ÏÐÒÅÄÅÌÑÅÔ ÔÅÐÅÒØ ÉÍÑ ÓÅÒ×ÅÒÁ É ÎÏÍÅÒ ÐÏÒÔÁ ÔÏÌØËÏ ÄÌÑ ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÊ É ÒÁÂÏÔÙ Ó ×ÉÒÔÕÁÌØÎÙÍÉ ÈÏÓÔÁÍÉ./dd dtstrongðÏÄÄÅÒÖËÁ ÀÎÉËÏÄÁ ÄÌÑ Windows NT/strong/dt ddApache 2.0 ÎÁ Windows NT ÔÅÐÅÒØ ÉÓÐÏÌØÚÕÅÔ ËÏÄÉÒÏ×ËÕ utf-8 ÄÌÑ ÒÁÂÏÔÙ Ó ÉÍÅÎÁÍÉ ÆÁÊÌÏ×. üÔÏ ÐÏÚ×ÏÌÑÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ ÎÉÖÅÌÅÖÁÝÕÀ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ, ÒÁÂÏÔÁÀÝÕÀ × ÆÏÒÍÁÔÅ Unicode, ÞÔÏ ÐÒÅÄÏÓÔÁ×ÌÑÅÔ ÐÏÄÄÅÒÖËÕ ÓÅÒ×ÅÒÏÍ ÍÎÏÇÏÑÚÙÞÎÏÓÔÉ ÄÌÑ ×ÓÅÈ NT- ÓÉÓÔÅÍ, ×ËÌÀÞÁÀÝÉÈ Windows 2000 É Windows XP. emüÔÏ ÎÅ ÒÁÓÐÒÏÓÔÒÁÎÑÅÔÓÑ ÎÁ ÔÁËÉÅ ÏÐÅÒÁÃÉÏÎÎÙÅ ÓÉÓÔÅÍÙ, ËÁË Windows 95, 98 ÉÌÉ ME, ËÏÔÏÒÙÅ ÄÌÑ ÏÂÒÁÝÅÎÉÑ Ë ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ ÉÓÐÏÌØÚÕÀÔ ÌÏËÁÌØÎÙÅ ÍÁÛÉÎÎÙÅ ËÏÄÏ×ÙÅ ÓÔÒÁÎÉÃÙ./em/dd /dl /section section id=module titleõÌÕÞÛÅÎÉÑ × ÍÏÄÕÌÑÈ ÓÅÒ×ÅÒÁ/title dl dtstrongmod_ssl/strong/dt ddîÏ×ÙÊ ÍÏÄÕÌØ ×
Re: New draft of manual style
* Joshua Slive wrote: with the help of google I took a crash course in XSLT and tried to complete your work. Fun, isn't it? ;-) oh, yes ;-) I spent several hours to find out that the things I wanted, don't work with xslt... however, I've learned much by doing that :) * reverted the link colors to the proposed :) the green and the red, weren't a good choice, imho. there was too less contrast between them. (e.g. I have problems with red green, like about 20% of men) But now you've chosen red for the module entries. I really like to restrict the use of red to things that we want to be important (like security warnings). It is too jarring to see in ordinary text. hmm, my red and green were much more different in contrast, but ok. I set the module color now to blue (like in the current version) * but, you're right, I removed the underlines of code and module links for better reading My problem is that there is too many different link colors and actions. I prefer that hover trigger only a single, consistent change. In your versions, sometimes hovering adds an underline, and sometimes it removes it. Sometimes it triggers a color change, and sometimes it doesn't. In addition, colors tend to get less forceful when you hover. This seems backwards to me. Hovering should make the link stronger, because it gets you closer to the action. modified the link styles as follows: * a:link color = a:hover = a:active * a:hover and a:active are always underlined * a:visited is less forceful everywhere this results in: - no change, if the link is underlined and not visited - color change, if the link is underlined and not visited - underline change if the link is not underlined and not visited - color underline change if the link is not underlined and visited better? See my previous email question re the semantics of th. the table /head/ is defined by thead, table /header cell/ by th. They may appear everywhere a table header cell is needed. * a lot of small issues, thus the xsl produces proper HTML (e.g. exampletable..., used in howto/htaccess.xml) I don't like the way you handled example in the xslt. Your code essentially says if it is pre or table, then leave it, otherwise wrap it in p class=example. nope. I always put the example into div class=example. Your previous version didn't validate, because you set up: div class=examplecode [ example content ] /code/div if example content is a pre or a table, you get a problem. code is an inline element and cannot contain blocklevel elements like pre or table. So my code produces three variants: div class=example pcode [ simple text ] /code/p /div !-- or -- div class=example pre [ preformatted text ] /pre /div !-- or -- div class=example table [ table ] table /div This is meant as: an example that contains a paragraph containing code or an example that contains preformatted text or an example that contains a table. Maybe we could say: an example that contains preformatted text containing code. IMHO, that behavior is correct. (If that doesn't make sense, think of example as an element like blockquote or li. These elements can take pretty much any contents in xhtml. They may contain complete paragraphs in p, or they may contain just some simple bare text It would not make any sense (semantically or otherwise) to wrap the entire contents of a blockquote in p.) ;-) Blockquote is not a good example. It is intended to contain block level elements. http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd In transitional DTD it may contain %flow;, but I'd never recommend the transitional DTD - especially in our case there's no need for that. Probably we also need some modifications to the DTDs: Let's address that as a seperate issue. If you want to look at changing that right now, please start a new thread. ok :) later nd -- s s^saoaaaoaaoaaaom a alataa aaoat a a a maoaa a laoata a oia a o a m a o alaoooat aaool aaoaa matooololaaatoto aaa o a o ms;s;\s;s;g;y;s;:;s;y#mailto: # \51/\134\137| http://www.perlig.de #;print;# [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New draft of manual style
* Joshua Slive wrote:
1. There was one main reason I stopped developing the wacky style:
complexity. If felt it was over-complex both visually and
particularly the css and html code. The css code had the advantage
that it was externally developed and maintained at style.tigris.org,
but I still didn't like using something that seemed difficult to
maintain.
probably nice to hear :)
I revised the css completey and hope that the ruleset is now more
simple.
2. Let's try to determine exactly what about the original style people
like better. Perhaps we can combine the two in a way that will work.
Some suggestions:
a) Black-on-white. I tend to agree that this is preferred.
hmm, really: black on white is too much contrast. After a while it hurts
my eyes. But I can imagine, that for example japanese characters
(symbols? could someone lead me to the right term, please? ;-) are
better to read then, because they are much more complex.
Of course, with xslt we are able to include a different style sheet for
such case. But that's probably not a good idea.
b) Side-menu listing important stuff seperate from text rather than
having the menu integrated from the text. I like this, but I'm not
sure how much it is about the cool factor. It also leads to the
obvious disadvantage of having to put the whole darn page in a table,
which is annoying but very common for modern sites.
I don't like the sidebar, because it wastes so much space. On the other
hand on large pages, like mod/core.html it's useful and makes the page
more clear.
c) Smaller font. As I mentioned in the original discussion, smaller
fonts tend to look more modern and professional, since almost all
major websites now use a less-than-default font size. Of course, it
is silly to contradict what the user set as their default font, but
since almost all sites do it, small can almost be considered the
default.
-1 for font-size: small.
If we want a small(er) font, I'd propose using px instead, because if
someone set up his browser to use a smaller font by default, a
font-size:small will lead to a non-readable document.
d) Other things ??? (I think the header and footer from the new
version are nicer, and I also prefer how the section titles are now
handled...)
I've added a Modules breadcrumb on modulesynopsis pages.
And, more technical: added xml:lang and lang attribute to html.
Also sourced out the menu items to the $lang.xml files.
This results in the following changes (in $lang.xml)
messages lang=en
!-- attribute containing the language token. --
!-- breadcrumb links --
message name=apacheApache/message
message name=http-serverHTTP Server/message
message name=documentationDocumentation/message
message name=versionVersion 2.0/message
!-- super menu --
message name=modulesModules/message
message name=faqFAQ/message
message name=glossaryGlossary/message
message name=sitemapSitemap/message
!-- footer line --
message name=maintainedbyMaintained by the /message
I'm a bit unsure about the term Apache HTTP Server Documentation
Project in the footer line. It's yet hardcoded in the common.xsl,
because I think, it's the proper noun of the project and should not be
translated. (?)
you'll find my current work at:
http://test.perlig.de/apdoc/manual/
I set up several alternate style sheets (loose style, sidebar, color
schemes), which you may try out using a browser that can handle them
(e.g. mozilla).
The whole stuff is rolled in:
http://test.perlig.de/apdoc/manual.zip
(1.3 MB, windows \n) and
http://test.perlig.de/apdoc/manual.tar.gz
(0.98 MB, unix \n)
nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #
[ $japh =~ /{(.)}/] - [0] = map $_ - () #André Malo #
= @japh;# http://www.perlig.de/ #
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] upgrading.xml - little misprint
on 29.08.2002 16:38 Uhr Ilia Soldis ([EMAIL PROTECTED]) wrote: In this paragraph the word 'where' was used instead of 'were'. Comitted. Thanks. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: New draft of manual style
Hi Joshua, I'm not sure whos argument it supports, but I thought I would point out that, coincidentally, Jakob Neilson's latest usability Alertbox is on font-size: http://www.useit.com/alertbox/20020819.html - At least let users override whatever default font size you have, i. e. don't use px as M$IE cannot override it (Opera and Mozilla can). - Select a default so that as few as possible users need to know how to override it (i. e., 10+ pt). Capable users will override it anyway, so care about those who know less about their browser configuration. - Kess' suggested alternate style sheet is explicitly approved by Nielsen. :-) - Nielsen votes for maximum color contrast and doesn't like grey ... just as his own pages look like. ;-( Regards, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
