[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bugs #8895] REQ : Change to handling of Dynamic elements
From: |
Simon Stapleton |
Subject: |
[bugs #8895] REQ : Change to handling of Dynamic elements |
Date: |
Wed, 12 May 2004 04:34:22 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/124 (KHTML, like Gecko) Safari/125.1 |
This mail is an automated notification from the bugs tracker
of the project: GNUstep.
/**************************************************************************/
[bugs #8895] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8895>
Project: GNUstep
Submitted by: Simon Stapleton
On: Wed 05/12/04 at 08:33
Category: gsweb
Severity: 5 - Average
Item Group: Change Request
Resolution: None
Assigned to: None
Status: Open
Summary: REQ : Change to handling of Dynamic elements
Original Submission: I'm currently putting together a website that uses title
attributes heavily (accessibility and all that), and as a result I'm putting
together a lot of dynamic elements.
I would like, for example, to use the title attribute of an input field to
indicate error status. However, once I've created the element, I can't get to
its attributes, which become part of the htmlBareStrings. I could deal with
the attribute locally, but then I have to redo appendToRequest:inContext:. It
seems to me that it would be nice to be able to 'get at' the bare strings in a
more accessible way, and to mutate them during the lifetime of the element.
I've found that if I add an element to htmlBareStrings and then call parent
appendToRequest:inContext:, the number of elements doesn't change, and I lose
the end tag.
So.
I propose changes to GSWHTMLDynamicElement as follows:
First off, have an 'isStandalone' flag so we can make standalone tags generate
the proper closing (See my other bug)
Next up, rip all the non-element attributes (i.e. those that would generate
static attributes within the tag itself) into a dictionary, and redo the
'drawing' code to use this instead of the current static string that is built.
that way, I can override appendToResponse:inContext: to create a new attribute
dictionary 'on the fly', temporarily replace the existing dictionary, call
superclass drawing code, then replace the original dictionary.
Would this work?
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8895>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bugs #8895] REQ : Change to handling of Dynamic elements,
Simon Stapleton <=