Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms
From: David Mark on 13 Jun 2010 22:18
On Jun 13, 10:04 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/13/2010 6:50 PM, Thomas 'PointedEars' Lahn wrote:
>
>
>
>
>
> > David Mark wrote:
>
> >> Garrett Smith wrote:
> >>> David Mark wrote:
> >>>> And the whole idea is ridiculous anyway.  You obviously shouldn't use
> >>>> HTML5 yet.  The above magic spell will only help with IE.  Who knows
> >>>> what the other thousand-odd agents out there will do with these
> >>>> elements?
>
> >>> If support can be detected and a fallback alternative can be provided,
> >>> why not?
>
> >> Because you can't do that to any reasonable degree of certainty
> >> (certainly not by following the MS advice).
>
> > First of all, I have not read the article.  But if, say,
> > document.createElement("video") returns a reference to an object that has a
> > play() method, is that not enough indication for you that this element is
> > supported as suggested by the HTML 5 draft?
>
> The generalization could be mnde that where the test does that, that
> creating a VIDEO element would result in an object with a play method.
> It wouldn't detect which file types would be playable, though.
>

Neither does the AUDIO element, which is detectable but thoroughly
worthless at the moment. Less than worthless really as it is flying
false flags in many cases.
From: Garrett Smith on 14 Jun 2010 00:18
On 6/13/2010 7:17 PM, David Mark wrote:
> On Jun 13, 9:59 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>> On 6/13/2010 6:38 PM, David Mark wrote:
>>
>>> On Jun 13, 9:25 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>>>> On 6/13/2010 3:36 PM, David Mark wrote:
>>
>>>>> On Jun 13, 6:19 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>>>>>> On 6/13/2010 2:20 PM, David Mark wrote:
>>
>>>>>>> MS has finally started to recommend feature detection.

[...]

>
> For one, HTML5 isn't even finished yet. For two, see my response to
> PE regarding such detection. It's a complete waste of time at the
> moment (and likely will be for years to come).

Well CSS2.1 is not finished either.

HTML 5 is different in a few ways. Some HTML 5 features codify existing
browser behavior. They take things that work and put them into the spec.

Codified features start with the doctype and include things like
navigator.userAgent and the input.width property, both discussed
recently, plus others, such as javascript: pseudo-protocol.

Some codified features, such as document.all and a FORM's "past names
map", are inconsistent, badly designed, and have never worked right.
Specifying them won't make them any more advisable or well-designed. If
and when these features reach TR status, they may have the potential to
teach them to a developer who is unaware of their history and
programming "by the book". Such developer relying on the standard
feature may not immediately notice the problems. It seems as if these
features were specified to cater to implementors, not to the developer
who reads specifications.

Ian Hickson:
"I think it is woefully optimistic to expect any significant number of
authors to read the specification."
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0512.html

The sad thing about that is that it is probably right. So few actually
the specifications these days. When I was learning this stuff, things
like jQuery and Prototype would not have been possible. Even if the APIs
ahd been in place at that time, the performance in the browsers could
never have handled such inefficient style of coding and the file sizes
would not have been practical. The closest thing to those was Dan
Steinmann's Dynamic Duo. And in those days, standards and specifications
were something to be hoped for. Then came the DOM core and DOM 2 HTML
specs. Not without their problems, but in contrast to what was
available, miles ahead.

Dynamic Duo worked in IE4 and Netscape 4. Back then, you *couldn't*
write same code paths and expect it to run in both browsers. Not even
for image swaps because in NS4, if the image was inside of a positioned
thing, that thing became a layer and so the image was not a property of
the document, but a property of the containing layer's document
property. To swap an image required a depth-first traversal. That is
something that the previous FAQ notes explained. Still there, but not
linked any more. Interesting history lesson, and the relevance it bears
is that today, the libraries are larger than DynLayer API, yet they have
much fewer browser differences to contend with (no depth first traversal
needed for chaging an image swap). So, it is a pity that today, it is
almost a given that developers won't read the specs.

