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
