CSS-SAC
view release on metacpan or search on metacpan
sub new { return bless [], __PACKAGE__; }
sub warning { warn "[warning] $_[1] (line " . (caller)[2] . ")"; }
sub error { warn "[error] $_[1] (line " . (caller)[2] . ")"; }
sub fatal_error { die "[fatal] $_[1] (line " . (caller)[2] . ")"; }
# #
# #
### Default Error Handler #############################################
1;
=pod
=head1 NAME
CSS::SAC - SAC CSS parser
=head1 SYNOPSIS
use CSS::SAC qw();
use My::SACHandler ();
use My::SACErrors ();
my $doc_handler = My::SACHandler->new;
my $err_handler = My::SACErrors->new;
my $sac = CSS::SAC->new({
DocumentHandler => $doc_handler,
ErrorHandler => $err_handler,
});
# generate a stream of events
$sac->parse({ filename => 'foo.css' });
=head1 DESCRIPTION
SAC (Simple API for CSS) is an event-based API much like SAX for XML.
If you are familiar with the latter, you should have little trouble
getting used to SAC. More information on SAC can be found online at
http://www.w3.org/TR/SAC.
CSS having more constructs than XML, core SAC is still more complex
than core SAX. However, if you need to parse a CSS style sheet, SAC
probably remains the easiest way to get it done.
Most of the spec is presently implemented. The following interfaces
are not yet there: Locator, CSSException, CSSParseException,
ParserFactory. They may or may not be implemented at a later date
(the most likely candidates are the exception classes, for which I
still have to find an appropriate model).
Some places differ slightly from what is in the spec. I have tried to
keep those to a justified minimum and to flag them correctly.
=head2 the CSS::SAC module itself
The Parser class doesn't exist separately, it's defined in CSS::SAC.
It doesn't expose the locale interface because we don't localize
errors (yet). It also doesn't have C<parse_style_sheet> but rather
C<parse>, which is more consistent with other Perl parsing interfaces.
I have added the C<charset($charset)> callback to the DocumentHandler
interface. There are valid reasons why it wasn't there (it can be
trusted only ever so often, and one should look at the actual encoding
instead) but given that it's a token in the grammar, I believe that
there should still be a way to access it.
=head1 METHODS
=over 4
=item * CSS::SAC->new(\%options) or $sac->new(\%options)
Constructs a new parser object. The options can be:
- ConditionFactory and SelectorFactory
the factory classes used to build selector and condition objects.
See CSS::SAC::{Condition,Selector}Factory for more details on the
interfaces those classes must expose.
- DocumentHandler and ErrorHandler
the handler classes used as sinks for the event stream received
from a SAC Driver. See CSS::SAC::{Document,Error}Factory for more
details on the interfaces those classes must expose.
Methods will be called on whatever it is you pass as values to those
options. Thus, you may pass in objects as well as class names (I
haven't tested this yet, there may be a problem).
NOTE: an error handler should implement all callbacks, while a document
handler may only implement those it is interested in. There is a default
error handler (which dies and warns depending on the type of error) but
not default document handler.
=item * $sac->ParserVerion or $sac->getParserVerion
Returns the supported CSS version.
Requesting this parser's ParserVersion will return the string 'CSS3'.
While that is (modulo potential bugs of course) believed to be
generally true, several caveats apply:
To begin with, CSS3 has been modularised, and various modules are at
different stages of development. Evolving modules may require evolving
this parser. I hesitated between making ParserVersion return CSS2,
CSS3-pre, or simply CSS3. I chose the latter because I intend to
update it as I become aware of the necessity of changes to accommodate
new CSS3 stuff, and because it already supports a number of constructs
alien to CSS2 (of which namespaces is imho important enough to justify
a CSS3 tag). If you are aware of incompatibilities, please contact me.
More importantly, it is now considered wrong for a parser to return
CSSx as its version and instead it is expected to return an uri
corresponding to the uri of the CSS version that it supports. However,
there is no uri for CSS3, but instead one uri per module. While this
issue hasn't been resolved by the WG, I will stick to returning CSS3.
However, B<the behaviour of this attribute is certain to change> in
the future, so please avoid relying on it.
( run in 0.618 second using v1.01-cache-2.11-cpan-ceb78f64989 )