Going back to HTML 5 specifying input's width, it is not actually a new
feature but it is a new standard. The design of HTML 4 specified an
INPUT's *size* attribute as "the width of the element in pixels" for
input type="image", otherwise, for text or password inputs, the number
of characters. The feature is overloaded to do two different things and
it never worked right for character width; browsers always seemed o vary
on how wide the element would be and size="4" would not necessarily
correspond to CSS width: 4em. It turns out browsers recognize `width`
and `height` and treat it as such for certain input elemnets, so now
HTML 5 specifies a `width` attribute on INPUT type="button" and
type="image". It works as specified, though not exactly so in IE, as
shown in the recent "jquery quiz".

Another difference with HTML 5 is that it is modular. There are parts of
the specification that are further along than others. There exists the
possibility that some of it will be scaled back.

New HTML 5 features are a different story. Any new feature must be
carefully evaluated and tested and fallback handling and degradation
strategies should be considered in the initial program design.

Garrett
From: Garrett Smith on 14 Jun 2010 00:26
On 6/13/2010 7:11 PM, David Mark wrote:
> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>
> wrote:
>> David Mark wrote:
>>> Garrett Smith wrote:
>>>> David Mark wrote:

[...]

> And as I have recently written an HTML5 audio add-on to supplant my
> old plug-in based audio functions, I can say for sure that the stuff
> is not ready. Virtually all of the file formats report that they can
> "maybe" work. Virtually none but OGG's work in today's browsers.
> It's a shame the browser developers rushed into implementing that
> stuff. Their race to be first has resulted in features that are
> impossible to test. When and if the features are fixed, we'll still
> be left with a slew of iffy browsers.

I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases. It would be an eye opener and a wake
up to them. I'm always annoyed when I get a new standard feature, RTM,
and find out that they implemented it wrong.

Garrett
From: Justin Johnson on 14 Jun 2010 05:28
> I've seen Dojo's browser detection code (which they use internally for
> virtually everything, including CSS hacks).  It's all UA-based, so if
> you really want to use browser sniffing, you could do much better than
> Dojo's rendition.

That's unfortunate, especially when their own article on the subject
promotes the opposite right off the bat.

http://dojotoolkit.org/reference-guide/quickstart/browser-sniffing.html

"You should try to use capability detection (http://dev.opera.com/
articles/view/using-capability-detection/) when possible. When that is
not an option, Dojo provides a number of is variables for browser
detection, defined at runtime based on the users current browser."
From: David Mark on 14 Jun 2010 06:13
On Jun 14, 5:28 am, Justin Johnson <booleang...(a)gmail.com> wrote:
> > I've seen Dojo's browser detection code (which they use internally for
> > virtually everything, including CSS hacks).  It's all UA-based, so if
> > you really want to use browser sniffing, you could do much better than
> > Dojo's rendition.
>
> That's unfortunate, especially when their own article on the subject
> promotes the opposite right off the bat.
>
> http://dojotoolkit.org/reference-guide/quickstart/browser-sniffing.html
>
> "You should try to use capability detection (http://dev.opera.com/
> articles/view/using-capability-detection/) when possible. When that is
> not an option, Dojo provides a number of is variables for browser
> detection, defined at runtime based on the users current browser."

Yeah, lip service. They put that up fairly recently I think. For the
longest time, their authors advocated sniffing the UA string as more
"pragmatic" and "faster" than feature detection.

They have so much of it that there is very little hope of every
cleaning it up. The typical widget is crawling with isIE checks (and
still doesn't support Opera!) And when IE8 came out, they added lots
of isIE8 checks (to go with the existing isIE6 and isIE7 checks). No
wonder they are so anxious to wish IE6/7 out of existence. :)

And, of course, the previous version of Dojo (1.3) didn't work with
IE8. They told their users that 1.3 never claimed to work with IE8.
(!) I'm sure they'll say the same thing about 1.4 and IE9 (assuming
they have any users left at that point).
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms