Menu
▾
▴
formfaces-development — Mailing list for developers.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(11) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Kugelman, J. <jku...@pr...> - 2005-05-06 14:50:00
|
Without actually having thought about the CSS problem in detail, my hope is that we will only have to implement the parsing end of it and leave the rendering, cascading, etc. to the browsers. For example, add classes to each element like .first-child, .enabled/.disabled, .required/.optional, and so on. Then we can have the CSS parser translate pseudo-classes into real classes. We could have it translate pseudo-elements into real elements. This is just my hope, though. Whether or not this approach will work for all other CSS3 constructs, I do not know. John =20 > -----Original Message----- > From: for...@li... [mailto:formfaces- > dev...@li...] On Behalf Of Micah Dubinko > Sent: Thursday, May 05, 2005 6:57 PM > To: Stefano Debenedetti > Cc: for...@li... > Subject: [ff-dev] CSS performance >=20 > On the topic of CSS performance, Dave Hyatt of Apple Safari has some > interesting comments: >=20 > http://weblogs.mozillazine.org/hyatt/archives/2005_05.html#007507 >=20 > -m >=20 > -- > Available for consulting. XForms, web forms, information overload. > Micah Dubinko mailto:mi...@du... > Brain Attic, L.L.C. http://brainattic.info > Yahoo IM: mdubinko +1 623 298 5172 > Learn XForms today: http://xformsinstitute.com >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20 > _______________________________________________ > FormFaces-development mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formfaces-development |
|
From: Micah D. <mi...@du...> - 2005-05-05 23:51:53
|
If you look at http://wiki.brainattic.info/Brainstorm you'll see that I'm thinking about a 'get started' project to learn the ropes of making a new Dashboard Widget in OS X Tiger. Has anyone thought about doing something with XForms? Any ideas welcome (it is a brainstorm after all!) --feel free to add stuff on the Wiki page at will. .micah -- Available for consulting. XForms, web forms, information overload. Micah Dubinko mailto:mi...@du... Brain Attic, L.L.C. http://brainattic.info Yahoo IM: mdubinko +1 623 298 5172 Learn XForms today: http://xformsinstitute.com |
|
From: Micah D. <mi...@du...> - 2005-05-05 22:57:34
|
On the topic of CSS performance, Dave Hyatt of Apple Safari has some interesting comments: http://weblogs.mozillazine.org/hyatt/archives/2005_05.html#007507 -m -- Available for consulting. XForms, web forms, information overload. Micah Dubinko mailto:mi...@du... Brain Attic, L.L.C. http://brainattic.info Yahoo IM: mdubinko +1 623 298 5172 Learn XForms today: http://xformsinstitute.com |
|
From: Stefano D. <st...@de...> - 2005-05-05 21:20:03
|
I am happy to forward this on behalf of Claus -------- Messaggio Originale -------- Oggetto: Re: [ff-dev] Survey of JavaScript CSS3 engines Data: Thu, 05 May 2005 23:13:47 +0200 Da: Claus Wahlers <cl...@co...> A: Stefano Debenedetti <st...@de...> Referenze: <D87...@es...> <427...@de...> > AFAIK that CSS engine does a very good job at parsing the rules and > if I remember well it passes the whole CSS selectors test suite. if not the whole, then at least a significant part. the ecmascript css3 parser in the ugo cvs is currently work in progress, but quite complete (it's missing some at-rules yet like @media and @print). the parser creates a css dom. > On the other hand, rendering the parsed information is a > completely different issue... yup > Unfortunately I don't know the internals of that CSS parser so > I am CCing its author, Claus Wahlers, in the hope of getting > him to participate in this discussion ;-) i'm happy to help :) > Given that a full CSS renderer is probably going to be the least > performing part of an Ecmascript XForms engine (at least it was in > DENG, I think CSS it's more demanding and less optimizable than > XPath...) another option would be to leverage the browser's native > CSS parser (modulo some IE7-based enhancements for IE). > > It's probably going to be way more performant that anything we come > come up with. definately true, although this would be the solution that would cause the most crossbrowser headaches. also note that browser's native javascript engines are significantly faster that the flash player's (at least for flash player <= 7). > Note that this would probably mean parsing the stylesheet nonetheless as > supporting XForms-specific or not-yet-implemented CSS3 stuff could > probably be done by mangling the original stylesheet and document on the > fly (i.e. rules targetting pseudo-elements could be translated into > rules targetting injected elements in a private namespace and rules > targetting pseudo-classes could be translated into rules targetting > injected attributes in a private namespace). the performance problem is not the parser itself (it's relatively fast). the real problem is that you have to retrieve css properties for each element in the dom, and go through the whole cascade for *each* property. there are about 100 different css properties defined in css2. let's assume you have 200 elements in the dom, that'd make 20.000 trips through the cascade. this is what slows down deng, even though i use hashtables to speed up access. i think it'd be a good idea to use the native renderer as much as possible, and just use the custom engine for poorly supported or unsupported rules/declarations. cheers, claus. |
|
From: Stefano D. <st...@de...> - 2005-05-05 20:36:27
|
>>http://cvs.sourceforge.net/viewcvs.py/ugo/deng2/com/mozquito/deng/css/ >> >> From the UGO and DENG projects. GPL license. Another possibility. > > > Seeing as Stefano Debenedetti has been tentatively working with us, this > is a strong candidate. I've just invited him to join the mailing list, > so hopefully he can give us his opinion. Hi, yes, I finally joined.. AFAIK that CSS engine does a very good job at parsing the rules and if I remember well it passes the whole CSS selectors test suite. On the other hand, rendering the parsed information is a completely different issue... Unfortunately I don't know the internals of that CSS parser so I am CCing its author, Claus Wahlers, in the hope of getting him to participate in this discussion ;-) Given that a full CSS renderer is probably going to be the least performing part of an Ecmascript XForms engine (at least it was in DENG, I think CSS it's more demanding and less optimizable than XPath...) another option would be to leverage the browser's native CSS parser (modulo some IE7-based enhancements for IE). It's probably going to be way more performant that anything we come come up with. Note that this would probably mean parsing the stylesheet nonetheless as supporting XForms-specific or not-yet-implemented CSS3 stuff could probably be done by mangling the original stylesheet and document on the fly (i.e. rules targetting pseudo-elements could be translated into rules targetting injected elements in a private namespace and rules targetting pseudo-classes could be translated into rules targetting injected attributes in a private namespace). I am going to explore this path with ugo before giving up on it... ciao ste |
|
From: Sikora, G. <gjs...@pr...> - 2005-05-04 14:06:33
|
Micah, Let us set up a call for sometime Thur or Fri to discuss with John. One concern I have is FormFaces will need to support a GPL and Commercial License. This means we can't accept code under GPL license without a formal, prior agreement that we can use it under a commercial license. Very respectfully, Gary -----Original Message----- From: Kugelman, John=20 Sent: Tuesday, May 03, 2005 4:54 PM To: 'Micah Dubinko'; for...@li... Cc: Sikora, Gary Subject: RE: [ff-dev] Survey of JavaScript CSS3 engines Micah Dubinko wrote: >=20 > One of my initial thoughts was to maybe use Lex/Yacc and port the > resulting C code to JS, but upon reflection I don't think this is a > great idea. Even the simplest grammar produces 30-40k of code, and it > would be tedious to track changes. The CSS3 Selectors spec includes a > full grammar, but still... >=20 > Do any of you know of a similar parser-generator that targets JS? >=20 > For CSS3, looking at what's out there already, I found >=20 > http://simon.incutio.com/js/getElementsBySelector.js >=20 > A nice demo, but would take much work to get up to commercial quality. > For example, the tokenizer just splits on space, so selectors like a>b > won't work. Also this code gives no indication as to licensing. This seems small enough that we could reproduce it ourselves if licensing is a no go. Writing a better tokenizer would be no problem though. We could easily reuse much of the code we wrote for the XPath tokenizer. > http://markpasc.org/lj/200304/htmlp.py > > Python, but not too hard to port to JS. Haven't looked at too much. MIT > license. This is an HTML parser, no? > http://dean.edwards.name/my/cssQuery.js.html >=20 > Dean Edwards' IE7 code. Nicely structured, extensible, and surprisingly > compact. Liberal licensing--attribution required and nothing else. This > is a strong possibility to use in ff. Yes, this project is impressive.=20 > http://cvs.sourceforge.net/viewcvs.py/ugo/deng2/com/mozquito/deng/css/ > > From the UGO and DENG projects. GPL license. Another possibility. Seeing as Stefano Debenedetti has been tentatively working with us, this is a strong candidate. I've just invited him to join the mailing list, so hopefully he can give us his opinion. ... Given the relatively small sizes of all of these implementations, perhaps it won't be such a big deal to write our own if we have to. One advantage to doing so would be that a lot of parsing code already exists for the XPath engine, so reusing the XPath code could lead to a lot less code overall than having a separate parser for CSS. Ultimately, my main concern is getting all of the rules for cascading rules 100% correct. FYI, the activity level around here should be ramping up quite a bit soon. We've unfortunately been temporarily distracted by other projects, but that is coming to a close. John |
|
From: Kugelman, J. <jku...@pr...> - 2005-05-03 20:54:00
|
Micah Dubinko wrote: >=20 > One of my initial thoughts was to maybe use Lex/Yacc and port the > resulting C code to JS, but upon reflection I don't think this is a > great idea. Even the simplest grammar produces 30-40k of code, and it > would be tedious to track changes. The CSS3 Selectors spec includes a > full grammar, but still... >=20 > Do any of you know of a similar parser-generator that targets JS? >=20 > For CSS3, looking at what's out there already, I found >=20 > http://simon.incutio.com/js/getElementsBySelector.js >=20 > A nice demo, but would take much work to get up to commercial quality. > For example, the tokenizer just splits on space, so selectors like a>b > won't work. Also this code gives no indication as to licensing. This seems small enough that we could reproduce it ourselves if licensing is a no go. Writing a better tokenizer would be no problem though. We could easily reuse much of the code we wrote for the XPath tokenizer. > http://markpasc.org/lj/200304/htmlp.py > > Python, but not too hard to port to JS. Haven't looked at too much. MIT > license. This is an HTML parser, no? > http://dean.edwards.name/my/cssQuery.js.html >=20 > Dean Edwards' IE7 code. Nicely structured, extensible, and surprisingly > compact. Liberal licensing--attribution required and nothing else. This > is a strong possibility to use in ff. Yes, this project is impressive.=20 > http://cvs.sourceforge.net/viewcvs.py/ugo/deng2/com/mozquito/deng/css/ > > From the UGO and DENG projects. GPL license. Another possibility. Seeing as Stefano Debenedetti has been tentatively working with us, this is a strong candidate. I've just invited him to join the mailing list, so hopefully he can give us his opinion. ... Given the relatively small sizes of all of these implementations, perhaps it won't be such a big deal to write our own if we have to. One advantage to doing so would be that a lot of parsing code already exists for the XPath engine, so reusing the XPath code could lead to a lot less code overall than having a separate parser for CSS. Ultimately, my main concern is getting all of the rules for cascading rules 100% correct. FYI, the activity level around here should be ramping up quite a bit soon. We've unfortunately been temporarily distracted by other projects, but that is coming to a close. John |
|
From: Kugelman, J. <jku...@pr...> - 2005-05-02 17:28:27
|
That would be great. John =20 -----Original Message----- From: for...@li... [mailto:for...@li...] On Behalf Of Borgrink, Susan Sent: Monday, May 02, 2005 12:58 PM To: for...@li...; Sikora, Gary Subject: RE: [ff-dev] Opera crashing =20 Do you want me to install Opera and try some testing here to replicate the problem? =20 Susan =20 -----Original Message----- From: for...@li... [mailto:for...@li...] On Behalf Of Kugelman, John Sent: Monday, May 02, 2005 11:50 AM To: for...@li...; Sikora, Gary Subject: [ff-dev] Opera crashing =20 I don't know why yet, but after a couple dozen page loads Opera crashes. Will need to investigate... =20 John Kugelman Progeny Systems Corporation (703) 368-6107 x169 =20 |
|
From: Borgrink, S. <sbo...@pr...> - 2005-05-02 16:57:56
|
Do you want me to install Opera and try some testing here to replicate the problem? =20 Susan =20 -----Original Message----- From: for...@li... [mailto:for...@li...] On Behalf Of Kugelman, John Sent: Monday, May 02, 2005 11:50 AM To: for...@li...; Sikora, Gary Subject: [ff-dev] Opera crashing =20 I don't know why yet, but after a couple dozen page loads Opera crashes. Will need to investigate... =20 John Kugelman Progeny Systems Corporation (703) 368-6107 x169 =20 |
|
From: Kugelman, J. <jku...@pr...> - 2005-05-02 15:50:22
|
I don't know why yet, but after a couple dozen page loads Opera crashes. Will need to investigate... =20 John Kugelman Progeny Systems Corporation (703) 368-6107 x169 =20 |
|
From: Kugelman, J. <jku...@pr...> - 2005-05-02 14:59:37
|
Good news! I spent a day and got FormFaces working in Opera. Almost all of the "Examples" pages work in Opera. Insert and delete are broken, though repeats work. You will need the just-released Opera 8. Opera 7 doesn't have document.implementation.createDocument, so that was a non-starter. Bonus standards compatibility--Opera 8 implements the DOM 3 Load and Save module, so now we support that module too. Might I add that I *hate* Opera for the ridiculous hacks I had to implement to get it to cooperate. Far worse than any hack I've ever written for Internet Explorer. John =20 > -----Original Message----- > From: Steven Pemberton [mailto:Ste...@cw...] > Sent: Friday, April 29, 2005 9:59 AM > To: Sikora, Gary; Steven Pemberton > Cc: Hertz, Mike; Borgrink, Susan; Kugelman, John > Subject: Re: FormFaces 2005 rel.1 Alpha 3_25_05 >=20 > On Fri, 29 Apr 2005 14:27:25 +0200, Sikora, Gary <gjs...@pr...> > wrote: >=20 > > The plan is to support all JavaScript/Dom 2 browsers ... we are just > > currently testing in IE and FireFox. > > > > Thanks for the exposure! >=20 > Great news. Let me know when it works in Opera, since that will be very > good for polemic reasons, Opera being the only place where you can't yet > run XForms in any way, and it will help undermine the WHAT WG position. >=20 > In fact, I am speaking in a session shortly where I'll be followd by WHAT > people, so if it is a quick fiz, that would be terrific. >=20 > Thanks again. >=20 > Steven |
|
From: Micah D. <mi...@du...> - 2005-04-28 23:36:33
|
One of my initial thoughts was to maybe use Lex/Yacc and port the resulting C code to JS, but upon reflection I don't think this is a great idea. Even the simplest grammar produces 30-40k of code, and it would be tedious to track changes. The CSS3 Selectors spec includes a full grammar, but still... Do any of you know of a similar parser-generator that targets JS? For CSS3, looking at what's out there already, I found http://simon.incutio.com/js/getElementsBySelector.js A nice demo, but would take much work to get up to commercial quality. For example, the tokenizer just splits on space, so selectors like a>b won't work. Also this code gives no indication as to licensing. http://markpasc.org/lj/200304/htmlp.py Python, but not too hard to port to JS. Haven't looked at too much. MIT license. http://dean.edwards.name/my/cssQuery.js.html Dean Edwards' IE7 code. Nicely structured, extensible, and surprisingly compact. Liberal licensing--attribution required and nothing else. This is a strong possibility to use in ff. http://cvs.sourceforge.net/viewcvs.py/ugo/deng2/com/mozquito/deng/css/ From the UGO and DENG projects. GPL license. Another possibility. Right now, I'm thinking that reusing/integrating one of the above is a better option than writing from scratch. What do the rest of you think? .micah -- Available for consulting. XForms, web forms, information overload. Micah Dubinko mailto:mi...@du... Brain Attic, L.L.C. http://brainattic.info Yahoo IM: mdubinko +1 623 298 5172 Learn XForms today: http://xformsinstitute.com |
|
From: Micah D. <mi...@du...> - 2005-04-27 21:28:19
|
Somebody asked today about a "Powered by XForms" logo. I thought that was a great idea, so I'm happy to announce a contest to design one. http://wiki.brainattic.info/Powered_by_XForms Please visit the wiki for instructions and a place to track the submissions. Deadline is May 20, 2005 (just in time for XTech). Thanks! -- Available for consulting. XForms, web forms, information overload. Micah Dubinko mailto:mi...@du... Brain Attic, L.L.C. http://brainattic.info Yahoo IM: mdubinko +1 623 298 5172 Learn XForms today: http://xformsinstitute.com |
|
From: Kugelman, J. <jku...@pr...> - 2005-04-26 20:10:15
|
Roger that. John =20 > -----Original Message----- > From: for...@li... [mailto:formfaces- > dev...@li...] On Behalf Of Micah Dubinko > Sent: Tuesday, April 26, 2005 3:54 PM > To: for...@li... > Subject: [Formfaces-development] Hi everybody >=20 > Let's make sure this is working. -m |
|
From: Micah D. <mi...@du...> - 2005-04-26 19:54:08
|
Let's make sure this is working. -m -- Available for consulting. XForms, web forms, information overload. Micah Dubinko mailto:mi...@du... Brain Attic, L.L.C. http://brainattic.info Yahoo IM: mdubinko +1 623 298 5172 Learn XForms today: http://xformsinstitute.com |
|
From: Kugelman, J. <jku...@pr...> - 2005-04-26 17:39:51
|
Susan, Micah, =20 To help organize our communications better I set up a mailing list at SourceForge: for...@li.... We should use this for all development communication rather than e-mailing each other directly. =20 Go to http://lists.sourceforge.net/lists/listinfo/formfaces-development to subscribe to the list. =20 There's also a mailing list where CVS commit log messages will be sent: for...@li.... You can subscribe to that mailing list if you want to see all the commit messages. (Although, I don't know if I set it up correctly yet.) =20 John Kugelman Progeny Systems Corporation (703) 368-6107 x169 =20 |
