[Bug 8552] Remove the Progress Element

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





--- Comment #14 from Krzysztof Maczyński <1981km@gmail.com>  2009-12-30 19:27:57 ---
I'll comment on just 2 of your points, since others can be easily seen to be
either obvious or highly contentious and discussed many times elsewhere.

> 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.
Of course <input type="range" readonly="readonly"> tag is also a range control
in XForms which takes an approach from 50000 metres and makes distinctions
among control types only as much as necessary from the perspective of binding
to an underlying data model (I called it presentation agnosticism). If you want
to tweak presentation, you use CSS, XBL and such. If you want to enrich
semantics (and possibly base presentational aspects on it as a sensible good
practice), use RDF, e.g. via WAI-ARIA. Both are laudable endeavours.

You seem to prefer a universal hammer both for painting your walls and
preparing salads. I'm not here to prevent you from doing so. I just want to
ensure for myself and numerous others the ability to use for particular types
of tasks the tools we find most appropriate and have them interoperate in clean
and simple ways. Please don't deprive us of what we believe is better. Can't we
tend to solve problems in ways which don't step on each other's feet?
(I know I've taken even more liberty than you did in digressing from the bug at
hand. Please understand the motivation based on our needs and the threat we
perceive from some WHATWG tendencies.)

>> 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 CSS WG is going to work on it nevertheless. That would be a good time to
discuss details. But about author friendliness I think the issue is the same as
usually. If you do just toy apps, one-off eye candies or similar plankton
(which is what most authors actually do, but they contribute little towards
innovation and are served more easily with high level authoring tools), you'll
likely prefer to have everything you find useful at your fingertips in a
syntactically uniform way and won't be hindered much by quirks and
inconsistencies. Still today most authors prefer presentational markup to CSS
(especially for layout, which actually wasn't a priority for levels 1 and 2),
although few speak about it openly, knowing it's generally frowned upon. But
when you want to do something great and innovative, you start appreciating
clean design with no idiosyncratic obstacles, mathematically precise rules with
as few exceptions as possible, modularity, orthogonality and separation of
concerns. So again, please do whatever legacy content needs but treat it as
legacy, a mess to deal with, not the ideal to perpetuate, and using solutions
which don't get into the ways of people knowing what they want with a sane
approach.

Back to the point at hand, I'm not against the progress element type any more
than against turning HTML into a bloated UI language in general, biased towards
presentation in a browser and having little value without scripting. If you go
ahead and keep it in, I believe the right final destination for it will anyway
be something like a legacy UI module in a future version of M12N.


-- 
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 Wednesday, 30 December 2009 19:27:59 UTC