issue #140 :media-overlay-active
Marisa DeMeglio
Today, Daniel Weck (the other editor of the Media Overlays spec) and I
met on Skype to discuss the :media-overlay-active pseudoclass issue
#140 [1]. As you have probably read in this thread [2], the issue is
that there are differing viewpoints about whether it is best to use a
pseudoclass or to create a reserved regular class name in CSS.
As our discussion progressed, we found that we are both increasingly
in favor of using a reserved regular class name in CSS instead of
using a pseudoclass. We want Media Overlays to be easy to implement
with existing browser technology, and we have heard from implementers
that the CSS processing required for handling custom pseudoclasses is
challenging. A search-and-replace method that renames
":media-overlay-active" to ".media-overlay-active" was the nearest
feasible approach, but the problem is that there are cases for which
it will not work acceptably, so we cannot recommend it. We see that
using a reserved regular CSS class name will produce the correct
output 100% of the time.
We understand the benefit of using a pseudoclass: that it is never
going to conflict with author-defined class names, and that it is the
more correct approach from a standards perspective. However, it
appears to be impractical from implementers' perspectives, and
therefore runs a high risk of not being supported at all.
Another part of the thread about this issue mentioned renaming
"media-overlay-active" (in whatever class or pseudoclass form it
takes) to "-epub-media-overlay-active"; I don't think there is any
debate about this, and I'd like to make this change once we resolve
the bigger issue.
Looking forward to hearing your thoughts and reaching a resolution.
Marisa and Daniel
1. http://code.google.com/p/epub-revision/issues/detail?id=140
2. http://groups.google.com/group/epub-working-group/browse_thread/thread/826af2152a60aa46
Peter Sorotokin
As I said before, (1) this sets a dangerous precedent that will open a path
for more abuse in the future and (2) I reject the logic that CSS processing
is challenging (in fact, I do not think it is possible to implement either
EPUB2 or EPUB3 properly without it).
An additional observation which I have after playing with this a bit is that
if media overlay is added as a post-processing of a non-audio-enabled EPUB
file (which is the most interesting case to us), we could use CFIs (or any
other "pointing" fragment identifier scheme) to point to the text, but there
would not be any real elements where they point. Highlighting would have to
be done using a more complex technique than simply adding/removing a class
to an element. So using a class name does not really scale for future use.
It is too late to make this change even if it was a good one. For instance,
I would need to figure out what is the position of other stakeholders at
Adobe for class name reservation. This kind of techniques are used, for
instance, in microformats. In my opinion, they suffer from the same flaws
and should be replaced with something like RDFa, but I'd need to find people
who deal with that stuff and figure out where Adobe stands there.
I do support renaming the pseudo-class to give it -epub prefix.
If Apple still cannot live with the current spec, even after adding the
prefix, I think we will have to defer this feature.
Peter
Daniel Weck
name solution: what if the author him/herself was able to define the
class name?
This is the approach adopted by a recent SMIL Timesheets
implementation proposal [1], which elegantly enables the
discoverability of CSS styles applicable to the "active" (in the time
dimension) element. It is also cheap to implement, and doesn't break
any philosophical mantra.
Note that with SMIL Timesheets, there may actually be more than one
active element at a given time (parallel activation), but this is de-
facto restricted by the SMIL synchronization model in EPUB3 Media
Overlays.
SMIL Timesheets allows authors to define as many class names as they
see fit, so that various "active" styles can be applied to different
parts (content fragments) of the document. This is useful for
graphically-rich content that relies on various background colors or
images, from page to page. To keep things simple in EPUB3, we could
restrict the granularity to the publication as a whole, or do it on a
per-content-document basis (or both, actually).
We could, for example, leverage the existing metadata infrastructure
rather than relying on a particular attribute in the HTML5 or SMIL
markup. Reading systems would just have to pick-up the class name(s)
when loading the manifest or the content documents headers, and this
class name could easily be "injected" (+ subsequently removed) via DOM
manipulation whenever an element gets activated (+ subsequently de-
activated).
Note about implementation complexity:
support for per-content-fragment "active" styling requires tracking
the author-specified CSS class name, which tunnels down the document
tree via an inheritance mechanism totally independent from CSS's own
mechanism. Should this be controlled from the SMIL markup, this would
add yet another level of indirection that would increase the
complexity by an order of magnitude. Thus why I recommend considering
the simpler publication-level, and/or content-document-level solution.
Regards, Daniel
[1]
http://wam.inrialpes.fr/timesheets/docs/timeAction.html
Daniel Weck
synchronized text/audio using human pre-recorded narration, and I
assume that it is based on EPUB3 Media Overlays with the reserved "-
epub-media-overlay-active" class name.
It seems that a few children's books have already been produced for
the iBooks store platform, so I imagine that the Apple folks are keen
to see an emerging solution that doesn't break their content model.
I am glad to report that my proposed alternative solution would only
require a minor addition to the package metadata of *new* titles, and
of course a minor update of the reading system itself to support
authored style customizations.
See, for example, how we currently specify the duration of individual
"chapters" (SMIL files) and the total duration of the publication:
<package>
<metadata>
…
<meta property="media:duration" about="#ch1_audio">0:32:29</
meta>
<meta property="media:duration" about="#ch2_audio">0:34:02</
meta>
<meta property="media:duration" about="#ch3_audio">0:29:49</
meta>
<meta property="media:duration">1:36:20</meta>
…
</metadata>
…
</package>
As you can see, the "about" attribute refers to manifest items (SMIL
files), and in its absence, the metadata value applies to the
publication as a whole.
Now, this is how it would look for the CSS "media overlay active"
class (assuming "media:active-class" is added to the EPUB3
vocabulary):
<package>
<metadata>
…
<meta property="media:media-overlay-active-class"
about="#ch1_audio">ch1_media-overlay-active</meta>
<meta property="media:media-overlay-active-class"
about="#ch2_audio">ch2_media-overlay-active</meta>
<meta property="media:media-overlay-active-class"
about="#ch3_audio">ch3_media-overlay-active</meta>
<meta property="media:media-overlay-active-class">-epub-media-
overlay-active</meta>
…
</metadata>
…
</package>
Authors would define the styles for the various classes in their
content document stylesheets. The "-epub-media-overlay-active" class
would apply to the entire publication, unless overridden by the per-
chapter styling (the SMIL engine would easily obtain this information
statically, at initial parsing stage => no dynamic inheritance
resolution here).
Note that allowing different highlighting styles for different atomic
sections of the publication is particularly useful for children's
books where the page background is often a rich illustration, with
various contrast and color schemes (in a 10-pages illustrated book,
each page can realistically be implemented with a single HTML file,
using fixed layout if necessary => each file/page would define its own
suitable playback styles).
Feedback welcome. Regards, Daniel
[1]
http://itunes.apple.com/us/app/id364709193?mt=8#
Marisa DeMeglio
attribute in the Media Overlays file itself? For example, to allow
document-level styling information to be overridden for a single par?
Or, would we expect that authors would assign a class to the
corresponding HTML element for that par, and use a CSS rule like
.myMediaOverlaysClass.mySpecialCaseText {color: blue !important;}
?
Marisa
Peter Sorotokin
I think that declaring what the "active" class is somewhere is a much better
solution than some sort of a magic class name. Not sure if metadata is the
right place for it, but I don't have strong feelings on that.
Peter
On 6/9/11 4:07 AM, "Daniel Weck" <danie...@gmail.com> wrote:
> As you probably all know by now, iBooks 1.3 implements [1]
> synchronized text/audio using human pre-recorded narration, and I
> assume that it is based on EPUB3 Media Overlays with the reserved "-
> epub-media-overlay-active" class name.
>
> It seems that a few children's books have already been produced for
> the iBooks store platform, so I imagine that the Apple folks are keen
> to see an emerging solution that doesn't break their content model.
>
> I am glad to report that my proposed alternative solution would only
> require a minor addition to the package metadata of *new* titles, and
> of course a minor update of the reading system itself to support
> authored style customizations.
>
> See, for example, how we currently specify the duration of individual
> "chapters" (SMIL files) and the total duration of the publication:
>
> <package>
> <metadata>
> Š
> <meta property="media:duration" about="#ch1_audio">0:32:29</
> meta>
> <meta property="media:duration" about="#ch2_audio">0:34:02</
> meta>
> <meta property="media:duration" about="#ch3_audio">0:29:49</
> meta>
> <meta property="media:duration">1:36:20</meta>
> Š
> </metadata>
> Š
> </package>
>
> As you can see, the "about" attribute refers to manifest items (SMIL
> files), and in its absence, the metadata value applies to the
> publication as a whole.
>
> Now, this is how it would look for the CSS "media overlay active"
> class (assuming "media:active-class" is added to the EPUB3
> vocabulary):
>
> <package>
> <metadata>
> Š
> <meta property="media:media-overlay-active-class"
> about="#ch1_audio">ch1_media-overlay-active</meta>
>
> <meta property="media:media-overlay-active-class"
> about="#ch2_audio">ch2_media-overlay-active</meta>
>
> <meta property="media:media-overlay-active-class"
> about="#ch3_audio">ch3_media-overlay-active</meta>
>
> <meta property="media:media-overlay-active-class">-epub-media-
> overlay-active</meta>
> Š
> </metadata>
> Š
Daniel Weck
a new attribute in the SMIL and the need to handle inherit/override
behavior in the document or timing tree. Combining multiple classes,
like you suggest, is a much better option. I don't think we need to
standardize this though ... perhaps an informative note and/or an
illustrative example?
Dan
Daniel Weck
danie...@gmail.com
Cramer, Dave
>> wrote:
>>> As you probably all know by now, iBooks 1.3 implements [1]
>>> synchronized text/audio using human pre-recorded narration, and I
>>> assume that it is based on EPUB3 Media Overlays with the reserved "-
>>> epub-media-overlay-active" class name.
Yes, Apple does use EPUB3 media overlays and -epub-media-overlay-active
Dave
Casey Dougherty
Daniel, Marisa - Thank you for examining MO again. I ran Daniel's revised proposal by Kevin and we feel that the proposal is needlessly complex. It solves the philosophical objection, but in practice book developers will use the CSS class name from the documentation/samples. CSS already provides facilities to customize the highlighting style differently for different documents/elements (as was mentioned already). In the end, this will be one more thing authors have to learn and implement without gaining any new functionality.
Casey
Daniel Weck
discoverable means that the EPUB3 standard doesn't have to *reserve* a
class name, which is unanimously considered bad practice and would set
a significant negative precedent given how widespread EPUB is. To
quote this morning's comment [1] from one of the CSS Working Group
member:
"
If epub is supposed to play nicely with other web content, then
reserved class names are a no-no. The entire *point* of pseudoclasses
is that they are reserved class names, so the class attribute remains
entirely in author's hands."
"
You say: "the proposal is needlessly complex". I disagree on both
accounts. In my view, it is both needed and simple. Firstly, it is
needed because the EPUB3 Working Group will not reach a consensus with
either of "reserved class name" or "pseudo class" solutions. The
"discoverable class name" approach addresses the objections to the two
aforementioned proposals. Secondly, it is simple because it relies on
an existing, well-understood metadata mechanism, which is cheap to
implement (reading systems) and easy to incorporate in a production
workflow (the additional metadata entry can actually be automated, or
be part of a template). In the spirit of compromise, I would however
be happy to consider removing the option for authors to define a class
name on a per-content-document basis (i.e. only allow publication-wide
class name).
The proposal is also non-intrusive with respect to already-published
iBooks content, in the sense that existing material based on the draft
version of EPUB3 will still work when the iBooks reading system is
updated to support the final, approved EPUB3 specification. This is
because in the absence of media overlay "class name" metadata, the CSS
styling of "active" elements becomes implementation-dependent. In the
case of Apple iBooks, this would mean using the "-epub-media-overlay-
active" class, so old content would still work.
You say: "in practice book developers will use the CSS class name from
the documentation/samples". I agree, but authoring and sample code are
the embodiment of specifications. Here we have an opportunity to
standardize the discoverability of the Media Overlay "active"
class(es), at minimal cost and in a non-controversial fashion. I'd
much rather grab this opportunity than defer the issue and end-up with
vendor-specific solutions.
Could you please run this discussion again on your side, including my
suggestion to only allow the discovery of the class name at the
publication level?
Many thanks, and congratulations for the successful iBooks release! :)
Cheers, Dan
[1]
http://lists.w3.org/Archives/Public/www-style/2011Jun/0248.html
Daniel Weck
danie...@gmail.com
Daniel Weck
<package>
<metadata>
...
<meta property="media:active-class">epub-media-overlay-active</
meta>
...
</metadata>
</package>
Adapting the Media Overlay "active" styles on a per-content-document
basis is still possible, by organizing stylesheets in a particular way
(e.g. different CSS files for different HTML files). And of course it
is still possible to enable content-fragment-specific styling by
making use of combined CSS class names (e.g. .epub-media-overlay-
active.mySpecialParagraphClass {color: blue;}).
Regards, Dan
> mean using the "-epub-media-overlay-active" class, so old content
Daniel Weck
danie...@gmail.com
Markus Gylling
It looks like we have two options for resolving this issue:
* defer the feature completely (and let it be implemented in multiple proprietary ways instead)
* go with Daniels proposal, as described earlier in this thread and below.
Note that I am not including the reserved class name option here, as it has met with objections in this WG, and in addition has been described as a "no-no" by a CSS WG member.
At this point, I would like to ask: is there anyone in this WG who would want to register a "can not live with" (aka objection) for Daniels proposal? Please respond within 48 hours; if we have no can not live withs registered, the next steps are to settle the final details (term name, global only or not), and then issue a formal 72 hour notification period for this change to be included.
I hope we can settle on Daniels proposal here, as leaving this feature undefined in the spec is likely to cause a lot of publisher headache going forward.
Regards, /markus
On Jun 10, 2011, at 1:12 AM, Daniel Weck wrote:
> Hi Casey, making the Media Overlay "active" CSS class name discoverable means that the EPUB3 standard doesn't have to *reserve* a class name, which is unanimously considered bad practice and would set a significant negative precedent given how widespread EPUB is. To quote this morning's comment [1] from one of the CSS Working Group member:
>
> "
> If epub is supposed to play nicely with other web content, then reserved class names are a no-no. The entire *point* of pseudoclasses is that they are reserved class names, so the class attribute remains entirely in author's hands."
> "
>
> You say: "the proposal is needlessly complex". I disagree on both accounts. In my view, it is both needed and simple. Firstly, it is needed because the EPUB3 Working Group will not reach a consensus with either of "reserved class name" or "pseudo class" solutions. The "discoverable class name" approach addresses the objections to the two aforementioned proposals. Secondly, it is simple because it relies on an existing, well-understood metadata mechanism, which is cheap to implement (reading systems) and easy to incorporate in a production workflow (the additional metadata entry can actually be automated, or be part of a template). In the spirit of compromise, I would however be happy to consider removing the option for authors to define a class name on a per-content-document basis (i.e. only allow publication-wide class name).
>
> The proposal is also non-intrusive with respect to already-published iBooks content, in the sense that existing material based on the draft version of EPUB3 will still work when the iBooks reading system is updated to support the final, approved EPUB3 specification. This is because in the absence of media overlay "class name" metadata, the CSS styling of "active" elements becomes implementation-dependent. In the case of Apple iBooks, this would mean using the "-epub-media-overlay-active" class, so old content would still work.
Casey Dougherty
Casey
Daniel Weck
Using CSS selectors based on fragment identifiers and multiple
classes, changing the ".active" style depending on document context is
pretty straight-forward. The single package metadata entry is a neat
solution.
The 48h clock is still ticking.
Cheers, Dan