Give every element an ID

jasonl · Post by **jasonl** » November 6th, 2002, 1:30 pm

I put this up in the old phorum but before I could check for responses it closed down. So, I thought I would put it up here too.

I would love it if phoenix could give every button, menu, menu item, menu pop, etc. an ID. There are still a handful of items out there that don't have IDs (at least in Mozilla so I am assuming the same is true with phoenix). This isnt a major problem for most people but for those of us that are hacking the code with overlays, it would be nice to have. I have an add-on for mozilla that does this and with every new build or release I have to go back in and edit a bunch of files. I am planning on making my add-on work with phoenix but this feature would be nice since the version will be changing so much. I filed a bug with mozilla but it doesnt look like it will be resolved any time soon if ever. I would be willing to generate the list of items without ids and even give them ids if somebody designing phoenix would like me to. Thanks...

~Jason

clav · Post by **clav** » November 6th, 2002, 2:16 pm

Bug 170243 is kind of related to this

grayrest · Post by **grayrest** » November 6th, 2002, 8:45 pm

I'd like to see this as well. Advanced skins also need ids on stuff because there's no way to work around it with js.

John Angelico · Post by **John Angelico** » November 14th, 2002, 3:52 pm

THanks for putting this up Jason.

I am looking at this from a user angle too.

In NS4.61 on OS/2 I can identify Forms elements and build an app that feeds data into a form.

However, Moz and Phoenix don't have unique IDs for Form elements so I can't do that any more.

Since the site is critical to my business (credit card payments lodgement from my customers), I have to stay with NS4.61 just so I can feed data to the form.

grayrest · Post by **grayrest** » November 15th, 2002, 11:42 am

He's not talking about content area stuff having an id, he's referring to the chrome/skin. In phoenix the engine renders both the UI and the content. We'd like every chrome element to have an id, as this makes it much easier to do add-ons.

John Angelico · Post by **John Angelico** » November 15th, 2002, 7:28 pm

Yes, I realise that he was focussing on development and chromes/skins.

But I wanted to deliberately *add* my reference to the page content elements being uniquely addressable because I believe the same factors are involved, and there are user/developer/application benefits available there too.

michel v · Post by **michel v** » November 16th, 2002, 12:34 pm

John, isn't that an issue with the page itself then?

John Angelico · Post by **John Angelico** » November 19th, 2002, 3:18 pm

Yes, I guess it is an issue with the page itself.

But it started as a question about addresssing all the elements in a Moz window, and the page itself is still a sub-class of all the upper level classes right up to the outermost frame.

Therefore I believe my question is related to the original post, because we are all wanting to identify/label/access elements of the entire window, albeit for different purposes.

So to summarise what I see as the essential questions:

1. Is this working as designed or is it a bug of some sort?

2. Do the designers of Moz/Phoenix intend us not to access elements within the overall frame?

3. How have they considered the two cases we have here:
a) addressing elements at the chrome level to simplify alternative skinning
b) addressing elements at the page/form level to be able to feed data into input fields
?

4. Are there any other aspects of the frame needing labels for accessing sub-elements?

HTH

darksheer · Post by **darksheer** » November 19th, 2002, 3:21 pm

I may be off-base here, but for elements within the page, shouldn't the DOM handle this?

Give every element an ID

Give every element an ID

Element IDs

Element IDs

Element IDs