SoylentNews is people
SoylentNews
Physicist Igor Ljubuncic writes about the dearth of offline graphical web editors. These used to be quite common, but all the established names are long gone and even some of the newer ones are looking neglected. He summarizes what's still available now in 2018 and the relative strengths and weaknesses of these remaining tools.
Once upon a time, there were dozens of WYSIWYG editors, all offering their own wonders, as well as their own range of inconsistencies, garbage code and functionality. I came across the old Nvu back in 2006, upgraded to Kompozer when this one came about, and kept on using it ever since in some form or another, as it offers the simplicity of writing stuff without having to worry about code, plus some serious usability benefits that no other program seems to offer. But then, Kompozer hasn't seen any updates in a long while, and some refresh is needed. What do we have on the table?
And I'll add in a general question, what is your preferred method of dealing with either HTML or CSS or both? Strangely mine is Emacs for the HTML and vi for the CSS.
(Score: 3, Informative) by mrpg on Wednesday October 03 2018, @06:07PM
I use dreamweaver CS6, the last before the Adobe Creative Cloud. Sometimes I just work on the code directly.
If I don't have it I use notepad (W7) or leafpad on Linux.
(Score: 5, Insightful) by wonkey_monkey on Wednesday October 03 2018, @06:10PM (5 children)
Open URL in browser. Open source file in editor. Edit file. Save File. Reload page.
WYSIWYG.
systemd is Roko's Basilisk
(Score: 2) by wonkey_monkey on Wednesday October 03 2018, @06:13PM (1 child)
Yeah okay my brain is not engaged today.
systemd is Roko's Basilisk
(Score: 2) by FatPhil on Wednesday October 03 2018, @10:10PM
But yeah - if you write semantically clear HTML, or templates, then you should be able to compose them - knowing what they will look like - as plain text in dum-dum-dahhhh - whatever text editor you're happiest editing in. If it doesn't look correct, your CSS and your HTML should be simple enough to easily work out where you went wrong. And if you can't, then your HTML and your CSS are not simple enough[*].
Most of his examples were basically just GUI text editors, not WYSIWYG ones anyway, so you were as on-point as TFA's FA!
[* If, however, your HTML looks like:
<div class='content wc-12'><div class='main-content xp-2001'><div class='content-body wtf-69'><div class='content-main bbq-24'><div id='content content-main'><div class='header big biggish'>...
then just kill yourself, you're producing worse shit than the worst of the tag-soup of the 90s. And it's your own damn fault that it doesn't look like what you intended - because you never made your intentions sufficiently lucidly anyway.]
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Insightful) by ilPapa on Thursday October 04 2018, @12:51AM (1 child)
The problem is, the people who know HTML and CSS well enough to do this almost never know what a good web page is supposed to look like. They end up making something functional-but-ugly. Which is fine for us here on soylentnews.org. Functional-but-ugly is how we roll - it defines us. But most of the world in 2018 expect something that looks fairly nice.
I know, I know. Don't blame me, I'm just the messenger. Maybe functional-but-ugly will make a comeback and we'll all be superstars again.
You are still welcome on my lawn.
(Score: 2) by termigator on Thursday October 04 2018, @05:25PM
That is why you have the UI designer role separate from the UI implementor role. The designer can specify look-n-feel, layout, etc via mockups and/illustrations. The implementor is then tasked to do it in real code for the target platform. And on good teams, both roles work together so the implementor can provide feasabilty and cost feedbacks to the designer.
Main problem with WYSIWYG editors, especially for web-based interfaces is they generate horrible, hard to sustain code. I rather have someone who really knows HTML, CSS (and JavaScript) to implement the interface in a sustainable matter, but that person, or persons, do not have to be the folks that designed what the end-user sees.
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @07:08AM
Open URL in browser. Hit 12. Make changes to the HTML and CSS. Fiddle with it until it looks like what is needed. Copy/paste the code into your program/ide/editor/notepad++/VSC/whatever.
Wash. Rinse. Repeat.
(Score: 4, Insightful) by urza9814 on Wednesday October 03 2018, @06:19PM (20 children)
They're dead because they were all pretty awful. Always were, always will be. People who know enough to use those things properly also know enough to write the actual code; and people who need expensive tools for editing websites are probably working on websites too complex for basic WYSIWYG editors anyway.
Also damn near everything can save to HTML these days anyway. Hell, I could build a web page in my friggin' email client and save it as HTML and upload to a host. There's also no shortage on online tools...usually they're linked to purchasing some service though, because nobody will pay for a dedicated tool so they mostly serve as a form of advertising and "value-add". And it's harder to restrict it to your own service if you offer the tool as an offline download, so it's all online-only. Which shouldn't be much of a problem since it's hard to build a website if you don't have a decent internet connection to begin with.
Personally, I build websites with Notepad++ at work where I'm stuck on Windows, and Brackets or Nano when I get to use a real OS.
If you can't manage that, then go pay SquareSpace or whoever else will let you just stuff your information into one of their prepared templates.
(Score: 4, Insightful) by requerdanos on Wednesday October 03 2018, @06:36PM (12 children)
I am not sure about the "always will be" part, because I believe that it would be useful for someone to make one with something like the below features:
Does this sound about right?
(Score: 5, Funny) by bob_super on Wednesday October 03 2018, @06:45PM (1 child)
I'm sorry, but for proper modern web design, the necessary functions are:
- automated white space insertion
- automated tracking code insertion
- automated social media trackers insertion
- automated ad provider linking
- automated deletion of technical data, with optional automated replacement by useless marketing drivel and generic pictures of happy things
(Score: 2) by VLM on Wednesday October 03 2018, @07:09PM
And fifty people on twitter complaining about how we need more people of color spaces inserted into web pages
(Score: 3, Insightful) by Zinho on Wednesday October 03 2018, @07:25PM (5 children)
The problem with any WYSIWYG editor for the Web is that it has to show you something as "what you get", and there isn't a single "what": each rendering engine has its own capabilities and quirks, and browsers sharing the same rendering engine also manage to give different output in many cases. A good WYSIWYG editor would allow you to tie in several alternate rendering engines and switch between them at will. This would result in a development environment that gives a reasonable approximation of the target browsers' behavior, while also being guaranteed to get some specific quirky behavior wrong as an edge case compared to any specific browser. This assumes, of course, that your page has no backend that it needs to pull queries from in order to function; otherwise, the editor needs to simulate the web server's behavior as well.
The only real way to see "what you get" in Web development is to publish to an instance of the web server that will be hosting the page, then load it in an actual browser.
I don't mean by that to say there's no value in WYSIWYG editors as a tool; I really like your list of proposed features. HoT MetaL Pro back in the day hit several of those bullet points, and I preferred it over Frontpage and Dreamweaver (probably dating myself here). As long as I only expected it to be a decent-guess preview for what a browser might display then it was useful in that role. Just as often, I was using a simple text editor with syntax highlighting, as that did the job just as well and often faster.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 3, Insightful) by urza9814 on Wednesday October 03 2018, @08:05PM (2 children)
Which sounds like a great feature for a web IDE, but that program would no longer be WYSIWYG. The whole point of WYSIWYG is that you design what the web page should *look like*, then the editor goes and builds the code to actually force it to display that way on all reasonable/expected/supported rendering engines. Which, as you've noted, isn't really possible....and is part of the reason you end up with convoluted code and a mess of scripting libraries, because they have to find workarounds for all of the different behaviors of different browsers, including potentially reinventing new standards so they can backport the feature to an older browser (or simply not supporting the newer features at all).
It gets even worse when you consider that these programs are often built for use by *designers*. I did web dev for a designer once. Lots of "move this half an inch up" at which point I'd have to guess at their screen size/resolution/DPI, alter the spacing by some guestimate number of pixels/ems, ask them to try again, and screw with my numbers a bit more when they come back and say "That only moved three eighths of an inch" or "it didn't move at all" if the issue is a browser difference. A web developer understands that this is how the Internet is *intended* to work; a designer is going to be filing bug reports because what they saw was not what they got.
(Score: 3, Interesting) by Zinho on Wednesday October 03 2018, @08:34PM
Well said.
I believe Frontpage was explicitly catering to the desires of people who thought your first paragraph was a catalog of good ideas. Of course, Microsoft simplified the process of making their web pages look exactly like a Word document by only targeting IE, and heavily leveraging proprietary tags. Dreamweaver, in contrast, catered to the designers you mentioned in your second paragraph and their exact positioning fetish.
I think the problem with webpage editing software is that programmers aren't the target market - if you know how to write code, then you're already using a text editor to write your web pages and you're happy with it. As a result, we aren't likely to spend money on a fancy editor that does a poor job of helping us with our work. And as long as the target market is people who couldn't hand-code the page to begin with, legible/easy-to-maintain output is low on the priority list for features.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 4, Funny) by sjames on Wednesday October 03 2018, @09:24PM
A designer is a delusional being that insists on spending thousands on specially calibrated monitors and office lighting so they can produce an ad slick that looks exactly what they see on their screen. All so I can see it entirely differently anyway because I'm reading it while wearing tinted glasses on a train with dubious quality lighting or in my living room that definitely does not have calibrated lighting.
(Score: 2) by Thexalon on Wednesday October 03 2018, @08:19PM (1 child)
Except you actually mean a bunch of different browsers, because there are sometimes major differences between how different browsers behave, e.g. some of them evaluate CSS in a different priority ordering.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Zinho on Wednesday October 03 2018, @08:37PM
Exactly. Bonus points for running multiple versions of each browser in parallel in case different releases of the same browser acted differently. Lightweight virtual machines became my friend pretty quickly when they became available.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 2) by urza9814 on Wednesday October 03 2018, @07:26PM
Yeah, that sounds alright...but I'll believe it's possible to meet all of those at once as soon as I see a single piece of software which does it,..
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @08:50PM (2 children)
https://grapedrop.com [grapedrop.com] check your boxes
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @01:03AM (1 child)
went to grapedrop in Firefox, couldn't read the faint/disconnected-stroke font, useless
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @07:13AM
They have the right idea though. Forgive them for their screwed up design. Perhaps it is incentive to fix it and send them a pull request.
(Score: 3, Interesting) by VLM on Wednesday October 03 2018, @07:05PM
Interesting its sort of cross platform problem. For a good laugh try android development using android studio and its WYSIWYG editor. The fundamental problem in both cases seems to be evolution of the language is faster than evolution of the WYSIWYG although end user devices seem to render well.
In Android Studio you can use the layout editor to do a... TextView like from 2010 and it'll work, but if you want to do Material Design stuff thats only 3 or 4 years old, thats far too new to be supported, so if you want to do TextInputLayouts with TextInputEditTexts inside using androidx the layout editor changes from WYSIWYG render mode to WTF render mode. Oh well, maybe someday Android devs will have a dev environment that supports stuff written after 2013 or so. And yes I am using a beta canary (and if you don't know what that is, its kinda like sausage you better off not knowing).
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @08:30PM (2 children)
I was once turned down for a web development job because, although I could configure the web server and hand-write HTML and CSS and Javascript and PHP and Perl and run a SQL database, I had never used Dreamweaver. The manager wanted someone who knew Dreamweaver and not someone who could learn it in two weeks, so they started looking for a newbie from the local community college whose entire webdev experience was taking one course in Dreamweaver. I was unqualified.
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @08:52PM
If you don't bother with the WYSIWYG features in Dreamweaver, it's basically a text editor with a built-in FTP client. You could have just lied.
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @09:15PM
Are you me?
Similar experience, what made it more amusing in my case was that at one point in time there were 200 web servers in the UK, I ran five of them and set up 4 of the others and updated content, created graphics etc. on all of them..so one way or another in the early 90's I was responsible for 4.5% of the UK's servers and their content, to be then told no Dreamweaver experience, no job was, I suppose, a bit of a slap in the face, but I took it as more like the final sign that it was time to move on..
(Score: 2) by aclarke on Wednesday October 03 2018, @09:04PM (2 children)
Brackets has a Windows version, so you could run it there too.
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @11:55PM (1 child)
Only if his 1) boss 2) IT dept let him...
(Score: 2) by urza9814 on Thursday October 04 2018, @01:31PM
Well, technically Notepad++ isn't officially approved either, but half the company uses it...thankfully it doesn't require being actually installed since we don't have admin rights.
I do actually prefer Notepad++ over Brackets anyway though. Brackets is more or less the least bad text editor I've found for Linux. Kate is probably my favorite text editor of all time, but I don't use KDE anymore so I don't want to have all of that bloat installed and loaded just for a text editor...and when I last used it, it was crashing and having various display issues pretty frequently anyway.
(Score: 2) by bradley13 on Wednesday October 03 2018, @06:41PM (9 children)
It's actually really odd: AFAIK there are no decent tools for simple, static sites. There are all sorts of overly complicated frameworks, but for a simple, static site, directly editing the HTML and CSS is about the best solution. Sad...
Everyone is somebody else's weirdo.
(Score: 3, Interesting) by agr on Wednesday October 03 2018, @06:51PM
LibreOffice has an html editor that seems to work for simple stuff.
(Score: 2, Informative) by Anonymous Coward on Wednesday October 03 2018, @07:16PM (3 children)
I wrote a framework with 2 way databinding that allows you compose your page in markdown or HTML.
It is standards based and will render nicely all the way back to IE11 using only the polyfills it absolutely needs.
It's not WYSIWG but using modern coding tools like vscode you can crank through the design elements pretty quickly.
I called it telepathy because it's designed to be so easy to use it's like it read your mind.
If you'd like to give it a spin, the demos are here.
https://telepathic-elements.github.io/demos/index.html [github.io]
More info is here...
https://github.com/telepathic-elements/telepathic-element [github.com]
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @11:30PM (2 children)
Tried the "simple demo" got a blank page, apparently it can't handle an environment without javascript. Oh well...
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @12:18AM (1 child)
Yeah sorry,modern web development using things like WebComponents are a javascript based specification, there isn't a way to make that degrade gracefully because you're not creating a static document, you're building an application by composing elements together.
What this tool does is to allow you to specify the UI layer, as a template in whatever you prefer, HTML or Markdown, and then seamlessly bind to the controller without the need to explicitly declare bindings.
My point was more or less that with any modern code editor, I've built a handy tool to let you connect any controller to any view doing nothing more than inserting ${var} into the template where you want the controller's this.var to show up. You can get 2 way databinding for free by setting the value of the element(s) to ${var}
I apologize, if you're just building a static document, the tool isn't helpful.
But if you're trying to build an interactive application and things like Angular or React feel overly complicated, this does 99% of what they and it does it without the need to import a billion scripts. It tries to do so in an easy and natural way, convention over configuration so to speak.
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @10:03AM
I opened https://telepathic-elements.github.io/demos/simple-demo.html [github.io] in firefox. It's a blank page. Is that right? I can't see what it's meant to do from the HTML.
Same for https://telepathic-elements.github.io/demos/qr-code-demo.html [github.io]
Tried in Firefox and Palemoon on Linux.
Here's the code:
Umatrix has allowed a script to run from the host domain.
I've seen corporate sites like this. I've rung businesses on the phone to tell them that their site doesn't work.
JavaScript is enabled. The css and html files are being loaded from the host site. There is an error about loading 'Roboto' css from the googleapi fonts tracking site, but otherwise no errors. Nothing in the console.
For the hangman one I can see:
but there is no content.
What do we need to do to get these pages to work in Firefox on Linux?
(Score: 3, Interesting) by choose another one on Wednesday October 03 2018, @07:33PM (1 child)
It's not really odd actually, well at least it makes perfect sense to me.
For very simple static sites a text editor has always been the best way, and always will be, and those people who still want very simple static sites today will be the sort of people who are comfortable with a text editor and raw html - the web was, after all, never meant to be WYSIWYG. Capable text editors with fancy html modes are legion on every platform, pick any or stick with Emacs / vi as you wish.
For anything vaguely complex graphically, WYSIWYG-web is dead because the rise of mobile devices has finally beaten the clue into marketing's thick skulls that not everyone has the same damned screen size (or keyboard or...) and "the page must look pixel-for-pixel same as this photoshop proof" is clearly an insane specification. For some of us it always was clearly insane, but we were fighting against the tide of marketing PhotoShop/DreamWeaver/Flash jockeys at the start of this century. Thank Jobs those days are gone.
As for offline capability, well it isn't necessary to have everything in the editor anymore, a modern low-end laptop can easily run web servers for testing and the browsers and emulators for the clients and devices you want to test with / support. A more capable developer laptop can host VMs and emulate your production servers, but if (as is likely these days) you are going to host production on cloud instances anyway, you might as well develop on cloud instances from the start and pick up platform issues earlier.
DreamWeaver apparently still lives on, but if there is ever a time when there is a party to drive a web-is-not-*****-WYSIWYG stake through its cold undead heart, then let me know because I will gladly help wield the hammer.
(Score: 3, Funny) by MichaelDavidCrawford on Wednesday October 03 2018, @07:37PM
"We use vi, son. They use emacs."
Yes I Have No Bananas. [gofundme.com]
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @07:18AM
It's called "Dreamweaver 2"
or NVU if that floats your boat.
They work.
(Score: 2) by theluggage on Thursday October 04 2018, @12:18PM
Maybe directly editing the HTML and CSS is the best solution for a simple, static site, once you've ruled out using a CMS?
Purists would say that HTML markup should be strictly semantic, and the rendering entirely up to the browser, so any concept of WYSIWYG would be considered harmful wrongthink. Although I'd always temper that with a healthy slice of pragmatism, its not a bad aspiration as long as you don't let the perfect be the enemy of
the goodgetting any work done - and modern HTML5 lets you get slightly closer to the ideal. Using a "graphical" editor for HTML/CSS is always going to be like washing your feet with socks on.(Score: 3, Informative) by aristarchus on Wednesday October 03 2018, @06:45PM (1 child)
Bluefish [openoffice.nl]. One fish, two fish.
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @07:43PM
Seconded! Love Bluefish.
(Score: 2) by Fnord666 on Wednesday October 03 2018, @07:13PM
Dreamweaver [adobe.com]
Coffee Cup [coffeecup.com]
All of which were offline at one time. I prefer coding the HTML and CSS directly. Most of these were used because web sites that I took over administration of were coded using these tools and the code they generated was horrific to try and edit directly.
(Score: 1, Interesting) by Anonymous Coward on Wednesday October 03 2018, @07:34PM
I took a class that used BlueGriffon for WYSIWYG web page editing. I did not think it was bad.
(Score: 2) by MichaelDavidCrawford on Wednesday October 03 2018, @07:35PM
It has a fully functional thirty-day demo after which certain features are disabled but it remains completely useful.
I was using Notepad++ on Windows before my Acer bit the dust. Notepad++ has a bug in which invalid UTF-8 appears in the files from time to time; BBEdit displays them as upside-down question marks, while the W3C Validator calls them "Invalid Code Points".
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by theluggage on Wednesday October 03 2018, @07:40PM
On one side, if you don't need some sophisticated, bespoke layout, there are content management systems that can create reasonable looking websites with minimal technical skills. You get the login/comments/forum stuff that is SOP for many websites for free and editors can update content using a simple wordprocessor-like interface that is far, far simpler (and more foolproof) than any old-school WYSIWYG editor ever was. Plus, content editors don't need a copy of the software - they work online. If you really, really want to work "offline" then bundle a copy of the CMS with a standalone server - if it makes sense to implement anything in a browser then its a web editor.
On the other hand, if you don't want to work within the constraints of a CMS and want a bespoke layout, you probably didn't want to work within the constraints of a WYSIWYG web editor anyway - they were usually pretty awful as soon as the structure got non-trivial. I used DreamWeaver for a while and it wouldn't have been much use to anybody who didn't know HTML and CSS.
Nowadays, there are great editors for lovingly-hand-crafted HTML with tools like emmet for cutting down some of the tedious typing of tags, and previewing the result is a doddle.
Somewhere, between CMS and raw code, there is a little, shrinking niche for offline WYSIWYG.
Sheesh - they'll be adding a rich text editor to Soylent News soon and then even muggles will be able to shout in bold face - all will be lost.
I can't believe that nobody has completely implemented vim within Emacs... Of course, we should never have used HTML - the web should have been written in LaTeX :-)
(Score: 4, Informative) by Freeman on Wednesday October 03 2018, @08:33PM
The last one I tried and tested a bit was BlueGriffon. At the time, it seemed like it was 100% free, but now it seems like they're seriously marketing the pay us for the software aspect.
http://bluegriffon.org/ [bluegriffon.org]
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Interesting) by fyngyrz on Wednesday October 03 2018, @08:55PM (2 children)
Funny you should ask. :)
I wrote a documentation system, wtfm [ourtimelines.com], and an underlying macro language, aa_macro [ourtimelines.com], to deal efficiently and flexibly with HTML and CSS. The graphic editors I tried uniformly produced bloated, low quality and often cross-browser incompatible pages; yet writing complex HTML and CSS directly to get things done right is hugely labor intensive.
I like the CSS abstraction; it's very useful to the extent that the various browsers implement it correctly to spec. But within HTML or out in its own file, it's clumsy, far too wordy, and not all that powerful — and HTML is also extremely clumsy and wordy. Yet I wanted the power of CSS and HTML abstraction, and furthermore I wanted indexes and lists of figures and tables of contents and glossaries and parameters and stacks and pretty-printing and other such goodies. I couldn't find anything even close to the power I could imagine. So I created it myself.
Using wtfm, I can write things like this into a project file or a page's local style area...
[style p <p style="margin-left: 0">[b]</p>[lf]]]
...which, in turn, lets me write on a page...
{p This is a paragraph.}
...thereby abstracting everything about the paragraph. The language is far more capable than just that, but this simple example illustrates one way (not the only way) of getting the content as separated from both the HTML and CSS formatting as possible, which is what makes the actual writing of the documentation or website easy.
Since I write a lot of complex documentation, the benefits accrue to me constantly. Having built up an extensive library of styles in the language, I generate reasonably sized web pages that arrive quickly and with the minimum requests to the web servers, while presenting a minimal load to the client browser, and no coding on a page that doesn't actually need to be there to accomplish the goal of presenting its specific content.
Other solutions exist for extremely simple cases, such as markdown [daringfireball.net], but the ones I looked at wouldn't serve for the tasks I had to accomplish, and I needed to get work done, not hunt for solutions that might not even exist. Hence, wtfm and aa_macro. They do what I wanted done, and as I wrote them, extending, fixing and polishing them as needed is second nature to me.
I have made both available for free, and both are open source. There's a fairly steep learning curve to get at the available power beyond markdown-level usage (though that is certainly dead-simple), but for those who face the kind of workload I do and sport an at least somewhat programming-oriented mindset, it is absolutely worth the time it takes. Also, I listen carefully to the other users. These projects are very much subject to improvement over time.
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @08:22PM (1 child)
Cool, thanks for making this tool available! I'll probably spin it up next time I have a >10pg technical doc.
(Score: 2) by fyngyrz on Thursday October 04 2018, @10:11PM
Most welcome. :)
(Score: 2) by aclarke on Wednesday October 03 2018, @09:07PM (1 child)
I think the answer the author of the article is looking for (minus the "offline" requirement) is a blogging engine. They should write blogs on Medium or WordPress.
As others have mentioned here, for anything more complicated than a blog article, a WYSWIG web editor introduces more complications than it solves. The modern web uses JavaScript, CSS, responsive design, APIs and databases. If you can't put the effort into learning these technologies then you should stick to blogging. Basically it's the difference between learning how to drive a car and deciding to build one.
(Score: 3, Insightful) by choose another one on Wednesday October 03 2018, @10:29PM
Offline doesn't really mean "no networking between programs at all", it just means not connected to the rest of the internet.
It is dead easy for anyone vaguely technical to setup a locally hosted copy of Wordpress (haven't tried Medium, but probably similar), and there are zillions of step-by-step tutorials for the non-technical. You can then mess around with Wordpress plugins, themes, etc. completely safely before you upload them to your hosted site. Or just create lots of Wordpress content, completely offline.
(Score: 3, Insightful) by Anonymous Coward on Wednesday October 03 2018, @10:48PM
Is slowly dying..
Its all part of the plan tho...
(Score: 2) by Arik on Thursday October 04 2018, @04:26AM (1 child)
HTML: An editor.
CSS: Nukes from orbit.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by theluggage on Thursday October 04 2018, @12:27PM
Only if you can't get your hands on a time machine to go back and prevent it ever being created (and, hopefully, creating space for something fit-for-purpose to have been developed in its place).
Its like PHP, Wordpress and Democracy - the worst possible solutions... with the exception of any of the alternatives.
(Score: 1) by kai_h on Thursday October 04 2018, @05:32AM (1 child)
Web pages today, almost without exception, are not static HTML and CSS.
Your browser is ultimately handed a bunch of HTML, CSS and JavaScript, but the HTML your browser receives was most likely not coded by hand and never existed as one chunk of HTML until it was dynamically generated. The vast majority of sites on the web today have a database driven back end and some form of CMS at the front end.
No-one is making sites any more with hand-coded HTML and CSS (nor even with GUI driven HTML and CSS) as now days they're more commonly coded in php or ASP.NET or something else like that. In some cases, the CSS is hand-coded, or developed with a GUI based tool, but it's difficult or even impossible to preview database driven webpages in an offline editor.
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @07:23AM
I still extract data from systems and produce HTML reports that are made pretty by CSS.
What should I use?
Right now I load the result in the web browser and play with it there with dev tools
(Score: 0) by Anonymous Coward on Thursday October 04 2018, @02:38PM
I run it through WINE, set to some old Windows, 2000 was the last one which could run this obsolete shareware stuff. I use it mostly to write simple instructions for my software I publish on GPL. Its only feature not present in SeaMonkey Composer's is that it has a scriptable buttons, so I can e.g. resize a picture with one click by running ImageMagick. Except this, it is like a Composer and was designed resembling Netscape Composer (yes, Netscape) UI.
And... there is no choice, I won't write a PDF for a 6-page (A4 format, with screenshots) program description, I tried to review modern solutions and found the following:
1. Use a HTML in non-WYSIWYG editor, producing potty-quality manual as author is focused not on describing the workflow and possibilities, but on thinking is this tag properly closed.
2. Use a Mark*-editor and convert it to HTML. Requires to re-learn a new language every some time and all of them are similarly bad, being worse than even very simple HTML beginners write. If TeX would not play a toy choo-choo with their programs and file formats to render a document, it would outperform them all in popularity.
3. Use a CMS. Pay 10x more for server because it will clog a few hundred MBs of database offering support for "cute bloggy" platform. "Customizable", and you still need to buy a plugin to make it look like a program's manual, not a page offering cheap watches site for Google's bots. Hire a person who will look after its security and will port the base every now and then because an update requires to re-write content. And the page is still spitting PHP errors. In CSS included in page. Seriously, if you see PHP errors in CSS in the header, you slowly start to like these "!--MS" FrontPage/Word's tags headers.
4. Use LibreOffice, result: 30MB HTML file, all pictures base64-bundled in because LO devs think that everyone has 64GB RAM for a browser. And... Really, who invented this thing? Someone had to implement it, someone had to test it, make a PR, pull it, check it and release it, and what? 30MB HTML files are not suspicious? I have seen numerous file formats, but I have never seen a webpage with every its image base64-encoded before! Is it a failed attempt to re-invent CHM format? Or they got inspired with MS .eml, which indeed does it?