HTML5 Form Elements

[BeeRich]

Hiya kids.

Instead of asking in support, I thought I would ask here in the group.

HTML5 has new form elements. They are not currently choosable in the
posted most recent version (non-beta) of BBEdit. Will this change
soon?

Cheers

[G. T. Stresen-Reuter]

On Feb 5, 2011, at 2:03 PM, BeeRich wrote:

> HTML5 has new form elements. They are not currently choosable in the
> posted most recent version (non-beta) of BBEdit. Will this change
> soon?

Could you be more specific about which elements are new in HTML5 (and consequently which ones are not "chooseable" in BBEdit)?

I'm just starting with HTML5 and was unaware that there were new form elements. I'd love to know what they are!

Ted Stresen-Reuter

[Ted Burger]

Here is a good description.

http://diveintohtml5.org/forms.html

I do think that you should address this question to the support at BBedit.

Thanks,
Ted
*********************** Ted Burger ****************************
t...@tobsupport.com ********* www.tobsupport.com

> --
> You received this message because you are subscribed to the
> "BBEdit Talk" discussion group on Google Groups.
> To post to this group, send email to bbe...@googlegroups.com
> To unsubscribe from this group, send email to
> bbedit+un...@googlegroups.com
> For more options, visit this group at
> <http://groups.google.com/group/bbedit?hl=en>
> If you have a feature request or would like to report a problem,
> please email "sup...@barebones.com" rather than posting to the group.
> Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>

[BeeRich]

Specifically form elements:

phone, search, url, email, datetime, month, week, time, datetime-local, number, range, and color. I would have hoped for some kind of GUI for building these types.

I was under the impression that BBEdit would be "all or nothing" when it came to integrating HTML5.

Cheers

[Watts Martin]

On Feb 5, 11:02 am, BeeRich <beer...@gmail.com> wrote:

> Specifically form elements: phone, search, url, email, datetime, month, week, time, datetime-local, number, range, and color.

Those aren't form elements, they are new types for the existing form
input element. It is true that BBEdit's "tag maker" should handle
these, as they're pretty important parts of the spec. However...

> I would have hoped for some kind of GUI for building these types.

... I'm not entirely sure what you mean by that. The tag maker dialog
box needs to be extended--a check just now suggests that it doesn't
actually recognize *any* of the new HTML5 elements if you try to edit
them--but I imagine a future release will indeed get there. To the
best of my knowledge, that's as much "builder GUI" as BBEdit has ever
had.

[BeeRich]

On 2011-02-06, at 3:58 AM, Watts Martin wrote:

> Those aren't form elements, they are new types for the existing form
> input element. It is true that BBEdit's "tag maker" should handle
> these, as they're pretty important parts of the spec. However...
>
>> I would have hoped for some kind of GUI for building these types.
>
> ... I'm not entirely sure what you mean by that. The tag maker dialog
> box needs to be extended--a check just now suggests that it doesn't
> actually recognize *any* of the new HTML5 elements if you try to edit
> them--but I imagine a future release will indeed get there. To the
> best of my knowledge, that's as much "builder GUI" as BBEdit has ever
> had.

Yes, I know. That's why I'm asking. But having checkboxes on items I've never seen before, would be nice. Currently, check boxes for autofill are not there, so I was wondering where all of this is going. It seems behind, and I can only assume it will be there in the future. I'd like to start developing for 5, even though browser support is still quite behind.

[Brian M. Frick]

The article that, I believe it was Tom, posted, explains quite specifically how you can code in HTML5 and current browsers will gracefully ignore the new tags. I have begun coding all my sites in HTML5 and would *never* go back.

As for BBEdit -- they probably have no reason to implement something that's not quite yet set in stone; and to do so takes some time and thought. In other words, t'll be there when it gets there.
--
Brian

[BeeRich]

On 2011-02-06, at 10:42 AM, Brian M. Frick wrote:

> The article that, I believe it was Tom, posted, explains quite specifically how you can code in HTML5 and current browsers will gracefully ignore the new tags. I have begun coding all my sites in HTML5 and would *never* go back.

I've seen and tested otherwise.

> As for BBEdit -- they probably have no reason to implement something that's not quite yet set in stone; and to do so takes some time and thought. In other words, t'll be there when it gets there.

If it was a graceful transition, then the tools should be made available as people would choose to be coding or testing in 5. Just because it's there doesn't mean people have to use it. And it is "there" as a new document choice, but falls short elsewhere.

Thanks for the advice on "it's here when it's here". I didn't know that.

[G. T. Stresen-Reuter]

This is just a guess but I think Brian was saying that the HTML 5 specification isn't "there" yet. Again, I'm just getting into HTML 5 (and thus, am speaking out of ignorance, not uncommon mind you) but I don't recall seeing an official HTML 5 specification and until one is published, change happens (much to the chagrin of our beloved BBEdit developers).

> Thanks for the advice on "it's here when it's here". I didn't know that.

And to paraphrase a famous politician, I think that depends on what the definition of "it" is ;-)

Ted Stresen-Reuter

PS: Extra credit for those who correctly guess the original quote and can cite the source!

[Brian Frick]

