Need to manage Firefox's XTML manipulation

HTML & CSS
1

I have a section of HTML that has several levels of nested tags. Nothing unusual, nothing I haven’t done a million times before, nothing that doesn’t validate on the W3C validator. I also know that Firefox manipulates your (X)HTML, I’ve seen the difference between Firefox’s page source view and the inspect element view. Usually not much more than rearranging the attributes in your tags unless you’re using javascript. However, this is a new one. I have a blog where I include code samples and Firefox is rewriting this HTML in the page view…


                        <code class="codeNewIndent">
                         if (firstEcDateTime.GetSeconds() != secondEcDateTime.GetSeconds())<br />
                         {<br />
                             <code class="codeNewIndent">
                             outputAreTheseTimesNotEqual = true;<br />
                             </code>
                         }<br />
                         </code>
                     }<br />
                     </code>
                 }<br />
                 </code>
             }<br />
             </code>
         }<br />
         </code>
     }<br />
     </code>
 }<br />
 catch (NullReferenceException)<br />
 {<br />
     <code class="codeNewIndent">
     outputAreTheseTimesNotEqual = false;<br />
     </code>
 }<br />

into this…


<code class="codeNewIndent">
                            if (firstEcDateTime.GetSeconds() != secondEcDateTime.GetSeconds())<br>
                            {<br>
                                <code class="codeNewIndent">
                                outputAreTheseTimesNotEqual = true;<br>
                                </code>
                            }<br>
                            </code>
                        }<br>
                        </code>
                    }<br>
                    </code>
                </code>
            </code>
        </code>
    </code>
</code>
                 }<br>
                              }<br>
                      }<br>
              }<br>
     catch (NullReferenceException)<br>

It causes all of my closing braces to collapse to the left margin instead of nesting properly. Every other browser (IE6-8, C, O, S) handles the code beautifully, and I can tell from the page source view that even FF is getting the markup properly. I’ve never seen it make a change to the markup this drastic, and I’m not sure if I want to alter valid markup to make it happy. Are there any solutions to this issue?

2

Don’t know if this is relevant, but do you need all those <code> tags? I would have thought one opening one and once closing one would be enough for code. I’m probably missing something. Anyhow, have you tried wrapping everything in <pre> tags? Also, when displaying code, you normally have to turn things like < into it character reference. <.

Sorry if I’ve missed the point of the question.

3

:slight_smile: Not at all ralph; all valid questions. This is a C# code snippet so there are no tags to escape, all the tags you see are real markup, purely for structural purposes.

I frequently only need an opening and closing set of code tags, or an additional level or two of nesting. The multiple sets of tags keep separate blocks of sample code neatly wrapped. It makes it much easier to to repeat a code snippet later in the page or to “quote” piece for a different page. I’ve also attached the CSS styling for my code samples to the code elements. Using a single style rule .computerCode code {display: block; margin-left: 1em;}, the code elements also neatly manage the styling as well – the outer code tag is indented 1em, the first level of nesting is indented another 1em for a total of 2em, etc. So they not only organize functions and internal code blocks but make it really easy to manage styling.

4

The opening and closing CODE tags don’t match to begin with. Also I saw no difference (running in my Fx browser) between ‘view source’ and the first example it didn’t change them to BR - like it sometimes does when you save XHTML files.

Obviously when viewed in the viewport (normal browser view) it wasn’t indented without the CSS but other than that, it as the same as version 1. Though the CODE is supposed to collapse multiple spaces when contained within other containers hence where PRE usually would do nicely as a wrapper to the code.

5

This is a C# code snippet so there are no tags to escape, all the tags you see are real markup, purely for structural purposes.

Then instead of mixing HTML in with C#, just use the HTML tags created specifically for this (pre + code) and everything should be shown precisely as you’ve copied it (though I’m not sure what happens with tabs made of other-than-8-spaces, but whitespace (and newlines) in general are supposed to be preserved).

You should say which version of Firefox since it is indeed known to make large changes to code when rendering…
for example there’s a nice example (in 3.6.x) where HTML5’s “new” anchors-can-wrap-blocks idea makes FF puke depending on what’s inside:

