Tantek-Mozilla-Projects

From MozillaWiki
Jump to: navigation, search

This page lists Mozilla related projects that Tantek is working on.

Summary:

2023-03-24: Major updates coming. Still working on the above, with more to be listed. Watch Standards for updates.

Contents

To be updated

The rest of this page needs a major update. - Tantek (tantek.com) 15:53, 3 July 2017 (PDT)

Previously from Tantek:

pages

A few of the pages I've created in the past

ideas to explore

Some ideas to consider exploring. Tantek has not taken on these (yet). This is a place to collect potential tasks. Feel free to grab any of these and ask Tantek questions about suggested approach(es) etc.

additional potential CSS work

  • Proposing -moz- innovations. There are numerous -moz- innovations like selectors (e.g. :-moz-broken), properties, and values.
    • Methodology: if we can document, determine, or hear of (e.g. from web designers/developers) real world public web use cases for any particular -moz- innovation, then we should consider pursuing standardization of it. Otherwise, it's better to not standardize so we can change our implementation as needed to match our internal needs (e.g. for UI/themes etc.).

various UI thoughts

  • "about:downloads" to address/bring up a "downloads window" view which would be one way to put the downloads window into a tab (and perhaps even enable that as a default option, downloads in a tab rather than separate window). This seems so obvious that there must be an existing bug / feature request for this.

APNG adoption

See: APNG

Critical areas of focus

  • IndieWeb - the independent web, providing user-centered freedom, ownership, and control over and above silos and their TOSeses.
  • Microformats - open standards for marking up information in HTML, simpler, easier, more maintainable, and higher quality than alternatives (RDFa, microdata), and sidefile efforts (XML, RDF). See also HTML5 and Tantek's book on getting started with HTML5.
    • microformats2-parsing in particular landing support in Firefox Toolkit/Platform for Share, Social Bookmarking, Context Menu, Shopping

Working groups and standards communities (representing Mozilla and open web interests)

Web platform specifications (editing, in rough priority order)


Additional projects:

The rest of this page needs a major update. - Tantek (tantek.com) 20:04, 27 May 2016 (PDT)

Summary of work items

(This section is quite out of date - to be updated!)

Summary of work items / general next actions and status:

  • CSS / HTML5 / DOM
    • CSS3 UI
      • Achieved LCWD2. Next action: collect LCWD comment, produce disposition a new LCCR.
    • Full Screen - contributing only
      • Next: make sure issues are resolved or captured in WHATWG draft
    • CSS4 UI: collect ideas, features, pointer-events?, hit-testing?, proposals towards writing a FPWD.
  • microformats / h-card / hCard / vCard4 / identity
    • vCard4: review published RFC, document "the good parts" subset.
    • hCard 1.1 (incorporate resolved issues), h-card update based on microformats 2.0 + vCard4 good parts
  • Web Applications / Web Actions / Web Activities
  • Standards groups/community participation
  • Open Web Standards Events/Speaking:
    • IndieWebCamp, dConstruct, BarCampBrighton, TPAC, CSSWG f2f meetings
  • ... with additions and removals as it makes sense.

Needs review (the following projects need review to determine updated next steps and reprioritize)


See below for more details on each.

inbox

Please note, if you have specific requests for Tantek's time:

  • IM preferred. Tantek is available on IM to answer open web related questions.
  • Email is unreliable. Tantek can't guarantee any particular turnaround on email (see EmailEfail).
  • Works remotely. Tantek is in the SF office typically, in Mountain View occasionally, and often out speaking at a conference or at other W3C etc meetings or Mozilla related Events.

Inbox (add stuff here) :

HTML5

(needs update - 2014-11-20)

As a foundational technology, everything else (microformats, CSS3, WebApps, etc.) depend on getting HTML5 right, and fixing problems in the HTML5 spec.

needs re-consideration

These items need re-evaluation to see if they're still important to get into HTML5, lower priority, or can be postponed to HTML next.

Next: follow-up on each, determining next steps on rejected proposals, and update HTML5: spec issues accordingly.

summary naming

Moved to HTML5/summary

keeping crappy stuff out

simplify alt attribute guidance

Moved to HTML5/img.

