** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.

**** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.

Revision as of 18:14, 29 June 2011

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

I'm a Mozilla contractor working with Chris Blizzard and the web standards team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies. I participate in standards related events for both official organizations like W3C, and grass-roots efforts like microformats and ActivityStreams. If you have feedback for these groups, let me know!

inbox

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 UI elements

We need to define how Forms and other UI elements can be styled, and to synchronize our work with the W3C.

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:

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)

Possible new HTML5 UI elements

The new user interface elements in HTML5 cover quite a bit of Web Apps UI scenarios. There are both requests based on specific user/application scenarios, and there is also the full set of user interface objects represented by the values of the CSS3 UI 'appearance' property

specific new elements

<menubar>

pull-down-menu

context-menu

<input type="year"> - based on <time> element use case research

<input type="month-day"> - based on <time> element use case research

CSS3 UI appearance values

menubar - a menu of menus, typically arranged linearly, in a horizontal bar.

pull-down-menu - a menu where the name of the menu is displayed and the options remain hidden until the user activates the menu. When the user releases or deactivates the menu, the options are hidden again.

radio-group - a menu where the options are displayed as radio-buttons.

checkbox-group - a menu where the options are displayed as checkboxes.

outline-tree - a menu where the options can be shown or hidden with small widgets, often represented by a small triangle or plus and minus signs. might be possible to build one using <details> and <summary>.

combo-box - a field which is accompanied by a menu of preset values that can be used to quickly enter common or typical values.

draft and publish at least a minimal coverage test suite that covers those claims

document actual implementation results

reducing feature set down to what's been implemented in more than one browser

write new CSS3 UI LCWD editors draft with only non-at-risk features based on above implementation evidence (or imminent implementation - kept at risk)

write new UI Selectors FPWD editors draft with all new UI selectors (consider limiting to those with at least one implementation, any with less than 2 implementations, mark at risk up front)

collect/address new CSS3 UI LCWD issues as they are reported

respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)

incrementally draft new CSS3-UI CR draft accordingly

wait for new CSS3 UI LCWD last-call period to end

write UI Selectors LCWD - with features with at least one implementation, any with less than 2 implementations, mark at risk.

edit CSS3-UI CR draft accordingly that is ready for PR

WG processes for taking it to PR

Remaining related Firefox bugs/development tasks (stub/incomplete)
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:

investigate discussion of ink overflow vs layout overflow - fantasai will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.

Facebook uses some JS to add rows to text areas when you hit the end of the available space. It feels nicer than a scrollbar because you can see all of what you typed -- the height of the text area just grows and grows as you need it. It would be great to have 'resize' property values that allow the browser to auto-grow a textarea as a user enters data, e.g. 'grow-horizontal', 'grow-vertical'. 'grow-vertical' would emulate the current behavior that FB does with JS. (note from fantasai - this is the behavior you'd get with fixed min-height and auto height, so CSS can do this already if HTML doesn't get in the way)

Update 2011-032: @LeaVerou requested "elastic textarea effect with pure CSS" and follow-up: "mostly about height, not width" which sounds like resize:grow-vertical. There's also mention of "-moz-available" (need to research that and link it up).

DOM API vendor prefixing

spec implementation problem statement

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

needing some implementation to reality-check that the API/protocol/format "works" as intended, or is workable/usable

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:

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:

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

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.

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.

CSS vendor prefixes successes

Several well known web designers and developers have written at length about the successes of CSS vendor prefixes, and how they have both helped avoid problems from before, and actually improve the evolution of 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

simple protocol scheme prefixes proposal

The WebSockets specification (and iteration) provides a good example of a W3C Working Draft that has work also going on at the IETF (perhaps primarily), and there is a high likelihood of backwards incompatible changes being made to WebSockets's "ws:" protocol between different versions (-76, -00, -01).

Thus it is worth considering prefixing implementations of the "ws:" protocol in order to break/rev as necessary instead of being locked into a specific draft due to premature reliant adoption.

For all protocol schemes that are:

Proprietary. No standards organization draft yet published. OR

In a W3C or IETF working draft, not yet in a Candidate Recommendation, or perhaps public last call for IETF drafts (open to suggestions here).

Use vendor prefixed protocol schemes as follows:

vendor_prefix - unprefixed_name

E.g. WebSockets has a new ws: scheme, and we've implemented it in Firefox 4. We really should be using:

moz-ws:

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

simple HTML attributes prefixes proposal

Implementing prefixes on element names doesn't work because you can't have more than one element name per element, and thus prefixed versions would force developers to choose between unprefixed and a particular prefixed version.

However elements do have multiple attributes, and thus prefixing can work for attributes.

For all HTML attributes that are:

Proprietary. No standards organization draft yet published. OR

In a W3C working draft (e.g. New in HTML5), not yet in a Candidate Recommendation.

Use vendor prefixed attributes as follows:

vendor_prefix _ unprefixed_name

E.g. HTML5 has a new 'pattern' attribute, and we've implemented it in Firefox 4. We really should be using:

moz_pattern

This works because standard HTML attributes do not use underscores.

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

UI Layout

CSS3 Flex Box and Grid

There are two new CSS3 layout mechanisms being developed that could greatly assist with the layout of user interfaces.

CSS Waiting For

CSS3 Backgrounds and Borders

prefix removal from -moz-border-radius

Currently Mozilla's border-radius properties are prefixed with -moz- and the following bugs/issues are preventing us from removing the prefix:

% values on border-radius. There is existing content (themes?) that depend on the legacy moz-border-radius implementation of % values that depend on the % of *width* in both dimensions.

clipping overflow and replaced elements. We don't currently clip overflow hidden and replaced elements (e.g. img, video, canvas) to rounded corners. We need to do to this for a proper/complete implementation that won't risk creating further legacy/backward compat problems.

Events

See the Events page for event that I'm speaking or participating in accordingly.

Web Standards Coordination

There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.

Reference

Pages

Done

Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.

Completed Events

For more details on completed events, see the main Events page and its archives.

general concept of hit-testing so that elementFromPoint can be defined in terms of it (feedback fron annevk).

text-overflow

text-overflow. incorporated 'text-overflow', since it's more a UI/overflow thing than a typesetting thing. There are at least 3 implementations (IE, WebKit, Opera), and has a bug against Firefox: 312156

Safari scrolls the ellipsis ... and doesn't reveal any additional text - this doesn't make sense to me (RoC, nor me Tantek) as a user. If I scroll I should get to see the rest of the content. (Agreed)

Opera scrolls the text into view until the you can see the end of the text at which point the block scrolls no further (this is ideal beahvior -t). No ellipsis is display on the otherside of the block when you start scrolling characters off the start edge.

This seems like the best behavior so far, with the exception that as a user (and developer) I'd expect to see the text that scrolled off the start of the block get replaced by an ellipsis rather than simply clipped (agreed precisely with RoC on this and have specified this expected behavior as a SHOULD)

Testing IE9 in standards mode showed same behavior as Safari for scrolling+ellipsis.