Cookie Notifier (v4.2.6) is a Dreamweaver (DW) command application that allows web page developers to insert code into their web pages so that when the page is first viewed, a notification is displayed alerting the viewer of that web page that cookies are being used. Acceptance of cookies by the viewer is noted by setting a cookie whose name the web developer specifies. The viewer selects either Yes|No to cookies. In either case, the cookie's value is set to 0 (No) or 1 (Yes) and as long as that cookie is not deleted, this notification is no longer displayed when viewing the page. If the viewer selects No, then container elements with the classes or IDs specified by the web developer are removed completely from the document's DOM by wrapping these elements with comment tags. This is done to meet the new standards for the EU GDPR (European Union General Data Protection Regulations), which went into effect on May 25, 2018. According to these rules, the viewer of a web page must give explicit consent for cookie use, which as the referenced document states "For consent to be valid, it must be informed, specific, freely given and must constitute a real indication of the individuals wishes." By wrapping container elements which contain access to third party sites, cookie setting is delayed until the viewer has explicitly given consent. Elements in comments are not part of page's DOM. Basically this application creates a NO page, so that if the viewer makes a NO choice, all that is done is to set a small cookie to a value that indicates a No acceptance which will expire in 7 days (but this can be reset) and the layer is not shown again until after the cookie has expired. If the viewer chooses Yes, then the cookie is set to a value that indicates acceptance, expiring in one year's time (again this can be changed) before it is shown again. The layer is dismissed and a javascript routine, included with this package, is called to remove the comment tags so the elements, that were previously excluded, become part of the page's DOM. The notification layer is part of the page, continues to load on subsequent page loads but is not seen because its display is set to 'none'. This layer contains a small snippet of javascript coding which checks to see if the cookie has been set. If it has not been set yet, the layer's display is set to "block" so that it is seen, which contains code with links to routines which will set the cookie's value and expiration time based on which one is chosen.

The regulations do not require explicit approval of all cookies. Session cookies normally do not require explicit approval. It is my understanding of the regulations that the cookie used here will be acceptable for the following reasons:

  1. its value is either 0 or 1
  2. no other information on the viewer is recorded or kept

It is merely being used to indicate whether the viewer accepts or rejects cookies.

This version of the Cookie Notifier includes support for localStrorage, introduced in HTML 5, and help for users that use Goggle Analytics(GA).The latter support is solely at the discretion of the web developer, who indicates whether GA is being used on the page. In addition, the web-developer can now apply several animations to the Notification Layer, namely slideIn, slideOut, or fadeOut, all with their own animation times. fadeOut can be selected along with slideOut and if it is, will use the duration time specified for slideOut.

NOTE: If a web-page viewer has disabled cookies in their browsers, then this application does not work. This application will only allow for one notification layer with a given ID on a web page. Running this application more than once on a page and using the same layer ID, the code will remove the old layer first before proceeding to insert the new layer code, even it is exactly the same.


A user of this application normally doesn't need to have the cursor at any particular position in the document when inserting a notification layer, but on template based pages, an error message may occur. See the section Template based pages below for more information on how to handle it.

NOTE: It is strongly advised that you not use this application on a template page (.dwt). It can be used on template-based pages, because any code it inserts is place in unlocked regions of the page.

Once the application is installed in DW, it is accessed via Commands -> Goodies -> ReB Cookie Notification ..., or by clicking the icon in the Goodies panel,which opens the UI as shown in Figure 1 below. If data has already been entered before it will be used to fill in the fields in the UI.

UI for Cookie Notification App

Fig. 1a - Top portion of "Cookie Notification . . ." UI (v4.2)

UI for Cookie Notification App -- bottom

Fig. 1b - Bottom portion of "Cookie Notification . . ." UI (v4.2)

All values are completely changeable by the web developer. The default location of the layer is at the bottom of the page, but that, too, can be changed to the 'top'of the page, by selecting that value in the line Place Notification Layer. Text to be displayed in the layer is placed in the Input Text region and may also include HTML markup.

