Tantek-Mozilla-Projects

From MozillaWiki
Revision as of 00:14, 29 May 2010 by Tantek (talk | contribs) (→‎DOM API vendor prefixing: styling/heading for more content structure)
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 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.

DOM API vendor prefixing

spec implementation problem statement

Problem statement: the specification-implementation co-dependency problem.

All standards in development have the challenging seemingly contradictory problems of:

  1. needing some implementation to reality-check that the API/protocol/format "works" as intended, or is workable/usable
  2. being stuck with a specific (often buggy) implementation once it ships because there's content/pages/apps out there that depend on it.

There are three areas of the open web app platform that this has been problematic:

  1. CSS. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:
    1. 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though CSS 2.1 tries to fix clip.
    2. 'word-wrap' property. in this case, created/proposed by Microsoft, and implemented as of IE5.5/Windows ca 2000, we are again, kind of stuck with the particular implementation. Forum posts as of 2002 were recommending use of the literal word-wrap property. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also supported in Firefox 3.5 ca 2009, and it is in the latest (2007) version of the CSS3 Text spec which is just a working draft.
      1. See related 'word-break' property (word-break in CSS3 Text WD - latest, 2007), also initially (partially) implemented in Internet Explorer 5.x as word-break, and later switched to the prefixed '-ms-word-break'. More on CSS Compatibility and Internet Explorer.
  2. HTML. Too many examples to list here. Some browsers are still stuck supporting <blink> and <marquee> (which has many odd details), nevermind the classic example of <table> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.
  3. DOM. In particular Web Storage working draft (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.

existing solutions

The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.

CSS vendor prefixes

In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.

CSS prefixing is fairly straight forward: 

- abbreviated_vendor_prefix - property_name

(spaces added for clarification of the different components)

Examples include:

  • -moz-opacity
  • -o-border-radius
  • -webkit-border-radius
  • -ms-word-wrap
CSS vendor prefixes case studies
  • border-radius. for a few years now browsers have been implementing vendor prefixed versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.
  • word-wrap vs whitespace: pre-wrap. interactions between new properties and new values on existing properties. See this example of the property vs value interaction between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.

analysis of applicability

Can we apply similar thinking and solutions to HTML and/or DOM?

For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors can create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.

For DOM, it is not only possible, but there are examples in the wild.

mozOrientation is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)

simple DOM vendor prefixes proposal

For all DOM interfaces that are:

  • Proprietary. No standards organization draft yet published. OR
  • In a W3C working draft, not yet in a Candidate Recommendation.

Use vendor prefixed interfaces and values as follows: 

vendor_prefix _ unprefixed_name

E.g. in the above example of mozOrientation, we really should be using: 

moz_Orientation

This works because standard DOM APIs do not use underscores.

Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs

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=226552"