View Full Version : tag <br /> causes epubeck error: attribute clear not allowed


georg3200
11-13-2009, 06:59 AM
When I check a epub with epubcheck (1.0.3 or 1.04) I always get an error:

"attribute "clear" not allowed at this point: ignored"

I tried the br tag in different versions <br/> or <br /> or <br></br>
I always get the error with the attribute clear. None of my br-tags contains an attribute clear or any other attribute.

It seems that the epub itself works without any problems in ADE, on a Sony PRS 505 and a Bookeen Opus. The br-tag works fine.
But our customers use ebupcheck to control the books we deliver. They only accept error-free books.

Usually I replace the br-tag with a new paragraph, but sometimes thats a lot of work with the stylesheet:(

Does anyone know, what I can do or what the problem is?

thanks
georg

pdurrant
11-13-2009, 07:07 AM
Could it be something in your CSS?

<br /> is allowed in ePubs.

To prove it, here's a tiny ePub that has a <br /> in it, and passes epubcheck 1.04


When I check a epub with epubcheck (1.0.3 or 1.04) I always get an error:

"attribute "clear" not allowed at this point: ignored"

I tried the br tag in different versions <br/> or <br /> or <br></br>
I always get the error with the attribute clear. None of my br-tags contains an attribute clear or any other attribute.

It seems that the epub itself works without any problems in ADE, on a Sony PRS 505 and a Bookeen Opus. The br-tag works fine.
But our customers use ebupcheck to control the books we deliver. They only accept error-free books.

Usually I replace the br-tag with a new paragraph, but sometimes thats a lot of work with the stylesheet:(

Does anyone know, what I can do or what the problem is?

georg3200
11-13-2009, 08:32 AM
Indeed your example works without any errors.

I will take a closer look at the stylesheets we are using.

Thanks for the tip.

kjk
11-13-2009, 01:00 PM
But our customers use ebupcheck to control the books we deliver. They only accept error-free books.


They are using epubcheck to ensure error-free books?

pdurrant
11-13-2009, 04:43 PM
They are using epubcheck to ensure error-free books?

Perhaps it would be fairer to say that they're using epubcheck to ensure that they don't accept books with known errors?

I don't know of any way to ensure error-free books.

kjk
11-13-2009, 05:25 PM
Perhaps it would be fairer to say that they're using epubcheck to ensure that they don't accept books with known errors?

I don't know of any way to ensure error-free books.

darn, I was hoping maybe there was a new version of ePubcheck out there :D

kovidgoyal
11-13-2009, 05:38 PM
Even fairer to say they're using epubcheck to ensure they have books that pass epubcheck.

charleski
11-15-2009, 09:31 AM
It's nothing to do with your css.
You're using the transitional xhtml spec in your doctype:
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'

Change that to
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'
and the errors should go away

For instance, here's Pauls example ePub in which the only thing that's changed is the xhtml spec in the doctype. It now produces errors in epubcheck.

pdurrant
11-15-2009, 12:58 PM
How interesting.

The transitional XHTML 1.0 DTD has the br element with a default attribute of clear:none

The strict XHTML 1.0 DTD has the br element with no default attributes.

Double-checking the ePub specs, it seems we ought to be using the XHTML 1.1 DTD instead. And in that br has no default attributes.

So I think that epubcheck was right!

It's nothing to do with your css.
You're using the transitional xhtml spec in your doctype:
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'

Change that to
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'
and the errors should go away

For instance, here's Pauls example ePub in which the only thing that's changed is the xhtml spec in the doctype. It now produces errors in epubcheck.

charleski
11-15-2009, 01:48 PM
Yes, you're right. The doctype should really be
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"
(and the content should be valid xhtml 1.1) to avoid any problems.

I must admit I'm still a little confused about all this DTD stuff (I'm no expert). The IDPF specs spend some time talking about backwards compatibility, which suggests that it should be possible to use older specs, though any new document should be using the current one, of course.

Making sure that ePubs pass epubcheck is very sensible for publishers. They want a file that they can archive away and won't have to spend time and money to fix because it doesn't render correctly on a new ereader a few years down the road.

kovidgoyal
11-15-2009, 02:17 PM
Making sure that ePubs pass epubcheck is very sensible for publishers. They want a file that they can archive away and won't have to spend time and money to fix because it doesn't render correctly on a new ereader a few years down the road.

The problem with that concept is that passing epubcheck doesn't guarantee anything at all, other than that the file will pass epubcheck.

charleski
11-15-2009, 09:00 PM
The problem with that concept is that passing epubcheck doesn't guarantee anything at all, other than that the file will pass epubcheck.You can spend decades studying astronomy, but it doesn't mean you'll be able to guarantee with complete certainty that the sun will come up tomorrow.

It guarantees it's free of the errors for which epubcheck checks. Any problems with epubcheck are largely problems with the standard itself (though I'm sure it has some real bugs still).

It would simply be silly not to demand that epubs pass epubcheck if you're in the business of commissioning documents that will be archived.

kovidgoyal
11-15-2009, 09:45 PM
Umm no, the major problem with epubcheck is that all it checks for is the conformance of epub with various DTDs. In the real world, conformance with DTD's is by far the least important of all checks you could possibly perform. The only reason that epubcheck exists at all is that it is trivial to code.

And yet, the existence of epubcheck convinces endless scads of people that their epubs are going to work as they intended, just because they pass epubcheck. I would have been so much happier if trivial had been prepended to epubcheck. But then no one would use it and then how are we to give people a warm and fuzzy feeling that their epubs are A OK and going to work forever.

