Tantek-Mozilla-Projects

From MozillaWiki
Revision as of 03:03, 28 May 2010 by Tantek (talk | contribs) (→‎UI Styling: comparisions)
Jump to navigation Jump to search

Hi, I'm Tantek Çelik, and you've found my list of projects that I'm working on with Mozilla.

I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard, Arun Ranganathan, and the web standards team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies.

In particular:

Web Apps UI

UI Styling

At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.

1. Beautiful Built-in Tweakable Controls. Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.

Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.

2. Rich native-app-like experiences. Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:

a) Are built with the closest semantic built-in control for any particular custom control, and

b) Use a <canvas> for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, and

c) Have text-based fall-back in the canvas.

Example markup (event attributes/handlers omitted for simplicity) 

<button><canvas> Play </canvas></button>

(Now we just need a way to do that with text inputs too.)

The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.


For now, the sections below focus on addressing/solving the first cluster of use cases first.

The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.

Styling HTML5 forms elements

Main Page: User:Mounir.lamouri/HTML5_Forms

Each HTML5 form element must be complete to the following criteria:

1. It must include pleasant and working UI, where appropriate.

This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:

http://tantek.com/new-inputs.html

See HTML5/input for more <input> element tests.

2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)

Agreed, this is an absolute requirement.

Whenever there is any custom appearance of a form control, e.g. based on the new types, designers must be able to restyle them to fit in with their design. This means at a minimum:

  • ability to select specific "pieces" of any compound/composite form control for styling
  • ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)
    • existing Selectors UI pseudo-classes, and some notes on how HTML5 DOM property states trigger these pseudo-classes
      • :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.
      • :focus - an element which is currently accepting keyboard, pointer, or other input device events.
      • :enabled and :disabled - based on the state of the "disabled" property on the element.
      • :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.
      • :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".
      • :default - default buttons or submit buttons
      • :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.
      • :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).
      • :required and :optional - see HTML5 description of being required / required attribute
      • :read-only and :read-write - see HTML5 description of read-only vs read-write elements.
  • typography
    • font properties
    • text properties
    • color
  • box properties
    • width
    • height
    • padding
    • border
    • margin
    • background
    • box-shadow


3. If there's a constraint API the API must be complete.

4. It should be fully accessible.

CSS3 UI

http://www.w3.org/TR/css3-ui/

CSS3 Color

http://www.w3.org/TR/css3-color/

UI Layout

  • CSS3 Flex Box
    • need to get in touch with Tab Atkins and catch-up on the current state of his work vs. existing prefixed partial implementation in Firefox and Safari.


Social and Identity

Related Features

Features to work with:

  • Accounts Manager
  • ...

Standards and Communities

Standards and communities to engage with (recommended, unprioritized)

  • vCard 4 (IETF vcarddav)
  • hCard (microformats.org)
  • microdata vcard vocab (W3C/WhatWG)
  • OAuth (including OAuth 2, xAuth, OWF)
  • Portable Contacts
  • RelMeAuth
  • OpenID
  • WebFinger
  • Activity Streams
  • ...

Events

Events I'm planning on participating in accordingly:

Retrieved from "https://wiki.allizom.org/index.php?title=Tantek-Mozilla-Projects&oldid=226375"