Bruce Dubbs wrote: > It seems that your idea is for a look and feel change along with a dynamic > change of the book depending on the type if PM chosen by the user.
No, not really, sorry if it came across that way. The page layout was a product of some other work I had been doing in unrelated (non-LFS) work. I had to format what was output so that it would be recognizable, and in doing so, I just used some code pieces and css I had on hand. > Changing the look and feel may be a nice thing to do, but I wouldn't put it > at > the highest priority. There are lots of content issues that are more > important > in my opinion. It isn't a priority. If people want a change in the look of the book, that could come later. > Setting up for multiple PM types introduces a reasonably high level of > complexity. I think it also could detract from the learning aspect of the > book > as it selectively removes things. We also don't know yet how to do one > method > of PM, let alone multiple methods. If we do one, we are doing multiple. By that I mean that I believe if we introduce a PM method, we still want to allow people the choice of whether to use that or not, correct? So we will have at least two choices, PM-based instructions, or no-PM instructions. I don't know what you mean by 'selectively removes things'. > An issue that is not clear to me from your link is how I can make a change on > my > system locally and render the book and review the results before committing > the > change. Heh, which is probably why I should have waited before presenting it, so that more concepts would be clearer. A more robust POC would also have a 'Submit' button. The preview button just renders the page on your screen, while a submit would make a commit to the server. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
