Relying on CSS that uses ids, rather than classes, will give you all kinds
of issues integrating it all together. It may render faster on the client,
I don't know.
It's possible to hook into Tapestry and "pre-register" all those ids that
can cause conflicts. Tapestry will then not use them, and wi
I suggest that component authors use the code I gave you. I also suggest to
style by class instead of by id since the clientId should be a dynamic,
runtime value that is not known at build time.
If components have a static clientId, they can not (legally) be used in a
loop.
Thanks Lance,
These options are all great... helpful. I am interfacing with the author and
trying to communicate what I have identified is a show stopper for the users of
their library.
I think some rules of thumb need to be agreed upon especially with regard to
owness.
So it should really be
It's invalid html to have two elements with the same id so it will need to
be fixed.
Have you considered styling your CSS by "class" instead of by "id"?
Thanks Lance,
Thats helpful information.
I have a case where explicit raw usage of those ID's header, nav, main... are
being used right within a CSS file or even in explicit style .
So my layout is being blown off the map... (oops page).
I still am wondering what solution I should impose.
Tha
Most tapestry components take the approach of using the "id" parameter (not
to be confused with t:id) if one is provided. If an "id" is not provided, a
clientId is generated which is guaranteed not to clash with other id's on
the page.
public class MyComponent implements ClientElement {
@Enviro
