XUL:New Widgets: Difference between revisions
Jump to navigation
Jump to search
(html:a) |
mNo edit summary |
||
| Line 10: | Line 10: | ||
Answering NeilRashbrook's [[XUL:Priority_List#Priority_5|question]], <html:a> can't be used as is because: | Answering NeilRashbrook's [[XUL:Priority_List#Priority_5|question]], <html:a> can't be used as is because: | ||
* it isn't even visible when used used as <code><html:a href="about:">some text</html:a></code> | * it isn't even visible when used used as <code><html:a href="about:">some text</html:a></code> | ||
** (Neil) That's what you get for mixing box models. But you should be using <xul:label> or <xul:description>, not <html:p>. | |||
* not styled properly, if you get it to show by enclosing it in a <html:p> tags | * not styled properly, if you get it to show by enclosing it in a <html:p> tags | ||
* and opening the link in the same (often chrome) window when clicked. | * and opening the link in the same (often chrome) window when clicked. | ||
** (Neil) I suggested to bz that chrome URI content listeners should not offer to handle link clicks, although that's not possible the way URI content listeners currently work. | |||
Revision as of 16:40, 1 June 2005
Slider
Description of a <slider> tag. XUL already has one as part of the scrollbar but it needs a useful API and theme styling (especially native-theme styling). (NeilRashbrook) Note that the Mac still uses native scrollbars.
Link
Widget similar to HTML <a> element. Currently this can be/is implemented in a rather ugly way (in Extension Manager code): styling the label element in a special way + making it focusable and implementing oncommand/onkeypress.
Answering NeilRashbrook's question, <html:a> can't be used as is because:
- it isn't even visible when used used as
<html:a href="about:">some text</html:a>- (Neil) That's what you get for mixing box models. But you should be using <xul:label> or <xul:description>, not <html:p>.
- not styled properly, if you get it to show by enclosing it in a <html:p> tags
- and opening the link in the same (often chrome) window when clicked.
- (Neil) I suggested to bz that chrome URI content listeners should not offer to handle link clicks, although that's not possible the way URI content listeners currently work.