see whatever…

jump to menu

October 3, 2012

Touch handling in Windows 8 JS app

Filed under: CSS,HTML5,Javascript,Win8 — see @ 9:12 pm

Documentation for handling touch in Windows 8 style (Metro ;) apps with Javascript is not really sparse but nevertheless or maybe because of that a total mess. Lots of decriptions of classes (random links…),  some blog posts, a few samples which all seem very complicated and a few (better) pointers can even be found at StackOverflow (where else ;) .

Guess as until now I only used wrapper libs like Zepto or a few jQuery plugins for mobile touch handling (mostly iOS) which abstract the hard parts away I expected the code to handle a simple swipe left/right to be simpler.

After playing around a few hours, being lost in the depths of the Microsoft docs I came up with this:

 // define GestureRecognizer
 var recognizer = new Windows.UI.Input.GestureRecognizer();
 recognizer.gestureSettings = Windows.UI.Input.GestureSettings.manipulationTranslateX
 recognizer.addEventListener('manipulationcompleted', function (e) {
   var dx = e.cumulative.translation.x
   // **actually do something, left or right defined by dx > 0 or < 0**
 });

 // actual element which feeds the GestureRecognizer
 var processUp = function (args) {
   try {
     recognizer.processUpEvent(args.currentPoint);
   }
     catch (e) { } // translateYfails ?!
   }
 var swiper = document.querySelector('.swipearea')
 swiper.addEventListener('MSPointerDown', function (args) {
   try {
     recognizer.processDownEvent(args.currentPoint);
   }
     catch (e) { } // translateYfails ?!
   }, false);
 swiper.addEventListener('MSPointerMove', function (args) {
   try {
     recognizer.processMoveEvents(args.intermediatePoints);
   }
     catch (e) { } // translateYfails ?!
   }, false);
 swiper.addEventListener('MSPointerUp', processUp, false);
 swiper.addEventListener('MSPointerCancel', processUp, false);

All in all and in the end almost logical. You preprare a GestureRecognizer and feed it with events from a DOM element. This actually seems capable of doing lots of much more advanced stuff but for a simple swipe left/right gesture seems almost overkill. I wonder if there is something simpler?

In addition I do not understand why the recognizer feeding methods like recognizer.processUpEvent do actually raise an exception if in the above case a up/down swipe is used. One reason is that the element actually has a normal overflow, so the normal scrolling works there. This is the reason the recognizer is set up to only actually handle manipulationTranslateX gestures. But why the additional exceptions?

Anyway, the above seems to work (at least on my desktop and the simulator with both Mouse and BasicTouch mode). Not the simple stuff I have hoped for but maybe I did it all too complicated? Any hints are very much appreciated :)

October 8, 2009

cssutils 0.9.6final release and …

Filed under: CSS,cssutils,Python — see @ 12:53 pm

Yesterday I finally made a final release of cssutils after five alpha and four beta releases in about 10 months. This shows I sadly could not spend much time on it but actually this release has some nice stuff I think:

  • serializing is much improved (like 0.0px gets 0 now and so on)
  • some IE only values are at least parsable (alpha(…), expression(…)) and so these sheets can be minified with cssutils now
  • a complete rewrite of CSSValues (which still need a lot of work though)
  • Jython and GAE compatibility
  • added extensible CSS profiles (even someone used this for a start of a SVG profile)
  • implemented @font-face and http://www.w3.org/TR/css3-fonts/ spec (not complete probably but at least all stuff should be parsable now)
  • lots of both reported and internal bugfixes
  • lots of minor improvements…

Maybe I did this release now mainly because I wanted to start a little bit of new stuff and get this “out of the way”. Also a single (final) release in a year is the minimum I guess.

For 0.9.7 I plan some new stuff. For a long time there has been a big discussion about CSS variables and some people think they are even evil (to which I partly agree). On the other hand there seem to be quite a few CSS preprocessors (lesscss, hss, clevercss, etc) springing up so there seem to be a certain need for it. Also there is the CSS Variables spec which I think is even implemented in Webkit. So I thought why not add something like this to cssutils. People need not use it but if they want to, why not put it in this lib too ;)

So I guess I will implement the CSS Variables spec and maybe something like mix-in classes which I guess would be an extension to this and also seem to be quite useful.

A simple WSGI based CSS handler which would resolve both – variables and mix-ins – on the server would be nice. In the past I mainly used web.py but maybe I’ll try out a few other “mini-frameworks” (not sure if they like being called that but in lack of a better name) like e.g. werkzeug or bobo. If you have any preferences or suggestion please write in the comments (I prefer smaller frameworks and not bigger ones like Django for now but the results would certainly be very easily adaptable).

In addition to this (which may or may not lead to something) CSSValues still have to be reworked.

