Tantek-Mozilla-Projects: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(added events section)
(→‎Styling HTML5 forms elements: new inputs test page)
Line 14: Line 14:
1. It must include pleasant and working UI, where appropriate.
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 dangers to avoid).
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


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

Revision as of 15:11, 27 May 2010

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

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

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: