Simple, do not upgrade.   90% of what Dw CC has that Dw CS6 does not, is not requiered.   If you do require more up-to-date code hinting, then a free editor such as VS Code is the better option. Even Adobes Brackets that is now the code editor used in Dw CC is free. So look and think very carefully before subscribing to the CC plan, and ask yourself if the cost is worth it. ...その他を表示

And what has that to do with Dreamweaver? ...その他を表示

Adobe do say that Dw is for designers, even if they also go on to say Dw is for 'designers who wish to code'.   One only has to look at the code editor Adobe recommends for coding for its 'experiance cloud', (VS Code) to see that Dw is not considered 'up-to-standard', even by Adobe themselves.   The 'rot' really started back in CS5, when it was decided that 'theme' creation for wordpress, (etc) was more important than html5 and css3 support, and that those cms's are all that designers and developers require going forward. Add to that, with many 'well known at the time' Dw so called experts, saying that html5 and css3 would NOT be usable in browsers until 2022, (another 2 years away), Dw's demise was secured.   Even reading posts over the last few years, and the Dw road maps, demonstrates the complete and utter lack of knowledge of how the 'front end', (UI/UX) is changing by Adobe, (also read Dw managment). ...その他を表示

Adobe, (and the Dw team) DO see Dw as a tool for designers only, and b.t.w. you now have to leave anything you do that relates to the future of Dw, (at least that's what I was told to do, when I said the same as you are now saying in the pre-release).   In Dw's defence though. Ask yourself "how many people who decide(d) what Dw,s future should be, actually use Dw beyond personal sites"?   ...その他を表示

Sort of agree Os.   I do think that there could be a more 'visual' method of layout etc., but I also think that to do so would require the user to know what they are doing in html/css/js in order to do so.   css designer sort of 'got it right', but it also demonstrates, 'how to get it wrong', and don't even get me started on the Dws team not keeping it up to date.   Its the same with html. One could 'lay out' the html semantic layout visually, but only if one knows what they are doing.   As for js. The old 'actionscript' panel for Flash, could (or maybe that should be should) have been adapted to js coding, especially when it comes to the html canvas element.  ...その他を表示

No matter how many times I read such posts, (and I do wish the Dw/Adobe team would 'get their fingers out of their ears) I cannot help wondering, how many people who install the Adobes Premier pro program would expect to go pass themselves off as 'professional film editors'.   Given the number of people who expect to create web sites, (Adobe CC users) without any knowledge of code, it should be all of them. ...その他を表示

You are not saying anything that many others have said.   When I suggested that Dw was not worth more than $5 per month, I was told by many, that if I did not like Dw to leave. Adobe is NOT interested in web development, (then again, I do not consider Pinegrow as a serious web development program) and many of its 'attempts' to make a more visual web site creation tool, are a joke to anyone serious about the profession.   The question one has to ask though, (which I don't think even Adobe, or the Dw team know) is - 'who is the target audiance for Dw'? ...その他を表示

Be carefull about using html5 for epub, (yes, I do agree Dw should support epub creation, but it has difficulty keeping up wuth what web sites require, so no one hold their breath for that to happen). As I am not certain if the epub specs, (and readers) support using html5.   Whilst there isn't much difference between html5 and xhtml, there are cetain elements that are valid in xhtml but not in html5, (and vice-versa). So whilst it would be worth learning html5 for web development, it may not be for epub.   This is the html5 spec, (remember that unlike old html standards, html5 is a 'living standard', so there is no definitive version) - html5 spec.  Much of it you probably don't want, but DO read the semantic mark-up section.   as for epub - /epub-spec.html  That is the latest spec, which I think still recommends xhtml. ...その他を表示

Not certain what you are trying to do?   If it is having different background images for various sections, then you should attatch a background image to each section. e.g. article { backround-image: xyz.png; } p { background-image: xxy.png; }   If it is multiple background images for the same section, (e.g the body) then you use multiple background-images, seperated by commas, and the other properties should also be comma seperated.   See -  /Using_multiple_backgrounds  ...その他を表示

Are you using a version control system?   If you are using git then refreshing the files located in git, (or any other version control) will show you, (in the files panel, and in code view) both the updated files and the updated portions of the file. ...その他を表示

I can see many of those involved in holidays or similar having a very rough time over the next year or so.   For some other types of sites though, buisness is 'booming'. I have had a lot of requests from people I know, (and through others) to ask if I can add an e-commerce, (or convert too) parts of their sites. In lots of cases though, I have told those asking, that the site would have to be almost completely re-written.    Also I am not realy interested in comming out of retirement.  ...その他を表示

Don't blame Dw for this.   A few years ago, the W3C anounced that any new (or updated) sites should use (or convert to) the html5 doc type. At the same time they anounced that the old html4/xhtml doctypes are to be considered obsolete, (the debate on that is still ongoing). So as Dw is a tool for web development, (not ebooks) they dropped the older validation routines.   ...その他を表示

It's nice to know that nothing has changed, and that Adobe still thinks of web development as a 'graphic designers' add-on skill set.   That said, I will repeat what I have said many times - "Trying to compete in the bottom end of web development now, is a loosing stratergy for anyone serious about web development."   Most users of such a product are not interested in the code produced, (just as Muse users where not) and if it was not for the dramatic increase in download speeds available to those using the web, such bloated code would even be un-sellable to clients, (that apples to many Dw users, using frameworks as well). One only has to read a number of posts from recent weeks in this forum, to see that very few people have any interest in learning, (or knowledge) about code. Many now think that producing a web site, should be automatic, and easy, no matter what type of site is required.   The end line though, is that - it all comes down to making 'easy money'. If there is a market for 'cheap' to produce, someone will always fill that requirement.   ...その他を表示

If it still looks off, (which could also be a browser cache problem) try adjusting the top and bottom margins 1px at a time - margin: 1px auto 1px auto;   What is probably happening is that even though the display is in columns, the browser still treats all the 'p' elements as though it is just one long series of 'p' elements, without any other considerations. So even though a 'p' element looks o/k, the margin, (or padding) for that 'p' element may be carried over to the next column.   There is a css property for multi-column that 'tells' the browser to start a new 'p' (or any other) element in a new column, but Safari has yet to implement it. For that reason alone it is better to 'play' with the margin and padding values, until the desired visual layout is satisfactory. ...その他を表示

Forgot to add Ben,   For anyone thinking that srcset is just a 'gimmick'. Try viewing your site on a 30 inch+ 4k screen, then remember that 4k game consoles have browsers, and 1 in 5 users of them do use the built in browsers, (1 in 5-8 (estimated) for smart tv's). ...その他を表示

Don't worry Ben, if you are as confused as me on the subject, then welcome to the 'confusion reigns' group.   The question that I could not answer, (and no one else has satisfactorily to my knowledge) was that if px values are displayed in browsers as 1px = 16 device pixels, (4k screen) then how does srcset, (using the 'w' descriptor) or the px size for images work, as they are displayed at 1px = 1px?   The problem is becomming worse, with 30 inch+ 4k screens being used not just by smart tv's, but as desktop monitors. (makes me glad I retired). ...その他を表示

Hi Ben,   There is now, (once again) some debate over using decimals in px values.   With many 4x+ devices now being widely used, none of the device/screen manufacurers are saying, (or perhaps even know) what happens if decimals are used. It is possible with a 4x screen that a 0.25px, (or multiples of) pixel mesurement would 'display' 1px, (it gets even worse, when 8x screens are used). Also don't ask what difference the device pixel ratio does anymore.   The debate started with Apples anouncment regarding the iPad OS last year, (the statement that it would display desktop layouts by default) and how it would know which media-query was for desktop? ...その他を表示

You can simulate the effect by using css animations, (also works on desktop).   Set the animation to first increase the size of the image, (or whatever) then pause when the effect is at the desired size. Then un-pause the effect by having the user touch/click again. You can also just have the image pause for a set time, before shrinking the image.   Unfortunatly Dw does not have anything to help with the creation of such effects. The old google css designer app is probably the only free app I know of to 'visually' help, but it is dated, and only supports creating with webkit prefixed css. For multiple images, (or whatever) you will have to create the animation for each image, (cut/past and use image specific css selectors). ...その他を表示

Unfortunatly without using downloadable fonts, you will not get one typeface that works across all browsers. For maximim compatability you should use a css font-family declaration, so that acceptable alternatives will be used should a device not support your prefered choice. see - font family    The reason for that, is because most Android devices only have 2 fonts available, (droid and roboto), and whilst some other devices do include many more fonts, Android is by far the most single type of mobile device in use, (tablet and smartphone). ...その他を表示

What you are asking is for someone to teach you css, (by that I mean to tell you the definitions) which is not what happens here. The place to go for such is the W3C css pages where you can read them for yourself.   As far as div goes, (and to get you started) see - css visual formatting model level 2.1    That is just for starters, and there are other 'models' such as css flexbox and css grid layouts. ...その他を表示

You are making the assumption that your way of working, is the best way of working. Which may or may not be true.   There is also the problem of what type/size of site you work on, as this also may or may not be typical of what other users work on. Is it small/medium/enterprise sites that would be developed, and what features should Dw offer to support each or all types of site?   Without the Dw team giving us more information, no help is the best help we can offer them, (if they do not know what the feature should do, or what type(s) of site are to be built using it, how are we to know?).   The web has changed dramatically since the old SB's removal, so building a feature that only offers the same as before, (even if updated) may or may not be of use to many users, (off-line db's are an example). Required info is NOT forthcoming from the Dw team, so it is only fair to assume that they have no idea what is required also. ...その他を表示

As this discussion turned up in my inbox, I thought I would reply.   It is good to notice that the Dw team is running true to form, (still). Asking for feedback, (workflow, etc) then ignoring any replies, shows that nothing has changed in years, so no one should get their hopes up regarding the return of SB's and how they will work, (or when it will happen).   Even the inclussion of modern html or css should be viewed with lots of scepticism, simply because, (read the official announcement carefully) Adobe/Dw have always said that any features should have reached 'recommendation' status before Dw will 'fully' incorporate them into Dw. If you look at the html/css specs. most of the features, (inc flexbox, grids, animations, etc) are below recommendation status. Remember 'candidate recommendation' or below is NOT 'recommendation status.   Even modern SB's require a lot more info from the team, because how one works with databases will depend on many things, even simple things such as having the sql/php included above the html or in a seperate file should be considered, but without the team joining in, and telling us what they consider as usage, (even if it is only to say that Dw is for small personal sites only, must be known prior to any discussion).   The Dw team though, will not join in any discussion(s), it will rely on and take opinions of only people they consider as experts, most of whom have never worked in web development, it will also ignore anything they do not want to know or listen to.    No one should have any hopes of Dw getting anything working correctly as requiered by Dw users who are using Dw to earn a living as web developers. So don't hold your breath for anything workable, and don't even think of helping.  ...その他を表示

As someone who often sits by the lake, drinking beer, (prefer white wine though) I can recommend it Os. After a while one even starts to wonder what was so important or difficult about web development. After all with so many people saying how easy it should be to develop a web site, why bother. ...その他を表示

That's why I said to use transactions.   No matter what happens transactions are a db function, so the user can manipulate anything they like client side. Even if they order multiple items, and manipulate multiple costs, one can do a check using transactions on every single item, so any 'cheating' is immidiately exposed.   Stored procedures with transactions are how banks, enterprises, etc do it, and with good reason. If any discrepencies are found then the db can remove all data from the db that the user has stored, keeping the db structure clean. Plus if a single sp in a transaction fails, for any reason, then the entire transaction rolls back everything, as if it had never happened. ...その他を表示

Not really a problem Os.   Save the users order in a 'holding' database table. Then once the form is submitted to say paypals ipn, do a comparison of the returned total payment data from paypal with the total cost, (and any other info you wish) using sql transactions. Finally using the same transaction, transfer the clients info, (etc) to the actual orders table, and delete the 'temp' info using the same transaction.   MySQL supports transactions, but as transactions are a database engine function, the db engine must be one that supports them, (2 of the most popular engines do have support).   This is an ideal use of transactions, simply because, if one sql process fails, they all fail, and a reason for the failure is stored in the db log file, so you can trace the problem, (eg. price miss-match).   I know many will not wish to use transactions, as they also require stored procedures, but both are the way forward. Which is why I asked if the team plan on support when the 'planned' database functions are returned to Dw. ...その他を表示

I'm replying to this discussion as the original covered pdo. It maybe an idea though for someone to branch it to a new discussion.   Asking about workflows at this point a like cutting a piece of string into lots of bits then trying to make a whole piece again. Everyone will have different opinions and workflows, but first it would be good to know what the Dw team plans to include in Dw.   e.g. Will it have a sql admin panel?        Will stored procedures and transactions be included?         What type of user and app/site is envisioned for use?   That's just a few questions, for the team, (and others) to answer. ...その他を表示

I have to disagree Nancy. There are times when it can be absolutly necessary to keep html/css/js file sizes down to the absolute minimum.   As other assets used by sites grow, (I know most Dw users will not have to work to a file size specification) it can be necessary to make savings in the size of other files using other methods, and using different css files to match end users browsers is an important tool to many.   I have nothing against anyone using whatever method they and their clients decide upon, but all developers should have knowledge of other methods, and be able to use them if they wish. ...その他を表示