Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms
From: Thomas 'PointedEars' Lahn on 13 Jun 2010 21:50
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?


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Garrett Smith on 13 Jun 2010 21:59
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.

[...]

>>> var elm = document.createElement("div");
>>> elm.innerHTML = "<foo>test</foo>";
>>
>>> Tangled up with the innerHTML property a la jQuery. That's an
>>> automatic failing grade.
>>
>> That would be a different feature test.
>
> That would be a simple and direct feature test that would give a
> useful result.
>
>> The given test tests to see what
>> happens when setting innerHTML.
>
> Which is inappropriate given the stated goals of the test.
>

Goal #2:
| The second is that earlier versions of IE collapse all unknown
| elements at parse time.

>>
>> See the whatwg blog post that JDD linked to describes different in IE
>> when createElement is used:
>>
>> http://blog.whatwg.org/supporting-new-elements-in-ie
>
> Rather see my comments at the end of the cited blog. The MS
> suggestion is nothing more than an IE-centric object inference.
>

They want to know:

| The second is that earlier versions of IE collapse all unknown
| elements at parse time.

- and the test of setting innerHTML should invoke the parser. Inspecting
the result of that shows how the code was parsed.

>>
>>> 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).

I Disagree. If the goal is to see what an element can do, that can be
inspected in a test. A test for what a BUTTON's value is, for example
can be to create a button and check its `value` property. Why can't HTML
5 elements be tested using the same approach?

Garrett
From: Garrett Smith on 13 Jun 2010 22:04
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.

Garrett
From: David Mark on 13 Jun 2010 22:11
On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
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?
>

Of course, the operative word is "draft".

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.
From: David Mark on 13 Jun 2010 22:17
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.
>
> [...]
>
>
>
>
>
> >>> var elm = document.createElement("div");
> >>> elm.innerHTML = "<foo>test</foo>";
>
> >>> Tangled up with the innerHTML property a la jQuery.  That's an
> >>> automatic failing grade.
>
> >> That would be a different feature test.
>
> > That would be a simple and direct feature test that would give a
> > useful result.
>
> >> The given test tests to see what
> >> happens when setting innerHTML.
>
> > Which is inappropriate given the stated goals of the test.
>
> Goal #2:
> | The second is that earlier versions of IE collapse all unknown
> | elements at parse time.

That's not a goal, but a description of an unrelated quirk that they
used for their object inference. The only goal is to determine if the
HTML5 elements can be styled.

>
>
>
> >> See the whatwg blog post that JDD linked to describes different in IE
> >> when createElement is used:
>
> >>http://blog.whatwg.org/supporting-new-elements-in-ie
>
> > Rather see my comments at the end of the cited blog.  The MS
> > suggestion is nothing more than an IE-centric object inference.
>
> They want to know:
>
> | The second is that earlier versions of IE collapse all unknown
> | elements at parse time.

For Christ's sake. Again? See above.

>
> - and the test of setting innerHTML should invoke the parser. Inspecting
> the result of that shows how the code was parsed.

They went down the wrong road.

>
>
>
> >>> 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).
>
> I Disagree. If the goal is to see what an element can do, that can be
> inspected in a test. A test for what a BUTTON's value is, for example
> can be to create a button and check its `value` property. Why can't HTML
> 5 elements be tested using the same approach?
>

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).
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