Develop Reference

define word boundaries for HTML5 spellcheck

I have some HTML in a contenteditable that looks like <span>hello wor</span><strong>ld</strong></span>. If I change it, so that world is misspelt, I would like to be able to get suggestions on this complete word. However, this is what actually happens:
The text is separated into two words, left clicking simply gives suggestions for one or the other.
Is there any recourse?

The implementation of “spelling checks” requested by using the spellcheck attribute (which the question is apparently about) is heavily browser-dependent, and the HTML5 spec intentionally leaves the issue open. Browsers may implement whatever checks they like, the way they like, and they do. You cannot change this in your code.
Although modern browsers generally have spelling checks of some kind at least for English, they differ in the treatment of cases like this, among other things. Firefox treats adjacent inline elements (with no whitespace between them) as constituting one word, but Chrome and IE do not. Moreover, browsers might not spellcheck initial content, only content as entered or edited by the user.
The only way to get consistent spelling checking is to implement it yourself: instead of using the spellcheck attribute (“HTML5 spellcheck”), you would need to have spelling checking routine and integrate it into your HTML document using JavaScript. People who have implemented such systems normally have the routine running server-side and make the HTML page communicate with it using Ajax.

How can create custom timeline for html5 audio player?

I'm trying to create own player for html5 audio by javascript.I've got the play,pause and volume option of htm5 audio player like:
<audio id="playe" src="song.ogg"></audio>
<div>
<button onclick="document.getElementById('playe').play()">Play</button>
<button onclick="document.getElementById('playe').pause()">Pause</button>
<button onclick="document.getElementById('playe').volume += 0.1">Vol+ </button>
<button onclick="document.getElementById('playe').volume -= 0.1">Vol- </button>
<button onclick="if(document.getElementById('playe').volume == 0){document.getElementById('playe').volume += 1.0;}else{document.getElementById('playe').volume = 0;}">Mute</button>
</div>
but how can I show the timeline there ? and is that the correct way for 'mute' option that I applied ?
-Thanks.

I assume you already know about the controls attribute and are choosing to create your own player? (View on JSFiddle)
If that's the case, read on...
How can I show the timeline?
I can think of two possible elements that would be ideal to use (on semantic grounds). The first would be the <input type="range"> element. View it here. You could target the element and set the values of the attributes using the currentTime and duration properties of the DOM element in Javascript.
The 5.1 specs say that this element comes 'with the caveat that the exact value is not important'. This probably isn't true for a video timeline, right? We definitely want our users to know the exact value. Nevertheless, that phrase in the specs give an explanation for why there's no ability to display the associated number of the element.
But we can, of course, display the time in a separate element, sort of like how Youtube doesn't display the time over the slider (unless you're hovering it). For this, we should use the output element. It's meant to be used 'for the result of a calculation', and, implicitly, the result of the calculation of another Html element. This is why it has the for attribute; it 'binds' it to the value of another element. In this case, we'd make the for our identifier of the range input.
For a little example of what I just wrote, I suggest you check out Chris Coyier's implementation of this idea. In summary, the Html he uses looks like:
<input type="range" name="foo">
<output for="foo" onforminput="value = foo.valueAsNumber;"></output>
and then he just styles the output with css to look nice. Nifty, huh?
Random note: It happens that the DOM element of the audio element is a child of the HTMLMediaElement, and over at the MDN you'll find a good list of all of the properties and methods of these things. This will surely be useful in building your own audio player. The HTMLAudioElement itself doesn't add much to its parent.
The problem with the range input is that it's an Html widget that most definitely utilizes the Shadow DOM, so styling it is pretty difficult right now (in fact, impossible in every browser except maybe Chrome).
If you really need to style the appearance of the range input, the most control you'll get is by using a Javascript widget that mimics the behavior. You know, throwing a bunch of Html elements together such that they look like a range input, and then wiring functionality into it with Js.
& if this thing is for personal use or a team using Chrome or Safari, you could make this a Web Component, which would be the best, and most future-proof way to go about this. But the Shadow DOM is still poorly supported.
Is that the correct way to mute?
HTMLMediaElements don't have a mute method, so, yes, you'll need to write a little bit of script like that to do it.
I'd probably change how your script works, though. I think users are used to the volume 'saving' when they mute, then returning to that value when they unmute. Right now, your script doesn't have this behavior. I'd definitely add that in!
Other thoughts...
Inline Javascript is generally frowned upon. Why not move everything into an external file, or at least a script tag, so that it's more manageable? You could even write a plugin to make it all modular and stuff.

Why does jQuery Mobile use data-role attributes instead of classes?

This may be a naive question, but I'm learning jQuery Mobile and unsure why everything is related to a data-role attribute. It seems that even times when the role is related to the style, they are using data-role over class
I understand that for semantics, data-role makes sense in a lot of cases but it just seems to be abused here. Wouldn't that kind of lookup also be slower?
Why do they use data-role over class?
Thanks for any insight.

Why data
They could simply use role as an attribute (like other frameworks do), but this would make
the resulting HTML invalid. Therefore a data- is added to every attribute name.
Why not classes
I think the main reason for that is to separate view from logic as far as it is possible. In larger projects, CSS and JavaScript are not written by the same person.

It provides a lot of control over powerful styling techniques especially when combined with jquery ui. I use jquery mobile, I used their tool to easily make a theme roller and now when I use elements like data-role-header, footer listview. I have great looking pages with no effort. There are hundreds of data-role attributes you can bring into your code to easily create uniform, user friendly pages. I personally like the data-role - page attribute to create multiple views in a single HTML page. They are easy to use so the best way to learn about them is to play with them.

