Closed Bug 271261 Opened 20 years ago Closed 20 years ago

Revise the Mozilla Web Author FAQ

Categories

(Documentation Graveyard :: Web Developer, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: hsivonen, Assigned: hsivonen)

References

()

Details

Attachments

(1 file, 4 obsolete files)

Address text/html vs. application/xhtml+xml issues that commonly show up on
blogs. Check links. Address issues pointed out by Dr. Unclear.
Attached file XHTML issues, take 2 (obsolete) —
Attachment #166786 - Attachment is obsolete: true
Great idea!


> HTML-specific CSS exceptions do not apply. For example, the body element gets
> no special treatment.

According to the CSS specification certain properties, like 'overflow',
'background' and perhaps other get special treatment when they are applied to
certain elements.


> XPointer is supported in the fragment identifier part of the URL.

Sure? Are you aware of bug 235409? By the way, when you are talking about
fragement identifiers, shouldn't it be URI? (I may be bad informed about this
one, I base on on something I read in the past:
<http://www.pierobon.org/iis/url.htm>)

And please use a lowercase 'web'.
>According to the CSS specification certain properties, like 'overflow',
>'background' and perhaps other get special treatment when they are applied to
>certain elements.

Does Mozilla implement the special overflow behavior for HTML <body>? Is there a
test case so I don't need to write one?

>Sure? Are you aware of bug 235409? 

Whoa. Good catch. I guess the test case I was looking at was served using a
generic XML MIME type then.

>By the way, when you are talking about
>fragement identifiers, shouldn't it be URI?

Interesting point. The URL RFC seems unclear on this. Luckily now the list item
is gone. :-)

>And please use a lowercase 'web'.

"The World Wide Web" is a proper noun. Hence, the shorthand "the Web" is also a
proper noun.
Attached file XHTML issues, take 3 (obsolete) —
Attachment #166826 - Attachment is obsolete: true
> Does Mozilla implement the special overflow behavior for HTML <body>? Is there
> a test case so I don't need to write one?

I have written some test cases in the past, and I guess you can find some on
bugzilla. I'll look into that. In XHTML the property shouldn't work at all, by
the way.

From the specification:

> HTML UAs may apply the overflow property from the BODY or HTML elements to the
> viewport.

See also bug 242645 and bugs pointed from there.
Note to self: Explain why symbol/dingbat fonts "don't work".
Attached file FAQ update, take 1 (obsolete) —
Attachment #166921 - Attachment is obsolete: true
CCing Distler and Hixie for possible comments on the XHTML-related additions and
DU who suggested some other changes.
> The easiest way to make sure that the Standards mode is activated for HTML, is 
> to use this doctype declaration: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 
> 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Actually the easiest way is just:
   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">

> Is the CSS file served using text/css as the value of the Content-Type HTTP 
> header?

Mention that this is also mentioned in the JS console.

> It is also possible, although not very likely, that you are seeing a bug. The 
> CSS error handling rules require erroneous parts to be ignored rather than 
> fixed by guessing.

These two sentences are unrelated and shouldn't be grouped together like this.

