Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Henri Sivonen]

On Mar 21, 2005, at 16:54, Matthew Raymond wrote:
   Actually, now that I think about it, why do we need to have a spec 
saying that it's not depreciated or that it should be non-trivial to 
deactivate if the banks are going to blackmail UAs to support it? Why 
support blackmail through our specifications. If banks force them to 
implement a specific attribute in a specific way, fine, but don't 
force user agents to do it that way as a matter of spec compliance.
Like Hixie said, documenting the reality lets implementors know what 
the real world requires to be implemented. Then let's just put in 
hidden prefs for disabling it and be quiet about it so the clueless 
banks don't notice.

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

RE: [whatwg] required attribute for checkbox/select

[Matt Wright]

Matthew Thomas wrote:
> Because real-world graphical Web browsers use option menus to 
> implement , and your proposal is not how real-world
> people expect option menus to work.

You're absolutely right and I wasn't think about it from that
perspective.  It makes no sense for a user to see a required
error message when an option in the menu has clearly been
selected. I retract my suggestion to have 'required' apply
to select.

Matt Wright

Re: [whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

[Chris Holland]

I


On Fri, 11 Mar 2005 16:12:50 +0100, Hallvord Reiar Michaelsen Steen
<[EMAIL PROTECTED]> wrote:
> On 10 Mar 2005 at 0:24, Chris Holland wrote:
> 
> > When requesting a different host, we don't want the user agent to be
> > sending along cookies pertaining to that domain. Same goes for any
> > cached HTTP Basic Auth credentials.
> 
> Why not? Given that we add a mechanism for letting the third-party
> server control access to resources on a resource-by-resource basis, I
> don't see why we would want to prevent the third-party server from
> using sessions / cookies. Authentication is mostly a GUI problem (and
> GUI has always been ridiculous for HTTP auth anyway, with no way to
> terminate a session). It would not be a good thing if a JS request in
> the background could cause a HTTP authentication popup for a user
> name / password unrelated to the site you're browsing, so I agree
> with disallowing that. Am I missing anything regarding cookies?

Well it depends on how granularly we're granting access to resources.
The X-Allow-Foreign-Hosts header we were talking about earlier,
wouldn't lend itself to much granularity on specific resources. The
Mozilla/SOAP authorization model, seems a bit overkill for our use
cases.

consider a commerce-driven web application:

commerce.foo.com

which offers an easily accessible URI to "view my past orders":

http://commerce.foo.com/my/pastorders/

that URI returns valid xhtml.

Later-on, that same site wants to offer a list of its most popular
items to the public, and some other developer sets-up a URI that
returns an RSS feed:

http://commerce.foo.com/mostpopular/

Now, if they want other sites to publish their RSS data, if they
follow our spec, and try to be careful, they'll make sure
/mostpopular/ returns the X-Allow-Foreign-Hosts header, and will make
sure /my/pastorders/ does not. They'll make damn sure that anything
that starts with /my/* doesn't.

But let's be paranoid, and say they misconfigure their server, and all
responses include our header. blam, /my/* is exposed, foreign
documents can start sending authenticated queries to /my/*, and sniff
results by crawling the resulting DOM.

when it comes to cookies, I would advocate one of 2 approaches:

1) disable cookies for a ContextAgnosticHttpRequest
2) maintain an entirely separate cookie table for this request. the
question then becomes, do we maintain a separate cookie table for each
referring document? We'd essentially be considering each referring
document to be a separate application through which a user would
re-establish credentials to communicate with a foreign site. sounds
rather painful.

Where XmlHttpRequest differs from the whole SOAP model is that SOAP
isn't a protocol through which a user casually surfs the web while
establishing credentials on certain sites, while XmlHttpRequest, in
its current incarnation, fully leverages everything that HTTP offers.
I was hoping to slightly scale back some of those features in a
ContextAgnosticXmlHttpRequest.

Is there anything in the SOAP protocol that warrants persistence of
any types of credentials such as what the HTTP protocol provides with
Basic-Auth and Cookies ?








> --
> Hallvord Reiar Michaelsen Steen
> http://www.hallvord.com/
> 
> Note: mail to hallvors at online.no will still be read but you may
> want to start using
> hallvord at hallvord.com instead
> 
> 


-- 
Chris Holland
http://chrisholland.blogspot.com/

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Chris Holland]

i need to better articulate what i had in mind for a "sensitiveinput"
attribute to form or form elements:

Let's forget about "autocomplete" for a second, and focus on a
different specific feature, which is "saving passwords".

Today, all browsers ask you whether or not you wish to save passwords
on a given site. If they don't ask you via prompt, they let you
specify it in a preference.

A browser identifies a "password' field through an attribute "type"
whose value is "password".

If a user has explicitly allowed their browser to save passwords for a
given site, the next time they come back to this input box, their
password will be pre-filled with dots ***.

Now, I would like "sensitiveinput" to be a part of this specific
behavior, enabled based on the exact same preference that governs
password auto-completion. Imagine "sensitiveinput" being just like
making all your sensitive text inputs of type "password": their
auto-completion behavior mirrors that of passwords, yet their display
isn't as obfuscated.

SO, whenever a user, at any given time, is asked by their browser "do
you wish to remember passwords for this site?", if they click Yes, the
browser will not only remember passwords for this site, but also all
inputs that are marked with the "sensitiveinput" attribute, on-top of
remembering non-sensitive inputs.

If the user answers "NO", then the browser will make a point of NOT
remembering passwords and inputs with the "sensitiveinput" attribute.
It may remember other inputs that are not marked "sensitive".

With all this in mind, the message that today, in most browsers, says
something like "do you wish to remember passwords for this site?"
might be reworded to "do you wish to remember passwords and other
entries of sensitive nature for this site?".  ... or not ...

Again, i'm not talking about "adding yet another warning for sensitive
inputs", i'm talking about leveraging an existing warning, and
extending its behavior to a new type of attributes.

With that said, this is all ideal-world speculation, likely not
something that we'll be able to put into a draft or anything, but i
just wanted to at least clarify the idea so it can rear its head back
up should an implementation opportunity arise.

-chris





On Tue, 22 Mar 2005 09:39:44 +1100, Lachlan Hunt
<[EMAIL PROTECTED]> wrote:
> Olav Junker Kjær wrote:
> > If I understand correctly, your objection against "autocomplete" is that
> > it specifies UI behavior rather than semantic information about the data
> > (like a "sensitiveinput" attribute would).
> 
> Yes, that and the fact that it provides control of a user agent feature
> to an author which, as I stated in my initial post, is a user-hostile act.
> 
> Although sensitiveinput is a slightly more semantic name, the problem
> with it is not only because it's not already supported; but because,
> theoretically, any form with a password could be considered sensitive
> input, which may result in many more authors making use of it believing
> they are doing the right thing by adding more semantics, yet effectively
> preventing password managers storing any passwords at the expense of the
> user.
> 
> > This could easily be solved by keeping the name "autocomplete" but
> > redefine its sematics as indicating that the input data is sensitive.
> 
> Redefining its semantics would be an improvement.  Although it's not an
> ideal solution, it's one I may just have to accept.
> 
> --
> Lachlan Hunt
> http://lachy.id.au/
> http://GetFirefox.com/ Rediscover the Web
> http://GetThunderbird.com/ Reclaim your Inbox
> 
> 


-- 
Chris Holland
http://chrisholland.blogspot.com/

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Lachlan Hunt]

Olav Junker KjÃr wrote:
If I understand correctly, your objection against "autocomplete" is that
it specifies UI behavior rather than semantic information about the data
(like a "sensitiveinput" attribute would).
Yes, that and the fact that it provides control of a user agent feature 
to an author which, as I stated in my initial post, is a user-hostile act.

Although sensitiveinput is a slightly more semantic name, the problem 
with it is not only because it's not already supported; but because, 
theoretically, any form with a password could be considered sensitive 
input, which may result in many more authors making use of it believing 
they are doing the right thing by adding more semantics, yet effectively 
preventing password managers storing any passwords at the expense of the 
user.

This could easily be solved by keeping the name "autocomplete" but
redefine its sematics as indicating that the input data is sensitive.
Redefining its semantics would be an improvement.  Although it's not an 
ideal solution, it's one I may just have to accept.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Lachlan Hunt]

Ian Hickson wrote:
On Mon, 21 Mar 2005, Lachlan Hunt wrote:
> That's no reason to give in to their blackmail.
If a bank says "either you support autocomplete, or we won't allow your
users to access our site", then the browser vendor has no choice.
...
Remove "... and the ability to disable support should not be trivially 
accessible" from the spec
The fact of the matter is that banks will not support UAs where the
feature can easily be disabled.
Then leave the choice for the user agent vendor to decide, the spec 
should not dictate such user-hostile requirements.

# The off value means that the UA must not remember that field's value.
That should also be changed from "must not" to "should not" to allow for 
a user to override this decision.
That's taken care of in the later paragraph that says the feature can be 
disabled.
Then, as Jim Ley said, that makes the spec contradictory and inconsistent.
--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

Re: [whatwg] [wf2] type="url"

[Mikko Rantalainen]

Ian Hickson wrote:
On Sun, 13 Feb 2005, Anne van Kesteren wrote:
After thinking about it. Having |type="url"| instead of |type="uri"| or
|type="iri"| might not be so bad.
type="url" will get me lynched by standards purists.
type="iri" will get me lynched by confused authors.
type="uri" is a compromise.
I think pretty much anybody that could use the feature has some idea 
what "url" means. They don't know that "mailto:[EMAIL PROTECTED]" 
isn't url but that doesn't matter a little bit. I'd rather take 
"iri" as it clearly defines how the identifier should be encoded 
(urlencode()d UTF-8 string). Using "uri" as a compromise results to 
confused authors (who don't regognise the abbreviation) and confused 
purists (who cannot agree on encoding as uri spec doesn't define 
one, AFAIR).

--
Mikko

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Matthew Raymond]

Olav Junker Kjær wrote:
Lachlan Hunt wrote:
Then, please at least deprecate it.  If it's only being defined to help 
with interopable implementations, that's fine, but it's use should be 
discouraged as much as possible, therefore it should be deprecated.
If I understand correctly, your objection against "autocomplete" is that
it specifies UI behavior rather than semantic information about the data
(like a "sensitiveinput" attribute would).
This could easily be solved by keeping the name "autocomplete" but
redefine its sematics as indicating that the input data is sensitive. (the
recommended default UI in UA's that support autocompletion would still be
as described in the spec). Of course the name will be slightly misleading
now, but thats not a big deal. "checkbox" is also a name that suggest an
UI representation, but the semantics is still defined as UI neutral.
   I like this idea. Let the UAs keep their implementations without 
violating WF2, while at the same time define the spec so that it doesn't 
forbid implementations that empower the users. All in a sweet 
semantic-coated shell. ;)

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Matthew Raymond]

James Graham wrote:
Lachlan Hunt wrote:
Then, please at least deprecate it.  If it's only being defined to 
help with interopable implementations, that's fine, but it's use 
should be discouraged as much as possible, therefore it should be 
deprecated.
What the WHATWG spec says on this matter is irrelevant; browsers will 
implement whatever the banks dictate. As Hixie says, the spec only 
serves the purpose of documenting an accepted standard. Therefore, I 
really don't think it's worth any more time discussing this attribute.
   Actually, now that I think about it, why do we need to have a spec 
saying that it's not depreciated or that it should be non-trivial to 
deactivate if the banks are going to blackmail UAs to support it? Why 
support blackmail through our specifications. If banks force them to 
implement a specific attribute in a specific way, fine, but don't force 
user agents to do it that way as a matter of spec compliance.

Re: [whatwg] Introducing new elements is expensive

[Matthew Raymond]

Ian Hickson wrote:
On Sat, 12 Mar 2005, Matthew Raymond wrote:
That is not the case with  in a legacy user agent. Any HTML 
contents will display as HTML in a legacy UA. Yet if we assume the 
 model for , WF2 UAs will display the underlying 
markup as text instead of rendering it. So, right off the bat, we have a 
difference in how the contents of  are rendered between legacy 
and WF2 user agents.
Elements inside  are rendered as elements, with all that that 
implies; there is no special parsing.
   The contents of  are the initial value, yet they are not parsed.
   /me scratches his head.
Since we can't avoid a difference in rendering unless we artificially 
enforce a no-markup-inside- rule, what does it hurt to simply 
have a |value| attribute to set the .defaultvalue directly?
The two things are separate. What's the use case for value=""?
   Well, for one, in situations where you want to use  
as a fallback container for a calculated value.

Re: [whatwg] [wf2] type="url"

[J. King]

On Sun, 20 Mar 2005 20:28:41 -0500, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Sun, 13 Feb 2005, Anne van Kesteren wrote:
After thinking about it. Having |type="url"| instead of |type="uri"| or
|type="iri"| might not be so bad.
type="url" will get me lynched by standards purists.
type="iri" will get me lynched by confused authors.
type="uri" is a compromise.
Personally I'd elect for "url".  Even though I prefer the term URI (and  
really dislike the term IRI), "url" is what CSS uses, and there's a lot to  
be said for consistency when authoring documents.

--
J. King
http://jking.dark-phantasy.com/

Re: [whatwg] [WF2] The element

[Matthew Raymond]

Ian Hickson wrote:
On Thu, 10 Feb 2005, Matthew Raymond wrote:
...if you were used to using , would you use a tag with then same 
attributes but a longer name and a required closing tag to do the exact 
same thing? Especially if the specs say to use  in simple cases? 
Please don't make the mistake of assuming authors are logical creatures. :-)
If you had the option of writing a document that was valid and didn't rely 
on undefined error handling, or one that was invalid and might render 
differently in different user agents, which would you use?

If you had the option of writing one line to change the fonts and colours 
of your entire site, or of using one  element per bit of text, which 
would you do?
   I could give examples of why people might do one or the other, many 
of which have to deal with the ignorance of the author. That said, the 
authors aren't ignorant of . They're ignorant of . So, 
I don't see the point.

Obviously, many authors "choose" to write invalid sites and "choose" to 
use  instead of CSS.
   In all likelihood, they "choose" to do so because they either don't 
actually know anything about CSS or they're supporting some ancient 
browser that only supports .

As for the editor, they can simply use  by default and give a 
warning before saving if  has no contents. (Can we require 
contents??? My first guess would be no, but maybe someone knows more 
than I.)
The specs require editors to generate valid code, but they don't.
(This is not an argument against , though, since you are right, 
we could require that editors do this. Editors that don't would just be 
non-compliant.)
   You have a mild point, but don't forget that editors can also insert 
legacy contents into  (formerly ) depending on it's 
|type| attribute.

Well, one solution would be to provide an optional attribute that can 
exclude  from the .elements collection:
That (or it simply not being in the array at all) would be bad since the 
.elements array is used in other parts of the WF2 processing model. We 
could define it otherwise but that would be awkward. (It's already a pain 
for  for legacy reasons.)
   Yeah, I'm kinda leaning away from making  cloaked to 
.elements by default. Perhaps we could offer a scripting method: create 
a method that allows people to remove elements from the .elements array. 
In that way, one could just write a function that goes through the array 
and removes the  elements. A simple 
scripting solutions for a scripting problem. (Wait, can't you already do 
this with Javascript arrays?)

Re: [whatwg] [WF2] The element

[Matthew Raymond]

Ian Hickson wrote:
On Wed, 9 Feb 2005, Matthew Raymond wrote:
EXAMPLES:
  Here's a simple example for the three  scenario:
| 
|   /
|   /
|  
| 
This still breaks the .elements array, because the  element 
will be present in .elements in the WF2 UAs but not the legacy UAs.
   I don't see this as a big issue for the following reasons:
1) You yourself were stating that most WF2 content will be new content. 
Therefore, people can simply write scripts that avoid the problem from 
the beginning.

2) An author could always use an  and some 
scripting to ensure that a specific field is submitted to the server. 
The other controls could simple exclude the |name| attribute. In that 
manner, only one field name would ever be successfully submitted to the 
server.

It doesn't solve the problem of having "two forms": legacy UAs and WF2 UAs 
would send different fields, which is a pain for servers and a potential 
source of problems (e.g. hostile users could try sending both, which is 
unlikely to have been tested, and is likely to have unexpected effects).
   First of all, sending different fields is not a given. It depends on 
the fallback implementation. Secondly, if the fallback implementation 
does use multiple controls, then from the server side you'd have to deal 
with multiple field names in the first place in order to deal with WF2 
and legacy forms calling the same script at the same time. Can you 
explain exactly why it's so difficult to create server-side scripts to 
deal with this issue?

It doesn't solve the problem of the default (simplest authoring) being 
zero fallback for legacy UAs.
   The simplest thing to author would be to use , so I don't see 
your point.

It also introduces the possibility of being abused in a semantically 
incorrect way which would IMHO be much too tempting and would miss the 
point of the idea of graceful fallback, namely:

   
You don't have a WF2 UA. Sucks to be you.
   
   This is your real argument, and it is weak. You're referring to 
authors' past history of doing things like this:

| 
|   This is a frames-based page. Get a browser that doesn't suck!
| 
   The problem here was that supporting  is a huge pain in 
the a$$, especially if you're a hand coder like myself. It involves a 
massive amount of copying content and it's a pain to test because you 
need a browser without frames support to check it. So most people just 
said, "Screw it, let them get a browser that supports frames!"

   So, in many cases there was a real disincentive for inclusion, 
whereas you're talking about and intentional attempt to exclude. Look here:

Example 1:
| 
|   Go get a real browser, loser!
| 
Example 2:
| 
   It doesn't take a rocket scientist to figure out that no serious 
professional would use Example 1 in favor of Example 2. In fact, someone 
could easily get fired for favoring Example 1, since it's obviously 
malicious. You can't say the same for something like  or 
. Those elements *always require additional effort* to put 
something meaningful in them for legacy browsers, whereas with the use 
of / (I renamed it a while ago), the author has a 
choice of using a simple or complex fallback method.

Any one of these problems is, in my opinion, more critical than the 
suboptimal (although still functional) fallback of .
   I don't really feel you've made that point in any of the three above 
cases.

I think you are giving authors way too much credit. The point is that 
authors wouldn't _think_ about including fallback, or if they did they 
would do something dumb like:

   
You need a WF2 UA to enter a date.
   
Given two options, one which allows this and one which does not, I 
strongly, strongly favour the one that does not.
   For that matter, they could use Javascript to detect WF2 clients and 
disable a form on legacy clients. Or they could use browser detection to 
serve up a page that says "You cannot use this site without a 
WF2-compliant browser". You can't use markup to protect the entire world 
from a**holes, and guess what?!! People browsing the web don't 
necessarily need you to. If authors treat them like second-class 
citizens, they'll just go to a website that doesn't.

   And might I point out that detection of WF2 was part of your defense 
of the  element's poor fallback, by the way.

My biggest problem with this proposal, though, is that it is trying to 
solve a problem that I haven't been convinced exists. I just don't see 
that the simple fallback is a problem.
   Considering the fact that textboxes as date inputs are in the 
minority, and that many of those textboxes use formatting hints, I can't 
see how you could come to that conclusion.

As I've said before, I see these cases, with the given pros and cons for 
converting (in all cases you also have to update the server):

1. Authors who currently use type="text" with no format help.
   Pro: Better user experience in new UAs.
   Pro: Conversion of page is easy.
   That's not what  was intended for to be

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Olav Junker Kjær]

Lachlan Hunt wrote:
> Then, please at least deprecate it.  If it's only being defined to help 
> with interopable implementations, that's fine, but it's use should be 
> discouraged as much as possible, therefore it should be deprecated.

If I understand correctly, your objection against "autocomplete" is that
it specifies UI behavior rather than semantic information about the data
(like a "sensitiveinput" attribute would).

This could easily be solved by keeping the name "autocomplete" but
redefine its sematics as indicating that the input data is sensitive. (the
recommended default UI in UA's that support autocompletion would still be
as described in the spec). Of course the name will be slightly misleading
now, but thats not a big deal. "checkbox" is also a name that suggest an
UI representation, but the semantics is still defined as UI neutral.

regards
Olav Junker Kjær

Re: [whatwg] [wf2] 2.3. Changes to existing controls

[Anne van Kesteren]

Ian Hickson wrote:
Ok, how about this:
| The children of a form element must be block-level elements, unless one 
| of the ancestors of the form element is an element other than div whose 
| content model includes both block- and inline-level content, in which 
| case either block-level or inline-level content is allowed (but not 
| both).
+1
--
 Anne van Kesteren
 

Re: [whatwg] [wf2] 2.3. Changes to existing controls

[Ian Hickson]

On Mon, 21 Mar 2005, James Graham wrote:
>
> I think the need to point this out implies that the condition (and the 
> wording of the condition) is too complex for most authors to understand 
> (and it's clear that no UA will enforce such a condition). Therefore the 
> paragraph as it stands benefits no-one and I suggest altering the 
> wording, at least.

Ok, how about this:

| The children of a form element must be block-level elements, unless one 
| of the ancestors of the form element is an element other than div whose 
| content model includes both block- and inline-level content, in which 
| case either block-level or inline-level content is allowed (but not 
| both).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] 2.3. Changes to existing controls - radio buttons

[Ian Hickson]

On Mon, 21 Mar 2005, Anne van Kesteren wrote:
> Ian Hickson wrote:
> > The UA should not be required to provide such an ability. All radio 
> > buttons being unchecked in a group is an error condition. However if 
> > the UA wants to provide it, that's a UA thing.
> 
> It is in error? Let me quote something:
> 
> # Radio buttons in sets where none of the buttons are marked as checked
> # must all be initially left unchecked by the UA (which differs from
> # the behavior described in [RFC1866], but more accurately represents
> # common implementation and author needs).

That's a UA requirement, and doesn't have any bearing on whether something 
is an error or not.

The next bit says: "Authors are recommended to always have one radio 
button selected. Having no radio buttons selected is considered very poor 
UI." which I guess means it's not really an error condition, but it is 
close to it.


> If you allow them to be unchecked initially and a user accidently checks 
> one which needs to be unchecked for that particular user he/she has a 
> problem. The current description would allow that to happen.

Yes. Like it says: it's poor UI. Authors shouldn't do it.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] 2.3. Changes to existing controls

[Anne van Kesteren]

Ian Hickson wrote:
On Mon, 21 Mar 2005, Anne van Kesteren wrote:
The BODY element is a block-level element other than the DIV element.

No, it's not.
   http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
Hmm, ok. And how about P, H1, etc? I agree with James Graham that the 
wording isn't very clear.

--
 Anne van Kesteren
 

Re: [whatwg] [wf2] 2.3. Changes to existing controls

[James Graham]

Ian Hickson wrote:
On Mon, 21 Mar 2005, Anne van Kesteren wrote:
 

The BODY element is a block-level element other than the DIV element.
   

No, it's not.
  http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
 

I think the need to point this out implies that the condition (and the 
wording of the condition) is too complex for most authors to understand 
(and it's clear that no UA will enforce such a condition). Therefore the 
paragraph as it stands benefits no-one and I suggest altering the 
wording, at least.

--
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"
-- Dr. Bunsen Honeydew & Beaker of Muppet Labs

Re: [whatwg] [wf2] 2.3. Changes to existing controls - radio buttons

[Anne van Kesteren]

Ian Hickson wrote:
The UA should not be required to provide such an ability. All radio 
buttons being unchecked in a group is an error condition. However if 
the UA wants to provide it, that's a UA thing.
It is in error? Let me quote something:
# Radio buttons in sets where none of the buttons are marked as checked
# must all be initially left unchecked by the UA (which differs from
# the behavior described in [RFC1866], but more accurately represents
# common implementation and author needs).
(That it is considered "very poor UI" is nice, but not really that will 
scare away authors.)

If you allow them to be unchecked initially and a user accidently checks 
one which needs to be unchecked for that particular user he/she has a 
problem. The current description would allow that to happen.

--
 Anne van Kesteren
 

Re: [whatwg] [wf2] 2.3. Changes to existing controls

[Ian Hickson]

On Mon, 21 Mar 2005, Anne van Kesteren wrote:
> 
> The BODY element is a block-level element other than the DIV element.

No, it's not.

   http://www.w3.org/TR/html4/struct/global.html#h-7.5.3

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] 2.3. Changes to existing controls - radio buttons

[Ian Hickson]

On Mon, 21 Mar 2005, Anne van Kesteren wrote:
>
> Should UAs provide ways to uncheck a particular radio button:
> 
>  
>  
> 
> ... they are both unchecked; after I mark the first checked, should I be 
> able to uncheck it?

The UA should not be required to provide such an ability. All radio 
buttons being unchecked in a group is an error condition. However if the 
UA wants to provide it, that's a UA thing.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] 2.3. Changes to existing controls

[Anne van Kesteren]

Ian Hickson wrote:
# The children of a form element must be block-level elements,
# unless one of the ancestors of the form element is a td, th, li,
# dd, dt, or block-level element other than div, in which case
# either block-level or inline-level content is allowed (but not
# both). input elements of type hidden may be placed anywhere (both
# in inline contexts and block contexts).
Why does the content model of the FORM element have to be so
difficult? Why can't it be either block- or inline-level
irrespective of its parent element?
...but without allowing:
  ...  
The BODY element is a block-level element other than the DIV element. 
The definition should either be made more clear, or dropped in favor of 
just allowing either block- or inline-level markup irrespective of its 
parent element.

--
 Anne van Kesteren
 

[whatwg] [wf2] 2.3. Changes to existing controls - radio buttons

[Anne van Kesteren]

Should UAs provide ways to uncheck a particular radio button:
 
 
... they are both unchecked; after I mark the first checked, should I be 
able to uncheck it?

--
 Anne van Kesteren
 

Re: [whatwg] [wf2] 2.3. Changes to existing controls

[Ian Hickson]

On Mon, 21 Mar 2005, Anne van Kesteren wrote:
>
> # The children of a form element must be block-level elements, unless
> # one of the ancestors of the form element is a td, th, li, dd, dt, or
> # block-level element other than div, in which case either block-level
> # or inline-level content is allowed (but not both). input  elements of
> # type hidden may be placed anywhere (both in inline contexts and block
> # contexts).
> 
> Why does the content model of the FORM element have to be so difficult? 
> Why can't it be either block- or inline-level irrespective of its parent 
> element?

The main reason is to allow people to write markup like:


   
...
   
   
...
   

...instead of requiring:

   

 ...

   
   

 ...

   

...but without allowing:

   

 ...

   

In the table cell case there are semantics -- maybe the cell is part of a 
spreadsheet or something -- but in the  case the input doesn't have 
any particular semantics. It's not grouped into a thematic unit (like a 
paragraph or list). It's just... there. It would be like:

   
Hello world.
   

...which is also not allowed.


> (Note also that the block- or inline-level model can't be described by a 
> DTD, only with a schema, but I don't believe that is a problem, is it?)

As noted in the WA1 draft, conformance checkers will need to be a lot more 
involved than schema- or DTD-based validators anyway.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] [wf2] 2.3. Changes to existing controls

[Anne van Kesteren]

# The children of a form element must be block-level elements, unless
# one of the ancestors of the form element is a td, th, li, dd, dt, or
# block-level element other than div, in which case either block-level
# or inline-level content is allowed (but not both). input  elements of
# type hidden may be placed anywhere (both in inline contexts and block
# contexts).
Why does the content model of the FORM element have to be so difficult? 
Why can't it be either block- or  inline-level irrespective of its 
parent element?

(Note also that the block- or inline-level model can't be described by a 
DTD, only with a schema, but I don't believe that is a problem, is it?)

--
 Anne van Kesteren
 

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Jim Ley]

On Mon, 21 Mar 2005 11:08:29 + (UTC), Ian Hickson <[EMAIL PROTECTED]> wrote:
> It would also make
> any site using the feature non-conformant, which is pointless: 

how does using a deprecated feature make a site non-conformant?

> > # The off value means that the UA must not remember that field's value.
> >
> > That should also be changed from "must not" to "should not" to allow for
> > a user to override this decision.
> 
> That's taken care of in the later paragraph that says the feature can be
> disabled.

No it's not the MUST NOT, says just that, that it must not, if it says
something different elsewhere in the spec then the spec is
inconsistent with itself, and it needs fixing.

Either a conforming UA can be allowed to change the functionality
(which in www-architecture it must be able to, the user should control
his browser) in which case you cannot say that a UA MUST NOT remember
the fields value, or it can't which is clearly not the position of
anyone I've seen posting on this list.

Changing this to SHOULD NOT is obviously the correct result.

Jim.

Re: [whatwg] required attribute for checkbox/select

[Ian Hickson]

On Sun, 20 Mar 2005, Matt Wright wrote:
> > >
> > > 2) Why can't the required attribute apply to a select field?  It is 
> > > common for application designers to want to force the user to 
> > > manually select an option.  They will do something like  > > value="">Please select a valid option. You could easily 
> > > word the document to say that:
> >
> > That's, IMHO, semantic abuse. That isn't an option, and shouldn't 
> > be called an option.
>
> It may be semantic abuse, but I think it is pretty common usage in 
> actual web development practice.

Oh, sure, I don't deny that. So is "", though, and we're not going 
to encourage that either.


> It's technically not a valid option, but it's the best we've got in HTML 
> if you don't want the browser to preselect an option in your select box.

But if we're going to fix the problem here, it would be better to fix the 
problem by providing real menus or a real way to make s have a 
label and require a selection, than it would by kludging the current model 
to do it without fixing the semantics.

I fully agree that we need to cater for the use case you gave; but I think 
it would need non-trivial changes and therefore I would like us to wait 
until the next version of the Web Forms draft.


> I simply think that my original proposal makes the most sense from a 
> real-world web-apps implementation standpoint. Why deny authors the 
> ability to require a select element when this method would match up with 
> normal day-to-day usage of the element while not causing any negative 
> side-effects (that I know of)?

As mpt pointed out, I do not really think the interaction model you are 
proposing really makes sense for users who are used to list boxes.


> However, if you cannot get past the semantic conflict, wouldn't it at 
> least make sense to allow the required attribute on the select tag and 
> have it say that at least one option must be selected? For any single 
> select it would always be satisfied (since one option is always selected 
> by the browser), but for a multiple select at least one option would 
> have to be selected (since one is not always selected by the browser by 
> default)?

What's the use case for multiple select being required?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Ian Hickson]

On Mon, 21 Mar 2005, Lachlan Hunt wrote:
> > 
> > The "autocomplete" attribute is already implemented in user agents. 
> > There's nothing we can do about it. I included it in the spec simply 
> > so that it is at least defined somewhere, instead of being just 
> > something people have to Know About without being documented anywhere.
> 
> Then, please at least deprecate it.  If it's only being defined to help 
> with interopable implementations, that's fine, but it's use should be 
> discouraged as much as possible, therefore it should be deprecated.

Deprecating the feature would indicate that there is a chance the feature 
will be dropped in a future version, which there isn't. It would also make 
any site using the feature non-conformant, which is pointless: the sites 
are going to use these features regardless, why make people have to 
violate the spec to do so.


> > The fact of the matter is, banks blackmail vendors into supporting 
> > this feature. Not much WHATWG can do about this.
> 
> That's no reason to give in to their blackmail.

I'm sorry, but in the real world, there is. If a bank with 50 million 
customers comes to a browser vendor and says "either you support 
autocomplete, or we won't allow your users to access our site", then the 
browser vendor has no choice. The alternative would simply make the 
browser get no market share, as users simply don't use browsers that don't 
work on their bank's site.


> UAs should also be allowed to let the user to deactive this feature 
> easily, despite what the current draft says about that matter. ie. 
> Remove "... and the ability to disable support should not be trivially 
> accessible" from the spec

That would be, again, unrealistic. The fact of the matter is that banks 
will not support UAs where the feature can easily be disabled. In fact, 
the banks probably don't realise it _can_ be disabled in most UAs; if they 
did, support for those UAs would probably start disappearing.


> # The off value means that the UA must not remember that field's value.
> 
> That should also be changed from "must not" to "should not" to allow for 
> a user to override this decision.

That's taken care of in the later paragraph that says the feature can be 
disabled.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[James Graham]

Lachlan Hunt wrote:
Ian Hickson wrote:
On Sat, 12 Mar 2005, Lachlan Hunt wrote:
I realise I may be a little late with this issue, since WF2 seems to 
be fairly stable, but never the less I would like to note my 
objection to the inclusion of the autocomplete attribute [1].

The "autocomplete" attribute is already implemented in user agents. 
There's nothing we can do about it. I included it in the spec simply 
so that it is at least defined somewhere, instead of being just 
something people have to Know About without being documented anywhere.

Then, please at least deprecate it.  If it's only being defined to 
help with interopable implementations, that's fine, but it's use 
should be discouraged as much as possible, therefore it should be 
deprecated.
What the WHATWG spec says on this matter is irrelevant; browsers will 
implement whatever the banks dictate. As Hixie says, the spec only 
serves the purpose of documenting an accepted standard. Therefore, I 
really don't think it's worth any more time discussing this attribute.

--
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"
-- Dr. Bunsen Honeydew & Beaker of Muppet Labs

Re: [whatwg] [WF2] Objection to autocomplete Attribute

[Lachlan Hunt]

Ian Hickson wrote:
On Sat, 12 Mar 2005, Lachlan Hunt wrote:
I realise I may be a little late with this issue, since WF2 seems to be 
fairly stable, but never the less I would like to note my objection to 
the inclusion of the autocomplete attribute [1].
The "autocomplete" attribute is already implemented in user agents. 
There's nothing we can do about it. I included it in the spec simply so 
that it is at least defined somewhere, instead of being just something 
people have to Know About without being documented anywhere.
Then, please at least deprecate it.  If it's only being defined to help 
with interopable implementations, that's fine, but it's use should be 
discouraged as much as possible, therefore it should be deprecated.

The fact of the matter is, banks blackmail vendors into supporting this 
feature. Not much WHATWG can do about this.
That's no reason to give in to their blackmail.  As well as being 
depreacted, UAs should also be allowed to let the user to deactive this 
feature easily, despite what the current draft says about that matter. 
ie. Remove "... and the ability to disable support should not be 
trivially accessible" from the spec

# The off value means that the UA must not remember that field's value.
That should also be changed from "must not" to "should not" to allow for 
a user to override this decision.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

Re: [whatwg] required attribute for checkbox/select

[Matthew Thomas]

Matt Wright wrote:
...
I simply think that my original proposal makes the most sense from a 
real-world web-apps implementation standpoint. Why deny authors the 
ability to require a select element when this method would match up with 
normal day-to-day usage of the element while not causing any negative 
side-effects (that I know of)?
...
Because real-world graphical Web browsers use option menus to implement 
, and your proposal is not how real-world people expect option 
menus to work.

--
Matthew Thomas
http://mpt.net.nz/