Re: [ACTION-908] good practice for login forms

Francois Daoust wrote:
> Luca Passani wrote:
>>
>>
>> So does MWABP rejects the concept of a DDC and fully embraces the 
>> idea that multi-serving is necessary?
>
> Isn't multi-serving behind the [CAPABILITIES] best practice?
>  http://www.w3.org/TR/mobile-bp/#CAPABILITIES
> MWABP is built around this best practice.
>
> I don't understand why we would need to reject the concept of a DDC. 
> Multi-serving is recommended to improve the user experience on 
> specific classes of devices. The DDC is for the default experience.
>
> I would not use the term "necessary", but "recommended", sure!

So, before I delve into this discussion, I should make it clear that I 
was part of BPWG, I was unhappy with how the BP document was taking 
shape (hence GAP) and I am not going to start that kind of discussion 
all over again for this new MWABP. The reason I am here is to keep an 
eye on what those obscene transcoders are doing to get W3C endorsement 
to their kludges, and not to re-engage with BP discussions.
I had enough of that between 2005 and 2007.

Having said this (and since I am responsible for having started this 
discussion), I'll throw in a few comments. You can do what you want with 
them, including ignoring them completely. I don't care.

To me, the only approach that would make sense for a document like BPAWG 
is to be strong and take a position wrt multiserving vs LCD (least 
common denominator). That would enable everyone in the group to think 
much more clearly and on more solid ground.
Alternatively, you can also go for both choices (LCD and Multiserve are 
both OK), but then each practice needs to be evaluated in the context of 
whether the reader has chosen multiserving or not (basically providing 
two separate sets of practices side by side). This would make the 
document less clear.

Can W3C keep the distinction fuzzy and find practices that apply to 
both? yes, you can try, but this will invariably lead to a document with 
zero or no value for anyone, a bit like writing guidelines that apply to 
manufacturing of motorbikes and cars at one time.


>>
>> if no, where is the MWABP DDC defined?
>>
>> if yes, some of the practices listed may no longer be good practices 
>> in case of multiserving.
>
> Could you point them out?
yes

 > HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms is 
widely supported.

are you sure? I wouldn't recommend it unless you are mandating a DDR 
with information about which devices support compression mechanisms. 
Certainly not good for LCD approach

 > Minimize Automatically Issued Network Requests

yes for LCD. Not necessarily a good practice if conditions that don't 
make this a biggie are detected.

 > A single request for more data is considerably more efficient than 
several smaller requests.

not necessarily a good practice, depending on context.

 > Minimize external resources

not necessarily a good practice in case of multiserving and addressing 
certain high-end devices


 > Aggregate Static Images into a Single Composite Resource

definitely wrong, unless a DDR can tell you when this is OK. Also, this 
kind of sprite generation is very time-consuming to produce. It's in the 
domain of professionals who certainly don't need MWABP to know what they 
are doing.

 > Include Background Imaged in-line in CSS style sheets

bad practice (unless you have a DDR to tell you that background images 
are supported)

 > minimize DOM manipulation

how do you know that the device has a DOM to manipulate. The LCD 
approach should be "do not even try to manipulate the DOM", because this 
will mean errors and frustration on many devices.

 > Design for multiple interaction methods

How can I design for multiple-interaction if I don't have a DDR to tell 
me what interaction method to use?
So, is adoption of a DDR mandated?

 > Using Scripting to reduce performance

How do you know that a device has XHR()? and even if you do, which XHR() 
(standard, MS syntax1 or MS Syntax2)?
a DDR is needed. If not, you cannot say "use scripting", because it 
could fail. Also, how do you define "scripting"?

BTW, how do you inject content? can you use innerHTML() or not? do you 
need to manipulate the DOM? how do you know that a device can manipulate 
the DOM?

There is more to say. Frankly, I disagree with a lot of the practices in 
MWABP generally. As it is, the document has little practical value for 
developers. It is often misleading. It lacks the touch of someone who 
has built real mobile apps.

>>
>> Also, the spec seems to be sort of inconsistent with the CT stuff (a 
>> transcoder may wreck havoc in the Json, CSS, scripting, XHR() that go 
>> from the HTTP server to the client).
>
> There is an active discussion to have transcoders respect mobile 
> content explicitly flagged as such. I'm much in favor of it. "The best 
> practices need to be protected" is indeed the main argument in my view.

Good. I am curious to see what the result of the discussion will be.  
Please don't write a spec where everyone can read what they want in it, 
because this would increase confusion in the industry.

Luca

Received on Wednesday, 4 February 2009 23:10:47 UTC