<a href=“foo”>
<div>
stuff…
</div>
</a>

In HTML4/XHTML1 this is illegal but HTML5 people chose this over “hrefs-on-everything” because that’s not backwards-compatible. Making “a” have the same state as “del” and “ins” (blocks or inlines depending on context) seemed easier to implement. Browsers are, after all, used to seeing anchors wrapped around blocks, since so many people do it, so most browsers have error rendering anyway for this. When unified error rendering for HMTL5 was written, they could easily make new rules over what happens when anchors surround a block.

But if Firefox sees
<a href=“foo”> text text

and no </a> anywhere

then it will create new opening anchors… many many many of them. I guess it’s an attempt to find the closing one further on?

Well it’ll do this if the thing the anchor wraps is one of those fancy new HTML5 elements… prolly because, 3.6.x doesn’t have an HTML5 parser so it really doesn’t know what those elements actually are, even though in CSS we’ve set them to display: block.

<a href=“foo”>
<header>
<div> blah blah… </div>
</header>
</a>
Firefox starts whipping out the “make new anchor tags” machine. Many many anchor tags.

So I can see Firefox doing what ChronicleMaster described too even if Robert doesn’t see it… may depend on the FF version. It also makes me suspect that somehow there really is a mismatch, just once, somewhere, since that’s usually what triggers FF (or anyone else even if all other browsers are doing it correctly now) to really mess with markup… its error rendering has been turned on.

I also know that Firefox manipulates your (X)HTML, I’ve seen the difference between Firefox’s page source view and the inspect element view.

You notice how <br /> was turned into <br>. So you’re sending this as HTML. I would be super curious to know what FF did if you just sent this page out as application/xhtml+xml just for the lawlz. The error rendering shouldn’t be able to kick in: either there’s an error and it dies horribly, or there isn’t and it doesn’t change anything markup-wise. Maybe in Firebug or View Generated Source all tags with closing slashes that technically shouldn’t have closing slashes (what every browser getting served “HTML” considers an error and silently ignores) are attempted to recreate “validly” or something.

But I would avoid all the gedoe and just use pre and code tags, which everyone should accept.

Or was there a good reason not to, and instead mix markup in the C# code?

6

@XhtmlCoder
I didn’t want to copy all six conditional clauses, I hate looking at “everything and the kitchen sink” code blocks in people’s posts, but the code tags do all match up and the W3C validator (and all other browsers) are happy with the markup. Didn’t mean to confuse things. PRE is interesting, see below.

Interesting. I’ve never seen pre used in anyone’s production code (least of all mine), only in “Hello World” demos of the pre tag and ASCII art; usually I don’t even remember that it exists. That would probably be significantly easier as well. Something like <code><pre>…code sample…</pre></code>? I may play around with that. Is that how you display code samples in your own web pages?

I checked it on my main computer which is running FF5.0. I checked it in a lower version (3.6 or 4.0, but I’m just guessing) with the same effect so I didn’t think too much about specifying the version.

It may depend on FF version. When I first saw it (all my initial testing is in FF btw) I assumed it was a mismatch issue, so I went over it using Notepad++'s highlighting to make sure all my opening and closing tags matched, validated it at W3C, and it’s working in all other browsers. The closing braces form a beautiful diagonal line. Hopefully, PRE or something will resolve that.

That’s a fabulous idea! Wish it was an option, so far as I know, there’s no way to get .NET pages to serve as true application/xhmtl+xml. IIS just can’t hack it.

7

IIS… it can’t be that retarded. I mean, it’s a popular server, it should be able to do mostly the same stuff Apache can :slight_smile:

Something like <code><pre>…code sample…</pre></code>?

Other way around, and yes, I use them for my code examples.

<pre> is a block element, and all it means is, preserve whitespace. Newlines are newlines, tabs should be tabs, and multiple whitespace is not rendered as a singe whitespace.

