radkovo / jstyleparser Goto Github PK

We're integrating jStyleParser and when running hundreds of HTML parse tests, i get a StackOverflowError exception when analyzing a specific stylesheet. I have the HTML but i cannot attach it to this issue so i can send it upon request.

Stack trace:
java.lang.StackOverflowError at __randomizedtesting.SeedInfo.seed([CDDE6B651FEC8B45:8F931EECCE17E8E5]:0) at java.lang.String.indexOf(String.java:1503) at java.lang.String.split(String.java:2338) at java.lang.String.split(String.java:2422) at cz.vutbr.web.csskit.ElementMatcherSafeCS.elementClasses(ElementMatcherSafeCS.java:46) at cz.vutbr.web.domassign.Analyzer.assignDeclarationsToElement(Analyzer.java:256) at cz.vutbr.web.domassign.Analyzer$2.processNode(Analyzer.java:214) at cz.vutbr.web.domassign.Analyzer$2.processNode(Analyzer.java:211) at cz.vutbr.web.domassign.Traversal.levelTraversal(Traversal.java:53) at cz.vutbr.web.domassign.Traversal.levelTraversal(Traversal.java:58) at cz.vutbr.web.domassign.Traversal.levelTraversal(Traversal.java:58) .....

I narrowed it down to two stylesheets on the specific page, but when loading those stylesheets in other HTML pages, the error didn't show up.

These are not yet standardised, but unofficially supported by all browsers since a long time.

For a blast from the past, this article is a good read.

Use-case

In the browser, when the mouse is hovered over an element, we need to find out whether that element has a hover style and then invalidate the layout+renderer accordingly.

Question

Is there a good / optimal way to do this? If not, can it be added?

Suggestion

One way could be: the analyser has an API that returns a list of applicable rules for an element. The caller can then walk the rules to see if any rule depends on a specified pseudo-element and hence requires invalidation.

tab-size property is still in draft stage (CSS Text Level 3), but is already implemented in all browsers (except IE).

Just recording it here, for completeness.

I am not sure if the bug title is correct, but this test doesn't work:

http://test.csswg.org/suites/css2.1/20110323/html4/shand-border-000.htm

(the border color is not green).

The border property is defined with a short hand:

border: medium solid;

It looks like the border-color should be inferred as initial and then get assigned to the color of the element, which is set to green.

It is possible that we are not calling the analyser correctly in gngr, but I thought I would check with you first, since it seemed more probable in this case that it's an issue in jStyleParser.

Note that there are five more tests in similar vein here:
http://test.csswg.org/suites/css2.1/20110323/html4/chapter-1.html

.. but they work fine. Only the border one fails.

Test case

The z-index of div2 is specified as -2147483649. jStyleParser doesn't put any z-index value in corresponding nodeData.

If I understand right, when the z-index is lower than the minimum value, it should get clipped to the minimum value.

Although this might seem like a rare edge-case, I think this might be used not-so-rarely in real websites, to ensure that some element is always rendered behind others.

Current jStyleParser version still does not support arbitrary strings as 'list-style-type' values...

I have added some code to implement this, and it is available in the https://github.com/s-n-ushakov/-forked--radkovo--jStyleParser/tree/jstyleparser-2.1-usn-upstream branch, 2c39c891fc80047e216ab1f2543037547a694ea5 commit.

To be frank, I am not sure whether adding string("") was the the right approach to extending enum ListStyleType in interface CSSProperty, so please feel free to adjust it if necessary.

I am also not sure whether the genericTerm() call that I added to class DeclarationTransformerImpl does anything really meaningful, but that was my best effort at my level of understanding of the API available... :)

And unfortunately I got this amendment combined in one branch with another amendment that addresses the issue of getting the project built under Java 8 in pom.xml , please see commit be85374849fc1cc0eb0e69066a87c96d63789a13.

So please have a look and advise if that makes sense and whether my pull request is necessary.

And in case all these amendments deserve a merge, then there is one more commit to take care of stripping my stray comments off...

