[whatwg] Pattern Hint

[Matthew Raymond]

Ian Hickson wrote:
> On Sat, 8 Oct 2005, Matthew Raymond wrote:
>>My argument isn't that |title| can't contain pattern hints. What I 
>>object to is designing HTML5 so that |title| is the only thing that can 
>>be used for pattern hints on legacy browsers.
> 
> I don't understand why you think it is the only thing that can be used for 
> pattern hints (on any browser, legacy or otherwise).

   Take your demo for example. Suppose you want both pattern hints and
tooltips in the legacy code. In that case, you'd want the code to
degrade to something like this for an HTML 4.01 user agent:

| <input id="t1" name="t1" title="Enter the first date here.">
| format: DD/MM/YYYY HH:MM

   In this type of case, if you use Javascript to solve the fallback
issues you run into two problems. The first is obvious: What's the
fallback when the user agent either doesn't support scripting or has it
disabled? The other situation is related, but less obvious. If the
control-related data isn't in the DOM by default, you have to manage the
data in Javascript for an indefinite number of controls, each one
potentially having unique pattern hints and tooltips. Content is shifted
from semantic markup to behavioral scripting, with the result being
degraded fallback and more complicated scripting.

   Now, let's see how <altinput> handles this case:

| <altinput for="t1" type="datetime">
|   <input id="t1" name="t1" required="required"
|   title="Enter the first date here.">
|   format: DD/MM/YYYY HH:MM
| </altinput>

   What happens here is that <altinput> attempts to replace the |type|
of <input id="t1"> with its own |type|. If the |type| is not supported
by the user agent, <altinput> essentially becomes a <span>. However, if
|type| is supported, <input id="t1"> is converted to the new type and
within the <altinput> only <input id="t1"> is rendered. Thus, the legacy
browsers experience the ideal degraded content mentioned above, while
HTML5 browsers would experience this:

| <input type="datetime" id="t1" name="t1" required="required"
| title="Enter the first date here.">

   Notice that the content inside <altinput> is identical to our HTML
4.01 fallback with the exception of the |required| attribute, which I
only added in case |type="datetime"| isn't supported but |required| is.

   Here's a bare-bones credit card scenario:

| <altinput for="cc1" type="creditcard" required="required">
|   <input type="hidden" id="cc1" name="cc1">
|   <p><label>
|     Card Type:
|     <select name="cc1_type">
|       <option>Visa</option>
|       <option>Mastercard</option>
|       <option>Discover</option>
|     </select>
|   </p>
|   <p>
|     Card Number:
|     <input type="number" name="cc1_1"> -
|     <input type="number" name="cc1_2"> -
|     <input type="number" name="cc1_3"> -
|     <input type="number" name="cc1_4">
|   </p>
|   <p>
|     Expiration:
|     <select name="cc1_exp_month">[...]</select> /
|     <select name="cc1_exp_year">[...]</select>
|   </p>
| </altinput>

   Notice a problem, though. In the above, you don't want the label for
the hidden control to render, but you do want it to render if it's
successfully changed to the "creditcard" type. So you end up in a
situation where <altinput> needs a |label| attribute or similar when the
associated control is of type "hidden". (Thought: Put |label| attributes
on <input> elements that are hidden when the |type| is "hidden"?)

   Not sure how I want to solve this problem. What's clear, though, is
that XBL2 doesn't really solve the problem, even if you assume all HTML5
browsers support it. Even if you could us XBL2 replace the parent
element containing the fallback content with a simple bit of WF2 markup,
you'd have to know that the user agent fully supports the replacement
markup.

   /me shrugs.

   This whole thing is a mess. Our inability to trust user agents to
implement the markup correctly means that proper fallback is practically
impossible.