Inside <pre> you can have all sorts of neat stuff. <code> is an inline tag, and doesn’t “do” anything but says what’s inside is code.

There are other tags if applicable such as samp, var and kbd. Likely you don’t want any of those but if your code is possibly instructional for students you might want to look into the semantics of those… and someone I used to use is deprecated but I forget who so also check if they’re still in use, lawlz :slight_smile:

You can mimic syntax highlighting by either
<code class=“vars”>some var you want yellow<?code>

or
<code class=“vars”><span>somevar</span> more code more code</code>
.vars {
color: #0f0;
}
.vars span {
color: #ff0;
}
or you can have comments in blue like
<pre>…
<code>some code</code>
/some comment/
<code>more code</code>
</pre>
pre {
color: #00f;
}
pre code {
something else for what’s in code;
}

Anything you write inside a pre as HTML is PCDATA (parsed character data), meaning the browser will treat it as it always does. So inside a pre be careful with PCDATA and do &amp ; and &lt ; etc for those characters if you want them literally shown and not parsed.

Example

Another example

Just be aware pre is something you probably don’t want if your containers are small or you want this working on mobile. Pre won’t wrap text, as it’s specifically not supposed to.

Sometimes I see on WordPress pages pre’s that are too wide for the main article container. People usually use Javascript to get around that it seems, since if I turn on the pages’ JS then often I get styled and fitting code examples. Lord if I know why.

8
Off Topic:

Those are some great links, poes. Answered some questions about forms I was planning to ask. :smiley:

9

[ot]The first link, I already consider the code outdated. I need to update w/ARIA junk… it’s kinda written with mostly older JAWS in mind!
Second link is new HTML5 stuff, not all works everywhere and I’m finding bugs in Opera[/ot]

10
Off Topic:

O well, the first link is still useful. :slight_smile: Let me know when it’s updated.

11

You would think IIS can manage that, but I’ve yet to meet a .NET guy here at Sitepoint or any of the other forums I visit that thought it was possible. (To be fair, most of them look at me like I have two heads for wanting to try it in the first place.) I half believe it’s an area where MS felt it was irrelevant, and half believe that it may be included and the MS community couldn’t care less. One of the hazards of working in C#. :wink:

GAHHH!!

OK, I’ve got to start reading all the way through to the end of things. I was reading a little of your post, then implementing, then reading and implementing a little more all with a fully maximized FF5 (note the version, ;), I’m trying to be more friendly!). So I get to the bottom and trying resizing the viewport.

Horizontal scrollbar how you mock me!

sigh This is really interesting though, and a hell of a lot easier than multiple layers of code tags. My website is based around a fluid layout, and I’d hate to kill that for the code samples, but I’m going to consider it for awhile before making a decision. While this does cause problems because the lines don’t wrap, every other drawback you mentioned is also an issue using my technique, so this is pretty slick. And it entirely resolved the collapsing left margin problem in FF that started this thread. Very nifty.

PS Love your accessible form demo! Very nice work.

12

Horizontal scrollbar how you mock me!

If you know your minimum width for desktop, you can do what many others do:

Manually put breaks in your code every x-number characters, with like a red plus sign or a carriage-return symbol or something to let readers know you are continuing on the same line (O’Reilly books do this). This makes sure your pre is never too wide, though the code part will be a narrow strip then.

If this must work for mobile you may have to actually use the server side to serve up non-pre code. Or a link to plain-text version of the code (this isn’t a bad idea actually… have it as MIME text/plain).

My form demo (first example) actually is wider than my smallest possible page width, esp in FF (Opera and Chrome make the text smaller everywhere). I didn’t put in extra line breaks but possibly when I redo that page in the future I will.

When I update my accessible form demo it’ll have some aria-describedby stuff so you can have some non-form text in the form if you’re careful, and I only found out after I wrote that that NVDA jumps in and out of Forms Mode whenever it encounters non-form-controls in a form, so those users have less issue with non-form-controls in forms than, say, JAWS users.

I did get a Mac something G4? from someone so after it’s cleaned and reformatted I can maybe finally test VoiceOver.