I think I'll go through the tickets I've commented on so far and update them with "this can be implemented by users given a first-class scripting language like Lua".  Hint: this is one of the ones that can be implemented by users given a first-class scripting language like Lua.  ;)

Ah, but try ⌘{ and ⌘} in Safari anyway.  ;)  While the menu says one thing, for interoperability reasons (Xcode, Terminal, various other tabbed applications *coughfinderonmaverickscough*) Safari allows a variety of shortcuts to be used.  Even ⌘⌥⇧← and ⌘⌥⇧→ work.  Yes, the latter pair is kinda nuts.

Edited to add: because of the consistency across the applications I use for both development and outside of work I've muscle-memory trained ⌘{ and ⌘} -- it simply works everywhere.  Adium has a drop-down allowing you to select which pair of shortcuts to use for tabbed navigation, including now all of the above mentioned styles.  Note that ⌘{ and ⌘} is the only combination that works in Terminal.app without painful global remapping in System Preferences.

There are only two things Ack does not do well: searching of very large files (hundreds of megabytes+) and multi-line regexen.  However both of these are highly specialized tasks with a far lower occurrence count than standard searches, both non-regexen and regexen.

Ack has many benefits over pure grep for programmers:

• Intelligent file selection: only searches known text files by default.  (And if you need it to search more you can either add to the known types or have it search all.)  Also ignores known bad files such as backup files, core dumps, and version control files (i.e. the contents of .svn or .git).
  
  
• It naturally gives a configurable amount of context and provides other customizable settings, making machine parsing and formatting for GUI selection of the found lines quite easy.
  
  
• Standard GUI search options exposed as simple switches.  (ignore-case, smart-case where if search terms are lowercase search is insensitive, filename sort, whole-word, etc.)
  
  
• Configurable by advanced users through the ~/.ackrc file, i.e. to add additional types.

Standard grep can be a fallback if the regular expression contains explicit multiline matching.

Due to sandboxing requirements, you can override the ACKRC environment variable to point at an ackrc file within your application bundle, or the Application Support folder for the application.

I'll give a slightly better answer with links to how you can actually solve it.  ;P

http://www.textasticapp.com/v4/manual/lessons/How_can_I_add_my_own_syntax_definitions__themes_and_templates.html

https://github.com/mrmartineau/HTML5

https://github.com/lenn4rd/CSS3-TextMate-Bundle

Works on the desktop version, too:

http://www.textasticapp.com/mac/manual/lessons/How_can_I_add_my_own_syntax_definitions__themes_and_templates.html

You can add HTML5 and CSS3 support yourself.  [Puede agregar HTML5 y CSS3 mantenerse.]

http://www.textasticapp.com/v4/manual/lessons/How_can_I_add_my_own_syntax_definitions__themes_and_templates.html

https://github.com/mrmartineau/HTML5

https://github.com/lenn4rd/CSS3-TextMate-Bundle

(Updated to link to correct manual entry.)

Textastic supports syntax definitions from standard TextMate bundles, thus it already "supports" HTML5 and CSS3.

Ack.  Integrate ack searches.  It's great, fast, efficient (only searches code and text files, naturally avoids binary ones) and provides easily parseable results for GUI consumption.

One of the most useful forms of completion I've found in other editors, excluding actual full code insight, is the nearest-startswith match.  Type three letters, hit escape, and it'll auto-complete the nearest word that starts with those three letters.  Keep hitting escape to cycle ever further out from the cursor.

Also showing non-printable characters would be useful.  Things like the pagebreak character, bell, escape, etc.

Being able to use either would be awesome.  (Or have it configurable.)