Re: [css-regions] content/presentation separation, and regions as elements

Hey,


On Fri, Dec 20, 2013 at 4:58 AM, Cramer, Dave <Dave.Cramer@hbgusa.com>wrote:

> On 12/19/13 8:13 PM, "Alan Stearns" <stearns@adobe.com> wrote:
>
>
> >
> >So I wanted to note how you can use named flows to combine content and
> >presentation from entirely separate files. I believe Fantasai preferred
> >this approach. Combining files is a key feature of IE's current
> >implementation, and one reason we added the content keyword to the
> >specification.
>
> This may address some of our concerns, too. We work with HTML files that
> represent book chapters. Given that the same source may end up in ebooks
> as well as various print editions, we prefer to keep the source "clean"
> and use different CSS files for the different presentations. Having a
> separate HTML template with presentational information would allow us to
> continue with the single content source without resorting to external
> processing.
>

We also work with CSS Regions in one context and use the same text for
epubs in another.

I am a bit confused why this should mean one needs two different source
files. To get the output to render well in epub readers, one needs to
convert it to XHTML, put it in a special zip file, add anchor links to all
sub headlines one wants to mention in the TOC, etc. .

Or take footnotes -- in the epub one will want to have them as an aside,
while in the browser version one needs them to be something else (for
example elements placed to the side of the main text by using
display:relative combined with some javascript to ensure they don't overlap.

If one absolutely wants to have the epub version and the web version in the
same file without any changes, it would only be an extra container element.
If one isn't opposed to using Javascript, one wouldn't even have to have
the extra element, but could instead have the javascript create this
element if needed.


 Maybe it could be an option to load the contents of a named flow from
another file if this is something absolutely needed (again: javascript
could easily do this for you and even handle more complicated sources such
as a websocket call, etc. ), but I wouldn't make it obligatory as that
would seem like a restriction with little purpose (and the cause of a lot
more development time to get around this rather arbitrary restriction)

>
> >
> >
> >I also brought up the issue of flow-from applying to elements. One thread
> >of feedback we've recieved is that flow-from should only apply to
> >pseudo-elements (or other CSS-generated boxes). This has never made much
> >sense to me. As far as I know, content is the only property that is
> >currently restricted to pseudo-elements, and we're looking to extend its
> >use to elements. I believe Fantasai agreed with me that restricting a new
> >property to pseudo-elements would be a bad choice.
>
> Yep. Luckily PrinceXML ignores this restriction on the content property,
> and we find it really useful to entirely replace some elements. Our source
> HTML may contain "space breaks" [1] with three asterisks to indicate a
> change of scene in a novel. We may replace those asterisks with some
> font-based ornament or image in the printed version but not the ebook
> version. That's really easy using content on the element.
>
> Dave
>
> [1]
> http://w3c.github.io/dpub-pagination/index.html#space-breaks-and-ornaments
>
>
> This may contain confidential material. If you are not an intended
> recipient, please notify the sender, delete immediately, and understand
> that no disclosure or reliance on the information herein is permitted.
> Hachette Book Group may monitor email to and from our network.
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com