305106 - Mozilla Store uses unsemantic and/or invalid mark-up (does not validate/invalid HTML/fails validation)

Status: RESOLVED WONTFIX

(Websites :: store.mozilla.org, defect)

Description

[Grey Nicholson (they/them)]

Comment 1

[Grey Nicholson (they/them)]

This applies to the Americas shop ( http://validator.w3.org/check?uri=http://store.mozilla.org/default.php ), the non-Americas shop ( http://validator.w3.org/check?uri=http://intlstore.mozilla.org/ ) and the location-agnostic landing page ( http://validator.w3.org/check?uri=http://store.mozilla.org/ ).

Also, while we're on the topic of bad mark-up, both shops use table elements for content that isn't tabular data. This is generally considered to be the primary example of unsemantic use of HTML and general bad web practice.

Upgrading severity to major, since Mozilla is "An advocate for standards on the Net" ( https://www.mozilla.org/about/ ); also reassigning to default in case that's changed in the last nine months.

Comment 2

[Marcia Knous [:marcia]]

Email with link to bug information has been sent to both stores.

Comment 3

[Gérard Talbot]

Please visit bug 326708 for details, specifics and explicit issues and matters which rightly deserve to be fixed, corrected and improved. Both bug 326708 and this bug 305106 are now blocking bug 151557.

Marcia, I hope both bug 326708 and bug 305106 can be fixed soon. If I could help fix those, I would.

"we're making one of the most standards-compliant browsers around. It would be bad show to have an incompliant website."
mozilla.org Documentation Style Guide on validation
http://www.mozilla.org/contribute/writing/guidelines#validation

Comment 4

[Gérard Talbot]

Blocking 151557

Comment 6

[Gérard Talbot]

I'm voting for this bug mostly because 

1- under normal circumstances, a lot of us would have fixed this bug a long time ago 
2- this bug has first been reported more than 18 months ago
3- this bug has been reported by others before
4- this bug should be easy to fix for anyone (and professionals) who are supposed/ought to be able to create well-designed and web-standards-compliant webpages!

Gérard

Comment 7

[Gérard Talbot]

12 months after creating+opening bug 326708 and this bug, nothing basically has changed:

Softwares & Guides; CDs and books
http://store.mozilla.org/category.asp?catid=1 : 83 errors:
http://validator.w3.org/check?uri=http%3A%2F%2Fstore.mozilla.org%2Fcategory.asp%3Fcatid%3D1&charset=%28detect+automatically%29&doctype=Inline&verbose=1

Clothing; T-shirts, polos, caps, and fleece
http://store.mozilla.org/category.asp?catid=2 : 284 errors:
http://validator.w3.org/check?uri=http%3A%2F%2Fstore.mozilla.org%2Fcategory.asp%3Fcatid%3D2&charset=%28detect+automatically%29&doctype=Inline&verbose=1

Other merchandise
http://store.mozilla.org/category.asp?catid=3 : 102 errors:
http://validator.w3.org/check?uri=http%3A%2F%2Fstore.mozilla.org%2Fcategory.asp%3Fcatid%3D3&charset=%28detect+automatically%29&doctype=Inline&verbose=1

Comment 8

[John Slater]

Hi Mike. This is one of the larger Mozilla Store bugs out there. There seem to be some validation issues with the store site...since we are a company that strongly supports web standards and the open web, we'd like to have the store site be as valid as possible.

Using http://validator.w3.org/ lists them -- many are syntax, but there are some bigger issues as well. Take a look and let us know what you think.

Thanks,
John

Comment 9

[Pascal Chevrel:pascalc]

http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fstore.mozilla.org%2F

The new store doesn't even have a doctype which is the base of any HTML document, the previous store had bad markup but had a doctype so this is a regression in code quality (and the previous code was already bad).

The code should be valid XHTML Strict with semantic markup, please fix it before you open the international store. Why do we have onserverclick attributes ? Never heard of it before, non standard, AFAIK it's not supported by Gecko and the only documentation I found about it is in MSDN...

Comment 10

[Tristan Nitot]

Pascal: I do agree that we have to practice what we preach. But asking for XHTML 1.0 Strict is a bit over the top, even if it's my personal preference. Let's say that any html version that validates is good. HTML 4.1 Transitional would be better than the current tag soup. Aiming at semantic markup and valid and HTML 4.1  Strict would be great.

Comment 11

[Gérard Talbot]

"All new pages should validate as HTML 4.01 Strict using the W3C Validator. (...)"
mozilla.org Documentation Style Guide
http://www.mozilla.org/contribute/writing/guidelines#validation

As far as I'm concerned, everything that needs to be fixed at Mozilla Store has been specified, identified and listed in this bug and in bug 326708.
Thank you for voting for this bug.

Comment 12

[Gérard Talbot]

The current stylesheet also fails validation
http://jigsaw.w3.org/css-validator/validator?uri=http://store.mozilla.org/css/home.css

Font-size is defined, specified in pixels ("px") 33 times in 
http://store.mozilla.org/css/home.css
and not in relative units (em or %). So, this will create well-known accessibility problems in browsers and other user agents.

"Units: avoid absolute length units for screen display
 Do not specify the font-size in pt, or other absolute length units for screen stylesheets. They render inconsistently across platforms and can't be resized by the User Agent (e.g browser). Keep the usage of such units for styling on media with fixed and known physical properties (e.g print).
 Use relative length units such as percent or (better) em (...)"
W3C Quality Assurance Tips for webmasters:
Care with font-size
http://www.w3.org/QA/Tips/font-size

font-size:10px;
is exactly the kind of font-size that users (over 40 years old or with low/lower vision) will want to increase.

Comment 13

[Gérard Talbot]

There are *many* other issues with the http://store.mozilla.org/css/home.css
which regards to:
- use and relying on default values, 
- proper usage of CSS inheritance (e.g.: #container declares {font-family:
verdana;} so there is no need to redeclare font-family: verdana 9 other times), 
- over-excessively qualified selectors: 
(e.g.:#header ul li:hover.tabon a{color:#003399;})
- over-qualified class rules, 
- over-qualified id rules, (at least 37 occurences)
- over-defining, over-declaring, over-coding the stylesheet to workaround the
side effects of an over-coded-to-the-pixel-constained layout
- CSS code optimization to make it streamlined, efficient, performant

Comment 14

[Gérard Talbot]

Mike, 

1- Why did you add a Null End Tag to all <img>, <br> and <input> in many store.mozilla.org webpages? The HTML validator was reporting each and every instances of such code with this explanation:
"The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HMTL 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HMTL 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML."

2- I can understand removing borders around clickable images (although I would never do/recommend that) but removing borders around images which do not have borders anyway is over-kill, unnecessary. E.g. in store.mozilla.org at line 36:
<div id="toptiernav">
<ul>
        <li><img src="./images/header/cart.png" alt="" style="border:0"/></li>

On top of that, img {border:0} is declared redundantly anyway in
http://store.mozilla.org/css/home.css


3- In http://store.mozilla.org/docs/scripts.js
function popUpview(url)
{
  sealWin=window.open(url,"win",'toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=1,resizable=1,width=475,height=600,left=0,top=0');
}

Why do you try to remove the address/location bar and the status bar when MSIE 6 SP2, MSIE 7 and Firefox 3 force the presence of the status bar in secondary windows and when Firefox 3 will force the presence/rendering of the location/address bar (MSIE 7 already forces the presence of the location bar). 
Bug 337344: Change default dom.disable_window_open_feature.location to true
All browsers now try to render those toolbars as anti-phishing measures or counter-address-forgeing/phishing measures.

Same thing for
function helpwin(url) 

4- vertical-align only applies to inline elements and to table cells: so, trying to apply a vertical-align declaration to <ul>, <li> elements and to <div id='sortby'> must be ignored by browsers (there is a bug on this in MSIE 7), therefore should be removed from the home.css stylesheet.

5- I still think there is over-coding, over-declaring in the home.css stylesheet: 350 css declarations and some 130 css rules is a lot for not so complex webpages. CSS code compression certainly looks possible in home.css; inheritance and browser default values may not have been fully used (take advantage of such capability with CSS code).

Comment 15

[Grey Nicholson (they/them)]

This isn't fixed yet. For example:

1. The footer uses “   |   ” to separate list items, rather than actually making them list items.
2. Some links use “click here” as link text, which is incorrect unless “click here” is a good description of the destination.
3. The main page header contains no text (just an image with an empty alt attribute) and isn't inside an h1 element.
4. Several other links contain no text and so are virtually unusable with images and CSS off.

(These are just a few quick observations based on the front page.) Inline styles should probably be avoided as well.

Comment 16

[Mike Bommarito]

Thank you for the input.

Comment 17

[Gérard Talbot]

6. In the left navigation pane, images are used to display the words, items. E.g.:
http://store.mozilla.org/images/leftnav/mozilla-store-nav-shirt-off.jpg
is the T-Shirt.
There are many problems with this kind of coding practice:
- images are usually at least 100 times (usually more) bigger in file size than text: here, "T-Shirt" text would be 7 bytes while its image is 1303 bytes; many images of text therefore means many KB wasted
- images increase number of HTTP requests to the server: if you have 10 images, then there will be at least 11 http requests to the server. This contributes to slowing down the rendering of page
- images can not be enlarged while text can be increased with Ctrl++
- images of text can not be "operated" by software like text can: translation, search engines, inline translation, copying text, etc.
- images of text is actually less accessible than text
- etc. "Forgeting the purpose of text" http://www.webpagesthatsuck.com/biggest-mistakes-in-web-design-1995-2015.html
"Text as image"
http://www.456bereastreet.com/archive/200408/web_development_mistakes_redux/

7. There are still webpages that do not pass markup validation
http://validator.w3.org/check?uri=http%3A%2F%2Fstore.mozilla.org%2Fproduct.php%3Fcode%3DMZ23012%26catid%3D9&charset=%28detect+automatically%29&doctype=Inline&group=0
http://validator.w3.org/check?uri=http://store.mozilla.org/popups/view.php?code=MZ23012

8. "javascript:" pseudo-links must be avoided everywhere so that they do not interfere with users.
See section 7.2.1 of
http://developer.mozilla.org/en/docs/DOM:window.open

E.g.:
at line 52 of http://store.mozilla.org/product.php?code=MZ23012&catid=9
		<a title="Enlarge" href="javascript:popUpview('popups/view.php?code=MZ23012')">	

can be better replaced with

<a title="Enlarge" href="popups/view.php?code=MZ23012" onclick="popUpview(this.href); return false;">

The use of secondary windows is also a debattable decision now that almost all modern browsers are tab-capable browsers.

Comment 18

[Grey Nicholson (they/them)]

re: comment 17, Gérard's point 6: personally, I'd be satisfied with appropriate alt attributes. Images being unresizeable is the browser's fault (and is fixed for Fx 3). I'm quite happy to waste bandwidth in return for extra sexiness.

Generally, let's avoid swamping this bug with lots of specific examples. We could discuss those in the forums or newsgroups and report back with a synopsis of the most severe general problems.

Comment 19

[Gérard Talbot]

Greg,

Can we all agree to have the 7 other points addressed and your 4 points addressed? I do not wish to discuss each point any further as they are all obvious and common sense improvements, better coding practices to do to the webpages.

"javascript:" pseudo-protocols links are reported as invalid by W3C link checker and are bad coding practice: the links won't even work if/when javascript support is disabled/inexistent. "javascript:" pseudo-protocols links are always considered bad coding practices unless you want to create a bookmarklet.

font-size expressed in "px" unit can be easily replaced, improved for the benefits of anyone/everyone.

vertical-align can be removed where and when it is not in appropriate CSS code: instead of being download, parsed and then ignored, it should be removed from the code.

"click here" is bad practice, lots of consecutive   is often poor, weak semantic, etc.

We don't have to discuss these points. We shouldn't have to discuss these points. Some of them have already been mentioned in the mozilla.org markup and style guidelines.

Comment 20

[Grey Nicholson (they/them)]

(In reply to comment #19)
> Can we all agree to have the 7 other points addressed and your 4 points
> addressed? I do not wish to discuss each point any further as they are all
> obvious and common sense improvements, better coding practices to do to the
> webpages.

Yes.

> We don't have to discuss these points. We shouldn't have to discuss these
> points. Some of them have already been mentioned in the mozilla.org markup and
> style guidelines.

I agree. It's *because* there are so many easily-pointed-out examples of bad practice that I want to keep those out of this bug report - I want to avoid a deluge of individual examples bloating the report and making it too intimidating and unwieldy for the person/people trying to fix this.

And, if every time this bug gets resolved we come along and say “you missed a bit!” (like I just did), no-one will want to bother trying to fix this.

This is quite a general report for a large problem. I think it would be better to break it down into several new bugs, each of which describes one specific bad practice (not just one *instance* of that practice) and how it should be fixed; all of those bugs should block this one.

To that end, I've started a thread at MozillaZine Forums so we can inventory all of the problems without degrading the signal-to-noise ratio here: http://forums.mozillazine.org/viewtopic.php?t=593983

(I'd also like to emphasise that being properly semantic is the main goal; validation is mainly a prerequisite for that.)

Comment 21

[Gérard Talbot]

Mike Bommarito, 

What is happening with this bug? Any progress?

Comment 22

[Kohei Yoshino [:kohei]]

store.mozilla.org has been closed.