cssparser-developers — CSS Parser Developers

Re: [cssparser-developers] CSS Parser updates/patches

[Alan K. <al...@tr...>]

On 6/13/2011 6:53 AM, Ronald Brill wrote:
> So i checked out the thing and have tried to build it and fix some issue.
> At first i have noticed, that some of the problems are already fixed because of the chanes waldbaer did; but nerver relased.
> Additionaly we need some more fixes and imporvements. So i have started some coding.
>
> Finally i contaced Daniel to submit that patch. But i think he has no time at the moment.
> Is it possible that i send you the (monster) patche and you commit the stuff (of course after carefully checking). And second, is it possible for you to make at least snapshot builds available?
> We have some plans to make a new release but it will be really helpfull too have have an improved version of cssparser also.
I agree.  Would it be possible to break up the large patch into discrete 
functional patches, or are they irretrievably combined?

I've not performed releases myself for this project, but I'd be willing 
to help get things moving.

[cssparser-developers] CSS Parser updates/patches

[Ronald B. <rb...@rb...>]

Hi CSSParser Developers,

I'm one of the HtmlUnit developers. At the moment, we have some issues open related to problems with cssparser.

So i checked out the thing and have tried to build it and fix some issue.
At first i have noticed, that some of the problems are already fixed because of the chanes waldbaer did; but nerver relased.
Additionaly we need some more fixes and imporvements. So i have started some coding.

Finally i contaced Daniel to submit that patch. But i think he has no time at the moment.
Is it possible that i send you the (monster) patche and you commit the stuff (of course after carefully checking). And second, is it possible for you to make at least snapshot builds available?
We have some plans to make a new release but it will be really helpfull too have have an improved version of cssparser also.

Thanks for your time/support



    RBRi
    --------------------------
    Wetator
    Smart web application testing
    http://www.wetator.org

Re: [cssparser-developers] Subversion

[Alan K. <al...@tr...>]

On 3/20/2008 1:15 PM, Alan Krueger wrote:
> (The question was asked earlier, but in the middle of another message.
> I'll restate the question to ensure it doesn't get missed.)
>
> Does anyone object to using Subversion for our source control?  We can't
> use both SVN and CVS at the same time.  We would have to enable SVN,
> convert our existing CVS repository into SVN, then import that into SF's
> SVN repository.
>
> It takes a bit of work, but it should be easy to back out if something
> went wrong in the conversion process.  I'm in favor of Subversion
> myself, I've found it quite a bit easier to use than CVS and more powerful.
I got only positive responses back then, but I didn't have time to look 
at it then.  I'd forgotten about this until recently.

I've converted over the CVS repo into SVN and imported it.  I haven't 
done any cleanup like adding svn:ignore properties anywhere or removing 
the CVSROOT from the trunk yet.

I disabled the CVS feature in the project, but we can get it back if 
someone rabidly objects at the last minute.  =)

Thanks,
Alan

[cssparser-developers] Compiling parser from .jj files

[Gabriel G. <gr...@LE...>]

Hello everyone,

I have a question about recompiling the parser's source with JavaCC and the .jj files found on the CVS. 

I have checked out the latest version (0.9.6-SNAPSHOT) and it works just fine. When I recompile the parser using the .jj files found in src/main/javacc and replace the files found in target/generate-sources/javacc, I always EmptyStackException errors with the same test code that was working just fine before.

The exact error I'm getting is:

Exception in thread "main" java.util.EmptyStackException
	at java.util.Stack.peek(Stack.java:85)
	at java.util.Stack.pop(Stack.java:67)
	at com.steadystate.css.parser.CSSOMParser$CSSOMHandler.endDocument(CSSOMParser.java:266)
	at com.steadystate.css.parser.AbstractSACParser.handleEndDocument(AbstractSACParser.java:488)
	at com.steadystate.css.parser.SACParserCSS2.styleSheet(SACParserCSS2.java:51)
	at com.steadystate.css.parser.AbstractSACParser.parseStyleSheet(AbstractSACParser.java:320)
	at com.steadystate.css.parser.CSSOMParser.parseStyleSheet(CSSOMParser.java:139)
	at CssTest.main(CssTest.java:24)

Is there anything that I'm doing wrong? Is there a special procedure to follow to recompile the parser?

Thanks a lot for the help,
Gabriel

[cssparser-developers] *.jj recheck please

[Waldbaer <wal...@us...>]

Hi list,

can somebody experienced with javacc syntax please recheck the .jj 
files? To me it looks like there are some differences between the parser 
implementations and the CSS grammars, especially for CSS1.

-- 
Waldbaer

Re: [cssparser-developers] Where should a Locator point to?

