extend-a-story-devel Mailing List for Extend-A-Story
Interactive and Extendable Story
Brought to you by:
jjweston
Menu
▾
▴
extend-a-story-devel — Extend-A-Story Development Discussion
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Jeff W. <jjw...@gm...> - 2011-10-01 05:39:06
|
The migration from Subversion to Git is complete. On Fri, Sep 30, 2011 at 9:30 PM, Jeff Weston <jjw...@gm...> wrote: > This is a quick announcement for anyone using Subversion to access the > Extend-A-Story source code. Shortly, I will be migrating from > Subversion to Git. If you wish to continue to access the > Extend-A-Story source code through the source code repository, you > will need to switch to Git when this migration is performed. I will > send another message when this migration is complete. -- Jeff Weston PGP public key available from http://pgp.mit.edu/ PGP Key ID: 0xC12DA028 |
|
From: Jeff W. <jjw...@gm...> - 2011-10-01 04:30:34
|
This is a quick announcement for anyone using Subversion to access the Extend-A-Story source code. Shortly, I will be migrating from Subversion to Git. If you wish to continue to access the Extend-A-Story source code through the source code repository, you will need to switch to Git when this migration is performed. I will send another message when this migration is complete. -- Jeff Weston PGP public key available from http://pgp.mit.edu/ PGP Key ID: 0xC12DA028 |
|
From: Jeff W. <jjw...@gm...> - 2008-08-26 06:01:02
|
The migration from CVS to Subversion is complete. While you will still be able to access the old CVS repository, you will need to use the Subversion repository in the future if you want the latest code. On Mon, Aug 25, 2008 at 7:06 PM, Jeff Weston <jjw...@gm...> wrote: > Just a quick announcement for anyone using CVS to access the > Extend-A-Story source code. Shortly, I will be migrating from CVS to > Subversion. If you wish to continue to access the Extend-A-Story > source code through the source code repository, you will need to > switch to Subversion when this migration is performed. I will send > another message when this migration is complete. -- Jeff Weston PGP public key available from http://pgp.mit.edu/ PGP Key ID: 0x14B456ED |
|
From: Jeff W. <jjw...@gm...> - 2008-08-26 02:06:29
|
Just a quick announcement for anyone using CVS to access the Extend-A-Story source code. Shortly, I will be migrating from CVS to Subversion. If you wish to continue to access the Extend-A-Story source code through the source code repository, you will need to switch to Subversion when this migration is performed. I will send another message when this migration is complete. -- Jeff Weston PGP public key available from http://pgp.mit.edu/ PGP Key ID: 0x14B456ED |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-24 15:10:59
|
On Wed, 23 Jul 2003, Jeff Weston (Sir Toby) wrote: > I'm still having my users beat on the new pages. I'll let them know that > the IE centering issue is now fixed so they'll take another look. I've just had a report that IE 5 is still not centering the table properly. IE 6 works fine. Do you have any thoughts on whether or not we can do anything for IE 5? -- Jeff Weston (Sir Toby) |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-24 06:23:52
|
On Wed, 23 Jul 2003, Matthew Fringe Duhan wrote:
> I believe that you will want to set the table class as below in order
> for it to be 500px wide and centered.
>
> { margin-left: auto; width: 500px; margin-right: auto; }
>
> See these examples for why this works:
> http://www.w3.org/Style/CSS/Test/CSS1/20020115/test412.htm
> http://zvon.org/xxl/CSS2Reference/Output/index.html
Okay... The funny thing about the problem is that my style declaration
looks just like what you used above. I did try your test page out in IE,
and when it worked, I went on a thorough search for what was different
between what they're doing, and what I'm doing. The problem? IE craps out
when I include the <?xml> tag bit at the top of the file. If I remove
that, IE renders the page correctly. The problem is that without the
<?xml> tag, the W3C Validator can't determine the encoding type. So, to
make the validator happy, I have added a <meta> tag that specifies the
encoding type, just like what they did with the test code. What a pain...
But, the pages now render fine in IE. I've committed these changes to CVS.
I'm still having my users beat on the new pages. I'll let them know that
the IE centering issue is now fixed so they'll take another look.
Any more thoughts on my use of the <div> tag to acheive centered text? Any
other suggestions for the new coding standard we're working towards?
I'll probably start looking at converting over the simple php scripts to
XHTML 1.1 soon. Things like the statistics page, or the search form should
be easy. Episode creation, reading episodes, and the admin page will
likely be a lot harder...
--
Jeff Weston (Sir Toby)
|
|
From: Matthew F. D. <fr...@fr...> - 2003-07-23 21:20:44
|
I believe that you will want to set the table class as below in order
for it to be 500px wide and centered.
{ margin-left: auto; width: 500px; margin-right: auto; }
See these examples for why this works:
http://www.w3.org/Style/CSS/Test/CSS1/20020115/test412.htm
http://zvon.org/xxl/CSS2Reference/Output/index.html
Sincerely,
Matt
On Wednesday, July 23, 2003, at 10:48 AM, Jeff Weston (Sir Toby) wrote:
> On Wed, 23 Jul 2003, Matthew Fringe Duhan wrote:
>
>> I've got to run to work, but at quick glance it looks like you did not
>> set the align: center property in the table classes in the CSS. I can
>> look at it more tonight. Thanks.
>>
>> Sincerely,
>> Matt
>
> Hmm... I tried adding "align: center" to the "centered" table class,
> but
> IE still renders the page the same. I ran the new stylesheet through
> the
> W3C CSS validator and it complained that the "align" property doesn't
> exist.
>
> --
> Jeff Weston (Sir Toby)
|
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-23 15:49:13
|
On Wed, 23 Jul 2003, Matthew Fringe Duhan wrote: > I've got to run to work, but at quick glance it looks like you did not > set the align: center property in the table classes in the CSS. I can > look at it more tonight. Thanks. > > Sincerely, > Matt Hmm... I tried adding "align: center" to the "centered" table class, but IE still renders the page the same. I ran the new stylesheet through the W3C CSS validator and it complained that the "align" property doesn't exist. -- Jeff Weston (Sir Toby) |
|
From: Matthew F. D. <fr...@fr...> - 2003-07-23 13:33:11
|
I've got to run to work, but at quick glance it looks like you did not set the align: center property in the table classes in the CSS. I can look at it more tonight. Thanks. Sincerely, Matt On Wednesday, July 23, 2003, at 02:30 AM, Jeff Weston (Sir Toby) wrote: > On Tue, 22 Jul 2003, Jeff Weston (Sir Toby) wrote: > >> I've completed my pass of making the documentation XHTML 1.1 >> compliant. >> I've made an external stylesheet for ease of use. I've also committed >> the >> whole mess into CVS. > > Well, I just tested the new documentation with IE (my regular browser > is > Mozilla), and it was crapping out on me. I guess IE needs the <html> > tag > to be immediately below the doctype declaration. I've made the > appropriate > change in CVS. I also just noticed that IE isn't centering my > "centered" > table like Mozilla is. Any idea why this is happening? It's getting > late, > and I need to get to bed. If you don't know what's up, I'll see if I > can > research this tomorrow. > > -- > Jeff Weston (Sir Toby) > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > extend-a-story-devel mailing list > ext...@li... > https://lists.sourceforge.net/lists/listinfo/extend-a-story-devel > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@ Matthew Duhan fr...@fr... http://www.fringenet.net When I want my opinions I'll ask me for them. WWW, HTML, VR, MOO, HRSFA, TMBG, TLA--any more initials and I'll go insane Roger, this is God. Pick up the pace. |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-23 07:30:58
|
On Tue, 22 Jul 2003, Jeff Weston (Sir Toby) wrote: > I've completed my pass of making the documentation XHTML 1.1 compliant. > I've made an external stylesheet for ease of use. I've also committed the > whole mess into CVS. Well, I just tested the new documentation with IE (my regular browser is Mozilla), and it was crapping out on me. I guess IE needs the <html> tag to be immediately below the doctype declaration. I've made the appropriate change in CVS. I also just noticed that IE isn't centering my "centered" table like Mozilla is. Any idea why this is happening? It's getting late, and I need to get to bed. If you don't know what's up, I'll see if I can research this tomorrow. -- Jeff Weston (Sir Toby) |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-23 06:10:08
|
I've completed my pass of making the documentation XHTML 1.1 compliant. I've made an external stylesheet for ease of use. I've also committed the whole mess into CVS. I will ask my users to take a look at the new documentation files to see if there are any older browsers still out there that I need to worry about. Let me know any issues you have with what I've done so far as well. I'd like to hammer out any basic issues with migrating to XHTML 1.1 before moving onto the PHP code. You can find the latest version of the files I'm working on here: http://www.sir-toby.com/extend-a-story/beta-story/ -- Jeff Weston (Sir Toby) |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-23 03:49:59
|
On Tue, 22 Jul 2003, Jeff Weston (Sir Toby) wrote: > On Tue, 22 Jul 2003, Matthew Fringe Duhan wrote: > > > I agree with this approach. As it is now, the files should pass a test > > for XHTML Transitional with the addition of the correct DTD: > > > > <?xml version="1.0" encoding="UTF-8"?> > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > > <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" > > > > > at the start of the document before the copyright notice. I tested this > > in the w3c validator and it passed. XHTML strict is, of course, more > > strict, and doesn't allow ANY presentation formatting in the code, such > > as color or align. For backwards compatibility I'd recommend sticking > > with XHTML 1.0 Transitional. If we want to be forward thinking and only > > focus on 5+ browsers then XHTML 1.1 Strict should be okay. What do you > > think? > > I've been focusing on the strict variant. I've added the DTD declaration > for XHTML 1.0 Strict to the document I'm working on to make sure it passes > the validator. Working toward the strict specification will allow us to be > better prepared for the future. I don't imagine I'm going to have too many > problems with people using older browsers. I've just updated the doctype for the page I'm working on to XHTML 1.1. XHTML 1.1 appears to be basically XHTML 1.0 Strict with a module framework, so the work I've already done to the file already passes the XHTML 1.1 validator. Again, here is the URL for the file I'm working on: http://www.sir-toby.com/extend-a-story/beta-story/docs/begin.html I've added a class to the table, and removed the width specification. Let me know what you think about my earlier discussion regarding the <div> tag. I'm perfectly happy to go with a generic "centered" class if you don't want the flexibility of setting the class of the tags inside the <div> tag. I think I'll start working on the documentation for creating episodes now. -- Jeff Weston (Sir Toby) |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-23 03:37:08
|
On Tue, 22 Jul 2003, Matthew Fringe Duhan wrote: > On Saturday, July 19, 2003, at 12:42 PM, Jeff Weston (Sir Toby) wrote: > > > I've taken a bit of time to investigate what it will take to make > > Extend-A-Story compliant with XHTML 1.0 Strict. I've started with the > > documentation files, since those are static and should allow us to > > convert over to the new standard without too much difficulty. Once we > > settle upon a good way to convert to the new standard in general, we > > can move on to converting the Extend-A-Story code. > > I agree with this approach. As it is now, the files should pass a test > for XHTML Transitional with the addition of the correct DTD: > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" > > > at the start of the document before the copyright notice. I tested this > in the w3c validator and it passed. XHTML strict is, of course, more > strict, and doesn't allow ANY presentation formatting in the code, such > as color or align. For backwards compatibility I'd recommend sticking > with XHTML 1.0 Transitional. If we want to be forward thinking and only > focus on 5+ browsers then XHTML 1.1 Strict should be okay. What do you > think? I've been focusing on the strict variant. I've added the DTD declaration for XHTML 1.0 Strict to the document I'm working on to make sure it passes the validator. Working toward the strict specification will allow us to be better prepared for the future. I don't imagine I'm going to have too many problems with people using older browsers. > > The first thing I've noticed about the HTML you've given me is that > > you are still using attributes that are not part of the XHTML 1.0 > > Strict standard. I have started over with the begin.html document from > > scratch, and have been testing it against the validator. You can look > > at my version here: > > > > http://www.sir-toby.com/extend-a-story/beta-story/docs/begin.html > > Oops, as I mentioned above, I was coding more for XHTML 1.0 > Transitional, and did that before I saw this part of the e-mail. :) > (That'll teach me to read). What you've got looks fine, though I > question the use of the div tag. It seems unnecessary. Why not instead > define a generic class: .centered {text-align: center} And then any > element can be a member of that class: <h1 class="centered" > >Extend-A-Story</h1> <h2 class="centered" >Instructions for Beginning > Players</h2> etc. Just different coding styles I guess. I tend to shy > away from div unless it's necessary as a functional or layered grouping. I did consider using a more general class for the <h1> and <h2> tags, but it occurred to me that you may want to have a class for those tags that is separate from the centered class, so you can have your own custom styles applied to them. Also, the use of the <div> tag in that fashion seemed like the best replacement for the <center> tag. > > I had to add a <style> section in order to get the same layout as the > > previous version. Take a look and let me know what you think. Again, > > my goal here is to allow us both to have our own formatting of the > > HTML by just adjusting an external style sheet. The <style> section I > > am using now will eventually be moved to a seperate file. Let me know > > if you think we need to add any additional classes or anything to give > > you the flexibility to style the document to your needs. > > I agree with making the styles external eventually. Other than the div > issue mentioned above, I think that it looks okay. I might recommend > making the table a class as well, in order to specify the width (and any > other presentation elements) in the CSS. Okay, I'll add a class for the width="500" table, and move the width specification to the style declaration. -- Jeff Weston (Sir Toby) |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-23 03:25:26
|
On Mon, 21 Jul 2003, Matthew Fringe Duhan wrote: > On Wednesday, July 16, 2003, at 12:57 AM, Jeff Weston (Sir Toby) wrote: > > > I understand your concern that the current approach is not the best > > way to go at it. In particular, if one wants to add a large number of > > tags, one would have to add a large amount of code to the decoding > > functions to handle it. It would be nice if we could make the tagging > > a data driven element, such that the allowed tags, and how they are > > decoded, is put in the database somehow. That way someone could easily > > add new tags to the database without having to touch the code. We > > could probably build an interface for it. Also, it would make it easy > > to have different tag schemes that an administrator, or users would be > > able to choose between. It sounds like your users want a BBCode like > > scheme, while I think my users are more familiar with an HTML tagging > > scheme. It would be nice to be able to support both without too much > > hassle. > > Hmm, now that's an idea that I hadn't considered. I was thinking along > the lines of additional php modules/includes, but I think that your > solution is more elegant. Would the admin have to add all case > possibilities like now? Also, what would we 'match' to? english terms > like bold, italic? HTML? Something else? Something to ponder. I think it would be nice if we could keep all the formatting tags in lower case, just to make things easy. We'll need to make Extend-A-Story smart so that it will handle formatting tags from users entered in any permutation of case. As far as what the tags will convert to... I sort of figured we'd go with a literal translation, similar to what is currently being done in code. To make things even more expandable, we might use regular expressions for tag detection, and some sort of substitution for converting the tag to real HTML (or whatever) code. We may even be able to work around the case issue with some clever regular expressions. > Sorry it took so long to reply. Work has gotten busier lately, but > should calm down again later this week. No worries. Work has been crazy for me as well. Kinda gotta worry about putting food on the table before working on hobbies. ;-) -- Jeff Weston (Sir Toby) |
|
From: Matthew F. D. <fr...@fr...> - 2003-07-22 06:42:17
|
On Saturday, July 19, 2003, at 12:42 PM, Jeff Weston (Sir Toby) wrote: > I've taken a bit of time to investigate what it will take to make > Extend-A-Story compliant with XHTML 1.0 Strict. I've started with the > documentation files, since those are static and should allow us to > convert > over to the new standard without too much difficulty. Once we settle > upon > a good way to convert to the new standard in general, we can move on to > converting the Extend-A-Story code. I agree with this approach. As it is now, the files should pass a test for XHTML Transitional with the addition of the correct DTD: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" > at the start of the document before the copyright notice. I tested this in the w3c validator and it passed. XHTML strict is, of course, more strict, and doesn't allow ANY presentation formatting in the code, such as color or align. For backwards compatibility I'd recommend sticking with XHTML 1.0 Transitional. If we want to be forward thinking and only focus on 5+ browsers then XHTML 1.1 Strict should be okay. What do you think? > > I've found a validator that I've been using to ensure the HTML is valid > for the new standard. Here is a URL: > > http://validator.w3.org/ Yes, the W3C also offers a program called Tidy which can validate. It acts as a standalone or as a plug-in to many editors. > > The first thing I've noticed about the HTML you've given me is that you > are still using attributes that are not part of the XHTML 1.0 Strict > standard. I have started over with the begin.html document from > scratch, > and have been testing it against the validator. You can look at my > version > here: > > http://www.sir-toby.com/extend-a-story/beta-story/docs/begin.html Oops, as I mentioned above, I was coding more for XHTML 1.0 Transitional, and did that before I saw this part of the e-mail. :) (That'll teach me to read). What you've got looks fine, though I question the use of the div tag. It seems unnecessary. Why not instead define a generic class: .centered {text-align: center} And then any element can be a member of that class: <h1 class="centered" >Extend-A-Story</h1> <h2 class="centered" >Instructions for Beginning Players</h2> etc. Just different coding styles I guess. I tend to shy away from div unless it's necessary as a functional or layered grouping. > > I had to add a <style> section in order to get the same layout as the > previous version. Take a look and let me know what you think. Again, my > goal here is to allow us both to have our own formatting of the HTML by > just adjusting an external style sheet. The <style> section I am using > now > will eventually be moved to a seperate file. Let me know if you think > we > need to add any additional classes or anything to give you the > flexibility > to style the document to your needs. I agree with making the styles external eventually. Other than the div issue mentioned above, I think that it looks okay. I might recommend making the table a class as well, in order to specify the width (and any other presentation elements) in the CSS. Sincerely, Matt |
|
From: Matthew F. D. <fr...@fr...> - 2003-07-22 03:37:04
|
On Wednesday, July 16, 2003, at 12:57 AM, Jeff Weston (Sir Toby) wrote: > On Tue, 15 Jul 2003, Matthew Duhan wrote: > >> That was me. In making the changes to Extend-A-Story to support Style >> Sheets and potentially support additional tags, I wanted to make it as >> HTML4/XHTML compliant as possible, according to the W3C specs. While >> case does not matter for HTML, it does for XML (and some translators >> of >> XHTML), so I decided to go with a more standard lowercase format for >> the >> XHTML code. I also removed some of your formatting that used >> depreciated >> tags, such as the CENTER tag. > > I see... I was not aware of the specification. I might have a few > choice > words for the W3C consortium, but this isn't your fault. I'll have to > think about what I want to do about this. I do agree that deprecated > tags > such as the CENTER tag should probably be removed. However, I am > concerned > that some of my users may be using older browsers and will not > understand > the new HTML specification we will be using. If this turns out to be an > issue, I'd like to find some way to provide support for older browsers. Well, coding in the old style shouldn't affect things. All Web browsers *should* understand both upper and lowercase tags, though older browsers may not understand newer tags like CSS. > > Have I mentioned I hate HTML coding? :) You'd think its funny for a web > developer to hate HTML coding, but here we are. I just can't stop > thinking > about how something so useful can be made so annoying. Anyways, I > digress. > These issues are not your fault. :P I think that the advent of XHTML is actually a good thing, and will help make what is a very loose language have a bit more structure to it. > >> I guess that didn't occur to me, as the editor that I use (BBEdit) >> automatically color codes and differentiates between code, string, and >> plain text. As I said above, I'd prefer to keep within the W3C specs. >> If you feel strongly about it, I'm not opposed to using uppercase HTML >> tags, but I would at least prefer to use lowercase attributes >> (align="center" vs ALIGN="CENTER"). > > Well, my editor (TextPad) does syntax highlighting as you describe. > I've > just gotten used to the case difference in addition to the > highlighting to > help differentiate between the various bits of code. Originally, > Extend-A-Story was built using the pico editor on Linux. That editor of > course has no syntax highlighting, so the case difference made it > incredibly easier to see what was going on. I just kept the same > standard > when I moved to more powerful editors. You say pico, I say vi. Can't we all just get along? > > Incidentally, I also prefer uppercase attribute names, but I see that > those are also required to be lower case by the new standard. *sigh* > >> I believe that my changes shouldn't break this functionality the way >> I've coded it. Unless I sent you the wrong version, looking at my >> version of general.php, line 640 is where >> getEpisodeBodyTranslationTable( ) begins. On the left side of the >> replacement array (lines 642-661) I have kept the various upper- and >> lowercase permutations. On the right side, where the replacement is >> returned, I am returning only lowercase HTML code. This lowercase code >> is what will be translated by the browser. When I tested this, it >> worked >> as expected, with authors being able to use both upper-and lowercase >> tags. > > You are quite correct. I was in a hurry and read the code too fast, > thus > getting it backwards. Your version should work fine. > >> This by the way brings up an interesting point, and one which we >> should >> probably try to hash out. The way EAS is coded now, it leaves authors' >> input untouched, and does the translation on display only. This can >> become a hindrance if we want to add support for more tags, as we will >> have to check for every permutation of every tag. This is partly why I >> see using a BBCode derivative easier. I think that it would add a >> little >> more load on input, but less load on output, if we were to check for >> the >> presence of tags first, and automatically toLower them before >> inserting >> into the db. This way, the getEpisodeBodyTranslationTable function >> only >> has to search for the lowercase version. Or better yet, why not >> translate on input, so that the complete tags go into the db for those >> tags we deem 'valid,' and others would remain < and >. What are >> your thoughts on this? > > In the version 1 releases of Extend-A-Story, things were quite a bit > different. The HTML entities (<, >, &, ") were all escaped out to their > HTML escape sequences when written to the database. When displaying an > episode, the allowed HTML sequences were scanned for and then converted > back to HTML. > > When I built version 2, I moved away from that approach. I didn't like > how > the data in the database was so HTML-centric. If I decided to display > an > episode using some other format, you would need to go to a lot of > effort > to remove the HTML specific coding and put some other coding in place. > As > it stands right now, the data the user enters in is stored directly in > the > database as entered. When displaying the episode (in this case, to a > browser rendering HTML) the conversion of special character to HTML > entities, and the conversion of formatting codes to HTML is done at > that > time. Ah, ok, that makes sense then as to why you process on output rather than input. I still think it may be easier to at least convert to lowercase on input. I'll have to think about that a bit. > > Now don't get hung up on the fact that the tags I'm using for > formatting > episodes are the same as the HTML tags with the same purpose. This was > done because I knew my target audience knew HTML already, and so that I > didn't have to invent some new way of doing the tagging. I could have > easily used [P], (bold=ON), *hr*, or whatever mechanism I could come up > with. The tags would still get processed the same way. Gotcha, and could also allow expandability into other formats easily. > > I understand your concern that the current approach is not the best > way to > go at it. In particular, if one wants to add a large number of tags, > one > would have to add a large amount of code to the decoding functions to > handle it. It would be nice if we could make the tagging a data driven > element, such that the allowed tags, and how they are decoded, is put > in > the database somehow. That way someone could easily add new tags to the > database without having to touch the code. We could probably build an > interface for it. Also, it would make it easy to have different tag > schemes that an administrator, or users would be able to choose > between. > It sounds like your users want a BBCode like scheme, while I think my > users are more familiar with an HTML tagging scheme. It would be nice > to > be able to support both without too much hassle. Hmm, now that's an idea that I hadn't considered. I was thinking along the lines of additional php modules/includes, but I think that your solution is more elegant. Would the admin have to add all case possibilities like now? Also, what would we 'match' to? english terms like bold, italic? HTML? Something else? Something to ponder. > > You bring up another good point about the uppercase/lowercase issue > with > formatting tags. We certainly don't want to be checking for every > possible > permutation of a tag. If we force all the tags to be of a certain case > (say, lower case for now), we can do a toLower on the episode text, > locate > the tags, and convert the tags in the original episode to lower case. > Then > searching for the tags when displaying an episode becomes much simpler. Right > >>> In particular, the change of HTML coding style of the files in the >>> doc >>> directory has changed the files so much that they are nearly >>> unrecognizable. >> >> My apologies for that. After I had gotten your initial e-mail, it >> sounded like the work that I would be doing might not be integrated >> into >> the main branch, so I edited HTML as well as code. > > I think the main thing that bothered me about the documentation HTML > was > that my version was word wrapped at something like 78 characters, while > yours had no word wrap at all. Yeah, I removed word wrap. Just a bad habit of mine, since line breaks can translate into spaces, and they're unnecessary with programs that have built-in word wrap. It's an easy fix though. > >> I can try to separate out some of the HTML formatting changes and >> document it or send you another tgz. To be honest, though, most places >> (other than the docs) where I made changes to the HTML formatting I >> also >> made other changes to the HTML, such as adding the warning or error >> class, or removing depreciated tags such as CENTER. You may have >> noticed >> I also attempted to separate content from presentation where possible, >> creating a set of inclusion files (named "inc-") for repeated bits of >> formatting. > > Yeah, I did see your additional changes. I like abstracting out common > bits of logic (such as the Story Home and Site Home navigation logic) > into > a common file that can be used elsewhere. > >> I really feel that the benefits of standardizing on the current W3C >> recommendations for XHTML (http://www.w3c.org/TR/xhtml1/#guidelines) >> will outweigh the short term difficulty of integrating these changes >> into EAS. Some features that I can foresee adding would be more easily >> implemented if we adhere as much as possible to XML/XHTML specs. > > Yes, I'm sure you're right. If I seem grumpy about it, its because I'm > grumpy at the specification. I really see no reason why they couldn't > allow for both upper case and lower case tags to be used. Sure, they > are > different XML elements, but the elements could be defined to mean the > same > thing. There's nothing in XML that would prevent this. I don't know if > a > similar trick can be used for the attributes though... > > Again, I digress. We have the standard, and I don't like it. I guess > I'll > have to live with it. Although... I could in theory write the HTML > however > I darn well please and then use an XSLT transform to turn it into > proper > HTML. But, that's too much work. Again, as I said earlier, I hate HTML > coding. :) Heh. And actually, I think the spec states that XHTML is read by the browsers in uppercase, even though it's written in lowercase. The joys of standards. > >> I agree. We just need to decide the standard. :) I understand your >> desire to use uppercase HTML for easier readability in the code view. >> If you feel strongly about it then I am willing to work that way, and >> I >> feel confident that I can fairly quickly change the 2.2.0 code back to >> uppercase if need be. As I mentioned above, though, I think in the >> long >> run it will benefit us to try to use current W3C specs. > > I think I'll agree to try to keep it within the W3C specs. I'll find > some > way to not complain too loudly about it. :D > >>> Just so you know, here are the features I'm thinking of starting work >>> on: Showcase Random Episodes, and Sort Search Results by >>> Chronological >>> Order. >> >> Sounds good. I would also like to add additional tag support, but I >> can >> hold off on that until we hash things out. > > Sounds like a good plan. I've actually not done any work in > anticipation > of incorporating your changes. I agree with your suggestion of holding > off > on further changes until we hammer out these first round of changes. > >> I agree. With any collaboration such as this there are bound to be >> initial hurdles to work through. This is especially the case because I >> began modifying something which was initially a one person project, >> using my own coding practices. I'm sure that we'll be able to hash it >> out. > > Yeah, its always hard to open up something you've worked on by > yourself. > But, I think the benefits of collaboration far outweigh the hassles of > getting these issues ironed out. > >> If you ever want to chat about it online, I'm on AIM under [snip], or >> we >> can continue using e-mail. > > I do use online IM clients on occasion, but I don't have any installed > right now. However, considering the length of our emails, and the > highly > technical nature of our discussions, I think email will be the > preferred > discussion medium. However, I would like to suggest continuing the > discussion on the devel mailing list. I see that you've subscribed, so > I'm > sending this response to the list itself. Got it. > > I don't know how familiar you are with the SourceForge lists, but just > as > a general warning, they don't set the "reply to" header to actually > point > back to the list. If you want to reply to a posting and have it go > back to > the list, you have to use "reply to all" to do it. Thanks for the warning. > > > Here's how I'd like to move forward: > > Let's stick with the W3C standard. I'll take a closer look at the files > you've submitted and see just what the changes are. This will take me > some > time, and I can't really guarantee I'll have lots of time to look at > your > changes in great detail until the weekend. I'm sure I'll have questions > about what you've done, so we'll likely have additional discussions > about > them. In general, my goal for integrating your changes is to keep the > user > experience for the users on my site identical to the current user > experience while still maintaining the features you want in the code > base. > Ideally, I should be able to have my look and feel, and you should be > able > to have your look and feel while using an identical code base, with > only a > different style sheet. Agreed. That's partly why I wanted to abstract out common elements also. A change in one place affects all instances. Same for CSS. > > We should hold off on working on any new features until we get the > above > changes ironed out. However, it sounds like the enhanced tagging > capability is an important feature to you. That will likely be a > complicated enough change that we should start talking about how we > want > to improve upon the current system. > > Once we've handled the coding style changes, I'll evaluate additional > patches from you, and when I'm comfortable with giving you direct > access > to the CVS repository, I'll add you as a developer. I'll try to do this > quickly, since I understand that the anonymous pserver access is quite > lousy right now. > > > Whew! This email is a mouthful, but I think we're getting on the right > track. Hopefully you feel the same way. Let me know your impressions as > well. Please be sure to respond to the mailing list so that we can > keep an > archive of our discussions. Sorry it took so long to reply. Work has gotten busier lately, but should calm down again later this week. Sincerely, Matt > > -- > Jeff Weston (Sir Toby) > |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-19 17:43:06
|
I've taken a bit of time to investigate what it will take to make Extend-A-Story compliant with XHTML 1.0 Strict. I've started with the documentation files, since those are static and should allow us to convert over to the new standard without too much difficulty. Once we settle upon a good way to convert to the new standard in general, we can move on to converting the Extend-A-Story code. I've found a validator that I've been using to ensure the HTML is valid for the new standard. Here is a URL: http://validator.w3.org/ The first thing I've noticed about the HTML you've given me is that you are still using attributes that are not part of the XHTML 1.0 Strict standard. I have started over with the begin.html document from scratch, and have been testing it against the validator. You can look at my version here: http://www.sir-toby.com/extend-a-story/beta-story/docs/begin.html I had to add a <style> section in order to get the same layout as the previous version. Take a look and let me know what you think. Again, my goal here is to allow us both to have our own formatting of the HTML by just adjusting an external style sheet. The <style> section I am using now will eventually be moved to a seperate file. Let me know if you think we need to add any additional classes or anything to give you the flexibility to style the document to your needs. -- Jeff Weston (Sir Toby) |
|
From: Jeff W. (S. Toby) <jjw...@ke...> - 2003-07-16 05:58:05
|
On Tue, 15 Jul 2003, Matthew Duhan wrote: > That was me. In making the changes to Extend-A-Story to support Style > Sheets and potentially support additional tags, I wanted to make it as > HTML4/XHTML compliant as possible, according to the W3C specs. While > case does not matter for HTML, it does for XML (and some translators of > XHTML), so I decided to go with a more standard lowercase format for the > XHTML code. I also removed some of your formatting that used depreciated > tags, such as the CENTER tag. I see... I was not aware of the specification. I might have a few choice words for the W3C consortium, but this isn't your fault. I'll have to think about what I want to do about this. I do agree that deprecated tags such as the CENTER tag should probably be removed. However, I am concerned that some of my users may be using older browsers and will not understand the new HTML specification we will be using. If this turns out to be an issue, I'd like to find some way to provide support for older browsers. Have I mentioned I hate HTML coding? :) You'd think its funny for a web developer to hate HTML coding, but here we are. I just can't stop thinking about how something so useful can be made so annoying. Anyways, I digress. These issues are not your fault. > I guess that didn't occur to me, as the editor that I use (BBEdit) > automatically color codes and differentiates between code, string, and > plain text. As I said above, I'd prefer to keep within the W3C specs. > If you feel strongly about it, I'm not opposed to using uppercase HTML > tags, but I would at least prefer to use lowercase attributes > (align="center" vs ALIGN="CENTER"). Well, my editor (TextPad) does syntax highlighting as you describe. I've just gotten used to the case difference in addition to the highlighting to help differentiate between the various bits of code. Originally, Extend-A-Story was built using the pico editor on Linux. That editor of course has no syntax highlighting, so the case difference made it incredibly easier to see what was going on. I just kept the same standard when I moved to more powerful editors. Incidentally, I also prefer uppercase attribute names, but I see that those are also required to be lower case by the new standard. *sigh* > I believe that my changes shouldn't break this functionality the way > I've coded it. Unless I sent you the wrong version, looking at my > version of general.php, line 640 is where > getEpisodeBodyTranslationTable( ) begins. On the left side of the > replacement array (lines 642-661) I have kept the various upper- and > lowercase permutations. On the right side, where the replacement is > returned, I am returning only lowercase HTML code. This lowercase code > is what will be translated by the browser. When I tested this, it worked > as expected, with authors being able to use both upper-and lowercase > tags. You are quite correct. I was in a hurry and read the code too fast, thus getting it backwards. Your version should work fine. > This by the way brings up an interesting point, and one which we should > probably try to hash out. The way EAS is coded now, it leaves authors' > input untouched, and does the translation on display only. This can > become a hindrance if we want to add support for more tags, as we will > have to check for every permutation of every tag. This is partly why I > see using a BBCode derivative easier. I think that it would add a little > more load on input, but less load on output, if we were to check for the > presence of tags first, and automatically toLower them before inserting > into the db. This way, the getEpisodeBodyTranslationTable function only > has to search for the lowercase version. Or better yet, why not > translate on input, so that the complete tags go into the db for those > tags we deem 'valid,' and others would remain < and >. What are > your thoughts on this? In the version 1 releases of Extend-A-Story, things were quite a bit different. The HTML entities (<, >, &, ") were all escaped out to their HTML escape sequences when written to the database. When displaying an episode, the allowed HTML sequences were scanned for and then converted back to HTML. When I built version 2, I moved away from that approach. I didn't like how the data in the database was so HTML-centric. If I decided to display an episode using some other format, you would need to go to a lot of effort to remove the HTML specific coding and put some other coding in place. As it stands right now, the data the user enters in is stored directly in the database as entered. When displaying the episode (in this case, to a browser rendering HTML) the conversion of special character to HTML entities, and the conversion of formatting codes to HTML is done at that time. Now don't get hung up on the fact that the tags I'm using for formatting episodes are the same as the HTML tags with the same purpose. This was done because I knew my target audience knew HTML already, and so that I didn't have to invent some new way of doing the tagging. I could have easily used [P], (bold=ON), *hr*, or whatever mechanism I could come up with. The tags would still get processed the same way. I understand your concern that the current approach is not the best way to go at it. In particular, if one wants to add a large number of tags, one would have to add a large amount of code to the decoding functions to handle it. It would be nice if we could make the tagging a data driven element, such that the allowed tags, and how they are decoded, is put in the database somehow. That way someone could easily add new tags to the database without having to touch the code. We could probably build an interface for it. Also, it would make it easy to have different tag schemes that an administrator, or users would be able to choose between. It sounds like your users want a BBCode like scheme, while I think my users are more familiar with an HTML tagging scheme. It would be nice to be able to support both without too much hassle. You bring up another good point about the uppercase/lowercase issue with formatting tags. We certainly don't want to be checking for every possible permutation of a tag. If we force all the tags to be of a certain case (say, lower case for now), we can do a toLower on the episode text, locate the tags, and convert the tags in the original episode to lower case. Then searching for the tags when displaying an episode becomes much simpler. > > In particular, the change of HTML coding style of the files in the doc > > directory has changed the files so much that they are nearly > > unrecognizable. > > My apologies for that. After I had gotten your initial e-mail, it > sounded like the work that I would be doing might not be integrated into > the main branch, so I edited HTML as well as code. I think the main thing that bothered me about the documentation HTML was that my version was word wrapped at something like 78 characters, while yours had no word wrap at all. > I can try to separate out some of the HTML formatting changes and > document it or send you another tgz. To be honest, though, most places > (other than the docs) where I made changes to the HTML formatting I also > made other changes to the HTML, such as adding the warning or error > class, or removing depreciated tags such as CENTER. You may have noticed > I also attempted to separate content from presentation where possible, > creating a set of inclusion files (named "inc-") for repeated bits of > formatting. Yeah, I did see your additional changes. I like abstracting out common bits of logic (such as the Story Home and Site Home navigation logic) into a common file that can be used elsewhere. > I really feel that the benefits of standardizing on the current W3C > recommendations for XHTML (http://www.w3c.org/TR/xhtml1/#guidelines) > will outweigh the short term difficulty of integrating these changes > into EAS. Some features that I can foresee adding would be more easily > implemented if we adhere as much as possible to XML/XHTML specs. Yes, I'm sure you're right. If I seem grumpy about it, its because I'm grumpy at the specification. I really see no reason why they couldn't allow for both upper case and lower case tags to be used. Sure, they are different XML elements, but the elements could be defined to mean the same thing. There's nothing in XML that would prevent this. I don't know if a similar trick can be used for the attributes though... Again, I digress. We have the standard, and I don't like it. I guess I'll have to live with it. Although... I could in theory write the HTML however I darn well please and then use an XSLT transform to turn it into proper HTML. But, that's too much work. Again, as I said earlier, I hate HTML coding. :) > I agree. We just need to decide the standard. :) I understand your > desire to use uppercase HTML for easier readability in the code view. > If you feel strongly about it then I am willing to work that way, and I > feel confident that I can fairly quickly change the 2.2.0 code back to > uppercase if need be. As I mentioned above, though, I think in the long > run it will benefit us to try to use current W3C specs. I think I'll agree to try to keep it within the W3C specs. I'll find some way to not complain too loudly about it. > > Just so you know, here are the features I'm thinking of starting work > > on: Showcase Random Episodes, and Sort Search Results by Chronological > > Order. > > Sounds good. I would also like to add additional tag support, but I can > hold off on that until we hash things out. Sounds like a good plan. I've actually not done any work in anticipation of incorporating your changes. I agree with your suggestion of holding off on further changes until we hammer out these first round of changes. > I agree. With any collaboration such as this there are bound to be > initial hurdles to work through. This is especially the case because I > began modifying something which was initially a one person project, > using my own coding practices. I'm sure that we'll be able to hash it > out. Yeah, its always hard to open up something you've worked on by yourself. But, I think the benefits of collaboration far outweigh the hassles of getting these issues ironed out. > If you ever want to chat about it online, I'm on AIM under [snip], or we > can continue using e-mail. I do use online IM clients on occasion, but I don't have any installed right now. However, considering the length of our emails, and the highly technical nature of our discussions, I think email will be the preferred discussion medium. However, I would like to suggest continuing the discussion on the devel mailing list. I see that you've subscribed, so I'm sending this response to the list itself. I don't know how familiar you are with the SourceForge lists, but just as a general warning, they don't set the "reply to" header to actually point back to the list. If you want to reply to a posting and have it go back to the list, you have to use "reply to all" to do it. Here's how I'd like to move forward: Let's stick with the W3C standard. I'll take a closer look at the files you've submitted and see just what the changes are. This will take me some time, and I can't really guarantee I'll have lots of time to look at your changes in great detail until the weekend. I'm sure I'll have questions about what you've done, so we'll likely have additional discussions about them. In general, my goal for integrating your changes is to keep the user experience for the users on my site identical to the current user experience while still maintaining the features you want in the code base. Ideally, I should be able to have my look and feel, and you should be able to have your look and feel while using an identical code base, with only a different style sheet. We should hold off on working on any new features until we get the above changes ironed out. However, it sounds like the enhanced tagging capability is an important feature to you. That will likely be a complicated enough change that we should start talking about how we want to improve upon the current system. Once we've handled the coding style changes, I'll evaluate additional patches from you, and when I'm comfortable with giving you direct access to the CVS repository, I'll add you as a developer. I'll try to do this quickly, since I understand that the anonymous pserver access is quite lousy right now. Whew! This email is a mouthful, but I think we're getting on the right track. Hopefully you feel the same way. Let me know your impressions as well. Please be sure to respond to the mailing list so that we can keep an archive of our discussions. -- Jeff Weston (Sir Toby) |
