[Bug 8552] Remove the Progress Element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552





--- Comment #13 from Maciej Stachowiak <mjs@apple.com>  2009-12-29 15:40:34 ---
(In reply to comment #12)
> While the best mapping of XForms' range to HTML5 would indeed most often be
> adorned input (thx for reminding; I check on the proliferation of input/@type
> values only occasionally), the reverse mapping would give range (used with
> read-only MIP) for HTML5's proposed progress as well. 

I disagree. There is no mapping from HTML5 <progress> to XForms that preserves
semantic fidelity.  What you describe would be the XForms equivalent of <input
type=range readonly>. But <progress> does not have the same semantics as <input
type=range readonly>. One represents a progress indicator. The other represents
a range with a particular value selected, and not currently alterable by the
user. These are not the same thing.

> Genericity of XForms' set  of controls (device independence, presentation agnosticism, 
> features nice for a11y, l10n and m12n) is a better approach. 

This is really not the place to debate the merits of XForms vs. HTML. Suffice
it to say that HTML takes a different approach.

> HTML is not a UI (actually even GUI)  language and it would be both unwise and grotesque 
> (given the basis of HTML  forms' legacy) to extend it too much in that direction. 

HTML was not originally designed as a UI language, but it has evolved to be a
language for both documents and applications. And the HTML WG is chartered to
evolve HTML to support both documents and applications.

> I see two very viable styling solutions, both author friendly. One is functional notations in
> appearance values capable of expressing the necessary facets you mention. 

This is still less author-friendly than a single interface that takes care of
appearance, behavior and accessibility considerations at at once.

> The other is a binding (see  http://lists.w3.org/Archives/Public/public-html/2009Sep/0739.html
> for something similar). Thoughts, preferences, anybody?

HTML5 does in fact express the intended rendering and interaction behavior of
the <progress> element as a binding. However, it seems to me that as specified
it is not a binding that could be reused on an arbitrary element.

More generally, I think the cited message is based on an incorrect premise --
that the subject matter of HTML is only "hypertext", defined so narrowly as to
exclude even multimedia. That may have been true once, but hasn't been for at
least a decade.

> Even if progress is included, I strongly prefer a styling solution which would
> also be applicable beyond HTML5 (indeed, XForms comes promptly to mind).

You're certainly welcome to propose a syntax to get the styling of a native
progress bar, but I think the CSS WG would be a more appropriate venue.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 29 December 2009 15:40:39 UTC