Re: SimpleWebKit (was GNUstep Web browser (was Re: WebKit Bounty))

[Dr. H. Nikolaus Schaller]

Am 07.03.2007 um 01:42 schrieb Peter Cooper:

> Hello
>
> The current progress in SimpleWebKit is very gratifying, I did a  
> test build of the code from a  few days ago and the code compiled  
> on GNUstep (with only one slight change to an #ifdef), and a simple  
> palette seemed quite buildable (although in that version of the  
> code there was no content rendering).

Great! Maybe, you can share the GNUmakefile?

> > Ok, that brings up a different aspect - maintaining an own web  
> > browser
> > is a duplicate of work. And that is a completey different topic/
> > decision.
>
> I agree, web browser application development is a bit out of scope  
> here. I'm not sure it fits into the GNUstep-as-library, or  GNUstep- 
> as-dev-env philosophy at all, but it probably works for the GNUstep- 
> as-desktop-env people.

Well, WebKit is more a library - allowing to easily build a browser...

> I'd imagine Etoile is more interested in a disarticulated,  
> embeddable-everywhere object ;-)
>
> > 1. SimpleWebKit as part of mySTEP is here and shows that it works.
> > 2. And I will continue to work on it since I have reasons to do so.
> > 3. The offer to the GNUstep community to adopt it for a GNUstep web
> > browser it is here.
> > 4. But the GNUstep community must decide if they want to follow this
> > path and integrate it or not.
>
> I would very much like SimpleWebKit to be included as a framework  
> into the GNUstep-gui or dev-libs collections. As a number of people  
> have mentioned, even a purely standards-compliant(!) (X)HTML  
> renderer has significant practical uses for many existing and  
> future tools and applications, especially where the application has  
> some control over it's source HTML.
>
> As Nikolaus says, it *is* possible to have a broadly-working  
> framework for virtually all web content if enough effort is  
> applied. The amount of effort to get there is - unfortunately -  
> likely to be very high. For that reason, agreeing with Richard  
> here, it'd be prudent to ensure that SimpleWebKit could be easily  
> swapped-out and replaced at runtime by a future port of WebKit  
> (with all those tens of people at Apple, webkit.org and the KHTML  
> crowd chasing compatibility with awful markup for us), and although  
> this can be left for a later date it'd be smart to think about  
> *how* to do this easily fairly soon.
>
> > The question remains to me why we should write a (new?) basic xhtml
> > view when we can have a full (x)html view - to avoid duplication.
>
> At this rate, we'll have running code (thanks for the screenshot by  
> the way!) available for integration soon.
>
> The previously-attempted port of WebKit has stalled and any new  
> port is (as far as I know, currently) vapourware. Choosing between  
> something available and vapourware is easy I think: there is no  
> actual duplication right now!
>
> The benefits of the future port of WebKit (all-of-web  
> functionality, extremely bullet-proof and widely tested code,  
> devteam numbering in the tens of people) are not significantly  
> diminished by having SimpleWebKit in the tree. I still need the all- 
> of-web functionality, for example, as do others! Are any more  
> people into helping with the bounty?
>
> Integrating SimpleWebKit into our tree is quite beneficial because  
> it makes some functionality available that we need (source code and  
> Nib compatibility with OSX, basic (X)HTML functionality), it is  
> available (Nikolaus is building it for his project), it is suitable  
> for limited-resource platforms, and there are other added social  
> bonuses in that we can add a little more development effort by  
> enhancing and testing SimpleWebKit which can be shared back to  
> QuantumStep if Nikolaus wishes.
>
> In summary, I'd like SimpleWebKit added, and when it's in svn,  
> perhaps more people can help out.

There have been suggestions to rename it from SimpleWebKit - why not  
simply call it GNUstep-htmlengine? There is GNUstep-base, GNUstep-gui  
which is pretty descriptive of what the role of the library is. It is  
a base library, a GUI library and this one is a htmlengine.
> I'd be interested in helping with the CSS components once I  
> understand a little more Nikolaus' approach to rendering.

Basically the approach is to parse HTML into a DOM tree (DOMHTML.h) -  
exactly as KHTML/WebKit does. Then, rendering is done top down from  
the WebHTMLView which has a single child, an NSTextView and the root  
of the DOM tree. The NSTextView finally renders an attributedString  
(well, an NSTextStorage), that is built from the DOM Tree. I.e.  
building this attributedString does half of the work and the other  
one is NSTextView.

This allows the trick for NSAttributedString(Additions) to fetch the  
attributedString out of the WebView to e.g. convert to RTF.

Now, adding CSS would be a similar approach. Either, the CSS  
description must load from a separate file first, or it is included  
in the DOM tree as <style> tags. So, the first step would be to parse  
the CSS into an DOMCSS tree. As soon as this is available, the DOM to  
attributedString conversion can use it to return a well formatted  
string. Finished loading of an external CSS must trigger the  
rendering to be repeated since layout and style may have changed.  
This is a bahaviour that you can see sometimes with Safari on a slow  
connection - firstly, you get a page with raw text and then the  
background, tables, images and formats come in.

Nikolaus