Karl wrote:
>Todd Blanchard skrev: >> On Oct 9, 2006, at 11:23 AM, Lex Spoon wrote: >>> As far as I know Scamper parses HTML just fine. If you think not, >>> maybe lobby to get Scamper using your parser? What is better about >>> it? >> It understands CSS. >> It understands DOCTYPEs >> It understands W3C DOCTYPE definitions for the various >> HTML/XHTMLstandards and can use them to guess about and recover from >> malformed HTML. It can download new DOCTYPES and use them. This >> makes it somewhat future proof. >> >> It has support for more modern tags like DIV and SPAN (missing in >> Scamper). >This sounds good :-) >> The only thing it is missing to be on par with modern browser like >> Firefox is Javascript support - which could be added either via a >> SpiderMonkey plugin, or a native JS interpreter, and plugin support. >Sounds like building Scamper on top of your parser is a good idea. When I played a little with trying to get Jon Hyland's MediaView browser working, I was never able to get Todd's HTML parser to load properly in a normal Squeak image. I was looking at possibly using Josh Gargus's port of Cassowary as a screen layout manager, since it seems to be made for just this kind of application. Here are a few observations: . Scamper has some understanding of MIME which MediaView doesn't. . Scamper is based on Morphic. . MediaView has lots of rendering code for different HTML elements, but I believe is dependent on a screen layout manager that was a separate (not included) part of the customized environment that MediaView was part of. . MediaView does NOT use Morphic, but instead uses Forms and more direct interaction with the Display. . Todd's HTML parser has the advantages he listed above. . Cassowary is "an incremental constraint solving toolkit that efficiently solves systems of linear equalities and inequalities." >From reading its documentation, I believe that it could be quite useful as a screen layout manager. . There has been some talk lately on the list of dropping HTTPSocket in favor of Steven Waring's HTTPClient code. In most respects that would probably be a good move. . It would be desirable to use ToolBuilder, so that a new web browser could be used in Morphic, Tweak, MVC and whatever else is built on the ToolBuilder API. So there are lots of parts to choose from, but I think integration might be a challenge. |
David Faught skrev:
> Karl wrote: >> Todd Blanchard skrev: >>> On Oct 9, 2006, at 11:23 AM, Lex Spoon wrote: > >>>> As far as I know Scamper parses HTML just fine. If you think not, >>>> maybe lobby to get Scamper using your parser? What is better about >>>> it? > >>> It understands CSS. >>> It understands DOCTYPEs >>> It understands W3C DOCTYPE definitions for the various >>> HTML/XHTMLstandards and can use them to guess about and recover from >>> malformed HTML. It can download new DOCTYPES and use them. This >>> makes it somewhat future proof. >>> >>> It has support for more modern tags like DIV and SPAN (missing in >>> Scamper). > >> This sounds good :-) > >>> The only thing it is missing to be on par with modern browser like >>> Firefox is Javascript support - which could be added either via a >>> SpiderMonkey plugin, or a native JS interpreter, and plugin support. > >> Sounds like building Scamper on top of your parser is a good idea. > > When I played a little with trying to get Jon Hyland's MediaView > browser working, I was never able to get Todd's HTML parser to load > properly in a normal Squeak image. I was looking at possibly using > Josh Gargus's port of Cassowary as a screen layout manager, since it > seems to be made for just this kind of application. > > Here are a few observations: > . Scamper has some understanding of MIME which MediaView doesn't. > . Scamper is based on Morphic. > . MediaView has lots of rendering code for different HTML elements, > but I believe is dependent on a screen layout manager that was a > separate (not included) part of the customized environment that > MediaView was part of. > . MediaView does NOT use Morphic, but instead uses Forms and more > direct interaction with the Display. > . Todd's HTML parser has the advantages he listed above. > . Cassowary is "an incremental constraint solving toolkit that > efficiently solves systems of linear equalities and inequalities." >> From reading its documentation, I believe that it could be quite > useful as a screen layout manager. > . There has been some talk lately on the list of dropping HTTPSocket > in favor of Steven Waring's HTTPClient code. In most respects that > would probably be a good move. > . It would be desirable to use ToolBuilder, so that a new web browser > could be used in Morphic, Tweak, MVC and whatever else is built on the > ToolBuilder API. > > So there are lots of parts to choose from, but I think integration > might be a challenge. > > I think the layout part is the hardest and will be hard to do in toolbuilder as one would need deep integration with the framework. I also thought about using Cassowary but never got around to really understand it. I have not looked at any of the other code you mention. In my HTMLTableMorph project I used a nice addition to the MorphicLayout by a french Squeaker, can't remember his name, that was quite good for the table layout. The next stage was to get the text morphs to behave and that is where I put the project on ice. I'll dig it up the code and put it on SqueakSource. Karl |
In reply to this post by David Faught
"David Faught" <[hidden email]> writes:
> Here are a few observations: Wow, great research, David! Very helpful. > . There has been some talk lately on the list of dropping HTTPSocket > in favor of Steven Waring's HTTPClient code. In most respects that > would probably be a good move. I do not know this code, but any carefully written HTTP implementation would likely be an improvement. HTTPSocket was written for a demo, and has had various patches added over time, and it has always just barely done well enough that no one got excited to clean it up and/or rewrite it. -Lex |
Lex Spoon skrev:
> "David Faught" <[hidden email]> writes: > >> Here are a few observations: >> > > Wow, great research, David! Very helpful. > > > >> . There has been some talk lately on the list of dropping HTTPSocket >> in favor of Steven Waring's HTTPClient code. In most respects that >> would probably be a good move. >> > > I do not know this code, but any carefully written HTTP implementation > would likely be an improvement. HTTPSocket was written for a demo, > and has had various patches added over time, and it has always just > barely done well enough that no one got excited to clean it up and/or > rewrite it. > > > -Lex > The SqueakMap download is from a server not running anymore. Karl |
In reply to this post by David Faught
On Oct 11, 2006, at 6:03 AM, David Faught wrote: > I was never able to get Todd's HTML parser to load > properly in a normal Squeak image. I suspect you ran into a problem caused by a dependency on a PList parser class I used to initialize a state table and did not include in the package. I think I have fixed this by including the class in the package, but I need to try a clean load. A modern web browser needs to be sure to implement the box model specified in css2. http://www.w3.org/TR/REC-CSS2/box.html There is also a fair amount of useful info on how mozilla does layout here: http://www.mozilla.org/newlayout/doc/layout.html Table layout behavior is specified here: http://www.w3.org/TR/REC-CSS2/tables.html This stuff is a lot more rigorously specified now than it was when Scamper was written. Its just a matter of digging up the instructions and implementing them. I'd help more if I had a bit more time. Perhaps after the first of the year I'll have some time. -Todd Blanchard |
In reply to this post by karl-8
check your mailbox
On Oct 13, 2006, at 12:16 AM, karl wrote: > Lex Spoon skrev: >> "David Faught" <[hidden email]> writes: >> >>> Here are a few observations: >>> >> >> Wow, great research, David! Very helpful. >> >> >> >>> . There has been some talk lately on the list of dropping HTTPSocket >>> in favor of Steven Waring's HTTPClient code. In most respects that >>> would probably be a good move. >>> >> >> I do not know this code, but any carefully written HTTP >> implementation >> would likely be an improvement. HTTPSocket was written for a demo, >> and has had various patches added over time, and it has always just >> barely done well enough that no one got excited to clean it up and/or >> rewrite it. >> >> >> -Lex >> > Anybody know where to get Steven Waring's HTTPClient. > The SqueakMap download is from a server not running anymore. > Karl > |
Todd Blanchard skrev:
> check your mailbox Thanks. Karl > > On Oct 13, 2006, at 12:16 AM, karl wrote: > >> Lex Spoon skrev: >>> "David Faught" <[hidden email]> writes: >>> >>>> Here are a few observations: >>>> >>> >>> Wow, great research, David! Very helpful. >>> >>> >>> >>>> . There has been some talk lately on the list of dropping HTTPSocket >>>> in favor of Steven Waring's HTTPClient code. In most respects that >>>> would probably be a good move. >>>> >>> >>> I do not know this code, but any carefully written HTTP implementation >>> would likely be an improvement. HTTPSocket was written for a demo, >>> and has had various patches added over time, and it has always just >>> barely done well enough that no one got excited to clean it up and/or >>> rewrite it. >>> >>> >>> -Lex >>> >> Anybody know where to get Steven Waring's HTTPClient. >> The SqueakMap download is from a server not running anymore. >> Karl >> > > > |
Free forum by Nabble | Edit this page |