You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/11/05 00:26:49 UTC
Other ID naming proposals (was Re: CForms widget ID naming)
Antonio Gallardo wrote:
> Sylvain Wallez wrote:
>> The ":" has been a valid character for ID in HTML and XML for years:
>> - http://www.w3.org/TR/REC-html40/types.html#type-id
>> - http://www.w3.org/TR/REC-xml/#id
>>
>> The CSS specification says how to use '\' to escape special characters:
>> - http://www.w3.org/TR/REC-CSS2/syndata.html#q4
>>
>> So writing a CSS rule for the input of widget "foo" should be
>> "#foo\:input { .... }"
>>
>> However, f*cking IE goes in the way, and although it properly escapes
>> '.' (used for container widgets), it is the only one among the 4
>> browsers I tested that doesn't understand '\:'. That means that the
>> '\3A' unicode escape sequence must be used.
>
>
> Happens to be that the 1 of the 4 tested, the IE is btw, the one with
> more than 90% of the market share! :-)
>
> Reading the above, I realized it directly affect the cocoon learning
> curve. If we imlement this way a cocoon newbie will need to know that
> when they want to code '\:' as '\3A'. I can see a lot of wasted hours
> dedicated to debug this. And this directly impact the overall user
> perception of cocoon.
>
> Seems to be like "another brick" in the "cocoon learning" wall. ;-)
Ok. Even if I don't think these CSS rules will be used often, you're
right that the IE quirk will go in the way of people.
Let's recap the various aspects of the problem:
- generated IDs should not be valid widget full names, to avoid any
potential conflict,
- this isn't just about the <input>, but about a common rule for all
generated IDs
- an HTML ID can contain letters, digits, underscores '_', colons ':'
and periods '.'.
- because of lookup paths, a widget ID cannot contain '/' nor '.'.
Libraries also add ':' to the forbidden characters.
Since '.' is used as the combination character to build full names, I
thought ':' was a good choice. Now it leads to some (unjustified) fears
about namespace prefixes, and requires a weird CSS syntax.
A thing that wasn't formally said up to now is that a widget name *must*
be a valid HTML/XML identifier. XML is more permissive as it allows
(letter | '_' | ':') as the first character, whereas HTML requires the
first character to be a letter. So a widget name *must* start with a
letter (top-level ones, actually).
So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
fd:field in a fd:group) and the ID of its <input>.
- "foo.bar..input": the '.' is doubled, which can never conflict with a
widget's full name
- "foo.bar._input": generated element's name starts with a character
that we can forbid as the first character of widget names
I prefer the first one (double '.') which is IMO more readable than the
second.
Other ideas?
Let's make a choice and have 2.1.8 out!
> Is there another solution? I like AJAX. I want to have AJAX. I know
> your are a brilliant programmer. For this reason I am pretty sure you
> can come with a more elegant solution! :-)
Well, as I said in my answer to Jörg, my guess is that Ajax will lead
people to use CSS rules with classes rather than IDs. But I made other
proposals above, so let's choose one.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2005-11-05 at 11:20 +0100, Ugo Cei wrote:
> Il giorno 05/nov/05, alle ore 08:46, Sylvain Wallez ha scritto:
>
> >> So let's make other proposals. Let's consider wiget
> >> "foo.bar" (e.g. a fd:field in a fd:group) and the ID of its <input>.
> >> - "foo.bar..input": the '.' is doubled, which can never conflict
> >> with a widget's full name
> >> - "foo.bar._input": generated element's name starts with a
> >> character that we can forbid as the first character of widget names
> >>
> >> I prefer the first one (double '.') which is IMO more readable
> >> than the second.
> >
> > Another one, which looks more natural: "foo.bar.input.": the
> > trailing '.' ensures it cannot conflict with a widget's full name
>
> The fact that it is not that readable might be a plus. The problem
> with double dots or a dot at the end is that it's easy to miss when
> reading the code. an extra '_' sticks out more and won't be missed as
> easily.
agreed, +1 for the underscore
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 05/nov/05, alle ore 08:46, Sylvain Wallez ha scritto:
>> So let's make other proposals. Let's consider wiget
>> "foo.bar" (e.g. a fd:field in a fd:group) and the ID of its <input>.
>> - "foo.bar..input": the '.' is doubled, which can never conflict
>> with a widget's full name
>> - "foo.bar._input": generated element's name starts with a
>> character that we can forbid as the first character of widget names
>>
>> I prefer the first one (double '.') which is IMO more readable
>> than the second.
>
> Another one, which looks more natural: "foo.bar.input.": the
> trailing '.' ensures it cannot conflict with a widget's full name
The fact that it is not that readable might be a plus. The problem
with double dots or a dot at the end is that it's easy to miss when
reading the code. an extra '_' sticks out more and won't be missed as
easily.
Ugo
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.11.2005 08:46, Sylvain Wallez wrote:
>> So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
>> fd:field in a fd:group) and the ID of its <input>.
>> - "foo.bar..input": the '.' is doubled, which can never conflict with
>> a widget's full name
>> - "foo.bar._input": generated element's name starts with a character
>> that we can forbid as the first character of widget names
>>
>> I prefer the first one (double '.') which is IMO more readable than
>> the second.
>
> Another one, which looks more natural: "foo.bar.input.": the trailing
> '.' ensures it cannot conflict with a widget's full name
I definitely prefer the ones which can not conflict with other widget's
full name instead of forbidding another character. Your last proposal
with trailing dot is the one I like most.
Jörg
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Sylvain Wallez wrote:
>> So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
>> fd:field in a fd:group) and the ID of its <input>.
>> - "foo.bar..input": the '.' is doubled, which can never conflict with
>> a widget's full name
>> - "foo.bar._input": generated element's name starts with a character
>> that we can forbid as the first character of widget names
>>
>> I prefer the first one (double '.') which is IMO more readable than
>> the second.
>
> Another one, which looks more natural: "foo.bar.input.": the trailing
> '.' ensures it cannot conflict with a widget's full name
>>
>> Other ideas?
>>
>> Let's make a choice and have 2.1.8 out!
For me the solution with a leading '_' seems more natural, since it is
easier to distinguish from other IDs (imagine user posts which describe
their problems and miss the trailing '.') and it has the common semantic
of an 'internal thing', like private variables are often named after
(e.g. C/C++ and other languages).
Andreas
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 5 nov. 05, à 08:46, Sylvain Wallez a écrit :
> ...Another one, which looks more natural: "foo.bar.input.": the
> trailing '.' ensures it cannot conflict with a widget's full name...
I also like this option better.
-Bertrand
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Antonio Gallardo wrote:
>> Sylvain Wallez wrote:
>>> The ":" has been a valid character for ID in HTML and XML for years:
>>> - http://www.w3.org/TR/REC-html40/types.html#type-id
>>> - http://www.w3.org/TR/REC-xml/#id
>>>
>>> The CSS specification says how to use '\' to escape special characters:
>>> - http://www.w3.org/TR/REC-CSS2/syndata.html#q4
>>>
>>> So writing a CSS rule for the input of widget "foo" should be
>>> "#foo\:input { .... }"
>>>
>>> However, f*cking IE goes in the way, and although it properly
>>> escapes '.' (used for container widgets), it is the only one among
>>> the 4 browsers I tested that doesn't understand '\:'. That means
>>> that the '\3A' unicode escape sequence must be used.
>>
>>
>> Happens to be that the 1 of the 4 tested, the IE is btw, the one with
>> more than 90% of the market share! :-)
>>
>> Reading the above, I realized it directly affect the cocoon learning
>> curve. If we imlement this way a cocoon newbie will need to know that
>> when they want to code '\:' as '\3A'. I can see a lot of wasted hours
>> dedicated to debug this. And this directly impact the overall user
>> perception of cocoon.
>>
>> Seems to be like "another brick" in the "cocoon learning" wall. ;-)
>
> Ok. Even if I don't think these CSS rules will be used often, you're
> right that the IE quirk will go in the way of people.
>
> Let's recap the various aspects of the problem:
> - generated IDs should not be valid widget full names, to avoid any
> potential conflict,
> - this isn't just about the <input>, but about a common rule for all
> generated IDs - an HTML ID can contain letters, digits, underscores
> '_', colons ':' and periods '.'.
> - because of lookup paths, a widget ID cannot contain '/' nor '.'.
> Libraries also add ':' to the forbidden characters.
>
> Since '.' is used as the combination character to build full names, I
> thought ':' was a good choice. Now it leads to some (unjustified)
> fears about namespace prefixes, and requires a weird CSS syntax.
>
> A thing that wasn't formally said up to now is that a widget name
> *must* be a valid HTML/XML identifier. XML is more permissive as it
> allows (letter | '_' | ':') as the first character, whereas HTML
> requires the first character to be a letter. So a widget name *must*
> start with a letter (top-level ones, actually).
>
> So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
> fd:field in a fd:group) and the ID of its <input>.
> - "foo.bar..input": the '.' is doubled, which can never conflict with
> a widget's full name
> - "foo.bar._input": generated element's name starts with a character
> that we can forbid as the first character of widget names
>
> I prefer the first one (double '.') which is IMO more readable than
> the second.
Another one, which looks more natural: "foo.bar.input.": the trailing
'.' ensures it cannot conflict with a widget's full name
>
> Other ideas?
>
> Let's make a choice and have 2.1.8 out!
>
>> Is there another solution? I like AJAX. I want to have AJAX. I know
>> your are a brilliant programmer. For this reason I am pretty sure you
>> can come with a more elegant solution! :-)
>
> Well, as I said in my answer to Jörg, my guess is that Ajax will lead
> people to use CSS rules with classes rather than IDs. But I made other
> proposals above, so let's choose one.
>
> Sylvain
>
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director