remove meta Content-Language

Moved to HTML5/meta

upgrade HTML4 features to be more flexible and usable

restoring pragmatic HTML4 things

Moved to HTML5/cite.

improving new features

iframe sandbox removal

Moved to HTML5/iframe.

lower priority improvements

  • <meter> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.

HTML next

Proposals/changes deferred to the next version of HTML (often dependent on more/better use-cases, and/or better implementation of HTML5 as defined so far).

nesting time

Moved to HTML5/time. am pm handling too.

Web Apps

(needs update - 2014-11-20)

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.

Note that providing facilities for (re)building native-app-like UIs is just one part of what such rich web-apps need to compete with native apps.

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.

Working with Mounir Lamouri on this: User:Mounir.lamouri/HTML5_Forms

Each HTML5 UI 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:

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

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

  • Need more sample/test/wiki pages for other HTML5 UI elements.

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

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 CSS3-UI pseudo-elements
      •  ::value can be used for selecting/styling placeholder text (see bug 457801 comment 25)
      •  ::choices can theoretically be used to style the popped-up state of a <select> pop-up menu. No known implementations.
      •  ::repeat-item - no known applicability to HTML(5) form controls, at-risk in CSS3-UI, resolved to be dropped.
      •  ::repeat-index - no known applicability to HTML(5) form controls, at-risk in CSS3-UI, resolved to be dropped.
    • consider additional pseudo-elements based on vendor prefixed pseudos
      • Safari 5 supports pseudo-elements for restyling overflow scrollbars
        •  ::webkit-scrollbar-thumb
        •  ::webkit-scrollbar-track
        •  ::webkit-scrollbar
    • consider additional pseudo-elements based on web designer requests for stylability of form controls
  • 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.
    • additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features
      • "placeholder" attribute - needs a new :-moz-placeholder pseudo-class (bug 457801)
        • :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.
  • 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.

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
CSS UI appearance values

  From CSS3 UI 5.1. Appearance values:

Needs:

  • tab - a button that looks like the browser's tabbed windows tabs.
  • 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.
  • signature - a field for entering a signature, e.g. on a touch or tablet device or with a mouse.

Do we need something equivalent to HTML5's <progress> element?

updated appearance value list

Full updated appearance value list with equivalents:

  • icon - handled by 'icon' property and HTML5 Drag & Drop
  • window - mostly handled outside of elements, except perhaps a tooltip value which could be purely presentational
  • button - by default a push-button
    • push-button - <input type=button> and <button>
    • hyperlink - <a href>
    • radio-button - <input type="radio">
    • checkbox - <input type="checkbox">
    • menu-item - <option> and <optgroup>
    • tab - no HTML5 equivalent
  • menu - by default a pop-up-menu
    • menubar - no HTML5 equivalent
    • pull-down-menu - no HTML5 equivalent
    • pop-up-menu - <select>
    • list-menu - <select size=n (where n>1)
    • radio-group - no HTML5 equivalent
    • checkbox-group - no HTML5 equivalent
    • outline-tree - no complete HTML5 equivalent but <details> and <summary> may help.
    • range - <input type="range">
  • field - <input type="text"> and <textarea>
    • combo-box - no HTML5 equivalent
    • signature - no HTML5 equivalent
    • password - <input type="password">

CSS Style Attributes

latest published draft (CR)
https://www.w3.org/TR/css-style-attr/
latest development / in progress draft
https://dev.w3.org/csswg/css-style-attr/
spec source (for editing)
https://dev.w3.org/csswg/css-style-attr/Overview.src.html
test suite
TBD
implementation reports of the test suite
TBD
issues list for the current draft
https://wiki.csswg.org/spec/css-style-attr
remaining tasks
  • test suite
    • expecting to work with Ted O'Connor of Apple on this
  • implementation reports
  • PR draft
  • wait for W3C AC review
  • REC
waiting for
  • Ted O'Connor answer whether he can help with test suite / implementation reports.
    • emailed 2011-080

See also CSSWG wiki task list: https://wiki.csswg.org/spec/css-style-attr

CSS3 UI

