It would have been a good idea to include them as media queries in the past, but as html5 develops more features are being added that work in the same way, (conditional type statements).   srcset and the relatively new attributes for the video, (which differentiate between low-res, hd, uhd) tags attributes work in the same type of way. In that that let the browser decide what to load. ... View more

But I am old Ben, I have no illusions on that, my mind says 25 years old, my body just laughs. (Joke). ... View more

As Ben has mentioned that Dw should include all in a revamped Dw as per your post Birnou, I feel I should reply in your post.   Saying that only Wappler can do these now, is correct, (providing one wants them as point and click) but the old Dw Spry Db extension, (which I mentioned previously) could also do them all, (for free). I don't think that ajax usage should be by default though, (as in Wappler). Instead it, (or all you mention) should be options that users can decide to use or not, depending on the project/site.   It's interesting though, that what Dw was capable of 13/14 years ago, is now up for discussion. As I can remember that back then very few had any interest in them, and unfortunatly that 'lethargy' also carried over to diss-interest in what html5 and css3  brought to the possibilities in web development as far as most Dw users were concerned. ... View more

The problem of testing, (and a 'take it or leave it' approach) is that all 'new' features then become a Dw dev team and their advisors idea of what can/should be done and how. Which lets face it, on past experiance does not bode well for the implementation or for reducing the number of bugs present in them on the realese of the product.   Even thing as simple as srcset and css variables, have caused a lot of discussion in this forum, (for, against and how, what is required). Plus how will css grids/flexbox/multi-column layouts be implemented in a visual way? As reading a few older posts in this forum, a lot of mis-information, (and almost nothing when it comes to multi-column) has been posted. Plus lets not even talk about 'newer' features regarding css grids and flexbox, that are still in development, and as for css shapes/transitions/transforms/animations, lets hope that whomever tackles the implementation and development of those, (and testers) know what they are doing, (remember the original UI for transforms/transitions, was taken from Dw and developed into Edge Animate).    ... View more

Just to get back to the roadmap.   I'm wondering if there are also any plans to move the Dw UI into the 'visual' requirements arena that those with limited code knowledge appear to want?   The reason I ask, is that with the demise of Muse and BC, and the promise of 'a replacement' product for Muse users in that forum, the announcements of various features in the Dw roadmap, along with improving the UI of features may be an indication of such a 'wish' by Adobe.   Which then also leaves me with the question of 'testing', which has been discussed previously, as very few Dw users, (and testers) actually use Dw for anything more than 'personal/small' web sites, (mainly static using what was in html4, not html5 or css3).  So to what standard will these new features be implemented and tested? Or will it be a 'take it or leave it' route to implementation and testing? ... View more

I read the wappler post you refer to, and smiled when I came to post 4 or 5, (the one giving examples of what they could not do).  What I found interesting is that every item mentioned was possible using the Dw Db 'spry' extension for Dw, (the one that was only realeased via Adobe labs).   So the Dw team does have examples of the code requiered for not just the mysqli/pdo sb's, but the ajax/xml/etc, mentioned in that post, (though it does require updating).   As for the 'roadmap' for Dw. Interesting, but what does the team interpretate as 'latest html/css/js standards'. Then comes the question of testing, as Dw, (and its forums) have lost LOTS of the people with experiance in modern server-side and client side usage. ... View more

Osgood wrote - Panic is currently re-writing Coda from the ground up, it's taking a long time, but they know to keep adding bits onto an old, passed its sell by date programme is not going to work in the long term, they have seen a rapid leakage of users over the past 4/5 years.   That's what I'm trying to point out Os. Dw has used the same ageing (or old outdated) code for years. Mainly html, inline css, javascript with a bit of c++ thrown in for things like OS file managment, save, etc. Then over the years they have added, removed or changed so many features, (without fully removing what has been removed) that everything has slowed down to the point of 'no return'.   The comparison would be - getting IE5 to work with modern, (todays) html, css and js. Which would require the developer to use 'helper' js to implement the missing features. This would mean the browser, (IE5) would run slower and slower. Which is what has happened to Dw.   Many users do not realise that Dw itself, is little more than a browser based application. ... View more

