Re: Responses to assorted ponts (was Re: New elements vs. Trident)

Hi Brad,

I think you misunderstood the entire thrust of this thread. This was  
a discussion about the design principle "degrade gracefully". My  
contention was that scripting is not a t all a good example of  
degrading gracefully. Others raised the possibility of exploiting IEs  
(limited?) support for namespaces in text/html serializations to find  
a way to degrade gracefully in IE. Unfortunately, those namespace  
complexities also pushed the issue beyond a degrade gracefully example.

It has nothing to do with one approach being simpler than another  
approach. That will all depend on the author and the scenario. I  
think many want to provide authors with recommended compatibility  
paths for legacy browsers, but that's a separate issue from degrading  
gracefully. It may be that a compatibility path provides an  
opportunity for degrading gracefully, but not in this case it seems.

Take care,
Rob

On Oct 1, 2007, at 12:23 AM, Brad Fults wrote:

> Hi Rob,
>
> A few things.
>
> On 9/17/07, Robert Burns <rob@robburns.com> wrote:
>>>> What's the difference between creating reusable compatibility
>>>> scripts for IE or creating reusable      compatibility scripts to
>>>> work around interoperability issues? They both seem equally
>>>> convoluted enough to be excluded as examples of degrades
>>>> gracefully. The difference is that the interoperability issues
>>>> only hit authors that need to do specific DOM manipulation of
>>>> those elements which much of what I see in HTML5 is meant to avoid
>>>> the need for that.
>>>
>>> It's pretty easy to write a script that reparents the siblings of a
>>> <figure> void element inside it up until the matching </figure>
>>> element. It has been done in the past for the <abbr> element so we
>>> know it is doable.
>>
>> Try using that fix in a browser without javascript though.
>
> I'm pretty sure the point here was that most if not all modern
> browsers other than IE handle unknown elements in a way that would not
> require a script workaround. Therefore any modern user agent that does
> not support scripting (as you mention) will not have to worry about
> depending on a script-based workaround. Relying on such a workaround
> for only older versions of IE limits the scope (and time period) of
> the fix and is objectively the solution with the least hassle from the
> perspective of language designers.
>
>>> It's pretty hard to write a single script that will treat elements
>>> named "html:figure" as if they were named "figure" under all
>>> circumstances in non-IE browsers. I would venture to say it is
>>> impossible. For example, I can't think of a way to make tagName
>>> return "FIGURE" in Safari for all "html:figure" elements.
>>
>> If its a canonical prefix its very simple to transform a string
>> tagname into another string without the "html:" prefix. It is not
>> impossible.
>
> The issue raised here with using a new element called html:figure is
> that other technologies inextricably linked to HTML such as the DOM
> cannot and should not be required to compensate for inconsistent
> language design on the part of HTML.
>
> It is not a feasible or defensible position to require all HTML
> authors to use an additional scripting framework to provide
> abstractions on top of the standard DOM either, so it should be clear
> why this solution is untenable from this perspective.
>
>>> It's also  possible to do different script-based fallback for non-
>>> IE user agents, by replacing all "html:figure" elements in the DOM
>>> with "figure" elements. However, there are many existing user
>>> agents and other tools that would support "figure" just fine, but
>>> which don't do scripting at all. Whereas IE is the only user agent
>>> I know of that can't properly handle parsing of unknown elements.
>>> So it makes more sense to do the compatibility hack for the one
>>> exception rather than for the common case.
>>
>> Again, you're just spinning this. IE is a browser many authors need
>> to target. You can count up the number of UAs, but it still doesn't
>> change the fact that IE is the majority of all UAs most users have in
>> most authoring situations.
>
> The issue you touch on here is an important one so I want to make sure
> we're clear on this point. HTML 5 is not being designed for any
> specific browser or version, though consideration is being given to
> the current state of browser affairs during the design phase. This
> distinction is of monumental importance and I think it will become
> clear as to why with a simple hypothetical example.
>
> When the intrepid W3C contributors of the future are working on HTML
> 9.0 and Microsoft has just shipped IE 2052 with full support for HTML
> 8.0, some naïve developer will dare pose the question:
>
>     Dearest HTML WG,
>
>     Why is it that only a select few elements in HTML have their names
> prefixed with "html:"
>     for no apparent reason?
>
>     -- Puzzled Pete
>
> Imagine the group's embarrassment when the chair replies,
>
>     Pete,
>
>     Way back in 2007 when the WG was designing HTML 5.0, somehow it
> was decided that
>     the support (or lack thereof) of a previous version of IE (6.0!)
> would dictate the naming of
>     these select few elements, introducing this inconsistency and
> contributing to an infinite
>     amount of confusion up until this day. I humbly apologize for this
> on behalf of the WG.
>
>     -- HTML WG Chair
>
> In other words, Rob, while support from the existing pool of browsers
> should be taken into consideration when designing HTML 5, they should
> by no means overtake goals of central importance like consistency or
> comprehensibility; especially when the aforementioned browser(s) can
> be supported with little effort on an author's part for a finite
> period of time.
>
>>> Using new elements with their plain names is an approach that works
>>> with no fixup needed in Safari, Opera, Firefox, Konqueror, or one
>>> of the many browsers and other applications sharing their engines.
>>> Simple script-based fixup makes it also work in IE and browsers
>>> that share its engine. I'm looking for the simplest solution to
>>> serving content with new elements to the current generation of
>>> browsers and other user agents. I haven't heard a simpler one so  
>>> far.
>>
>> Again, you're counting browsers or rendering engines, but that's only
>> part of the issue. The other part being swept under the rug is that
>> IEs by far the majority browser that's going to effect many users and
>> authors.
>
> A finer point on this business of current browser support is that the
> HTML WG expects HTML authors to be writing standard HTML for
> consumption by a plethora of user agents, never just from the popular
> browser du jour. IE's current market share, as far as I am concerned,
> is coincidental and of little consequence to HTML authors, as they
> should not be concerned with "targeting" IE, but rather with making
> their content as ubiquitous as possible.
>
> Language design decisions that support this line of thought should be
> preferred to those that rely on any time-dependent statistic when
> those decisions don't entail disastrous ignorance of significant
> segments of the population (this decision doesn't, as there is a
> workaround for IE).
>
>>> Writing <html:figure> ... </html:figure> is not a natural way to
>>> write HTML. It's not even a natural way to write XHTML, where a
>>> default namespace declaration is most commonly used.
>>
>> I didn't know writing HTML was a natural thing. Adding a four-letter
>> prefix does not make the markup convoluted.  Adding a xmlns binding
>> is also not convoluted. We might as well just say anything that's not
>> plain text is convoluted.
>
> This may be the most telling point yet. If you were not aware that
> writing HTML could be a natural thing, you have (probably unwittingly)
> ignored a large segment of the authoring population. Unlike machine
> code or proprietary XML schemas, HTML is a language of the people that
> is meant to be simple, effective and comprehensible to the common web
> author. Most importantly, it should be possible to write HTML without
> referencing a thick manual so authors can concentrate primarily on
> what concerns them most: content.
>
> The design of the language must reflect these goals and not make any
> assumptions as to the authoring habits employed in its construction,
> least of all those that abstract away the consistency or uniformity of
> the syntax.
>
> In answer to your claim: adding a four-letter prefix most certainly
> does introduce unnecessary obstacles to the consistency and
> comprehensibility of the language; something that would require an
> enormous mountain of good, defensible reasons behind it, where this
> proposal lacks a single one.
>
> Best,
>
> -- 
> Brad Fults

Received on Monday, 1 October 2007 21:00:28 UTC