latest published draft
https://www.w3.org/TR/css3-ui/
latest development / in progress draft
https://dev.w3.org/csswg/css-ui/
spec source (for editing)
https://dev.w3.org/csswg/css-ui/Overview.bs
test suite
https://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/
implementation reports of the test suite
TBD
issues list for the current draft
https://wiki.csswg.org/spec/css3-ui
remaining tasks

Remaining tasks to get CSS3 UI to PR:

  • resolve issues. resolve/apply proposals from issues list: https://wiki.csswg.org/spec/css3-ui
  • collect other tasks
  • text-overflow
    • create an implementer FAQ on the W3C wiki re: text-overflow accordingly
      • go through local test documents on work laptop
      • go through emails on "text-overflow" with fantasai, mats, roc
  • :indeterminate - add an example using HTML5 progress element and with input type=checkbox with DOM property set to indeterminate deliberately per devmo :indeterminate example
    • Move to W3C wiki, collaborate with Tab & fantasai to incorporate into Selectors4
    • Internet Explorer 8+ CSS3 UI support - ??? (expect email from johnjan @ MS)
    • IE5/Mac CSS3 UI support - ???
  • put out a call for at least a minimal coverage tests that covers those claims per implementer
  • document actual implementation results
  • collect/address CSS3 UI LCWD2 issues from www-style [css3-ui], [css-ui]
    • respond to all the commenters on issues with proposed resolutions + editor's draft edits (hopefully thus addressing their concerns and resolving the issues accordingly)
    • incrementally draft new CSS3-UI CR draft accordingly
  • edit CSS3-UI CR draft accordingly that is ready for PR
    • reduce feature set down to what's been implemented in more than one browser, or in one browser and imminently expected in another browser. mark at risk anything that is not interop in 2+ browser per above tests.
  • publish CSS3-UI LCCR with minimal test suite and results
  • if necessary, 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)
  • WG processes for taking it to PR

CSS4 UI

  • write CSS4 UI FPWD with:
    • public requests recorded: https://wiki.csswg.org/spec/css4-ui
      • the below items should be incorporated into that CSSWG wiki page
    • previous CSS3-UI features that got dropped
      • stuff from CSS3 UI CR that only had one implementation (that we believe is worthy of standardizing, or at least one other implementer expresses interest on)
      • stuff from and related to previous CSS3 UI drafts that's been reraised
    • other CSS features that are UI related in other CSS or other W3C specs
    • new features
      • CSS portions of Gecko:FullScreenAPI, e.g. the new pseudo-classes
      • new 'resize' values - e.g. grow-vertical, grow-horizontal
        • 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).
    • forward reaching properties/values to enable native-like interfaces

Additional CSS3 UI related features in Mozilla to investigate:

CSS3 Element

element function

