Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
Andreas Hochsteger schrieb: Hello, Using plain IE (6.0.2900.2180.xpsp_sp2_gdr.05031-1519) I got a security warning, that active contents have been deactivated. Same thing here with IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519, displays just fine. The security warning comes from the onload=... functions. I just used the plain form (i.e. without cocoon, and without loading the resources needed). Displays also ok in - Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 - Opera Version 8.5 Build 7700 - Netscape 7.1 Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.4) Gecko/20030619 Netscape/7.1 (ax) Christoph
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
hepabolu wrote: Sylvain Wallez wrote: Can you build a standalone xhtml file that reproduces the problem? Here it is. It works fine in firefox (both windows and mac) and safari, but it produces the error I mentioned before in IE6. Are you by chance serving it up with an XML mime-type? The error you quoted seems to be an XML validation message which shouldn't occur for HTML.
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
Jason Johnston wrote: hepabolu wrote: Sylvain Wallez wrote: Can you build a standalone xhtml file that reproduces the problem? Here it is. It works fine in firefox (both windows and mac) and safari, but it produces the error I mentioned before in IE6. Are you by chance serving it up with an XML mime-type? The error you quoted seems to be an XML validation message which shouldn't occur for HTML. No, if I serve it up with application/xhtml+xml I get the source code as xml (of course only in IE). So I serve it up with text/html. This is driving me crazy. Bye, Helma
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
hepabolu wrote: On Sun, 6 Nov 2005, Sylvain Wallez wrote: [X] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Guys, I suppose this was the final result of the voting process. At the time I didn't have any problem with it, but now I'm running into an error: Entity names, PI targets, notation names and attribute values declared to be of types ID, IDREF(S), ENTITY(IES) or NOTATION cannot contain any colons. Erro processing resource 'http://localhost:/myform.form' What is displaying this message? Is it Cocoon, a parser, IE6? The colon character is explicitely allowed in ID attributes in the XML specification. Can you build a standalone xhtml file that reproduces the problem? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
Sylvain Wallez wrote: Entity names, PI targets, notation names and attribute values declared to be of types ID, IDREF(S), ENTITY(IES) or NOTATION cannot contain any colons. Error processing resource 'http://localhost:/myform.form' What is displaying this message? Is it Cocoon, a parser, IE6? The colon character is explicitely allowed in ID attributes in the XML specification. It's IE, the form looks fine in Firefox and Safari. Can you build a standalone xhtml file that reproduces the problem? I'll try. Bye, Helma
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
Sylvain Wallez wrote: Can you build a standalone xhtml file that reproduces the problem? Here it is. It works fine in firefox (both windows and mac) and safari, but it produces the error I mentioned before in IE6. Bye, Helma Title: OSN - Zoek modellen Veel succes! Model Auteur Jaar
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
On 28.11.2005 23:50, hepabolu wrote: Can you build a standalone xhtml file that reproduces the problem? Here it is. It works fine in firefox (both windows and mac) and safari, but it produces the error I mentioned before in IE6. Works for me: IE 6, Win 2k. Jörg
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
Joerg Heinicke wrote: On 28.11.2005 23:50, hepabolu wrote: Can you build a standalone xhtml file that reproduces the problem? Here it is. It works fine in firefox (both windows and mac) and safari, but it produces the error I mentioned before in IE6. Works for me: IE 6, Win 2k. Jörg aaargh. I have WinXPPro. Why can't it be consistent? Bye, Helma
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
On 11/28/05, hepabolu [EMAIL PROTECTED] wrote: Joerg Heinicke wrote: On 28.11.2005 23:50, hepabolu wrote: Can you build a standalone xhtml file that reproduces the problem? Here it is. It works fine in firefox (both windows and mac) and safari, but it produces the error I mentioned before in IE6. Works for me: IE 6, Win 2k. Jörg aaargh. I have WinXPPro. Why can't it be consistent? I don't see any errors simply displaying the form you sent: I'm on Win XP Pro SP2. IE 6 (6.0.2800.1106)..?? -- Peter Hunsberger
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
I got an error using WinXPPro with Firefox 1.5 (2005-11-07) in an IE-Tab (1.0.6.3) (https://addons.mozilla.org/extensions/moreinfo.php?id=1419). Using plain IE (6.0.2900.2180.xpsp_sp2_gdr.05031-1519) I got a security warning, that active contents have been deactivated. Plain Firefox is ok. Cheers, Andreas hepabolu schrieb: Sylvain Wallez wrote: Can you build a standalone xhtml file that reproduces the problem? Here it is. It works fine in firefox (both windows and mac) and safari, but it produces the error I mentioned before in IE6. Bye, Helma Veel succes! Model Auteur Jaar
Re: [VOTE] Naming rule for HTML IDs generated by CForms - error in IE with XHTML
On Sun, 6 Nov 2005, Sylvain Wallez wrote: [X] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Guys, I suppose this was the final result of the voting process. At the time I didn't have any problem with it, but now I'm running into an error: Entity names, PI targets, notation names and attribute values declared to be of types ID, IDREF(S), ENTITY(IES) or NOTATION cannot contain any colons. Erro processing resource 'http://localhost:/myform.form' span id=search.nameinput type=text title= value= name=search.name id=search.name:input//span All this when displaying my valid XHTML form in IE6 (WinXP). Help! Bye, Helma
Re: [VOTE] Naming rule for HTML IDs generated by CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 6 Nov 2005, Sylvain Wallez wrote: [X] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Sorry if I'm late. Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDca2WLNdJvZjjVZARAgq/AKC1Z3gDqfH2sH1eFwP3BTLII1T3RwCdHBL/ pODCvrX4SC/q8yt3vvOD86o= =wOVD -END PGP SIGNATURE-
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: So please choose one proposal below: [+1] foo.bar:input (colon, not CSS-friendly because of IE) [-1] foo.bar..input (double period) [-1] foo.bar.input. (trailing period) [-0] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Vadim
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Le 7 nov. 05, à 08:36, Sylvain Wallez a écrit : ...So I kindly ask people to carefully read and understand the rationale and motivation behind ':'. Ok, thanks for your (repeated I think ;-) explanation, then: [+1 ] foo.bar:input (colon, not CSS-friendly because of IE) -Bertrand
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Il giorno 07/nov/05, alle ore 08:36, Sylvain Wallez ha scritto: So I kindly ask people to carefully read and understand the rationale and motivation behind ':'. Alright, you convinced me. I hereby revert my previous vote and vote +1 on using the colon. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: The initial foo.bar:input proposal *structucally* prevents name all crispy clear now. I revert my previous +1 and +1 this proposal instead. Jorg
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: [X] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Jeroen
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On Sun, 2005-11-06 at 11:51 +0100, Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) +1 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Jorg Heymans wrote: Sylvain Wallez wrote: The initial foo.bar:input proposal *structurally* prevents name all crispy clear now. Phew! Sometimes, when there's a lot of background, producing a clear explanation is not an easy task ;-) Now I'm glad I finally was able to do it, and will make sure this is written in the docs, to avoid the same effort later in the future :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: [VOTE] Naming rule for HTML IDs generated by CForms
Hi all, [X] foo.bar:input (colon, not CSS-friendly because of IE) +1 from me as well. It's the least evil one, it does interfere with the libraries meaning of :, however, since it is in effect hidden from the user, it's okay. Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Hi, [+1] foo.bar:input (colon, not CSS-friendly because of IE) (do people still use IE? ;-) Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On Nov 7, 2005, at 3:26 AM, Sylvain Wallez wrote: Jorg Heymans wrote: Sylvain Wallez wrote: The initial foo.bar:input proposal *structurally* prevents name all crispy clear now. It was clear then. As always there are trade offs. In this case Its between possible naming conflicts and a CSS incompatibility (bad practices aside) in 90% of users browsers. Which error will be easier to detect? Which is most likely to affect users? Phew! Sometimes, when there's a lot of background, producing a clear explanation is not an easy task ;-) Now I'm glad I finally was able to do it, and will make sure this is written in the docs, to avoid the same effort later in the future :-) as opposed to sooner in the future? ;-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: So please choose one proposal below: [X] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Andrew Savory wrote: Hi, [+1] foo.bar:input (colon, not CSS-friendly because of IE) (do people still use IE? ;-) only a 90% minority does :) -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Ezkovich Glen wrote: snip/ Phew! Sometimes, when there's a lot of background, producing a clear explanation is not an easy task ;-) Now I'm glad I finally was able to do it, and will make sure this is written in the docs, to avoid the same effort later in the future :-) as opposed to sooner in the future? ;-) Sooner or later, it all depend on when that doc will be written :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[VOTE] Naming rule for HTML IDs generated by CForms
Hi all, In order to finally get 2.1.8 out, we have to define once the naming rule for HTML IDs generated by the CForms stylesheets. Let's give some background for those who haven't followed the discussion. CForms stylesheets produce container elements for fields, that include the input itself and other information such as the validation error, help popup, calendar icon, etc. So a widget whose full name is e.g. foo.bar (field bar in group foo) would be output as: span id=foo.barinput name=foo.bar id=foo.bar:input (help, cal, etc.) /span We see here a generated id for the input. The question is what name rule should be used to produce generated IDs, not only for this input, but also for the help, calendar, and any other synthetic elements created by the stylesheets. The main point being that this rule *must* ensure that generated IDs can never conflict with widget full names (e.g. foo.bar-input would potentially conflict with a bar-input widget sibling of bar). To find this naming rule, we have to consider that: - widget names cannot contain the '/', '.' and ':' characters. - HTML IDs must begin with a letter [1] although XML IDs can also start with '_' and ':' [2] - we should be able to use generated IDs in CSS rules. We've seen that IE requires ':' to be written using the '\3A' unicode escape which isn't really user friendly. There has been a number of proposals, and a number of different opinions about them. So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Cast your votes! Sylvain [1] http://www.w3.org/TR/REC-html40/types.html#type-id [2] http://www.w3.org/TR/REC-xml/#id -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [X] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) My preference was for ':' but IE makes it not convenient. I also think that using '_' will go in our way in the future, as we'll use more and more direct mapping of forms with other entities, and '_' is allowed at the beginning of identifiers in most programming languages whereas '.' is not, as it's a kind of universal combining char (Java, JS, SQL, Python, Ruby, etc). Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Sorry for stepping in very late, but to me all of these solutions look rather ugly. If I only have the choice between the four from above, I would go for the underscore solution. But why can't we just use bar-input and forbid to use id's that end with -input? Or forbid the use of '-'? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Carsten Ziegeler wrote: Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Sorry for stepping in very late, but to me all of these solutions look rather ugly. If I only have the choice between the four from above, I would go for the underscore solution. But why can't we just use bar-input and forbid to use id's that end with -input? Or forbid the use of '-'? Oh please, go read the threads. We cannot forbid - in widget names, as it's used in too much occasions. And the problem is not only -input but also -cal, -help, -toolbar, -combobox, -resize-handle or -whatever will come out from advanced stylings. So we need a *general* rule for all generated IDs that ensures no one will ever conflict with widget names. We then structurally avoid and problem in the future, whatever mapping people invent between a widget and its HTML rendering. Also, if you read the thread, you will notice that this notation is almost transparent to _user_ (not styling writers) as the use of these generated IDs will mostly be restricted to plug additional behaviour to inputs and in that case they can use form.inputs['foo.bar'] which is totally independent from the naming rule used. The other case where these IDs may be used is for CSS rules, but I consider that this will be very unfrequent as most often, CSS class selectors will be used to style a whole family of widgets rather than individual ones, for which they can use a specific class anyway. And even for an individual widget, it's IMO better to define an additional CSS class rather than using the full ID, as it decouples class rules from widget names. My initial proposal, using ':' was IMO the cleanest, but some issues were raised with the way this character has to be escaped in CSS rules with IE. Even if, again, I think CSS class selectors will be used much more often than CSS ID selectors. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Sorry for stepping in very late, but to me all of these solutions look rather ugly. If I only have the choice between the four from above, I would go for the underscore solution. But why can't we just use bar-input and forbid to use id's that end with -input? Or forbid the use of '-'? Correcting some typos that may lead to confusion... Oh please, go read the threads. We cannot forbid - in widget names, as it's used in too much occasions. And the problem is not only -input but also -cal, -help, -toolbar, -combobox, -resize-handle or -whatever will come out from advanced stylings. So we need a *general* rule for all generated IDs that ensures no one will ever conflict with widget names. We then structurally avoid and problem in the future, whatever mapping people invent between a widget and its HTML rendering. ... will avoid _any_ problem... Also, if you read the thread, you will notice that this notation is almost transparent to _user_ (not styling writers) as the use of these generated IDs will mostly be restricted to plug additional behaviour to inputs and in that case they can use form.inputs['foo.bar'] which is totally independent from the naming rule used. ... will mostly be _limited_ to plugging additional behaviour ... : there is no structural restriction, but the simple observation of the frequent use cases. The other case where these IDs may be used is for CSS rules, but I consider that this will be very unfrequent as most often, CSS class selectors will be used to style a whole family of widgets rather than individual ones, for which they can use a specific class anyway. And even for an individual widget, it's IMO better to define an additional CSS class rather than using the full ID, as it decouples class rules from widget names. My initial proposal, using ':' was IMO the cleanest, but some issues were raised with the way this character has to be escaped in CSS rules with IE. Even if, again, I think CSS class selectors will be used much more often than CSS ID selectors. Yeah. I more and more think we should use ':' and ask people to use CSS class rules instead of ID rules. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote:
[X] foo.bar:input (colon, not CSS-friendly because of IE)
[ ] foo.bar..input (double period)
[ ] foo.bar.input. (trailing period)
[ ] foo.bar._input (underscore, requires to forbid it as the beginning
of widget names)
Cast your votes!
As I would never use CSS rules based on IDs as they are a moving target IMHO I
don't have a problem with it. And if I really had to, there is at least some
workaround IIUC. The other options are really ugly. So +1 for the first.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On Nov 6, 2005, at 2:51 AM, Sylvain Wallez wrote: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [X] foo.bar._input (underscore, requires to forbid it as the beginning of widget names)
Re: [VOTE] Naming rule for HTML IDs generated by CForms
* Sylvain Wallez: The main point being that this rule *must* ensure that generated IDs can never conflict with widget full names (e.g. foo.bar-input would potentially conflict with a bar-input widget sibling of bar). Then why don't you use a « reserved » keyword inbetween, such as « bar-___reserved_cforms_input___ »? -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: [x] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Jorg
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Sorry for stepping in very late, but to me all of these solutions look rather ugly. If I only have the choice between the four from above, I would go for the underscore solution. But why can't we just use bar-input and forbid to use id's that end with -input? Or forbid the use of '-'? Oh please, go read the threads. We cannot forbid - in widget names, as it's used in too much occasions. Sigh, how do you know that people are not using ':' in their widget ids? Which is starting with 2.1.8 not allowed any more...so as we don't have problems with not allowing the ':' character in ids, I don't see a reason why we should handle the '-' differently? Anyways, this whole id thing is really a pita and suggestions like a double period or trailing period are absolutely not userfriendly. It doesn't matter how often you have to use them. So, for clearness, I would go for a different solution but as this vote is only about the four suggestions my vote is: [X] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Carsten Ziegeler wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: So please choose one proposal below: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Sorry for stepping in very late, but to me all of these solutions look rather ugly. If I only have the choice between the four from above, I would go for the underscore solution. But why can't we just use bar-input and forbid to use id's that end with -input? Or forbid the use of '-'? Oh please, go read the threads. We cannot forbid - in widget names, as it's used in too much occasions. Sigh, how do you know that people are not using ':' in their widget ids? Which is starting with 2.1.8 not allowed any more...so as we don't have problems with not allowing the ':' character in ids, I don't see a reason why we should handle the '-' differently? Anyways, this whole id thing is really a pita and suggestions like a double period or trailing period are absolutely not userfriendly. It doesn't matter how often you have to use them. So, for clearness, I would go for a different solution but as this vote is only about the four suggestions my vote is: [X] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) I know we are under pressure to release 2.1.8 really soon. I think this decision is really important. It impact the whole cforms framework. Hence, if you have a more elegant idea, please share it with us. :-) Best Regards, Antonio Gallardo.
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Il giorno 06/nov/05, alle ore 11:51, Sylvain Wallez ha scritto: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ X] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Reinhard Poetz wrote: Sylvain Wallez wrote: [X] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ ] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Cast your votes! As I would never use CSS rules based on IDs as they are a moving target IMHO I don't have a problem with it. And if I really had to, there is at least some workaround IIUC. The other options are really ugly. So +1 for the first. I totally agree with your POV, especially as I envision that Ajax will require us to have form identifiers generated at runtime to allow for several instances of a form definition in a page [1]. So, since the CSS rule problem is what caused all this discussion, and we finally consider that it's not that much a problem... I change my vote: [X] foo.bar:input (colon, not CSS-friendly because of IE, but will actually never been used in CSS rules) Sylvain [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113111500216874w=2 -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Jean-Baptiste Quenot wrote: * Sylvain Wallez: The main point being that this rule *must* ensure that generated IDs can never conflict with widget full names (e.g. foo.bar-input would potentially conflict with a bar-input widget sibling of bar). Then why don't you use a « reserved » keyword inbetween, such as « bar-___reserved_cforms_input___ »? Because I'm concerned by the length of these generated IDs that will clutter up the page. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On 06.11.2005 23:11, Sylvain Wallez wrote: As I would never use CSS rules based on IDs as they are a moving target IMHO I don't have a problem with it. And if I really had to, there is at least some workaround IIUC. The other options are really ugly. So +1 for the first. I change my vote: [X] foo.bar:input (colon, not CSS-friendly because of IE, but will actually never been used in CSS rules) Me too: [X] foo.bar:input Jörg
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On Nov 6, 2005, at 4:13 PM, Sylvain Wallez wrote: Jean-Baptiste Quenot wrote: * Sylvain Wallez: The main point being that this rule *must* ensure that generated IDs can never conflict with widget full names (e.g. foo.bar-input would potentially conflict with a bar-input widget sibling of bar). Then why don't you use a « reserved » keyword inbetween, such as « bar-___reserved_cforms_input___ »? Because I'm concerned by the length of these generated IDs that will clutter up the page. I understand this concern but in general I think distinguishing between auto generated names (ids) and author generated names is a good idea. A convention for auto generated names is to begin them with _. In this case it can conflick with auto-generated widget names. A simple convention for naming in this case could be simply to use something along the lines of foo.bar._cfInput or, since this likely will step on some widget names, foo.bar._agInput (ag for auto- generated). A concern here is that root of the ID is somewhat obscured. An alternative naming would be along the lines of foo.bar.cf_input. While not following the more general convention it comes close. (I'm sure someone will confuse it for a column name ;-).) While there remains clutter it is significantly reduced to 3 characters per id. A minimal amount considering the clarity it brings. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Le 7 nov. 05, à 02:05, Ezkovich Glen a écrit : ...An alternative naming would be along the lines of foo.bar.cf_input. While not following the more general convention it comes close. (I'm sure someone will confuse it for a column name ;-).) While there remains clutter it is significantly reduced to 3 characters per id. A minimal amount considering the clarity it brings... Same feeling here, foo.bar.cf_input Looks more obvious than the punctuation-based proposals, and the increase in ID lengh is only 3 chars. I think punctuation-based rules are too easy to miss when reading the generated code (to debug it at 3AM ;-) -Bertrand
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Bertrand Delacretaz wrote: Le 7 nov. 05, à 02:05, Ezkovich Glen a écrit : ...An alternative naming would be along the lines of foo.bar.cf_input. While not following the more general convention it comes close. (I'm sure someone will confuse it for a column name ;-).) While there remains clutter it is significantly reduced to 3 characters per id. A minimal amount considering the clarity it brings... Same feeling here, foo.bar.cf_input Looks more obvious than the punctuation-based proposals, and the increase in ID lengh is only 3 chars. I think punctuation-based rules are too easy to miss when reading the generated code (to debug it at 3AM ;-) -1: this doesn't avoid conflicts with wiget names, which is the primary goal of this discussion. Although it avoids the problem for fields that don't have child widgets, the problem remains for containers. Let's consider for example a form for a digicam description. The app developer decides to use the cf_ prefix for everything related to CompactFlash storage. He thus adds a cf_size field for the storage capacity. He then puts this information in a group with a fancy styling that allows users to resize panels, and thus generates a cf_size element to handle the client-side interaction. Bang! You have a name conflict! And that one is much more difficult to understand at 3AM as it impacts the definition of the form itself, and only appears with a special combination of widget and styling. The initial foo.bar:input proposal *structucally* prevents name conflicts. They can *never* happen, whatever name you give to widgets and whatever styling you put around them. The only weak point of this proposal is ID selectors in CSS because of IE. Now we've seen in the discussion that it's a bad practice anyway as it links the CSS to the form model, and that changing the form model then not only requires to change the template, but also the CSS. So I kindly ask people to carefully read and understand the rationale and motivation behind ':'. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