There are three ways to display for accepting/declining cookies, using buttons, by Yes|No with links, or with the checkmark and x symbols. All options result in the notice not being shown again, as long as the cookie has not been deleted. By clicking the option labeled Include BUTTONs, the fields which are grayed out will be opened and the user can select them. With this option selected, two buttons with the text specified (changeable by the user) will be inserted on either the left (default), center, or right of the page. The buttons are placed on their own line wrapped in <div></div> tags, unless a placement location, indicated by the characters |xb|, has been included in the input text, in which case they are inserted in line at that location, with the page location being ignored.

The other two options are placed at the end of the input text. Also the web developer can eliminate the separating vertical bar, by putting a check in the box (which can be accessed once this line is checked).

Data which has been entered via the UI is saved in the file rb_CNApp.js located in the directory rbcn (another reason for not deleting it). Thus if this file exists, its information is reloaded into the UI for you when this application is called.This file will be overwritten by newer versions when the application is run. Any changes the web developer has made to the notification layer markup or the associated style sheet (rbCN.css) file outside of this application are not saved. If the web developer has done this, he/she should work directly with those files and stop using this application because the files maybe overwritten. The style sheet associated with the notification layer will not be overwritten if there is a check in the check box on the line labeled CN style sheet. NOTE: if a layer with the same id as that specified in Notification Layer Id is found in the document, it is silently deleted from the page so that the web developer can insert the new layer he/she is currently working on. Do NOT delete the rbcn directory or you will have to re-enter the data in all fields. If something doesn't seem to be going according to your expectations, check that the CN style sheet box is set appropriately. Or just remove the layer and its supporting directory rbcn and just start over again.

The cookie created has a default expiration period of 365 days but that value can be changed easily by entering another value in the box.

The lines labeled Element class names and Element ID names are where the web developer puts the class names or ID names (multiple names being separated by spaces or commas) of container elements that might have information which are setting third-party cookies. The only containing elements that this application recognizes are the block level elements p and div, all other block level elements are by-passed. If the viewer has selected No to cookies these containers are removed from the document's DOM so they aren't seen, by wrapping them in a special type of comment tag. If these container elements have other classes assigned to them, they will still be removed. ID values may be prefaced with the '#'. When using classes to specify container elements, the web developer need not specify class names of children elements of a node that will be removed. With both class names and ID values, there is a short-hand naming method which involves wrapping question marks around partial matches to be made such as ?partial_name?. It is advised not to use the hash sign on ID values when using this approach. This is a very powerful method and if you are not specific enough with the partial_name you can end up removing unwanted container elements. So be very careful when using this approach. When used with ID values, the first element with an id value that matches partial_name will be removed, whereas with class names all elements with class names which match partial_name are removed.

If comment tags are contained in the content of the elements that are going to be wrapped, they are converted into a CDATA section so that <!-- comment --> becomes <![CDATA[-- comment --]]>. They are converted back to normal comment tags when the wrapping comment tags are removed.

The notification layer can be set to slideIn or slideOut by clicking the appropriate box at the bottom of the UI. The default time of this transition is set to 0.5 sec (500 ms) but this can be changed by entering a new number in the text box labeled duration. Either one or both can be selected. If fadeOut is also selected, then it will be applied during slideOut and with the time duration specified for slideOut. Any a value less than 10 entered into these boxes will be treated as being time in seconds and converted to milli-seconds when the layer is created.

Once the "OK" is clicked, the application modifies the web page to create essentially a NO page which will be served to the public and creates a minimum style sheet (rbCN.css) in the directory rbcn located where the web page is located. That style sheet is very basic (see below) and can be edited by the web developer to stylizes it to his/her liking, after this application has been run once.

    #layer_id {
        background-color: #FFF;
        position: fixed;
        left: 0px;
        pgPos: 0px;
        padding: 10px 30px;
        color: #000;
        width: 100%;
        font-family: Verdana, Arial, sans-serif;
        z-index: 999999999;

