Is there a way to localize input type="date" in HTML5 - forms

I know that at the time of this writing only Opera supports a browser UI for
<input type="date" name="mydate">
and maybe my attempts to localize this field have been met with frustration because niceties like localization have not yet been included in their implementation, but I don't even see mention of it in the HTML5 spec. Is there a way that localization should be specified? Should I do lang="fr" on a parent element?
Some notes on the implementation of the site in question:
Localization (language) is explicitly picked by the user because they are managing data in multiple languages and it is not reasonable to expect that the user's browser chrome is in the language being viewed or that the browser is providing desired language request headers.
I want to be sure that if the page is rendered in French that the date picker provided by browser chrome shows options that make sense for French language.
The plan is to fall back to jQueryUI for browsers that do not support type="date", I will use the detection mechanism provided in Dive into HTML 5

From what i know, the thinking behind what we do in Opera (full disclosure: I work for them) is that the date picker is almost an extension of the chrome, a browser-native control. As such, it will be localised according to the language of the browser, rather than the language of the page being viewed.

I agree with lambacck. Currently I am writing Javascript code to make the new form features available cross browser, using jQuery UI for this.
I work in Luxemburg which is a good place to illustrate the localization problem in more detail.
Most websites we write are multilingual de|fr|en. From our stats we can tell, that people use the language switch on the site to display their preferred language, but this choice rarely matches the preferred browser locale.
If the locale of the calendar etc. field is done by the OS, this brings us back to the unfortunate <input type=file> situation where the label reads Upload a file and the button says Parcourir. You can do nothing about this language mix and I always found this to be a major annoyance.
Conclusion, I have to overwrite the default calendar with the jQuery one to be sure it does what I want.
In my opinion a configurable API or at least a way to manipulate the locale on a HTML level would be great. Since the new field types are not widely adopted yet by the other browser manufacturers, I imagine this issue could still be taken in account.
Thanks for reading this.

