HTML 5 and CSS 3 Support In Dreamweaver CS5

Question

I cannot find any information on this web site about whether and how Dreamweaver CS5 supports HTML 5 and CSS 3. There are lots of other fancy high-end whiz-bang technologies highlighted in CS5, but without support for HTML 5 and CSS 3, Adobe has left a great big hole in the middle of the new Dreamweaver. If I'm going to have to code these by hand, then there's little incentive for me to upgrade from CS4. Adobe may, by this oversight, intend to extend the useful life of Flash, but if this is so it's penny wise and pound foolish. There is much to like about Flash - and much to dislike about how it works on the user side. Leaving these problems unresolved hurts Flash, and leaving HTML 5 and CSS 3 support out of Dreamweaver hurts Dreamweaver. In other words, this is a lose-lose strategy.

Answer 1

Hi Scott
Sorry for the delay in replying, but I turn my internet connection off when working, otherwise I have found I tend to do more research than work.
Media-Queries:
I had viewed the video on the possible implementation of media-queries when it was first released, and in most respects the implementation is as I would expect, but it would be helpful if it was, (in a future development of the use) possible to show a list of 'common' smartphone/handheld devices, (makes/models) within the dreamweaver interface that would be usable with the screen size being used, (possibly as an import from the 'device central' device list as a drop-down list). My reason for asking for this feature is primarily as a time saving feature for the css layouts via media-queries as it would then show the targeted/usable devices in a list, and possibly alleviate the requirement of developing layouts that are not really required.
Video:
At the moment I am using the video feature as you have indicated where possible, and am doing so with the use of IECC's for IE as a fall-back for that browser. I have tried targeting versions if Firefox and Safari that support the video element by testing for it with JavaScript, but I have found this unreliable, possibly when the standard is finalized this may be the better method.
SVG:
I personally have decided to go with svg in preference to canvas. I have seen a few 'wow' factor demo's produced using canvas but as they use cross-compiled java to javascript code they are in reality showing nothing that has not been done before, (If we had 4Ghz processors with multi-core in 1999 similar trial graphics in vml would have worked just as good then, showing my age here!).
My current work-flow with svg is - Inkscape - Modify the code by hand/preview in a browser - copy/past the code into dreamweaver.
The current in-line implementation of svg's in the IE9 preview is where I see the main future of the svg implementations, as this makes using svg's for graphic elements and basic animations much more viable/easier for the average designer/developer, and lets not forget that as it is a vector it is ideal for resizeable background images in fluid/liquid layouts.
I should say here, that I will for the foreseeable future use flash/swf's for more complex animations, as these are still much better quality than anything that can be achieved with svg or canvas.
I would like to see the possibility of using Fireworks for the creation of svg's, and a work flow similar to that available between fireworks and dreamweaver at the moment.
Cache manifest and database:
As you have rightly grouped these two together, (and I cannot really envision a situation that they would not be used so) the situation with these is for me, (when trying to create the code for use) the necessity of 'remembering' what I must include in the cache and the transfer of the data for the database.
Both are probably better explained with a typical scenario -
A new research/development firm has developed the technology and parts to upgrade an autos internal combustion engine to an hydrogen powered engine. However the products list is specific to the motor manufacturers engine type, and to make matters worse the sales department also wishes an off-line version of the demos and parts list to be available to its sales team and customers, (o/k, maybe this is not a typical scenario, but it does demonstrate the usage).
When developing the 'custom' html 5' enabled page I would require the cache manifest to include all necessary javascript/images/videos that would be required for the particular auto manufacturer to be available off-line, and compiling the list must be done at present by hand making it subject to possible errors.
As for the database, (manufacturer specific) this must also be available off-line and updateable by the sales person and customer, as they are not always on-line and no hard-copys of material will be produced, (except when printed by the mechanic).
My solution for me regarding the cache manifest would possibly be a dialogue in dreamweaver that would show all resources associated with the auto manufacturers model type used in the html site. I have used namespaces, (or some form of identifier) for general and model specific javascript, and a model identifying code for images and videos. The dialogue would then allow me to filter the resources required using the namespaces and identifier and include them in the list as required, possibly in much the same way that items are moved from a general list to a more specific list when creating the 'favourites' toolbar in dreamweaver.
The database is on first appearance much simpler, as I would simply download the database using the motor_id as a filter, (yes Scott, you can see where I am going with this ) for those who cannot this would be wrong. You have correctly seen the problem with doing this, but I will explain for those who have not. The sales person and the customer would not see any of the images or videos that have references stored in the database, as these are just references and not the actual images/videos, yes one could use 'BLOB' for storing the items but this is not in my experience a reliable method. What is required is some form of method that would also download these items and place them into the required file position for off-line viewing, (which is what the cache manifest would do).
So I would also require the possibility to add dynamically to the cache manifest from an sql database at the same time as the 'save for off-line' option is generated, (I have experimented with doing this in a similar manner that xml is created from an sql database).
That's it for the html 5.
Accessibility:
For checking I use the firefox accessibility extension and total validator extension first, then the WAVE evaluation tool.
But for Dreamweaver I would like to see the inclusion of the ARIA options as standard, especially when developing 'rich-internet-applications' particularly the aria-live and role options. I often find it interesting in discussions about html 5 where it is seen by many as a 'new' mark-up' language for the web, but rarely seen in the context of helping in accessibility when used correctly. Even the html 5 spec contains a section on using the new mark-up as part of accessibility and how the ARIA roles should be applied, (see - http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#annotation s-for-assistive-technology-products-%28aria%29).
The inclusion of an extra live-view option in dreamweaver that render the page in 'screen reader' mode would also be a possible accessibility checking help. This could be done by simply turning off the background-images 'on-mass' and rendering any items as they would be seen by a screen reader. As most screen readers do now parse JavaScript and css, it would illustrate the problems of using such techniques as light-boxes without using the aria-live role to tell users that the light-box in now the focus of the page.
For anyone who has stayed with this post, my sincere thanks, and any comments on the content would be welcome.
Paula Z