>-----Original Message----- >From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 23, 2006 4:29 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [doc] Intrim solution > >Morozova, Nadezhda wrote: >> Geir, >> >> Thanks for your effort in migrating docs to a more stable state inside >> the website. I've been examining your solution, and here are my >> comments: >> >> 1) Nice and quick way to import new docs into the website without >> converting them into XML for internal processing. Never thought of it :) >> >> 2) Source of resulting file is not optimal because: >> - Doctype declarations, metatags and head content are copied >> from the imported document into the middle of the >> resulting HTML code >> - <body> of the page HTML has a nested <body> of imported >> document > >Yep, but has there been any reported bad effects? > > >> 3) Stylesheet referenced in resulting document is applied to the whole >> page, including the left navigation menu. > >Yep. > >> >> This last point can be workarounded easily by making minor changes in >> the referenced stylesheet (I could do this and send you a patch). >> However, I don't like this solution and would rather vote for a common >> CSS for the whole website. > >Yep! > >> >> A major obstacle to having one CSS for the Harmony website is that >> there's no such CSS at the moment! L&F of page content is set in the >> .vsl file that Anakia uses. >> I suggest that we move away from this by reducing .vsl to processing >> only and move out all presentation tags into a Harmony-wide CSS. This >> would help us: >> - reduce file size (and consequently i-net traffic) for Harmony website: >> you load only one file instead of loading the same styles for each page >> - reduce effort of integrating more docs into the website: each doc >> references the same stylesheet and is displayed in the same way >> - simplify doc structure: no nested <body> and <meta> elements; numerous >> <font> tags replaced with a hierarchical HTML tag and class structure >> - clarify website functioning mechanism: distinguish processing macros >> and presentation of resulting output >> >> If the community agrees, I could try and implement this solution. >> That would take a relatively significant amount of time as it would >> include: >> 1) Editing .vsl to remove presentation info and improving structure of >> resulting HTML code >> 2) Creating a .css and testing it to fit existing files and new ones >> 3) Going through all current XML files making up the website to make >> adjustments in <body> content per new CSS requirements (can be done by a >> script or auto-replacement but still) > >The last one I don't understand. Rarely is there any L&F info in the >XML - that's the point of this approach - that the document content - >the XML - is independent of the rendering. > >> >> All in all, this seems like a serious effort. Help most welcomed! >> > >Sounds good - I wouldn't try to bite it all off at once - I'd start with >seeing what it takes to get a basic CSS applied in the .vsl and start >looking at it from there. > >Lets try to do this incrementally, so if we decide not to do it, the >investment is as small as possible. >
+1 I'd even prefer the resulting HTML could be validated as valid HTML 4.01 Strict. Regards, Alexey. >(IOW, go for it!) > >geir > >--------------------------------------------------------------------- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