Also there is going quite a bit in the CSS world currently (the mailing list has become very lively in the last one or two years). So I guess I pick a few things which I think may be useful in the near future (and also will not take too much time to implement :) and add them to the next release.

December 26, 2008

combine and minify CSS

Filed under: CSS,cssutils — Tags: , , — see @ 12:55 pm

I have been working on minifying CSS for quite some time now and had written a simple web.py based CSS handler which does exactly that. Actually it simply uses the minify option of cssutils

Additionally the handler does combine all imported stylesheets of a given proxy sheet into a single one. Nice for development as you can split sheets into as many as you like but deploy only one. So you may have the following stylesheet style.css:

/* proxy sheet */
@import "basics.cs";
@import "layout.css";
@import "forms.css";
/* etc... */

(I normally separate styles into something similar).A given HTML page always references the single stylesheet style.css which would even work without a combinator as @imports will be loaded by the browser anyway. But for deployment or when using the simple combinator handler style.css will contain all rules from all imported sheets resulting in only a single HTTP request. If additionally minified after combination the savings on load time in most cases is substantial.

For the next release of cssutils I added a combinator function to cssutils itself:

proxysheet = cssutils.parseFile(PATH_TO_CSS) # or use parseUrl etc
combinedsheet = cssutils.resolveImports(proxysheet)
cssutils.ser.prefs.useMinified()
print combinedsheet.cssText

Based on this I thought it would be nice to have a service which does just that, resolve all imports in a given sheet, minify it and return it. So I started the CSS Minifier at GoogleAppEngine (GAE). It has a basic frontend where you enter an URL, may optionally select advanced options (for now the error level below which errors are simply swallowed, the target encoding which may currently be UTF-8 or ASCII and the option if the imports should actually be resolved).

Additionally it may be used as a simple service which returns a combined and minified sheet or in case of any errors a HTTP 400 BAD REQUEST with the error log.

The only problem on GAE was that it prevents usage of urllib/urllib2 to actually fetch the content of URLs. But it has it’s own API for that so no big problem to rewrite the fetching code. For the next cssutils release I actually added the code for GAE into cssutils itself. If cssutils thinks it runs on GAE it uses the GAE specific fetcher code, else urllib2 as before.

To detect if a script is running on GAE for now I try to “import google.appengine”. Not quite sure if that is enough but for now it seems to work.

Anyway, hope this service may be useful.

October 16, 2008

CSS Systems

Filed under: CSS — see @ 10:28 pm

via Isotoma found Natalie Downe’s CSS Systems, some thoughts about it:

  • a “system” for better communication for the end user (in most cases another developer) is a good and valid point
  • ordering (#17) and grouping (#18) of different style “areas” is mostly on what I would agree on.
  • the term helper classes (#18) for e.g. forms is great. I guess I did this unintentionally anyway but terming it this way is great
  • during the whole presentation (it is a PDF from a pres.) there is lots of “I like” or “I don’t like”. It seems CSS has quite some areas which are a matter of taste (and it seems my taste differs in more than one area…)
  • Using CSSEdit on Mac (which I don’t know as I do not work on Mac) seems to influence how you write your styles too. I normally use Aptana with a custom helper script (server side) which allows working in more than one file but get as an end result a single CSS file (to cut down HTTP requests)
  • Some of the things I do like (but not Natalie apparently):
  • IE specific sheets verses CSS Hacks: I prefer the hacks as IE condiditional comments require:
  • more than one sheet with more than one HTTP request PLUS maintainance problems with styles littered over several sheets (hacks keep related styles together). I do use valid hacks only though and try to minimize them too which normally is possible with most designs to develop HTML + CSS for
  • “Selector based indentation” (#44): This is actually something I do quite often. Not for everything but for the styles Natalie would put into the area of “page structure” (the layout I guess) and “page components” (some say “modules”). The general layout (e.g. 2 column-container with a left and and right column in it) seems a perfect fit for indentation. As this general layout is mostly quite simple (as it is a skeleton only) and stable hopefully ;) (if not the HTML and there for CSS has to change substancitally anyway) I don’t see a problem of maintainance here. Also as page componens/modules are normally not really that long (I find for most designs and therefor also page modules the HTML is quite simple and therefor the CSS mostly too) and are by definition self-contained (a module…) indenting there is a helpful way to make the CSS more readable. If you factor out helper classes (e.g. for a specific kind of link or headline or list etc) these groups become even smaller so indenting makes these even more useful.
    If you use CSSEdit this may be different but it seems CSSEdit does show something like an improved version of Aptanas “Outline” which I do not find very helpful anyway so guess CSSEdit would not help me much either (again a position of tool and taste)
  • Maybe indentation also is a matter of what programming languages you use? I could even live with a CSS without any curly braces just defining declaration blocks by indentation. But that would be a Python programmers wish (actually there is a script which allows you just this but for that I am more a HTML/CSS than a Python guy ;) ). But the same as Java programmers seem to hate indentation with a meaning in Python some people seem to ignore indentation in CSS as a help for adding addiotional information/context
  • Class instead of element name selectors: Indentation makes most sense if you have a self-contained module with selectors mostly using element names and not classes (at least not module specific classes). E.g.:
  • .download {}
      .download h2 {}
      .download ul {}
        .download li a {}
        .download li .specific-helper-links-extended-here {}
  • this way you minimize the amount of classes needed altogether (yes you need to keep track when e.g. changing the “h2″ to an “h3″ but if you change the HTML for this case the whole structure where this module is used changes so you should be aware of the anyway. But I am not dogmatic here, you may still use a class “.header”. If you are worried to use “ol” instead of “ul” you probably will be better of styling the “li” anyway) [but I am drifting off...]
  • I do agree on to think about “what” to style and not “where” (#44) it will be (semantically on the module and not the single HTML element level of course so this is not really an argument against indentations of related style declarations IMHO). Anyway, the CSS classes reflect this in their “semantic” naming as a result. Sometimes there may be a problem here though. For designs not being stable yet (but the CSS to be done nevertheless, deadline ACK!) but also for websites running a long time and being extended/changed etc,  sometimes finding a proper and longlived name is sometimes really difficult. Especially if you get a design, start trying to find related modules and their respective (class) “names” but then the design uses just the same before defined modules for sometings totally different or the actual client puts totally different content in these the semantic names are actually totally wrong…
  • Sandboxing (#47): I agree on this which seems to contradict my point made about indentation. But in my experience most people simply try to be too clever (and therefor complicated) or sometimes even too bureaucratic. Simplifying the CSS (leave out any not needed selector part) sometimes make a sheet not just dramatically shorter and maintainable but also
  • style leaking by keeping the element name with a class it maybe ok for helper classes but to page components (which I would equal to modules – not sure now if Natalie actually meant this) I find an adding of a module class (above example “.download”) sufficient.
  • “height” being evil I strongly agree on…
  • 2 points I think are missing:
  • #id versus .class: I only use IDs for tying label and form elements together and anchors so normally NOT for CSS styling at all (maybe for Javascript enhancements but even then hardly). You mess up your cascade and also you never know if you may use a style declaration again (which you can’t in case it is an ID without duplication the style declaration OR adding another ID…)
  • Once you use “!important” you are lost. Never use “!important” except maybe for print styles or even more-maybe for IE bug fixing but you have to be very careful…

July 30, 2008

cssutils 0.9.5 final…

Filed under: CSS,cssutils — see @ 2:25 pm

After about 6 months of development 0.9.5 of cssutils is released as a final version. The last final version has been 0.6 …

Not that final means perfect but at least I tested everything, the lib itself, the scripts which have been broken in some alpha and beta releases and also the examples on the website which have been changed quite a bit. There still are quite a few areas where I suspect problems but there has to be a release at some point ;)

Anyway a release means starting a new one. I guess I have to improve the basic property handling. New values have been added to CSS2.1, CSS3 modules can be added (especially the Color Module which is almost a recommendation).

But I think I do look into other small projects first as I have been concentrating on cssutils in my spare time for quite some time now…

July 14, 2008

cssutils 0.9.5 soon

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

I guess this is one of the releases I have been tested much more deeply than any others before. I know there are still lots of bugs in the lib but I did not expect such a major one which has been fixed in 0.9.5rc2. It more or less made handling lib not as it is meant to be handled. Please see the change log for a more details explanation just in short:

The global setting cssutils.log.raiseExceptions defines if exceptions when using any DOM method are actually raised (the default) or simply logged away. Problem was that whenever you used any parse* function or any CSSParser.parse* method this setting was set to “False” and exceptions were not raised anymore. Exceptions would be if the parser itself was initialized with CSSParser(raiseExceptions=True) which I reckon hardly anyone who uses the lib had done.

0.9.5rc2 fixes this bug. Any parse* does restore the original value of cssutils.log.raiseExceptions to its former defined value (which would be “True” as the default value).

I know this is normally not a time for such a serious change (at least I think it is serious, is it not?) but I think better now than later. Also there is a workaround. Simply set csstutils.log.raiseExceptions to “False” or “True” whatever you prefer. Beware though that “True” (meaning raising) should be used except during a parse* but when actually working in the DOM.

Anyway, there are also some positive things to report. A few bug have been “squashed” and the performance has been improved by maybe 25% (depending on your source sheet). This was more or less a side effect of a bugfix which made me refactor the tokenizer and realize that there is massive room for optimization…

Guess 0.9.5final will be coming shortly. The next release 0.9.6 will probably concentrate on properties and values which are not testet very well and do have room for optimization – speaking positively ;)

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.

Older Posts »

Powered by WordPress