Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)

2005-10-10 Thread David Crossley
Ferdinand Soethe wrote: > > OK, since we all seem to agree on this I will write some piece for the > updated docs next week and leave the changes. Every major change should also be listed in site-author/status.xml file. A brief note would suffice and link to other info, such as the updating_*.htm

Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)

2005-10-07 Thread Ferdinand Soethe
OK, since we all seem to agree on this I will write some piece for the updated docs next week and leave the changes. -- Ferdinand Soethe

Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)

2005-10-07 Thread Kevin
On Fri, 2005-10-07 at 06:22 -0400, addi wrote: > On Friday October 07 2005 3:06 am, Ferdinand Soethe wrote: > > Ross Gardler wrote: > > > One of our community has raised a concern, > > > we have to address it. In this case I feel the call is yours as to > > > whether the changes stay or not (others

Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)

2005-10-07 Thread addi
On Friday October 07 2005 3:06 am, Ferdinand Soethe wrote: > Ross Gardler wrote: > > One of our community has raised a concern, > > we have to address it. In this case I feel the call is yours as to > > whether the changes stay or not (others will speak up if they have an > > opinion). > > Yes 'oth

General approach to backward compatibility (was: Re: Cleaning up html-processing)

2005-10-07 Thread Ferdinand Soethe
Ross Gardler wrote: > One of our community has raised a concern, > we have to address it. In this case I feel the call is yours as to > whether the changes stay or not (others will speak up if they have an > opinion). Yes 'others' please do! Problem is the interpretation of bugs and features

Re: Cleaning up html-processing

2005-10-06 Thread Ross Gardler
Ferdinand Soethe wrote: Ross Gardler wrote: Any solution applied to SVN should not change existing behaviour, even if that behaviour does not suit you. Make it configurable or, if you are using 0.8-dev you can simply add a project locationmap with a match for the stylesheet you don't like

Re: Cleaning up html-processing

2005-10-06 Thread Ferdinand Soethe
Ross Gardler wrote: > Any solution applied to SVN should not change existing behaviour, even > if that behaviour does not suit you. > Make it configurable or, if you are using 0.8-dev you can simply add a > project locationmap with a match for the stylesheet you don't like and > provide your own

Re: Cleaning up html-processing

2005-10-06 Thread Ross Gardler
Ferdinand Soethe wrote: Kevin wrote: Thanks for sticking with me. Just one point to finish with. The new code bypasses old working code that some web sites may depend on? A user may have been happy with the default cellpadding and cellspacing while setting their own class. Just a backw

Re: Cleaning up html-processing

2005-10-06 Thread Ferdinand Soethe
Kevin wrote: > Thanks for sticking with me. Just one point to finish with. > The new code bypasses old working code that some web sites > may depend on? A user may have been happy with the default > cellpadding and cellspacing while setting their own class. > Just a backward compatibility issue

Re: Cleaning up html-processing

2005-10-06 Thread Kevin
Hi Ferdinand, Thanks for sticking with me. Just one point to finish with. The new code bypasses old working code that some web sites may depend on? A user may have been happy with the default cellpadding and cellspacing while setting their own class. Just a backward compatibility issue, I'm sure

Re: Cleaning up html-processing

2005-10-05 Thread Ferdinand Soethe
Hi Kevin, thanks for taking the time to explain. Re-reading a forth time I now understand that with > I think should be: > > you actually suggested part of the fix that David later committed. I'm sorry. I just saw 'not' and your explanations below and concluded that you wanted to turn around

Re: Cleaning up html-processing

2005-10-05 Thread Kevin
On Wed, 2005-10-05 at 23:27 +0200, Ferdinand Soethe wrote: > Kevin wrote: > > > This is not my approach. It is in document2html.xsl code anyway. > > > Look at line after new > > After re-reading the whole thread a third time I still don't get what > your approach is. Would you mind explaining i

Re: Cleaning up html-processing

2005-10-05 Thread Ferdinand Soethe
Kevin wrote: > This is not my approach. It is in document2html.xsl code anyway. > Look at line after new After re-reading the whole thread a third time I still don't get what your approach is. Would you mind explaining it once more? Thanks, Ferdinand Soethe

Re: Cleaning up html-processing

2005-10-05 Thread Kevin
On Wed, 2005-10-05 at 08:26 +0200, Ferdinand Soethe wrote: > Ross Gardler wrote: > > > Sorry, I didn't follow this thread closely, I just noticed David had > > corrected Ferdinands commit. You seem to be suggesting that The commit > > should never have been made. Ferdinand, is that the case now t

Re: Cleaning up html-processing

2005-10-04 Thread Ferdinand Soethe
Ross Gardler wrote: > Sorry, I didn't follow this thread closely, I just noticed David had > corrected Ferdinands commit. You seem to be suggesting that The commit > should never have been made. Ferdinand, is that the case now that you > have found some other issues with what you were doing? N

