More on <input> syntax proposal

[fprog]

I read the section 2.4 on input:
http://www.whatwg.org/specs/web-forms/c ... extensions
and I'm extremely glad of "date", "time", "number"

The calendar should be fully CSS stylable and could be make
to look stylish like their JavaScript equivalent:
http://www.dynarch.com/projects/calendar/

However I think that type="number" should be "long long" only
or /^[\+\-]?[0-9]+$/,

while type="float" or "double" as you which
should be /^[\+\-]?[0-9]+\.?[0-9]*([Ee][\+\-]?[0-9]+)$/

So this can be valid. I don't see also "money" which would be
2 decimal from 0.00 to 99,999,999,999.99.
or "percent" which would be 0.000 - 100.000%

On 2.6 pattern, I fully agree except I want a "bright" browser:

<input type="text" name="CanadianZipCode"
convert="upper"
pattern="[A-Z][0-9][A-Z]\-[A-Z][0-9][A-Z]" />
should display [___-___] as the result

Another work around is to have:

<input type="text" name="CanadianZipCode"
convert="upper"
pattern="[A-Z][0-9][A-Z]\-[A-Z][0-9][A-Z]"
display=" - "/>

Same for this:

<input type="text" name="AmericanPhone"
pattern="\([0-9][0-9][0-9]\)\-[0-9][0-9][0-9]\-[0-9][0-9][0-9][0-9]"
display="( )- - "/>

So that a user type 305 555 6789 (no dash) and backspace on 6 goes to 5.

Don't get me started on stupidities like this:

(<input name="areacode" type="text"/>) <input name="phonepre" type="text"/> - <input name="phonepost" type="text"/>

and then some glue javascript nightmare to make it work like it should.


The goal is simple: Remove all the JavaScript work-around.
Why should I have to import 30K of JS lib everytime I write a webpage?

Also, missing is this VERY NEEDED FEATURE!

<input type="richtext" name="wordpadeditor">
<b>This <i>is</i> so cool man</b>
....
Finally, this is a REAL browser
</input>

TinyMCE work arounds MUST DIE.
http://tinymce.moxiecode.com/

You can think of a richtext input as an "editable <iframe>"
that could work also, BUT that <iframe> must be submittable by forms.

<iframe editable="true"> ... </iframe>


Another nice to have would be JSTL or Struts or equivalent logical
construct within HTML like this:


<switch name="zipswitch" value="CA">
<case match="(CA)|(US)">
<input type="text" name="zipcode" />
</case>
<default>No zipcode</default>
</switch>

So I can write a no brainer:

<select name="country"
onchange="document.getElementById('zipswitch').value = this.value">
<option>CA....

or like everyone does nowaday:

onchange="$('zipswitch').value = this.value"


Input, comments, better workaround all welcome of course =)

[zcorpan]

Wow, a lot of good stuff in there. Perhaps you should have started different threads for each proposal so that they can be discussed separately. We'll see how it goes, if it becomes hairy then we can always split it up afterwards...

The calendar should be fully CSS stylable and could be make
to look stylish like their JavaScript equivalent:
http://www.dynarch.com/projects/calendar/

CSS is out of scope for the WHATWG. You should forward this to www-style@w3.org . If you want to discuss it here (which is fine) please start a new thread in Off Topic.

However I think that type="number" should be "long long" only
or /^[\+\-]?[0-9]+$/,

while type="float" or "double" as you which
should be /^[\+\-]?[0-9]+\.?[0-9]*([Ee][\+\-]?[0-9]+)$/

So this can be valid. I don't see also "money" which would be
2 decimal from 0.00 to 99,999,999,999.99.
or "percent" which would be 0.000 - 100.000%

Doesn't the step="" attribute cater for your use-cases here?

On 2.6 pattern, I fully agree except I want a "bright" browser:

<input type="text" name="CanadianZipCode"
convert="upper"
pattern="[A-Z][0-9][A-Z]\-[A-Z][0-9][A-Z]" />
should display [___-___] as the result

Another work around is to have:

<input type="text" name="CanadianZipCode"
convert="upper"
pattern="[A-Z][0-9][A-Z]\-[A-Z][0-9][A-Z]"
display=" - "/>

Same for this:

<input type="text" name="AmericanPhone"
pattern="\([0-9][0-9][0-9]\)\-[0-9][0-9][0-9]\-[0-9][0-9][0-9][0-9]"
display="( )- - "/>

So that a user type 305 555 6789 (no dash) and backspace on 6 goes to 5.

Don't get me started on stupidities like this:

(<input name="areacode" type="text"/>) <input name="phonepre" type="text"/> - <input name="phonepost" type="text"/>

and then some glue javascript nightmare to make it work like it should.


The goal is simple: Remove all the JavaScript work-around.
Why should I have to import 30K of JS lib everytime I write a webpage?

A good proposal, although I'm not sure if there is anything in particular that is stopping UAs from implementing this behavior for pattern="".

Also, missing is this VERY NEEDED FEATURE!

<input type="richtext" name="wordpadeditor">
<b>This <i>is</i> so cool man</b>
....
Finally, this is a REAL browser
</input>

TinyMCE work arounds MUST DIE.
http://tinymce.moxiecode.com/

You can think of a richtext input as an "editable <iframe>"
that could work also, BUT that <iframe> must be submittable by forms.

<iframe editable="true"> ... </iframe>

Don't the contenteditable="" and .designMode attributes in HTML5 cater for this? You still have to use JS for it to be submitted though. Is that a problem?

Another nice to have would be JSTL or Struts or equivalent logical
construct within HTML like this:


<switch name="zipswitch" value="CA">
<case match="(CA)|(US)">
<input type="text" name="zipcode" />
</case>
<default>No zipcode</default>
</switch>

So I can write a no brainer:

<select name="country"
onchange="document.getElementById('zipswitch').value = this.value">
<option>CA....

or like everyone does nowaday:

onchange="$('zipswitch').value = this.value"

It seems like <datalist> covers this use-case.

[fprog]

I was only suggesting that the UA should be able to style
this using existing CSS, that's all.

However I think that type="number" should be "long long" only
or /^[\+\-]?[0-9]+$/,

while type="float" or "double" as you which
should be /^[\+\-]?[0-9]+\.?[0-9]*([Ee][\+\-]?[0-9]+)$/

So this can be valid. I don't see also "money" which would be
2 decimal from 0.00 to 99,999,999,999.99.
or "percent" which would be 0.000 - 100.000%

Doesn't the step="" attribute cater for your use-cases here?

step could be used,
but the point was that percent and money
have specific regional settings that the UA must support,
like space over comma and dot over comma,
the dollar sign on left or right, minus vs parenthesis, etc.

i.e. Between US $ (1,000,000.00) vs -1 000 000 $ US

Same way as date could be: yyyy-mm-dd mm/dd/yyyy ...
altough they are entered differently, I suggest that the UA
always post them using YYYYMMDD and HHmmSSssss

Same way as time could be: 5:00pm or 17h00

On 2.6 pattern, I fully agree except I want a "bright" browser:

<input type="text" name="CanadianZipCode"
convert="upper"
pattern="[A-Z][0-9][A-Z]\-[A-Z][0-9][A-Z]" />
should display [___-___] as the result

Another work around is to have:

<input type="text" name="CanadianZipCode"
convert="upper"
pattern="[A-Z][0-9][A-Z]\-[A-Z][0-9][A-Z]"
display=" - "/>

Same for this:

<input type="text" name="AmericanPhone"
pattern="\([0-9][0-9][0-9]\)\-[0-9][0-9][0-9]\-[0-9][0-9][0-9][0-9]"
display="( )- - "/>

So that a user type 305 555 6789 (no dash) and backspace on 6 goes to 5.

Don't get me started on stupidities like this:

(<input name="areacode" type="text"/>) <input name="phonepre" type="text"/> - <input name="phonepost" type="text"/>