Cheers,
Sergey

jStyleParser is a quite useful tool and am very happy that it exists. Have been playing with it and learning a lot. Thanks!

That said, I did notice an interesting and potentially significant bug.

It seems in some cases, jStyleParser evaluates CSS classes based on the order they are in and can miss if an element has multiple classes that modify the same property.

I researched it a bit and found that the order of the classes should not matter, rather it should go by which style rule comes later in the .css file.

For instance, let’s say you have <div class ="red blue">. The red CSS style has {color:red;} and the blue has {color: blue;}. As is, the div will always be parsed as being red because it came first.

But the correct interpretation is, I believe, that it should be blue if the blue style rule comes later in the css.

This can be particularly significant with widths as shown below in a test case I came up with:

HTML file

<html lang="en"> 
<head>
<link rel="stylesheet" type="text/css"  href="/testing/test.css">
</head>
<body>
<div class = "coltypea coltypeb"> Lorem ipsum <p class = "blue red"> test</p></div>
</body>
</html> 

CSS File

.coltypea {width: 90%;}
.coltypeb {width: 10%;}
.red {font-size: 50px;}
.blue{font-size:12px;}

With this code, the potential bug can be seen in that both Firefox and Chrome interpret the width of the <div class = "coltypea coltypeb"> element to be 10% as that definition comes later in the CSS.

jStyleParser, however, seems to think that element has a width of 90%.

Not sure if it matters, but I am using TagSoup instead of NekoHTML to parse the HTML code.

css>>>