For mobile the best solution we have found is to use a text input for date entry, with a calendar icon next to it that has an invisible date input over the icon.
Advantages:
works on all browsers and devices
can use next button into date on iOS (if multiple fields)
user can type in date (very useful)
avoids iOS UI bugs (1. editing existing data with blank date, next into date, date value is set to today - arrrgh, 2. keyboard showing, next into date, popup shows and keyboard disappears - ouch)
use a date library to show date in input as localisation set for your user's account (not browser), and can use a smart date library (type in "tomorrow" etc).
click calendar icon to see date as browser localisation
graceful fallback even if input type=date not supported by device/browser (e.g. some Android devices don't support date or have serious bugs).
for desktop (detected by no touch support) we show our own custom date dropdown.
HTML is a something like:
<input type=text>
<span style=position:relative>
<input type=date class=date-input tabIndex=-1>
<div class=date-input-icon>▼</div>
</span>
CSS:
.date-input {
position: relative;
z-index: 1;
webkit-appearance: none;
display: inline-block;
opacity: 0;
width: 1em;
}
.date-input-icon {
position: absolute;
right: 0;
width: 1em;
}

Related

Hiding plain text in email readers: is <--! better than <div dislay:none or is there a better way?

I am trying to include, in email, a simple text alternative for non html email readers.
I can not use MIME (service I am using doesn't support it, only HTML only or Text only).
I figure most people (95%) have simple html support, so I'll avoid css.
But for the text-only folks I want to include a text-only version.
I have tried hiding it with
<div class="TEXT ONLY" style="width:0; overflow:hidden;float:left; display:none">
<--! text here -->
And wrapping the second around the first.
That works in Gmail and in Yahoo, outlook ,etc ](per testing here)(http://info.contactology.com/email-view) and testing in my own gmail account and an ancient 10 year old Goldmine client).
But I'm looking for problems with the above or a better solution. Maybe just using the second option '<--!' (since, if it is displayed it's fewer confusing HTML tags for the user to ignore)
Both of them will make the text invisible,
But,
<div class="TEXT ONLY" style="width:0; overflow:hidden;float:left; display:none">
will be accessible via the DOM.
where as,
<--! text here -->
will not be accessible via the DOM.
So ultimately the choice is yours, depending on your requirements. If just hiding the element is your only concern then I would rather prefer the <--! text here -->. This can hide anything including entire html contents too (unless it includes -->), where as, the DIV way may cause problems with the DOM in certain cases.
You can use the following technique that I employ to emulate "email preview text". Quick background (in case you're interested): Most email clients grab alt text and link text to generate preview text, but my company includes multiple images and a "click to view in browser" link before any informative content, so the generated preview text is garbage.
I add the following code right after the opening body tag:
<!--email preview text-->
<div style="display:none;font-size:1px;line-height:1px;max-height:0;max-width:0;opacity:0;overflow:hidden;">
Here is my preview text. You should have roughly 90 characters and include a call-to-action. Read on to find out more.
</div><!--/email preview text-->
Adapted from Litmus.com.

iphone input type (number with two decimals)

I'm developing an iphone application with phonegap, this means my application is in html5, javascript and css. I have a form with a field for weight on an object. I'm trying to get an input type similar to;
<input type="time"/>
Html5 supports different types of input, and this will toggle a different keyboard for the iphone, for example the numeric keyboard for numbers. The one I'm looking for is the one where you can roll vertically over numbers. Like when you set your alarm clock on the iphone, example below.
http://blog.ringtonefeeder.com/wp-content/uploads/2009/01/iphone-alarm.png
The input type="time" gives me that, but it's restricted to 24 hour window and 1-59 minute window.
Is there anyway to customize this input type so I can get a 2 decimal number? in the range of 0-999.99 kg.
I realize this is a vague question but it's hard to explain.
Have a look at inputmode="decimal" attribute.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode
Not widely supported yet but it comes available in iOS 12.2.
https://caniuse.com/#feat=input-inputmode
As far as I know, there's no way of doing this in the PhoneGap world. You can view the available keyboards here. You could probably roll your own if you're capable in objective-C, but then you'd have a create a plug-in for it so PhoneGap could see it.
One of the keyboards not shown on that page is: UIKeyboardTypeDecimalPad, which is a telephone keypad with just numerals and a decimal point, which might also work for your application. Shown here:
However, I've been unable to figure out how to have it shown via HTML.
If you want the telephone keypad, you'd use:
<input type="tel">
Similarly if you wanted a numeric keypad, it'd be:
<input type="number">
As far as I know (and someone please correct me if I'm wrong), there's no equivalent for UIKeyboardTypeDecimalPad like this made up type:
<input type="decimalNumber">

How to work around visualeditor not working on iphone

Visual editors such as kupu and tinymce don't allow you to type when used on an iphone. In Plone HTML view still works but the user will have to know html syntax. Is there any better work around?
Problem here is that most modern mobile phones (with a few exceptions) do support web browsing with a limited functionality only. Functionality that is necessary in order to use kupu and tinymce. Plone HTML is a good approach. You might have a very simplified html element description on that page or linked with the very few elements a user needs.
Plone supports plain text and restructured text (same as Sphinx docs) in rich text input also.
This is enabled for the default Page content type, though the option has been hidden in the latest Plone versions I think.
What you would need to do is to write a plug-in which monkey-patches rich text field to force the input to to be plain text/restructured text on mobile browsers.
Web and Mobile provides some facilities for this, to see whether a HTTP request is from a mobile user agent (mobile.sniffer package)
http://webandmobile.mfabrik.com/
I'm attempting to do the same thing on my DroidX with Plone 4.0.5. I've tried the default Browser, Dolphin, Opera Mini, Opera Mobile, Firefox 4, and Firefox 5. So far Rich Text fields do not work in the default Browser, Dolphin, Opera Mini, Opera Mobile. I got close in Firefox 4 and 5 as I could enter text but just not "see" it properly. However, Firefox 4 and 5 are buggy and locked up when I attempted to use them.
The way I got around this problem was to turn off javascript in your mobile browser and then when you edit your content use either Plain Text, Markdown, or type in the raw HTML into the place where the Rich Text field is supposed to be. I could successfully enter text this way in the default Android Browser and Dolphin.

Native looking HTML selector with Android/iPhone Webkit?

Looking at Google Calendar on my android web browser I noticed the time selector looks like a native Android selector as opposed to looking like an HTML selector drop-down. To see it:
go to http://calendar.google.com/
Touch the plus button at the top right
Touch the time drop-down
You should see the native-looking selector.
What HTML incantation are they using to get that look?
Are there other android specific or HTML5 specific tags to get native (or improved) look on Android/iPhone webkit (and WebView)?
I am not as familiar with Android, but I do know that there are a number of special CSS attributes that one can use with WebKit on the iPhone. Essentially they are any CSS attribute beginning with -webkit, which indicates that they are CSS attributes which have not yet been standardized. It is a normal part of the standards process, where potential standard tags and attributes must be implemented in a "test case" to show how they would work. There are a number of sites that have a full list of the -webkit attributes. I like this one the best. Many of these attributes provide more advanced layout capabilities, which can help items look more "native."
The time selector is a regular <select> tag on the iPhone version.
The date selector is a completely custom calendar picker that Google has created from scratch.

How to put the Amazon Kindle Web Browser into Article Mode

How do you put the Amazon Kindle web browser into Article Mode via HTML or Javascript?
Editor's note: Some pages are not automatically detected as "articles" by the Kindle 3 browser, and give an error message when trying to go into Article mode. What does the Article mode use to determine what portion of the page to display?
Is this related at all to Readability?
http://lifehacker.com/5163401/readability-bookmarklet-quick+formats-pages-for-smoother-text
Actual JavaScript code for Readability, which is heuristic based:
// Study all the paragraphs and find the chunk that has the most <p>'s and keep it:
This also appears to be related to Safari 5's Reader mode. Here is what is required for Safari Reader:
This definitely needs more investigating, but so far, these appear to be the most important factors for Safari’s Reader functionality to kick in:
Use the right markup, i.e. make sure the most important content is wrapped inside a container element. Whether you use <article>, <div> or even <span> doesn’t seem to matter — as long as it’s not <p>.
The content needs to be long enough. Use enough words, use enough paragraphs, use enough punctuation. Every paragraph should have at least 100 characters.
Reader doesn’t work for local documents.
http://www.wired.com/gadgetlab/2010/09/simple-tip-turns-kindle-into-ultimate-news-reader/ - The "f" key feature outlined above or some other feature? Not quite sure what article mode means.
It means that the browser will try to identify if the page you are looking at has a main body of text (is an article), parse it out and then display only that text without clutter and for easy scrolling.
I don't think you can force it via the web page's code
As far as I know, once the website has loaded (and if you are on an specific topic) you can turn on the "Article Mode" from the menu.
I've seen similar JS tools for Chrome too, so I assume it's part of webkit.