Prefixes in ePub CSS profile
Brady Duga
discuss the following proposal for incorporating unstable CSS modules
into the EPUB profile. Please review it before the meeting so we can
attempt to come to resolution on the topic.
Proposal:
All properties in CSS modules that have not yet reached Candidate
Recommendation, or are in danger of losing that status (e.g. CSS Ruby)
will receive an unversioned “-epub-” prefix, with some exceptions
noted below. A definitive list of such properties will be forthcoming,
but they include the properties in CSS 3 Text, CSS Writing Modes, and
CSS 3 Speech. The syntax of these properties will be defined by dated
references to the current, published versions of the modules in
question. The semantics, however, will be specified by the most recent
published version of the relevant module.
There are three properties that are exceptions to this rule. First,
“text-trim” which has been dropped from the latest editors draft of
CSS 3 Text. We take this as a sign that it is in danger, and will drop
it from our list of properties entirely. Second, “ruby-position” will
remain as -epub-ruby-position in our profile, but both syntax and
semantics will be specified by the EPUB spec. The final property,
“speakability”, remains uncertain. More input on this property is
needed before we recommend what should be done with it.
--Brady
Daniel Weck
On 27 Apr 2011, at 01:43, Brady Duga wrote:
> The syntax of these properties will be defined by dated
> references to the current, published versions of the modules in
> question. The semantics, however, will be specified by the most recent
> published version of the relevant module.
Great.
> The final property, “speakability”, remains uncertain. More input on
> this property is
> needed before we recommend what should be done with it.
The functionality ("semantics") is likely to remain stable, but the
name of the property may change. The aforementioned referencing
pattern therefore seems suitable for the 'speakability' property of
the CSS3 Speech Module.
Regards, Daniel
MURATA Makoto
In the teleconf, I opposed to the original proposal from Apple,
which uses both unprefixed properties and fixed properties.
Let me explain why.
I wrote a summary of some options including the proposal from
Apple. As shown in that summary, the proposal from Apple does
have some advantages as well some disadvantages. In my understanding,
the biggest advantage is that, when the final CSS recommendations
do not change the syntax, migration will be easier.
http://groups.google.com/group/epub-working-group/browse_thread/thread/ca3ef768f53c3a99#
http://groups.google.com/group/epub-working-group/browse_thread/thread/af9726725305351c#
However, in reality, content authors will make a variety of
stylesheets anyway. Some will have prefixed ones only, and others
will have both prefixed and unprefixed ones (including
both occurrence orders). Yet others will use the -webkit-
prefix as well, which is currently available. We will have to
handle such stylesheets anyway. Even if IDPF recommends
the use of both prefixed and unprefixed properties and
the final CSS recommendations introduce no syntactical changes,
I do not think that implementors can simply drop the support
of prefixed properties.
If EPUB3 introduces prefixed properties, we have to admit that
implementations will probably have to support the prefixed properties
for a long time (more than 5 years, I guess).
Furthermore, if the final CSS recommendations does change the syntax,
we will have a mess.
Regards,
Makoto
2011/4/27 Brady Duga <du...@google.com>:
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
Peter Sorotokin
Peter
Neil Soiffer
I second Peter's agreement.
Neil Soiffer
Edward O'Connor
Brady wrote:
> 1. Authors should/must include both prefixed and unprefixed versions
> of properties in their style sheets. Reading systems that implement
> these properties must support the prefixed versions. We will
> mandate that the unprefixed version come either before or after the
> prefixed one, with clarifying text about aliasing the properties.
> This allows us to drop prefixes in the future, since content should
> continue to work. It also allows epub content documents to work
> unmodified in browsers once the CSS specs are implemented without
> prefixes in those user agents.
This is our original proposal, and it's one that we can live with. That
said, we prefer our revised proposal, and I don't recall there being
anybody on the call who couldn't live with it.
Makoto wrote:
> In the teleconf, I opposed to the original proposal from Apple,
> which uses both unprefixed properties and fixed properties.
I believe most or all of your concerns with our original proposal are
addressed by our revised proposal. In fact, your concerns were what
prompted the revision! :) Here's how our proposals fare (quotes from
<URL:http://groups.google.com/group/epub-working-group/browse_thread/thread/af9726725305351c>):
> Pro: 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.
>
> Pro: If the final recommendations do not change the borrowed
> properties, the EPUB fork is merely a collection of aliases and
> is thus not serious.
Agreed on both counts.
> Con: If the final recommendations or interim drafts change the
> borrowed properties, this approach provides two forks: a prefixed
> fork and an unprefixed fork.
Only in our original proposal; our revised proposal avoids this issue.
> Con: 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.
I don't think this is true. Consider an EPUB3 book containing the
following CSS properties:
-epub-foo: old-syntax;
foo: old-syntax;
Between EPUB3 being published and the Foo module going to CR, the syntax
of the 'foo' property changes.
You now open this .epub in a Reading System that supports the updated
(CR) Foo module. In such an RS, "-epub-foo: old-syntax;" parses, but
"foo: old-syntax;" fails to, and thus the prefixed rule gets applied.
Our revised proposal avoids this problem entirely, since "foo:
old-syntax;" would never appear in content.
> Con: 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.
I believe my example above illustrates why this isn't a problem with our
original proposal. (It is also not a problem for our revised proposal.)
> However, in reality, content authors will make a variety of
> stylesheets[…] We will have to handle such stylesheets anyway.
Of course. So our spec should help authors to write their stylesheets in
the most robust manner possible.
> Even if IDPF recommends the use of both prefixed and unprefixed
> properties and the final CSS recommendations introduce no syntactical
> changes, I do not think that implementors can simply drop the support
> of prefixed properties.
As you said before, regardless of what the EPUB spec ends up saying,
authors will include all sorts of craziness in their CSS. Even if we
mandate that authors include both prefixed and unprefixed properties,
there will be authors that only include one, and other authors that only
include the other.
Consider an EPUB3 document published containing the following rules:
-epub-foo: syntax;
foo: syntax;
At some later time, the Foo module goes to CR *without* any syntax
changes.
Reading Systems don't magically change overnight when specs move along
the W3C's spec stages. So Reading Systems that shipped before updating
their CSS engines to support the CR Foo module would use the prefixed
property, and ignore the unknown, unprefixed one.
But at some point you'll have a Reading System that implements the
unprefixed 'foo' property. When such an RS encounters our book
containing the above rules, it would prefer the unprefixed property.
In both cases, the author achieves her intended effect.
> If EPUB3 introduces prefixed properties, we have to admit that
> implementations will probably have to support the prefixed properties
> for a long time (more than 5 years, I guess).
Neither our original proposal nor our revised proposal constrain future
versions of EPUB, and the EPUB4 WG might very well keep our prefixed
properties around—even if the CSS specs are well past CR at that point.
But should they decide to drop support for prefixed properties, EPUB3
documents in the wild would be better off containing the unprefixed
properties as well.
> Furthermore, if the final CSS recommendations does change the syntax,
> we will have a mess.
This concern is addressed by our revised proposal.
Getting back to Brady's email, he describes the prefixed-only proposal.
> [This proposal] requires reading systems to maintain prefix support
> for the foreseeable future. Proponents of this approach argue that is
> the case anyway,
While this is likely the case for *some* Reading Systems, or even some
specific properties in some reading systems, I don't know how reasonable
it is to mandate it for all of them. Historically, different UAs have
had different policies with regard to vendor prefixes in CSS[1], which
is the closest thing to prior art for guiding our decision here.
--
Edward O'Connor
WebKit Rendering Team
Apple Inc.
1. One the one hand, Mozilla usually tries to drop support for -moz
prefixed properties as soon as they can. On the other, WebKit will
likely support its -webkit prefixed gradient syntax for the
forseeable future.