Fwd: Removal of other semantic elements

---------- Forwarded message ----------
From: Shelley Powers <shelley.just@gmail.com>
Date: Mon, Apr 5, 2010 at 10:55 AM
Subject: Re: Removal of other semantic elements
To: Doug Schepers <schepers@w3.org>
Cc: www-style CSS <www-style@w3.org>


On Mon, Apr 5, 2010 at 9:26 AM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Shelley-
>
> CCing CSS list.
>
> Shelley Powers wrote (on 4/5/10 8:24 AM):
>>
>> The real core of the proposal is whether it's better to attempt to
>> create single purpose elements representing well defined and broadly
>> used widget behaviors created using JavaScript and CSS. My contention
>> is to do so will most likely fail, because whatever is created in the
>> browsers based on HTML specs can never hope to keep up with the state
>> of the art using the JS and CSS. And we developers and designers will
>> only use whatever is state of the art.
>
> That's demonstrably not correct.  Why do so many people still use HTML form
> controls?  Yes, many sites use custom controls from libraries, but I suspect
> they are in the minority, still.
>

I don't believe I was advocating the removal of existing form
controls, such as input and textarea. I was discussing the addition of
new elements that have been successfully implemented in libraries,
such as the progress element and the meter, which is supposedly some
form of bar gauge.

Neither of these is form specific. In fact, to create them as form
elements was a gross error.

> There may be some designers and developers that prefer to use cutting-edge
> stuff on some projects, but that is hardly a universal attitude; please
> don't imply that you speak for all developers and designers.  And we should
> also be thinking of the content creators who are not professional developers
> and designers, and who use HTML only casually as part of their job.  These
> people are very unlikely to have the time, energy, and training to use
> jQuery and the like, but they would benefit from new form controls.
>

Cutting edge? Anyone that uses a progress bar is cutting edge. Most
folks use an indeterminate throbber to signify that some action is
happening.

Evidently, it's OK for Ian and others to speak for all developers when
they created these elements. I feel I'm just as justified to speak for
all developers when I argue against them.

And progress and meter are not "form" elements. Why they were created
as such is because Ian wanted to use label with them. And the only
reason he created meter, is felt people didn't understand progress
enough and would use it incorrectly.

Oh, and these little guys are going to end up in the CSS working
group, because if you haven't already seen, each of the browsing
companies is creating a different visual appearance for these and for
the other new input types that I haven't, yet, provided a change
proposal for. They're also not currently providing a way for people to
style many aspects of the element using CSS. So we're looking forward
to a new batch of -moz, -o, etc, which will then have to go through
three years of CSS standardization while the browsers work out the
individual pieces of these elements and then begin the push to
standardize them.

> As far as "keeping up", how many form controls do we need?  How much more
> innovation is there about basic controls?  I don't see many new custom
> controls... just the same few that look a bit nicer than the native browser
> controls, and a few more that have become common enough to standardize.  I
> think HTML5 captures some of the most important ones.  If we find that's not
> enough, we can add a few more essential ones in HTML6.
>

If they were a superior offering maybe, but they're inferior to what
we have in our libraries.

Let's also consider others impacted. There's the designers who have to
figure out how to get a consistent look and feel from elements that
are styled and behave differently in each browser, and probably each
operating system.

>From a security stand point, yet more code to break, yet more code to
add vulnerabilities, yet more code to increase the size and complexity
of browsers that are beginning to get overly complicated.

Scope creep: if people think a color picker is a widely used item in
applications now, we're in for a world of hurt in the future. Color
pickers are one of the least used widgets there are.

>
>> And we'll only use what we can control, style, design, and customize.
>
> Your concern about styling is a real one.  So, rather than focus energy on
> removing these new controls, why not devote some time and energy on a
> proposal to the CSS WG on how to style all form controls, including these
> new ones?  There are lots of new CSS features being implemented which could
> be repurposed for that cause, like the corner rounding in the borders spec,
> gradients, animations and transitions, etc. Basically, any effect you can
> apply to create a "custom control" with the look and feel you want should be
> applicable to actual form controls.
>

In other words, add yet more complexity by having to now push these
through yet another committee, rather than use what we have. And add
yet more CSS for the designers and developers to figure out, as well
as going through yet another round of -moz, -o, etc.

I do not find this an efficient approach.


> What is needed for this is a detailed compendium of the various possible
> parts that any form control would be comprised of; for example, there were
> some proprietary Microsoft scrollbar-styling properties
> (scrollbar-base-color, scrollbar-track-color, scrollbar-face-color,
> scrollbar-highlight-color, scrollbar-3dlight-color,
> scrollbar-darkshadow-color, scrollbar-shadow-color, scrollbar-arrow-color)
> that I used on one of my earlier sites, and I got a lot of positive comments
> on it.  Naturally, not all UAs would have all the same parts in their own
> controls, but a defining a superset would let designers get at the vast
> majority of them (possibly as pseudo-elements, for ease-of-use with
> selectors).  A good place to start is to look at the various custom controls
> that script libraries define, and see what parts of those are stylable in
> each of those libs.
>

In other words re-create what we have now?

> How much nicer for designers and developers would it be for them to use the
> CSS skills they already have to style their controls than to have to buy
> into one or more custom libraries to build them?
>

In other words that people can use what they already use now?

> I expect this topic has already been raised (and probably rejected) for an
> addition to CSS.  But I think times have changed, and it's time to reexamine
> some of our basic premises about what CSS should be (and is) used for.  I
> don't see why the browser chrome should be inviolate, when it's such an
> important part of the look-and-feel of a site.
>
>
>> Additionally, attempting to create as single purposed elements any of
>> the widget behaviors opens the door for innumerable objects that will
>> create significant problems and cost for developers, tool builders,
>> content management systems, and yes, even browser makers.
>
> Those projects that don't want to use these new controls don't have to.
>  Browser makers have already chimed in that they are willing to implement
> them.
>

This isn't about just browsers.

What was it the new head of the W3C mentioned recently? Something
about getting developers involved, not just the browser companies. I
can't find the original posting, but I think the point was, this group
gives a great deal of priority to the browser companies, sometimes to
the neglect of other communities.

There's also the HTML Editor builders, the WYSIWYG tool creators, the
lint tools, the validators, the content management systems, the other
web application developers. This impacts on many groups other than
just browser companies.

>
>> Frankly, I'd
>> rather you all spent time making your browsers faster, better, more
>> secure, than re-creating what we better can create using our favorite
>> libraries.
>
> That's a false dichotomy.  The individuals who are working on script
> optimization and security are unlikely to be the same set of people working
> on adding new form controls.
>

But a browser is not isolated parts, all operating independently.

But if you don't like my change proposals, I would enjoy reading your
counter proposals.

> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

Shelley

Received on Monday, 5 April 2010 16:43:11 UTC