- From: Dailey, David P. <david.dailey@sru.edu>
- Date: Tue, 26 May 2009 13:04:32 -0400
- To: "Dailey, David P." <david.dailey@sru.edu>, "Doug Schepers" <schepers@w3.org>
- Cc: <public-svg-ig@w3.org>
Incidentally, both http://srufaculty.sru.edu/david.dailey/cs427/StateOfArt-Dailey.html and http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html seem to be crashing my recently installed version of IE8. I didn't have this problem with IE7. Does anyone else have an IE8 to test? David -----Original Message----- From: public-svg-ig-request@w3.org [mailto:public-svg-ig-request@w3.org] On Behalf Of Dailey, David P. Sent: Tuesday, May 26, 2009 12:12 PM To: Doug Schepers Cc: public-svg-ig@w3.org Subject: RE: Another draft of SVG book: Draft 2.0 Hi all, Just got back from a long weekend and saw the discussion. Thanks Doug! Let me respond to a few issues and then ask some questions. >I spent a considerable amount of time (a few hours) cleaning up the HTML code to make it well-formed and valid (which is why it took me so long to upload it). I really hope we can avoid that in the future. I know you originally wrote the book in a text editor (MS Word?), but hopefully someone out there can recommend an HTML-output editor that won't butcher the code. Any suggestions? I've been using Macromedia Homesite and doing the HTML manually. Homesite doesn't do any wysiwyg but is rather like notepad++ or other similar things in being a code-based editor. Any deviation from well-formedness would either descend from the original Word to HTML conversion or from oversights I introduced with manual editing. This latter category should be relatively few in number. I think we should be okay, now that we have a clean version to work with. Ruud had found some 1500 of those, so I know how ugly those several hours would have been. >A lot of the problems revolved around blocks of code, tables (often with annotated code), block quotations, <pre> blocks, and styling. Well problems with styles could have been introduced by me. Compare http://srufaculty.sru.edu/david.dailey/cs427/StateOfArt-Dailey.html#operations with the corresponding part at http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html (the links in the Table of Contents don't work now). I see you've removed all the custom styling. Probably to rely on the W3C style sheet at http://www.w3.org/StyleSheets/TR/W3C-ED ?? I had introduced a number of styles to deal with the code blocks since there are actually several different contexts in which code is represented. The only way I could style some of the code to make it look good was to put it inside a table and then style from there. Search for the words "One more example may help to clarify a bit" in the two documents http://srufaculty.sru.edu/david.dailey/cs427/StateOfArt-Dailey.html and http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html -- <pre> and <code> and < together with <div> would not seem to allow the desired effect to be rendered across browsers (particularly IE, where many of the problems occur). It would be nice to be able to style the code blocks the way they are done in http://srufaculty.sru.edu/david.dailey/cs427/StateOfArt-Dailey.html >I think we can avoid most of those problems by coming up with a cleaner way to handle the content that is now in tables. Most of that is not actually tabular data, but is being used for layout and positioning. The annotations in particular could be handled by CSS much more nicely. Yeah. The problem right now is that there are about six different kinds of code blocks with and without illustrations. I thought perhaps that the use of the various classes in http://srufaculty.sru.edu/david.dailey/cs427/StateOfArt-Dailey.html would help at least to be able to identify and find the various different types. There was pedagogical intent behind the choice of layout, so I figured that we'd probably want to remove tables at some time. My understanding is that tables of heterogeneous geometry (like with lots of rowspans and colspans) are sometimes not implementable in CSS unless you move to CSS3 and then cross browser problems kick in. I don't know. I do prefer the appearance at http://srufaculty.sru.edu/david.dailey/cs427/StateOfArt-Dailey.html if someone knows a way to make it look like that and validate. >I would also like to see SVG rather than rasters wherever possible. I tend to agree with Helder there. Too much SVG will crash IE. My much smaller paper at https://www.svgopen.org/2008/papers/39-The_Edges_of_Plausibility/ does indeed crash IE/ASV (3.03 and apparently 3.06) -- too many embeds or objects and IE just gives up. There are now probably fifty or so links to on-line SVG content already added since version 1. I'm linking from a separate link rather than from the graphic to make it clear when those examples exist and when they don't. >But perhaps more important than any of this is that we need to move this forward soon. Browsers are changing rapidly, and I think that if we don't publish soon, much of this will be stale. As it is, we will need to publish updates fairly quickly on its heels. Actually, an attempt has been made to modernize the content. Places that used to only discuss Opera, FF and IE now discuss Safari and Chrome (at least in many places). Agreed though, that more modernization is needed. I think the places where it is needed are fewer than it might seem though. >Maybe we should set up a telcon to discuss next steps, and we could each take a section to review? Yes, I think it makes a lot of sense to divide up sections. Fixing the table of contents first so people can get places, probably makes the most sense. I think a global replace of "StateOfArt-Dailey.html#" by "svgprimer.html#" ought to fix that. BTW, Shawn Roe's section on XSLT has arrived -- I recall Helder also shares an interest in that. Thanks again for your work Doug. It looks like Helder's most recent comments will have to go into draft three. Cheers David
Received on Tuesday, 26 May 2009 17:05:58 UTC