Quote:
Originally Posted by kovidgoyal
However, you still have to read and parse the entire tag tree. Whether you do it in a streamed fashion or not. The reason you have to read and parse the entire tree is to support CSS selectors. I suggest you read the following to understand just why it is neccessary http://www.w3.org/TR/CSS2/selector.h...dant-selectors |
Well i know CSS 2.1 and descendant selectors very well and i know that the W3C recommends parsing the whole element tree. But can we agree on that technically "only" knowledge about the parent tree of elements is required to support those selectors? There is no knowledge about the subsequent parts of the xml tree required.
Quote:
Originally Posted by kovidgoyal
It's certainly true that you don't have to store all the text content in memory and that means the size limit of 300KB can probably be increased. But frankly, the increased programming complexity and consequent rendering fragility is not worth it. I think 300KB is a perfectly reasonable limit. EPUB creators simply have to keep it in mind.
|
It's a restriction which is not necessary imo. Maybe the next ePub renderer will require 200Kb as limit and another one chooses 180Kb and so on. ePub creators shouldn't have to deal with restrictions which are not part of the ePub specification.
Quote:
Originally Posted by kovidgoyal
As for pre-parsing and storing rendered versions of the file, I think that is an extremely inelegant solution and imposes an absolute restriction on allowing display modification by the user. Say good bye to allowing free font resizing, line space and margin adjustments.
|
Agreed, storing rendered versions of a file would be the wrong way.