Gallery is inserting the following style tag into the head tag of generated pages:
<style type="text/css" media="all">@import "/imagegallery/main.php?g2_view=imageframe.CSS&g2_frames=myframe";</style>
This causes such pages to fail W3C validation, since the ampersands should be represented as ampersand-amp-semicolon HTML entities.
Also the validator complains about the
surrounding g2image imageblocks.
If there is any quick/easy way to resolve these issues that would be great.
Cheers,
Jon
Comments
Comment #1
jonbowyer commentedThe sentence "Also the validator complains about the surrounding g2image imageblocks."
should read "Also the validator complains about the DIV tag surrounding g2image imageblocks."
(I had used an actual div tag in my original post, so it was being stripped out by drupal!)
Comment #2
lvthunder commentedWhat is it about the div tag that the validator is complaining about.
Comment #3
jonbowyer commentedThis is what the validator (http://validator.w3.org/check) says about the DIV tag I mentioned:
Line 187, Column 382: document type does not allow element "div" here; missing one of "object", "ins", "del", "map", "button" start-tag.
…s ="giImageBlock g2image_float_right"><div class="one-image">(The validator highlights in red the closing angle-bracket after g2image_float_right")
"The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element."
"One possible cause for this message is that you have attempted to put a block-level element (such as "p" or "table") inside an inline element (such as "a", "span", or "font")."
Comment #4
jonbowyer commentedFore completeness, here is what it says about the unencoded ampersand in the STYLE tag within the page HEAD:
Line 10, Column 92: cannot generate system identifier for general entity "g2_frames".
…lery/main.php?g2_view=imageframe.CSS&g2_frames=myframe";</style>(The validator highlights in red the g immediately following the ampersand character)
"An entity reference was found in the document, but there is no reference by that name defined. Often this is caused by misspelling the reference name, unencoded ampersands, or by leaving off the trailing semicolon (;). The most common cause of this error is unencoded ampersands in URLs as described by the WDG in "Ampersands in URLs".
Entity references start with an ampersand (&) and end with a semicolon (;). If you want to use a literal ampersand in your document you must encode it as "
&" (even inside URLs!). Be careful to end entity references with a semicolon or your entity reference may get interpreted in connection with the following text. Also keep in mind that named entity references are case-sensitive;&Aelig;andæare different characters.If this error appears in some markup generated by PHP's session handling code, this article has explanations and solutions to your problem.
Note that in most documents, errors related to entity references will trigger up to 5 separate messages from the Validator. Usually these will all disappear when the original problem is fixed."
Comment #5
lvthunder commentedWhich doctype are you using. I believe most of the default Gallery themes use XHTML Strict, but in any case both of those errors are coming from the Imageframe module in G2.
Comment #6
jonbowyer commentedHere is my doctype and content-type info:
Are you saying I need to raise this as a bug in Gallery itself rather than as a bug with the Drupal Gallery module?
Surely the issue with the STYLE tag in the page HEAD is something that's fixable within the Drupal Gallery Module, even if the DIV tag issue is not?
Comment #7
lvthunder commentedYes that's what I'm saying. The style tag and the div problem both come straight from the imageframe module. Unless I'm wrong I don't think the gallery module changes it in any way.
Comment #8
jonbowyer commentedI hear what you're saying, however when I access my Gallery directly (i.e. not viewed from within Drupal) the imageframe CSS is put in correctly, using the
&html-entity.From the HEAD of a Gallery page when the Gallery is viewed directly (i.e. NOT within Drupal):
<link rel="stylesheet" type="text/css" href="main.php?g2_view=imageframe.CSS&g2_frames=myframe"/>Notice that the & has been correctly written out as
&.It is only when I view the Gallery embedded within Drupal that the improperly-formatted URL appears:
From the HEAD of a Drupal-Gallery page (i.e. the Gallery embedded into Drupal):
<style type="text/css" media="all">@import "/imagegallery/main.php?g2_view=imageframe.CSS&g2_frames=myframe";</style>Notice that in this case the & has been written out as a single & character which is not valid HTML.
Could you look into this and see if you can help me figure out where the problem is / how to fix it?
Cheers again,
Jon
Comment #9
lvthunder commentedOk I was wrong and misunderstood which page you were looking at, but now I know. After looking into this sadly this is by design. See this link. Maybe in Drupal 6 it will be different since they changed the way CSS was imported.
Comment #10
lvthunder commentedI also found this thread that says G2.3 fixes a lot of validation problems. Although I'm not sure if 2.3 works with the Drupal 5 version of the module. If you post a bit more code around the part that is having the issue I might be able to help though.
Comment #11
profix898 commented1. Regarding the css include for image frames read the link posted in #9 (and yes, it is not an issue in Drupal 6 anymore). If you think you need a quick workaround take a look at gallery_base.inc (line 401+) and comment that line.
2.
…s ="giImageBlock g2image_float_right"><div class="one-image">is indeed generated in the gallery module. Actually "one-image" div is returned from G2 and then wrapped with "gi*" and "g2image*", so that Drupal users can easily customize the layout. What exactly is wrong with the nested divs? Is it the class names, the div cascade or what?P.S. Thanks lvthunder for helping out on support requests ... really good to have at least one person around :)
Comment #12
jonbowyer commentedThanks both of you for providing further info on this.
From what I understand, if I "fix" this so that the HTML validates, browsers may then be unable to read the imageframe CSS anymore, so by fixing one thing I have broken something else?
Therefore editing the code near line 401 of gallery_base.inc will not be a solution, unless it can be changed so that it generates a
<link rel="stylesheet"..line instead of a<style type="text/css"..line (as is done by standalone gallery).Is this doable? or does it have to be a
<style>tag, and therefore use a non-compliant & character?Comment #13
lvthunder commentedYou could take out that line that changes it and just add the css file in your theme. That way it can be in the form you want. It's not the most elegant solution, but it should work.
Comment #14
jonbowyer commentedFYI I have solved the other error (the DIV tag error), which comes from image blocks embedded within drupal content via gallery filter tags.
It seems that these DIV tags are being put inside a P tag; which is not valid. I did not create that P tag myself, nor is it present when you edit the node content - it is being put in by the "Line break converter" which is on by default for Drupal's "Filtered HTML" input format. If I use the "Full HTML" input format or turn off the Line break converter for the Filtered HTML input format, the spurious P tags disappear and the validation errors disappear.
Here is the source HTML that is generated for that part of the page when the Line Break Converter is turned on (formatted for easy reading) with comments added to show the offending P tags:
I have now found that I can leave the Line Break Converter turned on as long as I re-arrange the order of the filters in the Input Format so that the Line Break Converter is run LAST (i.e. after the Gallery Filter) rather than before, as was happening by default.
It might be worth updating the documentation for Drupal's Gallery module to draw attention to this, as I suspect that it's an easy mistake to make and I'm not the only one who has done it.