The pseudoclass "media-overlay-active" is a creation of EPUB3 Media
Overlays. Members of the WG felt it was a hack to use a regular CSS
class with a special magic name, and that a pseudoclass would be
better. It was also pointed out that to support EPUB, reading systems
would have to implement (some of?) CSS themselves anyway (I'm not
clear on how much of it RSs have to do on their own), and adding
support for this pseudoclass wouldn't really be an extra burden.
I know that some off-the-shelf javascript libraries, such as MooTools
and jQuery, support something like custom pseudoclasses. However, it
seems that any custom selectors get evaluated on page load, but not
necessarily after that. I'm having a closer look and I'll let you
know what I find.
As for renaming it to "-epub-media-overlay-active", is this commonly
done for custom pseudoclasses? I don't have any issue with it.
Marisa
1. In the first case, the pseudoclass selector style properties don't
trigger the evaluation function unless the style properties are
declared in the script itself.
2. In the second case, adding/removing a class dynamically only works
for proper classes (prefixed by ".", not ":"). This may be a
limitation of jQuery; I haven't tried alternatives.
Have a look at the attached files for details and more comments.
Marisa
Neither of these solutions are in conformance with the spec.
In the first case, you aren't using pseudo-classes. You're using a jQuery construct that is based upon the syntax of pseudo-classes, but really implements filters against the DOM tree and manipulates the style attribute of the elements directly. This is purely a jQuery-ism and, besides the syntax, has nothing to do with pseudo-classes. It also requires defining all styles using javascript.
In the second case, you aren't using pseudo-classes either. You're pretty explicitly using a regular class, and then dressing it up with some jQuery syntax.
Even if you pre-process all CSS in order to transform the :media-overlay-active psuedo-class into a .media-overlay-active class, you still aren't in conformance with the spec as far as javascript is concerned. Any javascript which looks at the resulting CSS rules or tries to integrate with the :media-overlay-active pseudo-class will find that it doesn't exist. And even if you don't care about javascript, it's not reasonable to require all reading systems to pre-process all CSS as text before handing it off to the browser (especially as this includes inline stylesheets, which will require a full-fledged HTML parser distinct from the final web rendering engine in order to extract).
At this point, I think it's safe to say that the spec needs to be changed. I would suggest blessing the usage of the .media-overlay-active class as a replacement for the :media-overlay-active pseudoclass. This is a minimal change, is very easy to implement for reading systems, and is likely to match the compromise already chosen by any reading systems that may have started work on this feature already.
-Kevin Ballard
> <media-overlay-active-pseudoclass.zip>
I think that renaming pseudo-class to -epub-media-overlay-active (or
something shorter, like -epub-mo-active) would be a reasonable thing to do.
However I strongly object against changing it into a real class. CSS classes
are for authors to use and we should not infringe on that. Highjacking a
specific class name would create a dangerous precedent that would be
difficult to eradicate.
Also, if we only limit ourselves with the features that are available in the
browser without much additional work, we will never be able to do any
innovative things in the group. While we do want to align with web
standards, I do not think we ever agreed to cede all control to web
standards groups.
Preprocessing stylesheets is not difficult and I don't find anything
unreasonable about requiring it. They are certainly not hard to find (and
since HTML is not allowed in epub, there is not need to do HTML parsing).
Media overlays is an optional feature and if some Reading Systems cannot
implement that pseudo-class, well, they don't have to.
Peter
Thanks for your input, Peter.
Casey
On May 19, 2011, at 9:06 PM, Casey Dougherty wrote:
> +Kevin. He was not able to email the group, so I sent the email for him. Would be great if you could keep him on the thread going forward.
>
> Thanks for your input, Peter.
>
> Casey
>
>
> On May 19, 2011, at 8:54 PM, Peter Sorotokin wrote:
>
>> Casey,
>>
>> I think that renaming pseudo-class to -epub-media-overlay-active (or
>> something shorter, like -epub-mo-active) would be a reasonable thing to do.
>> However I strongly object against changing it into a real class. CSS classes
>> are for authors to use and we should not infringe on that. Highjacking a
>> specific class name would create a dangerous precedent that would be
>> difficult to eradicate.
I'm not sure we have any reasonable alternative. I'm also not sure it's a bad thing to reserve all class names beginning with a specific prefix (e.g. "-epub").
*Edit: I have another idea, proposed below.
>> Also, if we only limit ourselves with the features that are available in the
>> browser without much additional work, we will never be able to do any
>> innovative things in the group. While we do want to align with web
>> standards, I do not think we ever agreed to cede all control to web
>> standards groups.
Requiring reading systems to customize their html rendering engines is, I think, not practical in the slightest. At a bare minimum, this would completely rule out reading systems implemented in-browser, and it is a significant barrier to entry for other reading systems as well.
I think it's very likely that if the standard requires a custom html engine, reading systems will simply end up in non-compliance and will instead implement a de-facto alternative.
>> Preprocessing stylesheets is not difficult and I don't find anything
>> unreasonable about requiring it. They are certainly not hard to find (and
>> since HTML is not allowed in epub, there is not need to do HTML parsing).
What do you mean, HTML is not allowed in epub? If you're referring to the fact that it's really XHTML, I'm not sure that makes any difference. It still requires using a full-fledged XML parser to parse the entire document, then modify it, and then finally pass it to the HTML engine (which has to re-parse the whole thing).
And regardless of the work required, I do think it's unreasonable to expect the files in an epub to be pre-processed as text before ever being passed to the html engine.
>> Media overlays is an optional feature and if some Reading Systems cannot
>> implement that pseudo-class, well, they don't have to.
The eventual goal of providing a spec is to have other systems implement the spec. It seems to me like you're more concerned with having the spec be "correct" than having it be practical.
*Edit: Another possibility if you really don't want to use CSS classes is to add a new HTML attribute to the tag. This can then be styled using attribute selectors. I would be a bit leery about using this though, as attribute selectors don't have correct namespace support until CSS3 and don't have widespread browser support (or possibly any, I'm not sure). That would mean that, to be practical, the attribute would have to omit the namespace.
-Kevin Ballard
On May 19, 2011, at 8:54 PM, Peter Sorotokin wrote:
> Kevin's Comments inline.
>
> On May 19, 2011, at 9:06 PM, Casey Dougherty wrote:
>
>> +Kevin. He was not able to email the group, so I sent the email for him.
>> Would be great if you could keep him on the thread going forward.
>>
>> Thanks for your input, Peter.
>>
>> Casey
>>
>>
>> On May 19, 2011, at 8:54 PM, Peter Sorotokin wrote:
>>
>>> Casey,
>>>
>>> I think that renaming pseudo-class to -epub-media-overlay-active (or
>>> something shorter, like -epub-mo-active) would be a reasonable thing to do.
>>> However I strongly object against changing it into a real class. CSS classes
>>> are for authors to use and we should not infringe on that. Highjacking a
>>> specific class name would create a dangerous precedent that would be
>>> difficult to eradicate.
>
> I'm not sure we have any reasonable alternative. I'm also not sure it's a bad
> thing to reserve all class names beginning with a specific prefix (e.g.
> "-epub").
Kevin,
I disagree. Class names are simply not for us to define. I don't think
something like that would fly at W3C level, nor I think we should engage in
this.
>
> *Edit: I have another idea, proposed below.
>
>>> Also, if we only limit ourselves with the features that are available in the
>>> browser without much additional work, we will never be able to do any
>>> innovative things in the group. While we do want to align with web
>>> standards, I do not think we ever agreed to cede all control to web
>>> standards groups.
>
> Requiring reading systems to customize their html rendering engines is, I
> think, not practical in the slightest. At a bare minimum, this would
> completely rule out reading systems implemented in-browser, and it is a
> significant barrier to entry for other reading systems as well.
There is no need to customize browser engine, this can be implemented purely
in JavaScript. Or you could customize it - either way would work.
> I think it's very likely that if the standard requires a custom html engine,
> reading systems will simply end up in non-compliance and will instead
> implement a de-facto alternative.
I have no control over browser engine on iPad (moreover, I am prohibited by
Apple to put my customized engine on it) and yet I see a way to implement it
there. You have total control over that engine and yet you are saying it
cannot be customized. I find this weird. If you want to customize it, you
can just go and do it!
>
>>> Preprocessing stylesheets is not difficult and I don't find anything
>>> unreasonable about requiring it. They are certainly not hard to find (and
>>> since HTML is not allowed in epub, there is not need to do HTML parsing).
>
> What do you mean, HTML is not allowed in epub? If you're referring to the fact
> that it's really XHTML, I'm not sure that makes any difference. It still
> requires using a full-fledged XML parser to parse the entire document, then
> modify it, and then finally pass it to the HTML engine (which has to re-parse
> the whole thing).
All you need to do in this case is to find stylesheets in the document which
is already parsed by the browser engine, find rules that use pseudo-class
(yes, it requires parsing) and implement them yourself. Note that this rule
cannot be applied by the CSS engine directly anyway, because you would have
to integrate it with the media playback.
> And regardless of the work required, I do think it's unreasonable to expect
> the files in an epub to be pre-processed as text before ever being passed to
> the html engine.
So what you are saying is that we cannot invent any extensions to CSS. I
strongly disagree with that, it means that this WG is simply a tail on the
W3C dog.
>>> Media overlays is an optional feature and if some Reading Systems cannot
>>> implement that pseudo-class, well, they don't have to.
>
> The eventual goal of providing a spec is to have other systems implement the
> spec. It seems to me like you're more concerned with having the spec be
> "correct" than having it be practical.
First of all, I see this as a very dangerous limit on the scope of this WG
mission. I agree that it has to be practical, but there is nothing really
hard to implement here - especially for Apple that unlike others actually
controls the browser engine.
>
> *Edit: Another possibility if you really don't want to use CSS classes is to
> add a new HTML attribute to the tag. This can then be styled using attribute
> selectors. I would be a bit leery about using this though, as attribute
> selectors don't have correct namespace support until CSS3 and don't have
> widespread browser support (or possibly any, I'm not sure). That would mean
> that, to be practical, the attribute would have to omit the namespace.
Well, we certainly own our namespace and we do already require CSS3
namespaces, but that does not strike me as a good way to express the desired
behavior. Again, this is a hack, something that would not even be considered
at W3C level. Why should we settle for less?
Peter
------ Forwarded Message
From: Kevin Ballard <kbal...@apple.com>
Date: Fri, 20 May 2011 00:01:32 -0700
To: Peter Sorotokin <psor...@adobe.com>
Cc: Casey Dougherty <cdoug...@apple.com>
Subject: Re: :media-overlay-active
Note, I cannot post to the epub-working-group ML, so feel free to re-post
this to the list.
On May 19, 2011, at 11:35 PM, Peter Sorotokin wrote:
>> *Edit: I have another idea, proposed below.
>>
>>>> Also, if we only limit ourselves with the features that are available in
the
>>>> browser without much additional work, we will never be able to do any
>>>> innovative things in the group. While we do want to align with web
>>>> standards, I do not think we ever agreed to cede all control to web
>>>> standards groups.
>>
>> Requiring reading systems to customize their html rendering engines is, I
>> think, not practical in the slightest. At a bare minimum, this would
>> completely rule out reading systems implemented in-browser, and it is a
>> significant barrier to entry for other reading systems as well.
>
> There is no need to customize browser engine, this can be implemented purely
> in JavaScript. Or you could customize it - either way would work.
How would you go about implementing it in JavaScript? I don't know about
other browser engines, but at least WebKit doesn't even preserve the CSS
rules which have unknown selectors (which includes use of unknown
pseudo-classes).
>> I think it's very likely that if the standard requires a custom html engine,
>> reading systems will simply end up in non-compliance and will instead
>> implement a de-facto alternative.
>
> I have no control over browser engine on iPad (moreover, I am prohibited by
> Apple to put my customized engine on it) and yet I see a way to implement it
> there. You have total control over that engine and yet you are saying it
> cannot be customized. I find this weird. If you want to customize it, you
> can just go and do it!
Care to explain how?
I also wonder why you believe we, the iBooks group, have total control over
the WebKit framework that ships with the OS.
>>>> Preprocessing stylesheets is not difficult and I don't find anything
>>>> unreasonable about requiring it. They are certainly not hard to find (and
>>>> since HTML is not allowed in epub, there is not need to do HTML parsing).
>>
>> What do you mean, HTML is not allowed in epub? If you're referring to the
fact
>> that it's really XHTML, I'm not sure that makes any difference. It still
>> requires using a full-fledged XML parser to parse the entire document, then
>> modify it, and then finally pass it to the HTML engine (which has to re-parse
>> the whole thing).
>
> All you need to do in this case is to find stylesheets in the document which
> is already parsed by the browser engine, find rules that use pseudo-class
> (yes, it requires parsing) and implement them yourself. Note that this rule
> cannot be applied by the CSS engine directly anyway, because you would have
> to integrate it with the media playback.
Assuming I'm interpreting you correctly, you're suggesting grabbing all
stylesheets, re-downloading any externally-linked stylesheets to get their
raw text, and implementing a full CSS parser in JavaScript. That is a pretty
big thing to require all reading systems (who wish to support media
overlays) to implement. And I'd argue that it _still_ isn't in conformance
with the spec, as far as scripting is concerned. Any scripts which attempt
to observe or interact with these media-overlay-active styles would simply
not work.
I'm also pretty sure that such a trick would only work on very simple
selectors. Anything more complicated, such as
'foo:not(:media-overlay-active)' or 'foo:media-overlay-active + p` or any
myriad of other selectors, would require a complete re-implementation of CSS
3 Selectors in JavaScript. If anything, this is even less feasible than
requiring all reading systems to implement their own CSS parsers.
-Kevin Ballard
------ End of Forwarded Message
A web-browser -based reading system can easily manipulate the DOM and
the CSS (JQuery or not), so although support for the full-blown pseudo-
class may not be provided per say, from a black-box / functional
testing perspective there do not seem to be any major compliance issue
with EPUB3 Media Overlays. In my view, "supporting" the -epub-media-
overlay-active pseudo class doesn't necessarily mean implementing it
as a *real* pseudo-class. I'd rather be pragmatic about the reality of
implementing innovative specifications, rather than trying to
standardize the ".media-overlay-active" reserved class name
(effectively, a nasty "magic string"), which sounds much more like a
hack to me than pre-processing content in order to handle (clone) the
pseudo-class styles.
As for using a markup attribute: I really think that -epub-media-
overlay-active should stay in the presentation layer (just
like :target, :active, :enabled, :focus, :hover, etc.).
Dan
Daniel Weck
danie...@gmail.com
>>>
>>> Requiring reading systems to customize their html rendering engines is, I
>>> think, not practical in the slightest. At a bare minimum, this would
>>> completely rule out reading systems implemented in-browser, and it is a
>>> significant barrier to entry for other reading systems as well.
>>
>> There is no need to customize browser engine, this can be implemented purely
>> in JavaScript. Or you could customize it - either way would work.
>
> How would you go about implementing it in JavaScript? I don't know about other
> browser engines, but at least WebKit doesn't even preserve the CSS rules which
> have unknown selectors (which includes use of unknown pseudo-classes).
>
You can pre-process style sheets either as you serve them to the browser
engine from your app (media type is marked in manifest) or you can find all
stylesheets by going through DOM (iterate through style elements, if it has
src do XMLHttpRequest).
Then you have to parse it. Granted, doing proper job is not easy, but it is
not terribly hard either, even in JavaScript. (If you really feel like you
need a shortcut, you can use regular expressions - it would work in most
practical cases, but it won't work correctly in all cases, of course).
Again, you could do it in your app code and CSS parser is an off-the-shelf
component these days.
You do not need to filter that pseoudo-class out: CSS rules will ensure that
it will be ignored by the browser engine.
>>> I think it's very likely that if the standard requires a custom html engine,
>>> reading systems will simply end up in non-compliance and will instead
>>> implement a de-facto alternative.
>>
>> I have no control over browser engine on iPad (moreover, I am prohibited by
>> Apple to put my customized engine on it) and yet I see a way to implement it
>> there. You have total control over that engine and yet you are saying it
>> cannot be customized. I find this weird. If you want to customize it, you
>> can just go and do it!
>
> Care to explain how?
>
> I also wonder why you believe we, the iBooks group, have total control over
> the WebKit framework that ships with the OS.
That is perhaps an overstatement, but we do represent our companies here,
not just our groups, so "you" really means "Apple". We aslo have to
represent IDPF to other groups at our companies. So I do treat you Apple
people as representatives of WebKit, iOS, iPad and other things Apple to
some extent here as well. When something EPUB-related is wrong in InDesign,
no one makes a distinction if I work in that group or not. People just say,
why don't you Adobe fix it?
Also you really don't need total control either. I see things like font
embedding and hyphenation appearing in iBooks, so I assume you do have at
least some influence.
>
>>>>> Preprocessing stylesheets is not difficult and I don't find anything
>>>>> unreasonable about requiring it. They are certainly not hard to find (and
>>>>> since HTML is not allowed in epub, there is not need to do HTML parsing).
>>>
>>> What do you mean, HTML is not allowed in epub? If you're referring to the
>>> fact
>>> that it's really XHTML, I'm not sure that makes any difference. It still
>>> requires using a full-fledged XML parser to parse the entire document, then
>>> modify it, and then finally pass it to the HTML engine (which has to
>>> re-parse
>>> the whole thing).
>>
>> All you need to do in this case is to find stylesheets in the document which
>> is already parsed by the browser engine, find rules that use pseudo-class
>> (yes, it requires parsing) and implement them yourself. Note that this rule
>> cannot be applied by the CSS engine directly anyway, because you would have
>> to integrate it with the media playback.
>
> Assuming I'm interpreting you correctly, you're suggesting grabbing all
> stylesheets, re-downloading any externally-linked stylesheets to get their raw
> text, and implementing a full CSS parser in JavaScript. That is a pretty big
> thing to require all reading systems (who wish to support media overlays) to
> implement.
Well, if it is too big, do regular expressions - better than nothing. I
actually have an assumption that to do a good job on the Reading System one
has to have CSS preprocessor somewhere - either on the app side or in the
JavaScript - for many other reasons, so I do not see it as an extra burden.
> And I'd argue that it _still_ isn't in conformance with the spec,
> as far as scripting is concerned. Any scripts which attempt to observe or
> interact with these media-overlay-active styles would simply not work.
This feature targets spine-referenced content. Scripts in this environment
will find a lot of surprises which are bigger than media-overlay-active
preudo-class. That's why we warn that such scripts are not likely to be
interoperable.
> I'm also pretty sure that such a trick would only work on very simple
> selectors. Anything more complicated, such as 'foo:not(:media-overlay-active)'
We do not allow CSS3 selectors beyond CSS namespaces, BTW.
> or 'foo:media-overlay-active + p` or any myriad of other selectors, would
> require a complete re-implementation of CSS 3 Selectors in JavaScript. If
> anything, this is even less feasible than requiring all reading systems to
> implement their own CSS parsers.
That's true. I think it would be very reasonable to limit where
:media-overlay-active can occur. Perhaps Marisa and Daniel could comment on
that. We can either only allow it to occur only standalone or allow it to
only be combined with tag name and class name (i.e. only
:media-overlay-active, foo:media-overlay-active and
.foo:media-overlay-active are allowed, nothing else).
Peter
>
> -Kevin Ballard
You can pre-process style sheets either as you serve them to the browser
engine from your app (media type is marked in manifest) or you can find all
stylesheets by going through DOM (iterate through style elements, if it has
src do XMLHttpRequest).
Also you really don't need total control either. I see things like font
embedding and hyphenation appearing in iBooks, so I assume you do have at
least some influence.
Well, if it is too big, do regular expressions - better than nothing. I
actually have an assumption that to do a good job on the Reading System one
has to have CSS preprocessor somewhere - either on the app side or in the
JavaScript - for many other reasons, so I do not see it as an extra burden.
This feature targets spine-referenced content. Scripts in this environment
will find a lot of surprises which are bigger than media-overlay-active
preudo-class. That's why we warn that such scripts are not likely to be
interoperable.
I'm also pretty sure that such a trick would only work on very simple
selectors. Anything more complicated, such as 'foo:not(:media-overlay-active)'
We do not allow CSS3 selectors beyond CSS namespaces, BTW.
or 'foo:media-overlay-active + p` or any myriad of other selectors, would
require a complete re-implementation of CSS 3 Selectors in JavaScript. If
anything, this is even less feasible than requiring all reading systems to
implement their own CSS parsers.
That's true. I think it would be very reasonable to limit where
:media-overlay-active can occur. Perhaps Marisa and Daniel could comment on
that. We can either only allow it to occur only standalone or allow it to
only be combined with tag name and class name (i.e. only
:media-overlay-active, foo:media-overlay-active and
.foo:media-overlay-active are allowed, nothing else).
Thanks
Marisa
Here is what first comes to mind for us:
- legacy properties and display values (oeb-*** things)
- our own historical extensions (e.g. adobe-hyphenate)
- our layout extensions (PGT and XPGT)
- supporting proper CSS syntax on engines which only allow prefixed
properties
- filtering out properties which are not compatible with pagination (e.g.
absolute positioning)
Not processing CSS simply means you don't have much control.
Of course, MathML is not done by today's browsers too and things like
triggers and custom media type handlers need to be hooked to the vanilla
browser engines.
Peter
So, my question is, since I'm not too familiar with CSS in
EPUB, what are some other EPUB features that, to implement them
correctly, would require a CSS preprocessor in the reading system?