The Wilson Project
Blog of Front-End Developer/UX Engineer Ivan Wilson

Skip to Navigation

Tag Archive / CSS

  • 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

  • What is Project Ottawa?

    a method of building a visual model of an web application UI/front-end layer

    During the past four months, I have been presenting previews of sketches and notes from my notebook via Flickr.

    Preview Sketches:

    Project Ottawa [or the Ottawa model/diagrams] started in late February, prior to my trip to Ottawa for Jonathan Snook’s SMACSS Workshop. It was there that I did the first initial sketches post-workshop and a few weeks later, created the first draft.

    After some review and criticism from a fellow co-worker, I decided to work on the second draft. This took more twice as much time as the first, with testing and constant revisions. However, at this point, I am writing the final pages and presenting the Second Draft as a microsite in early/mid July.

    The Model

    In short, the model is based on a) recent work on modularizing CSS (via Nicole Sullivan, Jonathan Snook and etc), b) analog to linear algebra, most specifically linear transforms, and c) my ideas on the UI layer, based on a concept called The Information Layer.

    With these three items, I designed a visual “code” with symbols representing blocks of programming code and content. By examining mostly my own work, I developed the rules and basics to use the symbols to represent not the parts of the web application system, but also describing interactions withing the system.

    The original purpose of this was archival, record keeping for myself. However, I began to realize that there was nothing out there that visually describes the work that FEDs [front-end developers] were doing. We have code and and can talk about CSS, HTML, etc. But, maybe for the first time, there was something that allowed the work to be visualized and be more tangible.

    Status

    Currently, this is the second draft. Even though models are always being revised and changed, I kept the term “draft” because I wanted to present the working model in a state that was good enough for demonstrations. However, this draft appears, so far, to be close to being stable. Naturally, there is more work in the near future.

    Final Preview

    As I mentioned before, the final document will be presented as a microsite around early/mid July.

    Before that, I created a single page preview, giving a brief overview of the model and its use in “mapping” a single page, AJAX driven site. This is based on the sketches/drawing from the last Flickr preview and the same example will be used as a case study in the final document/microsite.

    Final Preview – Modeling a single page, AJAX driven site

  • 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.