[Waldbaer <wal...@us...>]

Daniel Gredler schrieb:
> Then standardizing on the first character sounds good to me!

I checked in some changes, so that the CSSOMObject's Locators point to 
the first character. This does not effect line/char numbers in exceptions.

-- 
Waldbaer

Re: [cssparser-developers] Where should a Locator point to?

[Daniel G. <djg...@gm...>]

Then standardizing on the first character sounds good to me!


On Mon, Nov 24, 2008 at 3:43 AM, Waldbaer <wal...@us...>wrote:

> Daniel Gredler schrieb:
> > What's the current behavior?
>
> It's somehow mixed ...
>
> --
> Waldbaer
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> cssparser-developers mailing list
> css...@li...
> https://lists.sourceforge.net/lists/listinfo/cssparser-developers
>



-- 
Daniel Gredler
http://daniel.gredler.net/

Re: [cssparser-developers] class selector '.important'

[Waldbaer <wal...@us...>]

Waldbaer schrieb:
> Hi,
> 
> just recently I parsed a CSS resource containing something like the 
> following:
> 
>    .important {
> /* ... */
> }
> 
> using the CSS 2.1 SAC parser. There seems to be an issue with the class 
> selector '.important' because 'important' is a keyword in the grammar.
> 
> I'll try to look into this after the weekend.

I think, I fixed it. The (few) test run without failure.

Re: [cssparser-developers] Where should a Locator point to?

[Waldbaer <wal...@us...>]

Daniel Gredler schrieb:
> What's the current behavior?

It's somehow mixed ...

-- 
Waldbaer

Re: [cssparser-developers] TAB handling

[David S. <dav...@gm...>]

On 22/11/2008, at 4:39 AM, Daniel Gredler wrote:

> Works for me, though I'd prefer we had some feedback from David  
> regarding the initial rationale for this code :-/

The plan for me is to go camping in a couple of hours, but looking at  
the wind and the rain outside I may have an opportunity to go through  
all this sooner than that.

David

Re: [cssparser-developers] Where should a Locator point to?

[Daniel G. <djg...@gm...>]

What's the current behavior?


On Fri, Nov 21, 2008 at 5:26 AM, Waldbaer <wal...@us...>wrote:

> Hi,
>
> I plan to rewrtie the adding of Locators to CSSOM objects and
> LexicalValues. At the moment the following objects get a Locator:
>
> * CSSCharsetRuleImpl
> * CSSImportRuleImpl
> * CSSFontFaceRuleImpl
> * CSSMediaRuleImpl
> * CSSPageRuleImpl
> * CSSStyleRuleImpl
> * CSSUnknownRuleImpl
> * Property
> * LexicalUnitImpl
>
> Which location in the source code should the Locator point to?
>
> Should it always point to the first character?
>
> Example:
>
> @import "../../dojo/resources/dojo.css";
> ^                           Locator for CSSImportRuleImpl
>
> #testLayout {
> ^                           Locator for CSSStyleRuleImpl
>     height: 100%;
>     ^                       Locator for Property 'height'
>             ^               Locator for LexicalUnitImpl '100%'
>     border: 1px solid black;
>     ^                       Locator for Property 'border'
>             ^               Locator for LexicalUnitImpl '1px'
>                 ^           Locator for LexicalUnitImpl 'solid'
>                       ^     Locator for LexicalUnitImpl 'black'
> }
>
> --
> Waldbaer
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> cssparser-developers mailing list
> css...@li...
> https://lists.sourceforge.net/lists/listinfo/cssparser-developers
>



-- 
Daniel Gredler
http://daniel.gredler.net/

Re: [cssparser-developers] TAB handling

[Daniel G. <djg...@gm...>]

Works for me, though I'd prefer we had some feedback from David regarding
the initial rationale for this code :-/


On Fri, Nov 21, 2008 at 11:12 AM, Alan Krueger <al...@tr...> wrote:

> Waldbaer wrote:
> > Well, I did some _changes_, but I did not write the original code. David?
> >
> If I'm reading the diff correctly, it claims those lines were added in
> that revision.
> > The problem that I see with this special treatment is that some viewing
> > applications may treat a TAB char as 8, some as 4, some as 2 characters
> > wide. In fact it's still only one character.
> >
> > I propose to remove the whole case block for '\t'
> I agree.  This is really presentation logic embedded in the parser.  The
> caller can expand the returned column based on how it treats tabs, but
> that's not something the parser itself needs to do.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> cssparser-developers mailing list
> css...@li...
> https://lists.sourceforge.net/lists/listinfo/cssparser-developers
>



-- 
Daniel Gredler
http://daniel.gredler.net/

