incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: svn commit: r792168 - in /websites/production/openofficeorg: ./ content/openofficeorg/people.html
Date Mon, 04 Jul 2011 17:59:56 GMT

On Jul 4, 2011, at 9:39 AM, Joe Schaefer wrote:

<snip>

>>> 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.
> 
> That isn't useful feedback.  Useful feedback would be something like:
> the table columns break the text into two rows on whitespace-separated text.
> Or is it the reverse, that you *want* them to break into two rows (
> in which case you have a bug because that's not what happens on my
> screen)?

OK. I could have stated my issue more carefully. There are two different points here. One
is overall and the other is specific to this case.

(1) Overall we should all agree that we design our web content to look in a narrow window
like a laptop. Ten years ago this would be about 600px. Now I think we should work towards
800px. Then pages work on Tablets, Laptops, etc.

(2) The intent is for the shorter data in the first three columns to not wrap - while the
last column is very free-form. When not given widths I find that html layout gives too much
space to this content.

I now have it controlled by adding &nbsp; to the longest text in columns two and three.
The fourth column only wraps for three people on my 13" laptop and the table looks like it
was done by a professional.

> 
>>> Would  simply using &nbsp; 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 &nbsp;
> 
> No that's not what I meant for you to do.  What I meant was, look at the
> longest entry in each column and replace the separating whitespace in
> that one entry with &nbsp;.  If your problem is columns breaking prematurely
> this will resolve it.

Yes, this is what I did on my second try. Admittedly this moves the problem. A real solution
would modify markdown. This is something to think about.

>>>> 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.
> 
> We have an xslt file somewhere in the conversion-utilities directory
> that converts tables to markdown-style tables, if you decide to go that way
> (and I strongly recommend you do).  It's currently embedded in the
> anakia stuff but can easily be extracted.

Yes. A pointer to existing scripts is great. If you would give me the full repos path I'll
take a look this week.

You may have noticed that we've started with a webcontent fetch in ooo/trunk/tools/dev/.

>> 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.
> 
> Change happens. ;-)

And when two committers are in the same place discussion happens for all to see!

Regards,
Dave



Mime
View raw message