In article <[email protected]>, John-Mark Bell <[email protected]> wrote: > On Wed, 14 Jan 2009, Michael Drake wrote:
> [CSS parser] > Even if it isn't, there's not enough work left to fill 10 weeks. The > selection algorithm can easily be implemented in a few days of full-time > resource, and that's the only major thing outstanding. The remaining > parsing issues are trivial in comparison. OK. Although, IIRC GSoC wanted organisations to have ideas with a broad range of difficulties and if a student finishes whatever project they undertook early, I'm sure we could come up with some other stuff that both the student and mentor would be interested in. :) As for libcss, won't integrating with NetSurf be a bit non-trivial? > [Dynamic pseudo classes] > > 7. Depends on libcss.draw. > Likely. It's mostly layout, however. Yep, we'd need some way for the core to know which bits of layout would be affected, run layout on those bits and then redraw. I think partial layout could take a fair bit of thinking about. > [Inlines] > > 10. The changes to make rendering take into account margins, paddings, > > splittings and nestings when plotting background colours, images > > and borders are done. There are still other issues like white-space > > property and vertical-align. > Right. Line heights are also fixed since then. The unicode line splitting thing mentioned on the old ideas page is not relevant, I think. It's a RUfl issue, I think, because that stuff works on the GTK port. James? > [Keyboard nav, other platforms, page reader, RO gui code -> library] > > The rest (2, 3, 6 and 8) can all be run again, as those aspects haven't > > been touched. > The first three seem reasonable. I have serious reservations about > a) finding someone suitably qualified and b) the utility of extracting a > library from the RO UI code. Well a) shouldn't be a concern for us. Perhaps you're right for b), although I think it might be nice. Maybe we could have an idea about doing RO GUI work like tabs. > > Also, we can think up new projects. I'll have a think about that for a > > few days. > One that is obvious to me is libdom. It needs the following doing to it: > 1) Fixing so it compiles > 2) Sort out the mess that is dom_string > 3) Use vtables rather than known function names + switching on node type > 4) Test suite > 5) Write a binding to hubbub > 6) The rest of DOM 3/2/1/0 implementing (primarily, Events) Cool. I guess it's a bit early for discussing details, but maybe 1) should be done before GSoCage. The idea that leaps out at me is a layout and box tree test system and test suite. It would be ideal if we already had a separated layout engine, but I guess something could be done like making a minimal NetSurf front end and working off that. IIRC, there's a framebuffer front end which doesn't do any framebuffer stuff. The tester could work by dumping layout stuff like box tree with sizes and position details and matching with a test suite. Michael -- Michael Drake (tlsa) http://www.netsurf-browser.org/