Re: [cssparser-developers] Where should a Locator point to?

[Alan K. <al...@tr...>]

Waldbaer wrote:
> Which location in the source code should the Locator point to?
>
> Should it always point to the first character?
>
> Example:
>
> @import "../../dojo/resources/dojo.css";
> ^                           Locator for CSSImportRuleImpl
>
> #testLayout {
> ^                           Locator for CSSStyleRuleImpl
>   
That seems like a sensible approach to me.

Re: [cssparser-developers] TAB handling

[Alan K. <al...@tr...>]

Waldbaer wrote:
> Well, I did some _changes_, but I did not write the original code. David?
>   
If I'm reading the diff correctly, it claims those lines were added in 
that revision.
> The problem that I see with this special treatment is that some viewing 
> applications may treat a TAB char as 8, some as 4, some as 2 characters 
> wide. In fact it's still only one character.
>
> I propose to remove the whole case block for '\t'
I agree.  This is really presentation logic embedded in the parser.  The 
caller can expand the returned column based on how it treats tabs, but 
that's not something the parser itself needs to do.

[cssparser-developers] class selector '.important'

[Waldbaer <wal...@us...>]

Hi,

just recently I parsed a CSS resource containing something like the 
following:

   .important {
/* ... */
}

using the CSS 2.1 SAC parser. There seems to be an issue with the class 
selector '.important' because 'important' is a keyword in the grammar.

I'll try to look into this after the weekend.

-- 
Waldbaer

[cssparser-developers] Where should a Locator point to?

[Waldbaer <wal...@us...>]

Hi,

I plan to rewrtie the adding of Locators to CSSOM objects and 
LexicalValues. At the moment the following objects get a Locator:

* CSSCharsetRuleImpl
* CSSImportRuleImpl
* CSSFontFaceRuleImpl
* CSSMediaRuleImpl
* CSSPageRuleImpl
* CSSStyleRuleImpl
* CSSUnknownRuleImpl
* Property
* LexicalUnitImpl

Which location in the source code should the Locator point to?

Should it always point to the first character?

Example:

@import "../../dojo/resources/dojo.css";
^                           Locator for CSSImportRuleImpl

#testLayout {
^                           Locator for CSSStyleRuleImpl
     height: 100%;
     ^                       Locator for Property 'height'
             ^               Locator for LexicalUnitImpl '100%'
     border: 1px solid black;
     ^                       Locator for Property 'border'
             ^               Locator for LexicalUnitImpl '1px'
                 ^           Locator for LexicalUnitImpl 'solid'
                       ^     Locator for LexicalUnitImpl 'black'
}

-- 
Waldbaer

Re: [cssparser-developers] TAB handling

[Waldbaer <wal...@us...>]

Alan Krueger schrieb:
> Waldbaer wrote:
>> I wondered why the columnNumbers for characters following a TAB 
>> character are so big. The TAB character seems to be treated like 8 
>> characters. I found the following:
>>
>> com.steadystate.css.parser.ASCII_CharStream.UpdateLineColumn(char c), 
>> line 162:
>>
>>          case '\t' :
>>              this.column--;
>>              this.column += (8 - (this.column & 07));
>>              break;
>>
>> Why is this special treatment for TAB?
>>   
> According to the SourceForge CVS browser, that looks like it was one of 
> your changes.  :-)
[...]
>     Changes since *1.2: +125 -125 lines*
>     Diff to previous 1.2
>     <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&r1=1.2&r2=1.3>cleanup
> 
> http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=diff&r1=1.2&r2=1.3 <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=diff&r1=1.2&r2=1.3>
> 
> 162 
> <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l162> 
> 	         case '\t' : 	         case '\t' :
> 163 
> <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l163> 
> 	            column--; 	             this.column--;
> 164 
> <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l164> 
> 	            column += (8 - (column & 07)); 	             this.column += 
> (8 - (this.column & 07));
> 165 
> <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l165> 
> 	            break; 	            break;

Well, I did some _changes_, but I did not write the original code. David?

The problem that I see with this special treatment is that some viewing 
applications may treat a TAB char as 8, some as 4, some as 2 characters 
wide. In fact it's still only one character.

I propose to remove the whole case block for '\t'.

-- 
Waldbaer

Re: [cssparser-developers] TAB handling

[Alan K. <al...@tr...>]

