Re: native elements versus scripted

On Tue, Apr 6, 2010 at 4:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> From: Shelley Powers <shelley.just@gmail.com>
>> On Tue, Apr 6, 2010 at 3:29 PM, Jonas Sicking <jonas@sicking.cc> 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.
>

Well, there really isn't many reasons why. Either they wanted to do
their own, they didn't know about the libraries, or they created the
application before the libraries.

But not sure what this has to do with change proposals, so moving on...

>>> 2. What do you do in non scripted environments, such as HTML UAs otBher
>>> 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
> documents.
>

I don't believe I advocated a scripted replacement for figure, aside, or meter.

I do for details. Can you give an example of a non-scripted UA that
would also implement details?
'
>> 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.
>

In my original email, I gave demonstrations. It's not cost as in
dollars, but costs as in the negative impacts. For one, not being able
to style the progress element's "chrome" so to speak.

>>> 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:
>
> <html>
>  <head>...</head>
>  <body>
>    <form action="form.php">
>      <label>I read the agreement <input type=checkbox name=ireadit></label>
>    <form>
>  </body>
> </html>
>
> 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*.
>

In my PHP template for my sites, I include script libraries. I don't
include script, because Drupal modularizes the libraries, so we don't
have to directly touch the script--though I do when I'm playing around
with my own libraries.

For one of the scripting libraries, Lightbox, I also add a class name
to my img elements.


>>> 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.
>

You can insert an input element and give an identifier. I think you
can also insert a script element, and give it a source. Or you can
pick an option from your CMS and it does it all for you.

>>> 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.
>

OK

> / Jonas
>

Shelley

Received on Tuesday, 6 April 2010 21:49:27 UTC