Skip navigation
Currently Being Moderated

HTML 5 and CSS 3 Support In Dreamweaver CS5

May 4, 2010 5:39 PM

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.

 
Replies 1 2 Previous Next
  • Currently Being Moderated
    May 4, 2010 7:20 PM   in reply to thewhitedog

    You can make HTML5 documents and CSS3 files in Dreamweaver.  Neither one is a final specification so if new features are added along the way you will have to hand code them for the time being.  Also if you want to criticize CSS3 support, the only browser that does not support CSS3 is Internet Explorer.  Also Internet Explorer does not fully support HTML5.  Although both are in the specification for IE9.

     

    Additionally Adobe removed support for .NET development as of CS4 because Microsoft chose not to share its proprietary information with Adobe.  Thus instead of lagging behind the curve Adobe dropped support for .NET.  Would you make the same argument with .NET vs PHP?  Is Microsoft trying to extend the useful life of .NET?  There is much to like about Windows - and much to dislike about how it works on the user side.  And with more people switching to Mac's and no native software in the Mac environment hurts Windows.  It's a lose-lose strategy.

     

    But hey, without competition who would buy anything and who would innovate at all.  Competition helps everyone.  Draft specifications and endless betas help no one.

     

    If the upgrade is not worth it for you don't upgrade.  Adobe only requires you upgrade once every 3 versions and with a release once every 18-24 months that means you only need to upgrade once every 54-72 months.  If you want to see features in future Adobe products, there's a form for that: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform .

     
    |
    Mark as:
  • Currently Being Moderated
    May 5, 2010 6:03 AM   in reply to thewhitedog

    Hi

     

    You can get the extensions for css3 and html 5 at the following -

    css3 - http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail& extid=1986525.

    html 5, see this thread - http://forums.adobe.com/thread/607931?tstart=0.

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    May 5, 2010 4:45 PM   in reply to thewhitedog

    You're putting the cart way before the horse here.

     

    1) HTML 5 web specifications are not yet finalized.

    http://www.w3.org/TR/html5/

     

    2) Browser support for HTML5 and CSS level 3 properties are still spotty at best.

     

    The new web standards probably won't be viable for another 12-18 months.

     

    Nancy O.
    Alt-Web Design & Publishing
    Web | Graphics | Print | Media  Specialists
    http://alt-web.com/
    http://twitter.com/altweb
    http://alt-web.blogspot.com

     
    |
    Mark as:
  • Currently Being Moderated
    May 6, 2010 6:28 AM   in reply to thewhitedog

    Hi Thewhitedog

     

    I have to agree with you about adobes strategy regarding dreamweaver and the future of the web. But my complaint with them would go a little further, in that they now give the impression that one must either use an 'open source' CMS system, a third party or adobe (paid for) system, or flash, and this is where they appear to be concentrating their efforts.

     

    Admittedly the new php features are helpful and make working with dreamweaver in this respect much easier, but dreamweaver still remains an 'also ran' product as far as adobe is concerned, (as I see it ).

     

    Adding upcoming feature to dreamweaver is for me a must, if they are not incorporated, (even if the spec is not complete) then how do people learn to use them, this not only applies to html 5 and css3, but to things like svg, php:pdo, cross database behaviours, etc. The argument that the specs are incomplete does not 'hold water' as the css 2.1 specs where only finalised in 2007, years after people started using them and they where incorporated into dreamweaver, (most of css 2.1 was available in dreamweaver MX2004).

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    May 6, 2010 9:49 AM   in reply to thewhitedog

    Dw CS4/CS5 do support CSS3 and HTML5.

     

    But, as it's not yet a standard, It support some parts of CSS3/HTML5 in DW's Live View. There's a lot of hype about HTML 5 (Apple ...) but it's mostly about a very, very small subset of the spec (audio, video, canvas) that have stolen much of the public attention, but as their functional issues get worked out (which codecs will be supported long-term, whether IE will ever support native canvas, etc) I’m sure Adobe will continue to push forward with more dedicated authoring. But there's nothing stopping you from writing HTML5 content in DW today, or going forward. I did it on a new website I’ll be launching very soon.

     

    You can also take a look at that blog if you want to follow the evolution of Adobe tools and HTML 5.

     

    --

    Martin

     
    |
    Mark as:
  • Currently Being Moderated
    May 6, 2010 10:26 AM   in reply to thewhitedog

    Hi,

    What features would you expect to see with HTML5/CSS3 support?

    Thanks,

    Donald Booth

    Dreamweaver Quality Engineering

     
    |
    Mark as:
  • Currently Being Moderated
    May 6, 2010 12:19 PM   in reply to Martyn_C

    Re: wider intentions, this should make things reasonably clear:

    http://tcrn.ch/9zfTyW

     

    To think we aren't very excited about HTML 5 is patently false.  We absolutely are, but we also base our excitement and the promise of HTML 5 (and CSS 3) in reality.  HTML 5 represents a lot of functional areas - interactivity, graphics, networking, local/offline application support, layout and design, et al.  Which are most important to you?  And when?  Support for HTML 5 isn't a single thing you 'turn on', but a lot of small things that will undoubtedly build up and become consistent over time.   We'll follow a similar path with DW, and keep a careful eye on both browser adoption/standardization as well as actual functional needs and build out richer support over time.  You can certainly expect to see and hear more on this very shortly in regards to Dreamweaver CS5, too.

     

    @Martin- excellent points, and pointer to the Design and Web blog.  Keep an eye on that if you want to see peeks into R&D around emerging standards currently underway (caveat- any/all of these may change significantly before ending up in a DW release, if at all).

     

    Right now, alas, there's a lot of fragmentation around the key (or at least more controversial) areas of HTML 5 - canvas (not natively supported by IE 9), audio/video (differing codec support between vendors, licensing concerns), et al.  You can bet we've got ideas about each, and in some cases are both in progress working around them as well as seeing how certain open issues will resolve short-term. 

     

    But reading through this thread and thinking about the larger issues, Don Booth's response (and larger question) sums up what - IMHO - this conversation SHOULD be about, independently of the overblown media hype that HTML 5 is enduring today:  what does the term 'HTML 5 Support' really mean to YOU as a designer or developer?  What gives it meaning to your clients, and what new types of projects will they ask you for that require it?  These are the questions we've been digging into, and will continue to dig into.  It's easy to get caught up in the blanket hype around HTML 5 right now while simultaneously realizing it's potential, but when you rip into what these new standards actually mean to you and your clients, what types of projects and tasks will be made either easier for you to develop or richer for your end-users, and what areas of the HTML 5 (and CSS 3) spec(s) are most critical today (and in the future), there are probably a handful of specific, immediate problems we really need to solve.  It's a bit ironic that the first poster in this thread feels that better general support for PHP based apps & lightweight CMSes, simplified project/site setup and inline visualization of CSS in CS5 are 'high-end, whiz-bang' features - they're actually very fundamental updates that represent the bulk of customer requests and feedback over the last 2 years, and HTML 5 - despite being an amazing collection of technology, and a standard we intend to get behind in a big way - is largely the topic of scrutiny right now due to media hype.  As we move forward into supporting HTML 5 both short and long-term, what would be incredibly helpful is if we could instead focus on what areas of the HTML 5 (and CSS 3, or even SVG) spec(s) you feel will be most crucial to you and your clients, why, and how you'd ideally like to work with them.  Cause that's where our attention is going to be focused, and at least speaking for myself, we're hoping you'll be along for the ride with us as HTML 5 picks up steam.

     

    - Scott, Adobe Systems

     
    |
    Mark as:
  • Currently Being Moderated
    May 6, 2010 5:58 PM   in reply to thewhitedog

    This thread might be helpful.

    http://forums.adobe.com/thread/633442?tstart=0


    -- Sag-e-Attar Junaid Atari

     
    |
    Mark as:
  • Currently Being Moderated
    May 6, 2010 6:39 PM   in reply to thewhitedog

    White,

     

    I think you are misinterpreting what I said  before and what Scott is saying now.  They are not dismissing HTML5 for  the features where it competes with Flash.  Much the same why they support PHP and dropped the .NET support.  As Scott was saying, if you know what part of HTML5 you need implemented first, they will start looking into that.  But with an incomplete specification it would be difficult to tackle HTML5 and CSS3 with a broad sword and hope you hit enough of what users want.  If you do that you can limit the capabilities of the program whereas if there are features of HTML5/CSS3 that have more in depth details they can implement one object that is great instead of tons of objects that are just average.

     

    I do agree with you that the Web blog is fairly new and underdeveloped compared to other blogs that have been around much longer like John Nack blog (a good article reminiscing about LiveMotion - http://blogs.adobe.com/jnack/2010/05/my_decade_at_adobe.html - Adobe's original answer to Flash, which really had a better timeline then anything I've seen in Flash thus far).  But if it is maintained by their team, then it could be a great asset for them.

     

    As much of a fan of Apple as I am having owned Apple laptops and iPods for the last decade, despite not owning an iPhone (because of AT&T), you have to admit they are masters of manipulation and can make anything seem "cool".  This is what they have done with HTML5.  They have turned it into the cool thing of the moment.  In many cases for Apple this works, for others it doesn't.  For instance, they are heavily into Blu-Ray, but they will be damned to pay the licensing to put a Blu-Ray drive in their computers.  So is Blu-Ray the way to go for Adobe Premiere, or should they just forget about it and move to digital distribution?  Do you see the point of the question?  It's not to answer, but to make you think about why they make the decisions they do.  Honestly I have a Droid and I would like to see them release an open Flash beta test for Android devices.  And I have the Flash Gala release running on my Macbook Pro right now and Flash has never been smoother.  Not a single crash in Firefox or Safari (64-bit).

     

    One item I notice from your post that I think the Dreamweaver team, and other Adobe teams in general can look into is making users more aware of what is going on.  Unless users know about the Labs and go to the link directly, there really is not much on the product pages themselves to let users know about upcoming technologies.  Especially in the case of the web which is changing everyday, links directly to the labs to let users know a little more about what is being developed.  Obviously you have to take them through the labs anyway because of the high priced lawyers all company's have to write disclaimers about how the product is for testing, Adobe is not responsible, etc, etc, etc.

     

    Also for reference the HTML5 specification was last updated on May 6, 2010: http://dev.w3.org/html5/spec/Overview.html .  If there are features you are using or are planning on using say something.  Give an example of a feature in HTML5/CSS3 that DW does not fully support as you would expect it to.  For instance here would be a specific issue I would have with Dreamweaver. If you asked me what the worst feature was in Dreamweaver I would have said the validator which was removed in CS5.  However, instead of removing it completely I would have rather seen some element that would take my code and put it into the W3 site as if it were done via direct input without having to upload it.  Maybe an AIR Application could accomplish this.  Same thing would go for the CSS validator.

     

    So in the end I don't think they are being reluctant they are just looking for a direction to be pointed in while the specifications are being finalized.  Just give them some specifics and see what happens.  What do you really have to lose?

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 5:51 AM   in reply to thewhitedog

    This is from Macworld Dreamweaver CS5 review.

     

    Although neither HTML 5 nor CSS3 are finalized standards, support among many Web browsers for some CSS3 properties is strong and some aspects of HTML 5 continue to make their way onto Web sites. Given that Dreamweaver has historically offered features that were ahead of the curve, even offering workarounds to support all browsers, this timid approach to emerging Web techniques in CS5 is disappointing.

    It’s sad to see Adobe dropping the ball last few years. It seems they are focusing in the wrong areas. And have you noticed how ugly the UI is in the new Dreamweaver? It’s ancient!

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 6:23 AM   in reply to thewhitedog

    Hi

     

    First; I think this is the first time I have read reply's on this forum from Adobe employees about what is being said/asked for by people posting on the forum, this is I think a very welcome change and something that would be welcome if they took part in such discussions more often.

     

    Martym_C wrote -

    It support some parts of CSS3/HTML5 in DW's Live View.

    This is not Dreamweaver supporting html 5 or css3, but the webkit browser engine as used in safari.

     

    This does prove the point though in deciding what to implement from the html 5 and css3 spec in dreamweaver, in that if the browser engine that dreamweaver is using supports some feature then should not the syntax be available in dreamweaver itself. Yes, I know that reading proposed specs and working drafts can be very boring and often confusing, (especially when it changes) but if I can do it and try to implement it, (xhtml 5/css3) then surelly there should be someone employed by adobe who can also do so, and decide if it is reasonable to incorporate as the specs stand, after all it is not dreamweaver that must actually render the code, (it should only have the code available by default and not as an extension).

     

    An example of the incomplete support in dreamweaver is the font-face rule which was proposed for css 2 and is still missing in CS5, then we come to svg support not only in dreamweaver but in fireworks also, this is supported in all browsers now except IE, (is supported in IE9 preview), and svg was initially an adobe proposal to the w3c!

     

    As for html 5 video/audio, (I know the codex is a problem) but as there are at least 7 different ways to incorporate flash into a html page, (as I know of) anything that simplifies incorporating videos, etc. can only be an improvement.

     

    O/k, media queries is in a preview of proposals for possible future incorporation, but it should have been in CS5, as it is one of the items that has reached release candidate and is unlikely to change, once something has reached release candidate then please incorporate it in the next update, (if there are to be updates for CS5?).

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 7:50 AM   in reply to pziecina

    @thewhitedog: I did read your response, did you actually read mine?  The link to the Design and Web blog - clearly an Adobe site - I referred to from an earlier post has quite a bit on our intent and even specific examples of R&D we're working on around these specs.  Besides that, we've never posted our future feature sets or R&D, so even this is more of an inside peek than you'd generally get.   It would be a lot more productive if you actually engaged in the conversation and talked more about what parts of HTML 5 you want to use, and why.  If you can't answer that question, it'll be hard to talk more specifically.  Quite frankly, HTML 5/CSS 3 are baseline technologies we intend to and will support deeply just like every other before them, ust with a more pragmatic approach and not being biased or rushed by the current Apple HTML 5 vs. Flash drama (which I find incredibly unfortunate, but personally spend all my time in the HTML/CSS world).  It'll happen very shortly, in fact, and the roadmap will be evolving.  I'd go on, but @snakeyz02 seems to have nailed the intent of my original response above with his response, not sure I'd have much to add to that, at least right now.

     

    @pziecina: Thanks for actually engaging in more specifics, although it would be a mind-numbing exercise to go down the element/property list for HTML 5 and fisk it, it would be a lot more handy to hear exactly what you intend to leverage HTML 5 for too (as you've clearly given this some thought), and why Applications?  Better design and text flow?  The <video> element alone (which tends to be the #1 reason I've heard for HTML 5 interest over the last 3-4 weeks, quite frankly).  To us they're all interesting, and targets for implementation - some more relevant short-term than others (again, we have our thoughts there, but are all ears if you'd care to share your own intents).  For the record, webkit was chosen specifically because it would give us the best opportunity to support HTML 5/CSS 3 rendering long-term (so yes, we do consider that one key level of support in DW- accurate rendering).  Expect to see DW's webkit updated to bring on more support for various elements shortly, along with more baseline support for the new standards.  From there, as patterns in authoring emerge and some of the short-term browser inconsistencies resolve, we'll be specifically targeting them for more specific features.  That's how it works, generally speaking.  Any 'roadmap' I could share - even if I could - would be revised regularly as best practices and projects evolve to begin leveraging HTML 5.

     

    And of course we're incredibly excited about the possibilities and have tons of ideas, and will probably slip them out more iteratively than you've been used to in the past with Dreamweaver.  Keep posted to the Design and Web blog (linked above in the thread) if you want some sneak peeks, and know there's a LOT more to come, and probably sooner than you'd expect.

     

    -Scott, Adobe Systems

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 9:14 AM   in reply to sfegette

    Hi Scott

     

    First thank you and the other members of the team for taking the time to reply.

     

    Before I reply further, I do appreciate that much of the html 5 and some parts of the css3 spec are in still in constant revision, a typical example of this is the border-image property which has changed to my knowledge at least 3 times since it was first proposed, and both safari and firefox had it wrongly implemented originally compared to how it is now proposed.

     

    For me the layout proposals of html 5 are a vast improvement as they, (if used correctly) 'force' the designer/developer to actually think about the correct syntax and if it is appropriate to use in a particular context. But that is a minor feature for dreamweaver to have as far as I can see, in that is covered by the extensions currently available as it is pure element syntax and not anything to do with the more complex sections of the proposals. Although it would be an advantage if dreamweaver rendered these in design view, this would also apply to media-queries and the sections of css3 that have reached the candidate proposal stage.

     

    The video is as I am aware, is a problem for everyone that is 'experimenting' with this section of the proposal, but as it already implemented in the more advanced browsers and will be implemented in IE9 some form of support is a necessity, (there are rumors that the next version of the iPhone will allow the flash player plug-in) initially I along with many others I suspect, will probably continue to use flash for video until it is clear how this is to be implemented, (knowing how things have happened in the past the IE9 implementation is probably the one that will become 'standard').

     

    Now the real problem areas:

    SVG support is a must even if it is only a feature to import the svg code created by another program, (the creation of svg's should be a feature in fireworks now) as the various 'options' now available on incorporating svg into html make it a viable alternative for graphic items, (in line svg at last, or at least in IE9).

    Forms are another area that, (originally the xhtml 2 forms module) will be used often by designers/developers and some support to help with the creation of html 5 forms would also be appreciated, (see the implementation in Opera).

    Cache Manifest creation help, is also another possible area that may be included in dreamweaver for the creation of 'off-line' browsing apps.

    Help with the creation of 'off-line' databases also.

     

    The list could continue, but that is enough about html 5

     

    Now for something that does not get mentioned often by anyone on the forum -

    WCAG 2.0

    The accessibility help in dreamweaver is so far outdated it should be updated as soon as possible. For many incorporating things like alt and tab index are as far as accessibility goes, any improvements in this field would I think help to improve the situation, but this is probably a discussion for a different thread, (any offers anyone?).

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 4:25 PM   in reply to Donald Booth

    Anyone employed by Adobe as "Dreamweaver Quality Engineering" who has to ask that question really has no business being in that role.

     

    Seriously, you have to ask "what do you expect" for the thousands of pounds we're being asked to spend every 18 months in upgrades. We expect nothing less than the software to support the cutting edge of web development, be that experimental or not. CSS 3 features have been used in websites for years now, sure they benefit a minority audience with hacks and CSS trickery making up for the inadequacies of lesser browsers, but right now Dreamweaver is the Internet Explorer of web development tools and given the 18 month development cycle, those of us stupid enough to support a flagging software developer are going to be stuck with software that's outdated from its release date.

     

    Hardly something that comes under the nomenclature of "quality" is it?

     

    But seeing as you asked, go take a look at Style Master - http://www.westciv.com/style_master/ THAT'S what I personally would expect from Adobe.

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 4:30 PM   in reply to pziecina

    Hi, @pziecina - great thoughts.  Exactly what I was hoping for. 

    Since I learn far more by asking than by talking, I've a few responses/followups if you've the time and inclination:

     

    - CSS3 media queries are particularly interesting, primarily as HTML 5/CSS 3 will have increased relevance to smartphones and/or alternate devices short-term due to varying browser implementations on the desktop browsers (and reasonably consistent/standardized versions of webkit available on most modern smartphones).   Here's what we're thinking as for a real, tangible way to manage this workflow- do you see this as a viable way to work?

    http://blogs.adobe.com/designandweb/2010/03/multiscreen_authoring_with _css3.html

     

    - WRT video: good to see IE is supporting H.264, although that does leave Firefox/Opera hanging with their Ogg Theora-based support.  I see fragmentation a reality for the short-term, but fallback/graceful degradation would appear to be the most crucial factor to consider short term.  One best practice that seems to be emerging a bit is using a FLV (Flash Video) as the fallback to HTML 5, therein you'd always get native video if your browser can support it, and fall back to FLV if not.  Do you see yourself working that way short-term?  How would you cascade support for the various video playback mechanisms (or would you at all)?

     

    - SVG: although Firefox support has lagged, it is in current builds but as a 'technology preview' (i.e. likely to change).  Although that means it's still a bit volatile to write features around, this makes SVG a lot more viable than canvas on the desktop browsers short-term as IE's still holding out with native canvas support.  How do you see yourself using SVG, or canvas, uniquely?  What type of tools and workflows would you see as most viable for working between SVG and/or canvas regions and the 'outer containers' of your page/app markup? 

     

    - Cache manifests and offline SQLite - very very important for persistent online/offline web apps IMHO.  I'd see caching as a very important issue for mobile designers in particular where you may want to highly optimize for slower wireless network connections.  Aside from the offline data storage (which will clearly be a huge benefit for web apps specifically), how and for what reasons would you be leveraging cache manifests in projects over the next year or two?

     

    - I'm personally obsessed with accessibility, but will admit I've become more reliant on service-based tools (WebAIM's WAVE, for example: http://wave.webaim.org/, and the W3C validator(s)).  How are you generally validating your projects' accessibility and standards compliance now?

     

    Sorry for all the followup questions, but that's how we get here- it's far easier to build good solutions when you really dig into the problems and base them in real-world scenarios. Thanks for indulging, BTW ;-)

     

    -Scott, Adobe Systms

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 4:42 PM   in reply to Steven D. Reid

    Stephen- I think you may have missed the nature of that question, and why it was asked.

     

    Don wasn't asking because he doesn't know the answer.  He's asking because he only knows how to answer that question for himself.  As I can only answer for myself, or you for yourself.  Asking how, when and in what ways you would want to use technology (like HTML 5/CSS3/SVG/or whatever) is crucial to understand your specific needs, concerns and workflows more deeply and expand upon them, otherwise we'd just be making assumptions or imposing our own workflows upon our customers from isolation.  We ask these questions all the time.  Please refer to my prior post as a good example of how this type of conversation can be an incredibly positive one. 

     

    Trust me, we have tons of our own ideas here (available via links in the thread above for your perusal, lest you really think we're just sitting around idly waiting for some divine inspiration to strike), but will ALWAYS get out and ask questions and dig into the problems like crazy before imposing a solution on you.

     

    -Scott, Adobe Systems

     
    |
    Mark as:
  • Currently Being Moderated
    May 7, 2010 4:49 PM   in reply to sfegette

    Oh, and @Stephen, I've used StyleMaster many times before, and always felt it was a very nice app - specifically with the recent v5 release (and John Allsopp is a hell of a guy, too).  But it's also very CSS-specific, and not necessarily a tool for generating HTML 5-based markup or constructs, let alone the app and multiscreen-specific aspects of HTML 5 (some points on that in my prior post). 

     

    In DW CS5 we added CSS inspect (firebug-style live CSS introspection, as well as online site/page introspection- not just limited to local files/apps) and a lot more features to work in realtime with CSS, so although I don't think we aspire to be StyleMaster, I'd agree it's a very nice app that's influenced us (along with CSS Edit, Firebug, Xylescope and others) this last release.

     

    -Scott, Adobe Systems

     
    |
    Mark as:
  • Currently Being Moderated
    May 8, 2010 8:26 AM   in reply to sfegette

    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-mo dels.html#annotations-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

     
    |
    Mark as:
  • Currently Being Moderated
    May 10, 2010 2:57 PM   in reply to pziecina

    Hi, @Paula - excellent thoughts, and it's good to hear that we're seeing the database/cache manifest issues in a similar fashion (that's a tricky one to explain without going into deep technicalities).  Media Queries are a very interesting area as we move into a multiscreen world more rapidly, obviously- we're thinking about a lot of ways to abstract 'classes' of devices easily to make it simple to target a range of devices or form factors but it'll be very illuminating to see how that particular aspect of front-end design evolves over the next year or so as phones and tablets make more of a push onto the web and best practices emerge.  Thanks a million for sharing (and if anyone else has opinions/thoughts on these topics by all means join in!).

     

    @thewhitedog- talking about this isn't painful at all, it's what I do!  Glad the limited details I can share were helpful. 

     

    -Scott, Adobe Systems

     
    |
    Mark as:
  • Currently Being Moderated
    May 10, 2010 10:46 PM   in reply to thewhitedog

    This is what I thought would happen initially anyway. Just because it's "ADOBE" doesn't mean they have inside tracks to any and all things web-tech related. They wouldn't have wanted to include some measely HTML 5 features that were suspect about 6 months ago only to discover they weren't going to be part of the final spec (of which full compliance isn't expected until 2020)

     

    Just as Apple releases products and then updates them hardly in any time at all, I was thinking that incremental upgrades might address more CSS3 and HTML5.

     

    It's a new frontier. There's no reason to make a entire upgrade to a new whole number in order to charge more... make plug-ins that work with the base install and give the updates to those who actually buy the base. Wait until CS6 to actually implement into the API's and charge more.

     

    But, stepping back, the real thing is one of marketing and target audience. I work for a very large corporation as a front-end developer and what is paying the bills isn't html 5. Sure, it's fun, but if after almost 10 years there is still roughly 8% of the net using IE6.... it almost becomes a 'fanboy' issue...at least for another year and half or so.

     

    Design is still number one. Even in the interactive world. The user doesn't care what technologies are used so long as the content they are looking for is there, easily accessed and provides them the information they need.

     

    I know Andy Clarke is using what aspects of HTML 5 he can in everything he's doing. Awesome. If even 5% of my 2+ million target base were using browsers that supported those currently available aspects, I'd be using them and taking the necessary steps to ensure all the rest didn't see screw-ups on the screen.

     

    I realize I got off track but this thread was one of the more interesting discussions and seemed the best place!

     

    Adobe: you have to do something. Serve the masses instead of the elite. Pull a Walmart and the bean counters and customers will be happy. Mimic Apple too much and the web-side of products will eventually suffer.

     
    |
    Mark as:
  • Currently Being Moderated
    May 19, 2010 7:43 PM   in reply to CanonBoy

    Hey All,

    Here's a little project that myself and some of the team have been working on for a bit:

    http://labs.adobe.com/technologies/html5pack/

    Let us know what you think.

    Thanks,

    Don

     
    |
    Mark as:
  • Currently Being Moderated
    May 20, 2010 11:11 AM   in reply to thewhitedog

    Hi thewhitedog

     

    First, let me say that I did not intend to participate on the forum again for at least a few months, but when reading your reply, (in my inbox) I do feel you deserve some credit for the extensions release.

    I would take credit for suggesting the project, but obviously it could not have been thrown together in the few days since I mentioned using extensions to provide HTML 5 and CSS 3 support in Dreamweaver.

    Don't underestimate the power such posts and discussions have, especially when it is immediately after the launch of a new version of a product.

    As for Adobe having the extension in preparation, personally I think they did not intend to release the 'technology previews' as an extension, but as this is how they with all probability develop them, (as extensions) they only had to package them together and publish it, (work time would be negligible for doing this).

     

    Also let's not forget that over the last few months adobe has been criticised extensively for its lack of html5/css3 support, (not just in dreamweaver) and its concentration on flash technology improvements over 'standard' web design/development, just read - http://www.adobe.com/choice/?promoid=GXSAD, and then think about the timing of the news releases, and this discussion.

     

    Another reason may also be that many developers/designers have decided not to upgrade from cs4 to cs5, (as I and many others that I collaborate with, have also done) their reasons vary but the main one I repeatedly hear is that most have already invested in a php ide, which makes the reasons to upgrade equal to '0', as any other improvements, (even taking the extension into consideration) are negligible.

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    May 20, 2010 11:25 AM   in reply to pziecina

    @thewhitedog- thanks for the good words.  We indeed well underway with this (and had always planned to release support for HTML5 regardless), I just was not able to say that specifically at the time, even though we really wanted to  ;-)

     

    @pziecena - sorry to hear you aren't upgrading, although your reaction to DWCS5's feature set (and that of your colleagues) hasn't been the general reaction from the marketplace we've been hearing so far (PHP & CMS integration was one of our most highly requested feature areas before HTML5 took a rapid upsurge over the last month or two due to recent media events).  There's an infinite number of directions any one release of Dreamweaver could take - literally, and we certainly do listen VERY carefully to all discussions (including this one) to decide what to implement and when.  Perhaps the next release will have more features of interest to you, however- but I can't talk about those features yet either (although yes we're already at work on those too).

     

    -Scott, Adobe Systems

     
    |
    Mark as:
  • Currently Being Moderated
    May 20, 2010 11:44 AM   in reply to sfegette

    Hi Scott

     

    I did say -

    their reasons vary but the main one I repeatedly hear is that most have already invested in a php ide,

    This is also my main reason, and as I invested in a php ide only six months ago! After much testing of the web suite I decided not to update. I would say though that for anyone who has not invested in such a product then DW CS5 would be a sound alternative.

     

    My decision is no reflection on what you have done with CS5, but as my clients range between large multi-national corporate sites, (for which I required the ide) and small business sites, for which improved DW server behaviours would have been a much better improvement for me. However I would guess that you already know my opinion on this?

     

    As you say perhaps CS6.

     

    Paula

     
    |
    Mark as:
  • Currently Being Moderated
    May 20, 2010 6:54 PM   in reply to thewhitedog

    You need to downloadAdobe Dreamweaver CS5 HTML5 Pack from here:

     

    <http://labs.adobe.com/technologies/html5pack/>

     

    It is still in beta but it does help a lot.

     

    hth

     
    |
    Mark as:
  • Currently Being Moderated
    May 20, 2010 7:07 PM   in reply to thewhitedog

    @thewhitedog- Not sure where you're getting your broader information, but the Flash 1.0 mobile plugin has always been scheduled for the Froyo release of Android - that's when we get support in that OS, and obviously Apple has their own opinions/directions so there's never been any opportunity to even show what's possible on their platform.  10.1 on Android was demoed just yesterday at the Google I/O conference and sent out to reviewers as well) during Google's I/O conference.  The prerelease is now open to the public for developers at Adobe Labs.

     

    Do you really think that HTML5 ads - which, I might add cannot be 'Flash-blocked' and are already reported to take over your entire screen (going by the Apple iAd announcements) - will be any less intrusive than Flash (or Silverlight) ads, if not more so?  Further, many early adopters have already proven that rich HTML5 applications have just as much potential to crash a browser or OS as Flash, Silverlight or Java - the only reason you've not witnessed this so far is simply because little of what's available in Flash (or those other environments) has ever been available natively within a browser until very recently.  Poor coding/engineering crashes browsers, not runtimes.  In 3 years you'll likely see just as many obtrusive ads and overengineered widgets in HTML5 as you do in Flash.  That's not to say that you won't also see just as many brilliant experiences built in all of these technologies, just that as HTML expands its reach it will also inherit the performance risks like everyone else.  With great power comes great responsibility, and HTML5 is very new.  For all the wonderful things HTML5 can and will do, there is and will be much that it can't.  We create tools to help people publish their ideas, so quite frankly are not going to dictate how and where that happens - the HTML5 pack is, as you've noted, a first offering of how we'll be supporting creativity in whatever medium it needs to be delivered within.  It's that simple.

     

    I think you subscribe to one opinion in this discussion, but there's most definitely another side which clearly has caused enough of a stir at Apple for their CEO to post a public missive about it on their home page, and if you really look at the wider responses and opinions across the globe it's not exactly 'every computer user' who feels the same as yourself.  Quite frankly, I own an iPad and have to regularly explain to my son why he isn't able to access his favorite sites on it (largely Flash games and educational material).  To him, it simply means the tablet is useless (which is annoying, as he continues to steal my laptop as a result).  But you are certainly welcome to your opinions, of course.  Personally-speaking, I prefer to ignore the drama as much as possible and keep working on making things better, so forgive me if I excuse myself to return to that now. 

     

    best- Scott

     
    |
    Mark as:
  • Currently Being Moderated
    May 21, 2010 6:01 AM   in reply to sfegette

    Hi Scott

     

    Sorry to disturb you again, and this is defiantly my last post on this subject, (I am, or supposed to be semi-retired!).

     

    First, I think that many people are confused about the difference between html5 tags and the html5 api, and that the api is where the real difference lies between (x)html that we now use and html5 as it is proposed. The html5 tags are named as per the 'function' they perform in the mark-up, and must still be styled via css, so using them alone gives no real advantage over 'standard' (x)html at the moment. The real difference is the api, which can be compared with having the javascript code that one would normally write to perform a specific 'function/effect' natively available in the browser as standard.

     

    For those interested in using or seeing just how involved the video code is for html5 with 'fall-back' code for legacy browsers, see - http://www.html5video.org/kaltura-html5/.

     

    Now my question for you Scott - When will the css3 animation editor be available, (or have I missed something in cs5) see - http://blogs.adobe.com/designandweb/Rich%20Ad%20Screenshot.tiffhttp://blogs.adobe.com/designandweb/Rich%20Ad%20Screenshot.tiff

     

    Paula

     
    |
    Mark as:
  • Currently Being Moderated
    May 21, 2010 6:56 AM   in reply to pziecina

    Hi, Paula- the animation editor is still under development, not part of the HTML5 pack per se.  Keep posted on that.

     

    -S

     
    |
    Mark as:
1 2 Previous Next

More Like This

  • Retrieving data ...

Incoming Links

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points