incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Ellison <>
Subject Re: [www] html instead of markdown (mdtext)?
Date Thu, 11 Aug 2011 21:41:24 GMT

Surely this is looking at the issue the wrong way around.  HTML is a 
lower lever of abstraction.  Yes, this suggestion makes life easier for 
the maintainer but at the expense of extra complexity/difficulty for the 
contributor -- especially as the average contributor isn't at ease 
working in HTML, so will tend to use some form of WYSIWYG editor.  Hence 
different editors can end up laying out the HTML completely differently 
if they use different tools to do this, so an svn differencing of two 
successive versions with minor content changes could end up looking 
entirely different.

If we are going to HTML then perhaps it might be appropriate on this 
project to mandate the use of the OOo web editor for editing all such 
content.  Just a thought.

Regards Terry

On 11/08/11 19:55, Kay Schenk wrote:
> On Thu, Aug 11, 2011 at 10:13 AM, Dave Fisher<>  wrote:
>> On Aug 11, 2011, at 9:12 AM, Kay Schenk wrote:
>>> I am proposing that we adopt plain HTML for the OOo website instead of
>> the current markdown (mdtext) implementation.
>> We can mix and match.
> yes, but... mdtext is converted to html anyway. I just think the overhead --
> i.e. maintenance by existing and "new" folks -- will be unweildy.
>>> I hesitate to make this recommendation given ALL the time and research
>> Dave and others have already spent on the current incubator website, but, I
>> feel, given that we will be migrating a rather large existing site, it makes
>> sense.
>> Don't worry about me. What I've learned is useful to me even if we decide
>> to take another approach.
>> How do you propose handling all of the Kenai wrapping?
> uh...I'll be honest...I am not familiar with the " Kenai wrapping". And I
> dare say, probably few are. My *guess* is this in invovled in
> headers,footers, and ????
> We might be able to ignore whatever this is and just get on with something
> WAY simpler for the time being.
> The new site won't be registering users and probably doesn't need a lot of
>> the current *.vm and *.html.html files.
>>> I also realize that doing this will "break" the ability to use the webgui
>> editing capability of the Apache CMS, forcing everyone to use svn for page
>> updates. However, I don't have a good feel right now for the ultimate impact
>> of that -- e.g. what do we expect in terms of web site editors.
>> You really CAN edit HTML using the Apache CMS Web-Gui. It is just that I
>> currently like unwrapped body html.
> Oh--OK -- I hadn't tried this and this isn't what the web page about the CMS
> indicates.
> So, even better.
>>> This would allow us to continue to use the default template system
>> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
>> text with normal HTML. HTML files shouldn't require any "wrapping" functions
>> at all I think, since this is the indigenous format for web servers. We
>> would have to bypass header, footer and navigation items for anything that
>> *isn't* html, like js, css files.
>> In the back of my head this week I've been thinking about a way to use
>> properly formed html and then "rewrap" to apply consistent headers and
>> footers is forming. The idea is to use an xslt filter to extract html from
>> the<head>  and<body>.
> Well this may be super but unfortunately I am not knowledgable enough to
> really know what you're saying here. But isn't this the purpose of the
> template system -- to just patch on the headers, footers, anythng else?
> Again, I am thinking "project long-term". I think it's vital to put
> something in place that the regular web-jockey is familiar with.
>> For the head - grab various elements including scripts and style. For the
>> body grab it all. There are at least two advantages:
>> (1) Each html page can be separated and tested outside of site framework.
>> (2) Every html page published on the site automatically has the proper
>> framework.
>>> Unfortunately, I've had a very difficult time this week trying to find
>> any information on the setup details of Dotiac::DTL (documentation not
>> available) -- the relationship of the two .pm files to the template areas,
>> etc.
>> It took me sometime to understand how it works. If you follow the
>> instructions on running locally - website-local.mdtext - it ought to work.
> OK--I still have NOT done that.  The thing is the instructions still do NOT
> give details on the setup of Dotiac::DTL. If I installed that locally, maybe
> some documentation would emerge. And I will do that. There's LOADS of info
> on django -- but not this perl wrapper.
>> Perhaps we should IRC tomorrow and we can identify the disconnect in this
>> documentation.
> uh--sorry, I'm unavailable tomorrow. I think YOUR documentation is fine
> really for what you're trying to get people to do -- with dealing with
> mdtext. But, this is kind of my point.
> *IF* we went straight html, and *IF* the templates were setup and fixed in
> place -- yes, we'd need a perl/django wonk for this aspect (along with some
> MUCH better documentation on this aspect) --  folks wouldn't have to do a
> local setup at all. They'd simply edit HTML and commit the way we've always
> done in the past. Much simpler in my mind.
>>> I took at look around at many the Apache web areas (svn) at:
>>> You will see, as I did, that the vast majority are not using markdown,
>> and this is NOT a requirement.
>> It is not a requirement, it was a recommendation. (POI uses a very old
>> version of Forrest and no one has wanted to change...)
>>> Anyway, thoughts/comments on this proposal?
>> Let's see if others have something to say. (I've got some Fortran and SQL
>> to do today.)
> yes, good idea...have fun with your project
>> Regards,
>> Dave
>>> --
>>> ------------------------------------------------------------------------
>>> MzK
>>> "Those who love deeply never grow old;
>>> they may die of old age, but they die young."
>>>                         -- Sir Arthur Pinero

View raw message