Re: Cleaning up html-processing

2005-10-04 Thread Ferdinand Soethe
Kevin wrote: > I was suggesting undoing the change and going back to r232890, > thought it did the job correctly? Am I missing something? I've > added comments to template below. Sorry for not responding to this. While I was writing a response David fixed to problem. > Am I missing somethi

Re: Cleaning up html-processing

2005-10-04 Thread Ross Gardler
Kevin wrote: On Tue, 2005-10-04 at 17:24 +0100, Ross Gardler wrote: Ferdinand Soethe wrote: Even though class is empty and "" will show "" the test condition does not seem to work properly so all tables are now treated like in the otherwise branch. See Davids commit: http://svn.apach

Re: Cleaning up html-processing

2005-10-04 Thread Kevin
On Tue, 2005-10-04 at 17:24 +0100, Ross Gardler wrote: > Ferdinand Soethe wrote: > > > Even though class is empty and > > > > "" will show "" > > > > the test condition > > > > > > > > does not seem to work properly so all tables are now > > treated like in the otherwise branch. > > See Davi

Re: Cleaning up html-processing

2005-10-04 Thread Ferdinand Soethe
Ferdinand Soethe wrote: > Ferdinand Soethe wrote: >> Sorry for the wild goose chase. What I still don't know is why this >> doesn't work with my existing site (set up just a few weeks ago). >> Since stuff like this has happened a few times I almost feel like I >> should do all develop

Re: Cleaning up html-processing

2005-10-04 Thread Ross Gardler
Ferdinand Soethe wrote: Even though class is empty and "" will show "" the test condition does not seem to work properly so all tables are now treated like in the otherwise branch. See Davids commit: http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/skins/common/xslt/html/docum

Re: Cleaning up html-processing

2005-10-04 Thread Ferdinand Soethe
Ferdinand Soethe wrote: > Sorry for the wild goose chase. What I still don't know is why this > doesn't work with my existing site (set up just a few weeks ago). > Since stuff like this has happened a few times I almost feel like I > should do all development on freshly seeded installations

Re: Cleaning up html-processing

2005-10-04 Thread Ferdinand Soethe
Ross Gardler wrote: > I also was unable to find a border="1" sing search tools. Perhaps we can > work with Ferdinand to solve this on todays Forest Tuesday. Thanks. After Kevin's posting I got suspicious and tried a freshly seed site this morning. Border = 1 no longer shows and class is properl

Re: Cleaning up html-processing

2005-10-04 Thread Ferdinand Soethe
Ross Gardler wrote: > I also was unable to find a border="1" sing search tools. Perhaps we can > work with Ferdinand to solve this on todays Forest Tuesday. Thanks. Am on the road right now but will try to join in later today. -- Ferdinand Soethe

Re: Cleaning up html-processing

2005-10-03 Thread Ross Gardler
David Crossley wrote: Kevin wrote: Ferdinand Soethe wrote: But using these new transformation it becomes obvious that it is no longer a css-Effekt. If you make Forrest transform an html-file with something like . The resulting Forrest page will have I can't reproduce the bor

Re: Cleaning up html-processing

2005-10-03 Thread David Crossley
Kevin wrote: > Ferdinand Soethe wrote: > > > But using these new transformation it becomes obvious that it is no > > longer a css-Effekt. If you make Forrest transform an html-file > > with something like > > > > > > . > > > > The resulting Forrest page will have > > > > > > > > I

Re: Cleaning up html-processing

2005-10-03 Thread Kevin
On Sun, 2005-10-02 at 22:20 +0200, Ferdinand Soethe wrote: > Thanks Kevin, > > > Don't think there is. The border effect is achieved by setting the > > background colour in profile.css and using a cellspacing="1" on all > > ForrestTable classes. > > and yes. That may be true for ForrestTable cla

Re: Cleaning up html-processing

2005-10-02 Thread Ferdinand Soethe
Thanks Kevin, > Don't think there is. The border effect is achieved by setting the > background colour in profile.css and using a cellspacing="1" on all > ForrestTable classes. and yes. That may be true for ForrestTable classes. But the source I'm talking about has a different class attribute and

Re: Cleaning up html-processing

2005-10-01 Thread Kevin
On Sat, 2005-10-01 at 12:01 +0200, Ferdinand Soethe wrote: > After cleaning up a couple of rough edges in processing > and skinning table-elements in html-files I'm now stuck with the > problem of a border="1"-attribute appearing in table's that have a > class attribute in the source. > > Searchin

Cleaning up html-processing

2005-10-01 Thread Ferdinand Soethe
After cleaning up a couple of rough edges in processing and skinning table-elements in html-files I'm now stuck with the problem of a border="1"-attribute appearing in table's that have a class attribute in the source. Searching for border, border="1" and table in all the way downwards from webapp