jeroen said:
Please inspect one of my most recent submissions
ok. :+)
in German, so the text won't distract),
since much of a structural approach involves a grasp of the underlying _meaning_, text never "distracts"... i'll let jim give a detailed analysis of how well the file acts when ported to .epub or .mobi, but i can give you a few thoughts on my opinions of it, since you asked... first, though, you can do a good test yourself, just by: 1. ripping out the stylesheet, and examining the text; 2. setting width on the body to something like 500px. if your markup still works under those circumstances, the odds are much higher it'll work in reader-machines. won't tell you everything, but it will tell you quite a bit. *** now on to my reactions... although i can't be positive, because of the german, it seems to me that this markup is quite acceptable. (aside from troubles specific machines might have.) i'm not sure if the tables will work with a small width, so that'd be something to check, and fix if necessary. pagenumbers always present a problem, because they get mixed in to the text. the best solution for that is to make them easily visible to a reg-ex, for removal... in this particular book, the square-brackets work fine, because you don't have any other occurrences of them, but that won't always be the case, so i'd recommend that you add an additional component, such as [#69]. or -- if a number-sign seems too intrusive to you -- you could use nbsp around the bracketed pagenumber. your "inhalt" links jump to the actual place in the t.o.c. that match the jump-point, which is something i have often thought about doing, but usually decided against, relying instead on a jump to the top of the t.o.c. page. in working with your file, i think my instinct was right. when i jump back to a table of contents, i don't wanna see the contents _from_that_point_down_, i want it all. or at least i want the contents _around_ the jump-point. (if browsers didn't put the target-point at the _very_top_ of the window, but instead showed some context-lines, which is something that i've always argued they should, i might prefer your method. but as it is, i prefer mine.) the most solid recommendation i would have, though, is for you to re-think your policy on creating link id's... right now, they are some weirdish alphanumeric string, which might have some rhyme or reason to it, i didn't bother to try to figure it out, but it's still far too cryptic. i generally use the text of the jump-point itself, so that people who are looking at the text can _guess_ the link and almost always be correct, with a very high certainty. it's often the case that we think of the id element as an internal reference that only the computer needs to know, but it actually serves to create a deep-link into the text, so it has to be human-readable and even "make sense". anyway, that's my feedback, based on a quick once-over. -bowerbird