Please find the explanation of data-roles here.
data-role attribute is used to control the behaviour of the widget of element. For example in case of button you can use input type="button" (no data-role="button" attribute required in this case, as this is standard behaviour of this element) but you can use a element, and then you need to explicitly provide it:
So for me it's rather useful solution, as buttons behavior on mobile devices can be same for different elements. You just need to provide data-role attribute, and jQuery will do the rest for you.
This is the quotation from main jQuery Mobile website:
jQuery mobile framework takes the "write less, do more" mantra to the
next level: Instead of writing unique apps for each mobile device or
OS, the jQuery mobile framework allows you to design a single
highly-branded web site or application that will work on all popular
smartphone, tablet, and desktop platforms.
They want to style every control you have in the same way, so write less, do more approach is fulfilled. So jQuery Mobile adds same styling for all elements with the same role to make things look the same way, but it doesn't mean you can't change it. It just means that they care about good look of your website, and they are aware that every button should be similar to others.
Also the page I mentioned earlier says:
The jQuery Mobile framework uses HTML5 data- attributes to allow for
markup-based initialization and configuration of widgets.
So you are reading HTML and you know how elements will behave without looking to CSS file - which I think is cool if you're not front-end dev. Of course front-end dev can overwrite CSS, but he must follow the rules, e.g. if data-inline is set to true he should style it regarding that elements must naturally follow this rule (be inline).

jQueryMobile adds a load event handler to the page, which processes the DOM looking for various data-xxx attributes. When it finds those, it does more than just stylize the elements.
In many cases it creates a type of widget tied to the data-role. For example, a <div data-role="header"> is turned into a toolbar widget, the creation of which may extensively modify the DOM within that element.
For some of the simpler widgets, like buttons, folks have seen that not much happens other than some classes get added, so why not just shortcut the process and do that directly? That can work, but it isn't future-proof. At different points in history, different versions of jQM had created buttons with different DOM structures. So I personally think it's best not to shortcut jQM, and let it process the data-attributes as it sees fit.
That being said, it would still have been possible to create widgets identified by classes rather than data-attributes, which was how people used to do these things before jQM. But then there might be an expectation that there would be CSS associated with those classes as well. Use of the data- attributes makes it clear that this is a structural/role thing rather than just styling.

Is it good practice (or a good idea) to leave out HREF on links that are hooked up via JavaScript?

Expanding on this question,
For items that trigger dialogs and menus (i.e. non navigational), is it good practice to leave out the HREF attribute in links that have events that are hooked up via JavaScript? In these cases, does it makes sense to have HREF there at all?
From this: some text
Or even worse, this: some text (which forces you to use event.preventDefault())
to this: <a>some text</a>

==Edited a little more==
Bad, bad idea. It wont show up as a link for one thing. If you need a button, but are use an <a> as one, just using a <button> or <input type="button">. As you said, "non-navigational". The entire point of <a> is navigational.
Out of those two tho, use href="#" putting javascript:// in a link is worse than adding inline styles.

Pragmatically - this is what I have learned over 16 years of JS
have the href, if not you need to set the cursor to hand or pointer
make the href go to a "sorry you need javascript" page if you do not want to use # or as I learned recently #somethingNotExisting
NEVER have href="javascript:anything()"
return false or preventDefault in the onclick which is preferably set in an onload handler
UPDATE: For menus and such, the agreed markup are lists with css and using links in such menus is recommended if the links actually loads content to gracefully degrade to plain html navigation if script is off

You should use the command element instead.
The command element represents a command that the user can invoke.
HTML5: Edition for Web Authors
This has the benefit of being semantically correct. There's at least one fork of html5shiv which 'enables' support for the element in older browsers.

Create your own HTML Textfield with Javascript

I came across the following http://ckeditor.com/demo , and was wondering if anyone had a basic tutorial how to implement this (or perhaps what key search terms I should use)?
Is this just a heavily modified TextField, or have they somehow managed to create a completely new TextField from scratch?
I tried googling this many times, and I always get pages relating to customizing the built-in TextField with CSS etc.

A good place to start if you want to learn how richtext web editors work is to look into the contenteditable attribute and the document.execCommand method (the best editors use a lot more than this, but these are at the foundation). Over-simplified, an editor consists of a contenteditable block and ways to invoke document.execCommand on the text selection.
But, speaking as a person who has actually developed an editor of this kind, you might be better off using an existing one (CKEditor being a great one, in my opinion).
Edit: Note that contenteditable is a proprietary (Microsoft) property, but most (all?) browsers have implemented it now, and it will be in HTML5.
Edit 2: I want to try to clear up a few misconceptions.
A div or iframe isn't in itself editable, it requires the contenteditable attribute. The use of an iframe is typically a workaround for the fact that older Gecko browsers only supported an alternative editable property (designMode) that could only be applied to a whole document.
While some operations of advanced editors probably do employ innerHtml, this isn't the key to making an editor on the web.

It is not a textbox. It is a DIV that has lots of HTML injected to it with javascript.
The basic idea is that JavaScript uses the innerHtml property of the div and writes HTML to it.

This is a javascript implementation that replaces a input. It basically hides the input and uses it for storing and passing the data via POST.

The advanced textfields I have seen have all been iframe or div. The code behind them is quiet messy and not very accessible.
Proceed with caution!

You may want to consider WYSIWYM instead of WYSIWYG.