You missunderstand Birnou. The comparison between Dw Ultra Dev and Dw CS5 was for the underlying code used, as both use html2, inline css (version 2) and js v2. It has nothing to do with when or what is included, which if you have Ultra Dev installed you can check for yourself. All that a user must do, is go to the Dw instalation, (including what is installed in the 'hidden' user folder) and open the files to see what is used.   The above does not apply to the Brackets editor integration, 2017 and later) as this does use html4, css and js v4.   As for Dw MX (2004), I included that simply to point out that the fact css was included for users to build stylesheets, that should not be confused with the code Dw itself uses.  ... View more

html4 was not a standard until late 1999, so given the development cycles of Dw/homepage/etc at the time it is unlikely that Dw used it, although I do agree that Dw2004 release that incorporated css does give the impression to the user of being a much more modern version than previous ones, (impressions can be deceptive), mainly because css usage was incorporated for the end user.   If you read the expanding Dw documentation for ultra dev, then compare it to CS6, (edit - sorry that should read CS5) there is almost no difference, (even reading the actual code, shows no difference, only new features written in html, in-line css and js v2). ... View more

You have just confirmed what I thought, (the underlying Dw code is to old), by that I mean the code that ties it all together.   The disabled features you mentioned, are mainly from Brackets based code, which is much more modern than the code on which Dw is still based - Dw's base code goes back to html2, in-line css, javascript v2 all of which is then tied together using c++ from the 90's, (Windows 95/98/xp, or whatever the Apple OS was at the time, just recompiled). That's why I think the performance has dropped off so dramatically over the years, as more and more has been asked of Dw, without the base Dw code keeping up.   Yes, it could be argued that as computers have gotten faster, (remember a fast computer at the time of xp's release was still only about 1ghz, and ram about 512Mb), so the performance of Dw's base code should have increased, the trouble is, as we both know, there comes a point when it starts to drop off, which I think was reached in the late 00's.   There is also the problem of Dw now using 2 (or more) very different code bases, (1 from Dw before 2017 version, 1 from the Brackets code editor, and others from the different 3rd party features). All of which will have been incorporated using the 'quick and dirty' coding methods that have become very prevalent in programming over the years, (or to rephrase the methology, 'get it working, and that is good enough').     ... View more

Hi Birnou, doing nothing today, so thought I would look in on the forum.   I don't think Dw is meant for users who are building anything more than 1 site at a time, or more than 1 user working from the local drive. So anything more than those users should not be using Dw. Even modern client side code has fallen way behind what is possible, (or required in many cases), with only code support for those who are building small 'cheap' or 'demo/personal' sites.   Dw was built, (years ago) for such type of user, and over the years bits have been added for such users. Without a complete rewrite of the underlying Dw code it has reached its limit of possibilities. All the updates to Dw since CS6, have simply been add-ons to support the single user, (designer not developer). Slowing it down completely once more is asket of it.   Who is to blame for this, is irrelevant now. Simply because to get it working correctly for anything more is not going to happen, as the underlying code that ties everything together is too old and slow, and Adobe either is not interested, or does not 'see' Dw as more than it currently is. ... View more

I don't normally read this forums posts anymore, but when I get posts in my inbox to a 2 year old discussion, I have to ask, why?   Reading your post from a few days ago, I have no idea what you are asking for?   Dw is dead, especially when it comes to the modern web, (and don't use bootstrap). Even the ACP's who reply in this forum, all admit to using 'other' programs, (which should tell you something). There is absolutely NO chance of Dw catching up with what web developers require anymore, the team is very small, (most of those people in the Dw 'credits', that you read when you click on 'about', left the team years ago).   All you can do if you want more than Dw currently offers, (and who dosn't.) is find a different program, just like everyone else. ... View more

It is not including code hints for creating PWAs that I am against, (as everyone knows, if even a single modern browser includes any html5, css or javascript. Then it should be included.). It is the inclussion of 'wizards' to help in the creation, before at least 85% of browsers support a feature that I am against.   When users ask for PWAs in Dw, (and Wappler, etc) they are not asking for code hints, but some form of 'wizard' to help. Which to me is putting the 'horse before the cart', simply because users are ignoring the possible future improvements and requirements that could happen durring the implementation process by browsers.   The other problem with environments such as Dw implementing such features, as an 'all in one process'. Is that like SB's, users start to think that how a program such as Dw implements them, is 'static', (that is how it is done, and will always be 'how it is done'). Ignoring any future security issues, or other improvements.. ... View more

Going slightly off-topic with this.   I notice that there is continued support for adding the ability for PWAs, not just in Dw but in Wappler and other dev environments.   I have to ask WHY?   Safari and by association iOS, (even 13) does not support all the features required to build a fully functional PWA that does the name PWA justice, as it is still missing many of the features required. There is no point in building a PWA in my opinion, if it cannot offer more than the old 'save this page for off-line use', which is all that Safari anf iOS device users could currently see if a site offered PWAs, (and that's forgetting all the problems of maintaining two different PWA code bases. 1for browsers with good support, and a second for Safari and iOS).   See - PWA support for Safari.  Whilst the article is 18 months old some of the features that are mentioned as 'getting support', still do not have full support. ... View more

I'm going to stick my neck out now, (translation for Birnou - its like saying 'put my neck into the guilotine, and hope no one pulls the lever'). I don't contribute to the forum much anymore, but over the holidays, I did speak with a number of people looking to start out in web development, and what I learned was -   No one who intends to make a career in web development uses Dw anymore. However some did use Dw whilst in Uni, or further education, simply because of the student discount, and 'other' adobe products being requiered for the course(s) taken. This I think leaves Dw as something only used by none coders, (read not large or enterprise requierments) or those who would have to use other adobe products anyway.   In that respect, I think Dw is actually all that is required. Simply because it meets the requirements of the small site builders, working for themselves, or only building sites on a casual or personal basis, and not requiering anything more than a basic rwd site or newsletter creation. ... View more

By ALL content, google means that the content available should be viewable/readable on any device used. If it is cut-down or truncated in any way, without some method being provided to view/read the full content, then it fails the criteria.   These days, there is no excuse not to allow a user of a smartphone, to view/read all content that is available, without having to use some other means to do so. One of the reasons for this policy, is that many users may now only use or have one device. e.g. a smartpone user may no longer have a laptop or desktop to use. Which would make it impossible for them to view/read the full content if a laptop/desktop browser was the only way to do so.   I think, (personal opinion here) that with the rise in the use of mobile devices and smart tv's, laptops/desktops will become a 'work' or 'learning' requirement only for many. The days of someone having multiple ways of viewing/reading web site content, are declining rapidly. ... View more

It's not ment to change the content. Search engines, (google) have said that ALL content must be viewable on every device, otherwise they will 'penalise' the site ratings. It goes back to the question of 'how do you allow all content to be viewable'? js and media-queries hiding or showing specific device content, leaves that device user with the full content, (if requiered') having to use a device, (mobile/desktop) that supports the content they wish to see. Yes, you could do it using ajax, but is that really an easy solution? ... View more

Instead of hiding content, (which will be downloaded anyway) why not use the html5 detail/summary element?   see - Browser support for detail/summary and - Brief overview   It will be supported in MS Edge in the October update. ... View more

IE 7, 8, and 9 have one good thing going for them, which is they support the use of IECCs. That means the you only require to create a seperate stylesheet for layout for those browsers, and include that in an IECC just below your main stylesheet(s). If you are using a mobile first stratergy, then dont't forget to include any 'other' styles that are not for layout in that stylesheet. Otherwise IE7,8 will not see them. ... View more

