daviddurand
commented
11 years ago Lots of people are using these design properties, so any problems are likely to be browser cache or setup issues. You do have to have the advanced site property for the new reader enabled, of course.
It's also important to test any overrides on staging as it has browser caching turned off. The live site requires refreshing (and sometimes a cache flush) for many changes to propagate -- one reason the live layouts are considerably faster.
You should target any new reader deployment at the Reader Beta. It's already in production on several sites, and is where all reader new work is being directed. It will become the standard reader at some point this fall.
I don't know what you want to accomplish with page size, but the global page layout is determined by a lot of elements, CSS styles, and javascripts; bug fixes and adjustments have required structural changes in the past, even when attempting to support the same rendering. You can try to change this, but it will probably be painful, and we will attempt to ensure that bug fixes or feature improvements will not break changes this area.
If there's a bug or usability issue in the global layout or sizing please let us know so we can fix it -- one reason for the reader is that we saw that a standardized solution offered a better way to get user experience optimizations in place for all our customers. Within that goal of a standardized reading platform, we are gradually opening up the reader to more customization, but we can't have an evolving standard and maintain compatibility with arbitrary style changes that people might make to the presentation.
With all that said, here are some ....
Notes and tips on customizing reader CSS
We do not attempt to guarantee that layout-affecting CSS will not have to change, except for the options explicitly supported by documented design parameters or affecting contents of the header and help regions, at their current sizes. Classes with t- prefixes can be safely adjusted as to rendering (color, background, etc).
If you do try adjusting the page layout outside the header or the content of the help bar, you need to proceed with caution. You should not attempt to adjust the layout div.t-content element or any of it's contents. That part of the reader includes link overlays, will support annotations soon, and has been very tricky to get right.
We have switched to using design parameters to select site-markup variations. This has a lot of deployment advantages (ability to use staging to test new versions, etc.). There will be limit on the lifetime of old reader version support, so for sites whose CSS you will not want to revisit, it's best to avoid any risky customizations.
The t-reader id on the reader body tag makes override CSS much easier as rules starting with #t-reader gain CSS priority over rules that do not have it. We use this to make jquery overrides a (little) safer. The same capability is now supported in regular tizra pages with the id my. Tizra CSS will never use #my in system generated CSS, so you can use #my in CSS rules to implement overrides.
You may well have to change the CSS at some point, but it is possible to change the size of the header area, and to change the button icons in the toolbar. The JQuery mobile HTML classes and markup have changed a lot between versions, and are slated to change radically again in the next version (already in alpha). We strongly recommend leaving these as-is, or making minimal adjustments; if you do, expect that those stylesheets will have to change.
Trying to adjust the layout of the search buttons, etc. is likely to be a thankless task that is sure to recur in the future.
If you change z-index values anywhere on the page, you will likely break things, including particularly the fallback support for IE 7-9.
orangedrink
https://github.com/Tizra/Tizra-Customer-Tracker/wiki/Customizing-New-Reader
I'm looking at the wiki but adding the properties described there doesn't work. Is there anything I can do to set a height to the page when the new reader is being used?