EPUB3 introduce prefixes to properties in CSS WD? (Part 2)
MURATA Makoto
I managed to write the second part, which caused a lot of brain damage.
Here goes.
Regards,
Makoto
-----------------------------------------------------------------------------------------
7. Versioning
Section 1.2.4 of the EPUB content spec shows a versioning strategy.
The IDPF anticipates revising the EPUB 3 specifications if and
when such incompatible changes occur, updating the normative
constraints defined herein as necessary and incrementing the
minor version number of EPUB 3 (e.g., publishing an
EPUB 3.0.n).
This strategy implies that each minor version of EPUB3 has slightly
different versions of properties derived from CSS WDs and that reading
systems have to behave differently depending on the minor version.
Reading systems could reply on the version attribute of the package
document or property prefixes (e.g., epub301-, epub302-).
Note: I contacted Simon Fraser (a member of the CSS WG) of Apple.
He wrote:
>We also have a strong preference to avoid -epub3 and -epub4 prefixes,
>since we do not want the additional burden of supporting multiple obsolete
>behaviors in perpetuity. We'd prefer a single -epub prefix.
In my interpretation, Apple is against the EPUB versioning strategy.
8. Possible options
There are two major options, unprefixed or prefixed properties in EPUB
CSS Profile, and two variations.
8.1 Unprefixed properties
EPUB CSS Profile has unprefixed properties (rather than prefixed ones)
borrowed from CSS WDs. EPUB reading systems support these unprefixed
properties. EPUB stylesheets contain unprefixed properties but no
prefixed properties.
1) Pros
- If the final recommendations do not change the borrowed properties,
this approach ensures longevity and leads to no forks.
2) Cons
- If the final recommendations or interim drafts change
the borrowed properties, this approach provides a fork and
fails to ensure longevity (unless we rewrite EPUB publications
by conversion).
- The upcoming corpus of EPUB publications will cause lock-in: it
will become difficult for the CSS WG to change the properties even
when there are good reasons.
8.2 Prefixed properties
EPUB CSS Profile has prefixed properties (rather than unprefixed ones)
derived from CSS WDs. EPUB reading systems support these prefixed
properties. EPUB stylesheets contain prefixed properties but no
unprefixed properties.
1) Pros
- This approach ensures longevity if future EPUB reading systems continue to
support the prefixed properties in EPUB3.
- This approach does not cause lock-in to the current design.
- If the final recommendations or interim drafts do not change the
borrowed properties, the EPUB fork merely provide syntactical
aliases thus providing little overhead.
2) Cons
- If future EPUB reading systems do not support the prefixed properties,
we will lose longevity.
- The EPUB fork caused by this approach will lead to significant
burdens especially when the semantics of the EPUB fork become
different from those of the final CSS recommendations or interim
drafts.
8.3 Unprefixed properties after prefixed ones
This option is a variation of 8.2 Prefixed properties. Differences
are as follows:
>EPUB CSS Profile has prefixed properties (rather than unprefixed ones)
>derived from CSS WDs.
This is slightly changed. Unprefixed properties are also allowed.
>EPUB reading systems support these prefixed properties.
No changes. However, when the referenced CSS specs becomes W3C
recommendations, EPUB reading systems are expected to support prefix
properties.
>EPUB stylesheets contain prefixed properties but no
>unprefixed properties.
This is slightly changed. Each prefixed property in a stylesheet is
followed by an unprefixed property. For example, epub-writing-mode is
followed by writing-mode. If both prefixed and unprefixed properties
are supported by a reading system, the unprefixed one (e.g.,
writing-mode) wins.
1) Pros
- If the final recommendations do not change the borrowed properties,
this approach ensures longevity. An implementation can easily migrate
from prefixed properties to unprefixed ones.
- If the final recommendations do not change the borrowed properties,
the EPUB fork is merely a collection of aliases and is thus not serious.
2) Cons
- If the final recommendations or interim drafts change
the borrowed properties, this approach provides two forks:
a prefixed fork and an unprefixed fork.
- If the final recommendations or interim drafts change
the borrowed properties, this approach fails to ensure
longevity (unless we rewrite EPUB publications by conversion).
If reading systems start to support unprefixed properties, the existing
corpus of EPUB publications will not work.
- Although unprefixed properties are simply ignored by upcoming
reading systems, they arguably cause lock-in. If reading
systems start to support unprefixed properties, the existing
corpus of EPUB publications will not work.
Simon wrote:
> I've checked with other people here at Apple, and we agree on the following,
> from an implementor's perspective:
>
> * EPUBs should use the -epub prefix for CSS3 properties that are not in CR.
> * For future compatibility, EPUBs should include an unprefixed property
> declaration after the prefixed one, in most cases[1].
>
> As an implementor, we have the following considerations:
> * We share the same code between EPUB viewers and the web browser
> * We have a strong desire to avoid content-specific behaviors (i.e. we will
> not add behavior that only triggers if an EPUB is being displayed).
> * Thus, we cannot expose unprefixed properties to EPUB only
>
> We also have a strong preference to avoid -epub3 and -epub4 prefixes,
> since we do not want the additional burden of supporting multiple obsolete
> behaviors in perpetuity. We'd prefer a single -epub prefix.
>
> I think that the -epub prefix is also of benefit to authors, since it indicates that:
> 1. the behavior is not stable, and subject to change in future versions of a given UA
> 2. the behavior may be different in different UAs.
8.4 Unprefixed properties *before* prefixed ones
This option is only slightly different from the previous one. In this
option, each unprefixed property in a stylesheet is followed by a
prefixed property. For example, writing-mode is followed by
epub-writing-mode. If both prefixed and unprefixed properties are
supported by a reading system, the prefixed one (e.g.,
epub-writing-mode) wins.
1) Pros
- If the final recommendations do not change the borrowed properties,
this approach ensures longevity. An implementation can easily migrate
from prefixed properties to unprefixed ones.
- If the final recommendations do not change the borrowed properties,
the EPUB fork is merely a collection of aliases and is thus not serious.
- Even when the final recommendations change the borrowed properties,
this approach ensures longevity as long as future EPUB reading
systems continue to
support the prefixed properties in EPUB3.
- If reading systems continue to support the prefixed properties in EPUB3,
the upcoming corpus of EPUB publications will not cause lock-in,
since unprefixed properties continue to be ignored.
2) Cons
- If the final recommendations or interim drafts change
the borrowed properties, this approach provides two forks:
a prefixed fork and an unprefixed fork.
- If the final recommendations or interim drafts change
the borrowed properties, reading systems cannot stop
the support of prefixed properties without hampering
longevity (unless we rewrite EPUB publications by conversion).
- Although unprefixed properties are simply ignored by upcoming
reading systems, they arguably cause lock-in. If reading systems
start to support unprefixed properties and stop the support of
prefixed properties, the existing corpus of EPUB publications
will not work any more.
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
Daniel Weck
To minimize brain damage, I made a little table summary:
http://epub-revision.googlecode.com/svn/trunk/build/CSS-Props-Prefix-Pros-Cons.html
Feel free to edit this file, and if necessary to move it wherever
suitable on SVN, for the time of this ongoing discussion.
Regards, Daniel
Daniel Weck
danie...@gmail.com