Flexbox and css grid layouts have become on-going topics for discussion for about 5-6 years in these forums, and like everything else which you use and when is a decission only you can make.   flexbox is well established, (even back to the iPhone 2 / iPad1, and Android 2.4 had support). Grids however has the opposite problem, in that it was iOS 10 before mobile devices could use them, (IE10+ has support).   It is now however not an either/or choice of what you learn, as both have become a necessity for developers to learn. ... View more

I'm not saying don't build PWAs, just that they must be a requirement if built. Reading the 'mini' app paper they would be an ideal solution for sites that do not require a full blown PWA. ... View more

There are a number of usability problems, such as the lack of any method of knowing if a post has been replied to, and more importantly where the reply is. If someone replies to a specific post, then it creates a sub-group, but there is no indication which post should be expanded to read a new reply.   Then we come to the problem of not having the full editor with sub-posts. The menu for selecting what posts are displayed and in what order, should be 'sticky', and not keep defaulting to 'Relevance', as only the individual knows what is relevant.   It's early days yet though, and they are probably hoping for feadback on what is required. The main problems will possibly be that every forum will/may have differing requirements.  ... View more

I'm replying in a new post, as the small reply box for sub-replys does not allow me to format my text.   I don't think PWAs becoming main stream would be a good thing for the web. Simply because most sites do not require it. For most sites they are overkill, plus they require thought to be put into how they work, in addition to and beyond what many people creating 'run of the mill' sites are willing to invest. Once they become anywhere near automated in there creation, (which many will want) how many end users will use them?   If we read those who are not interested in web standards and accessibility, we see and read a lot of 'bad practices' and misinformation being written, (then followed) by many. Look at Animate, or discussions in the Ps forum about how the web works, and you will see and read lots that no longer reflect how things should or does work, or posts from users that simply want to use new methods to replace old outdated ones, (such as using html5 canvas to replace flash) but ignoring all the problems and reasons why the old methods have been replaced and worse still ignoring the modern web and the standards now required.   Maybe 'mini' apps will have a place, as they are more specific to answering a specific client/end-user requirement than full blown apps or PWA, especially if they do follow the W3C standards. But a PWA 'free for all' would I think simply 'kill' the reasons why and when of their use.     ... View more

Thank you Ben, as I said I had never heard of them before reading the wjite paper. The 'not having to register through an app store', will I think be a great selling point for them. It is only a personal opinion, but hopefully the api's they talk about developing, will make development much easier for many, as a 'standard' method of creation would place them above full blown device specific apps, especially for those concentrating mainly on websites and PWA's. ... View more

I think we are back into the same uncertain times that mobile devices have created. I never thought device specific apps would catch on. But with the always connected times we now live in, both clients and end users expect more, (probably for less) than having to log into a web site to do anything. ... View more

A PWA is complementary to a web site. A 'mini' app is for complementary features when a fully blown app or PWA would be overkill. ... View more

Yes, but a 'mini' app is from what I can understand, only for essential or complementary info. It is not intended to replace a 'fully blown' site or PWA features. ... View more

Thanks for the thought Os,   The user case I thought of after reading the white paper, was - If a regular customer purchases something, then a 'mini' app could be used for order tracking, (dispatched, on-the-way, estimated delivery time). That would alleviate any requirement by the customer to log into the site just to find out what is happening to the order.   Instalation of the 'mini' app is the big problem as far as I can see. I know tablet devices are going over to be more like desktops, so maybe instalation from an app store will not be required by tablet devices. ... View more

Thanks for the reply Ben,   I had never heard of 'mini' apps before reading the white paper, and could not work out how they would be installed without going through an app store. If they are intended to be complementary to PWA's, (which is the impression I had from reading) then I can see them as being thought of as a 'quick' and easy way for end users to have any features thought essential available. Making those features easier to find and use.   That said, if 'mini' apps have to be installed via an app store, then I cannot see any use for them. Which is why I posted the question. ... View more