see whatever…

jump to menu

May 13, 2008

cssutils ongoings

Filed under: CSS,cssutils — see @ 10:12 pm

I am busy with a few other things so the new release of cssutils is coming up a bit slow.

A few changes (and not even very minor) have been added to trunk and so next beta will have them. I know they should have been in an alpha release but it’s all just tags…

I guess after this beta (maybe I find the time in the next 2 weeks or so) there will even be a “final” release for the current version 0.9.5. There has not been a “final” release of any version since – I really don’t know – maybe 0.5.3? But maybe doing some alphas, betas and a final is better than just leave it with a beta?

Anyway, there is work underway and hopefully a new release this month. (I guess this post is mostly to keep myself actually doing it…)

April 21, 2008

CSS validator on Google AppEngine

Filed under: CSS,cssutils,Python — Tags: , — see @ 10:37 pm

After I got my AppEngine invitation last weekend I put a very simple CSS validator application together (based on the guestbook demo ;) ). No info or style yet and not complete either but I wanted to play around with AppEngine.

One problem is that apps cannot make URL requests via urllib so actually resolving @import rules in given CSS sheets does not work currently. I guess I need to rewrite the underlying cssutils library a bit to actually use Googles urlfetch lib. Seems easy, only missing thing is time ;)

March 24, 2008

cssutils 0.9.5b2

Filed under: CSS,cssutils — see @ 12:40 am

Already a new release. At least the broken features in b1 are fixed. There are a few open ends but nothing that serious.

Also the fixes did not take as much time as expected. And a few other minor fixes are onboard as well. I guess cssutils is getting better and better (still hardly good enough though ;) )

There probably will be one or two further 0.9.5 beta releases before I start on 0.9.6. There are a few things I like to really check out before delving into stuff like querying a stylesheet (hope at least to get started with it for 0.9.6) and maybe registration of property validation and maybe also custom @rules. There are also a few other areas I would like to do (if I get the time) namely optimizing serialization which would be nice if ordered by selector specificity (indented more as specificity gets higher, I do this when writing CSS by hand but hope to make this happen automatic). And I guess reworking the whole CSSValue stuff which is redefined in CSSOM as compared to CSS 2.1 DOM would be good to do sooner than later.

let’s see…

March 20, 2008

cssutils 0.9.5b1

Filed under: CSS,cssutils — see @ 12:49 am

finally a new release! It took so long as main task was to add more tests and that is not really the work I enjoy the most…

Tests use minimock now which is small and simple.

Also the licenses have been simplified. To be really honest the license does not really interest me much. I chose the LGPL as XOM uses it and I reckon Elliotte Rusty Harold knows more about this than I ever want to ;)

I guess I view licenses more like marketing / selling / other boring stuff which I do not particularly am interested nor good in. Guess I should be but I actually like the actual “meat” of the stuff…

anyway, too much mumbling, should get some eyes shut…

UPDATE

It is not that I do not do any testing (cssutils currently has 262 tests, hardly enough but not that bad either). But the latest beta is not as good as it should be. 2 new features do not really work and it seems the basic feature of parsing is a little strange. As long as not import rules should be resolved (which is broken) and parseURL() is not used (which is broken and will change quite a bit) the release is ok I guess. Still annoying…

Also I played around with some things and found quite a few points which should have been fixed long ago. Nothing serious but some areas where setting a property would corrupt a complete stylesheet (e.g. setting CSSImportRule.type which definitely should be readonly). I fixed these things and I guess just playing around a bit does help finding things (not necessarily bugs but these too).

Anyway, I hope I get a new rel over easter. Unfortunately I will be away for a few days next week so it might get a little later.

February 19, 2008

“search” or “find”

Filed under: Web — see @ 8:32 pm

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?

February 3, 2008

cssutils 0.9.5a3, the namespaces release ;)

Filed under: CSS,cssutils — see @ 11:05 pm

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 inOrder=True.

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…

February 1, 2008

coincidence or pre-pycon release wants?

Filed under: CSS,cssutils,Python,XML — see @ 7:40 pm

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.

HTML5 or XHTML 2.0

Filed under: Web,XML — see @ 2:01 pm

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.

January 2, 2008

cssutils ongoings

Filed under: CSS,cssutils — see @ 11:58 pm

I started to actually query the sheets cssutils already does parse. Selector specificity is halfway done (ugly word BTW) but during development I found some serious issues. The CSSStyleDeclaration retrieval methods all ignored the priority of a property and some other minor stuff. I think it is fixed now but I need to do some more tests. But I guess at least an initial 0.9.5 alpha is due soon.

On a sidenote, 0.9.4b1 had the most downloads in the first days since release of all cssutils versions ever. I don’t get too much feedback (bad as would like to hear more, good as I probably won’t have the time to cope with much more ;) ) but it seems CSS in general and therefor “CSS libraries” have become more important in the last years despite CSS being around even before 2000. I guess CSS is taken more seriously as it is used quite nicely for e.g. selectors in libs like jQuery or lxml.

(I know cssutils is not hardly as useful but I think it is getting somewhere currently)

December 29, 2007

cssutils 0.9.4b1

Filed under: CSS,cssutils — see @ 7:19 pm

I’ve put probably (if no major problems occcur) the last but in any case the first beta release of cssutils online. Mainly a few improvements and bugfixes, a bit more docs and a thing here or there. The main feature may be a “combine” script which resolves @import rules in a sheet. Idea is to have a simple “proxy” CSS loaded from an HTML page which then loads all other needed CSS files (for e.g. layout, modules, colors or however you structure your CSS files). For production the “combine” script should be run which resolves the @imports in the proxy script (no nested imports yet!) and saves the resulting SINGLE CSS files optionally minified for deployment. The HTML does not have to be changed as the proxy ideally contains all needed CSS rules now. But for development a nice structure of CSS files may be used and kept…

Inspired by the Yahoo HTML performance guides (google for it, too lazy too look for the link now but I realize writing this comment almost takes longer ;) ) which propose to cut down on HTTP requests (very simplified summarized…). CSS certainly may quite easy be combined. Javascript is not as easy as it has no direct “include” facility, should be possible though.

Anyway, cssutils 0.9.5 will (probably) be adding better support for selectors, ideally it will be possible to query a cssutils stylesheet for styles for certain elements or documents. As this means building the complete first C of CSS (the Cascade) this will probably take a bit longer. But I guess it will make cssutils at least a bit more useful than just being a very big pretty printer…

BTW, I need to define which CSS hacks survive cssutils. I guess mostly hacks in the bounds of valid CSS will survive, currently the only non-valid hack “$propname” (used for IE) does survive. Anyway, something for next year ;)

« Newer PostsOlder Posts »

Powered by WordPress