On May 7, 2007, at 6:35 AM, Ian Charnas wrote:
> http://trac.turbogears.org/ticket/1383
>
> Some discussion might be necessary on this. Basically in xhtml the
> "id" attribute is defined by the w3c as....
>
> ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
> followed by any number of letters, digits ([0-9]), hyphens ("-"),
> underscores ("_"), colons (":"), and periods (".").
>
> However, currently the "valid_id" regular expression on line 55 of
> core.py only accepts alphanumeric characters. Although periods and
> colons are not often used, I use the hyphen and underscore all the
> time. Allowing elements to have ids with underscores might confuse
> toscawidgets though, because it seems that's how toscawidgets keeps
> track of compound widgets. Not really sure what a solution would be,
> I imagine this must have come up before???
On May 7, 2007, at 8:18 PM, Ian Charnas wrote:
>
> Hyphens and Underscores are definitely included in the specs, and I
> haven't run across a good argument that would urge us not to use
> them. Colons and periods however, *are* problematic because they are
> also special characters in CSS selectors, as I believe Jorge was
> pointing out. The period denotes a css class, and the colon denotes a
> pseudo-class or a pseudo-element. I haven't seen any webmasters using
> periods and colons as part of an id... which gives us an interesting
> option. Currently, underscores are used to form the ids of compound
> widgets. If we switched that to periods (or colons), we would open up
> the door for people to use underscores in ids, without losing anything
> in the process. This would however, potentially break some people's
> css, if they had used the existing underscore-laden id fields as css
> selectors in their css.
There's no problem in using underscores in widget ids but there are
two problems with using hyphens or dots:
1) First (and least important) is that accessing child widgets as
attributes of widget.c will not work:
mywidget.c.some-id-with-hyphens
This however can easily be worked around by the fact that the object
at the "c" attribute implements __getitem__:
mywidget.c["some-id-with-hyphens"]
2) The biggest problem is that FE's NestedVariables [1] will
completely break since it uses dots and hyphens to decode the nested
structure generated on the form field widgets' names (which are
derived from the ids). However, this should be solvable because those
separators are configurable. To go this route we just need to decide
on two "reserved" chars to act as separators that are w3c compliant
too. The regexp should not allow them to be used for input names to
avoid confusion.
>
> Of course, an even better option (if possible) would be to force
> people to use ids for their widgets that are unique throughout a
> page. There are a number of difficulties in this however (repeating
> fields pose a challenge, extra work needed to find parents/children of
> widgets)
TW tries to ease this job by generating ids automatically taking into
account their position in the tree, for example, a coumpund widget
with a button with id "btn" would be mangled to "mywid_btn" so you
could have two of these compound widgets in the same page with no
collisions as long as all widgets in the same nesting level and
rooted at the same widget/page have distinct ids. The autogenenrated
id can always be accessed at the widget's "id" attribute (unlike TG
widgets where this info is only available during a request)
>
> Alberto, could you comment on the idea of switching from underscores
> to periods for compound widget ids?
I've initially implemented the compund-widget-id-building using dots
but changed back to underscores (like TG widgets are) since jQuery
choked on things like:
jQuery("#foo.bar")
I guess because it interprets the dot as a CSS class selector.
I've aplied your patch to try it out but it breaks two tests related
to widget names beginning with an underscore (which was asked for in
another ticket). It would be solved by tweaking the regexp to allow
ids beginning with an underscore though it would not follow the
spec... anyway, the spec should take preference over that ticket I
guess so I'll have to change those tests.
Alberto
[1] http://formencode.org/Validator.html#http-html-form-input
BTW, crossposting to toscawidgets-discuss. Let's please move this
thread there since there are TW users subscribed there who might not
be in TG trunk and a, most probable, change that might break their
apps will surely be of interest to them :)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
