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) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
|
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
|
|
From: Waldbaer <wal...@us...> - 2008-08-11 07:45:37
|
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 |
|
From: Waldbaer <wal...@us...> - 2008-08-11 07:44:01
|
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. |
|
From: Waldbaer <wal...@us...> - 2008-08-11 07:41:54
|
Test, please ignore Waldbaer |
|
From: Alan K. <al...@tr...> - 2008-05-28 14:17:09
|
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 |
|
From: D&J G. <djg...@gm...> - 2008-03-27 22:08:39
|
Done. I've uploaded it to SF and deployed it to our Maven repo, which I'll soon request be sync'ed with the central repo. Regards, Daniel On Thu, Mar 27, 2008 at 9:27 AM, Alan Krueger <al...@tr...> wrote: > D&J Gredler wrote: > > Does anyone mind if I cut a new release sometime in the next week? > > Most of the bugs have been fixed and are now marked as such. All unit > > tests are passing, and my "real world" usage with HtmlUnit seems to > > indicate that things are OK. > Sounds like a good idea to me. > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > 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-03-27 13:27:32
|
D&J Gredler wrote: > Does anyone mind if I cut a new release sometime in the next week? > Most of the bugs have been fixed and are now marked as such. All unit > tests are passing, and my "real world" usage with HtmlUnit seems to > indicate that things are OK. Sounds like a good idea to me. |
|
From: Johannes K. <ko...@w3...> - 2008-03-27 08:59:10
|
D&J Gredler schrieb:
> Does anyone mind if I cut a new release sometime in the next week?
+1 pro release
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
|
|
From: D&J G. <djg...@gm...> - 2008-03-27 00:52:34
|
Hi guys, Does anyone mind if I cut a new release sometime in the next week? Most of the bugs have been fixed and are now marked as such. All unit tests are passing, and my "real world" usage with HtmlUnit seems to indicate that things are OK. Thoughts? Daniel -- Daniel Gredler http://daniel.gredler.net/ |
|
From: Johannes K. <ko...@w3...> - 2008-03-26 17:57:43
|
[4th attempt to send this mail via list, 1st was 2008-03-25]
D&J Gredler schrieb:
> Anyways, I'll go ahead and set the min in the POM, but if anyone else has
> any comments, feel free to speak up.
Which Java 1.5 features are currently used or are planned to be used in
cssparser in order to set the compatibility to version 1.5?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
|
|
From: Johannes K. <ko...@w3...> - 2008-03-26 17:56:43
|
[4th attempt to send this mail via list, 1st was 2008-03-24]
D&J Gredler schrieb:
> I want to close bug 1337724 (we're no longer compatible with JDK 1.2), which
> was opened 3 years ago. However, before doing so I'd like to clarify which
> JDK version the project requires. It seems to me that Java 5 should be the
> minimum, since that's when the DOM Level 3 APIs were first added to Java.
> What does everyone think?
Currently the project requires Java 1.4 (use of java.net.URI). I don't
think we use DOM3 right now.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
|
|
From: Alan K. <al...@tr...> - 2008-03-26 15:17:42
|
Johannes Koch wrote: > Alan Krueger schrieb: > >> Testing non-subscriber posting to the cssparser-developers list. Please >> ignore. >> > Not ignoring it for testing purposes... Great, it looks like one of your attempts got through. =) |
3 messages has been excluded from this view by a project administrator.
