Re: [whatwg] Forms and POST'ing to data: URL's

[Ian Hickson]

On Thu, 24 Aug 2006, Charles Iliya Krempeaux wrote:
> 
> One use case, from my point-of-view, was to allow for non-networked form 
> submits

The solution is to use a scripting language, IMHO.


> What really motivated me to think about it is that is that I was writing 
> a blog post about how to create HTML e-mail signatures with hCards built 
> into them.
> 
> I wanted to include a form to help them do this.  The reader would fill 
> in their name, e-mail address, etc, and it would generate HTML code they 
> could use for their HTML e-mail signature.
> 
> However, I didn't want the form to make a request back to my server. 
> (Because people could be reading this in their feed reader were they 
> have the blog post cached from my feed.)  I wanted it to be entirely 
> self contained within the blog post.
> 
> So, as you mentioned, one solution is JavaScript.  However, JavaScript 
> has a couple problem.  #1: It complex.  (Yes... I'm lazy :-)  )  #2: Not 
> all blog readers will allow the execution of JavaScript.

Not all readers will allow form submission, or data: URIs, either.

It seems that you'd very quickly run against limitations of a templating 
solution, and that the complexity of such a solution isn't worth the 
limited use it would get.

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

Re: [whatwg] Dynamic content accessibility in HTML today

[Matthew Raymond]

James Graham wrote:
> OK, I think I hadn't appreciated just how vague the W3C document is. I 
> propose 
> we [standardize] the following:
> 
> A role attribute which may appear on (only non-semantic?) elements to 
> indicate 
> that that element is part of a DHTML widget and not marked-up prose. The role 
> attribute would not be namespaced (in HTML5, in XHTML5... well who knows). 
> The 
> role attribute would take certain predefined values (not those on the W3C 
> page 
> which are largely useless, e.g. banner, or otherwise covered in HTML5, e.g. 
> navlist) corresponding to the various types of UI widgets understood by the 
> accessibility toolkits. As far as possible we would stick to whatever Firefox 
> currently implements, but we would simplify the syntax where necessary (e.g. 
> avoid qnames wherever possible). Values outside the predefined list would 
> make 
> the document non-conforming.

   So long as it's clear that the UI roles are for DHTML widget
accessibility, then that's fine. UI roles feel mildly presentational to
me, but they're essential enough for accessibility that they can't
really be left to the style sheet, which is an optional technology.
Also, I suppose there may be situations where you'd want to use them
within an XBL binding, so I can't be certain the two aren't orthogonal
in specific use cases. (We should probably create use cases for using
the two in tandem to be sure.)

   Should the attribute only apply to  and  elements???

   Values that are not in the user agent's predefined list should be
treated just like unknown values in attributes like |rel|.
Vendor-specific values could probably have the same naming convention
that CSS uses: "-vendor-uirolename". Namespaces should either be
ignored, or we should use the Dublin Core dot convention
("namespace.subnamespace.role").

   Now that I look at that, the two don't seem compatible, so better to
use the second: "vendornamespace.subnamespace.role".

   The actual name "role" is too broad. Something like "widgetrole", or
"uirole" (which I prefer) would probably better communicate the
semantics of the attribute. (I proposed "wairole" earlier, but that's to
specific to a namespace.)

   Also, we need a way to allow accessibility for the UI state, so we
possibly need an attribute for that. Example...

| 
|   Any checkbox label
| 

   Thought: Should labels be able to treat elements with |uirole| as if
they were controls and pass focus to them when the underlying platform
permits focus passing to the specific UI role?

| 
| 
|
| A checkbox label

> Does that sound reasonable or have I totally missed the point?

   Well, this allows us to avoid creating predefined class names for
|class| without simultaneously preventing class names from having
semantic meaning in the document. I'm still not completely convinced
this isn't just a means of communicating a media-specific presentation,
and it might just be giving ammo to supporters of the |onbeforeprint|
and |onafterprint| attributes, as they make a similar case for the print
media in situations where styling is optional/unavailable. But, then, I
suppose if we're going to have a UI state, we need the roles as well for
balance...

Re: [whatwg] Web Forms 2.0 is now a W3C Working Draft

[Gervase Markham]

Jens Meiert wrote:
> Slightly off-topic - what I like most is this ultra-sensitive and tactful
> 
>   "for example the activation code for a nuclear weapon" [1]
> 
> Impressive.

I'm just interested to know what sort of nuclear weapons get activated
more than once... ;-)

(Yes, yes, I know. Pedants.)

Gerv

Re: [whatwg] Some comments on server-sent events

[Sverre Johansen]

On ons, 2006-08-23 at 18:58 +0200, Anne van Kesteren wrote:
> * What happens for other line feed characters? Are they treated as fields?
> Won't that give lots of problems for authors coding in non-Unix formats?
> HTTP for example allows both.

HTTP uses CRLF, but the specification recommends that UA should also
allow linefeeds for the headers. Other places, for example in the chunk
encoding, it requires CRLF.

rfc2616:
   The line terminator for message-header fields is the sequence CRLF.
   However, we recommend that applications, when parsing such headers,
   recognize a single LF as a line terminator and ignore the leading CR.

> * "For each non-blank, non-comment line, the field name is first
> taken[...]" doesn't cover what happens to command lines.
> 
> * "The ctrlKey field would be ignored[...]" should probably say
> "keyIdentifier" as that's what's used in the example.


-- 
Sverre Johansen

Re: [whatwg] input type="country"?

[Anne van Kesteren]

On Thu, 24 Aug 2006 19:00:15 +0200, Charles McCathieNevile  
<[EMAIL PROTECTED]> wrote:
I agree with all the arguments against speccing this, but also this  
smells much more like a browser feature to me. I think a much more  
realistic
approach would be for browser vendors to offer a setting to try to by  
default select the user's country when they encounter such a list in a  
page's form.


Opera supports RFC 2706 http://ietf.org/rfc/rfc2706 for form controls  
which basically allows page authors to indicate what certain form controls  
are for allowing them to be pre-filled.



--
Anne van Kesteren