How should the text on the button in the search box be labelled, “search” or “find”?
I could not find an answer on useit.com but I guess Nielsen must have looked into this question. From my own experience I would say “find” is an “Apple”-term (it’s called “finder” you know ) but “search” is not necessarily a “Windows”-term (although used in the explorers search box). From this alone I would think “search” is the term most people are accustomed to. Another reason to think the mainstream is using “search” (and therefore making more sense for websites that have a large and diverse target group) is that Google is using “Google search” for their button (in german too BTW). I guess I would therefore recommend using “find” only for websites targeting Apple users?
Do you have any data which label would be better?
I just noticed (looking at cssutils source) that Google has updated its “Source” tab. A quite usable SVN viewer (“Browse”) is available now as well as a “Changes” view. Very nice.
I finally managed to squeeze out a new alpha release of cssutils. I mainly implemented namespaces with all their implications. Namespace rules have been parsed for some time now but until now it was quite easy to build style sheets which were invalid regarding namespace usage. This should be difficult now as all namespaces are checked if they are used before deletion or it is checked if they are declared before adding a new rule or selector.
Actually adding a rule should be much simpler now as I added a new method
CSSStyleSheet.add(rule) which adds a rule at the appropriate position in the sheet. Until now one had to use
.insertRule(rule, index) which now has a new parameter
inOrder=False which may be used the same way as
.add(rule) but the new method is still much simpler as only the rule to add needs to be given, no
index (which could be
None and meant “at the end” until now) but also no setting of
All in all this release made me quite a few headaches as the namespaces had to be checked all the way from a selector using them via the relevant selectorList, CSSStyleRule, possible CSSMediaRule upto CSSStyleSheet. I also implemented analogous to
CSSStyleSheet.encoding which reflects a CSSCharsetRule
.namespaces which reflects all CSSNamespaceRules.
I also added quite a few tests which actually revealed quite a few embarrassing bugs…
The next steps before a final 0.9.5 release will probably be the improvement of the csscombine script and a first implementation of ViewCSS. Actually a prototype is already in the SVN in examples/style.py. It uses lxml (which just got to 2.0) but it should be quite easy to use other libs. Maybe I finish these works till the end of the month, let’s see…
Maybe just coincidence but at least two Python libraries (or tools) I frequently use just got or soon get a new release
- Epydoc, a Python package documentation tool just released v3.0
- lxml is close to 2.0 (2.0b2 is out and final 2.0 should be out latest next week)
maybe coincidence but maybe also because Pycon is coming up…
On a side note, cssutils will probably have a new release in the next week or two as well
UPDATE: lxml just got a definite 2.0 release.
Very interesing notes by Eric van der Vlist about HTML5 versus XHTML 2.0. I did not partake in the WHATWG (which would be an option – I know) nor do I know both specs in every detail but still I think I may have an opinion on the matter as I did read quite a lot about both and as a web developer have quite a lot of experience with HTML 4 (and it s obvious shortcomings of course) but also XHTML and even XHTML 2 which I used for a little project just to see if it is usable.
There are a few areas where both specs basically want the same, like removing older and unneeded, unused or misunderstood elements or attributes so both try to clean the cruft off HTML4.
I do think XHTML 2.0 seems a bit better in its concept e.g using @role for certain elements instead of HTML5s approach of introducing quite a few new elements so having a better forward compatible notion I guess (Erics comparison with Docbook is very convincing).
On the other hand HTML5 at first seems easier for authors as it does not use the strict XML syntax XHTML wants. (Also HTML5s Webforms are not as revolutionary as XForms, that probably is for another discussion).
What I did not know is that this strictness of XML is not specified as as strict as implemented currently (see the article for a nice overview). So it seems thinkable to have an XML syntax for XHTML 2 which is usable for almost everybody and not just the <irony>strange people</irony> (like me) who actually care about standards…
All in all I don’t think one of both specs is much better and should win (like HD-DVD versus Blu-Ray ) but one could think of a mixed vocabulary taking the best of both ideas. Just some ideas:
- use XHTML 2 <section> and <h> and @role instead of HTML4 <article>. <section> is in both I think but there are too many elements in HTML5 already (are <aside> , <header>, <footer> or <dialog> really necessary?)
- use HTML5 video/audio elements (<object> does seem to have failed somehow).
- use HTML5 forms but make XForms available in its own namespace (putting XForms into XHTML 2 is not the best idea but this way it is available if wanted or needed). HTML5 forms could then be as default, XForms if you really need the extra power of XForms. Maybe HTML5 forms could be made a bit simpler in this case – <datagrid>? (please don’t take this point too hard, I know XForms better than WebForms)
- use the XML syntax and DOM and therefor do not loose the ability to treat HTML5 with all the XML techniques and libs available: XPath, XSLT, XQuery, adding other vocabularies via namespaces like RDF, Microformats etc
- use XHTML2 meta data ideas (the simple triples) which I think are a great way to add semantics but simple (compare RDF…)
- make the resulting format be parsed in browsers with a more forgiving (but well defined in the scope of XML or even more defined) parser and behaviour
I think the main point that Eric van der Vlist article for me was that it is impossible to imagine all possible use cases or usages for a format during specification so the specification should be as general (not the right term, I can’t think of one now) as possible. This is one area where XTHML 2 is superior and HTML5 seems to look on the uses of the past without making it easy enough to cope with future enhancements. (BTW, as far as I know HTML5 is based on statistical information about e.g. which CSS classes are used most often. This is very important but maybe this point has had too much influence on some of HTML5 decisions? – no personal offense meant!).
I do not think XHTML 2 is perfect so I really think the result should be a mixed vocabulary with a mixture of the best ideas from both specs.