The compatibility section is a step in right direction. But how about the more obscure browsers like iphone, netscape, aol(ie blends), etc?

In time, we’d like to include as much compatibility information as we can in the reference. What you see today is a starting point that we believed we could compile in a reasonable time frame.

I would suggest that if you know of an obscure or derivative browser that has some interesting compatibility issue (e.g. if the iPhone browser differs from Safari 3 in a significant way), you might consider leaving a comment to this effect on the relevant page of the reference. We can then roll this information into the main reference page.

Also add a link at the brief matrix to jump to the full version.

This is an excellent idea! We’ll definitely to this.

If a element is partially implemented its buggy but if its not implemented at all is it unsupported or buggy?

We use four support levels in our reference:

• None - the feature is unsupported
• Buggy - the feature has some level of support, but is buggy or non-standards-compliant
• Partial - the feature is partially supported, and the functionality that is supported is standards-compliant
• Full - the feature is fully supported according to the current W3C recommendation

One more thing. You are missing the sitepoint favicon ;)

Good catch!

Also add a link at the brief matrix to jump to the full version.

If a element is partially implemented its buggy but if its not implemented at all is it unsupported or buggy?

Keep up the good work!

Thanks for your detailed feedback!

2. If my brief look around, in the compatibility section, I found a reference to the IE 3-pixel jog. The effect was described, but there was no mention of the well-known workaround, and the bug was not given its common name making it harder to Google for more info. Information on problems is useful, but not half as useful as it would be it there were also information on solutions.

I definitely agree! Hopefully user-contributed notes on pages like this will allow us to add references to common solutions/workarounds where they are missing.

3. One problem I came across recently is the issue of legend elements not wrapping. I used this scenario as a test-case, and the CSS reference failed. The white-space property doesn’t mention this issue. I might expect to be able to look up element-specific problems indexed by the element name. Perhaps that is planned for the HTML reference your graphic hints at but it’s specifically CSS information I’m looking for, so a by-HTML-element index would be useful to support the by-CSS-property index.

Figuring out where to document issues that lie at the intersection of HTML and CSS is a tricky one. Once we have the HTML Reference in place, it should be easier to see where things like this have slipped through the cracks. We will be relying in part on notes contributed by the user community to help us with this.

Provide a launch-able sample of the snippet being expressed so the user can confirm the behavior in their own browser/blend.

This is definitely on our to-do list.

Provide a verbose view of the support browser matrix. As new browsers come on to the scene users might like to use the sample (see above) and record their findings and thus help keep the matrix relevant.

There is already a complete browser support matrix in the ‘Compatibility’ section of the page (scroll down to see it on most pages). Did you have something different in mind?

Thanks for your feedback!

I print preview in landscape, and half the “y” in apply in the first sentence is cut off. Strange behavior.

Any chance you haven’t set the ‘Scale’ drop-down menu in the Print Preview window to ‘Shrink to fit’?

It is bookmarked to probably use daily or at least when I can’t find a specific in my books from sitepoint.

Why does the internet search seem so much easier :)

Ahem… any chance of being admitted to reference.sitepoint.com ?

Thanks

Any chance? Thanks