18 Nov
2009
18 Nov
'09
2:09 p.m.
On Nov 18, 2009, at 11:48 AM, Sergiu Dumitriu wrote:
On 11/18/2009 09:29 AM, Vincent Massol wrote:
Maybe one solution is to have a search.vm in colibri so that users can
easily override it in a custom skin? (I wonder if that's easy enough).
(an IX would be great for this btw)
Another solution is to simulate an IX by having a document with the
content and including it in the header (if the doc exists). Only pb is
where to put this doc....
(for me the search feature isn't a mandatory feature for templates (ie
the templates can work without the search feature present). Thus the
content feature can be a dynamic feature coming from some doc)
WDYT?
Thanks
-Vincent
Hi,
Whenever a panel is displayed more than once (ie on the panel page
itself if the page is also displayed in a panel column, in the panel
wizard, etc) we have invalid XHTML for panels that use an HTML ID
attribute. We have this in the search panel right now which I'd like
to fix.
In addition with Colibri we've hardcoded the search panel content in
the header.
Here's what I'd like to do:
1) Use class name of globalsearch and globalsearchinput instead of
IDs
+1
Note: WCAG tests forbid using<label>
without a FOR attribute which
means we need an ID for the input. This can be achieved easily using
velocity to increment a counter. This is a technical internal ID
anyway so it won't matter.
2) In Colibri, use #displaypanel(Panels.Search) instead of hardcoding
the panel content in the header. This allow users to edit the content
for example to change the link to Main/Websearch to Main/LuceneSearch
or do any other thing).
Note: the only change between what is currently in the Search panel
and in the colibri header is the image which can be overwritten in
colibri I guess. A better solution (if someone with CSS skills can
help me) might be to define the image to display in the CSS.
I'm not sure about this. The panel content currently has a
panelhiddenheader macro call, which means that it generates some extra
content besides what is currently in the header. Also, this introduces
side effects: if a user customizes the panel, changes will be
propagated
to the header. IMO the header should not depend on a panel. 3) In the release notes, mention the change and
tell users that if
they want to keep the old behavior (for ex if they have a custom skin
using the globalsearch* IDs) then they just need to edit the Search
panel and replace "class" by "id".
Here's my +1
+1