Re: Mulberry gone, now what?

Jeffrey Goldberg <nobody@xxxxxxxxxxxx> wrote in
news:11kjg6i1oobsp88@xxxxxxxxxxxxxxxxxx:

[snip]

> I'm sure that by now the vast majority of the HTML reading code in
> browsers is about reading broken HTML. Then we start getting version
> compatibility issues. It's easier for a browser to be backwards
> compatible with earlier HTML standards, but it's much harder for it to
> be backwards compatible with how its prior versions interpreted some
> particularly broken HTML document. Also for "web developers" (there'd
> be much less need for those specialists if HTML hadn't gone down this
> route) there is much more work because making an innocuous change to a
> broken document can lead to unpredictable results in how it renders.
>
> If popular browsers stopped accommodating broken HTML, then the
> problem would swiftly disappear, and writing web pages and building
> browsers would be much easier. But of course that isn't going to
> happen because any popular browser that did that would quickly cease
> to be popular.

[snip]

> Are you by any chance a web designer? I think that only someone's
> whose skills are focused on working around the problems erratic HTML
> could think that user agent sniffing in HTML is a good model of
> anything.
>
> I'm sorry to be so harsh, but for me, that kind of User Agent
> detection and action epitomizes what has gone wrong with the web.
> It's not something that I would ever want to see as a "solution" in
> protocols.

Jeffrey, everything you wrote is 100% factually correct, and I agree with
it completely. Yes, I am a web developer (among other things), and I
religiously refuse to do any browser detection. Whenever I use JavaScript
to validate form submissions, it is never without a server side
equivalent to both protect the application and provide feedback to the
user who may not be using a JavaScript-enabled browser. I've been doing
this for years, even when there was a time that browser sniffing was a
popular crutch for simply getting pages to render sensibly.

But the User-Agent string has been a clue to other, more serious,
problems, such as the poor handling of SSL, which simply can't be
tolerated in many circumstances. Users and PHBs alike bring pressure to
bear on web developers ("My son at college says the page looks different
in Firefox 1.5 beta than it does on my version of Internet Explorer 4 --
fix it!"). This has put web developers in unique position to deflect that
pressure onto browser developers, and it seems to have had some effect.
Yes, browsers have always seemed to support broken HTML, allowing for
some pretty sloppy coding. But now they also look at the DOCSTRING
(gasp!) and offer some strict modes that never existed before. At one
time, most web developers started out as content providers, and it was
rare to find one that was code-savvy (I had 10 years of programming
experience before I saw HTML, and laughed/cursed myself silly at it).
That's changed quite a bit, but there are times when I ask myself why a
content provider should even be concerned with the arcane technical
details that are necessary to create a valid page that doesn't even meet
some reasonable expectations. I fear it will be impossible to adhere to
some established philosophies about accessibility and graceful
degredation in the face of the popularity of AJAX.

But I am also a mail server administrator, and sorely miss the single
interface, zero configuration benefits inherent in HTTP user interfaces.
There are only a few basic parameters necessary to access one's mail
(IMAP/POP host, SMTP host, login, password, SSL/TLS), but can you name a
single graphical client that puts all of these settings in one simple
screen or dialog box? Or any that let you check mail on the fly without
setting up a permanent account? I won't go into the administrative
backend issues, because I understand and expect there to be some
complexity here, especially as the technology is still evolving. But
changes at the server should be transparent to end users, who will
ideally share a common experience. Mail protocols are hardly in their
infancy, so why has the HTTP user experience *seemed* to outstrip any
email UI available today, in terms of consistency and ease of use?

I'm not really suggesting that the User-Agent header be added to mail
protocols. For all I know, the W3C should take the credit for nudging
browser developers toward the center (albeit slowly). But I'm also not
sure that the strictness of mail protocols has contributed to user-
friendliness as much as it has to USENET flamewars. With the widespread
deployment of SMTP AUTH and STARTTLS, we can now move beyond some
important client issues (for example, who cares if a properly
authenticated Outlook sends an invalid HELO/EHLO?). So I guess the
question is how do we get to a more unified client/server & server/server
communication interface? Is the answer some new layer that sits on top of
HTTP, requiring only a URI (using exisiting HTTP authentication
mechanisms and SSL for encryption)?

.

Relevant Pages

  • Re: Simple question ??
    ... A web page is basically an HTML document. ... a technology that, at the most basic level, delivers HTML to a web browser. ... Internet Explorer, for example, can display Word documents, ... file format to a browser in its native state. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Toward WYSIWYG Web Page Authoring
    ... HTML and the web browser, ... Of course, even at the time of the first GUIs for developing HTML, WYSIWYG ... The best answer has emerged in the form of XML. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Toward WYSIWYG Web Page Authoring
    ... >> WYSIWYG Web page development capability on the Web - ever? ... > HTML and the web browser, ... > browser being the only web browser in existence at the time. ... The best answer has emerged in the form of XML. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Toward WYSIWYG Web Page Authoring
    ... >> HTML and the web browser, ... >> browser being the only web browser in existence at the time. ... >> WYSIWYG was already an impossible goal. ... The best answer has emerged in the form of XML. ...
    (microsoft.public.dotnet.framework.aspnet)
  • firefox file-upload broken?
    ... Don't know if this is a firefox or fedora firefox bug. ... Any web developers out there??? ... Given this html: ... View that in the browser and you will see an input text box with a "Browse" button. ...
    (Fedora)