GeoffC
11-17-2009, 05:51 AM
..... I've had plenty of annoying experience of epubcheck saying an ebook was good with no errors or warnings, but it looks good in firefox and ie - but then ADE insists "errors may cause this book to display incorrectly".
maybe the best way is to have one of each device that accepts epub and use those as the decider? (though whether each device itself follows the standard is another matter entirely).

kovidgoyal
11-17-2009, 09:13 AM
I usually advise people to get hold off at least one epub displaying device and check their files on that. It's no guarantee of anything other than that your files will display on that device, but IMO if your file displays on one device the chances that it will display on others are much higher than if it passes epubcheck.

Valloric
11-17-2009, 09:59 AM
Umm no, the major problem with epubcheck is that all it checks for is the conformance of epub with various DTDs. In the real world, conformance with DTD's is by far the least important of all checks you could possibly perform. The only reason that epubcheck exists at all is that it is trivial to code.

And yet, the existence of epubcheck convinces endless scads of people that their epubs are going to work as they intended, just because they pass epubcheck. I would have been so much happier if trivial had been prepended to epubcheck. But then no one would use it and then how are we to give people a warm and fuzzy feeling that their epubs are A OK and going to work forever.

Actually I'm planning on writing an epub checking library in C++. I'd extend epubcheck, but it's in Java and I can't link to it in Sigil (no, JNI and GCJ/CNI don't count). And I agree, it's very limited in it's current form. All of your arguments stand, although I do think that epubcheck still provides a useful service.

I'm interested in your (and other people's) thoughts on this: what should it check for etc. This project is a couple of months away until I get Sigil to a somewhat more stable state and implement the redesign + a few other major features. But I will start work on this eventually.

I plan on providing separate CLI and GUI applications (very simple things) that will use the library so that people who don't want to use Sigil can still benefit from this project.

Of course, since the lib will be in C++, it could also be easily linked to by applications written in, say, Python. :)

GeoffC
11-17-2009, 12:38 PM
Actually I'm planning on writing an epub checking library in C++. I'd extend epubcheck, but it's in Java and I can't link to it in Sigil (no, JNI and GCJ/CNI don't count). And I agree, it's very limited in it's current form. All of your arguments stand, although I do think that epubcheck still provides a useful service.

I'm interested in your (and other people's) thoughts on this: what should it check for etc. This project is a couple of months away until I get Sigil to a somewhat more stable state and implement the redesign + a few other major features. But I will start work on this eventually.

I plan on providing separate CLI and GUI applications (very simple things) that will use the library so that people who don't want to use Sigil can still benefit from this project.

Of course, since the lib will be in C++, it could also be easily linked to by applications written in, say, Python. :)


wooooooo!!!!

of more use would be the specific error found, not some vague error statement which leaves one headscratching ....

again

wwwooooOOOOOOO!!!!

kovidgoyal
11-17-2009, 08:51 PM
I'd vote for including reader specific checks. So for example there is a page in the calibre wiki that documents the various quirks of ADE. It would be good to check for those. For example, ADE refuses to handle anchors names that start with a number. Or top level <br> tags (though I believe that was fixed in recent releases). Then are the various quirks of webkit based renderers. A place they are documented is in the EPUB output plugin in calibre, which implements work arounds for all these quirks. And of course it needs to do checking of flow sizes. Even though the flow size restriction has been mitigated in recent Adobe SDKs, it's not unlimited nd I think it's good practice to encourage people to split up their HTML anyway.

But really the most important set of tests is rendering tests and those are impossible to automate, the best that could be done is identify certain constructs that are unlikely to render correctly and warn about them. Things like fixed whitespace containers, large (wide) tables and so on.

And as GeoffC said it would be very important to make the error messages actually intelligible. I'm no dunce and I have a hard time figuring out what epubcheck error messages mean. I can only imagine how cryptic it must be for people that are not as familiar with XHTML.

Jellby
11-18-2009, 06:05 AM
For example, ADE refuses to handle anchors names that start with a number.

Well, according to the HTML4 spec (http://www.w3.org/TR/html4/types.html#h-6.2):

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

Maybe that's changed in XHTML, though.

kovidgoyal
11-18-2009, 09:03 AM
Well, according to the HTML4 spec (http://www.w3.org/TR/html4/types.html#h-6.2):

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

Maybe that's changed in XHTML, though.

Yeah but ADE is the only major HTML renderer I know that doesn't handle anchor names that start with numbers.

charleski
11-19-2009, 03:32 PM
Umm no, the major problem with epubcheck is that all it checks for is the conformance of epub with various DTDs.It's basically an extended XML validator. I don't understand your antagonism. I've certainly found it helpful in locating errors I've made while editing ePubs.

It doesn't guarantee that an ePub will render on current or future devices, but it does filter out elementary errors and superfluous fluff.

Valloric
11-19-2009, 08:50 PM
It's basically an extended XML validator. I don't understand your antagonism. I've certainly found it helpful in locating errors I've made while editing ePubs.

It doesn't guarantee that an ePub will render on current or future devices, but it does filter out elementary errors and superfluous fluff.

My thoughts exactly. Epubcheck may be limited, but it has its uses. I'm guessing Kovid's main objection is that people use it and think "if it passes epubcheck, all will be well" when it's likely that it won't be.

But that's the problem of the users, not the tool. Epubcheck makes no claims that it is the be-all, end-all epub checker.