Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

which HTML5 content modell to check? #988

Closed
Doktorchen opened this issue Feb 28, 2019 · 5 comments
Closed

which HTML5 content modell to check? #988

Doktorchen opened this issue Feb 28, 2019 · 5 comments
Labels
type: not an issue The issue is rejected (not an actual issue or not relevant)

Comments

@Doktorchen
Copy link

Is it correct, that epubcheck-4.2.0-beta only checks content models of HTML5.2?
I think, it has to check at least the content models of HTML5.0, 5.1 as well, because books following EPUB 3.0 or 3.0.1 will presumably follow HTML 5.0 or because EPUB 3.0 predates the HTML5.0 recommendation they will follow even an earlier variant of HTML5.

To claim, that something is an error, when the usage was completely correct at the time, the book was created, is extremely alienating for authors.
They cannot rely anymore, that their books remain valid.
Such eternal updates of digital books to fit to changing recommendations feels like the punishment of Sisyphos ;-)

Example: For the table element the content model changed after 5.0 in something backwards incompatible (to XHTML 1.x and HTML4) - concerning possible positions of tfoot.
An attribute sortable introduced in 5.0 was removed in 5.1.

@rdeltour
Copy link
Member

It was decided in w3c/publ-cg#68 that EPUBCheck would not differentiate among EPUB 3.x spec versions. This incidentally means that EPUBCheck will follow the latest HTML evolutions, which may indeed invalidate some previously-valid elements or attributes.

If you disagree with this decision, I would suggest to comment to the issue mentioned above, or create another issue in the EPUB3 CG tracker.

This issue can be closed until this decision changes at the CG level.

@rdeltour rdeltour added the type: not an issue The issue is rejected (not an actual issue or not relevant) label Feb 28, 2019
@Doktorchen
Copy link
Author

Well not much use to check further, what epubcheck 4.2.0-beta does, I only have test books for EPUB 3.0 or 3.0.1 ;o)
I will stay with 4.1.1 for further testing (and reporting test results to authors on my page).
Maybe I will add a hint about this problem.

@tofi86
Copy link
Collaborator

tofi86 commented Feb 28, 2019

This can indeed be a major blocker for the use of EPUBCheck 4.2 with regard to the implementation dates at big vendors. for example, it took apple over 4 years to upgrade from EPUBCheck 3 to 4, and there have been voices in CG calls that suggest similar situation at other big vendors.

Will be really hard to create EPUBs for cross-platform then...

@mattgarrish
Copy link
Member

Yes, it's the next big problem to tackle after updating the spec and epubcheck, but if vendors aren't keeping pace with updates, it's an industry problem and needs to be solved at that level.

We've been living in the past for a long time now and it's been equally frustrating for publishers who can't take advantage of new features and have to cross-reference the new specifications to find out what has died and where HTML really is right now.

There really also isn't anything such as 3.0 or 3.0.1 validation. There are vendors who use specific releases of epubcheck, but what those versions allow or disallow is static. It can't be reproduced in any useful fashion for "throwback validation" as the schemas and tests are always being fixed and improved.

@Doktorchen
Copy link
Author

In the past, when there was a switch from XHTML2.0 to HTML5 the HTML5 working group at W3C promised, that HTML5 does not need a version indication, because it will not be backwards incompatible. This was never true and became obvious with HTML5.1 and HTML5.2.

But the core idea remains: HTML5 is author friendly, because there is no version indication, apart from (XML)-structure bugs for the XML variant everything is correct, the author thinks is correct. In doubt HTML5 has to provide rules how to deal with old or even undefined content for developers of user-agents.

This means, a checker has to accept, what authors believe/feel, what is correct.
To check only 5.2 or in the future an arbitrary other version would be completely against the core idea of HTML5, that authors do not have to care anymore.

This means, the epubcheck should only provide error messages about XML syntax errors, maybe warnings, if a document does not fit to the basic structure (root html element, containing one head followed by one body).
This ensures, that authors and book store and distributor staff will not be surprised and frustrated by changing error messages and warnings by epubcheck, that do not fit to their interpretation of the language.

The second edition of SVG 1.1 has only minor backwards incompatibilities compared to the first edition. SVG 2 has much more.
But SVG 1.1 still has a version indication, therefore something to check properly.
For SVG 2 applies a similar concept as for HTML5 - what the authors thinks, that is ok, is ok.

As far as I understand the related sections in EPUB 3.1 and 3.2 this is the spirit of these versions as well - what authors assume, that it works, is fine.

From my point of view: These concepts without version indication and without applicable testing will result in a lot of nonsense.
But that is the current state of information in internet anyway, why worry? ;o)
'post-truth', 'post-factual' (german: postfaktisch): Facts do not matter, what you feel, that is right, counts, you are free to interpret everything in your own way, publishing any nonsense about it ;o)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: not an issue The issue is rejected (not an actual issue or not relevant)
Projects
None yet
Development

No branches or pull requests

4 participants