Community & Business Groups

  • AccessAbility - Chennai

    3 Sponsors
    The primary objective of this group is be a discussion forum and to teach the necessity of accessibility within the Chennai region. A secondary objective is to raise awareness of Web accessibility among college students. This group will not produce specifications.
    Support creation Comment on the proposal Report a problem
  • Cryptoledgers

    3 Sponsors
    This group aims at creating an international and interdisciplinary network of researchers - academic and non-academic - interested in exploring the economic, legal, technical and societal challenges raised and faced by cryptoledger-based applications, such as Bitcoin or Ethereum. The purpose of this group is to enable peer support and collaboration for researchers across institutions and disciplines to achieve a better understanding of the opportunities and risks posed by cryptocurrencies and other cryptoledger-based applications. This group includes those doing theoretical analysis, investigating tools and applications that might hinder or support the adoption of alternative cryptocurrencies, or collaborating on the development of new tools to further promote their deployment worldwide. This group will not publish specifications.
    Support creation Comment on the proposal Report a problem
  • Exposing IEEE LOM metadata as Linked Data

    4 Sponsors
    This community recommends an approach for exposing IEEE Learning Object Metadata (LOM), a metadata standard for educational contents, as Linked Data. It is intended as a bridge for linkage of educational metadata into Linked Open Data (LOD). This community aims to describe a mapping of IEEE LOM elements to RDF based on Linked Data principles.
    Support creation Comment on the proposal Report a problem
  • Extensible Data Model Declaration Language for Education

    1 Sponsors
    XDMDL is proposed as a high level schema language that will allow people to define, share, combine, reference and profile data models. The proposal has grown out of a requirement recognised within the education community working in the SCORM and xAPI traditions, and it is intended to pilot the specification by demonstrating how it can help improve data interoperability between software systems designed to manage and deliver learning activities.
    Support creation Comment on the proposal Report a problem
  • Math Protocol Handler

    3 Sponsors
    This group's aim is to discuss and agree on the use of a custom protocol handler (math:) and standard parameters for enabling the export of mathematical expressions in MathML to other applications, such as assistive technologies, graphing calculators, math notebooks and other mathematics oriented applications, such as IPython and MATLAB. For more information, see https://wiki.benetech.org/display/MATH/Protocol+Handlers+for+External+Applications+to+Process+MathML
    Support creation Comment on the proposal Report a problem
  • The Hardware Pixel

    1 Sponsors
    A group for people who love pixels! This group is in support of exposing device pixel densities to web developers and letting web developers have the ability to use 'hardware pixels' instead of 'CSS pixels' on demand. Native developers have this affordance, why can't we? Hardware pixels! We want hardware pixels! ## What we want ## We want metrics! The hardware pixel density of a screen can live in the window.screen object as window.screen.pixelDensity, for example. The value would be the average of the vertical pixel density and the horizontal pixel density of the screen (in hardware pixels per unit). Vertical and horizontal pixel densities of the screen can be exposed in window.screen.verticalPixelDensity and window.screen.horizontalPixelDensity. Yes, the vertical and horizontal values don't always have a ratio of 1 across devices. Pixel Aspect Ratios are important for developers and designers that truly care about device-independence. ## How can it be done? ## Easy. The EDID data in modern screens tells us the width and height of a display in millimeters, the native resolution of the screen, and other interesting information. This info allows us to calculate a screen's hardware pixel density in pixels per millimeter with floating point precision. Exposing these values in window.screen is even more trivial. ## Why do we want these values? ## In this modern day, developers are moving towards device-independent development more than ever before. By exposing physical characteristics of a screen (when supported by the screen (just like how OpenGL is exposed through WebGL when supported by a device)) web developers will be able to make device-independent decisions on their development process. Currently, the lack of these metrics means that a web app can only look *almost* the same across devices, but not necessarily *exactly* as intended. We're engineers; *almost* is not enough. For example, suppose I want to make a push menu that is *always* 1 physical inch wide. This is currently not possible because inches in the web are "CSS inches", not physical inches. CSS units like centimeters, millimeters, and inches are currently unreliable across devices. You might think "why not just create a div element that is 1 cm wide, then get it's width in pixels and that's how many pixels per cm you have". Sure, that works, but those are *CSS* pixels per *CSS* centimeter. On top of that, not all operating systems operate at the same dpi, and to make matters worse not all devices have a devicePixelRatio of 1 (mines 2 by default in Mac OS X Yosemite). So the value that you'll get from this technique, if you adopt it right now, vary a *whole lot* across devices. We can't say with any confidence that something being displayed on various screens on multiple devices is 1 physical inch wide. Giving us these screen metrics will not only help us, it will help the future generation of developers because not only will exposing these screen metrics based on EDID info (when supported by the screen) get us closer to device-independent development more often, it will also promote the use of the EDID standard by screen manufacturers so that the next generation can benefit even more from the exposed screen metrics. ## Pixel Freedom for All! May the pixel be with you! ##
    Support creation Comment on the proposal Report a problem
  • Web Background Sync

    4 Sponsors
    This group is developing a specification to allow web apps to run tasks in the background. This includes running after the user has navigated away from the page, closed the browser, or the device has fallen asleep. We focus on preserving user privacy and resources while providing a useful and expressive API.
    Support creation Comment on the proposal Report a problem