:media-overlay-active
Edward O'Connor
While reviewing the Media Overlays spec[1], we encountered the
:media-overlay-active pseudoclass in § 3.4 Associating Style
Information[2]. Does this pseudoclass originate with the Media Overlays
spec, or is it defined somewhere else and merely referenced here? I
couldn't find a pointer to a CSS spec draft containing such a
pseudoclass.
I wonder about the implementability of this pseudoclass in some Reading
Systems. Consider, for instance, a hypothetical Reading System
implemented in JavaScript running inside an off-the-shelf Web engine
such as Gecko or WebKit. Such a Reading System could emulate the
functionality of :media-overlay-active using HTML5's Timed Track API.
The catch is, the CSSOM doesn't provide access to CSS rules using
pseudoclasses unknown to the Web engine, nor do these engines usually
provide the ability for authors to define arbitrary pseudoclasses. This
problem exists for other classes of Reading Systems as well.
Also, is :media-overlay-active an invention of EPUB? If so, is there any
intent to define it within the CSS WG? Either way, shouldn't it gain an
-epub prefix, and be :-epub-media-overlay-active?
Ted
1. http://epub-revision.googlecode.com/svn/trunk/build/30/spec/epub30-mediaoverlays.html
2. http://epub-revision.googlecode.com/svn/trunk/build/30/spec/epub30-mediaoverlays.html#sec-docs-assoc-style
Marisa DeMeglio
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
Daniel Weck
system implementors can emulate the pseudo-class by pretending that
this is just a normal CSS class, and by directly manipulating the
class attribute of elements (to activate/deactivate the highlighting
styles on the fly). I know from experience that JavaScript libraries
like JQuery make this really easy, and the performance penalty not
significant. Daniel
Marisa DeMeglio
this with jQuery. Both have a catch, though - some pre-processing of
the external CSS document's :media-overlay-active style declaration(s)
would be necessary for these examples to work in a real-world
scenario. This pre-processing is necessary as far as I can see,
because:
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
Casey Dougherty
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>
Peter Sorotokin
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
Casey Dougherty
Thanks for your input, Peter.
Casey
Casey Dougherty
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:
Peter Sorotokin
> 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
Peter Sorotokin
------ 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
Daniel Weck
On 20 May 2011, at 05:36, Casey Dougherty wrote:
> 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.
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
likely to lack support for unknown pseudo classes or properties. But
EPUB publications are unzipped into a temporary folder by reading
systems before the content is actually parsed or fed to a processing
agent, so >>sed s/:media-overlay-active/.media-overlay-active/g<<
substitution doesn't sound too far-fetched in my view. Browser-based
reading systems that completely deconstruct the EPUB distribution unit
on the server side (to eventually reconstruct a complete UI for the
client) certainly have this level of control over the content. Dan
Daniel Weck
danie...@gmail.com
Peter Sorotokin
>>>
>>> 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
Peter Sorotokin
------ Forwarded Message
From: Kevin Ballard <kbal...@apple.com>
To: Peter Sorotokin <psor...@adobe.com>
Cc: Casey Dougherty <cdoug...@apple.com>, Al Cannistraro <al...@apple.com>, Daniel Weck <danie...@gmail.com>
Subject: Re: :media-overlay-active
Note: please forward to the epub-working-group.
It looks like we're not making any progress, so I'm going to consider this our final position, and you can make of it what you will.
The problem: The Media Overlays spec defines the :media-overlay-active pseudo-class for use with CSS styling for elements with active media overlays. As it stands, no web rendering engine supports this pseudo-class, nor do they preserve the CSS rule during parsing for later inspection via JavaScript.
The solution that we at Apple would like to implement is a practical one. Namely, get rid of the pseudo-class and use a regular class with a reserved name. The arguments against this solution, as I understand it, are that media-overlay-active should really live exclusively in the presentation layer, and that we shouldn't be reserving any class names at all as they belong to the epub authors.
The solution that seems to be recommended by the epub working group is to customize the web rendering engine in use to support this pseudo-class. I don't understand why the working group considers that at all acceptable. The iBooks group has already been criticized for the suggestion that we are benefiting from being part of the same company that makes the OS and web rendering engine, but it seems that the working group now wants to make it a requirement that the reading system and web rendering system be authored by the same organization. I feel it is obvious why this is a bad idea. It also completely rules out the idea of implementing a reading system completely in-browser using JavaScript.
The two alternative implementable solutions I have heard both involve pre-processing all CSS files and embedded scripts, parsing them with a third-party CSS parser, and extracting the rules using the pseudo-class. The problems common to both these solutions are that they require either intercepting all CSS files or re-downloading all CSS files, and parsing them with a fully-featured CSS parser (I'm not willing to consider a solution using regular expressions - either we parse CSS properly, or not at all). The first solution involves transforming the pseudo-class back into a regular class. The second solution involves storing the style rules elsewhere, and then applying them to the style attribute of the active node when appropriate.
The first such solution raises exactly the same set of issues as using a class to begin with. It also adds an additional problem where scripting content needs to be tailor-written to a browser engine if it wishes to interact with the media-overlay-active styling at all (whether it's merely observing the active element, or adding/modifying style rules). We recognize that scripting is already considered to not be easily cross-platform, but this issue is a step beyond the normal browser-specific quirks, in that the given solution to the media-overlay-active employed by the browser will not even be documented and may not be considered stable.
The second such solution effectively reserves the style attribute for use by Media Overlays, which is a significantly worse problem than reserving specific class names. It also makes it impossible for JavaScript to detect or interact at all with the media-overlay-active styling. It also rules out using any sort of complex selector involving :media-overlay-active.
Have I missed anything?
If or when we at Apple implement this spec, the only two solutions I see us using are either the first JavaScript solution (of transforming the pseudo-class into a regular class), or ignoring the pseudo-class entirely and going with a regular class. I believe that other reading systems are likely to make a similar choice. It would greatly simplify things, and make it far more likely for reading systems to actually implement this spec, if the horribly impractical pseudo-class is forgotten.
The objections to using a regular class are valid objections. But every single alternative seems to be far worse. It just doesn't seem to be practical at all to insist on using the pseudo-class.
I'd also like to respond to a few specific points that weren't covered above.
On May 20, 2011, at 1:00 AM, Peter Sorotokin wrote:
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).
Just because something is possible does not make it a good idea.
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.
Font embedding and hyphenation are part of CSS Fonts and CSS Text, respectively. They are not epub-specific. I don't see why you think we (the iBooks team) are responsible for them.
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.
I disagree that regular expressions are better than nothing. Either parse CSS correctly or don't parse it at all - supporting valid CSS only sometimes, with the exact rules depending on the quirks of your regular expressions, would be a rather serious bug.
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.
There's no reason to deliberately make the situation worse. It's perfectly reasonable for a script to assume that a reading system in compliance with the Media Overlays spec would allow the script to interact with the same CSS rules.
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.
That's not a namespace selector. That's a tag named "foo" using the negation pseudo-class. A similar example that might make this more clear would be '.dropcap:not(:media-overlay-active)', which should match any element with the "dropcap" class that does not have :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.
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).
Why restrict how it's used? It's supposed to be a pseudo-class, and we're supposed to support CSS. Suggesting that you can use the pseudo-class only sometimes, in a very restricted set of rules, seems like a bad idea. We shouldn't be hobbling this feature before it's even out the door.
Marisa DeMeglio
changed the media overlays draft from having a magic-word CSS class
name to having a pseudoclass, and WG members mentioned that reading
systems would be doing some CSS preprocessing anyway, so it wouldn't
really be an additional burden. This also echoes recent comments from
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?
Thanks
Marisa
Peter Sorotokin
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
Brady Duga
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?
William McCoy
Sent from my iPhone