[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Other ID naming proposals (was Re: CForms widget ID naming)
From:       Sylvain Wallez <sylvain () apache ! org>
Date:       2005-11-05 7:46:47
Message-ID: 436C6367.4080708 () apache ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]