In no case do we return a parse tree node for a construct that is not well-formed in isolation, and when parsing a group of items (a selector list or declaration group), we discard when not doing so would cause more styles to apply. E.g. in a, b##id, p { color: blue; color::red } we throw away the b##id instead of turning it into b since that would result in more styles being applied. We throw away color::red since it is not well-formed in isolation. We don't need to throw away anything else, since we assume properties are disjoint, and selectors in a comma list are disjoint. The result after discarding malformed content is a, p { color: blue }.
When we expect a token that is not there in tolerant mode, we report an error and proceed to the next token that signals the start of a similar chunk or the end of the containing block. Usually this means finding the next ; or }.
E.g. in {@code color red; background-color: blue} we expect a :after color but since none is forthcoming, we skip to the semicolon and start parsing the background color property.
Mismatched curly brackets are harder to deal with, so those are handled in the outer loops.
We employ several recovery strategies when we encounter a parsing problem.
All ignored tokens not specified in CSS2.1 as ignorable must be reported. We only apply the error recovery strategies where we make a decision about how to proceed. So the functions that parse list items and parts of list items return {@code null} to indicate a tolerable failure, and the functionsthat parse lists of list items will examine their return values, and apply one of the recovery strategies. The recovery strategies are written to make sure that they enqueue a message if the malformed construct contained tokens.
All the parsing functions below should obey these conventions
This class parses a few extensions to the CSS grammar.
The star hack described in the wiki article is very widely used, and we handle it by adding a new type node type: {@link CssTree.UserAgentHack}which has a set of user agent IDs, and the node that would be visible to those user-agents. Clients that care about filters can transform the tree to remove inappropriate filters, or to transform the tree so that those filters will be visible in only the appropriate contexts using CSS.
If you want extra paranoia, turn on paranoidStringCheck, which will throw an exception when it encounters strings with colons in; then the only risk is something that includes, and specifies the type of, HTML, XML or XSL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|