Alan Krueger wrote:
> http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=log#rev1.3 
> <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=log#rev1.3>
>
>     Revision *1.3* - (view
>     <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&revision=1.3&view=markup>)
>     (download
>     <http://cssparser.cvs.sourceforge.net/viewvc/*checkout*/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?revision=1.3>)
>     (annotate
>   
Wow, that REALLY didn't send well through the list manager.  :-(

Re: [cssparser-developers] TAB handling

[Alan K. <al...@tr...>]

Waldbaer wrote:
> I wondered why the columnNumbers for characters following a TAB 
> character are so big. The TAB character seems to be treated like 8 
> characters. I found the following:
>
> com.steadystate.css.parser.ASCII_CharStream.UpdateLineColumn(char c), 
> line 162:
>
>          case '\t' :
>              this.column--;
>              this.column += (8 - (this.column & 07));
>              break;
>
> Why is this special treatment for TAB?
>   
According to the SourceForge CVS browser, that looks like it was one of 
your changes.  :-)

http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=log#rev1.3 
<http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=log#rev1.3>

    Revision *1.3* - (view
    <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&revision=1.3&view=markup>)
    (download
    <http://cssparser.cvs.sourceforge.net/viewvc/*checkout*/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?revision=1.3>)
    (annotate
    <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0>)
    - [select for diffs]
    <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&r1=1.3&view=log>

    /Tue Apr 11 08:18:35 2006 UTC/ (2 years, 7 months ago) by /waldbaer/
    Branch: *MAIN*
    <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?view=log&hideattic=0&pathrev=MAIN>

    CVS Tags: *PRE_MAVEN*
    <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?view=log&hideattic=0&pathrev=PRE_MAVEN>

    Changes since *1.2: +125 -125 lines*
    Diff to previous 1.2
    <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&r1=1.2&r2=1.3>cleanup

http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=diff&r1=1.2&r2=1.3 <http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?hideattic=0&view=diff&r1=1.2&r2=1.3>

162 
<http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l162> 
	         case '\t' : 	         case '\t' :
163 
<http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l163> 
	            column--; 	             this.column--;
164 
<http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l164> 
	            column += (8 - (column & 07)); 	             this.column += 
(8 - (this.column & 07));
165 
<http://cssparser.cvs.sourceforge.net/viewvc/cssparser/cssparser/src/com/steadystate/css/parser/ASCII_CharStream.java?annotate=1.3&hideattic=0#l165> 
	            break; 	            break;

Re: [cssparser-developers] TAB handling

[Daniel G. <djg...@gm...>]

No idea... does the cvs log say who committed those lines of code?


On Thu, Nov 20, 2008 at 11:21 AM, Waldbaer
<wal...@us...>wrote:

> Hi,
>
> I wondered why the columnNumbers for characters following a TAB
> character are so big. The TAB character seems to be treated like 8
> characters. I found the following:
>
> com.steadystate.css.parser.ASCII_CharStream.UpdateLineColumn(char c),
> line 162:
>
>         case '\t' :
>             this.column--;
>             this.column += (8 - (this.column & 07));
>             break;
>
> Why is this special treatment for TAB?
>
> --
> Waldbaer
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> cssparser-developers mailing list
> css...@li...
> https://lists.sourceforge.net/lists/listinfo/cssparser-developers
>



-- 
Daniel Gredler
http://daniel.gredler.net/

[cssparser-developers] TAB handling

[Waldbaer <wal...@us...>]

Hi,

I wondered why the columnNumbers for characters following a TAB 
character are so big. The TAB character seems to be treated like 8 
characters. I found the following:

com.steadystate.css.parser.ASCII_CharStream.UpdateLineColumn(char c), 
line 162:

         case '\t' :
             this.column--;
             this.column += (8 - (this.column & 07));
             break;

Why is this special treatment for TAB?

-- 
Waldbaer

[cssparser-developers] equals() and hashCode()

[Waldbaer <wal...@us...>]

Hi developers,

I think we should implement equals() and hashCode() for the CSSOM 
objects in com.steadystate.css.dom. Any suggestions?

See also feature request 
<https://sourceforge.net/tracker/?group_id=82996&atid=567972>

-- 
Waldbaer

Re: [cssparser-developers] Test

[Waldbaer <wal...@us...>]

Waldbaer schrieb:
> Test, please ignore
> 
> Waldbaer

Hmm, that's strange. I can only post to this list with my sourceforge 
email alias, not with my real address, although I also subscribed with 
my real one.

[cssparser-developers] Test

[Waldbaer <wal...@us...>]

Test, please ignore

Waldbaer

[cssparser-developers] cssparser help forum

[Alan K. <al...@tr...>]

Is anyone else monitoring the cssparser help forum 
<https://sourceforge.net/forum/forum.php?forum_id=283564>?  There was a 
message posted there on Monday 
<https://sourceforge.net/forum/message.php?msg_id=4986901> that I don't 
know the answer to offhand and don't have a spare moment to research.

Thanks,
Alan