WHATWG Weekly: translate attribute and other changes to HTML
Since the last WHATWG Weekly, almost a month ago now, over a hundred changes have been committed to the HTML standard. This is the WHATWG Weekly and it will cover those changes so you don’t have to. Also, remember kids, that fancy email regular expression is non-normative.
translate attribute
To aid translators and automated translation HTML sports a translate since revision 6971. By default everything can be translated. You can override that by setting the translate attribute to the "no" value. This can be used for names, computer code, expressions that only make sense in a given language, etc.
Selector and CSS related changes
In revision 6888 the :valid and :invalid pseudo-classes were made applicable to the form element. This way you can determine whether all controls in a given form are correctly filled in.
Revision 6898 made the wbr element less magical. Well, it defined the element fully in terms of CSS rather than using prose.
A new CSS feature was introduced in revision 6935. The @global at-rule allows for selectors to “escape” scoped stylesheets as it were, by letting them apply to the whole document. It will likely be moved out of HTML and into a CSS once a suitable location has been found.
APIs; teehee!
It turns out that clearTimeout() and clearInterval() can be used interchangeably. Revision 6949 makes sure that new implementors make it work that way too.
Per a request from Adrian Bateman revision 6957 added a fourth argument to the window.onerror callback, providing scripts with the script error column position.
Speaking of scripts, in revision 6964 script elements gained two new events. beforescriptexecute which is dispatched before the script executes and can be cancelled to prevent execution altogether. And afterscriptexecute for when script execution has completed.
Revision 6966 implemented a change that allows browsers to not execute alert(), showModalDialog(), and friends during pagehide, beforeunload, and unload events. This can improve the end user experience.
I think it is dangerous to suggest that a content author would have sufficient knowledge to determine whether it is possible to translate a particular phrase into another language; this differs from specifically asserting that something should not be translated, as with a name or computer code. (That is, there should be a distinction between CAN and SHOULD with regard to the author’s intent when using the ‘translate’ attribute.)
If a translator chose to take the ‘translate’ attribute into account, it might be forced to provide a degraded experience for a user simply because the content author thought that their language was special. Ideally, a translator would be able to take an idiomatic expression in the source language and translate it to an appropriate idiomatic expression in the target language. Thus, the ‘translate’ attribute should be used only for content that the author think SHOULD NOT be translated; it should not be used for content that the author thinks CANNOT be translated (because they are quite likely to be wrong).
@Gordon: My understanding of this attribute is that it could be used for something like proper names, blocks of code, etc. that would under no circumstances ever be translated.
@Chad I agree with you that that is what the intent is behind the wording of the spec. I was responding to Anne’s suggestion in this blog post that it be used for “expressions that only make sense in a given language”. I don’t believe that this claim is supported by the spec, nor do I believe it should be.