|
I'm fully aware of CSS selectors thank you :-) I've been involved with web browsers - at the software level - for just shy of 15 years now. There's no reason why you can't stream through an XML document and flatten the selector space as you index it - and as the range of styles in a document is rarely that extensive the penalty for doing so is minimal.
Rendering fragility is a poor excuse - navigating the parse tree is a task that can be modularised and act as both a driver and restorer of index and style information. It's really not that difficult once you've got the framework in place. Any codebase that assumes or imposes an arbitrary size restriction on parsing a dataset that itself is unrestricted and shared with unknown third party software is bound to fail, however generous those restrictions may appear to be.
Inelegant solutions are necessary where you are trying to provide the ideal user experience. Agreed that completely free font sizing, line spacing and margin adjustments present an insurmountable task. However, it's worth noticing that most devices don't offer unlimited options, and most users will only ever select a small subset of those. Indexing (not storing rendered versions - ugh!) need only be performed on the most recent and most preferred choices. It's only when the user is determined to cycle through every option whilst reading the last page in a document that the interface need degrade to worst case re-parsing. Notice that even then, the experience is no worse than current 'all in memory' solutions. With indexing for rendering being a multi-level process, even that worst case can be hurried along by removing the need for dealing with overly complex parse trees.
|