Please, please, please Atlassian will you remove the option to export to PDF?
By doing so, you would fully convince us that Confluence is no longer fit for purpose, and we would have no alternative but to find a replacement product.
Granted, the new editor is pretty and slick, but we do not prize form over function.
We prepare and store all our customer-facing content in Confluence. We use a combination of the DIV macro with its CSS fine-tuning and the PDF-export stylesheet to prepare custom-branded documents that are paginated in precisely the way we require.
By removing our ability to fine-tune our documents with CSS, you are making life extremely difficult for us. If you also remove the option to export, you will successfully drive us away. Since that appears to be your intention, why prolong the process? Get it done.
As a hacker and maker, recently returned from "All Things Agile" conference (https://allthingsopen.org), Tom's comment reminds me of the previous line from "The Owner's Manifesto" that is heavily influenced by the Maker Movement.
Even though the Owner's Manifesto refers to hardware, the spirit applies. If you can't modify it to suit your purpose, someone is being evil by exerting power over your creativity and freedom.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
@Jessica Taylor You need to change your title - this is ConfluenceBLOG only. Why can't all pages in Confluence have these features? Who seriously uses blog for their every day use.
Please please please make these features active in the Confluence pages.
Atlassian Team members are employees working across the company in a wide variety of roles.
October 21, 2019 edited
Hi community!
My name is Avinoam and I’m a product manager working on the new editing experience in Confluence Cloud. I’ll do my best to answer all the editor related comments here!
“Any updates on features like anchor, sections,??”
“When are the linkable headings *actually* going to be available?
“Headings with Anchor links does not seem to work”
A: anchors will now work as link-able headers and is rolling out gradually to all customers, so if you don’t see it just yet, hang tight - it’s coming your way!
"Thanks for these updates- I am sure you are working hard getting the new experience implemented... just putting my two highest requests out there for bugs in the new experience:
1- Images to be linkable to documents or websites again
2- The include page macro to work without cutting off the copied page (and loosing some of the macro formatting)."
A: Thank you so much for this feedback!
Images with links should be coming very soon!
Thanks for the feedback, we’ll make sure to add it to our work log to fix.
"Nice to have tips in this page.
Any luck on:
Table in table
Tables in info/warning/success boxes
That would greatly enhance the look and feel of page as well as presentation of data."
"The sortable columns are a nice touch.
Will they be draggable in the near future?"
A: Great comments!
Table is table is something that we’ve deprecated in 2017 and honestly have no plans to bring back.
We’re working down the line to also support drag and drop table rows/columns but the exact timeline on that has yet to be determined.
"The current/legacy editor supports nested tables, even though Atlassian says it doesn't. Simply save a page with a table AND some text above and below the table. While viewing the saved page, copy/paste that table and text into a table cell on a page you are editing. It will create a nested table. You can then edit either the parent or child table in the normal way. And they said it couldn't be done. Sheesh. The new editor looks great, but its functionality is severely diminished since Atlassian decided to deny access to the DIV macro (with its style field to manipulate elements of the page with custom CSS). Without the content layout fine-tuning offered by the DIV macro, Confluence has lost much of its value for us."
"Interesting observation/suggestion. I checked the list of plugins and found the Page Source Editor for Confluence Cloud plug-in (is that what you meant?) Sadly, we have 30 users, so licensing would cost us $360 per year—simply to access functionality that is being withheld by Atlassian for their own ease and convenience. The cost couldn't be justified. It seems hopelessly counterproductive for Atlassian to remove client-side formatting options. CSS manipulation in the browser has zero impact on server-side code integrity. It's like the nice people at Atlassian intend to systematically choke us with a dumbed-down subset of content presentation tools to keep their lives simple. Anyone who reports that the new updates look great clearly isn't using Confluence to prepare branded documentation for product users. I'd be perfectly happy with the new editor if my documents were exclusively for internal company consumption. Heck, I'd be satisfied with a simple text editor. "
A: Super sorry to hear you feel that way! Would love to learn more about specific things you use the DIV macro and CSS customizations to achieve that you can’t with the new editor, as perhaps it may be a matter of us making sure some of the new editor features are more easily discoverable to bridge the gap.
"Would be great to have better quality video thumbnails. They are very poor at the moment."
A: We’re working rigorously to constantly improve the media experience in the new editor. Thank you for flagging this!
"OK, so this situation is now both ludicrous and indefensible.
The iframe macro has been retained in the new editor. The iframe macro offers client-side customization using both Class and Style fields.
The DIV macro has been removed, however, on the basis that its Class and Style fields potentially compromise the integrity of the host. Utter nonsense.
Atlassian, please explain how it is safe to modify an iframe with CSS while it is unsafe to retain the DIV macro that affords the same level of client-side control?
And what's with the macro: Legacy macro - do not use? If Atlassian doesn't want customers to use it, why has it been retained?"
A: Fair point! We’re working to make links and external sources a lot easier and smarter to support them natively in the new editor, either as links, cards or full on embeds - without the need for the iframe macro at some point. Yes, the current situation presents a bit of a limbo situation but we didn’t want to remove the iFrame macro before we have the functionality to fully replace it as customers still find it useful in the interim.
"Nice additions!
When will multi-cell (row/column) formatting be possible in tables? So tedious to update the alignment, color, etc for each cell one by one."
A: This actually already works! Please let us know if not on your end and we’ll look right into it!
"And, still, you choose to break backwards compatability to an age-old feature of all wikis -- creating a link to an undefined page that will be created in the future.
Boo!!!
This was a fundamental feature for top-down creation of pages, allowing the structure to be created now, and the leaves to be filled-in when needed.
All wikis have it. The ""new"" editor does not allow this to happen. That breaks a lot of decade's old work habits.
Too much fluff. Not enough basic mark-down stuff."
A: Agreed, that this is a totally valid use case. With that being said vs. many other features this has been one of the most unused in the old editor and we haven’t been getting much feedback on it in the new editor, again, in comparison to other features. With that being said, we’re monitoring all feedback closely and are trying our very best to set realistic expectations via our public roadmap.
Please reach out if you have any more questions or if I haven’t answered your question!
Avinoam - I see that the multi-cell formatting is partially supported/working.
Just tried to right align columns/rows that I selected and only the top and bottom selected row/cells had it applied.
Perhaps there are other formatting options and multi-cell selection scenarios that are not working properly. Please send this one back to the QA team ;)
@Avinoam Thank you for responding to some of the issues. I have arranged a meeting with you next Monday to explain why the removal of in-page CSS access represents a huge obstacle for our company and others that use Confluence to collaborate on and generate client-facing documentation. Since you have asked for clarification, however, I will explain here, which will provide an opportunity for you to consider the impact of removing the DIV macro.
Our Usage
We export Confluence pages to PDF format using the export option in Content Tools. The PDFs are generated from multiple Confluence pages (sometimes more than 100), and we apply a customized cover page and table of contents to each document using the Look and Feel > PDF Layout / PDF Stylesheet facilities.
We use the DIV macro in every single page to assign CSS classes to selected headings and content, and then we define the CSS classes in the PDF Stylesheet to ensure the finished document is presented with our company branding (layout, colors, etc.)
The Issues
Some of our individual pages are very long and contain many headings and subheadings. When we export to PDF, we regularly find section headings that end up being the very last piece of content on a page—with the section text itself following overleaf. That is hopelessly unprofessional, and word processors such as MS Word avoid such a situation by automatically pushing the heading onto a new page.
Since Confluence doesn't offer a PDF/paginated page-view mode, the problem is only discovered after the content is exported to PDF.
We get around the issue by inserting the heading into a DIV macro and adding the following CSS to the macro: page-break-before: always.
Before you suggest we can simply add a few carriage returns above the heading, regular carriage returns are ignored when exporting to PDF. You can force them with SHIFT + ENTER, but if you subsequently edit content earlier in the page (pushing the subsequent content down), you end up with unwanted spacing above your heading and have to go through a trial and error process of repeatedly exporting to PDF until you arrive at the desired position for the heading. One of our client-facing documents extends to more than 600 pages when exported to PDF. You cannot begin to imagine the headache we face if we need to keep repositioning the headings using SHIFT + ENTER.
As a point of note, we would consider exporting to MS Word and reformatting there, but that option is only available for single pages—not for multiple page exports.
Heading demotion is the devil's curse. Seriously. Why must that be forced on everyone? By way of reminder, when exporting a page that has a child page, heading1 titles in the child page are demoted to heading2 in the PDF output. The heading1 title in a grandchild page is demoted to heading3.
Since we have many hundreds of pages, we organize them in a hierarchy with many levels, but when they are exported to PDF, we need heading1 titles to be output as heading1 (not heading6 if the page happens to be arranged five levels below the parent). By the time you reach heading3 in a page that is nested several levels deep, the heading has disappeared altogether. It is enough to test anyone's patience.
We get around the issue by using the DIV macro to assign each heading a class that represents that heading, e.g., a heading1 title is assigned a class of heading1. In the PDF stylesheet, we simply override the hugely frustrating heading demotion by forcing all titles with the heading1 class to be output at a fixed font size, color, and position.
Sometimes, we want to precisely control the position of an item in the page. We can only do that with the in-page CSS offered by the DIV macro. We can't do it in the new editor.
Sometimes we want four or five columns in a page, or we want columns with specific widths. We can't do that with the Page Layout functionality, but we can with the Section and Column macros that have been removed from the new editor.
Sometimes we want to display a table without borders or tailor the borders on some pages to our requirements. We can do that currently by inserting the table into a DIV macro, applying a class, and setting the properties in the PDF stylesheet. We can't do it in the new editor.
We often need to include development code in our documents. Wherever we can, we use the CODE macro for that. Unfortunately, the CODE macro is indented, includes fairly large padding, and has a predetermined font-size. The result of these three fixed design elements is that our code is often made extremely difficult to read (when it includes lines that are too long for the width of the code block). In such cases, we use the DIV macro to create an identical replacement for the CODE macro. It has the same border box and the same font, but we are able to select a more suitable font size for the specific code-snippet, plus we can remove the indentation and reduce the padding. We can't do that in the new editor. Our only option is to use the PDF stylesheet to change all code blocks.
We often need to include reference material and inline comments in our documents that we don't want to appear in the customer-facing PDFs. We use the DIV macro for that by simply applying the no-print class to the DIV. There is no option for that in the new editor.
In the new editor, there are options to resize an image in the page (better than the current editor) and set its position (left, right, center, wrap left, and wrap right). For images in table cells, however, there are no such options; the image is inserted in the center, and the only option is to delete it. It is possible, however, to resize and position an image in the page and then drag it into a table cell where the size and position are maintained. That's not right. The same options should be included for images in table cells.
Additional Complications
We would rather avoid having to replace Confluence due to the huge amount of content we have authored and we also use Jira (and the two are heavily interconnected), so we have attempted to compromise with the shortcomings of the new editor.
The most serious issue for us is the unprofessional look of section headings at the bottom of a page. Seriously, that looks shockingly awful. Even a child wouldn't settle for it.
In an attempt to work around it, I tried sacrificing heading6 and using it as a method for forcing a page break. I simply entered the text "[Page Break]" in the page (as a reminder to myself) and formatted it as heading6. In the PDF stylesheet, I forced heading6 (HTML: <h6>) to be hidden and be set to "page-break-after: always".
Nothing happened. It turns out heading6 (HTML: <h6>) in the new editor must be referenced as HTML <h5> in the PDF stylesheet. Wait, what?
The workaround was, however, successful until I remembered about page demotion and...boom...it doesn't work with nested pages.
Conclusion
We wish to avoid switching to an alternative product because have invested massive amounts of time compiling material in Confluence over several years, and the product interconnects with Jira—which is useful for us.
We are simply trying to find solutions to the problems Atlassian is attempting to force on us by removing functionality that is key for us to achieve the results we require.
We do not accept the argument that allowing a user to implement client-side CSS poses a threat to the content beyond that which can be done in any half-decent editor or word processor anyway. And regular-Joe users won't even be accessing such functionality. There is also no threat to server data integrity. If you are so concerned that a user might make their content unreadable or whatever, simply apply a warning to the macro to advise the user that applying unsuitable CSS may render the page unreadable or something to that effect.
Recommendations
Return control over items in the page to the user. It appears you have removed many options for your own convenience—but to the detriment of your users. That is an unsustainable business model.
Failing that, at least retain the DIV macro and allow users to add their own CSS and class settings to tailor the presentation of content to their needs. The other deprecated macros all have their uses, but none is likely to be considered as important (and powerful) as the DIV macro.
If you really object to users presenting their own content on screen the way they want rather than the way you want, why not turn the DIV macro into a PDF CLASS macro that simply offers a single field to set a CSS class that will be applied to the content within that section when it is exported to PDF? In that way, users could still tailor the presentation of PDF output without impacting the presentation of online pages. There is no reasonable argument for why Atlassian should be opposed to that, but it would make a huge difference for customers who need to brand and customize their PDF output.
In a worst-case scenario, you should at least make it possible to export multiple Confluence pages to MS Word. At the moment, it is possible to export only a single page. The resulting output is fairly terrible, of course, but at least we would have the option to apply our own styles and formatting directly to the resulting MS Word document rather than in Confluence. If that facility were added, we wouldn't feel so backed into a corner and left considering throwing Confluence into the dumpster.
Atlassian Team members are employees working across the company in a wide variety of roles.
October 22, 2019 edited
@Kelvin A Hill I can't thank you enough for that super detailed and thoughtful response. Couldn't have asked for more! The context really helps in understanding how you're using it and the problem it poses for your business and operations.
@Avinoam I have stumbled upon more issues in the new editor that are causing significant headaches. I have updated my response, above, with those issues (they are documented as issues 6, 7, and 8). I have also updated other parts of my response, including the recommendations.
I'm having serious issues being able to link to headers in the new editing experience. When I hover over the header- I never get a link. Is anyone else having this issue?
@Catherine Snyder I am too. I wonder if it has to do if the document was created in an old format or the new one? I was really looking forward to this one.
Atlassian Team members are employees working across the company in a wide variety of roles.
October 28, 2019 edited
@Catherine Snyder@Shanta Nathwani link-able headers is rolling out gradually as we speak to all customers in the new editor. You should expect to have it in your site available by end of this week/beginning of next!
Does Atlassian plan to do anything about this issue when attempting to add the CYO macro in the new editor? It seems like a rather glaring error. Perhaps no one has noticed it. [eye-roll emoji]
87 comments