From: "Michael Haufe ("TNO")" on
On Mar 29, 4:40 pm, Hans-Georg Michna <hans-
georgNoEmailPle...(a)michna.com> wrote:

> Assuming you want to group a couple of elements in an HTML page
> for some purpose, let's say something to be done to them using
> JavaScript. Assume these elements are otherwise unrelated and
> cannot easily be found by other means, so you have to give them
> some kind of marker to be able to find them easily.
>
> How would you do that? I would give them a class attribute and a
> particular string in that attribute, and I still think this is
> pretty much what class is meant for.

Give them both an ID.
From: Garrett Smith on
Hans-Georg Michna wrote:
> On Mon, 29 Mar 2010 07:39:51 -0700 (PDT), Michael Haufe ("TNO")
> wrote:
>
>> On Mar 29, 9:33 am, Hans-Georg Michna <hans-
>> georgNoEmailPle...(a)michna.com> wrote:
>
>>> I don't doubt the general usefulness. The problem is that the
>>> different browsers do not adhere to a good, clearly defined
>>> standard and implement it well.
>>>
>>> With such problems they might have been better off doing
>>> nothing.
>
>> I would argue that it is simply too soon to rely on the API.
>
> Yes, that sounds sensible. The sad thing is that it takes at
> least 5, probably 10 years or more until almost all browsers on
> the Internet adhere to a thus improved standard.
>

Historically that has been true.

With frequent software updater and frequent releases, the time it takes
for a browser to become obsolete can decrease.

Combined with that, the trend towards intranet applications that are
designed to be functional on more than just one version of IE may cause
relatively new features to be available sooner.

> By that time we may have given up on HTML, CSS, and JavaScript
> altogether.
>
What would replace it?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on
Garrett Smith wrote:
> Hans-Georg Michna wrote:
>> On Mon, 29 Mar 2010 07:39:51 -0700 (PDT), Michael Haufe ("TNO")
>> wrote:
>>
>>> On Mar 29, 9:33 am, Hans-Georg Michna <hans-
>>> georgNoEmailPle...(a)michna.com> wrote:
>>
>>>> I don't doubt the general usefulness. The problem is that the
>>>> different browsers do not adhere to a good, clearly defined
>>>> standard and implement it well.
>>>>
>>>> With such problems they might have been better off doing
>>>> nothing.
>>
>>> I would argue that it is simply too soon to rely on the API.
>>
>> Yes, that sounds sensible. The sad thing is that it takes at
>> least 5, probably 10 years or more until almost all browsers on
>> the Internet adhere to a thus improved standard.
>>
>
> Historically that has been true.
>
> With frequent software updater and frequent releases, the time it takes
> for a browser to become obsolete can decrease.
>
> Combined with that, the trend towards intranet applications that are
> designed to be functional on more than just one version of IE may cause
> relatively new features to be available sooner.
>
>> By that time we may have given up on HTML, CSS, and JavaScript
>> altogether.
>>
> What would replace it?

When it comes to application delivery, it isn't a matter of replacement,
but of relegation to hobbyists, idealists, scientists, etc. Look what
happened with the iPhone (e.g. applications trump Web apps).

It should be patently obvious that scripts running on top of documents
is an awkward fit for applications. Combined with the incessant
bungling of the last few years (e.g. jQuery, Dojo), you can bet
something better will come along (and perhaps it already has with regard
to mobile devices). Hell, almost _anything_ would be better.
From: Thomas 'PointedEars' Lahn on
Garrett Smith wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Not only does HTML 4 explicitly allow class to be used for reasons
>>> other than CSS, it is actually used for such ulterior purposes.
>>> Microformats, for example, utilize class attribute in HTML.
>>
>> Microformats are not based on semantic markup; they are a design
>> mistake.
>
> Can you elaborate how and why?

Take this microformat example (courtesy of Wikipedia):

<div class="vcard">
<div class="fn">Joe Doe</div>
<div class="org">The Example Company</div>
<div class="tel">604-555-1234</div>
<a class="url" href="http://example.com/">http://example.com/</a>
</div>

To a HTML user agent, that is just a bunch of DIV elements with no meaning
attached. Now you might argue that the `class' attributes provide the
meaning, but the main purpose of the `class' attribute is to support
stylesheets (never trust the HTML 4.01 Specification when it starts talking
about "roles" and such), and the purpose of stylesheets is to *separate*
markup and presentation instead.

This should have been at least

<div>
<address>
<span class="fn">Joe Doe</span><br>
<span class="org">The Example Company</span><br>
<abbr>Tel.</abbr> <span class="tel">604-555-1234</span>
</address>
<a href="http://example.com/">http://example.com/</a>
</div>

where I leave the SPAN elements for possible formatting, or even better

<contact xmlns="http://example.com/contact">
<person>
<firstname>Joe</firstname>
<lastname>Doe</lastname>
</person>
<org>The Example Company</org>
<phone type="office">604-555-1234</phone>
<link url="http://example.com/" />
</contact>

But you do not get the latter, very semantic markup in HTML. However,
while you could do it with XHTML 1.1 (and an appropriate stylesheet), you
do not need to: The VCard should be generated for file download from the
same XML document (or JSON or whatever, as long as it has structure) that
the HTML code would; not vice-versa.


That Followup-To cljs was not intended, sorry;
X-Post & F'up2 ciwa.html to fix that.

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: Hans-Georg Michna on
On Mon, 29 Mar 2010 15:53:30 -0700 (PDT), Michael Haufe ("TNO")
wrote:

>On Mar 29, 4:40�pm, Hans-Georg Michna <hans-
>georgNoEmailPle...(a)michna.com> wrote:

>> Assuming you want to group a couple of elements in an HTML page
>> for some purpose, let's say something to be done to them using
>> JavaScript. Assume these elements are otherwise unrelated and
>> cannot easily be found by other means, so you have to give them
>> some kind of marker to be able to find them easily.
>>
>> How would you do that? I would give them a class attribute and a
>> particular string in that attribute, and I still think this is
>> pretty much what class is meant for.

>Give them both an ID.

Sure, that could be made to work. But since the IDs have to be
different, they don't really do what we want them to do---form a
group of elements. The JavaScript code to work on them would
have to contain a list of IDs for each grouping. That's ugly.

Hans-Georg