On Jul 4, 2011, at 9:17 AM, Joe Schaefer wrote: > ----- Original Message ---- > >> From: Dave Fisher <dave2w...@comcast.net> >> To: ooo-dev@incubator.apache.org >> Cc: ooo-comm...@incubator.apache.org >> Sent: Mon, July 4, 2011 12:09:53 PM >> Subject: Re: svn commit: r792168 - in /websites/production/openofficeorg: ./ >> content/openofficeorg/people.html >> >> >> On Jul 4, 2011, at 8:54 AM, Joe Schaefer wrote: >> >>> At 23' full-screen it renders just fine ;-). I'd say try >>> playing with the min-width css attribute for th or td. >>> >>> >>> You have a choice here of using ooo.css or embedding >>> a <style type="text/css"> block in the markdown just >>> before the table. >> >> That will be a PITA - each column needs a different minimum width and there >> is >> no way to differentiate. > > Perhaps you can describe "why" you need to do this?
Yes. not everyone has a big screen like you. A lot of people have learned that eye fatigue is aggravated by reading long lines. > Would simply using between the text words resolve this? Perhaps, so. I'll be experimenting with the headers. But for me knowing pixels is a little easier than counting >> Maybe someone should enhance markdown extras. >> >> http://michelf.com/projects/php-markdown/extra/#table >> >> All it can do is control the alignment. Width control ought to be allowed, >> either that or an id / class tag to actually tie it in with specific css. >> >> | Item | Value | >> | ------200 | --:100| >> | Computer | $1600 | >> | Phone | $12 | >> | Pipe | $1 | >> >> Thoughts? > > You do realize that the CMS allows you to do arbitrary things with the > markdown, > including preprocessing it before sending it off to the templating system. > Also > the python markdown parser is extensible, so if you prefer going that way and > contributing code to infra we can add a custom extension for everyone to use. Yes, I do. I am currently thinking about the OOo webcontent and conversion of the html. There will be thousand of pages, but hopefully not too many patterns. > >> >> Otherwise I really don't see why it's wrong to have the html table here. > > If you had examined the content of the table you might have noticed how > bloody > awful > the html was (filled with unmatched tags). What you have now is far more > maintainable > in a collaborative context- humans make terrible html parsers. Agreed. Not everyone has written lexers and parsers. I'm just frustrated by the movement of the controls. Regards, Dave
