View Single Post
Old 03-05-2010, 12:08 AM   #354
Solitaire1
Samurai Lizard
Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.Solitaire1 ought to be getting tired of karma fortunes by now.
 
Solitaire1's Avatar
 
Posts: 14,238
Karma: 66666666
Join Date: Nov 2009
Device: NookColor
Quote:
Originally Posted by DawnFalcon View Post
Untrue. Badly untrue, and indeed I'd call this an urban legend.

In some cases, additional verbosity can lead to slower load times. However, there are many causes where the direct opposite is true - by being specific, you can eliminate areas where the software has to look up defaults, make assumptions based on other data and generally "decide what to do".

For example, handling inheritance in CSS is often extremely slow, since there are multiple, often conflicting rules which must be applied. While something like XPath is overkill, a better defined inheritance model - which would almost certainly be more verbose - would be considerably faster.

(Also, CSS is not code, it's script!)
The reason I mentioned verbosity is to avoid ambiguity and confusion. However, there are ways to reduce the amount of code needed while still avoiding confusion and ambiguity.

One way via the use of commonly established defaults. The only time coding is needed is if it isn't the default. As an example, the default is one blank line between each paragraph (the amount of space is determined by the font in use), but this can easily be changed from this starting point. But if the default is fine no coding is needed.

Another way that might work even better is to avoid formatting within the ebook itself. Instead, the parts of the ebook are tagged to indicate what they are (such as Main Body, Chapter Heading, Page Header, and Page Footer) without any indication how they are to be displayed. This is one of the ideas behind CSS (separating the formatting of the text from what the text is).

The way the text will be displayed is handled by the ebook reader itself via a set of display defaults (such setting the reader to display the Main Body in Times New Roman 12 point with a 36 point indent on the first line of each paragraph and no blank space after the paragraph). The advantage of this is that the same ebook can be used on various ereaders, and each reader can be set to display the text in a manner suitable for it. It also avoids the problem of some types of formatting (such as full justification, and certain fonts) not being available since it's an issue of the ereader, not the ebook format.
Solitaire1 is offline   Reply With Quote