.a .b:not(:first-of-type):before{color:#FFF}a:hover{color:red}*{color:#000}

ParserDemo.java
print>>>

#of rules parsed: 2
Selectors: [a:hover]
Declarations:
  Property: color
  Values: 
    #ff0000
Selectors: [\*]
Declarations:
  Property: color
  Values: 
    #000000

gradle:
'net.sf.cssbox:jstyleparser:1.23'
code:

            StyleSheet style = CSSFactory.parseString(css, null);

            //obtain the number of rules
            System.out.println("#of rules parsed: " + style.size());
            //go through the rules
            for (RuleBlock<?> rule : style) {
                if (rule instanceof RuleSet) {
                    RuleSet set = (RuleSet) rule;
                    System.out.println("Selectors: " + Arrays.asList(set.getSelectors()));
                    System.out.println("Declarations:");
                    for (Declaration decl : set) {
                        System.out.println("  Property: " + decl.getProperty());
                        System.out.println("  Values: ");
                        for (Term<?> term : decl)
                            System.out.println("    " + term);
                    }
                } else if (rule instanceof RuleMedia) {
                    RuleMedia media = (RuleMedia) rule;
                    System.out.println("Media: " + media.getMediaQueries());
                    for (RuleSet set : media) {
                        //process similarly to the RuleSet processing above
                        System.out.println("  Rule: " + set);
                    }
                } else {
                    //other rules such as @page, @viewport etc.
                    System.out.println("Other rule " + rule);
                }
            }

Thanks for your job!

CSSFactory contains a method registerDeclarationTransformer. However, this method is unusable, because it expects an instance of DeclarationTransformer, which is effectively a final class: It only contains one constructor, which is private.
If the user should be able to register his own DeclarationTransformer, either a DeclarationTransformer interface has to be introduced (similar to SupportedCSS), or the constructor needs to be changed to protected.

There are about 32 tests which depend on this:

border-bottom-width: -0ex;

The above should be parsed as valid CSS and hence appear in the node data. Currently it is parsed as invalid, which effectively means the property gets the value "initial" which then computes to non-zero in some circumstances.

Variations of this test include: -0em, -0in, -0mm, -0cm, -0pc, -0pt, -0px.

I guess this also applies to all length specifications: margin, padding, etc. But haven't found their corresponding tests.

Processing this code:
<html><head><style type='text/css'>td:has(.servNoPad) { padding:0px !important; }</style><body></body></html>

I get this NPE:
java.lang.NullPointerException at cz.vutbr.web.csskit.antlr4.CSSParserVisitorImpl.visitSelpart(CSSParserVisitorImpl.java:1254) at cz.vutbr.web.csskit.antlr4.CSSParserVisitorImpl.visitSelector(CSSParserVisitorImpl.java:1217) at cz.vutbr.web.csskit.antlr4.CSSParserVisitorImpl.visitCombined_selector(CSSParserVisitorImpl.java:1139) at cz.vutbr.web.csskit.antlr4.CSSParserVisitorImpl.visitRuleset(CSSParserVisitorImpl.java:662) at cz.vutbr.web.csskit.antlr4.CSSParserVisitorImpl.visitStatement(CSSParserVisitorImpl.java:282) at cz.vutbr.web.csskit.antlr4.CSSParserVisitorImpl.visitStylesheet(CSSParserVisitorImpl.java:241) at cz.vutbr.web.csskit.antlr4.CSSParserFactory.parse(CSSParserFactory.java:206) at cz.vutbr.web.csskit.antlr4.CSSParserFactory.parseAndImport(CSSParserFactory.java:147) at cz.vutbr.web.csskit.antlr4.CSSParserFactory.parse(CSSParserFactory.java:72) at cz.vutbr.web.csskit.antlr4.CSSParserFactory.parse(CSSParserFactory.java:93) at cz.vutbr.web.css.CSSFactory.parse(CSSFactory.java:500)

Proposing this to be used for actually doing something with @font-face rules: registering custom fonts with AWT (see: radkovo/CSSBox#42).

E.g.:

public interface RuleFontFace extends RuleBlock<Declaration>, PrettyOutput
{
    public String getFontFamily();
    public URL getSource();
    // etc.
}

A few more tests that check for invalid CSS, such as:

div {
    background: red;
    height: 1in;
    width: 0;
    width: -1px;
}

Here, the node-data should show a width of 0, instead of -1px.

Tests affected:

• xhtml1/width-001.xht
• xhtml1/height-001.xht

Hi,
i would like to use jStyleParser to parse my css file. This file contains some browser specific attributes which are currently non-standard. Is there a simple way to extend jStyleParser to allow these attributes?

Quoting from CSS3-color spec:

CSS1 introduced the ‘transparent’ value for the background-color property. CSS2 allowed border-color to also accept the ‘transparent’ value. The Open eBook(tm) Publication Structure 1.0.1 [OEB101] extended the ‘color’ property to also accept the ‘transparent’ keyword. CSS3 extends the color value to include the ‘transparent’ keyword to allow its use with all properties that accept a value. This simplifies the definition of those properties in CSS3.

Some of the CSS tests depend on it. For example, this test

Currently, jStyleParser doesn't recognize transparent as a value in the node data; it has to be accessed as a property. I am not sure if this is intentional; but I think it causes unnecessary overhead: because the client code has to first try getting a value, and if null, then try getting the property. I can see a noticeable slowdown (30%) in the tests.

Hello,

I don't know if it is a bug or that the calc function is just not supported yet. But the calcfunction is not being parsed, if it is used, the whole rule set is ignored. It looks like it is the only function which is not working since functions like linear-gradient do work correct.

So this whole ruleset will be ignored.
.background2 { width: calc(100% - 100px); background: linear-gradient(red,yellow,blue); }

And this one will work.
.background2 { background: linear-gradient(red,yellow,blue); }

Regards,
Nico

As per this test

          div {
              color: rgb(100%, 0, 0);
          }

is not a valid color rule.

Expected behavior when localizing the style sheets is that the the Media queries would be inserted as well. What's occurring is that during the localization, the iteration is checking to determine if the item in the stylesheet is an instanceof RuleSet. Media queries are defined as a RuleMediaImpl instance and are not added.

Goal

Currently, jStyleParser starts fetching from the network whenever it sees @import rules.

However, in gngr, we need network connections to be handled in the browser core. Reasons:

• the browser maintains a network cache which can be utilised for the CSS requests
• the browser has a request manager to control which network requests are allowed
• the browser needs to maintain separate connection pools for separate trust zones

Ideas

I initially thought that it would be best if jStyleParser only did the parsing and returned @import rules in the AST. The browser would initiate the request and call the parser again.

However, I think a simpler way would be to pass a callback function to jStyleParser which the parser can call whenever it needs to make a network request. The actual request will then be processed/filtered/logged in the browser and the response will be handed back to the parser.

An example API could be:

public Interface NetworkProcessor {
  // fetches a URL and returns the response as a String.
  // On error, returns null
  public String fetch(URL url);
}

public Class CSSParserFactory {
  public parse(String css, blah blah, NetworkProcessor processor) {
  }
}

If you like, we could also probably use something like java.net.URLStreamHandler, but I haven't fully thought about that interface.

Why

I was profiling gngr, looking at memory allocations. Specifically, I was profiling the browser in interaction mode (after CSS parsing and layouting is done). For example, I open reddit.com, let the browser fully load all resources, finish JS loading, etc. I then start the profiler and hover the mouse over different elements to check the response times.

For such a profile, the largest allocations happen in AnalyserUtil.hasPseudoSelectorForAncestor in the inner for loop. The allocations are for creating an iterator for the list of selectors!

Suggestion

If an array is used to store the selectors, then the memory pressure drops significantly. It requires changing just a couple of lines of code. (However, the unit tests require more changes).

Using Arrays may also help in the future, when value types land in Java.

Arrays used to be a little cumbersome to use, but with the new streams APIs (Arrays.toStream()) and lambda support in Java 8, it is not so bad.

If you are fine with this. I can help make the changes, and send a PR.

After the hover optimisations, we have code like this in gngr:

  if (!mouseOver) {
    elementMatchCondition.addMatch(ancestor, PseudoDeclaration.HOVER);
  }
  final boolean hasMatch = descendent.hasHoverStyle(ancestor);
  if (!mouseOver) {
    elementMatchCondition.removeMatch(ancestor, PseudoDeclaration.HOVER);
  }
  if (hasMatch) {
    descendent.informLocalInvalid();
  }

This is because we want to make just one DOM pass, but different calls require different match conditions. The hasHoverStyle check requires the HOVER while the informLocalInvalid require HOVER to be absent.

If I could clone the MatchingCondition, my code will get simplified, and optimised:

// outside the DOM walk
originalMatchCondition = elementMatchCondition.clone();
originalMatchCondition.addMatch(ancestor, PseudoDeclaration.HOVER);

...
  // inside the DOM walk
  final boolean hasMatch = descendent.hasHoverStyle(ancestor, originalMatchCondition);
  if (hasMatch) {
    descendent.informLocalInvalid();
  }

I will send a PR for this soon, assuming you are okay with this change.

Testcase: xhtml1/uri-012.xht

CSS:

   p {
        background: red url( { test ); border: solid green; }

Node-data has no border-*-* properties.

I am not sure if this needs to be in jStyleParser; but it seems relevant. Would like to know your thoughts on this. Thanks!

The CSS DOM API allows querying the short hand form of a property, even when it is not directly specified. There are two types of behaviour:

1. In JS, element.style.background returns the background as specified in the style attribute.
2. In JS, getComputedStyle(element).background returns the short form of the computed background, even if only long forms are specified.

It would be nice to have some support for this from jStyleParser (in the form of static utility methods). The wiring to JS land can be done on the client side of course.

If a selector has both :before and :after then it should be rejected. For example:

#id:before:after {
}

The selector should be rejected. I am not sure if the whole rule gets rejected (probably not).

Test-case: https://test.csswg.org/suites/css21_dev/nightly-unstable/xhtml1/before-after-001.xht

Hello,
I think i found a bug on parsing css string containing html code, with animation delay rule set up with negative value.
Html code:

<html>
    <head>
        <style> 
            div {
                animation-delay: -1s;
                text-align: center;
            }
        </style>
    </head>
    <body>
        <div></div>
    </body>
</html>

When i parse it, only text-align rule is parsed.

Java code:

StyleSheet stylesheet = CSSFactory.parseString(css, null);
for (Rule<?> rule : stylesheet) {
            if (!(rule instanceof RuleSet)) {
                continue;
            }
            RuleSet ruleset = (RuleSet) rule;
            System.out.println("ruleset:" + ruleset);
        }

Note: using positive numbers or zero in animation delay, the rule block is correctly created.

I used 2.1 version.

The CSS parser uses the static CSSParser.getAutoImporMedia() to decide when to follow import rules.

This is not ideal, because we can't process CSS from different contexts simultaneously (say different tabs having different dimensions).

It would be nicer if the auto-import spec can be specified as an argument to the parse method, or an instance variable of the CSSParser.

Thanks,
HRJ

Hello,

I am currently trying out the jStyleParser and I like it very much. I have two questions though.

1. Are you going to support CSS animations? If yes, any idea when this will be released?
2. Why is RuleImport deprecated?

Regards,
Nico

When parsing the following CSS rules:

input[type=range]::-webkit-slider-runnable-track { ... }
input[type=range]::-webkit-slider-thumb { ... }
input[type=range]::-moz-range-track { ... }
input[type=range]::-moz-range-thumb { ... }
input[type=range]::-ms-track { ... }
input[type=range]::-ms-thumb { ... }

The parser gives the following error:

[main] ERROR cz.vutbr.web.csskit.antlr4.CSSParser - PARSING pseudo ERROR | inserting INVALID_SELPART
[main] ERROR cz.vutbr.web.csskit.antlr4.CSSErrorListener - CSSErrorListener syntaxError | extraneous input '-' expecting {INVALID_SELPART, CLASSKEYWORD, HASH, ':', ',', '>', '{', '[', '~', '+', S}
[main] ERROR cz.vutbr.web.csskit.antlr4.CSSParser - PARSING selector ERROR | inserting INVALID_SELECTOR

Resulting in these rules being excluded from the stylesheet.

While these pseudo-elements are non-standard and not on a standards track (according to MDN), they are nonetheless used in practice (Source 1, Source 2). As such, it would be nice to have support for them.

Flex-box layout has reached candidate recommendation stage and is supported by most browsers.

We are planning to support it in gngr.

Currently, none of the properties seem to be supported in jStyleParser.

@radkovo any plans for supporting this? It's been a long time since I looked at this code; is it possible to support these properties as strings, to begin with?

Hello,
I'm trying to use this library on Android but unfortunately we cannot use java.awt.Color and the current version 3.0 will crash when parsing a stylesheet with colors:
NoClassDefFoundError: Failed resolution of: Ljava/awt/Color;
Is there any way to make this library independent on java.awt.* classes?

Also regarding the License: If we can fix the above issue, would it be okay to use this library in a commercial, closed-source application? We would of course mention and link to your site in our information screen.

For example, the position property is case-sensitive. If it is specified with the following rule:

div {
  Position: relative;
}

Then it is not recognized.

However, other properties are correctly parsed such as baCkGrounD.

CSS:

html { font-family: 'Ahem' }
p { font-family: serif }

HTML:

<html>
<p>Test</p>
</html>

The p element doesn't get font-family:serif.

Apropos this test:

   p:invalidPseudoClass, p.test1 { color: yellow; background: red; }

The whole rule should be discarded, but it doesn't.

Found this from a w3c test:

            #1digit
            {
                color: red;
            }

This selector shouldn't be applied because it begins with a digit. Note that 1digit is a valid id in DOM, but not in CSS.

I have this issue with the Analyzer evaluateDOM() behavior.

When evaluating a class expression where there are multiple similar class names, only the first occurrence of the "similar" class name is considered. The returned StyleMap will not contain the style attributes of the later occurrences.

Here is an example:

<html>
<head>
<style>
.abc {
    background-color: blue;
}

.abcd {
    color: yellow;
}
</style>
</head>
<body>

<h1 class="abcd abc">Some text</h1>

</body>
</html>

The "abc" class will be completely ignored. Text background will not be applied.
I suspect the issue is that "abc" is a sub-string of "abcd", but I do not know whether this is a bug or not.

Hi,
I was testing a website which uses Bootstrap CSS 3.3.4 minified version, and I got the following exception:

Caused by: org.antlr.runtime.tree.RewriteEmptyStreamException: rule terms
    at org.antlr.runtime.tree.RewriteRuleElementStream._next(RewriteRuleElementStream.java:158)
    at org.antlr.runtime.tree.RewriteRuleElementStream.nextTree(RewriteRuleElementStream.java:145)
    at cz.vutbr.web.csskit.antlr.CSSParser.media_expression(CSSParser.java:2991)
    at cz.vutbr.web.csskit.antlr.CSSParser.media_term(CSSParser.java:2763)
    at cz.vutbr.web.csskit.antlr.CSSParser.media_query(CSSParser.java:2628)
    at cz.vutbr.web.csskit.antlr.CSSParser.media(CSSParser.java:2473)
    at cz.vutbr.web.csskit.antlr.CSSParser.atstatement(CSSParser.java:1430)
    at cz.vutbr.web.csskit.antlr.CSSParser.statement(CSSParser.java:908)
    at cz.vutbr.web.csskit.antlr.CSSParser.stylesheet(CSSParser.java:786)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory$SourceType$2.getAST(CSSParserFactory.java:78)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory$SourceType.encapsulateException(CSSParserFactory.java:191)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory$SourceType.access$100(CSSParserFactory.java:39)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory$SourceType$2.getAST(CSSParserFactory.java:84)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory.feedParser(CSSParserFactory.java:387)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory.createTreeParser(CSSParserFactory.java:354)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory.parseAndImport(CSSParserFactory.java:322)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory.parse(CSSParserFactory.java:226)
    at cz.vutbr.web.csskit.antlr.CSSParserFactory.parse(CSSParserFactory.java:253)

I hope the stack trace is sufficient to help you find the problem. Let me know if you need more info.

I just did some performance eval with this library and the TypeMapper creation dominates my sampling (which could deceive me). Maybe it could be created in CSSTokenFactory retained there and passed to the CSSToken constructor instead of the constructor of CSSToken creating one for itself each time.

TypeMapper seems to be immutable once constructed anyway.

Single quote characters appearing in an unquoted URI need to be escaped with a backslash so that the resulting URI value is a URI token.

Test-case: xhtml1/uri-005.xht

CSS:

            p
            {
                color: white;
                background: red url(support/\'green\ block.png);
            }

In node data: background-image: url('support/\'green block.png');

I am logging this as an issue here because the space character is being escaped correctly. So, escaping the quote character need not be very different, I guess.

MediaSpecNone still matches empty media queries, despite being labelled as the media spec "that does not match to any media query and expression."

Hello! There are too many output logs with styles. Could you turn it off? Or may be make some parametr that will turn log off. Specially too many logs in
cz.vutbr.web.csskit.antlr4.SimplePreparator.class
and
cz.vutbr.web.domassign.DeclarationTransformer.class.
I can't even watch my logs because there are thounds of lines

Currently, font-weight declarations are parsed successfully. However, when trying to write the parsed CSS to a file, these declarations are printed as floats (e.g. font-weight: 400.0) which is ignored by several modern browsers. I believe these need to be printed without the .0 in order for the browser to correctly interpret them.

Html containing <br> tags are modified as you would expect it for every other html tag.

<br>

is modified to

<br style=""></br>

Browsers treat <br> (always) like a line break.
The resulting document thus contains two line breaks.

Switching from 2.1 to 3.1, I noticed that quote inside css rules are not rightly converted.
Code:
<style> .myclass { background:url('my&quot;img.gif'); } </style>

In 2.1 the result was:
<div style="background: url('my&quot;img.gif');" id="ref1" class="myclass" ></div>
In 3.0 >=:
<div style="background: url('my\&quot\;img.gif');" id="ref1" class="myclass" ></div>
It seems it are not able to convert quotes anymore.

To reproduce:
Attempt to parse and print
margin: 2px 0 0 0
Expected Result:
margin: 2px 0 0 0
Actual Result:
margin: 2px000

One of the CSS2.1 test-suite has the following style code:

   #inner { background: white;
               border: 20px solid;
               border-color: #FCFCFC; #FCFCFC; #FDFDFD #FCFCFC;
               }

jStyleParser discards the whole rule, whereas other browsers recognize all three properties.

The method String.toLowerCase is used at multiple places in the code, and gets called a lot of times.

Sometimes, these calls are avoidable. For example, when a selector stores a class name, it can convert the class name to lower-case when the string is stored, rather than when the string is being matched.

Caveats

We have to be careful in this conversion, because the compiler can't check whether we are doing the right thing. In a way, the current implementation is more robust because it always calls .toLowerCase() and the logic is easy to understand.

One way out of this could be to follow a naming convention. Whenever a string is stored as lower-case, the field name can indicate that. For example, instead of defining a field called className we can define it as classNameLC. (LC == Lower Case)

Side-note

The attributes in DOM specs are case-sensitive, while the selector names in CSS spec are insensitive in quirks mode. In fully-standard compliant mode, the selectors in CSS are supposed to be case-sensitive.

It might be possible to take a stand and make the entire library fully-standards compliant, and thus avoid the conversions to lower case entirely.

Side-note 2

There is a new selector in Selector Level 4 Spec, which explicitly defines a case-sensitive selector (even if the User agent is in quirks mode).

When adding new tests and new HTML pages i suddenly got a reproducable NPE:

java.lang.NullPointerException at cz.vutbr.web.domassign.AnalyzerUtil.classifyRules(AnalyzerUtil.java:455) at cz.vutbr.web.domassign.AnalyzerUtil.classifyAllSheets(AnalyzerUtil.java:145) at cz.vutbr.web.domassign.Analyzer.classifyAllSheets(Analyzer.java:414) at cz.vutbr.web.domassign.Analyzer.assingDeclarationsToDOM(Analyzer.java:202) at cz.vutbr.web.domassign.Analyzer.evaluateDOM(Analyzer.java:135)

This happens if null is passed to the constructor of Analyzer. This is not a big deal but it took me a little while to spot the problem.

Hi,

I think I found issue with style inheritance of elements.

I have the similar html structure to the following:

<ul>
<li>
<a style="font-size: 15px">
<span class="a"></span>
</a>
</li>
<li>
<a>
<span></span>
</a>
</li>
</ul>

When trying to get the style of a including inherit, I don't receive the font-size.

I think the issue is with levelTraversal in org.w3c.dom.traversal.TreeWalker.Traversal:

When going over the children of a node the current node won't update until you do over the deepest node in the branch.

This becomes a problem when using:
main.inheritFrom(result.get((Element) walker.parentNode(), null));
(Analyzer, line 155)

(Element) walker.parentNode() return the ul element
So the element styling is incorrect.

Hope you understood me and thank you

Thanks for the great CSS parser tool, it has been very helpful for me in loading and analyzing websites.

That said, there is a slight issue I've noticed.

For some websites, jStyleParser can take a significantly long time to load stylesheets (getUsedStyles()) and create a DOM Analyzer.

For http://www.slate.com for instance, it takes more than 15 seconds to process the page. https://www.hackerrank.com/ is another site which takes a while, though not as slow.

There may be some bottleneck in the code causing these load times.

(As a note, I am adding an HTTP request header to my URL load requests as otherwise many websites won't load.)