I've moved your question to the InDesign EPUB forum.
Are you exporting as EPUB 2 or EPUB 3? Reflowable or Fixed Layout?
Reflowable. Both ePUB 2 and ePUB 3 have the problem.
It now uses ids. What are you trying to do? If it's just a few objects, you can change the ids to classes.
InDesign still does the classes. Look on the very top of your CSS. Usaully, there should be div.object-style (with border-style:solid;) or img.object-style.
Unfortunately the markup has become very messy since CC 2014 with all these unnecessary id's and auto generated classes. This is mainly the result of the fxl ePub team which uses and modified the engine as used before for reflowable epub (in place of adding a second engine, leaving reflowable ePub making its own code structure). For fxl ePub this is actually ok as it works. For reflowable, this kind of DOM and markup is just arbitrary tinkering.
That's not the same thing, unfortunately.
ID CC inserted [ class="whatever-object-style-name-was" ] into the image tag. (I'm talking about the HTML, not the CSS.)
ID CC 2014 does not. It includes no class in the image tag.
CC 2014 *does* generate a whole lot of IDs that I don't need. Wish it didn't.
I don't use InDesign to emit CSS; we use a custom style sheet. I devised a workflow using various object styles applied to graphics frames in order to apply classes to my images in the ePUB export. Unfortunately, ID CC breaks that workflow.
It's not just a few objects, unfortunately.
I don't want CSS applied on an object-by-object basis; I want it applied to a *class* of objects. That makes it easier to change simply by changing a few lines in the CSS.
We use our own standard CSS style sheet. We don't let InDesign emit CSS. Thus the IDs it auto-generates are not helpful.
Our workflow was based on assigning Object Styles to graphics frames, then having the class applied to the exported image tag. Unfortunately, the change in InDesign's export behavior in CC 2014 breaks that workflow.
Yeah well, I know this problem too. Adobe always changed parts of the code structure from version to version. This time the classes of the containers have been on the road map.
In this case there is no real solution, so you need to stick again on rule #1 if you deal with automation processes: Never change a running system.
I see. Yeah, then your best bet would be to downgrade... if that's even possible.
I'm also looking forward to a cleaner CSS code on later releases.
I am no longer on the team, but I wanted to step in and clarify what is happening here as this was an intentional change on our part.
An InDesign graphic/image is really two objects - the container (Object) and the child content (Graphic) and we have been struggling over the last two years to improve the consistency/clarity of our mapping of these InDesign concepts to HTML. In InDesign the ObjectStyle is applied to the Object/Container NOT the Image/Graphic child.
Rasterizing the Container does not destroy it - it still exists in our terms. This is important for things like interactivity which would like to target the original Object and would not like it to disappear.
There are obviously several ways for us to have done this but we elected to maintain the <div> which is associated with the Object no matter what happens to the Content.
So the class from the Object Style is still applied to the <div> mapped to the Container even though it was rasterized - it has stayed constant. So the tag does not change if the Container is rasterized or not.
The other thing we did in this update was to remove the generated classes which were used to hold properties which are not expressed by the Object Style - namely width and height. These used to be _idGenPageItem-# and puzzled a lot of people.
Since we decided to use IDs to support interactivity, it made sense to generate the CSS for the width/height based on the IDs and not special classes. This reduced the complexity of the HTML and my longer term direction was to try to use even more IDs rather than generated numbered classes.
Lastly, with regard to Kaz's hope for "cleaner CSS". Yea. Do not assume that the team believes or knows what you know with respect to markup and CSS. If you have specific places where you think the HTML/CSS could be improved - point them out with examples and suggest what you think the alternative should be. Better yet, submit a bug or find a team member and tell them. Otherwise expect it to be lost in the shuffle.
I was just curious to know which team you were referring to when you say
you are no longer on it? Would that be the ePub team, the InDesign team,
the Adobe team?
Thanks for the reply, Douglas. It's always eye opening to read your answers, although you often come across as angry at your customers. I imagine that's what happens when you read that many user forums.
No, I do not think I know more CSS than the developers at Adobe. And believe me that I appreciate the products you put out. What I believe is that, as you say, more feedback between the dev team and the final users would help you shape a product better geared to the users' needs.
I'll list a few thing I believe would help -me- better navigate my InDesign needs, and post them on a different thread. Let's see what other people say, and if your (ex)team can make them happen.
Thanks again. I do appreciate your work.
Actually, I have found that many of our customers DO know more than we do about their own workflow and so really I am just asking for specifics pertaining to them - never angry, truly. There are many equally valid opinions, the team's challenge is to navigate this sea of options and pick the one(s) that maximize...something.
Words like "better" and "cleaner" are not really actionable by engineers since it implies that we share a common understanding of the problem and solution and often I find that we do not. So be specific as you can.
Just a shout out to Yves Apel - he was super patient with me when I started on the epub stuff two years ago explaining WHY certain markup and css was a problem and WHAT would be better markup and css.
Without the help of expert customers such as him to get us started we would never have been able to make us much progress as we have - it is such a complicated area with many, many issues to contend with.
So we have much to teach/learn from each other and that is why I always to try to explain in my postings what the motivation/understand was for the change so you, the customer, can know our thoughts behind what we did.
Ps. Ariel: I remain at Adobe, but no longer on the InDesign team. CC 2014.1 was my last contribution to the product.
I'll try to be clearer on my points.
Again, thanks for the contributions to InDesign. I hope you do well on your next project.
> my longer term direction was to try to use even more IDs rather than generated numbered classes
Classes in HTML are like Styles (Paragraph, Character, Object) in InDesign. The power is in being able to apply one style to many elements.
Giving every object an ID is like giving every paragraph of an InDesign document its own paragraph style.
If all users rely on InDesign to generate their CSS, then I suppose that works (though it creates a lot of extra lines of CSS).
But not all users rely on InDesign to emit CSS.
We're a book publisher. We have many existing books that we're converting from print layouts to ePUB. We already used Styles (Paragraph, Character, Object) to apply consistent formatting to our print books' InDesign documents. We created one CSS template to use for all of our ePUB conversions. It's much easier this way to return consistently formatted ePUBS. It's also more likely to be adaptable to future changes--in HTML, in CSS, and in eReading platforms' support of both.
I was happy to have generated Classes for images. The generated IDs were not useful to us; we stripped them out.
Each new InDesign version's changes to ePUB export look like the result of a focus on Fixed Layout ePUBs at the expense of Reflowable. It sometimes seems like everyone in the ebook creation community is most excited about FL. But the vast majority of ebooks published and sold are Reflowable. The InDesign team wants to give designers the ability to create close replicas of their printed pages onscreen. But many of us working ebook designers are just trying to move book content from a legacy print format into a reflowable, adaptable digital format. To do that, we want clean, simple, semantic HTML and CSS. I'd love to be able to turn off the IDs and just generate classes. That correlates to what's considered a best practice in InDesign documents: Always try to use styles, not local formatting.
>Just a shout out to Yves Apel - he was super patient with me when I started on the epub stuff two years ago explaining WHY certain markup and css was a problem and WHAT would be better markup and css.<
Too much of honor. There have been also own interest behind.
>Classes in HTML are like Styles (Paragraph, Character, Object) in InDesign. The power is in being able to apply one style to many elements. Giving every object an ID is like giving every paragraph of an InDesign document its own paragraph style.<
That's the point. As David, I'm not a great fan of the CC 2014 code structure. Because of the IDs some workflows just broke as David explained. My personal goal is to have as less code as possible, but with the best compatibility. CC (2013) was very close on it. CC 2014 with the ids and all these positioning options, was as step back. I also consider the code as meed up which should become "cleaner".
Look at the example in here: ownCloud
2 x Text frames
1 x image frame
All have the object style "yellow" applied. The second frame has an inset spacing of 12 px.
padding:34.02px 34.02px 34.02px 34.02px;
padding:82.81% 0% 0% 0%;
margin:24px auto 24px auto;
This code is completely messed up.
Why 3 times display:inline-block; width:75%;? its defined in the object style.
Why not 12px for the padding of box 2 as defined?
Why this border width of 0px again. It has been defined already in the CSS reset for divs.
Here is my code:
margin:24px auto 24px auto;
padding:82.81% 0% 0% 0%;
Its smaller, nicer, cleaner and if you need to change a value that has been applied with an object-style (batch change frame settings), I also only need to change it once in the CSS for the (object-style) class "yellow" or its contained container "yellow-idGenContentObject" and not as above, multiple times.
In addition, the code is grouped together and not distributed over the whole CSS.
Comments in the CSS for different parts would also be nice!
Douglas, Anshul: Feel free to contact me on