Firefox 4 implements background: -moz-element(#foo); to use element with id foo as the background per https://hacks.mozilla.org/2010/08/mozelement/

We're pursuing adding element(#foo) as an "at-risk" feature to CSS3.

Proposal (worked with Tab Atkins)

Threads:

Thoughts:

  • CSS image() value - Tab Atkins has written it up.

CSS4 Color

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 msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000 (Internet Archive link), we are again, kind of stuck with the particular implementation. www.codingforums.com/archive/index.php/t-2075.html (Internet Archive link) 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 msdn.microsoft.com/en-us/library/ms531184.aspx (Internet Archive link) initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx (Internet Archive link) 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 scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx (Internet Archive link) 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.

Some next-steps:

  • need to get in touch with Tab Atkins and catch-up on the current state of his Flex Box work vs. existing prefixed partial implementation in Firefox and Safari.
    • 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.

Fullscreen

AKA Full Screen

latest living / development / in progress draft
https://fullscreen.spec.whatwg.org/
spec source (for editing)
https://github.com/whatwg/fullscreen/blob/master/Overview.src.html
latest snapshot W3C draft
https://www.w3.org/TR/fullscreen/
latest snapshot W3C TR-ready draft
https://dvcs.w3.org/hg/fullscreen/raw-file/tip/TR.html
W3C branch snapshot spec source
https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
test suite
TBD
implementation reports of the test suite
TBD
issues list for the current draft
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Fullscreen&resolution=---
wiki page - including FAQ
none currently (perhaps wiki.csswg.org URL when ready)

remaining tasks

WebAPI

ContactsAPI

  • sync up with User:Philikon on WebAPI/ContactsAPI and his additions and changes (see also his github).
    • converge PoCo vs vCard4/hCard4 difference
    • fix erroneous singular vs plural property distinctions (in practice, and vCard4 updates, nearly all properties are plural, best to assume as much for all properties, and apply singular semantics at a higher level to the first item in a collection if necessary)
    • simplify / minimize (hopefully eliminate) extra levels of API hierarchy (apparently from W3C Contacts API design)

Web Apps Waiting For

(needs update - 2014-11-20)

Tasks which are awaiting follow-ups from various standards bodies/lists. Re-ping as necessary to keep moving forward.

CSS Waiting For

CSS3 Backgrounds and Borders

Waiting for CR of https://www.w3.org/TR/css3-background/

And then: outstanding UI related issues:

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.

Bugzilla bugs:

  • 431176 - (border-radius) Tracking bug for remaining issues with CSS3 border-radius
  • 451134 - change -moz-border-radius* properties to css3-background names

Social and Identity

Related Features

Standards and Communities

Standards and communities to engage with (recommended, grouped by related)

identity / profiles / contacts

  • vCard4 (IETF vcarddav)
  • hCard (microformats.org)
  • Portable Contacts
  • RelMeAuth
  • OpenID
  • ...

social web

communities

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.

  • Standards - who is working on what standards in what organizations

See Also

Reference

Pages

See reference pages created

Historical

Former standards groups

More in Standards/Emeritus.

Former co-workers

See User:Tantek#emeritus.

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.

Annual Summaries

2011-06-15 - 2012-06-15
  • 2011-06 indiewebcamp.com - Created & co-organized the IndieWebCamp 2011 event and ongoing community to empower users to own and control their web identities and content.
  • 2011-11 W3C TPAC BarCamp - ran first ever W3C TPAC BarCamp day - to great reviews (best TPAC plenary day ever).
  • 2011-11 HTML5 <time> - restored the <time> element in HTML5, enhanced it to fit author needs.
  • CSS3-UI LCWD2 - edited/published an updated CSS3 User Interface Module second Last Call Working Draft.
  • 2012-02 vendor prefixes - kicked off a rational/scientific discussion of CSS -webkit- vendor prefix issue in the W3C CSS Working Group, and also drove it internally at Mozilla. See: Platform/Layout/CSS_Compatibility for details.
  • W3C HTML/CSS/WebApps/AB - represented Mozilla in HTML & CSS WG, WebApps & Advisory Board observer/expert face-to-face meetings
  • Invited Speaker - invited to and spoke at numerous conferences on behalf of Mozilla
  • WebAPI/ContactsAPI - wrote v1 spec for WebAPI/ContactsAPI, worked with dev to implement.

Past Mozilla Projects

Past Mozilla-specific projects.

Resolved HTML5 improvements and spec issues

reject longdesc

moved to: HTML5/img

allow date only on del ins datetime attribute

CSS

CSS Style Attributes
  • CSS Styling Attribute - achieved CR!
latest published draft (CR)
https://www.w3.org/TR/css-style-attr/
latest development / in progress draft
https://dev.w3.org/csswg/css-style-attr/
spec source (for editing)
https://dev.w3.org/csswg/css-style-attr/Overview.src.html
test suite
TBD
implementation reports of the test suite
TBD
issues list for the current draft
https://wiki.csswg.org/spec/css-style-attr
  • Hixie update reference to CSS Style Attribute draft in HTML5 References
    • emailed 2011-080
    • fixed 2011-165
CSS3 Color
  • CSS3 Color draft - achieved PR!
latest published draft
https://www.w3.org/TR/css3-color/
latest development / in progress draft
https://dev.w3.org/csswg/css3-color/
spec source (for editing)
https://dev.w3.org/csswg/css3-color/Overview.src.html
test suite
https://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/
implementation reports of the test suite
https://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/
issues list for the current last call
https://wiki.csswg.org/spec/css3-color
CSS3 UI

Updated CSS3 UI Editor's draft with:

pointer-events
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
    • Wanted for post-FF4; mats will be working on it, needs spec
    • W3C: https://dev.w3.org/csswg/css3-text/#text-overflow
    • DevMo: https://developer.mozilla.org/En/CSS/text-overflow
    • Webkit: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/doc/uid/TP30001266-SW24
    • Microsoft/IE: msdn.microsoft.com/en-us/library/ms531174(VS.85).aspx (Internet Archive link)
    • write test cases for 'ellipsis' and 'clip' (default value) and confirm cross-browser support.
    • Details that RoC wants:
      • What style the ellipsis has (font, color, etc) ... does it come from the text or does it come from the element with text-overflow on it?
        • from the element with text-overflow on it, this is what WebKit and Opera do
        • need test case to see what Webkit, IE, Opera do
      • does text-overflow inherit by default or not?
        • Inherited: no
      • how does it work with text-align:right, does the ellipsis go on the left?
        • text-align does not affect text-overflow
      • how does it work with bidi text, e.g. a line of Hebrew?
        • it is rendered according to the 'direction' of the element.
      • What about mixed bidi text e.g. English followed by Hebrew? I'm particuarly interested in the case of an LTR word followed by an RTL word that doesn't fit, e.g. 
        english WERBEH
        where only "english HEB" fits, where should the ellipsis go?
        • "english BEH…"
      • Can bidi text make the ellipsis appear at the beginning of the line?
        • bidi text? no. howevrer, setting 'direction:rtl' on the element will cause any ellipses to be drawn on the left side.
      • what happens if there's replaced content near the end of the line, say an image?
        • the image would wrap to the next line. but if there is white-space:nowrap, then...
      • Do you get the ellipsis or does the image overflow?
      • If an ellipsis, where does the ellipsis go?
        • it goes instead of the image and any text you have to remove in order to make the ellipsis fit.
    • add 3571013052_d419aff822_s.jpg CSS IS AWESOME examples/tests to the spec
    • capture issues and undefined aspects from fantasai/RoC emails as of 2011-031.
    • clarify text per emails from fantasai/RoC
      • the effect of text-overflow:ellipsis on lines whose line boxes are not direct children of the block box(es) with text-overflow.
      • the behavior of text-overflow:ellipsis on a block with 'overflow' of 'scroll' (no good interop, ideal behavior documented, needs screenshots)
        • testcase from RoC: https://lists.w3.org/Archives/Public/www-style/2011Jan/att-0669/test.html
        • 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.
      • behavior of text-overflow:ellipsis on lines containing replaced elements - they're treated as large characters.
      • interaction of text-overflow:ellipsis with event handling - does not affect events or layout.
    • add string and 2-value syntax per CSS WG resolution, but noted as at-risk.
ime-mode
box-sizing padding-box
  • add box-sizing: padding-box per Mozilla definitions
CSS3 UI LCWD2

publish new CSS3 UI LCWD with new at-risk features based on above implementation evidence (or imminent implementation - kept at risk), and all known outstanding issues resolved. (back to last call because we added features after the CR, and moved some previous features to at-risk).

Completed Events

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

Events 2010

For more, see: Events/2010

Events 2011
  • 2011-03-07...2011-03-09 CSS Working Group March 2011 meeting
  • 2011-03-10...2011-03-20 SXSW - spoke on microformats, gather input for HTML5
  • 2011-03-28...2011-03-31 Web 2.0 Expo - spoke on HTML5, gather input.
  • 2011-04-10 LinkedGov Data HackCamp - discussed role of microformats/browser in open data
  • 2011-04-13...2011-04-15 UX London - gather lots of CSS3-UI input
  • 2011-04-19...2011-04-21 Where 2.0 - gather input on GeoLocation additions, browser support for geo apps
  • 2011-04-22 WhereCampSF SF 2011 - gather input on browser support for geo apps
  • ...
  • 2011-07-16 Open Web Camp III (Internet Archive link) - at Stanford, California, United States.
    • speaker - on CASSIS. See also attendees (Internet Archive link)

For more, see: Events/2011

Events 2012

See: Events/2012

Events 2013

See: Events/2013

Events 2014

See: Events/2014

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