Canmove, confirm
2,698
edits
Changes
→Web Apps: prioritize HTML5 fixes to the top (and related, DOM prefixing) to get them in the editor's queue and community ASAP for consideration, reflection, expansion
== Web Apps ==
=== HTML5 spec improvements ===
A set of tasks/projects for improving the state of the [[HTML5]] specification. Proposals will be moved to separate pages once mature enough for submission to [[standards]] bodies.
==== keeping crappy stuff out ====
===== reject longdesc =====
* [http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc reject longdesc attribute]
** 2010-06-26 answered W3C HTML WG survey on related issue 30
** tweeted: http://tantek.com/2010/177/t4/objecting-longdesc-attr-html5 , http://twitter.com/t/status/17127775107
===== remove meta Content-Language =====
* [http://wiki.whatwg.org/wiki/Content-Language remove meta Content-Language]
** 2010-06-26 answered W3C HTML WG survey on related issue 88
===== investigate alt attribute revisions =====
Regarding http://www.w3.org/TR/html5/embedded-content-1.html#guidance-for-conformance-checkers
The complexity of the new alt attribute in HTML5 is bad for authors.
We should remove the last two points in this section:
* "... document is an e-mail ..." - not a useful case
* meta generator - causes as many problems as it solves
See related http://www.w3.org/html/wg/tracker/issues/80
Need to follow-up with Jonas Sicking to get more details on this one.
==== restoring pragmatic HTML4 things ====
* <code><cite></code> element for names of speakers
==== upgrade HTML4 features to be more flexible and usable ====
* <code><ins></code> and <code><del></code> <code>datetime</code> attribute should allow YYYY-MM-DD in addition to full ISO8601 datetime.
** easier for hand-authoring
** no need to force authors to enter artificial precision (e.g. YYYY-MM-DDT00:00:00Z instead of YYYY-MM-DD)
==== improving new features ====
* expand <code><time></code> and new date/time <code><input></code> elements to be consistent and reflect more real world use cases
** impedance match. handle the same set of year, month, date, time variants/subsets.
** more inputs/times. expand both time/input to handle additional real world cases
*** YYYY
*** --MM-DD
* improve <code><time></code> element to support uses analogous to the "value class pattern" date and time separation use case (compose nested <code><time></code> elements into a single date and time)
** perhaps even use a <code><time></code> to compose multiple nested date/time <code><input></code> elements for specific date/time components into a single date and/or time.
* <code><meter></code> - 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.
* <code><summary></code> (inside <code><details></code>)
** need a more specific name. summary is too generic sounding of an element name for this special usage. Similar to the problem with <code><address></code> (special use - for contact information for the document, but used as a generic "address" for street addresses).
** alternatively make a generic <code><summary></code> element - make it an actual summary inside <code><article></code> or <code><body></code>, as well as inside <code><details></code>. Another advantage is that this is close to the semantic of the Atom "summary" element, and the hAtom microformat 'entry-summary' property.
* <code>sandbox</code> feature on <code><iframe></code> should be considered for removal.
** needs security review
** will be a lot of work to implement
** may not actually solve the problem it is intending to solve
** get more input from Jonas Sicking
=== 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:
# '''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 [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html 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 [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code><blink></code> and <code><marquee></code> (which has many odd details), nevermind the classic example of <code><table></code> 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 [http://www.w3.org/TR/2009/WD-webstorage-20091222/ 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:
<pre>- abbreviated_vendor_prefix - property_name</pre>
(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 [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx 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.
[https://developer.mozilla.org/en/DOM/window.onmozorientation 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:
<pre>vendor_prefix _ unprefixed_name</pre>
E.g. in the above example of mozOrientation, we really should be using:
<pre>moz_Orientation</pre>
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
=== 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.
** 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.
*** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.
== Social and Identity ==