and then some glue javascript nightmare to make it work like it should.


The goal is simple: Remove all the JavaScript work-around.
Why should I have to import 30K of JS lib everytime I write a webpage?

A good proposal, although I'm not sure if there is anything in particular that is stopping UAs from implementing this behavior for pattern="".

The current specification does not mention the above "display" attribute
or similar behavior. There's a difference between expecting something
and wanting something from the web designer point of view.
If I want "(___)-___-____" I really mean it.


The goal is to specify a recommandation on how it should work,
giving too much liberty on UAs, means that totally different ways
of working will happen and therefore, work-arounds often using
quirks mode and javascript will have to be used again.

Also, missing is this VERY NEEDED FEATURE!

<input type="richtext" name="wordpadeditor">
<b>This <i>is</i> so cool man</b>
....
Finally, this is a REAL browser
</input>

TinyMCE work arounds MUST DIE.
http://tinymce.moxiecode.com/

You can think of a richtext input as an "editable <iframe>"
that could work also, BUT that <iframe> must be submittable by forms.

<iframe editable="true"> ... </iframe>

Don't the contenteditable="" and .designMode attributes in HTML5
cater for this? You still have to use JS for it to be submitted though.
Is that a problem?


Yes, it is. Stuff like that should work out-of-the-box even with JS disabled.
I don't want a "hackery", I want a <richtextbox> or <input type="richtext"> or <input type="html"> or
<textarea type="richtext"> or <textarea type="html">

Imagine how many forums, web app, blogs use this feature.
This kind of stuff exists for more than 10 years on Windows,
but never happened on HTML before tinyMCE and similar,
and the question is WHY??? It's so fundamental.

Another nice to have would be JSTL or Struts or equivalent logical construct within HTML like this:

<switch name="zipswitch" value="CA">
<case match="(CA)|(US)">
<input type="text" name="zipcode" />
</case>
<default>No zipcode</default>
</switch>

So I can write a no brainer:

<select name="country"
onchange="document.getElementById('zipswitch').value = this.value">
<option>CA....

or like everyone does nowaday:

onchange="$('zipswitch').value = this.value"

It seems like <datalist> covers this use-case.[/quote]

<datalist> is for google like search this is different.

JavaScript is not HTML designer aware, tags are.

i.e. This kind of logic can be created with a bright content editor,
think "frontpage, dreamweaver, etc",
but JavaScript will always have to be handcrafted.

Most graphic artist are not coders and vice-versa,
that's why CSS was invented. But simple common logic needs
to be expressed simply.

[MrBill]

Why not required="y" or required="n" ? (or blank for no as well)
I think things like selected="selected" or checked="checked" are silly,
they need to be simpiler:

selected="y"; selected="n" or blank
checked="y"; checked="n" or blank
..

In textarea add a LIMIT to limit number of characters, make it optional.
similar to maxlen for text
eg: LIMIT="200" this would limit the TextArea to 200 characters.

The new Date/time fields could have a format type that's optional
where it'd read something like: format="mm/dd/yyyy", etc for the field.

Can we suggest event handler's ?
if so:
onUnFocus !

File:
Add a filter like Delphi/C, etc.
make it optional
Eg:
Filter = "All files (*.*)|*.* | Project files (*.dpr)|*.dpr | Pascal units (*.pas)|*.pas'";

maybe this is covered in accept, but I didn't see it.

Some of these may have been covered, I really didn't see them.

- Thanks.

[MrBill]

Type = "state" - state list(s)

(with an additional country attribute that could have values like US/United States,Ca/Canada, etc & have all possibilities of State listings for each
country - pre populated !)

eg: (Case insensitive)
country="US|United States|USA"
country="CA|Canada"

also if Type = "state" may need something that'll allow the short list (CA,Co) long list (California,Colorado) or both (Ca - California, Co - Colorado)
maybe listtype="long|short|both"
- note since not all countries have states or provinces, this my not be viable.


Type = "countries" Country lists
a listing of all current countries
- note since countries change, this my not be viable. (add, leave, etc)