You're right... I wasn't being flippant when I said that; I meant precisely that the HTML5 spec is not completed, and instead of adding something that might (will) change over time, BareBones will smartly wait until it's completed before implementing it in BBEdit.
--
Brian

[BeeRich]

On 2011-02-07, at 11:35 AM, G. T. Stresen-Reuter wrote:

> This is just a guess but I think Brian was saying that the HTML 5 specification isn't "there" yet. Again, I'm just getting into HTML 5 (and thus, am speaking out of ignorance, not uncommon mind you) but I don't recall seeing an official HTML 5 specification and until one is published, change happens (much to the chagrin of our beloved BBEdit developers).

Ah I guess that is relevant since it might change. Didn't think of it changing. I guess I'm just hungry for 5.

[Robert A. Rosenberg]

At 08:37 -0500 on 02/07/2011, BeeRich wrote about Re: HTML5 Form Elements:

>On 2011-02-06, at 10:42 AM, Brian M. Frick wrote:
>
>> The article that, I believe it was Tom, posted, explains quite
>>specifically how you can code in HTML5 and current browsers will
>>gracefully ignore the new tags. I have begun coding all my sites
>>in HTML5 and would *never* go back.
>
>I've seen and tested otherwise.

What has failed with attempting to view a HTML5 page with current
browsers (ie: What has failed to gracefully degrade)?

The only case I know of is IE (of course) which will not recognize
(and gracefully degrade the new HTML5 tags and parms) unless you use
the HTML5SHIV (See
<http://www.seangw.com/wordpress/index.php/2010/07/css3-for-the-masses-html5shiv-css3-pie-possible/>
or <http://html5shim.googlecode.com>) or modernizr.js
(<http://www.modernizr.com>).

[BeeRich]

I recently wrote a simple HTML5 form test page and I noticed the following in Mac Safari (5.0.3):

- a numbers field won't use the increment/decrement toggle buttons for decimals.

- datetime, datetime-local and date are only demonstrating a text input. I believe Opera displays a proper calendar, which from what I understand, is a goal of having those fields. This also doubles as a problem because of the date format. I've had clients which requested mm-dd-yy format. Perhaps something more complex such as a MySQL formatting could help, but then we get back to the whole calendar presentation issue.

- time defaults to a 24 hour clock format.

- range has the slider, but there is nothing to demonstrate what the minimum and maximum values are, along with chosen value and incremental values.

- field specific validation on the form submit didn't throw any errors, but was demonstrated in other browsers

They all "work", but it seems quite far from where we could call it "useable" without having to rewrite the majority of code to wrap around it. Not to mention the differences amongst browsers.

I can see BBEdit being inside the realm of providing dialog boxes (what I called the GUI) with options for things like range limits, step values, etc.

[Robert A. Rosenberg]

Thank you for replying to my query.

Unfortunately, your examples are all of the "Not [yet] Supported" not the (as I queried) "Does not gracefully degrade" type. If I code "input type="email" ..." and there is no support it will gracefully degrade and act as a type="text" as opposed to not displaying anything.

If you go to the modernizr.com site, the home page displays a chart of what HTML5 features are supported by your browser. Going to <http://diveintohtml5.org/detect.html#input-types> shows which of the new input type parms are supported (and lists all of them). The article there explains about all the new features of HTML5 and shows in the respective section what support for the feature your browser has.

[BeeRich]

I recently wrote a simple HTML5 form test page and I noticed the following in Mac Safari (5.0.3):

- a numbers field won't use the increment/decrement toggle buttons for decimals.

- datetime, datetime-local and date are only demonstrating a text input. I believe Opera displays a proper calendar, which from what I understand, is a goal of having those fields. This also doubles as a problem because of the date format. I've had clients which requested mm-dd-yy format. Perhaps something more complex such as a MySQL formatting could help, but then we get back to the whole calendar presentation issue.

- time defaults to a 24 hour clock format.

- range has the slider, but there is nothing to demonstrate what the minimum and maximum values are, along with chosen value and incremental values.

- field specific validation on the form submit didn't throw any errors, but was demonstrated in other browsers

They all "work", but it seems quite far from where we could call it "useable" without having to rewrite the majority of code to wrap around it. Not to mention the differences amongst browsers.

I can see BBEdit being inside the realm of providing dialog boxes (what I called the GUI) with options for things like range limits, step values, etc.

On 2011-02-07, at 2:29 PM, Robert A. Rosenberg wrote:

[Paul Burney]

> Unfortunately, your examples are all of the "Not [yet] Supported" not
> the (as I queried) "Does not gracefully degrade" type. If I code
> "input type="email" ..." and there is no support it will gracefully
> degrade and act as a type="text" as opposed to not displaying
> anything.

I've had problems with the newer input types using various browsers.
In one case, I had multiple email address fields on a page (with other
fields). Having them set to type="email" caused browser autocomplete
features to go crazy in Opera and Chrome, making the form unusable in
those browsers.

I would still recommend trying to use the new form elements, but I
would also recommend testing them in a wide variety of browsers that
your users will be using, and being prepared to scrap their use if
necessary.

-Paul Burney
http://www.burney.ws/

[BeeRich]

Ya not so graceful after all.

[Robert]

It wouldn't surprise me at all if they were already working on this.
"HTML5" support will be another "buzz" compliant feature. :-)