> Most well-formedness constraints are enforced. (Currently Mozilla does not 
> catch character encoding errors,

As I recall, it also doesn't catch fatal namespace errors yet.
Attached file FAQ update, take 2
Thanks you for the comments.

> Actually the easiest way is just:
>    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">

With Mozilla, yes. However, that would trigger the quirks mode in Mac IE 5, so
omitting the URL would be bad cross-browser advice.

> Mention that this is also mentioned in the JS console.

Mentioned.

> These two sentences are unrelated and shouldn't be grouped together like
this.

Fixed.

> As I recall, it also doesn't catch fatal namespace errors yet.

But NS constraints are not WF constraints.
Attachment #167186 - Attachment is obsolete: true
Checked in. Pending rebuild.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Henri, how about adding a ol.toc and wrap your name and e-mail in an ADDRESS
element? See <http://www.mozilla.org/contribute/writing/markup> and
<http://www.mozilla.org/contribute/writing/guidelines>.
> how about adding a ol.toc and wrap your name and e-mail in an ADDRESS
> element?

Done. Pending site rebuild.
Nice!

->VERIFIED
Status: RESOLVED → VERIFIED
Some comments on the current content of the Mozilla Web Author FAQ

1- If you add a <br> between
//EN"
and 
"http://www.w3.org/
in the "Quirks mode and the Standards mode" section
it would reduce chances of creating/generating an horizontal scrollbar

2- Personally, I believe that the "support XSL" and both "application/xhtml+xml
versus text/html" sections (somewhat too geeky) should be removed from the FAQ
because these are definitively not issues commonly, frequently encountered in
newsgroups, forums, channels. IMO, they should not be in a FAQ; maybe these
"more-geeky" issues should be explained somewhere else.

3- Inconsistent or differential layout rendered by Mozilla is a very frequent
issue. Whole threads are created and discussed on this in newsgroups, discussion
forums: most people demand, request and expect Mozilla to render layout
identically, the same as MSIE. There are hundreds of bugzilla bugfiles with such
request, motivation. I personally do not believe that the current "Why isn’t
Mozilla rendering my page as I intended?..." section is the most efficient
content to explain why. Also, that section does not indicate any kind of
possible solution to reduce occurences of differential layout. I think that
section should try to convince, explain to readers to validate their markup code.
Using invalid markup code, non-standards markup code and malformed markup code
(incorrect syntax) are the most important reasons why webpages do not render
[roughly] the same across W3C web standards compliant browsers. So, that section
should logically lead to explain a way, to explain how to solve that
differential layout issue.

Site valet and David Hyatt blog (January 2004) have interesting quotes for such
section.

4- In the "style sheet does not work" section:
One reason I found as why my stylesheet was not working on my ISP web host
server was because their server did not support text/css MIME type; the web
server was not properly configured. And I've seen this before in newsgroups and
such warning in the javascript console. The thing is that in such case, MSIE
browser will compensate such server malconfiguration and will assume text/css
but not Gecko-based browsers.
2 link-resources I would add on this particular point:
- "External stylesheets shall also be served from the www-server with a
MIME-type of 'text/css' in its 'Content Type:' HTTP header.
You may need to negotiate with your server admin to add this MIME type to your
server if you are not able to configure the server yourself."
comp.infosystems.www.authoring.stylesheets stylesheet authoring FAQ
http://www.css.nu/faq/ciwas-aFAQ.html#QA05
- Properly configuring server MIME types
http://devedge.netscape.com/viewsource/2003/mime-types/

5- Somewhere, somehow, it should be indicated that
element_id.style.property_name = property_value;
form_control_name.value = intValue;
are not supported by Mozilla and are not valid (DOM 2 HTML, Core) ways to access
such elements. These are very frequently encountered code which break in Mozilla
but render as "expected" by MSIE. And such section should clearly indicate how
to solve such coding manners. I will address and focus on this issue myself in
bug 74952 because they are frequently encountered coding practices and they are
top reasons as why many pages do not work in Mozilla the way they work in MSIE.

My 2 cents
> 1- If you add a <br> between
> //EN"
> and 
> "http://www.w3.org/

The the site-wide style sheet makes <code> non-wrapping. Dealing with it in CSS.

> 2- Personally, I believe that the "support XSL" and both "application/xhtml+xml
> versus text/html" sections (somewhat too geeky) should be removed from the FAQ
> because these are definitively not issues commonly, frequently encountered in
> newsgroups, forums, channels. IMO, they should not be in a FAQ; maybe these
> "more-geeky" issues should be explained somewhere else.


The XSL answer was intended to the kind of developer who has discovered JAXP but
has not discovered JavaCC, SableCC or the compact syntax of Relax NG and who
shouts on the mailing lists how CSS is no good, because it is not XML, and how
XSLT is the greatest thing and how the world should adapt to XSLT. 

But OK. Removed the XSL issue.

The text/html vs. application/xhtml+xml serving issue is a permathread on blogs
that concern Web authoring.

The different treatment issue comes up over and over again when people venture
to the XML side.

The FAQ is not only for the bulk "It is not IE!!!" stuff from n.p.m.general. It
is also for frequent "geeky" issues.

> 3- Inconsistent or differential layout rendered by Mozilla is a very frequent
> issue. 

It is also a very broad topic if addressed in detail.

> I personally do not believe that the current "Why isn&#8217;t
> Mozilla rendering my page as I intended?..." section is 
> the most efficient content to explain why. 

The answer is rather abstract, because dealing with a broad topic in a
relatively succinct way requires a high level of abstraction.

> Also, that section does not indicate any kind of
> possible solution to reduce occurences of differential layout. 

Actually, it does. "Authors are supposed to communicate their intentions using
the Web standards." and "Mozilla&#8217;s Standards mode is, obviously, already
compatible with other browsers that implement the same standards reasonably
correctly."

> I think that section should try to convince, explain 
> to readers to validate their markup code.

DTD-based validation is *so* over-advertized. I guess the reason is that it is
easier to tell people to validate than to explain which errors actually matter
or, more importantly, which errors are not caught by the validator or which
SGMLism have no connection to real-life tag soup parsers.

> Using invalid markup code, non-standards markup code and malformed 
> markup code (incorrect syntax) are the most important reasons why 
> webpages do not render [roughly] the same across W3C web standards 
> compliant browsers. 

I'd put my bet on CSS issues being the most important reason--not HTML issues.

> 4- In the "style sheet does not work" section:
> One reason I found as why my stylesheet was not working on my ISP web host
> server was because their server did not support text/css MIME type;

That's already covered.

> http://www.css.nu/faq/ciwas-aFAQ.html#QA05

Adds no new info.

> http://devedge.netscape.com/viewsource/2003/mime-types/

I don't think that document adds relevant information about the CSS MIME type issue.

> 5- Somewhere, somehow, it should be indicated that
> element_id.style.property_name = property_value;
> form_control_name.value = intValue;
> are not supported by Mozilla

Good point. Added to the JS answer.
 
> DTD-based validation is *so* over-advertized. 

over-advertized: maybe. Well explained and well addressed: maybe not. Well
presented to invite, to lead amateur web authors to validate their webpages:
definitively not. In any case, Composer and Nvu softwares still have quite some
work to do here: bug 92525, bug 144604 and bug 173496.

> I guess the reason is that it is
> easier to tell people to validate than to explain which errors actually matter
> or, more importantly, which errors are not caught by the validator or which
> SGMLism have no connection to real-life tag soup parsers.
> 
> > Using invalid markup code, non-standards markup code and malformed 
> > markup code (incorrect syntax) are the most important reasons why 
> > webpages do not render [roughly] the same across W3C web standards 
> > compliant browsers. 
> 
> I'd put my bet on CSS issues being the most important reason--not HTML issues.
> 

Maybe you're right on this. In any case, I intend to submit a document on this
to mozilla.org later.

> > 4- In the "style sheet does not work" section:
> > One reason I found as why my stylesheet was not working on my ISP web host
> > server was because their server did not support text/css MIME type;
> 
> That's already covered.

You're right. I missed the place where you addressed that point. Sorry about
that. :)
 
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: