I was impressed at first, but I now see a major drawback. The pages devour signals and my mouse gestures go berserk. I wouldn’t want to use pages like that for practical purposes.
Rico is pretty nice – it doesn’t work in Safari yet though (they’re promising Safari support in a future release). In the meantime, the Prototype library used in Rails has good Safari support, but currently suffers from an unfortunate lack of documentation.
I was playing with it yesterday (I spotted the link from Veen as well). I was able to put together a simple accordion demo of my own very easily. I just wish that it was more flexible about what types of elements you could use. You have to use <div>s in the whole structure. One of my first experiments was to try defining the title/content bits of my accordion list as an unordered list or definition list. But it only works with divs.
I am curious about the “mouse gestures going beserk comment”. I haven’t seen this. Please feel free to email me at billwscott@gmail.com so that we can understand the issue. There is nothing going on in the page in the background so I am curious as to what this means.
Also, I am curious about whether we need to support other than DIVs. I am open to it but since DIVs are the standard building block for layout in the HTML+CSS world we felt that was the wisest course.
Bill: There are several ways of building the markup for the accordion thing that provide a more logical structure. I can think of four possibilities off the top of my head:
1. Each accordion section header marked up as an h2 (or h3 or whatever level makes the most sense).
2. As a nested list, with the top levels the section headers and the nested ones the inside content.
3. As a definition list – the terms are section headers, the definitions are content.
4. As a set of fieldsets, with the legends defining the headers.
Each of the above could make sense depending on the context in which the accordion effect is used.
To reiterate what I said earlier, and Simon expanded on: I don’t know that I’d say that divs are the standard building block. They are a good generic container for when there isn’t a more semantic option. To me, the accordion widgets would be represented best semantically by a definition list, or as a nested unordered list. Well, actually, an ordered list would probably be more semantic, but practically speaking, there’s little difference, so most of us fall back to unordered lists, because it requires less style hacking 🙂
Anyhow, it shouldn’t be to difficult in most cases to eliminate the need for the containers to specifically be divs. You’ve got a unique id to identify the parent container element. All you need to do from there is walk the tree of child block elements, regardless of what they actually are, right?
Very valid points. We will take this feedback. It is not a big fix to change to other elements.
One of the goals of Rico is to allow us to create Rails, JSP tags, PHP macros, etc. that just generate the elements. That is one of the reasons we settled on kind of the lowest common denominator approach to the HTML.
Thanks.
BTW, be looking for the middle of this next week (around the 28th/June) for us to release a new behavior around tables that hopefully you will find very interesting.
We have added the LiveGrid behavior which allows unlimited data to be viewed in a web page through a normal scroller. Read my Death to Paging blog at: http://looksgoodworkswell.blogspot.com
I’ve just been looking at it, very cool set of demos indeed.
Thanks Matt. I had been looking for drag and drop stuff…
I was impressed at first, but I now see a major drawback. The pages devour signals and my mouse gestures go berserk. I wouldn’t want to use pages like that for practical purposes.
Whew, at first glance from the title, I almost thought there was some racketeering going on. :-p
Rico is pretty nice – it doesn’t work in Safari yet though (they’re promising Safari support in a future release). In the meantime, the Prototype library used in Rails has good Safari support, but currently suffers from an unfortunate lack of documentation.
I was playing with it yesterday (I spotted the link from Veen as well). I was able to put together a simple accordion demo of my own very easily. I just wish that it was more flexible about what types of elements you could use. You have to use <div>s in the whole structure. One of my first experiments was to try defining the title/content bits of my accordion list as an unordered list or definition list. But it only works with divs.
Still though, quite slick.
Excellent feedback.
I am curious about the “mouse gestures going beserk comment”. I haven’t seen this. Please feel free to email me at billwscott@gmail.com so that we can understand the issue. There is nothing going on in the page in the background so I am curious as to what this means.
Also, I am curious about whether we need to support other than DIVs. I am open to it but since DIVs are the standard building block for layout in the HTML+CSS world we felt that was the wisest course.
Thanks!
Bill: There are several ways of building the markup for the accordion thing that provide a more logical structure. I can think of four possibilities off the top of my head:
1. Each accordion section header marked up as an h2 (or h3 or whatever level makes the most sense).
2. As a nested list, with the top levels the section headers and the nested ones the inside content.
3. As a definition list – the terms are section headers, the definitions are content.
4. As a set of fieldsets, with the legends defining the headers.
Each of the above could make sense depending on the context in which the accordion effect is used.
Mihai Bazon’s navbar does that with JS and has good browser compatibility.
To reiterate what I said earlier, and Simon expanded on: I don’t know that I’d say that divs are the standard building block. They are a good generic container for when there isn’t a more semantic option. To me, the accordion widgets would be represented best semantically by a definition list, or as a nested unordered list. Well, actually, an ordered list would probably be more semantic, but practically speaking, there’s little difference, so most of us fall back to unordered lists, because it requires less style hacking 🙂
Anyhow, it shouldn’t be to difficult in most cases to eliminate the need for the containers to specifically be divs. You’ve got a unique id to identify the parent container element. All you need to do from there is walk the tree of child block elements, regardless of what they actually are, right?
Very valid points. We will take this feedback. It is not a big fix to change to other elements.
One of the goals of Rico is to allow us to create Rails, JSP tags, PHP macros, etc. that just generate the elements. That is one of the reasons we settled on kind of the lowest common denominator approach to the HTML.
Thanks.
BTW, be looking for the middle of this next week (around the 28th/June) for us to release a new behavior around tables that hopefully you will find very interesting.
Later,
Bill Scott
We have added the LiveGrid behavior which allows unlimited data to be viewed in a web page through a normal scroller. Read my Death to Paging blog at: http://looksgoodworkswell.blogspot.com