I'm +1 for including an ID. Sure, issues should be addressed in the main silo code. But some code (such as for Twitter forms) really don't belong in the core code.
Adding the ID allows that decision to be made on a case-by-case basis. On Mar 2, 2009, at 12:08 AM, Michael Harris wrote: > > #450 discusses the addition of a class (but more likely an id) to > silos in the media splitter, such as id="silo_flickr". This isn't > technically hard, so it would be nice to either fix it or wontfix with > a reason why not. > > Arguments against: > * media silos are supposed to provide a unified interface, and so > shouldn't need to be addressed for CSS, so custom CSS may actually > decrease their usefulness. > * if something is broken, it should be fixed in the underlying > implementation, not hidden by CSS. > * custom CSS and JS should be resisted in order to generically improve > the underlying silo implementation. > > Arguments for: > * obviously, custom CSS and JS can be used in a silo. For example, a > silo might include custom forms, like the Twitter silo does, that > might benefit from CSS (to make the form pretty) or JS (for instance, > autocomplete on names). > > Does anyone have any thoughts on this, with the aim of moving > towards closing ? > > -- > Michael C. Harris, School of CS&IT, RMIT University > http://twofishcreative.com/michael/blog > IRC: michaeltwofish #habari > > > --~--~---------~--~----~------------~-------~--~----~ 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/habari-dev -~----------~----~----~----~------~----~------~--~---
