Re: some technical thoughts about incremental improvements to forms

Dave Raggett wrote:
> On Wed, 6 Sep 2006, Lachlan Hunt wrote:
>> Dave Raggett wrote:
>>> When people generate malformed markup they are putting themselves at 
>>> the mercy of the browser's error handling behavior (Caveat scriptor)
>>
>> That is a major interoperability concern of browsers these days...
>>
>> IMHO, while it is meant to be the author's problem, authors that fail 
>> to fix these problems make it the users' problem (when the site 
>> doesn't work in their browser), which in turn makes it the browser 
>> vendors' problem.
> 
> But even if one accepts that, it is still unrealistic to standardize 
> such browser error handling, particularly given the lack of 
> interoperability in existing implementations.

See the Parsing section of the Web Apps 1.0 spec [1].  At least 3 major 
browser vendors (Mozilla, Opera and Safari) are committed to 
implementing that algorithm which is being reverse engineered primarily 
from the 4 major browsers.

1. Where it is been shown that most browsers handle something in the 
same (or very similar) way, that behaviour has been documented.

2. Where it has been shown that all browsers handle something 
significantly differently from each other and authors aren't depending 
upon one particular method, the sanest approach possible has been 
documented.

e.g. The handling of badly nested elements fitted into this category. 
Each browser built very different DOMs and, after careful evaluation, 
the chosen algorithm was primarily based upon Safari's "adoption agency" 
approach.

3. Finally, where it has been shown that the handling of one particular 
browser (usually IE) is significantly depended upon, and other browser 
handling has proven to be incompatible with the real world, that 
specific handling has been reverse engineered and cleaned up where possible.

> The best I can suggest is to encourage people to check their markup, and 
> to avoid authoring tools that are known to produce malformed markup. It 
> isn't impossible to do so!

That simply isn't good enough.  It is an undeniable fact that many 
authors don't fix their errors and will continue to use tools that 
produce malformed markup.  It is unacceptable for browser vendors to 
have inconsistent and undefined error handling because it makes 
interoperability a nightmare in the real world and, when a page fails to 
work in one browser, the user inevitably blames the browser vendor, not 
the author.

>>>>>        <h:bind id="b1" name="fred"/>
>>>>
>>>> It doesn't have to have been bound to a namespace for IE to treat it 
>>>> as pseudo-XML
>>>
>>> My tests showed that the prefix has to be bound to a namespace URI
>>> for IE to allow CSS selectors to take effect on that element.
> 
> This is demonstrably true for IE6 and IE7 RC1. I am not sure what the 
> relevance is of the DOM view you referenced.

Never mind, I completely misread your previous statement and my test 
case was demonstrating that the namespace didn't need to be declared for 
it to be parsed as pseudo-XML, not that CSS can apply.

The only way I could get CSS to apply to elements with namespace 
prefixes was like the following, both with and without the declared 
namespace.

foo\:a { background: green; color: white; }

<foo:a>This line should have a green background.</foo:a>

Here's the working test case:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cstyle%3Efoo%5C%3Aa%20%7B%20background%3A%20green%3B%20color%3A%20white%3B%20%7D%3C/style%3E%0D%0A%3Cbody%3E%3Cfoo%3Aa%3EThis%20line%20should%20have%20a%20green%20background.%3C/foo%3Aa%3E

>> It's already confusing enough for authors as to why they can use <br 
>> />, but can't use <p /> and have it work as expected in text/html.
> 
> That's an unfortunate historical accident. If XML had come before
> HTML things would have been different, but that's too bad.

Different? Yes.  Better?  Not necessarily.  Do you have any evidence to 
suggest that XML would have been implemented any better than SGML was 
for HTML back in the early days?

>> many people (particularly Hixie) consider namespaces 
>> too complicated to use.
> 
> Maybe Hixie finds them too complicated, but namespaces are really quite 
> easy to use in practice if you follow simple guidelines,

Personally, I agree they're easy to use, but there are some confusing 
aspects about them.  I was only pointing out that there are those that 
oppose them.

>> Besides that, there is no point introducing XML syntax into HTML. As I 
>> said before, transitioning to XML through HTML is not the right 
>> approach.  If such a transition is to occur, it absolutely, 
>> positively, *must* (without a doubt) do so as *real XML* when browsers 
>> sufficiently support the languages!
> 
> How would you go about making it easier to use application/xhtml+xml 
> as a case in point?

The major barriers to doing so is IE's total lack of support and 
Firefox's current lack of support for incremental rendering of XML (bug 
18333).  Google either is or was a problem too, but I remember reading 
somewhere that support for XHTML either has been or will be added shortly.

When IE 8 is released in 1-2 years, it is expected to finally have full 
support for XHTML and, by then, Firefox will have fixed it's incremental 
rendering problems.  It's possible that Firefox may even have native 
support for XForms by then, given the current progess of the Mozilla 
XForms project.

After that happens, I'll have few technical objections to deploying 
XHTML+XForms in the real world, as XML, using scripts to simulate 
support for the XForms markup.  My only remaining concerns would be 
about providing an alternative version for users with scripts disabled 
and the minority browsers still without support for XHTML.

[1] http://www.whatwg.org/specs/web-apps/current-work/#parsing

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Wednesday, 6 September 2006 02:15:47 UTC