RE: SVG2Reqs

HTML also has a development-economy and learning-economy which SVG can tap
into by underwriting HTML.  By development-economy, I mean I can develop a
useful application by throwing together prebuilt widgets (like HTML tables
and edit boxes and drop downs) much faster than having to create those
widgets in SVG.  Of course if the widgets won't meet the requirements HTML
will flop.   So by putting SVG under HTML one can speedily develop without
the risk of a future requirement killing the whole thing because it can't be
done with a pre-built widget.  By learning-economy, people not trained in
development can throw together a bunch of widgets to create something
useful.  Not everyone has the background and training to build widgets from
SVG.  This takes time and skill.

 

Andrew 

 

From: Shropshire, Andrew A 
Sent: Tuesday, November 08, 2011 8:32 AM
To: Shropshire, Andrew A; 'www-svg@w3.org'
Subject: RE: SVG2Reqs

 

Would like to add that the edit box is the only non-SVG item.  It is done
with a foreignObject tag and uses the HTML edit box.  So it is a bit of
cheating, however, it could have been implemented in SVG if browsers
supported keyboard input events to SVG.  The edit control also needs cut and
paste to/from clipboard but I don't see those as show stoppers.  IE9 doesn't
support foreignObject, so on that browser, a javascript prompt is used.

 

Andrew 

 

From: Shropshire, Andrew A 
Sent: Tuesday, November 08, 2011 8:00 AM
To: 'www-svg@w3.org'
Subject: SVG2Reqs

 

As demonstrated here: http://wafo.cpol.army.mil/issue/employment.svg, most
common window controls, including scrollbars, dropdown boxes, list boxes,
check boxes, tables, etc have been implemented successfully in SVG.   

 

My suggestion is that all HTML controls in the HTML standard be implemented
in SVG as well as all visual effects in HTML.  HTML rendering would be
applied SVG.  In this way you simplify the rendering in browers by replacing
2 incompatible rendering approaches with one approach.

 

One would then achieve the bandwidth economy of HTML whereby a table can be
specified in a few lines (vs the 50Kb in SVG) when a customized table is not
needed, yet still retain the precision of layout and low level control
afforded by SVG if cookie-cutter HTML controls are insufficient.
Conceptually, HTML would be a set of common algorithms and controls built in
SVG that would be already on the browser (they need not be downloaded each
time) - ie HTML would be an SVG standard library.

 

In a similar vein, would like to simplify the incompatible architectures
posed by WebGl and Canvas and create a unified SVG-WebGl-Canvas-HTML
conceptual model, however,  this may be far off.  However, HTML seems more
and more like simply a derivative of SVG (and can be thought of as applied
SVG because it would appear one can do everything in HTML as pure SVG).

 

Andrew