Re: native elements versus scripted

> From: Shelley Powers <>
> On Tue, Apr 6, 2010 at 3:29 PM, Jonas Sicking <> wrote:
>> I agree that libraries could be used to add a lot of functionality
>> that is missing from HTML and add ARIA to make this accessible.
>> However relying on that still seems to have a few problems:
>> 1. A lot of people don't use libraries. I still see lots of websites
>> that use hand rolled date pickers (for example using 3 <select>s) and
>> aren't otherwise using libraries.
> I have to assume that most of the people who are doing the hand rolled
> work are doing so because they want to play with the technology on
> their own, or they did the work before the libraries existed.

I wouldn't make the same assumption, but I don't like guessing.

>> 2. What do you do in non scripted environments, such as HTML UAs other
>> than browsers?
> Well, I would say that the progress element is pretty useless whether
> it's built-in or created via a library.

Yes, for <progress> I can't immediately think of use cases. However
<figure>, <aside>, <meter>, <details> seem useful for generic

> In fact, I'd rather you focus specifically on cost and benefits
> perhaps related to the elements in my change proposals? I can't help
> this would focus the discussion on specifics.

I'm not sure how to do this given that I can't think of a way to get
any hard numbers to compare.

>> 3. You can't use scripting libraries to insert a date picker directly
>> in the markup.
> Are you talking about modifying the markup? Or inserting a date picker
> into the DOM and associated it with the element?

I can using a text editor, or using PHP, create simple markup that
contains a checkbox:

    <form action="form.php">
      <label>I read the agreement <input type=checkbox name=ireadit></label>

However if I want to add a date picker (to allow the user to indicate
when he/she read the agreement) there is no way to insert that
directly in the markup. Instead I have to call into script to do a
bunch of post processing on the DOM. I.e. I can't include the date
picker in the *markup*.

>> 4. How would a HTML editor insert a date picker? If it inserts a pile
>> of <div>s with ARIA, will another editor understand how to handle
>> this? While retaining styling etc?
> An HTML editor wouldn't. This isn't a HTML element. The elements to
> make up the datepicker are inserted into the DOM, not markup. I would
> say that's how Opera works now, but we don't have direction access to
> the components.

If HTML editors can't insert date pickers, that would be a loss in my
opinion. I don't see why they wouldn't want to do that given that they
currently support inserting other form elements.

>> However I will note that <select> and <input type=checkbox> are
>> largely unstylable, but still have seen quite a success on the web
>> today. And I'll also note CSS is already powerful enough to style the
>> hidden attribute and the <figure> and <aside> elements. So I don't see
>> that lack of styleablility could be an argument to remove those.
> Again, though, these elements are part of the DOM, and can be styled.
> The Date picker components are not accessible by us. All we can do is
> cast a CSS styling over the whole thing, which unfortunately has
> negative consequences on the actual date field, whether the date
> picker is supported or not.

I can't really do much more than repeat the section from my mail that
you are quoting, so to avoid going in circles I won't.

/ Jonas

Received on Tuesday, 6 April 2010 21:39:04 UTC