Never ending story: Jquery vs mootools - Joomla! Platform Development

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Never ending story: Jquery vs mootools
Received-SPF: pass (google.com: best guess record for domain of m...@rouvenwessling.de designates 83.169.42.93 as permitted sender) client-ip=83.169.42.93;
Subject: Re: [jplatform] Re: Never ending story: Jquery vs mootools
References: <11021392.2927.1328536415351.JavaMail.geo-discussion-forums@vbbfd4> <7717d9eb-8ae9-4ba3-9328-e294a9636685@f2g2000yqh.googlegroups.com> <74c62daa-01e2-4f66-8e79-dcb20075c...@q12g2000yqg.googlegroups.com> <4F4BC8A8.5080...@bsds.de> <f637eeec-cae6-45f8-bd7e-a38863576...@p6g2000yqi.googlegroups.com> <0907BCFF-A819-4D8E-82FD-4A8CB7514...@rouvenwessling.de> <8106c312-7965-4ff7-9d3a-be0f39dcd...@k29g2000yqc.googlegroups.com>
From: =?utf-8?Q?Rouven_We=C3=9Fling?= <m...@rouvenwessling.de>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <8106c312-7965-4ff7-9d3a-be0f39dcd...@k29g2000yqc.googlegroups.com>
Message-Id: <1C910DC4-4BF7-4CEF-9B5F-279F0A8C8...@rouvenwessling.de>
Date: Wed, 29 Feb 2012 19:02:28 +0100
To: "joomla-dev-platform@googlegroups.com" <joomla-dev-platform@googlegroups.com>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)



On 29.02.2012, at 18:23, Paladin <arlen.wal...@gmail.com> wrote:

>> Are you talking about HTML5 validation? Because otherwise I don't quite u=
nderstand how you wanna tell a validator "this is a username" without a conv=
ention. The convention in Joomla is to indicate it trough the class validate=
-username. Same for email, and others.
>=20
> I know. But there are other (and better) ways of doing that. For
> example micro-data. IIRC, the validators built-in to current browsers
> require attributes like "required" and "pattern" (for a regex that is
> to be applied), etc. Insisting on using class names only effectively
> takes good tools out of the users hands, never a Good Thing To Do.

That's what I mean by HTML5 validation. That's definitively a way I'd like t=
o go in the future but right now it's more hassle than it's worth. Too many b=
rowsers with broken or incomplete implementations - or no implementation at a=
ll in case of IE.

The nice thing about this is since we abstracted it away in the future when w=
e decide to embrace HTML5 forms this will be possible without extensions hav=
ing to change their forms.

>> The issue with HTML5 support is that we have to make up our minds (both C=
MS and Platform) what kind of output we want to support. Currently we're pre=
tty much in XHTML1 land (despite a few HTML5 templates). Would we be happy t=
o just support HTML5? That's easy, writing a patch to significantly improve J=
Form with HTML5 goodness in that case is a matter of a few hours. Or do we w=
ant to support both XHTML1 and HTML5 output? That isn't so easy anymore for J=
Form.
>=20
> Not sure how hard it actually would be, but I'll find out shortly. The
> biggest issue is the entire field rendering system needs to be
> changed, because you don't *know* ahead of time what attributes are
> going to be on the field, and the current attribute names are
> infinite, thanks to microdata. Have to admit I was flabbergasted when
> I saw the allowed attributes were hardcoded. I mean, I can understand
> how user input might need to be sanitized, but if you're sanitizing
> input from an XML file on the server, I have to think filtered input
> isn't going to be your biggest concern at the moment. ;{>}

I think JForm was designed with another approach in mind. It's not a tool  t=
hat just translates some XML 1:1 into a HTML form, it mostly abstracts away h=
ow HTML forms work. A good example of this is how the readonly and disabled a=
ttributes influence each other.

> As for HTML5 v XHTML, there's not a lot of twisting needed between the
> two for forms. Might be able to manage it with a flag and if-then
> output. A really "off the wall" approach might even be to pass the
> chunk through different XSLT's to output the various forms of markup.
> That way new markup "flavors" wouldn't require a code change, just
> another available XSLT. After all, HTML is a living document; it's
> going to be changing again and again. Unless we're saying Joomla isn't
> going to be around, I think setting output in stone like this will
> turn out to be a costly mistake.

Well for starters, how would you output the placeholder to a XHTML1 form?

An XSLT by itself probably won't cut it either, we do a lot of things in the=
 form fields besides generating the HTML code.

Best regards
Rouven
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
