Menu
▾
▴
cssparser-developers — CSS Parser Developers
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(33) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(17) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(4) |
Aug
(2) |
Sep
(5) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
|
16
|
17
|
18
|
19
|
20
(4) |
21
(8) |
22
|
|
23
|
24
(3) |
25
|
26
|
27
(2) |
28
|
29
|
|
30
|
|
|
|
|
|
|
|
From: Waldbaer <wal...@us...> - 2008-11-27 16:53:35
|
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 |
|
From: Waldbaer <wal...@us...> - 2008-11-27 16:49:23
|
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 |
|
From: Daniel G. <djg...@gm...> - 2008-11-24 17:05:04
|
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/ |
|
From: Waldbaer <wal...@us...> - 2008-11-24 15:22:08
|
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.
|
|
From: Waldbaer <wal...@us...> - 2008-11-24 08:43:56
|
Daniel Gredler schrieb: > What's the current behavior? It's somehow mixed ... -- Waldbaer |
|
From: David S. <dav...@gm...> - 2008-11-21 20:38:17
|
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 |
|
From: Daniel G. <djg...@gm...> - 2008-11-21 17:40:58
|
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/
|
|
From: Daniel G. <djg...@gm...> - 2008-11-21 17:39:28
|
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/ |
|
From: Alan K. <al...@tr...> - 2008-11-21 16:18:51
|
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.
|
|
From: Alan K. <al...@tr...> - 2008-11-21 16:12:18
|
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. |
|
From: Waldbaer <wal...@us...> - 2008-11-21 14:17:46
|
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
|
|
From: Waldbaer <wal...@us...> - 2008-11-21 10:26:47
|
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
|
|
From: Waldbaer <wal...@us...> - 2008-11-21 08:11:57
|
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 |
|
From: Alan K. <al...@tr...> - 2008-11-20 18:30:07
|
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. :-( |
|
From: Daniel G. <djg...@gm...> - 2008-11-20 17:57:34
|
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/ |
|
From: Waldbaer <wal...@us...> - 2008-11-20 16:40:29
|
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
|
