January 23, 2013 at 17:51#26808
Just bumped into this effect two days ago: an “9” MSIE CSS hack on a property with a nummerical value without an unit, such as
probably causes an exception in CSS handling so that the contents of the entire stylesheet in question is being ignored in that PD4ML run.
Other CSS – such as that stated in the HTML document, remains unaffected.
Other forms of that hack
left: 0px9;<br /> position: relative9;
seem to be successfully skipped and the rest of stylesheet used as it should.
Since this seems to be a common MSIE CSS hack and entering position:0 is otherwise legal, which leads to higher danger of such a statement in the stylesheet and misrendering of pages, it’d be nice if this form of the hack could be “supported” too.
Of course, it’s an easy way to avoid the problem (and good practice too) to simply always use units. Still it’s a mistake easily done and hard to find in a large stylesheet.
These are test URLs:
- One that works: http://bit.ly/WLIlbK
- …and one with a small difference… http://bit.ly/VjVwFk
They look the same in web browsers – the difference can be seen in the PD4ML GUI for example.
On a side note – when the shortened URL is called in the GUI, it also delivers the negative answer, even on the OK document (HTML is loaded OK, but attached stylesheet isn’t).
=>Could this be another PD4ML issue – ie. handling URLs with redirects?
When opening the expanded URL in the GUI, they show exactly the effect they should. So please use the expanded URLs for testing.
Note2: It indeed IS an exception, as I noticed in the GUIs console in the process of writing:
java.lang.NumberFormatException: For input string: "09"<br /> at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source)<br />
so maybe the fix wouln’t need to specifically address CSS hacks at all, simply making sure an invalid number won’t send the entire stylesheet crashing down would, as a side effect, solve this issue too 😉
ViktorJanuary 28, 2013 at 17:14#29193
The CSS hack problem can be solved in a third-party open-source library “CSS Parser project”, PD4ML relies on. I took quick a look on it – it is quite simply to suppress the exception, but a correct processing of “0px9” syntax would require to update JavaCC CSS grammar, which is relatively tricky.
JavaCC code edits have another drawback: by .NET port of it we would need to convert not JavaCC src, but semi-readable auto-generated Java code. So we implement patches to ss_ccs2.jar unwillingly.January 28, 2013 at 18:05#29194
Since the hack is what it is – a CSS hack meant to be ignored – and we do not want to play MSIE, I do not think there is any need or a way to try to parse that value. It should just be “safely ignored” as it is in non-MSIE browsers.
So I think catching that exception and throwing away that one property would be all that’s needed. Could this be done by you, or is that already something in the library?
On a side note: it’s not “0px9” what causes the exception – that value goes through. It’s that without an unit – “09” where the “9” gets parsed as part of a number – that crashes it.January 28, 2013 at 18:08#29195
Give a try to the attached.January 28, 2013 at 18:18#29196
Thank you a lot! I need to forward that and wait for it to be available for testing, but will get back to you as soon as we could deploy & test it.March 19, 2013 at 18:13#29197
Sorry for late response.
The patched version seems to be immune to the problem now.
The forum ‘HTML/CSS rendering issues’ is closed to new topics and replies.