Summary

[Lars Knoll]

Hi ,

thanks for summing the conference up. I think you got most points. I have some 
comments on parts of the points:

>   re: rendering/font.cpp: its clear that we never reach a common codebase
>   here. I'll just rename our file to font_x11.cpp soon in CVS, Safari
>   can just fork the complete file and name it font_darwin.cpp or whatever.

With Qt-3.2 out codebase will get simpler aswell, as QFont in 3.2 can do CSS 
style name matching of a list of families. I think the safari code already 
relies on this being handledd by the OS.

>   re: misc/decoder.cpp: Our code is crap basically, as we don't do
>   automatic encoding guessing properly and are by far wrong in many cases.

Yes. The autodetection needs quite some work.

>   It was suggested to sync up safari codebase with the latest stable
>   release, which is KDE 3.1 (3.1.1 soon). Should Konqueror backport the
>   new CSS parser for 3.1.1 ? Its definitely still hardly tested. Also
>   I'm personally unsure about the performance impact of the new CSS parser,
>   I've heard that bison generated code is quite slow (gcc developers
>   are bitching about that). IMHO it requires profiling first.

I'll bite into my keyboard if it's slower than the old code ;-)

The old parser relied on thousands of string comparisons, while we now do most 
of the work in a state machine. The old code was doing a huge amount of 
string copying, simplifyWhiteSpace calls etc. All this went away. 

Anyway, the CSS parser was never a speed bottleneck, it's the style selector 
that could need further tuning.

But you're right it's not tested as extensively as the old code. However it 
does pass almost all of the CSS1 test suite (except for the stuff which would 
need the rewrite of the inline box model), and I haven't seen a bug on real 
world web page I could assign to the css parser for some time now. 

The parser honours the CSS "forward compatible parsing rules", but I am 
currently not sure these error handling rules do not introduce some memory 
leaks, as the bison code just pops elements of the stack in this case. This 
is solvable however.

> - Testsuite: The "No regression" topic was discussed, and both sides
>   expressed interest in achieving an automated regression testing before
>   commit. Safari codebase apparently has automated testing already for
>   rendering quality, stability, memory impact and performance (Mozilla
>   development style comes to my mind..).

The safari team also does testing of speed regressions. I think this (aswell 
as maybe memory usage regressions) would be good for us aswell. 

Cheers,
Lars