Tres Seaver wrote:
>> I'm pretty sure you're not allowed dots in ids of HTML elements.
> The attached HTML and XHTML pages both pass the W3C validator (one HTMl
> 4.01 strict, the other XHTML 1.0 strict).  Both use dotted IDs for form
> elements.  Neither renders "properly" in Firefox 1.5 (the selectors
> based on the dotted ID, as well as those based on attribute, don't get
> applied the form elements).
>> At 
>> least not when they are prefixed by 'form'. A zope.schema.TextLine in a 
>> formlib form, for example, generates HTML like this:
>>    <input id="form.title" class="textType" type="text" value="Changed 
>> title" size="20" name="form.title"/>
>> In particular, we want to style the fields to look a bit more like 
>> Plone, and we have special cases for "title" and "description" that we 
>> want to style by ID, not class.
>> However, CSS like this has no effect in Firefox or Safari:
>> #form.title {
>>      font-size: 160%;
>>      font-family: <dtml-var headingFontFamily>;
>>      font-weight: normal;
>>      width: 99%;
>> }
>> #form.description {
>>      font: 100% <dtml-var fontFamily>;
>>      font-weight: bold;
>>      height: 6em;
>>      width: 99%;
>> }
>> Not all that surprising - it could look like I'm styling a form with 
>> class="description".
> Not according to the CSS specs.  Note that we might be better off making
> it easy to place a custom CSS class on the widget, rather than fighting
> browser failures on various other selectors.

I had another look at the specs, and I agree that dots should be valid, but
it's pretty horrendous that neither Firefox nor Safari will let me style
that. If I've messed up the CSS syntax, let me know.

- -1 on changing the default behavior;  to paraphrase, "broken browsers
you will have always with you."

+1 on changing 'renderTag' to use some kind of "local" policy (e.g.,
look up an 'ITagElementCleaner' utility) to spply such transforms.

    def renderTag(tag, **kw):
        cleaner = querytUtility(IWidgetTagCleaner)
        if cleaner is None:
            kw = cleaner(kw)

Yeah, this is nicer. I'd be happy to supply a patch for this. It would also
suport the case where you wanted to other "standard" transformations on

I'd like to understand what the chances are of Plone 3 (whch will run on
Zope 2.10.x, whichever is latest when Plone is released in mid-May or a bit
later) being able to depend on this. We may need some kind of monkey patch
in Plone if it can't go into a real Zope release in time,

View this message in context:
Sent from the Zope3 - dev mailing list archive at

Zope3-dev mailing list

Reply via email to