Tantek-Mozilla-Projects: Difference between revisions
(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 | 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
- feeds into requirements for CSS pseudo-elements
- consider existing UI pseudo-elements - do any of these make sense for new HTML5 input types?
- 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.
- existing Selectors UI pseudo-classes, and some notes on how HTML5 DOM property states trigger these pseudo-classes
- 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
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:
- June 1-4 Open Source Bridge, Portland, OR, http://opensourcebridge.org
- June 28-30 Voices That Matter Web Design in SF
- July 5-7 Mozilla Summit in Whistler, Canada.
- July 19-23 OSCON in Portland http://www.oscon.com/oscon2010
- August 23-25 W3C CSS WG f2f in Oslo http://www.w3.org/Style/Group/2010/Oslo
- September 3 dConstruct in Brighton http://2010.dConstruct.org/