Tag Archive / CSS3

  • Gesture-Based CSS Selectors

    [This is a short, informal proposal of a concept, with a more extensive version in the near future. However, this should be enough for starting discussion on its value/implementation.]

    What are Gesture-Based Selectors?

    Gesture-based CSS selectors are a combination of the current set of CSS selectors/pseudo-selectors to include new set of gestures currently being used in mobile (tap, tap hold, swipe, etc.). The main goal is to give basic interactivity to elements without JavaScript support.

    The closest analog would be the same sort of relationship with CSS3/JavaScript animation. In the current methodology:

    • CSS3 – basic/simple animations, removing the need for JavaScript resources
    • JavaScript/JavaScript Library via Events – complex animations, requiring more functionality beyond CSS3 animations

    Initially, this was just focused to touch gestures. However, this can be also be extended to other "gestures" such as the current JavaScript events "click", "mouse(over/out)", "key(up/down)", etc. This will allow for non-touch gestures → keyboard, voice/speech, inputs from any other devices, etc.

    CSS/Gesture Selectors Format

    The concept is to have these represented in CSS code by the following selector (in two versions, using the mobile gestures swipe left and tap hold as examples):

    1. selector:gesture-(gesture name)

      Similar to :hover, :focus pseudo-selectors (using current

      Examples:
      div:gesture-swipeleft { CSS code }
      a:gesture-taphold { CSS code }

    2. selector[gesture=”gesture name”]

      Similar to attribute selectors, introduced in CSS 2.1 but in use more with CSS3

      Examples:
      div[gesture=”swipeleft”] { CSS code }
      a[gesture=”taphold”] { CSS code }

    Constraints/Problems

    At this point, three initial problems appear:

    1. New Devices/Platform w/ Gestures – some sort of path/procedure needed for recognization of new gestures that is open and flexible. I recommend the following for an initial path:

      Device/Platform Support → JS event support → CSS/gesture selector available

      This will allow for the availibility for selectors mention above. However, there is the problem of device-specific gestures, which could mean that certain selectors will be available for only those devices. Currently, the touch events are only available on touch enable devices. If a [front-end] developer was writing code for a non-touch enabled device, the JS support would be non-existant -> no CSS/gesture support

    2. Gesture Uniformity – if a gesture gains support across platforms/devices, the related CSS selector should never be prefixed as we currently have for CSS3 features like animations or tranforms, ie "-iphone","-android", etc. I recommend this because unlike CSS3 features, these are OS based issues ("native"). The selectors will be device/platform "neutral" – let platforms/devices be solely responsible for interpretation.
    3. Computer Processing – if this gets implemented, how does this effect processor/power usage. How does the current set of CSS3 features (transitions/animations) deal with different computer processing power (hardware accelerators?)

      If this gets added to the current set – will there be a bigger demand for hardware processing? What would this mean for small, less powerful devices? (the drive behind iPhone design and construction).

      Overall – This is an issue that will need to be taken up post-proposal, with people more knowledgeable than me.

    In summary,

    1. Creation of CSS/gesture selectors to allow for basic interactivity, without the need of JS events
    2. Providing a “path” to allow for more gestures, not just current but for future devices/platforms and be platform/device independent.

    Flickr – Scans of hand-written notes from Polaris notebook

  • To All My Co-Workers And Clients:

    I want to apologize for all the bad coding decisions that I have made during the last couple of years. A number of decisions were made with ignorance as the impact they may have made in terms of performance. Some of those decisions may have been made without consideration for the user.

    If I seem out of sort during the last couple of week, it was simply because the changes I need to make will require changing not just code but a mental process. Like anything, this will take more than a fortnight to change. It is a process of renewal and making mistakes and just throwing stuff into the trash bin.

    What I need is some understanding and some patience while this process works itself out.

    Sincerely,
    Ivan Wilson
    Front-End/UI Developer

  • Endgame

    After two years this month, I have decided to end Project Charles in April. This will also mark the 10th anniversary of The Wilson Project.
    Mar 14 (Twitter)

    Depending on the ever changing schedule, Project Charles will be ending this year, if not sooner. After a long two years, I should be happy.

    I'm exhausted.

    I've carried this thing around, weathering all the stuff that gets thrown at me in the course of human life. This project became the internal motor of change, reflection, and experimentation. And a number of people have really benefitted from the results.

    The basis of Project Charles was redesigning The Wilson Project with the state of the art techniques in front-end development. No, we are not talking about the dazzling canvas experiments and all the fireworks. It was about learning all this new stuff to be able, like an experienced chef, to use this wider pallette to improve their work. Well, I'm still doing that. But Project Charles brought about an urgency to the process.

    Well, that urgency has come full circle. It's at a point where this project needs to end in order to go further on with other things. And since The Wilson Project Site is a working blog (and soon-to-be) portfolio site, I needed to end this thing to start doing new projects. And basically, I just need this monkey off my back. So why am I writing this blog entry?

    Because I feel that the need to apologize [to myself].

    This project was started with the idea of using XSLT via Symphony CMS. It's a very interesting application that I am sure will grow and improve. The cast of characters over there are currently working on the third version as I am writing this.

    Now, I'm in a time crunch. I cannot, at this time, learn XSLT and learn a new CMS without some focused time and effort. Unfortunately, considering the numerous hiatus periods in this project, that will never happen. So I took the hard choice and decided to move the project back to WordPress to speed up completion. I'm relieved at be removed of this burden. But I also feel sad, as I made some sort of bad compromised to complete this project. I know I shouldn't, but I'll live. I may feel bad for not completing the project in the way that I wanted fully but I have to move on.

    The other reason for Project Charles was conceptual. The "residue" of studying and observing the work around me of interaction design and front-end development. Yes, I have a few ideas that I've squirrel away.

    It's called The Information Layer.

    Ideally, Charles would have been the best demo, especially with Symphony/XSLT. But with the external changes of the last two years, there is a real need to share something now and not wait further down the road for an actual demo model.

    So, I'm shipping now. Everything can wait.

    I need my life back.

  • London and Back

    _DSC1607

    Just re-entered the country, after a week in London for the last FOWA (Future of Web Apps) conference for 2010. Take a while to settle down (not to mention get back to a regular sleep schedule). Spending a week going through all the notes and ideas from the conference. However, all this information will be slowly integrated for the remainder of this year. I was able to get some sightseeing, as well as going to The National Theatre (Hamlet) and a concert (BBC Symphony @ Barbican).

    Now, going home to DC to a stack full of work at CDG.

    Later.