where layer_id and pgPos (top or bottom) are the values specified in the UI. The following properties can be modified by the web developer -- background-color, padding, color, and font-family. Properties such as border (top and/or bottom) can be added if desired. The z-index value is set to a high value to make sure that it lies above other elements on the page that may also have their z-index set. The width value ensures that the notification layer spans the width of the view port. If the web developer, wants to span just a part of the view port, then this value can be edited too but the positioning information needs to be adjusted too. If the check box on the line labeled CN style sheet is checked then the rbCN.css file will not be overwritten on subsequent uses of this application. As an example, the following style sheet

    #layer_id {
         background-color: #000;
         border: 1px #fff solid;
         border-radius: 5px;
         position: fixed;
         right: 15px; 
         bottom: 20px;
         padding: 0px 10px 8px 10px;
         color: #fff; 
         width: 35%;
         z-index: 999999999;
         font-family: Verdana, Arial, sans-serif;
    #layer_id input {
         background-color: #f00;
         color: #fff;
    #layer_id input:hover {
         background-color: #0fc;
         color: #000;

creates a black Notification Layer that is located in the lower right hand corner of the browser window, with red buttons that turn greenish in color when hovered over.

The markup in the layer created can be edited by the web developer, but the <script> block should remain at the end of the div container and any modifications made are not saved to the file rb_CNApp.js. This block contains the code that handles subsequent views of the page depending upon the viewer's choice for cookies.

On a normal web page, the code for handling the notification layer and its display is placed just before the closing </body> tag. On template-based pages, it is inserted just before the last <!-- InstanceEndEditable --> tag. If, as a web developer, you are not comfortable with that placement, then create another editable region on your web page that lies as close to the closing </body> tag as possible so that the code may be placed there. A possible name for it would be cookie_notification.

Layer Animation

This version introduces several animations that can be applied to the Notification Layer, slideOut, slideIn, and fadeOut. The last animation reduces the opacity of the layer from 1.0 to 0 over a time period that the user can change and can be selected in addition to slideOut. If both fadeOut and slideOut are selected, the duration of the fade is that specified for slide out. The direction of slideOut and slideIn are selectable via the radio boxes that lie below the respective slide animation labels. All of these animations are acheived using CSS3 keyframes.

Layer Dismissal

The notification layer can automatically be dismissed if no action has been taken by checking the box on the line labeled Dismiss layer if no response? and specify a time to wait in the text box that follows it, with the default value being 5 seconds. If this action has been specified, it can be canceled by clicking anywhere within the layer. The notification layer will be displayed again on the next viewing of the page. Only by clicking either acceptance or rejection, will the layer not be shown again on subsequent viewings of the page.


As Figure 1 shows, once a Notification Layer has been created on the page, the UI will open with another button, Remove so that the layer can be removed from the page. Selecting this button will also remove any links to the supporting files associated with this application. An Alert will appear, asking you if you also want to remove the directory rbcn and its files. Unless you have good reason, it is suggested that you not remove this directory. The Remove button is present only if a notification layer exists on the page. If the directory rbcn exists but there is no notification layer, the UI will open populated with the last data entered via this interface.

Template based pages

On template based pages, a user may get the following error:

Possible error message given on template based pages.

Fig. 3 - Error message on template based pages

This error occurs because the code has run into a peculiarity in DW of setting an exact insertion point on the page. If this error should occur, click OK to dismiss the alert box and then go into Code View to position your cursor just before the end of the last editable region on the page. Click the Cookie notifier icon icon in the Goodies panel to insert the layer.

Miscellaneous Items

Resetting Cookie

As long as the directory rbcn exists, cookies can be reset (actually removed) by placing a line such as the following on the page:

<a href="#" onClick="docCookies.removeItem('cookie_name_used_in_application');">Reset Cookie</a>

Removing layer

Included in the code, is a javascript routine which will set the notification layer's display to none without setting any cookie value. Include a line such as the following:

<a href="#" onClick="rbDismissLyr('lyrId');">Dismiss Layer</a>

where lyrId is the id value given to the layer.

Local storage

localStorage and sessionStorage were introduced in HTML 5 and are similar to cookies in many ways. The main difference between these two are that sessionStorage only persists as long as the window is open whereas localStorage lasts essentially forever because, unlike cookies, there is no expiration time associated with it. It remains until it is explicitly removed or cleared. localStorage has a getItem, setItem, removeItem method, which are exactly the same as those associated with cookies, except the setItem method does not require an expiration time. localStorage is supported by most modern day browsers (see this page for browser compatibility).

Because they share the same methods, every where in the previous discusstion where a reference was made to docCookies, it can be replaced with localStorage.