> blocks around e-mails: > >

>     Access via the DOM also affects styling.
>
>     Also, if UAs have to parse it in the old way, what's the point?
>     It's not increasing the semantics, since the UAs have to parse it 
> the
>     old way.
>

> > ...or something. Then again, that does look pretty bad. I'm not a big fan of

. In fact, I stay away from it and use 
... with no-break spaces for code snippets. For 
mail archives, I suggest supporting format=flowed, which means  
should not be involved.

> On Fri, 8 Apr 2005, Henri Sivonen wrote:
>> I see the option are:
>> a) Banning XHTML divergence for everyone.
>> b) Behaving as if a) was the case and barfing at XHTML that cannot be
>> serialized as HTML.
>> c) Bending over backwards in order to track whether a given piece of
>> data can be serialized as HTML and whether there is a future need for 
>> a
>> given piece of data to be serialized as HTML.
>>
>> Option a) doesn't seem popular and implementing c) would be a pain,
>> which seems to leave b) for those who serialize as HTML. Of course, 
>> the
>> reason why one would want to serialize as HTML is IE (and Lynx).
>
> Agreed. Is option b acceptable to you?

I suppose that realistically it has to be, because enforcing a) doesn't 
look like a realistic option. :-/

It would help if WHAT WG published a RELAX NG schema for the 
text/html-compatible subset of the XHTML flavor. That would make 
appropriate barfing easier. It would also facilitate the implementation 
of text/html flavor conformance checkers.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From hsivonen at iki.fi  Sat May  7 11:50:11 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sat, 7 May 2005 21:50:11 +0300
Subject: [whatwg] [web-apps] 2.7.8 The i element
In-Reply-To: 
References: 

	<42611707.10401@lachy.id.au>

	<42612459.5080500@lachy.id.au>

Message-ID: <56ca39c50dc8065a6f27c3792785eac1@iki.fi>

On Apr 16, 2005, at 17:53, Ian Hickson wrote:

> On Sun, 17 Apr 2005, Lachlan Hunt wrote:
>>>
>>> Actually,  in HTML5 is currently defined as having specific
>>> semantics:
>>>
>>>    http://whatwg.org/specs/web-apps/current-work/#the-i
>>
>> So does "i" now stand for "instance", instead of "italics"?
>
> At least until someone argues otherwise. :-)

Everybody knows it originally stands for "italic". Who would you fool 
by claiming it stood for something else? For browsers, and the element 
name is just a string. They don't care of English words. The default 
rendering will have to be italics anyway due to ample legacy content. 
No matter what to write in the spec, for all practical purposes  
will mean "italic". I think acknowledging this would be in line with 
the descriptive approach the WHAT WG specs tend to take when it comes 
to features that have been already interoperably implemented.

What's the pseudo-semantic trickery good for? Will hard-line 
anti-presentationalists who spread false propaganda about  being 
deprecated suddenly embrace  if WHAT WG claims it stands for a 
different English word?

>> In that case, would you want to differentiate between ordinary titles
>> and real citations?  Or is that something that the class attribute 
>> could
>> handle, if needed?
>
> I don't know. What do people think?

I'd define  meaning a title of work (not a person and not limited 
to quoted works).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From hsivonen at iki.fi  Sat May  7 11:51:00 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sat, 7 May 2005 21:51:00 +0300
Subject: [whatwg] [html5] tags, elements and generated DOM
In-Reply-To: <4263A7DF.1000509@inkedblade.net>
References: <42524E27.6060006@annevankesteren.nl>
	<42534E44.8080101@lachy.id.au>

	<4253B881.3090206@lachy.id.au> <4253CA8A.1070608@olav.dk>
	<4253D10C.5000700@lachy.id.au>
	<4253D24A.8050308@annevankesteren.nl>
	<4253D7CA.2010807@lachy.id.au>
	<4253DA93.8030606@annevankesteren.nl>
	<4253E4FF.2090306@lachy.id.au> <4253F517.3040409@olav.dk>
	<425401B0.3040205@lachy.id.au>
	<42540251.4080405@annevankesteren.nl>
	<42546FCE.5070900@lachy.id.au>

	<4254CE93.4000403@lachy.id.au>

	<42550FFD.20201@annevankesteren.nl>

	<4255114D.10108@annevankesteren.nl>

	<4261C2BE.7060601@inkedb lade.net>
	<7becfe9e53869dcf45c0b5123f918a8b@iki.fi>
	<4263A7DF.1000509@inkedblade.net>
Message-ID: <6ae97fbbc664c4066e8c90d196914820@iki.fi>

On Apr 18, 2005, at 15:28, fantasai wrote:

> Henri Sivonen wrote:
>> On Apr 17, 2005, at 04:58, fantasai wrote:
>>> For those of us writing HTML by hand, this is not a practical 
>>> solution,
>>> particularly when invisible characters are involved. Invisible 
>>> characters
>>> aside, I don't want to go digging through a Unicode character map 
>>> every
>>> time I want → or τ.
>> That's not an issue for HTML where entities get tag soup treatment 
>> anyway.
>> I didn't say that authors should not type entity references in XML. I 
>> said that the entity references should be resolved before the data 
>> travels from the server to the client.
>
> So, when is my document going to get preprocessed? I certainly don't 
> want
> to bother fussing with it every time I fix a typo.

If there is no CMS and the server served raw files, the preprocessing 
would have to happen while editing or in an editor save hook.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From ianb at colorstudy.com  Sat May  7 12:04:54 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat, 07 May 2005 14:04:54 -0500
Subject: [whatwg] A thought: 
In-Reply-To: <6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
Message-ID: <427D1156.8050506@colorstudy.com>

Henri Sivonen wrote:
> On May 7, 2005, at 01:55, Ian Bicking wrote:
> 
>> I was just thinking about the recent problems introduced by the Google 
>> Web Accelerator following links that have side effects (the typical > href="form?delete=10">[delete this] stuff).
> 
> 
> Links like that are objectively wrong according to RFC 2616 (HTTP 1.1). 
> Google is free to follow those links without being responsible for the 
> side effects.

I think it's sufficient to note that this is an *extremely* common 
pattern, regardless of RFC 2616.  I think this might be a constructive 
place to discuss why it is so common, and what could be provided to web 
developers so they can do the right thing, but I don't think much is 
achieved by just saying that the majority of web developers are wrong. 
And it's the majority of web developers that use these kinds of links, 
regardless of spec.  Heck, Google uses these kinds of links.

>> One of the issues is that doing the Right Thing means creating a form, 
>> and that effects the UI,
> 
> 
> There'd be a design bug somewhere if the UI wasn't affected! When 
> something looks like a link to, the user has a good reason to expect 
> that following the link causes a safe retrieval operation. When 
> something looks like a button, the user has a reason to understand that 
> pressing the button may cause an unsafe operation.

Without Web Forms and nested forms, it *is* a bug to effect the UI in 
the ways that would be required, because isolated controls cannot be put 
inside the context of a larger form that submits to a different location 
and performs a different action.  The only way to do that now would be 
with Javascript, which would submit a form that existed elsewhere on the 
page.  It is also made more difficult by the fact that a form is a 
block-level element, and so has even more effect on the layout of the page.

And there's other much more safe operations that also cause side 
effects.  For instance, links that reorder items -- they aren't very 
dangerous, you don't really have to warn users implicitly about their 
effects, but it will cause problems if a UA clicks these links without 
direct user request.  I think there is a continuum, and by forcing safe 
state-modifying actions to look different it has caused many developers 
to do things that are unsafe with regard to HTTP, so that their UIs 
better represent (in those developers' opinions) the functionality they 
are providing.

Developers use many techniques to indicate what a control will do. 
Generally links give them more flexibility in how they indicate this,

I'm just trying to explain why this "incorrect" practice is so common. 
I haven't thought about it a lot before now, so I'm making it up as I go 
along, but emperically there must be reasons.  It then would be helpful 
to give developers tools that address those reasons, but allow them to 
use POST the way they should.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org

From ian at hixie.ch  Sat May  7 13:19:27 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 7 May 2005 20:19:27 +0000 (UTC)
Subject: [whatwg] WebApps spec, chapter 7.1.1.9 "Images"
In-Reply-To: <427C73D2.60108@web.de>
References: <427C73D2.60108@web.de>
Message-ID: 

On Sat, 7 May 2005, Jens Bannmann wrote:
>
> The note at the end of chapter 7.1.1.9 saying "All canvases implement 
> HTMLImageElement, so canvas elements can be passed to the drawImage 
> methods" looks like it's superfluous, now that HTMLCanvasElement no 
> longer inherits from HTMLImageElement. The rest of the spec, e.g. the 
> second paragraph of that chapter, was already changed accordingly.

Good catch. Removed. Thanks.

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

From jg307 at cam.ac.uk  Sat May  7 16:36:47 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Sun, 08 May 2005 00:36:47 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
Message-ID: <427D510F.6010802@cam.ac.uk>

Henri Sivonen wrote:
> 
>> One of the issues is that doing the Right Thing means creating a form, 
>> and that effects the UI,
> 
> 
> There'd be a design bug somewhere if the UI wasn't affected! When 
> something looks like a link to, the user has a good reason to expect 
> that following the link causes a safe retrieval operation. When 
> something looks like a button, the user has a reason to understand that 
> pressing the button may cause an unsafe operation.
>

I'm not sure that users (the vast majority of users who haven't even 
heard the term RFC, let alone read one) have any particular expectation 
for the safety of clicking on a link. The fact that so many webapps use 
links for unsafe operations kind-of supports that view. Plus, design 
_is_ important in these things and submit-style buttons don't always 
make good UI.

Consider the example of a webmail application. These often allow 
messages to be retrieved by clicking on hyperlinks containing the 
subject line*. This is apparently all well and good because retrieving a 
message is sounds like a simple GET-friendly operation. Except that the 
act of retrieving a message often has the side effect of marking the 
message read in some way (not an unsafe operation per-se but one that 
should only be initiated by a user). So with the current HTML spec, one 
has the option of a) using hyperlinks to retrieve messages so sticking 
with a familiar and well understood UI paradigm but violating HTTP and 
breaking e.g. precaching in UAs, b) using some sort of form for retrieve 
messages so making the UI ugly and probably harder to navigate, 
especially for users familiar with  approach a), or c) requiring 
scripting for basic functionality (retrieving messages and/or marking 
read messages as read).

Allowing  would, AFAICT, solve this kind of 
problem.

*I don't claim this is the optimum UI but it is certianly much the most 
common UI I have experienced in webmail applications.

From mpt at myrealbox.com  Sat May  7 19:25:52 2005
From: mpt at myrealbox.com (Matthew Thomas)
Date: Sun, 08 May 2005 14:25:52 +1200
Subject: [whatwg] A thought: 
In-Reply-To: <427D510F.6010802@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk>
Message-ID: <427D78B0.2080608@myrealbox.com>

James Graham wrote:
>...
> Consider the example of a webmail application. These often allow 
> messages to be retrieved by clicking on hyperlinks containing the 
> subject line*. This is apparently all well and good because retrieving a 
> message is sounds like a simple GET-friendly operation. Except that the 
> act of retrieving a message often has the side effect of marking the 
> message read in some way (not an unsafe operation per-se but one that 
> should only be initiated by a user).

You're right, it's not an unsafe operation. A Web browser does this with 
links anyway, when it gives visited links a different color from 
unvisited ones. That doesn't mean it should, early-Arena-like, present 
all links as buttons.

All the Webmail application is doing is retaining visited/unvisited 
presentation across whatever computer you log in to your Webmail from -- 
which is part of the point of it being a Web application in the first 
place. So that's not really a good example of a non-idempotent action, 
and therefore not a reason for specs to condone non-idempotent links.

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

From hsivonen at iki.fi  Sun May  8 00:04:12 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 8 May 2005 10:04:12 +0300
Subject: [whatwg] A thought: 
In-Reply-To: <427D1156.8050506@colorstudy.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D1156.8050506@colorstudy.com>
Message-ID: 

On May 7, 2005, at 22:04, Ian Bicking wrote:

>> There'd be a design bug somewhere if the UI wasn't affected! When 
>> something looks like a link to, the user has a good reason to expect 
>> that following the link causes a safe retrieval operation. When 
>> something looks like a button, the user has a reason to understand 
>> that pressing the button may cause an unsafe operation.
>
> Without Web Forms and nested forms, it *is* a bug to effect the UI in 
> the ways that would be required, because isolated controls cannot be 
> put inside the context of a larger form that submits to a different 
> location and performs a different action.

The canonical approach is making one form that encloses everything on 
the page. That way, you can sprinkle submit buttons wherever you like.

> And there's other much more safe operations that also cause side 
> effects.

If there are noticeable side effects (ie. something written in a log on 
the server does not count), GET is inappropriate.

> so that their UIs better represent (in those developers' opinions) the 
> functionality they are providing.

I don't think it follows that POST links are needed but that submit 
buttons need an alternative appearance that makes them more suitable to 
be packed in a table representing Web mail messages, etc. (I am not 
suggesting that form widgets be arbitrarily stylable. That doesn't work 
nicely with UI themes developed after Windows 3.1. I am suggesting a 
style property like button-type: grid-item; for selecting for a 
predefined list of button styles.)

What you are suggesting degrades to something unsafe. Styling submit 
buttons would degrade to something safe but perhaps ugly.

> I'm just trying to explain why this "incorrect" practice is so common.

I can think of the following reasons:
1) A very large number of people doing Web stuff are clueless and 
incompetent.
2) Many people haven't gotten in the habit of making page-wide forms.
3) A link is less verbose to type than a submit button.
4) Many people find submit buttons bulky and the buttons cannot be 
universally styled to be less bulky.

I think the last one is a big deal when the graphics deezyner overrides 
RFC 2616. But things that please them belong in CSS.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From ben at benmeadowcroft.com  Sun May  8 01:39:29 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Sun, 8 May 2005 09:39:29 +0100
Subject: [whatwg] Web Apps 1.0: Editing
Message-ID: <002801c553a9$771dfe80$0202a8c0@BensPC>

Regarding the Editing section, at the moment only contentEditable is
mentioned. While this is probably the most common method, designMode
should also be included.

Perhaps have two subsections, one for full document editing (designMode)
and the other for element content editing (contentEditable). There are two
well known implementations of designMode, in IE & Mozilla, and I think
that the Editing section should cover both off them, in effect get what is
already out there written down and specified in an non-proprietary spec.

Some useful designMode links:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/desig
nmode.asp
http://www.mozilla.org/editor/midas-spec.html

--
Ben Meadowcroft
http://www.benmeadowcroft.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From ben at benmeadowcroft.com  Sun May  8 02:30:44 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Sun, 8 May 2005 10:30:44 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
Message-ID: <003901c553b0$a03fc350$0202a8c0@BensPC>

I think the web apps 1.0 specification is lacking a section on on-line
help. This is a topic which I feel the current work could helpfully
handle.

There are two types of help that I think are appropriate for web
applications, full page help and element sensitive help.

I'd suggest first that we standardise a method of linking an application
page to it's help page. This could be done by specifying a link relation
type specifically for online help. For example:

The user agent could then allow users to access the on-line help using the
browser UI, i.e. from the help menu where the application specific help
could be made available or by pressing the F1 key.

My second proposal is to standardise element context help. This will allow
a user to get context sensitive help on a particular area of the web page
when mousing over or clicking parts of the page (depending on how the OS
implements similar features I suppose). This could be enabled by allowing
elements to have a context-help attribute (similar to the context-menu
attribute proposed).

--
Ben Meadowcroft
http://www.benmeadowcroft.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From jg307 at cam.ac.uk  Sun May  8 06:28:59 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Sun, 08 May 2005 14:28:59 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <427D78B0.2080608@myrealbox.com>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>
Message-ID: <427E141B.2060604@cam.ac.uk>

Matthew Thomas wrote:
> All the Webmail application is doing is retaining visited/unvisited 
> presentation across whatever computer you log in to your Webmail from -- 
> which is part of the point of it being a Web application in the first 
> place. So that's not really a good example of a non-idempotent action, 
> and therefore not a reason for specs to condone non-idempotent links.

I should have stated explicitly that when I said "marking the message as 
read in some way" I intended that the "some way" could be more than just 
changing a message's unread flag, it could be e.g. moving the message 
from the inbox to a "Read messages" folder. Even if the message is 
"just" marked as read, this can change more than the appearance of the 
message - it can change where in the interface it is displayed (in some 
sort of virtual-folder based setup), etc.   So I don't think you can 
dismiss this as "not really a good example of a non-idempotent action" - 
it clearly /is/ non-idempotent yet representing the action as a link is 
normal and widely understood.

From ian at hixie.ch  Sun May  8 08:30:14 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 8 May 2005 15:30:14 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: Editing
In-Reply-To: <002801c553a9$771dfe80$0202a8c0@BensPC>
References: <002801c553a9$771dfe80$0202a8c0@BensPC>
Message-ID: 

On Sun, 8 May 2005, Ben Meadowcroft wrote:
> 
> Perhaps have two subsections, one for full document editing (designMode)
> and the other for element content editing (contentEditable).

Is there any difference between

...and

...?

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

From ian at hixie.ch  Sun May  8 08:35:15 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 8 May 2005 15:35:15 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <003901c553b0$a03fc350$0202a8c0@BensPC>
References: <003901c553b0$a03fc350$0202a8c0@BensPC>
Message-ID: 

On Sun, 8 May 2005, Ben Meadowcroft wrote:
> 
> There are two types of help that I think are appropriate for web 
> applications, full page help and element sensitive help.

The problem with both is discoverability. Unless we can solve that, there 
is not much point having anything in the spec.

For example, WF2 used to have a help="" attribute on form controls. We 
removed it after we got feedback that users would have no way of knowing 
that there was help available and that it would thus be mostly useless.

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

From jim.ley at gmail.com  Sun May  8 10:47:36 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Sun, 8 May 2005 18:47:36 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: 
References: <003901c553b0$a03fc350$0202a8c0@BensPC>

Message-ID: <851c8d31050508104713d6c07e@mail.gmail.com>

On 5/8/05, Ian Hickson  wrote:
> On Sun, 8 May 2005, Ben Meadowcroft wrote:
> >
> > There are two types of help that I think are appropriate for web
> > applications, full page help and element sensitive help.
> 
> The problem with both is discoverability. Unless we can solve that, there
> is not much point having anything in the spec.

For the context sensitive one we use CSS with a cursor:help  that's
the way we usually implement it from a visible perspective, I'm not
sure if there's particular value in defining an attribute to take the
help contents though, especially as this would mean it couldn't then
have mark-up, which most of the context help systems I've done do use.

adding in a link rel of help would seem a pretty low rent thing to
define, how that may be exposed in a UI though I'm less clear, I don't
like the idea of adding it to the  browsers regular help chrome -
there needs to be a distinction between browser and web-application.

Jim.

From sjoerd at w3future.com  Mon May  9 05:23:30 2005
From: sjoerd at w3future.com (Sjoerd Visscher)
Date: Mon, 09 May 2005 14:23:30 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <427E141B.2060604@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk>
Message-ID: <427F5642.60507@w3future.com>

James Graham wrote:

> I should have stated explicitly that when I said "marking the message as 
> read in some way" I intended that the "some way" could be more than just 
> changing a message's unread flag, it could be e.g. moving the message 
> from the inbox to a "Read messages" folder. Even if the message is 
> "just" marked as read, this can change more than the appearance of the 
> message - it can change where in the interface it is displayed (in some 
> sort of virtual-folder based setup), etc.   So I don't think you can 
> dismiss this as "not really a good example of a non-idempotent action" - 
> it clearly /is/ non-idempotent yet representing the action as a link is 
> normal and widely understood.
> 

What this shows is that marking a message read when it is retrieved is a 
bad idea. Retrieving a message must be done with GET, so that it can be 
cached. Setting the read state should be done seperately with POST.

Most e-mail clients only mark an item read when it's open for a few 
seconds, it's a bonus that you can do that too.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

From jg307 at cam.ac.uk  Mon May  9 08:29:05 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Mon, 09 May 2005 16:29:05 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <427F5642.60507@w3future.com>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>
Message-ID: <427F81C1.3060001@cam.ac.uk>

Sjoerd Visscher wrote:

> James Graham wrote:
>
>> I should have stated explicitly that when I said "marking the message 
>> as read in some way" I intended that the "some way" could be more 
>> than just changing a message's unread flag, it could be e.g. moving 
>> the message from the inbox to a "Read messages" folder. Even if the 
>> message is "just" marked as read, this can change more than the 
>> appearance of the message - it can change where in the interface it 
>> is displayed (in some sort of virtual-folder based setup), etc.   So 
>> I don't think you can dismiss this as "not really a good example of a 
>> non-idempotent action" - it clearly /is/ non-idempotent yet 
>> representing the action as a link is normal and widely understood.
>>
>
> What this shows is that marking a message read when it is retrieved is 
> a bad idea. Retrieving a message must be done with GET, so that it can 
> be cached. Setting the read state should be done seperately with POST.

But can you do it such that it will work without javascript? I consider 
distinguishing read/unread messages to be a basic enough feature that it 
should be possible to implement it without requiring client-side 
scripting. In this case, the obvious implementation would be a 
javascript function called when the message was recieved that performed 
a background POST request to update the read flag on the message. Is 
there a better way?

> Most e-mail clients only mark an item read when it's open for a few 
> seconds, it's a bonus that you can do that too.

That's really not necessary for a web-based client (at least one with 
the example UI) since every message is explicitly requested by a click 
(as I understand it, the timer solves the problem that keyboard 
navigation over a list of messages can result in message being marked 
read).

This example isn't unique in assosiating a document request with an 
implicit change in that status of that document to the user. Another 
example would be a web-based document management system which had a 
"recently viewed documents" section. Again, this could be implemented by 
POSTing a "the document is actually being viewed" notification but 
that's really complex compared to just putting the logic to update the 
recently viewed documents list in the request handling function. Better, 
perhaps, but much more complex and requiring client side code to do 
something that previously could be handled server side.

Clearly allowing lins with method="post" would help these situations 
although they would break precaching of the webapp.

Assuming that people dislike  and accept that not all 
state altering operations imply form controls, it might not be possible 
for HTML5 to mitigate the additional server-side complexity mandated by 
requiring that GET operations are shadowed by extra POST operations 
everytime that requesting part of a web-app has an effect on the state 
of the app. Even so, we should make it easy to implement the client side 
part of the deal, preferably in a script-free way.

-- 
"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

From ben at benmeadowcroft.com  Mon May  9 09:00:12 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Mon, 9 May 2005 17:00:12 +0100
Subject: [whatwg] Web Apps 1.0: Editing
In-Reply-To: 
Message-ID: <000a01c554b0$336dfa70$0202a8c0@BensPC>

> On Sun, 8 May 2005, Ben Meadowcroft wrote:
> > 
> > Perhaps have two subsections, one for full document editing 
> > (designMode) and the other for element content editing 
> > (contentEditable).
> 
> Is there any difference between
> 
>    
> 
> ...and
> 
>    
> 
> ...?

Well setting designMode on the body won't work, it is set on the document
object using script, document.designMode="on". Actually I guess this
should added to one of the Document interfaces described in the spec.

Other than that I'm not sure what the differences between them are, I
imagine that setting  is pretty similar to
turning on designMode, perhaps someone else can shed some light on this?

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From ian at hixie.ch  Mon May  9 09:05:36 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 9 May 2005 16:05:36 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: Editing
In-Reply-To: <000a01c554b0$336dfa70$0202a8c0@BensPC>
References: <000a01c554b0$336dfa70$0202a8c0@BensPC>
Message-ID: 

On Mon, 9 May 2005, Ben Meadowcroft wrote:
> 
> Well setting designMode on the body won't work, it is set on the 
> document object using script, document.designMode="on". Actually I guess 
> this should added to one of the Document interfaces described in the 
> spec.
> 
> Other than that I'm not sure what the differences between them are, I 
> imagine that setting  is pretty similar to 
> turning on designMode, perhaps someone else can shed some light on this?

If document.body.designMode = 'on' is equivalent to 
document.body.contentEditable = 'on' then I don't see much point in having 
both. If they are different, let me know. :-)

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

From ben at benmeadowcroft.com  Mon May  9 14:53:43 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Mon, 9 May 2005 22:53:43 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <851c8d31050508104713d6c07e@mail.gmail.com>
Message-ID: <001f01c554e1$92b000b0$0202a8c0@BensPC>

> On 5/8/05, Ian Hickson  wrote:
> > On Sun, 8 May 2005, Ben Meadowcroft wrote:
> > >
> > > There are two types of help that I think are appropriate for web 
> > > applications, full page help and element sensitive help.
> > 
> > The problem with both is discoverability. Unless we can solve that, 
> > there is not much point having anything in the spec.
> 
> For the context sensitive one we use CSS with a cursor:help  
> that's the way we usually implement it from a visible 
> perspective, I'm not sure if there's particular value in 
> defining an attribute to take the help contents though, 
> especially as this would mean it couldn't then have mark-up, 
> which most of the context help systems I've done do use.

Having mark-up would be useful. My intent was to provide a method of
showing context sensitive help which allowed for a bit more information
than displaying the title as a tool tip does. Mark-up would go well with
that idea.

Discoverability would be left to the user agents. This kind of help is
fairly well established in windows, just look at the internet options
dialog of Internet Explorer for an example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From ian at hixie.ch  Mon May  9 15:04:01 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 9 May 2005 22:04:01 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <001f01c554e1$92b000b0$0202a8c0@BensPC>
References: <001f01c554e1$92b000b0$0202a8c0@BensPC>
Message-ID: 

On Mon, 9 May 2005, Ben Meadowcroft wrote:
> 
> Discoverability would be left to the user agents.

Unless someone can come up with a way to make discoverability practical 
and usable, there is no point us having this feature. The user agent 
manufacturers have already looked at this for some time and failed to come 
up with any reasonable mechanisms, which is why we removed help="" from 
Web Forms 2. Saying it is "left up to the UAs" doesn't help us when we 
_are_ the UAs. :-)

> This kind of help is fairly well established in windows, just look at 
> the internet options dialog of Internet Explorer for an example.

Context-sensitive help is well established in modern GUIs, yes. But the 
mechanisms by which it is made available are not available or discoverable 
to the end user in a Web scenario.

For example:

 * A cursor doesn't help, since it requires the user to hover over the 
   element in order to discover there is help needed.

 * A hot key is not useful since there is no way for the user to know when
   it would work (and since in the overwhelming majority of cases it would
   do nothing, there is no reason for the user to think to try it).

 * A menu item has the same problem as a hot key.

 * A button that can be pressed like in Windows dialogs is not an option
   because such a button doesn't exist and UA vendors object to 
   introducing new buttons due to the noticable effect it has on 
   usability (based on studies that have been made).

 * An icon that appears next to controls with help is unworkable since
   the icons would interfere with the page layout and thus need to be
   stylable to satisfy authors. (Furthermore, such help is already
   possible in a backwards-compatible way simply using hyperlinks.)

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

From dean at edwards.name  Mon May  9 15:51:06 2005
From: dean at edwards.name (Dean Edwards)
Date: Mon, 09 May 2005 23:51:06 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: 
References: <001f01c554e1$92b000b0$0202a8c0@BensPC>

Message-ID: <427FE95A.7000402@edwards.name>

Ian Hickson wrote:
 > On Mon, 9 May 2005, Ben Meadowcroft wrote:
 >
 >> Discoverability would be left to the user agents.
 >
 >
 > Unless someone can come up with a way to make discoverability
 > practical and usable, there is no point us having this feature.

It is not all about user agents. I once had to build a web application
with extensive context sensitive help. The app even recalled common
entries for data fields. To make it work we invented an attribute called
"helpID". If the "help" attribute were defined we would have used that
instead.

 > Context-sensitive help is well established in modern GUIs, yes. But
 > the mechanisms by which it is made available are not available or
 > discoverable to the end user in a Web scenario.
 >
 > For example:
 >
 > * A cursor doesn't help, since it requires the user to hover over the
 >  element in order to discover there is help needed.
 >

This provides some feedback at least. But Windows apps don't tend to
provide this form of feedback anyway.

 > * A hot key is not useful since there is no way for the user to know
 > when it would work (and since in the overwhelming majority of cases
 > it would do nothing, there is no reason for the user to think to try
 > it).
 >

An application is something that might be used often. People can
discover F1 for themselves. The UA could at least let the user know that
help is available by enabling the "help" point and click icon.

 > * A menu item has the same problem as a hot key.
 >

The help menu could be updated with page specific help items.

 > * An icon that appears next to controls with help is unworkable since
 >  the icons would interfere with the page layout and thus need to be
 > stylable to satisfy authors. (Furthermore, such help is already
 > possible in a backwards-compatible way simply using hyperlinks.)
 >

A web developer might want to indicate that help is available though:

[help]::after {
   content: url(help-icon.png);
}

I think that a help attribute is useful in the realm of web
applications. Applications tend to be more complex than web documents. A
good application is sometimes only as good as its help system. Even if
UAs make nothing of it, web developers would have a standard attribute
to hook their own help systems from.

-dean

From lachlan.hunt at lachy.id.au  Mon May  9 17:38:06 2005
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 10 May 2005 10:38:06 +1000
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <851c8d31050508104713d6c07e@mail.gmail.com>
References: <003901c553b0$a03fc350$0202a8c0@BensPC>	
	<851c8d31050508104713d6c07e@mail.gmail.com>
Message-ID: <4280026E.50608@lachy.id.au>

Jim Ley wrote:
> adding in a link rel of help would seem a pretty low rent thing to
> define,

There's already a "help" relationship defined in HTML 4 [1], it doesn't 
need to be added.  Perhaps it's semantics could be refined and maybe 
give some examples of use and describe some possible implementation methods.

[1] http://www.w3.org/TR/html401/types.html#h-6.12

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

From ian at hixie.ch  Tue May 10 00:58:03 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 May 2005 07:58:03 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <427FE95A.7000402@edwards.name>
References: <001f01c554e1$92b000b0$0202a8c0@BensPC>

	<427FE95A.7000402@edwards.name>
Message-ID: 

On Mon, 9 May 2005, Dean Edwards wrote:
> >
> > Unless someone can come up with a way to make discoverability 
> > practical and usable, there is no point us having [help].
> 
> It is not all about user agents. I once had to build a web application 
> with extensive context sensitive help. The app even recalled common 
> entries for data fields. To make it work we invented an attribute called 
> "helpID". If the "help" attribute were defined we would have used that 
> instead.

I don't see anything wrong with a Web application using custom attributes 
(preferably clearly prefixed or in a custom namespace) to store 
information like this. But I don't see the value in making the attribute 
for such a case standard. It would restrict what you could do with it, for 
one -- say the Web app wanted to store just a number for the help. Or just 
a URI. Or two URIs. Or an IDREF. Or a string. If we had an attribute, we'd 
have to define what it was, thus either blocking innovation, or using up 
an attribute for no good reason.

> [...reasons why the things I listed might work sometimes...]

Yes, all the things I listed are plausible solutions, that's why I listed 
them. But they're not good _enough_, IMHO.

> I think that a help attribute is useful in the realm of web 
> applications. Applications tend to be more complex than web documents. A 
> good application is sometimes only as good as its help system. Even if 
> UAs make nothing of it, web developers would have a standard attribute 
> to hook their own help systems from.

I don't see the advantage of having a standard way of doing something 
non-standard. It wouldn't improve interoperability.

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

From fora at annevankesteren.nl  Tue May 10 03:50:26 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 10 May 2005 12:50:26 +0200
Subject: [whatwg] [wf2] Note about XML attribute value handling
Message-ID: <428091F2.1000201@annevankesteren.nl>

Could we perhaps make a note about this in the WF2 specification:

Preferably somewhere close to . My weblog used to run 
on XHTML and previewed weblog comments where stored inside the VALUE 
attribute of a hiddenINPUT element (actually, that is still the case). 
As XHTML means the above mentioned XML rule applies all formatting got 
lost. That was a major problem for white-space significant replies. 
(Replies using the PRE element.)

I think it might make sense for the specification to point that out. And 
perhaps provide a way in a future update to the specification to have a 
hidden TEXTAREA. (Such a TEXTAREA can be implemented now using: 
foo.)

There was a similar problem with the XHTML admin of Movable Type as 
described here:

-- 
  Anne van Kesteren

From markwubben at gmail.com  Tue May 10 05:27:20 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Tue, 10 May 2005 14:27:20 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <427F81C1.3060001@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
Message-ID: <3b24e6c505051005276bb44a5e@mail.gmail.com>

On 5/9/05, James Graham  wrote:
> But can you do it such that it will work without javascript? I consider
> distinguishing read/unread messages to be a basic enough feature that it
> should be possible to implement it without requiring client-side
> scripting. In this case, the obvious implementation would be a
> javascript function called when the message was recieved that performed
> a background POST request to update the read flag on the message. Is
> there a better way?
Well, you could load an iframe with a redirect meta element, which
will then, uhm, use GET to modify the state. That's all I can think
off, though.

From mikko.rantalainen at peda.net  Tue May 10 13:49:57 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Tue, 10 May 2005 23:49:57 +0300
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <428091F2.1000201@annevankesteren.nl>
References: <428091F2.1000201@annevankesteren.nl>
Message-ID: <42811E75.4030907@peda.net>

Anne van Kesteren wrote:
> Could we perhaps make a note about this in the WF2 specification:
>   
> 
> Preferably somewhere close to . My weblog used to run 
> on XHTML and previewed weblog comments where stored inside the VALUE 
> attribute of a hiddenINPUT element (actually, that is still the case). 
> As XHTML means the above mentioned XML rule applies all formatting got 
> lost. That was a major problem for white-space significant replies. 
> (Replies using the PRE element.)

 works just fine with existing UAs even when one 
uses application/xhtml+xml provided that all meaningful whitespace has 
been converted to entities. 
 for LF,  for CR and so on. PHP, 
for example, provides function htmlentities() exactly for this purpose.

It would be nice to have a note about that somewhere in the spec. I too 
found it hard way.

-- 
Mikko

From fora at annevankesteren.nl  Tue May 10 16:37:14 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Wed, 11 May 2005 01:37:14 +0200
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <42811E75.4030907@peda.net>
References: <428091F2.1000201@annevankesteren.nl> <42811E75.4030907@peda.net>
Message-ID: <428145AA.6000803@annevankesteren.nl>

Mikko Rantalainen wrote:
>> Could we perhaps make a note about this in the WF2 specification:
>>   
>>
>> Preferably somewhere close to . My weblog used to 
>> run on XHTML and previewed weblog comments where stored inside the 
>> VALUE attribute of a hiddenINPUT element (actually, that is still the 
>> case). As XHTML means the above mentioned XML rule applies all 
>> formatting got lost. That was a major problem for white-space 
>> significant replies. (Replies using the PRE element.)
>
>  works just fine with existing UAs even when one 
> uses application/xhtml+xml provided that all meaningful whitespace has 
> been converted to entities. 
 for LF,  for CR and so on. PHP, 
> for example, provides function htmlentities() exactly for this purpose.

Really? Why would 'htmlentities' be useful in an XML environment? Also, 
getting HTML *entities* in your XML document doesn't seem like a good thing.

(I'm aware of possible solutions. It's just that you don't normally 
think of this. Even Tim Bray - editor of the XML specification - called 
it "broken as designed".)

-- 
  Anne van Kesteren

From mikko.rantalainen at peda.net  Tue May 10 22:48:32 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Wed, 11 May 2005 08:48:32 +0300
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <428145AA.6000803@annevankesteren.nl>
References: <428091F2.1000201@annevankesteren.nl> <42811E75.4030907@peda.net>
	<428145AA.6000803@annevankesteren.nl>
Message-ID: <42819CB0.702@peda.net>

Anne van Kesteren wrote:
> Mikko Rantalainen wrote:
>> works just fine with existing UAs even when one 
>>uses application/xhtml+xml provided that all meaningful whitespace has 
>>been converted to entities. 
 for LF,  for CR and so on. PHP, 
>>for example, provides function htmlentities() exactly for this purpose.
> 
> Really? Why would 'htmlentities' be useful in an XML environment? Also, 
> getting HTML *entities* in your XML document doesn't seem like a good thing.

Yes, you're right that in some cases that results in problems. That's 
because htmlentities() returns entity references like """; if it 
*only* returned numeric character references like """ it would work 
just fine despite the fact that it's designed for HTML. Those numbers 
refer to UNICODE character points. Als note that XML normalization rules 
state that "For a character reference, append the referenced character 
to the normalized value" but "For an entity reference, recursively apply 
step 3 of this algorithm to the replacement text of the entity." [1] 
Real world  user agent behavior might differ and that's what I'm really 
interested in.

That said, I'm using my own function to correctly encode special 
characters to numerical character references, but the point remains the 
same. It doesn't matter if you put stuff in the contents of an element 
or inside an attribute value; you *have to* encode the string to hide 
special characters. If you put the string inside an attribute, the 
encoding must also include all whitespace and quotation characters in 
addition to characters like "<", "&" and ">".

You cannot put a random string between  and  tags 
either and expect to get a valid XML fragment as a result.

[1] http://www.w3.org/TR/REC-xml/#AVNormalize

-- 
Mikko

From fora at annevankesteren.nl  Wed May 11 02:48:51 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Wed, 11 May 2005 11:48:51 +0200
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <42819CB0.702@peda.net>
References: <428091F2.1000201@annevankesteren.nl>
	<42811E75.4030907@peda.net>	<428145AA.6000803@annevankesteren.nl>
	<42819CB0.702@peda.net>
Message-ID: <4281D503.5030301@annevankesteren.nl>

Mikko Rantalainen wrote:
> You cannot put a random string between  and  tags 
> either and expect to get a valid XML fragment as a result.

True, that's why htmlspecialchars was created (in PHP). (Note that there 
are five predefined entities in XML of which " is one.)

-- 
  Anne van Kesteren

From markwubben at gmail.com  Wed May 11 03:28:25 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Wed, 11 May 2005 12:28:25 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <3b24e6c505051005276bb44a5e@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
Message-ID: <3b24e6c505051103282661831e@mail.gmail.com>

I think the following things are going on here:
1) Because of easier styling links have been used for non-idempotent actions
2) The semantics defining such an action are located in the URI,
instead of HTTP. Think `/delete/$id`
3) A way to solve this would be to use buttons with good styling. The
styling will be hard to do cross-browser
4) Another way is to use ``

I'd like to expend on point 4. It would be rather easy to create an
implementation for older browsers. The problem, however, occurs when
the `href` attribute points to the non-idempotent URI: without JS
providing the compatibility, it would still evoke a non-idempotent
action on the server. A way to solve this is by linking the `href` to
a URI which asks for confirmation (through a form), while using an
`action` attribute to specify the location of the non-idempotent
action. If the spec states that `href` must not equal `action`, we
have a solution for the problem.

An example:

    delete

What do you think?

From kornel at ldreams.net  Wed May 11 03:50:02 2005
From: kornel at ldreams.net (Kornel Lesinski)
Date: Wed, 11 May 2005 11:50:02 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <3b24e6c505051103282661831e@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk> <427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk> <427F5642.60507@w3future.com>
	<427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>
Message-ID: 

On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
wrote:

> An example:
>
>      method="post">delete
>
> What do you think?

That it doesn't look like data to send using POST method.
I'm afraid that in most cases it will be used as:

delete

So there must be something that requires authors to use it properly...

-- 
regards, Kornel Lesinski

From markwubben at gmail.com  Wed May 11 05:24:22 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Wed, 11 May 2005 14:24:22 +0200
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

Message-ID: <3b24e6c505051105244c825ced@mail.gmail.com>

On 5/11/05, Kornel Lesinski  wrote:
> That it doesn't look like data to send using POST method.
> I'm afraid that in most cases it will be used as:
> 
> delete
> 
> So there must be something that requires authors to use it properly...

Hmm, interesting. Perhaps the `href` must link to a resource outside
this page? This stuff is getting way too complicated....

From hsivonen at iki.fi  Wed May 11 06:42:35 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 11 May 2005 16:42:35 +0300
Subject: [whatwg] RELAX NG + Schematron schemas?
Message-ID: <93354aff6755fba0042414ef13e7a82e@iki.fi>

What's the situation with WHAT WG schema deliverables? Does WHAT WG 
even consider them WHAT WG deliverables? At some point fantasai was 
working on an SGML DTD. Is anyone planning on writing RELAX NG + 
Schematron schemas for the WHAT WG specs?

Has anyone assessed the nature of the machine checkable conformance 
criteria in terms of checkability using RELAX NG and the Schematron? 
How significant and numerous are the criteria that cannot be checked 
using RELAX NG of the Schematron?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From ian at hixie.ch  Wed May 11 10:05:47 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 May 2005 17:05:47 +0000 (UTC)
Subject: [whatwg] RELAX NG + Schematron schemas?
In-Reply-To: <93354aff6755fba0042414ef13e7a82e@iki.fi>
References: <93354aff6755fba0042414ef13e7a82e@iki.fi>
Message-ID: 

On Wed, 11 May 2005, Henri Sivonen wrote:
>
> What's the situation with WHAT WG schema deliverables? Does WHAT WG even 
> consider them WHAT WG deliverables? At some point fantasai was working 
> on an SGML DTD. Is anyone planning on writing RELAX NG + Schematron 
> schemas for the WHAT WG specs?
> 
> Has anyone assessed the nature of the machine checkable conformance 
> criteria in terms of checkability using RELAX NG and the Schematron? How 
> significant and numerous are the criteria that cannot be checked using 
> RELAX NG of the Schematron?

Anyone who wants to work on such support files is welcome to do so and 
will be provided with access to the syntax.whatwg.org site to make them 
available. Personally I won't be spending any time on them. The spec won't 
be giving any syntax support files normative status (since doing so would 
be redundant with teh spec prose).

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

From gavin at tmpei.com  Wed May 11 04:52:43 2005
From: gavin at tmpei.com (Gavin Anderegg)
Date: Wed, 11 May 2005 08:52:43 -0300
Subject: [whatwg] Correction for the Web Applications 1.0 Document
Message-ID: <2E4D1A9B-6887-40EB-9898-81F1E72E229A@tmpei.com>

Section 2.1.5 - Class
     In the following sentence there is a duplicate "separated":
     The value must be a list of zero or more words (consisting of  
one or more non-space characters) separated separated by one or more  
spaces.

Great document, by the way. Keep up the good work.

--------------
Gavin Anderegg
TechnoMedia PEI

Tel: 902.368.3043
Fax: 902.566.5447

From ian at hixie.ch  Wed May 11 10:08:24 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 May 2005 17:08:24 +0000 (UTC)
Subject: [whatwg] Re: Correction for the Web Applications 1.0 Document
In-Reply-To: <2E4D1A9B-6887-40EB-9898-81F1E72E229A@tmpei.com>
References: <2E4D1A9B-6887-40EB-9898-81F1E72E229A@tmpei.com>
Message-ID: 

On Wed, 11 May 2005, Gavin Anderegg wrote:
> 
> Section 2.1.5 - Class
>     In the following sentence there is a duplicate "separated":
>     The value must be a list of zero or more words (consisting of one or more
> non-space characters) separated separated by one or more spaces.
> 
> Great document, by the way. Keep up the good work.

Thanks, fixed.

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

From fantasai.lists at inkedblade.net  Wed May 11 20:50:25 2005
From: fantasai.lists at inkedblade.net (fantasai)
Date: Wed, 11 May 2005 23:50:25 -0400
Subject: [whatwg] [WA1] Literals and Actions, comments on inline markup
Message-ID: <4282D281.8030905@inkedblade.net>

Literals
--------

   There doesn't seem to be any appropriate markup for literals in HTML.

   For example:

      The words 'elude' and 'allude' are frequently mixed up.

   The formatting for such elements varies freely: I've seen single quotes
   (which I prefer), double quotes, and italics. It is therefore stylistic,
   and should be controlled (or controllable) with CSS.

Actions
-------

   I can't figure out any appropriate markup for things like

      The pattern, I said, not the text! *runs away*
                                         ^^^^^^^^^^^
                                            this.

   It's not used in formal specs or professional web apps, but,
   it's frequently used in less formal discussions.

Links ()
-----------

   * # If the a element has no href attribute, then the element is a placeholder

     This is nice.

   * Scanning quickly through the texts for  and , I didn't see a
     discussion of their differing semantics. Chris Hoess sums up an explanation
     you gave to him four years ago in bug 87428:

     https://bugzilla.mozilla.org/show_bug.cgi?id=87428#c43

     "Ian actually managed to convince me last night on IRC that there's a reason
      to have different UI for  and .  The first is
      a page link; the relationship denoted in the link element applies for the
      whole page. The second is a context link; the relationship denoted applies
      to the immediate context of the anchor element."

     I would like to see this mentioned in the spec.

   * # The type attribute ... is purely advisory.

     Should it factor into the algorithm for determining a file's content type
     when meta-information is not there, or is that outside the scope of this
     spec?

   * One of the previous uses of  was to mark a destination anchor with
     'name'. For the most part, the 'id' attribute has made this use obsolete.
     I'm wondering, though, what would be the appropriate WA1 markup to use
     for anchoring to a bit of text that is not otherwise marked-up?

     For example, I use  to mark sentence fragments in
       http://fantasai.inkedblade.net/weblog/2003/marketing/tab-logic#what
     so that I can refer to them in the discussion. (I'll admit the styling
     is not well-chosen... numbering them with CSS would have been ideal.)

Emphasis ()
---------------

   # The em element represents stress emphasis of its contents.

   I would render 'stress emphasis' as 'emphatic stress'.

   The example, btw, is *excellent*.

Strength ()
-------------------

   Subtle change from HTML4 semantics, and I think I approve. The example,
   again, is excellent.

   The contrast between
     # Changing the importance of a piece of text with the strong element
     # does not change the meaning of the sentence.
   and
     # The placement of emphasis changes the meaning of the sentence.
   is brilliant.

Highlighting ()
------------------

   # The m element represents a run of text marked or highlighted.

   This is cool.

   Another use for it would be in highlighting important phrases in
   documents optimized for skimming. (Or buzzwords in marketing hype
   like at the top of
     http://fantasai.inkedblade.net/weblog/2003/marketing/about
   , not that I approve of such language.)

   I'd say the distinction between highlighting and  & 
   is that highlighting does not change the reading of the text when
   you're reading straight through, it just helps you find the
   bits you should pay attention to.

Small Print ()
---------------------

   # The small element represents small print (part of a document often
   # describing legal restrictions, such as copyrights or other
   # disadvantages), or other side comments.

   Is  appropriate for the example at the end of
     http://fantasai.inkedblade.net/weblog/2003/big-small/
   ?

   # Note: The small element does not "de-emphasise" or lower the
   # importance of text emphasised by the em element or marked as
   # important with the strong element.

   Does  de-emphasize the text at all? This paragraph implies
   that it does, except within  or , but it is not clear
   from the definition.

Defining Instances ()
--------------------------

   # The paragraph, definition list group, or section that contains the
   # dfn element contains the definition for the term given by the
   # contents of the dfn element.

   I have very often seen defining instances whose definition is limited
   to just the sentence in which it appears. The rest of the paragraph
   is related discussion, of course, but nothing I would pull out into
   a glossary.

   Also, this sentence implies that  should be used with , but
   I don't see what you mean by that implication. There are no examples
   with  in the  section. If I were to take that idea and run
   with it, I'd say that if a  contains a , then the 
 is
   defining the term contained within the  only; the rest of the

 is extra meta-information. E.g.

term (t?rm)
    ...

Instance of Term ()
----------------------

   # The i element represents an instance of the use of a term, such as
   # a taxonomic designation, technical term, an idiomatic phrase from
   # another language, or similar.

   I think this is a great definition for an element we really need to
   have in HTML.

   However, I am not convinced that leaving HTML with no purely
   presentational tag for italics is a good idea. That leaves nothing
   for people who do not have the time, opportunity, or patience to
   learn/semantic/ HTML markup and for simplistic authoring UAs. 
   and  are often the first -- or only -- tags people learn, and
   they are among the few tags understood by most commenting systems.
   Whatever semantics you declare here for  will be flagrantly
   ignored by all but a minority of authors. How is defining 's
   semantics this way useful?

Inline Code Fragments ()
------------------------------

   The example should be of an inlined code fragment, not a block-inline
   tag combination pretending to be a block element.

Sample Output ()
----------------------

   # Nested samp and kbd  elements allow for the styling of specific elements
   # of the sample output using a stylesheet.
   #
   # jdoe at mowmow:~$ssh demo.example.com
   # Last login: Tue Apr 12 09:10:17 2005 from mowmow.example.com on pts/1
   # Linux demo 2.6.10-grsec+gg3+e+fhs6b+nfs+gr0501+++p3+c4a+gr2b-reslog-v6.189
   # #1 SMP Tue Feb 1 11:22:36 PST 2005 i686 unknown
   # jdoe at mowmow:~$ _

   This is an interesting example. The outer  can be interpreted as
   "output of terminal" and the inner one as "output of shell", which seems
   all well and good.

   However, what if I wanted to colorize the output of Mozilla's layout
   regression tests?

   Running verify test for E:\moz_src\mozilla\layout\html\tests\block\rtest.lst.
   Writing regression data to
     E:\moz_src\mozilla\layout\html\tests\table\core\verify\standards1.rgd
   Comparing to regression data from
     E:\moz_src\mozilla\layout\html\tests\table\core\baseline\standards1.rgd
   frame bbox mismatch: 0,26437,4824,600 vs. 0,26437,4872,600
   Node 1:
     TableOuter(table)(144) 0x10004 0,26437,4824,600, |null attr|-16777216|left:
     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw top:
     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top: 1[0x1]enum
     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum 0|1
     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw  Null
     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0 8
     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
   Node 2:
     TableOuter(table)(144) 0x10004 0,26437,4872,600, |null attr|-16777216|left:
     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw top:
     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top: 1[0x1]enum
     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum 0|1
     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw  Null
     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0 8
     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
   frame bbox mismatch: 0,0,4824,600 vs. 0,0,4872,600

   (This makes more sense if it's not wrapped. See
     http://www.mozilla.org/newlayout/doc/regression_tests.html
    But not much more.)

   I would want to mark up
     - the Running veryify test line
     - the Writing regression data line
     - the Comparing to line
     - the filenames in each of those
     - the frame bbox mismatch label
     - its vs. value
     - the node labels
     - the frame type (TableOuter(table))
     - each name-value pairing in the output line

   However, it does not seem to me that marking these with  would be the
   right thing to do any more than marking up function names, variable names,
   and keywords in a code sample with  would be the right thing to do.
   Either those are both right, or they're both wrong.

   Please specify.

User Input ()
------------------

   # The kbd element represents user input (typically keyboard input,
   # although it may also be used to represent other input, such as
   # voice commands).

   Can we have some examples for marking up GUI elements? E.g.

     Don't press the Emergency button.

     Go to Tools > Options... and select the General tab. Change
     the Indentation Type radio from Tabs to Spaces, check the
     Auto-Indent box, and type 4 into the Indent Spaces box.

   Those should be marked up so that one can use a style sheet to
     - make "Emergency" look like a button
     - display "Tools" and "Options" in the menu font
     - make "General" look like a tab
     - make "4" look like it's typed inside a text input
     - and use the appropriate label fonts for "Indentation Type",
       "Tabs", "Spaces", "Auto-Indent", and "Indent Spaces".

   # When the kbd element is nested inside another kbd element, it
   # represents an actual key or other single unit of input as
   # appropriate for the input mechanism.

   So "Press the Esc key" would be marked up as
     Press the Esc key
   ?

Superscripts and Subscripts (^{and _{)
---------------------------------------------

   # marking up mathematical, but

   "mathematical" should be replaced with a noun.

Quotes ()
------------

   * You should probably add some notes on presentation, esp. wrt
     quote mark generation.

   * You need to explain that  should only be used for actual
     quotations, not as a shortcut for “ and ”. (I've
     seen it abused that way, but I forget where..)

General
-------

   Overall, I'm really, really impressed with what you've done here.

   One nit: Please provide actual titles for the sections (as I have
   done here) rather than just putting the element name. (But don't
   leave out the element name either.)

~fantasai

From fantasai.lists at inkedblade.net  Wed May 11 21:14:23 2005
From: fantasai.lists at inkedblade.net (fantasai)
Date: Thu, 12 May 2005 00:14:23 -0400
Subject: [whatwg] [WA1] Literals and Actions, comments on inline markup
In-Reply-To: <4282D281.8030905@inkedblade.net>
References: <4282D281.8030905@inkedblade.net>
Message-ID: <4282D81F.70900@inkedblade.net>

fantasai wrote:
> 
> Strength ()
> -------------------
> 
>   Subtle change from HTML4 semantics, and I think I approve. The example,
>   again, is excellent.
> 
>   The contrast between
>     # Changing the importance of a piece of text with the strong element
>     # does not change the meaning of the sentence.
>   and
>     # The placement of emphasis changes the meaning of the sentence.
>   is brilliant.

Figured out what was bothering me about the first sentence.

   # The strong element represents strong importance for its contents.

Change "strong importance" to "importance stress". This also puts it
in parallel with "emphatic stress".

~fantasai

From Maniac at SoftwareManiacs.Org  Thu May 12 03:07:43 2005
From: Maniac at SoftwareManiacs.Org (Maniac)
Date: Thu, 12 May 2005 14:07:43 +0400
Subject: [whatwg] [WA1] Literals and Actions, comments on inline markup
In-Reply-To: <4282D281.8030905@inkedblade.net>
References: <4282D281.8030905@inkedblade.net>
Message-ID: <42832AEF.4070704@SoftwareManiacs.Org>

fantasai wrote:

> Literals
> --------
>
>   There doesn't seem to be any appropriate markup for literals in HTML.
>
>   For example:
>
>      The words 'elude' and 'allude' are frequently mixed up.
>
>   The formatting for such elements varies freely: I've seen single quotes
>   (which I prefer), double quotes, and italics. It is therefore 
> stylistic,
>   and should be controlled (or controllable) with CSS.

Not so freely in fact. For example in russian typography these things 
should be marked up only with quotes (U+00AB and U+00BB). Simple double 
quotes (") are however more widely used and single quotes (') are also 
used but mainly in tech-savvy environment. But speaking of italics as a 
way of marking up literals - this just won't be understood within 
majority of people. Italics in russian typography is quite rare and may 
be associated perhaps only with emphasis, not literals.

That said I agree that it should be controllable with CSS. But since 
it's not entirely stylistic it shouldn't be controlled only by stylesheet.

From sjoerd at w3future.com  Thu May 12 12:01:21 2005
From: sjoerd at w3future.com (Sjoerd Visscher)
Date: Thu, 12 May 2005 21:01:21 +0200
Subject: [whatwg] A thought:}}
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>

Message-ID: <4283A801.8040601@w3future.com>

Kornel Lesinski wrote:
> On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
> wrote:
> 
>> An example:
>>
>>     > method="post">delete
>>
>> What do you think?
> 
> 
> That it doesn't look like data to send using POST method.
> I'm afraid that in most cases it will be used as:
> 
> delete
> 
> So there must be something that requires authors to use it properly...
> 
Why? People write browser/standard specific things all the time. If it 
works for them, who cares?

I like this proposal because it actually solves the original problem, 
without a need for Google to change their accelerator code.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

From jg307 at cam.ac.uk  Thu May 12 15:05:37 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Thu, 12 May 2005 23:05:37 +0100
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>

Message-ID: <4283D331.7080803@cam.ac.uk>

Kornel Lesinski wrote:
> On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
> wrote:
> 
>> An example:
>>
>>     > method="post">delete
>>
>> What do you think?
> 
> 
> That it doesn't look like data to send using POST method.
> I'm afraid that in most cases it will be used as:
> 
> delete
> 
> So there must be something that requires authors to use it properly...
> 

Wouldn't it work if a single URL in the the href attribute was used for 
both request types? i.e. simply
delete
The serverside application would be expected to deal with GET requests 
on the URI in a sane way e.g. returning a confirmation page with a 
POSTable form on it - this would account for legacy clients and allow 
tools like GWA to work.

From michael at quuxo.com  Thu May 12 20:28:10 2005
From: michael at quuxo.com (Michael Gratton)
Date: Fri, 13 May 2005 12:58:10 +0930
Subject: [whatwg] A thought: 
In-Reply-To: <4283A801.8040601@w3future.com>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
Message-ID: <15cb675b6b43eba69145b1873029306a@quuxo.com>

[resent, to the list this time]

On 13/05/2005, at 4:31, Sjoerd Visscher wrote:
>
> I like this proposal because it actually solves the original problem, 
> without a need for Google to change their accelerator code.

No, it won't in many/most cases.

The Google Accelerator (and every other spidering tool, such as wget) 
will still fetch those links using GET because they are not aware of 
the new semantics implied by method="post". Most web applications I 
have seen (certainly nearly every one written in Java) do not 
differentiate between parameters provided by a GET or a POST; you can 
do either and the application will work in the same way. So the 
Accelerator will keep on fetching those links and applications will 
still perform some non-idempotent action and we will still have the 
same problem.

Since implementing this proposal to solve the Google Accelerator 
problem means both modifying existing UA to support it and/or fixing 
the web apps that are broken anyway, I would rather just fix the broken 
web apps in the first place and not implement this proposal.

/Mike

-- 
Michael Gratton, Software Architect.
Quuxo Software 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: 

From mikko.rantalainen at peda.net  Thu May 12 23:31:30 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Fri, 13 May 2005 09:31:30 +0300
Subject: [whatwg] A thought: 
In-Reply-To: <4283D331.7080803@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>	
	<4283D331.7080803@cam.ac.uk>
Message-ID: <428449C2.7090400@peda.net>

James Graham wrote:
> Kornel Lesinski wrote:
>>On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
>>wrote:
>>>
>>>    >>method="post">delete
>>
>>That it doesn't look like data to send using POST method.
>>I'm afraid that in most cases it will be used as:
>>
>>delete
> 
> Wouldn't it work if a single URL in the the href attribute was used for 
> both request types? i.e. simply
> delete
> The serverside application would be expected to deal with GET requests 
> on the URI in a sane way e.g. returning a confirmation page with a 
> POSTable form on it

+1

Server can figure out if the request has been made with GET or POST 
and it can behave correctly using to that information.

During transition phase scripting can be used to POST the delete 
operation or scripting could be used to add something to the GET 
request (like "?jsconfirmdone=1"). Details doesn't matter here as 
we're talking about workarounds that make the thing work without the 
confirmation page in UAs that don't support this new attribute 
"method". Default fallback behavior would be to use confirmation 
page generated by the server.

Broken server apps will be still broken and there's nothing we can 
write in the spec that forces every developer to create perfect 
applications.

-- 
Mikko

From ian at hixie.ch  Fri May 13 03:31:23 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 May 2005 10:31:23 +0000 (UTC)
Subject: [whatwg] Re: Forming Opinions
Message-ID: 

(In response to
   http://www.xml.com/pub/a/2005/04/20/deviant.html
   http://www.xml.com/pub/a/2005/04/27/deviant.html
   http://www.xml.com/pub/a/2005/05/04/deviant.html
   http://www.xml.com/pub/a/2005/05/11/deviant.html
...)

First of all, thanks for your comments!

I've skipped past the less concrete remarks, since they mostly relate to 
general issues of what direction Web browsers should be going in, whereas 
the WHATWG charter starts off with an assumption as to what direction they 
should go in, letting other directions be discussed and used in parallel.

You wrote:
>
> Section 2 starts off saying "At the heart of any form lies the form 
> controls", which seems like a poor choice of words. 

Agreed. Removed.

> Another useful resource is description of common features that are 
> widely implemented in IE and other browsers, but not formally documented 
> as a standard anywhere. In this camp is the autocomplete attribute. 
> There are likely others as well, but the arrangement of the document 
> makes it difficult to see which features fall into this category.

True. I have made a note to add an appendix in future specs that detail 
which parts are known to have been widely implemented already.

> Based on that experience, I've concluded that [the repetition] section 
> doesn't live up to one of the primary requirements of WF2: that it 
> should provide familiar ground for existing developers.

I agree. Unfortunately we haven't really seen a better proposal. 
Suggestions welcome! (The XForms model is unfortunately not really an 
option here for several reasons; in the first place it is not backwards 
compatible, not even to the small extent that the WF2 model is, and in the 
second place it is poorly defined in terms of the DOM, which makes it hard 
to integrate into the general HTML forms and CSS styling model.)

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

From hsivonen at iki.fi  Fri May 13 06:47:01 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 13 May 2005 16:47:01 +0300
Subject: [whatwg] A thought: 
In-Reply-To: <15cb675b6b43eba69145b1873029306a@quuxo.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk> <427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk> <427F5642.60507@w3future.com>
	<427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>
Message-ID: 

On May 13, 2005, at 06:28, Michael Gratton wrote:

> Most web applications I have seen (certainly nearly every one written 
> in Java) do not differentiate between parameters provided by a GET or 
> a POST; you can do either and the application will work in the same 
> way.

Of the various server-side frameworks available Java servlets are among 
the most cluefully designed when it comes to getting HTTP right. If a 
developer calls doPost from doGet, there is nothing the framework 
designer can do about it.

I'm still -1 on changing the specs to accommodate people who have been 
ignoring RFC 2616.

By the way, the main problem with the publicized case was that their 
non-idempotent GETs did not have query strings. Usually the people who 
don't respect the idempotency of GETs also have crufty URLs with query 
strings so that a robot can apply heuristics to avoid query strings.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From michael at quuxo.com  Fri May 13 07:42:04 2005
From: michael at quuxo.com (Michael Gratton)
Date: Sat, 14 May 2005 00:12:04 +0930
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>

Message-ID: <1115995324.7233.13.camel@localhost.localdomain>

On Fri, 2005-05-13 at 16:47 +0300, Henri Sivonen wrote:
> Of the various server-side frameworks available Java servlets are among 
> the most cluefully designed when it comes to getting HTTP right. If a 
> developer calls doPost from doGet, there is nothing the framework 
> designer can do about it.

True. I am not bashing the Servlet API, I am just pointing out common
practise. The Struts framework, for example, is a very popular Java
framework built on the Servlet API but it calls the same processing
method for both GETs and POSTs. Very poor form.

Also, I think that because it uses same API to access parameters
specified by both GET and POST requests it tends to encourage this sort
of behaviour. But this is probably OT.

> I'm still -1 on changing the specs to accommodate people who have been 
> ignoring RFC 2616.

Ditto.

> Usually the people who 
> don't respect the idempotency of GETs also have crufty URLs with query 
> strings so that a robot can apply heuristics to avoid query strings.

Which of course might punish sites (or users of sites) that have valid
uses for query strings.

/Mike.

-- 
Michael Gratton, Software Architect.
Quuxo Software 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: 

From jg307 at cam.ac.uk  Fri May 13 08:56:44 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Fri, 13 May 2005 16:56:44 +0100
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>

Message-ID: <4284CE3C.4040606@cam.ac.uk>

Henri Sivonen wrote:

> On May 13, 2005, at 06:28, Michael Gratton wrote:
>
>> Most web applications I have seen (certainly nearly every one written 
>> in Java) do not differentiate between parameters provided by a GET or 
>> a POST; you can do either and the application will work in the same way.
>
>
> Of the various server-side frameworks available Java servlets are 
> among the most cluefully designed when it comes to getting HTTP right. 
> If a developer calls doPost from doGet, there is nothing the framework 
> designer can do about it.
>
> I'm still -1 on changing the specs to accommodate people who have been 
> ignoring RFC 2616.

That seems to be based on the belief that all things which look like 
links must correspond to idempotent actions. I don't think this is true 
and, in general, think that trying to couple the user interface to the 
underlying protocol is a bad idea.

-- 
"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

From kornel at ldreams.net  Fri May 13 09:43:59 2005
From: kornel at ldreams.net (Kornel Lesinski)
Date: Fri, 13 May 2005 17:43:59 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <4284CE3C.4040606@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk> <427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk> <427F5642.60507@w3future.com>
	<427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>

	<4284CE3C.4040606@cam.ac.uk>
Message-ID: 

On Fri, 13 May 2005 16:56:44 +0100, James Graham  wrote:

> That seems to be based on the belief that all things which look like  
> links must correspond to idempotent actions.

Yes, that is exactly the idea behind it.

> I don't think this is true and, in general, think that trying to couple  
> the user interface to the underlying protocol is a bad idea.

That is user interface which represents what protocol does.

Links are not coupled with http GET method. You may link to any resource  
using any protocol, but following a link should not have side-effects - by  
design.

Web applications usually don't have undo, so IMHO it should be clear that  
click on certain UI elements has side effects.

Difference between radio buttons and checkboxes is quite clear by looks of  
them. There should be difference between links and buttons as well,  
because one _goes_ somewhere, and another  _does_ something.

In case with marking e-mail as read that would be element that _goes_  
somewhere AND _does_ something, so I think that  might be suitable in  
this case.

How about requiring non-idempotent links to have rel="nofollow"? That  
might solve the "google accelerator problem".

-- 
regards, Kornel Lesinski

From olav at olav.dk  Fri May 13 13:28:56 2005
From: olav at olav.dk (=?ISO-8859-1?Q?Olav_Junker_Kj=E6r?=)
Date: Fri, 13 May 2005 22:28:56 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <4284CE3C.4040606@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>	
	<4284CE3C.4040606@cam.ac.uk>
Message-ID: <42850E08.2030505@olav.dk>

James Graham wrote:
> That seems to be based on the belief that all things which look like 
> links must correspond to idempotent actions. I don't think this is true 
> and, in general, think that trying to couple the user interface to the 
> underlying protocol is a bad idea.

No, its a great idea! ;-)

Most users dont know anything about POST or GET, but I believe its a 
common expectation that you can always safely click links (and then 
press back to return), while you should think twice about pressing a 
form button, since it might indicate that you agree to something or 
wants to buy something or subscribe to a mailinglist or whatever.

I think this coupling between protocol and UI is one of the great ideas 
of the web.

So a link which performs a unsafe action is not just wrong according to 
HTTP, its also bad UI.

regards
Olav Junker Kj?r

From jg307 at cam.ac.uk  Fri May 13 14:02:24 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Fri, 13 May 2005 22:02:24 +0100
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>		<4284CE3C.4040606@cam.ac.uk>

Message-ID: <428515E0.5020408@cam.ac.uk>

Kornel Lesinski wrote:

> On Fri, 13 May 2005 16:56:44 +0100, James Graham  wrote:
>
>> That seems to be based on the belief that all things which look like  
>> links must correspond to idempotent actions.
>
>
> Yes, that is exactly the idea behind it.
>
>> I don't think this is true and, in general, think that trying to 
>> couple  the user interface to the underlying protocol is a bad idea.
>
>
> That is user interface which represents what protocol does.
>
> Links are not coupled with http GET method. You may link to any 
> resource  using any protocol, but following a link should not have 
> side-effects - by  design.
>
> Web applications usually don't have undo, so IMHO it should be clear 
> that  click on certain UI elements has side effects.

But that's already unclear. Given a button on a web page it's impossible 
(without context) to tell if it has side effects or not. If I click the 
"Search" button on Google, it has no side effects yet the "Submit Order" 
(or whatever the exact working is) button on Amazon, despite being 
exactly the same type of UI element, has side effects. The same is true 
in offline UIs - the Save menu item in my text editor is non-idempotent 
yet the close-by Open  menu item is idempotent. In general, it's hard to 
think of a class of UI where it's unambiguous which actions will have 
side effects just from the visual presentation of the elements and 
without additional contextual information.

Despite this, people have the desire to make links a special class of UI 
object that correspond to idempotent actions only. From a purely 
mechanical point of view, this makes sense - after all one doesn't want 
bots to follow links. From the point of view of that part of the web 
that consists of interlinked documents it mostly makes sense. But from 
the point of view of web applications, it doesn't make sense. It makes 
no sense to require a webmail application to use a form element to open 
each message just because doing so modifies the underlying database, 
despite the fact that a link is an appropriate element to represent the 
action.

Fortunately for the UI designers, there is an acceptable alternative to 
a link. It's  with  javascript to provide the  behavior. Even if 
there was a way to ensure that links were _never_ used for 
non-idempotent actions, you'd still see link-like elements used for such 
actions. Unfortunately they'd have none  of the semantic value  offered 
by  elements.

-- 
"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

From markwubben at gmail.com  Sat May 14 11:02:30 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Sat, 14 May 2005 20:02:30 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <428515E0.5020408@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>
	 <4284CE3C.4040606@cam.ac.uk>

	<428515E0.5020408@cam.ac.uk>
Message-ID: <3b24e6c50505141102285c593@mail.gmail.com>

On 5/13/05, James Graham  wrote:
> Despite this, people have the desire to make links a special class of UI
> object that correspond to idempotent actions only. From a purely
> mechanical point of view, this makes sense - after all one doesn't want
> bots to follow links. From the point of view of that part of the web
> that consists of interlinked documents it mostly makes sense. But from
> the point of view of web applications, it doesn't make sense. It makes
> no sense to require a webmail application to use a form element to open
> each message just because doing so modifies the underlying database,
> despite the fact that a link is an appropriate element to represent the
> action.
>
> Fortunately for the UI designers, there is an acceptable alternative to
> a link. It's  with  javascript to provide the  behavior. Even if
> there was a way to ensure that links were _never_ used for
> non-idempotent actions, you'd still see link-like elements used for such
> actions. Unfortunately they'd have none  of the semantic value  offered
> by  elements.

And this, I think, is the gist of the argument here. I agree with
James here, but what about you?

From markwubben at gmail.com  Sat May 14 11:04:04 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Sat, 14 May 2005 20:04:04 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <3b24e6c50505141102285c593@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>
	 <4284CE3C.4040606@cam.ac.uk>

	<428515E0.5020408@cam.ac.uk>
	<3b24e6c50505141102285c593@mail.gmail.com>
Message-ID: <3b24e6c5050514110468434643@mail.gmail.com>

Argh, sorry, folks.. I keep messing things up here. Must be the
conversation view...

On 5/13/05, James Graham  wrote:
> Despite this, people have the desire to make links a special class of UI
> object that correspond to idempotent actions only. From a purely
> mechanical point of view, this makes sense - after all one doesn't want
> bots to follow links. From the point of view of that part of the web
> that consists of interlinked documents it mostly makes sense. But from
> the point of view of web applications, it doesn't make sense. It makes
> no sense to require a webmail application to use a form element to open
> each message just because doing so modifies the underlying database,
> despite the fact that a link is an appropriate element to represent the
> action.
>
> Fortunately for the UI designers, there is an acceptable alternative to
> a link. It's  with  javascript to provide the  behavior. Even if
> there was a way to ensure that links were _never_ used for
> non-idempotent actions, you'd still see link-like elements used for such
> actions. Unfortunately they'd have none  of the semantic value  offered
> by  elements.

And this, I think, is the gist of the argument here. I agree with
James here, but what about you?

From dean at edwards.name  Mon May 16 13:00:02 2005
From: dean at edwards.name (Dean Edwards)
Date: Mon, 16 May 2005 21:00:02 +0100
Subject: [whatwg] Implementation of WF2 for IE
In-Reply-To: <3b24e6c5050514110468434643@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>	
	<4284CE3C.4040606@cam.ac.uk>		<428515E0.5020408@cam.ac.uk>	<3b24e6c50505141102285c593@mail.gmail.com>
	<3b24e6c5050514110468434643@mail.gmail.com>
Message-ID: <4288FBC2.8080009@edwards.name>

Hi all,

Some of the developers on this list are collaborating on a scripted 
implementation of Web Forms 2.0 for Internet Explorer (Win32). We are 
hosting the development on SourceForge. The solution will be available 
under the LGPL (although that it is open to change). There is an open 
discussion here:

https://sourceforge.net/forum/forum.php?forum_id=466583

We'd appreciate your help/insight/suggestions. To confess, we are 
already flummoxed by the CVS system, so if someone can be of help then 
visit the link above. The other developers are Olav Junker Kj?r (who has 
been extremely busy), Erik Arvidsson and Dimitri Glazkov.

The project home page is here:

https://sourceforge.net/projects/wf2/

There is very little to see so far. I'll post again when there is 
something concrete to demonstrate. This message is mostly a call for 
help with CVS. ;-)

Regards,
-dean

From ian at hixie.ch  Sat May 21 06:09:57 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 21 May 2005 13:09:57 +0000 (UTC)
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: <428F237D.8000508@annevankesteren.nl>
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>
Message-ID: 

On Sat, 21 May 2005, Anne van Kesteren wrote:
> Dan Brickley wrote:
> > Perhaps  would work?
> 
> Dropping [] would work too. I still haven't seen any use cases that 
> require this particular empty construct.

Actually Steven Pemberton gave some interesting examples of what look to 
me like valid use cases for 
 in a recent talk of his. Search for  
in these slides:

   http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/

I don't really see what else to use for those.

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

From fora at annevankesteren.nl  Sat May 21 06:25:33 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sat, 21 May 2005 15:25:33 +0200
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com>
	<20050521112154.GJ18952@homer.w3.org>	<428F237D.8000508@annevankesteren.nl>

Message-ID: <428F36CD.1030408@annevankesteren.nl>

Ian Hickson wrote:
>>> Perhaps  would work?
>> 
>> Dropping [] would work too. I still haven't seen any use cases
>> that require this particular empty construct.
> 
> Actually Steven Pemberton gave some interesting examples of what look
> to me like valid use cases for  in a recent talk of his. Search
> for  in these slides:
> 
> http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/
> 
> I don't really see what else to use for those.

Why doens't SECTION suffice? They are sections separated by decoration.
At least, that is how it appeals to me.

-- 
  Anne van Kesteren

From ian at hixie.ch  Sat May 21 06:33:14 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 21 May 2005 13:33:14 +0000 (UTC)
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: <428F36CD.1030408@annevankesteren.nl>
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>

	<428F36CD.1030408@annevankesteren.nl>
Message-ID: 

On Sat, 21 May 2005, Anne van Kesteren wrote:
> 
> Why doens't SECTION suffice? They are sections separated by decoration. 
> At least, that is how it appeals to me.

They're not really sections. The chapter is the section, these are 
paragraphs together in the same chapter, with a divider between some of 
the paragraphs.

I read a lot of fiction books and when I come across a "* * *" it reads to 
me like a paragraph, saying "Meanwhile, in a different part of the 
universe:"; it doesn't read as "end section. new section:".

IMHO.

To put it another way, sections are things that you can put a title to. 
There's no title you can put to a group of paragraphs separated from other 
groups of paragraphs in the same chapter of a work of fiction, in my 
experience. It's just the same chapter, with the narrative exploring 
different characters or scenes.

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

From rimantas at gmail.com  Sat May 21 06:42:05 2005
From: rimantas at gmail.com (Rimantas Liubertas)
Date: Sat, 21 May 2005 16:42:05 +0300
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>

Message-ID: <5ccfb334050521064226f6c575@mail.gmail.com>

On 5/21/05, Ian Hickson  wrote:
<...>
> Actually Steven Pemberton gave some interesting examples of what look to
> me like valid use cases for 
 in a recent talk of his. Search for 
> in these slides:
> 
>    http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/
> 
> I don't really see what else to use for those.
> 

I see no point for this even in this case. If you separate _sections_,
then they are already separate and you can style sections themself.

Example: http://rimantas.com/bits/hr/nohr.html

And if  had any semantic meaning, then it was trasfered to class
attribute ;)

Regards,
Rimantas
-- 
http://rimantas.com/

From christoph.paeper at tu-clausthal.de  Sun May 22 15:59:16 2005
From: christoph.paeper at tu-clausthal.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Mon, 23 May 2005 00:59:16 +0200
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com>
	<20050521112154.GJ18952@homer.w3.org>	<428F237D.8000508@annevankesteren.nl>		<428F36CD.1030408@annevankesteren.nl>

Message-ID: <42910EC4.5010601@tu-clausthal.de>

Ian Hickson schrieb:
> 
> I read a lot of fiction books and when I come across a "* * *" it reads to 
> me like a paragraph, saying "Meanwhile, in a different part of the 
> universe:"; it doesn't read as "end section. new section:".

     ...
     ...

     ...

     ...
     ...

Works have either just one plot or more which are either parallel (like 
the example above) or nested (where the top-most doesn't need to be 
stuffed into a 'div'). Correct mark-up (in inadequate presentation) 
could destroy the reader's pleasure, though, when the author wants to 
keep the recipient in the dark about what point of view a certain part 
really belongs to.

> To put it another way, sections are things that you can put a title to. 

'div' is the proper HTML element type for subdivisions (of sections) 
that actually are not sections. (IMO sections always have a heading, 
'h'.) It, optionally, can be categorized with the 'class' attribute and 
be identified by an 'id' attribute.

> There's no title you can put to a group of paragraphs separated from other 
> groups of paragraphs in the same chapter of a work of fiction, in my 
> experience.

Anyhow you can still group paragraphs by wrapping them in a division 
instead of dividing them by a separator. The latter is IMO not a very 
markupish approach. MLs are usually about putting (informational) atoms 
into bags and these into larger ones, iterated until you reach the top 
one, the root.

From ian at hixie.ch  Sun May 22 16:38:19 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 22 May 2005 23:38:19 +0000 (UTC)
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: <42910EC4.5010601@tu-clausthal.de>
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>

	<428F36CD.1030408@annevankesteren.nl>

	<42910EC4.5010601@tu-clausthal.de>
Message-ID: 

On Mon, 23 May 2005, Christoph P?per wrote:
> Ian Hickson schrieb:
> > 
> > I read a lot of fiction books and when I come across a "* * *" it reads to
> > me like a paragraph, saying "Meanwhile, in a different part of the
> > universe:"; it doesn't read as "end section. new section:".
> 
>   
>     ...
>     ...
>     
>     
>     ...
>     
>     ...
>     ...
>   

...has no semantics apart from delineating one section. Remember that 
class="" and  are meaningless. A document has the same semantics 
after you strip out any class attributes and  elements.

> > To put it another way, sections are things that you can put a title 
> > to.
> 
> 'div' is the proper HTML element type for subdivisions (of sections) that
> actually are not sections.

According to what specification? According to HTML4,  only "defines 
content to be block-level" (whatever that means!).

> Anyhow you can still group paragraphs by wrapping them in a division 
> instead of dividing them by a separator. The latter is IMO not a very 
> markupish approach. MLs are usually about putting (informational) atoms 
> into bags and these into larger ones, iterated until you reach the top 
> one, the root.

The paragraphs are all part of the  (chapter). They're not 
further grouped together, IMHO. An 
 is equivalent to a  with the 
content "Meanwhile, somewhere else..." or similar ("From someone else's 
point of view...", "At another time..."). In fact if a story was to be 
styled into comic form, 
 elements would typically be presented as 
narrator-level text in the next paragraph's panel. For example:

   No! said Fred.

   The tree stood alone.

In comic form:

   +----------+ +--------------+-------+
   |  _____   | | Meanwhile... |       |
   | < No! >  | +--------------+       |
   |  \/^^^   | |         /|\          |
   |  o       | |         /|\          |
   | -+-      | |          |           |
   | / \      | |          |           |
   +----------+ +----------------------+

Not that we have any user agents or stylesheet languages (short of actual 
humans) capable of that kind of interpretation and presentation today, but 
my point is that the  here is a unit on par with a paragraph, it's not 
an artefact of an implied higher level grouping.

In text form:

   "No!" said Fred.

      *   *   *

   The tree stood alone.

In aural form:

   No!, said Fred. [pause] The tree stood alone.

If we didn't have , I would imagine the above example would be marked 
up as:

   No! said Fred.
   * * *
   The tree stood alone.

...or some such. I really don't think:

    No! said Fred.

    The tree stood alone.

...would be better than , in fact I think it would be unnatural from 
an authoring perspective. We mustn't fall into the trap of considering 
everything to be a hierarchy, just because that is what XML most easily 
marks up. Book authors have managed quite well for centuries without 
considering their documents to be formed of trees! (Notwithstanding what 
paper is made of, I mean.)

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

From mikko.rantalainen at peda.net  Mon May 23 03:40:49 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Mon, 23 May 2005 13:40:49 +0300
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com>
	<20050521112154.GJ18952@homer.w3.org>	<428F237D.8000508@annevankesteren.nl>		<428F36CD.1030408@annevankesteren.nl>

Message-ID: <4291B331.50408@peda.net>

Ian Hickson wrote:
> On Sat, 21 May 2005, Anne van Kesteren wrote:
> 
>>Why doens't SECTION suffice? They are sections separated by decoration. 
>>At least, that is how it appeals to me.
> 
> They're not really sections. The chapter is the section, these are 
> paragraphs together in the same chapter, with a divider between some of 
> the paragraphs.
> 
> I read a lot of fiction books and when I come across a "* * *" it reads to 
> me like a paragraph, saying "Meanwhile, in a different part of the 
> universe:"; it doesn't read as "end section. new section:".

I read the "* * *" part exactly the same way. And I consider your 
quoted text to be the header for that sub-section even though it's 
omitted from the output. I feel that the correct markup to use would be

Yet another chapter

In the Jack's basement
...

Meanwhile in the Bill's room
...

In my opinion, this is the correct sematics for the content. To 
increase excitement for the reader, some of the content is hidden 
during the presentation. If you feel that hiding the information is 
part of the semantics in this case (arguably that may be true), just 
drop all the  elements with class "undisclosed" above.

I think this is an example of why an  element shouldn't be 
required inside a  element.

IMHO.

> To put it another way, sections are things that you can put a title to. 
> There's no title you can put to a group of paragraphs separated from other 
> groups of paragraphs in the same chapter of a work of fiction, in my 
> experience. It's just the same chapter, with the narrative exploring 
> different characters or scenes.

I think you can always put a title to a group of paragrahps. It's 
just that sometimes (often?) you decide to leave it out for brevity 
/ clarity / excitement / whatever.

-- 
Mikko

From olav at olav.dk  Tue May 24 11:13:06 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 24 May 2005 20:13:06 +0200
Subject: [whatwg] Submit buttons
Message-ID: <42936EB2.4090901@olav.dk>

I think there is a slight inconsistency with submit buttons.
Section 2.17.:
"Normally, activating a submit button ... must submit the first form the 
control is associated with"
Section 2.3
"If the platform supports submitting a form implicitly ... then when 
doing so the first submit button, this default button, must be the one 
used to initiate form submission (and it will therefore be successful)."

The problem is that the the default button for a form might not submit 
the same form when activatated, if the form is not the first form in the 
forms collection of the button.

It could be solved by requiring that submit buttons (and input 
type=image) may only be associated with a single form at a time.

regards
Olav Junker Kj?r

From supercanadian at gmail.com  Thu May 26 12:08:49 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 12:08:49 -0700
Subject: [whatwg] General TCP connections API?
Message-ID: <84ce626f050526120834cb3241@mail.gmail.com>

Hello,

(Please excuse me if this has already been discussed.  I'm still
working my way through the mailing list archive.  Also, I hope I'm not
out of place by just interjecting myself.)

Are there any plans to add an API to create TCP connections?

IMO, this is very necessary for creating "web applications".  And it
would be unfortunate if it wasn't included.

Right now, there seems to be a new fad revolving around
XmlHttpRequest.  It has been nicknamed AJAX by many.  And heralded as
a means of asynchronous communication for the Web.  However, AJAX only
gives the illusion of asynchronous communication between the server
and client.  The client is polling the server.  And often a new TCP
connection is created (and later tore down) each time the server is
polled.  (Which, IMO, is bad.)

The nice thing about XmlHttpRequest is that it makes it so you can
"update" a webpage without having to reload it.  Which improves
usability.  However, because of the polling, performance is adversely
affected.  Not to mention that polling is not the optimal mode of
communication.

One could come up with a new protocol for asynchronous communication. 
(Maybe as something to accompany HTTP.  Or maybe even as an extension
to it -- HTTP 1.2?)  Which may solve this problem.  But other
"problems" could arise in the future.  It would be good to provide
developers (of web applications) the building blocks to solve a wider
set of problems.  And to me, I think having an API to create TCP
connection is one of these building blocks.

Some might say that letting the client create general TCP connects
would bring up all sorts of security concerns.  However, I think these
security concerns can be dealt with by making it so the API would only
allow the client to create a TCP connection to the "host" that the
client -- the webpage (or web application) -- came from.

Or, alternatively, we could allow the host that the webpage (or web
application) came from to specify a list of domains (or IP addresses)
that clients could connect to.  (Of course, there would be
restrictions on this.  The hosts in that list would need to "allow"
the original host to do this.  A mechanism for this would need to be
created.)

There could even be other restrictions.  For example, a host could
specify what ports it allows webpages (and web applications) to
connnect to.

So,... are there any plans to add an API to create TCP connections?

See ya

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From kornel at ldreams.net  Thu May 26 12:58:35 2005
From: kornel at ldreams.net (Kornel Lesinski)
Date: Thu, 26 May 2005 20:58:35 +0100
Subject: [whatwg] General TCP connections API?
In-Reply-To: <84ce626f050526120834cb3241@mail.gmail.com>
References: <84ce626f050526120834cb3241@mail.gmail.com>
Message-ID: 

> The client is polling the server.  And often a new TCP
> connection is created (and later tore down) each time the server is
> polled.  (Which, IMO, is bad.)

HTTP/1.1 uses persistent connections by default. If you set long keepalive  
time on your webserver, chances are that all requests are going to be done  
over same TCP/IP connection.

To have your own connections you'd have to use other port than 80 and that  
may be disallowed on many restricted systems.

If user navigates to the next page, browser will destroy your JS objects  
and close their connections. That may result in worse performance than  
with HTTP connection that is kept alive between pages.

Even if connections are limited to the same host, you couldn't safely  
serve anything else on it. Spammers might use numerous HTML-injection  
techniques to send spam using other people's computers, and this may get  
much worse if host restriction fails. From past experience of hundreds of  
cross-site scripting vulnerabilities, you can be sure that this will  
happen sooner or later.

BTW: There's a hack that lets you get data from server without polling -  
use iframe, start sending its contents and don't close connection - keep  
sending 

every visitor will send spam using example.com server.

On a second thought this may be prevented by forcing some special  
handshake or transport protocol for custom connections...
but then this feature becomes just alternative HTTP + XML RPC that only  
offers smaller lag for price of increased complexity and worse  
browser/server support. Is it worth it?

-- 
regards, Kornel Lesinski

From supercanadian at gmail.com  Thu May 26 15:10:00 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 15:10:00 -0700
Subject: [whatwg] General TCP connections API?
In-Reply-To: 
References: <84ce626f050526120834cb3241@mail.gmail.com>

	<84ce626f05052613307e086b2b@mail.gmail.com>

Message-ID: <84ce626f05052615101c94a0a3@mail.gmail.com>

Hello,

On 5/26/05, Kornel Lesinski  wrote:
> On Thu, 26 May 2005 21:30:18 +0100, Charles Iliya Krempeaux
>  wrote:
> 
> >> To have your own connections you'd have to use other port than 80 and
> >> that may be disallowed on many restricted systems.
> >
> > Could you please elaborate on this.
> 
> Clients that have many blocked ports on firewall - for example to block
> P2P inside school networks.

I made this argument in another e-mail too,... but I'll do it again....

I think that we should allow TCP connections, even if it won't work in
some cases.

For example, often people access the web on a computer at a cafe or
school that does not have an e-mail client.  In these cases the
"mailto" URL will not work.  However, we still allow the "mailto" URLs
in webpages.

Also, it could be the case that a network (on an office) bans outgoing
connects on any port other than 80 (for HTTP) and 443 (for HTTPS).
This would stop FTP URLs from working.  However, we still allow "ftp"
URLs in webpages.

In other words, "let me use it when I can use it".  (Since we are
already following this principle on the web.)

[...]

> >> Even if connections are limited to the same host, you couldn't safely
> >> serve anything else on it. Spammers might use numerous HTML-injection
> >> techniques to send spam using other people's computers, and this may get
> >> much worse if host restriction fails.
> 
> > Could you please elaborate on this.
> 
> Let's say there's website
> example.com/page.php?name=John
> that prints
> Hello "John"!
> 
> On your website, if you create iframe with URL:
> example.com/page.php?name=

I won't be a problem if the web developers is escaping whatever the
user supplies.  (This is developer error, ignorance, or stupidity.) 
For example, if the web developer is using PHP, then he should be
making use of the htmlspecialchars() function.  For example, their
code should be something like:

Web developers should NOT be allowing arbitrary (HTML, JavaScript,
etc) code to get inserted into their webpages on their site!  (Even if
a web developer does this today, he allows the potential for havoc!)

I could also make an argument to NOT allow CGI parameters in the first
place because people could potentially use it to make system calls. 
For example, consider that I have a script that gives me "finger" info
for users of the system.  And suppose it is usually called with
something like:

    http://example.com/finger.cgi?username=joeblow

And that this is implemented with a system call.  Maybe something like:

Then there would be a problem if I called this URL with something like:

    http://example.com/finger.cgi?username=joeblow;rm+-fR+.

Then the command wouldn't just be:

    finger joeblow

But would be

    finger joeblow; rm -fR .

(Which could delete a hole bunch of stuff.)

I don't think developer error, ignorance, or stupidity should be an
argument to not allow TCP connections.

> every visitor will send spam using example.com server.
> 
> 
> On a second thought this may be prevented by forcing some special
> handshake or transport protocol for custom connections...
> but then this feature becomes just alternative HTTP + XML RPC that only
> offers smaller lag for price of increased complexity and worse
> browser/server support. Is it worth it?

The argument for allowing TCP connections isn't so that a small drop
in lag can be obtained.  But so that things that otherwise could not
be solved using HTTP can be solved (using a custom protocol).  (Please
refer to my "streaming images at 24 frames per second" example in the
other e-mail I wrote.)

See ya

> --
> regards, Kornel Lesinski
> 

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From supercanadian at gmail.com  Thu May 26 17:40:21 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 17:40:21 -0700
Subject: Fwd: [whatwg] General TCP connections API?
In-Reply-To: 
References: <84ce626f050526120834cb3241@mail.gmail.com>

	<84ce626f05052613307e086b2b@mail.gmail.com>

	<84ce626f05052615101c94a0a3@mail.gmail.com>

Message-ID: <84ce626f0505261740414b9c44@mail.gmail.com>

Hello,

I think this was suppose to go to the mailing list, and not just me.

See ya

---------- Forwarded message ----------
From: Kornel Lesinski 
Date: May 26, 2005 5:34 PM
Subject: Re: [whatwg] General TCP connections API?
To: Charles Iliya Krempeaux 

On Thu, 26 May 2005 23:10:00 +0100, Charles Iliya Krempeaux
 wrote:

>> On your website, if you create iframe with URL:
>> example.com/page.php?name=
>
> I won't be a problem if the web developers is escaping whatever the
> user supplies.

...and HTML developers should write valid HTML, etc.

Sorry, but there is A LOT of totally ignorant/incompetent web developers
and sysadmins.

> For example, let's say I want to stream images, or video, or audio,
> from the client to the server.

and how are you going to decode and display them using Javascript?
and how that is better than current streaming multimedia plugins? or Java?

> And that there were some high "performance" demands
> for this that HTTP couldn't meet.  (Like, for example, if I wanted to
> push 24 frames per second from client to server.)

This doesn't make sense to me.

HTTP doesn't add any overhead to TCP/IP except headers (you don't have to
use chunked encoding), so your custom protocol can't save you more than
*one* IP packet per file! (and typically less thanks to keepalive
connections)

For high performance you can't use TCP/IP and need some lower-level
protocol like UDP and specially crafted data format that works with
partial/out-of-order packets. That's absolutely not a thing anyone would
dare to implement in Javascript.

--
regards, Kornel Lesinski

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
 Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From supercanadian at gmail.com  Thu May 26 22:58:08 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 22:58:08 -0700
Subject: [whatwg] General TCP connections API?
In-Reply-To: 
References: <84ce626f050526120834cb3241@mail.gmail.com>

	<84ce626f05052613307e086b2b@mail.gmail.com>

	<84ce626f05052615101c94a0a3@mail.gmail.com>

Message-ID: <84ce626f05052622584508e9f5@mail.gmail.com>

Hello,

On 5/26/05, Kornel Lesinski  wrote:
> On Thu, 26 May 2005 23:10:00 +0100, Charles Iliya Krempeaux
>  wrote:
> 
> >> On your website, if you create iframe with URL:
> >> example.com/page.php?name=
> >
> > I won't be a problem if the web developers is escaping whatever the
> > user supplies.
> 
> ...and HTML developers should write valid HTML, etc.
> 
> Sorry, but there is A LOT of totally ignorant/incompetent web developers
> and sysadmins.

Agreed.  But if you are going to not support (or allow) anything that
could screw up a system due to a mistake by an ignorant/incompetent
web developers or sysadmins then we might as well not allow the whole
concept of CGI, server side scripting, and dynamic database driven
websites.  (Since this could be used to screw up systems.)

Just look at how many people use an HTTP GET (instead of POST, PUT,
DELETE, or something else) to change things -- delete or update
records -- on the webserver.  This sometimes causes problems when
search engines crawl sites.  Does this mean we should get rid of
search engine web crawlers because some ignorant/incompetent web
developer doesn't understand the differences between the different
HTTP methods and how they should be used?

Sometimes ignorant/incompetent web developers pass input from CGI
variables to a system call (unescaped and unquoted).  This can be used
to do all sorts of malicious acts by allowing the user to run
arbitrary commands on the server.  Does this mean that we should get
rid of CGI and server side scripting?

I disagree that ignorance/incompetents web developers or sysadmins
should be a reason to not allow TCP connections.  Because, following
that line of reasoning would be an argument to get rid of CGI, server
side scripting, and database driven websites.

> > For example, let's say I want to stream images, or video, or audio,
> > from the client to the server.
> 
> and how are you going to decode and display them using Javascript?
> and how that is better than current streaming multimedia plugins? or Java?

The image streaming thing was just an example.  (I was trying to come
up with an example that could make use of a TCP connection.  Although
it is an example I was working on before.  The solution to this was to
write a native desktop application for Linux, Windows, and Mac. 
Although part of that was due to needing to access the camera and
microphone on the computer.)

Incidentally, Java provides a TCP connection API like the one I'm
proposing for web applications.  Refer to #8 in the Java Security FAQ:

    http://java.sun.com/sfaq/

I actually think Java would be an excellent solution.  (I actually
really liked it when the JVM was in virtually every browser.) 
However, today, it doesn't seem to be there on all browsers.  Last I
checked, it wasn't even included on Windows XP.  And isn't included on
most Linux distributions.  (Although correct me if I'm wrong.)  Today,
you have to download and install it yourself.

Which is why I think there should be a TCP connection API.  So that a
plain vanilla web browser (of tomorrow) can create a TCP connection
(without relying on extensions that may or may not be there).

> > And that there were some high "performance" demands
> > for this that HTTP couldn't meet.  (Like, for example, if I wanted to
> > push 24 frames per second from client to server.)
> 
> This doesn't make sense to me.
> 
> HTTP doesn't add any overhead to TCP/IP except headers (you don't have to
> use chunked encoding), so your custom protocol can't save you more than
> *one* IP packet per file! (and typically less thanks to keepalive
> connections)
> 
> For high performance you can't use TCP/IP and need some lower-level
> protocol like UDP and specially crafted data format that works with
> partial/out-of-order packets. That's absolutely not a thing anyone would
> dare to implement in Javascript.
> 

What I was talking about here was more about the cost of creating and
tearing down TCP connections when using the HTTP protocol, for each
request.  Although, it is true that the "persistentness" of HTTP/1.1
can help.  However, as I understand it, this "persistentness" can't be
depended on.  (The connection could be closed by the server.)  But
correct me if I'm wrong.  (Perhaps I just don't have enough knowledge
about tweaking a webserver for its persistentness.)

See ya

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From dean at edwards.name  Fri May 27 22:44:14 2005
From: dean at edwards.name (Dean Edwards)
Date: Sat, 28 May 2005 06:44:14 +0100
Subject: [whatwg] Web Forms 2.0 Typo
In-Reply-To: <84ce626f05052622584508e9f5@mail.gmail.com>
References: <84ce626f050526120834cb3241@mail.gmail.com>		<84ce626f05052613307e086b2b@mail.gmail.com>		<84ce626f05052615101c94a0a3@mail.gmail.com>	
	<84ce626f05052622584508e9f5@mail.gmail.com>
Message-ID: <4298052E.4060901@edwards.name>

Ian,

Just spotted this: "validityMessage" should be "validationMessage" in 
http://whatwg.org/specs/web-forms/current-work/.

-dean

From ldrhcp at gmail.com  Sat May 28 08:27:13 2005
From: ldrhcp at gmail.com (Lenny Domnitser)
Date: Sat, 28 May 2005 11:27:13 -0400
Subject: [whatwg] Canvas should be script-only, not an HTML element
Message-ID: <94355ecc0505280827707692e6@mail.gmail.com>

Creating a non-semantic

> blocks around e-mails: > >

>     Access via the DOM also affects styling.
>
>     Also, if UAs have to parse it in the old way, what's the point?
>     It's not increasing the semantics, since the UAs have to parse it 
> the
>     old way.
>

> > ...or something. Then again, that does look pretty bad. I'm not a big fan of

. In fact, I stay away from it and use 
... with no-break spaces for code snippets. For 
mail archives, I suggest supporting format=flowed, which means  
should not be involved.

> On Fri, 8 Apr 2005, Henri Sivonen wrote:
>> I see the option are:
>> a) Banning XHTML divergence for everyone.
>> b) Behaving as if a) was the case and barfing at XHTML that cannot be
>> serialized as HTML.
>> c) Bending over backwards in order to track whether a given piece of
>> data can be serialized as HTML and whether there is a future need for 
>> a
>> given piece of data to be serialized as HTML.
>>
>> Option a) doesn't seem popular and implementing c) would be a pain,
>> which seems to leave b) for those who serialize as HTML. Of course, 
>> the
>> reason why one would want to serialize as HTML is IE (and Lynx).
>
> Agreed. Is option b acceptable to you?

I suppose that realistically it has to be, because enforcing a) doesn't 
look like a realistic option. :-/

It would help if WHAT WG published a RELAX NG schema for the 
text/html-compatible subset of the XHTML flavor. That would make 
appropriate barfing easier. It would also facilitate the implementation 
of text/html flavor conformance checkers.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From hsivonen at iki.fi  Sat May  7 11:50:11 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sat, 7 May 2005 21:50:11 +0300
Subject: [whatwg] [web-apps] 2.7.8 The i element
In-Reply-To: 
References: 

	<42611707.10401@lachy.id.au>

	<42612459.5080500@lachy.id.au>

Message-ID: <56ca39c50dc8065a6f27c3792785eac1@iki.fi>

On Apr 16, 2005, at 17:53, Ian Hickson wrote:

> On Sun, 17 Apr 2005, Lachlan Hunt wrote:
>>>
>>> Actually,  in HTML5 is currently defined as having specific
>>> semantics:
>>>
>>>    http://whatwg.org/specs/web-apps/current-work/#the-i
>>
>> So does "i" now stand for "instance", instead of "italics"?
>
> At least until someone argues otherwise. :-)

Everybody knows it originally stands for "italic". Who would you fool 
by claiming it stood for something else? For browsers, and the element 
name is just a string. They don't care of English words. The default 
rendering will have to be italics anyway due to ample legacy content. 
No matter what to write in the spec, for all practical purposes  
will mean "italic". I think acknowledging this would be in line with 
the descriptive approach the WHAT WG specs tend to take when it comes 
to features that have been already interoperably implemented.

What's the pseudo-semantic trickery good for? Will hard-line 
anti-presentationalists who spread false propaganda about  being 
deprecated suddenly embrace  if WHAT WG claims it stands for a 
different English word?

>> In that case, would you want to differentiate between ordinary titles
>> and real citations?  Or is that something that the class attribute 
>> could
>> handle, if needed?
>
> I don't know. What do people think?

I'd define  meaning a title of work (not a person and not limited 
to quoted works).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From hsivonen at iki.fi  Sat May  7 11:51:00 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sat, 7 May 2005 21:51:00 +0300
Subject: [whatwg] [html5] tags, elements and generated DOM
In-Reply-To: <4263A7DF.1000509@inkedblade.net>
References: <42524E27.6060006@annevankesteren.nl>
	<42534E44.8080101@lachy.id.au>

	<4253B881.3090206@lachy.id.au> <4253CA8A.1070608@olav.dk>
	<4253D10C.5000700@lachy.id.au>
	<4253D24A.8050308@annevankesteren.nl>
	<4253D7CA.2010807@lachy.id.au>
	<4253DA93.8030606@annevankesteren.nl>
	<4253E4FF.2090306@lachy.id.au> <4253F517.3040409@olav.dk>
	<425401B0.3040205@lachy.id.au>
	<42540251.4080405@annevankesteren.nl>
	<42546FCE.5070900@lachy.id.au>

	<4254CE93.4000403@lachy.id.au>

	<42550FFD.20201@annevankesteren.nl>

	<4255114D.10108@annevankesteren.nl>

	<4261C2BE.7060601@inkedb lade.net>
	<7becfe9e53869dcf45c0b5123f918a8b@iki.fi>
	<4263A7DF.1000509@inkedblade.net>
Message-ID: <6ae97fbbc664c4066e8c90d196914820@iki.fi>

On Apr 18, 2005, at 15:28, fantasai wrote:

> Henri Sivonen wrote:
>> On Apr 17, 2005, at 04:58, fantasai wrote:
>>> For those of us writing HTML by hand, this is not a practical 
>>> solution,
>>> particularly when invisible characters are involved. Invisible 
>>> characters
>>> aside, I don't want to go digging through a Unicode character map 
>>> every
>>> time I want → or τ.
>> That's not an issue for HTML where entities get tag soup treatment 
>> anyway.
>> I didn't say that authors should not type entity references in XML. I 
>> said that the entity references should be resolved before the data 
>> travels from the server to the client.
>
> So, when is my document going to get preprocessed? I certainly don't 
> want
> to bother fussing with it every time I fix a typo.

If there is no CMS and the server served raw files, the preprocessing 
would have to happen while editing or in an editor save hook.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From ianb at colorstudy.com  Sat May  7 12:04:54 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat, 07 May 2005 14:04:54 -0500
Subject: [whatwg] A thought: 
In-Reply-To: <6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
Message-ID: <427D1156.8050506@colorstudy.com>

Henri Sivonen wrote:
> On May 7, 2005, at 01:55, Ian Bicking wrote:
> 
>> I was just thinking about the recent problems introduced by the Google 
>> Web Accelerator following links that have side effects (the typical > href="form?delete=10">[delete this] stuff).
> 
> 
> Links like that are objectively wrong according to RFC 2616 (HTTP 1.1). 
> Google is free to follow those links without being responsible for the 
> side effects.

I think it's sufficient to note that this is an *extremely* common 
pattern, regardless of RFC 2616.  I think this might be a constructive 
place to discuss why it is so common, and what could be provided to web 
developers so they can do the right thing, but I don't think much is 
achieved by just saying that the majority of web developers are wrong. 
And it's the majority of web developers that use these kinds of links, 
regardless of spec.  Heck, Google uses these kinds of links.

>> One of the issues is that doing the Right Thing means creating a form, 
>> and that effects the UI,
> 
> 
> There'd be a design bug somewhere if the UI wasn't affected! When 
> something looks like a link to, the user has a good reason to expect 
> that following the link causes a safe retrieval operation. When 
> something looks like a button, the user has a reason to understand that 
> pressing the button may cause an unsafe operation.

Without Web Forms and nested forms, it *is* a bug to effect the UI in 
the ways that would be required, because isolated controls cannot be put 
inside the context of a larger form that submits to a different location 
and performs a different action.  The only way to do that now would be 
with Javascript, which would submit a form that existed elsewhere on the 
page.  It is also made more difficult by the fact that a form is a 
block-level element, and so has even more effect on the layout of the page.

And there's other much more safe operations that also cause side 
effects.  For instance, links that reorder items -- they aren't very 
dangerous, you don't really have to warn users implicitly about their 
effects, but it will cause problems if a UA clicks these links without 
direct user request.  I think there is a continuum, and by forcing safe 
state-modifying actions to look different it has caused many developers 
to do things that are unsafe with regard to HTTP, so that their UIs 
better represent (in those developers' opinions) the functionality they 
are providing.

Developers use many techniques to indicate what a control will do. 
Generally links give them more flexibility in how they indicate this,

I'm just trying to explain why this "incorrect" practice is so common. 
I haven't thought about it a lot before now, so I'm making it up as I go 
along, but emperically there must be reasons.  It then would be helpful 
to give developers tools that address those reasons, but allow them to 
use POST the way they should.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org

From ian at hixie.ch  Sat May  7 13:19:27 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 7 May 2005 20:19:27 +0000 (UTC)
Subject: [whatwg] WebApps spec, chapter 7.1.1.9 "Images"
In-Reply-To: <427C73D2.60108@web.de>
References: <427C73D2.60108@web.de>
Message-ID: 

On Sat, 7 May 2005, Jens Bannmann wrote:
>
> The note at the end of chapter 7.1.1.9 saying "All canvases implement 
> HTMLImageElement, so canvas elements can be passed to the drawImage 
> methods" looks like it's superfluous, now that HTMLCanvasElement no 
> longer inherits from HTMLImageElement. The rest of the spec, e.g. the 
> second paragraph of that chapter, was already changed accordingly.

Good catch. Removed. Thanks.

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

From jg307 at cam.ac.uk  Sat May  7 16:36:47 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Sun, 08 May 2005 00:36:47 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
Message-ID: <427D510F.6010802@cam.ac.uk>

Henri Sivonen wrote:
> 
>> One of the issues is that doing the Right Thing means creating a form, 
>> and that effects the UI,
> 
> 
> There'd be a design bug somewhere if the UI wasn't affected! When 
> something looks like a link to, the user has a good reason to expect 
> that following the link causes a safe retrieval operation. When 
> something looks like a button, the user has a reason to understand that 
> pressing the button may cause an unsafe operation.
>

I'm not sure that users (the vast majority of users who haven't even 
heard the term RFC, let alone read one) have any particular expectation 
for the safety of clicking on a link. The fact that so many webapps use 
links for unsafe operations kind-of supports that view. Plus, design 
_is_ important in these things and submit-style buttons don't always 
make good UI.

Consider the example of a webmail application. These often allow 
messages to be retrieved by clicking on hyperlinks containing the 
subject line*. This is apparently all well and good because retrieving a 
message is sounds like a simple GET-friendly operation. Except that the 
act of retrieving a message often has the side effect of marking the 
message read in some way (not an unsafe operation per-se but one that 
should only be initiated by a user). So with the current HTML spec, one 
has the option of a) using hyperlinks to retrieve messages so sticking 
with a familiar and well understood UI paradigm but violating HTTP and 
breaking e.g. precaching in UAs, b) using some sort of form for retrieve 
messages so making the UI ugly and probably harder to navigate, 
especially for users familiar with  approach a), or c) requiring 
scripting for basic functionality (retrieving messages and/or marking 
read messages as read).

Allowing  would, AFAICT, solve this kind of 
problem.

*I don't claim this is the optimum UI but it is certianly much the most 
common UI I have experienced in webmail applications.

From mpt at myrealbox.com  Sat May  7 19:25:52 2005
From: mpt at myrealbox.com (Matthew Thomas)
Date: Sun, 08 May 2005 14:25:52 +1200
Subject: [whatwg] A thought: 
In-Reply-To: <427D510F.6010802@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk>
Message-ID: <427D78B0.2080608@myrealbox.com>

James Graham wrote:
>...
> Consider the example of a webmail application. These often allow 
> messages to be retrieved by clicking on hyperlinks containing the 
> subject line*. This is apparently all well and good because retrieving a 
> message is sounds like a simple GET-friendly operation. Except that the 
> act of retrieving a message often has the side effect of marking the 
> message read in some way (not an unsafe operation per-se but one that 
> should only be initiated by a user).

You're right, it's not an unsafe operation. A Web browser does this with 
links anyway, when it gives visited links a different color from 
unvisited ones. That doesn't mean it should, early-Arena-like, present 
all links as buttons.

All the Webmail application is doing is retaining visited/unvisited 
presentation across whatever computer you log in to your Webmail from -- 
which is part of the point of it being a Web application in the first 
place. So that's not really a good example of a non-idempotent action, 
and therefore not a reason for specs to condone non-idempotent links.

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

From hsivonen at iki.fi  Sun May  8 00:04:12 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 8 May 2005 10:04:12 +0300
Subject: [whatwg] A thought: 
In-Reply-To: <427D1156.8050506@colorstudy.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D1156.8050506@colorstudy.com>
Message-ID: 

On May 7, 2005, at 22:04, Ian Bicking wrote:

>> There'd be a design bug somewhere if the UI wasn't affected! When 
>> something looks like a link to, the user has a good reason to expect 
>> that following the link causes a safe retrieval operation. When 
>> something looks like a button, the user has a reason to understand 
>> that pressing the button may cause an unsafe operation.
>
> Without Web Forms and nested forms, it *is* a bug to effect the UI in 
> the ways that would be required, because isolated controls cannot be 
> put inside the context of a larger form that submits to a different 
> location and performs a different action.

The canonical approach is making one form that encloses everything on 
the page. That way, you can sprinkle submit buttons wherever you like.

> And there's other much more safe operations that also cause side 
> effects.

If there are noticeable side effects (ie. something written in a log on 
the server does not count), GET is inappropriate.

> so that their UIs better represent (in those developers' opinions) the 
> functionality they are providing.

I don't think it follows that POST links are needed but that submit 
buttons need an alternative appearance that makes them more suitable to 
be packed in a table representing Web mail messages, etc. (I am not 
suggesting that form widgets be arbitrarily stylable. That doesn't work 
nicely with UI themes developed after Windows 3.1. I am suggesting a 
style property like button-type: grid-item; for selecting for a 
predefined list of button styles.)

What you are suggesting degrades to something unsafe. Styling submit 
buttons would degrade to something safe but perhaps ugly.

> I'm just trying to explain why this "incorrect" practice is so common.

I can think of the following reasons:
1) A very large number of people doing Web stuff are clueless and 
incompetent.
2) Many people haven't gotten in the habit of making page-wide forms.
3) A link is less verbose to type than a submit button.
4) Many people find submit buttons bulky and the buttons cannot be 
universally styled to be less bulky.

I think the last one is a big deal when the graphics deezyner overrides 
RFC 2616. But things that please them belong in CSS.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From ben at benmeadowcroft.com  Sun May  8 01:39:29 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Sun, 8 May 2005 09:39:29 +0100
Subject: [whatwg] Web Apps 1.0: Editing
Message-ID: <002801c553a9$771dfe80$0202a8c0@BensPC>

Regarding the Editing section, at the moment only contentEditable is
mentioned. While this is probably the most common method, designMode
should also be included.

Perhaps have two subsections, one for full document editing (designMode)
and the other for element content editing (contentEditable). There are two
well known implementations of designMode, in IE & Mozilla, and I think
that the Editing section should cover both off them, in effect get what is
already out there written down and specified in an non-proprietary spec.

Some useful designMode links:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/desig
nmode.asp
http://www.mozilla.org/editor/midas-spec.html

--
Ben Meadowcroft
http://www.benmeadowcroft.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From ben at benmeadowcroft.com  Sun May  8 02:30:44 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Sun, 8 May 2005 10:30:44 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
Message-ID: <003901c553b0$a03fc350$0202a8c0@BensPC>

I think the web apps 1.0 specification is lacking a section on on-line
help. This is a topic which I feel the current work could helpfully
handle.

There are two types of help that I think are appropriate for web
applications, full page help and element sensitive help.

I'd suggest first that we standardise a method of linking an application
page to it's help page. This could be done by specifying a link relation
type specifically for online help. For example:

The user agent could then allow users to access the on-line help using the
browser UI, i.e. from the help menu where the application specific help
could be made available or by pressing the F1 key.

My second proposal is to standardise element context help. This will allow
a user to get context sensitive help on a particular area of the web page
when mousing over or clicking parts of the page (depending on how the OS
implements similar features I suppose). This could be enabled by allowing
elements to have a context-help attribute (similar to the context-menu
attribute proposed).

--
Ben Meadowcroft
http://www.benmeadowcroft.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From jg307 at cam.ac.uk  Sun May  8 06:28:59 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Sun, 08 May 2005 14:28:59 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <427D78B0.2080608@myrealbox.com>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>
Message-ID: <427E141B.2060604@cam.ac.uk>

Matthew Thomas wrote:
> All the Webmail application is doing is retaining visited/unvisited 
> presentation across whatever computer you log in to your Webmail from -- 
> which is part of the point of it being a Web application in the first 
> place. So that's not really a good example of a non-idempotent action, 
> and therefore not a reason for specs to condone non-idempotent links.

I should have stated explicitly that when I said "marking the message as 
read in some way" I intended that the "some way" could be more than just 
changing a message's unread flag, it could be e.g. moving the message 
from the inbox to a "Read messages" folder. Even if the message is 
"just" marked as read, this can change more than the appearance of the 
message - it can change where in the interface it is displayed (in some 
sort of virtual-folder based setup), etc.   So I don't think you can 
dismiss this as "not really a good example of a non-idempotent action" - 
it clearly /is/ non-idempotent yet representing the action as a link is 
normal and widely understood.

From ian at hixie.ch  Sun May  8 08:30:14 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 8 May 2005 15:30:14 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: Editing
In-Reply-To: <002801c553a9$771dfe80$0202a8c0@BensPC>
References: <002801c553a9$771dfe80$0202a8c0@BensPC>
Message-ID: 

On Sun, 8 May 2005, Ben Meadowcroft wrote:
> 
> Perhaps have two subsections, one for full document editing (designMode)
> and the other for element content editing (contentEditable).

Is there any difference between

...and

...?

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

From ian at hixie.ch  Sun May  8 08:35:15 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 8 May 2005 15:35:15 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <003901c553b0$a03fc350$0202a8c0@BensPC>
References: <003901c553b0$a03fc350$0202a8c0@BensPC>
Message-ID: 

On Sun, 8 May 2005, Ben Meadowcroft wrote:
> 
> There are two types of help that I think are appropriate for web 
> applications, full page help and element sensitive help.

The problem with both is discoverability. Unless we can solve that, there 
is not much point having anything in the spec.

For example, WF2 used to have a help="" attribute on form controls. We 
removed it after we got feedback that users would have no way of knowing 
that there was help available and that it would thus be mostly useless.

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

From jim.ley at gmail.com  Sun May  8 10:47:36 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Sun, 8 May 2005 18:47:36 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: 
References: <003901c553b0$a03fc350$0202a8c0@BensPC>

Message-ID: <851c8d31050508104713d6c07e@mail.gmail.com>

On 5/8/05, Ian Hickson  wrote:
> On Sun, 8 May 2005, Ben Meadowcroft wrote:
> >
> > There are two types of help that I think are appropriate for web
> > applications, full page help and element sensitive help.
> 
> The problem with both is discoverability. Unless we can solve that, there
> is not much point having anything in the spec.

For the context sensitive one we use CSS with a cursor:help  that's
the way we usually implement it from a visible perspective, I'm not
sure if there's particular value in defining an attribute to take the
help contents though, especially as this would mean it couldn't then
have mark-up, which most of the context help systems I've done do use.

adding in a link rel of help would seem a pretty low rent thing to
define, how that may be exposed in a UI though I'm less clear, I don't
like the idea of adding it to the  browsers regular help chrome -
there needs to be a distinction between browser and web-application.

Jim.

From sjoerd at w3future.com  Mon May  9 05:23:30 2005
From: sjoerd at w3future.com (Sjoerd Visscher)
Date: Mon, 09 May 2005 14:23:30 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <427E141B.2060604@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk>
Message-ID: <427F5642.60507@w3future.com>

James Graham wrote:

> I should have stated explicitly that when I said "marking the message as 
> read in some way" I intended that the "some way" could be more than just 
> changing a message's unread flag, it could be e.g. moving the message 
> from the inbox to a "Read messages" folder. Even if the message is 
> "just" marked as read, this can change more than the appearance of the 
> message - it can change where in the interface it is displayed (in some 
> sort of virtual-folder based setup), etc.   So I don't think you can 
> dismiss this as "not really a good example of a non-idempotent action" - 
> it clearly /is/ non-idempotent yet representing the action as a link is 
> normal and widely understood.
> 

What this shows is that marking a message read when it is retrieved is a 
bad idea. Retrieving a message must be done with GET, so that it can be 
cached. Setting the read state should be done seperately with POST.

Most e-mail clients only mark an item read when it's open for a few 
seconds, it's a bonus that you can do that too.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

From jg307 at cam.ac.uk  Mon May  9 08:29:05 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Mon, 09 May 2005 16:29:05 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <427F5642.60507@w3future.com>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>
Message-ID: <427F81C1.3060001@cam.ac.uk>

Sjoerd Visscher wrote:

> James Graham wrote:
>
>> I should have stated explicitly that when I said "marking the message 
>> as read in some way" I intended that the "some way" could be more 
>> than just changing a message's unread flag, it could be e.g. moving 
>> the message from the inbox to a "Read messages" folder. Even if the 
>> message is "just" marked as read, this can change more than the 
>> appearance of the message - it can change where in the interface it 
>> is displayed (in some sort of virtual-folder based setup), etc.   So 
>> I don't think you can dismiss this as "not really a good example of a 
>> non-idempotent action" - it clearly /is/ non-idempotent yet 
>> representing the action as a link is normal and widely understood.
>>
>
> What this shows is that marking a message read when it is retrieved is 
> a bad idea. Retrieving a message must be done with GET, so that it can 
> be cached. Setting the read state should be done seperately with POST.

But can you do it such that it will work without javascript? I consider 
distinguishing read/unread messages to be a basic enough feature that it 
should be possible to implement it without requiring client-side 
scripting. In this case, the obvious implementation would be a 
javascript function called when the message was recieved that performed 
a background POST request to update the read flag on the message. Is 
there a better way?

> Most e-mail clients only mark an item read when it's open for a few 
> seconds, it's a bonus that you can do that too.

That's really not necessary for a web-based client (at least one with 
the example UI) since every message is explicitly requested by a click 
(as I understand it, the timer solves the problem that keyboard 
navigation over a list of messages can result in message being marked 
read).

This example isn't unique in assosiating a document request with an 
implicit change in that status of that document to the user. Another 
example would be a web-based document management system which had a 
"recently viewed documents" section. Again, this could be implemented by 
POSTing a "the document is actually being viewed" notification but 
that's really complex compared to just putting the logic to update the 
recently viewed documents list in the request handling function. Better, 
perhaps, but much more complex and requiring client side code to do 
something that previously could be handled server side.

Clearly allowing lins with method="post" would help these situations 
although they would break precaching of the webapp.

Assuming that people dislike  and accept that not all 
state altering operations imply form controls, it might not be possible 
for HTML5 to mitigate the additional server-side complexity mandated by 
requiring that GET operations are shadowed by extra POST operations 
everytime that requesting part of a web-app has an effect on the state 
of the app. Even so, we should make it easy to implement the client side 
part of the deal, preferably in a script-free way.

-- 
"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

From ben at benmeadowcroft.com  Mon May  9 09:00:12 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Mon, 9 May 2005 17:00:12 +0100
Subject: [whatwg] Web Apps 1.0: Editing
In-Reply-To: 
Message-ID: <000a01c554b0$336dfa70$0202a8c0@BensPC>

> On Sun, 8 May 2005, Ben Meadowcroft wrote:
> > 
> > Perhaps have two subsections, one for full document editing 
> > (designMode) and the other for element content editing 
> > (contentEditable).
> 
> Is there any difference between
> 
>    
> 
> ...and
> 
>    
> 
> ...?

Well setting designMode on the body won't work, it is set on the document
object using script, document.designMode="on". Actually I guess this
should added to one of the Document interfaces described in the spec.

Other than that I'm not sure what the differences between them are, I
imagine that setting  is pretty similar to
turning on designMode, perhaps someone else can shed some light on this?

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From ian at hixie.ch  Mon May  9 09:05:36 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 9 May 2005 16:05:36 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: Editing
In-Reply-To: <000a01c554b0$336dfa70$0202a8c0@BensPC>
References: <000a01c554b0$336dfa70$0202a8c0@BensPC>
Message-ID: 

On Mon, 9 May 2005, Ben Meadowcroft wrote:
> 
> Well setting designMode on the body won't work, it is set on the 
> document object using script, document.designMode="on". Actually I guess 
> this should added to one of the Document interfaces described in the 
> spec.
> 
> Other than that I'm not sure what the differences between them are, I 
> imagine that setting  is pretty similar to 
> turning on designMode, perhaps someone else can shed some light on this?

If document.body.designMode = 'on' is equivalent to 
document.body.contentEditable = 'on' then I don't see much point in having 
both. If they are different, let me know. :-)

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

From ben at benmeadowcroft.com  Mon May  9 14:53:43 2005
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Mon, 9 May 2005 22:53:43 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <851c8d31050508104713d6c07e@mail.gmail.com>
Message-ID: <001f01c554e1$92b000b0$0202a8c0@BensPC>

> On 5/8/05, Ian Hickson  wrote:
> > On Sun, 8 May 2005, Ben Meadowcroft wrote:
> > >
> > > There are two types of help that I think are appropriate for web 
> > > applications, full page help and element sensitive help.
> > 
> > The problem with both is discoverability. Unless we can solve that, 
> > there is not much point having anything in the spec.
> 
> For the context sensitive one we use CSS with a cursor:help  
> that's the way we usually implement it from a visible 
> perspective, I'm not sure if there's particular value in 
> defining an attribute to take the help contents though, 
> especially as this would mean it couldn't then have mark-up, 
> which most of the context help systems I've done do use.

Having mark-up would be useful. My intent was to provide a method of
showing context sensitive help which allowed for a bit more information
than displaying the title as a tool tip does. Mark-up would go well with
that idea.

Discoverability would be left to the user agents. This kind of help is
fairly well established in windows, just look at the internet options
dialog of Internet Explorer for an example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: 

From ian at hixie.ch  Mon May  9 15:04:01 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 9 May 2005 22:04:01 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <001f01c554e1$92b000b0$0202a8c0@BensPC>
References: <001f01c554e1$92b000b0$0202a8c0@BensPC>
Message-ID: 

On Mon, 9 May 2005, Ben Meadowcroft wrote:
> 
> Discoverability would be left to the user agents.

Unless someone can come up with a way to make discoverability practical 
and usable, there is no point us having this feature. The user agent 
manufacturers have already looked at this for some time and failed to come 
up with any reasonable mechanisms, which is why we removed help="" from 
Web Forms 2. Saying it is "left up to the UAs" doesn't help us when we 
_are_ the UAs. :-)

> This kind of help is fairly well established in windows, just look at 
> the internet options dialog of Internet Explorer for an example.

Context-sensitive help is well established in modern GUIs, yes. But the 
mechanisms by which it is made available are not available or discoverable 
to the end user in a Web scenario.

For example:

 * A cursor doesn't help, since it requires the user to hover over the 
   element in order to discover there is help needed.

 * A hot key is not useful since there is no way for the user to know when
   it would work (and since in the overwhelming majority of cases it would
   do nothing, there is no reason for the user to think to try it).

 * A menu item has the same problem as a hot key.

 * A button that can be pressed like in Windows dialogs is not an option
   because such a button doesn't exist and UA vendors object to 
   introducing new buttons due to the noticable effect it has on 
   usability (based on studies that have been made).

 * An icon that appears next to controls with help is unworkable since
   the icons would interfere with the page layout and thus need to be
   stylable to satisfy authors. (Furthermore, such help is already
   possible in a backwards-compatible way simply using hyperlinks.)

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

From dean at edwards.name  Mon May  9 15:51:06 2005
From: dean at edwards.name (Dean Edwards)
Date: Mon, 09 May 2005 23:51:06 +0100
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: 
References: <001f01c554e1$92b000b0$0202a8c0@BensPC>

Message-ID: <427FE95A.7000402@edwards.name>

Ian Hickson wrote:
 > On Mon, 9 May 2005, Ben Meadowcroft wrote:
 >
 >> Discoverability would be left to the user agents.
 >
 >
 > Unless someone can come up with a way to make discoverability
 > practical and usable, there is no point us having this feature.

It is not all about user agents. I once had to build a web application
with extensive context sensitive help. The app even recalled common
entries for data fields. To make it work we invented an attribute called
"helpID". If the "help" attribute were defined we would have used that
instead.

 > Context-sensitive help is well established in modern GUIs, yes. But
 > the mechanisms by which it is made available are not available or
 > discoverable to the end user in a Web scenario.
 >
 > For example:
 >
 > * A cursor doesn't help, since it requires the user to hover over the
 >  element in order to discover there is help needed.
 >

This provides some feedback at least. But Windows apps don't tend to
provide this form of feedback anyway.

 > * A hot key is not useful since there is no way for the user to know
 > when it would work (and since in the overwhelming majority of cases
 > it would do nothing, there is no reason for the user to think to try
 > it).
 >

An application is something that might be used often. People can
discover F1 for themselves. The UA could at least let the user know that
help is available by enabling the "help" point and click icon.

 > * A menu item has the same problem as a hot key.
 >

The help menu could be updated with page specific help items.

 > * An icon that appears next to controls with help is unworkable since
 >  the icons would interfere with the page layout and thus need to be
 > stylable to satisfy authors. (Furthermore, such help is already
 > possible in a backwards-compatible way simply using hyperlinks.)
 >

A web developer might want to indicate that help is available though:

[help]::after {
   content: url(help-icon.png);
}

I think that a help attribute is useful in the realm of web
applications. Applications tend to be more complex than web documents. A
good application is sometimes only as good as its help system. Even if
UAs make nothing of it, web developers would have a standard attribute
to hook their own help systems from.

-dean

From lachlan.hunt at lachy.id.au  Mon May  9 17:38:06 2005
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 10 May 2005 10:38:06 +1000
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <851c8d31050508104713d6c07e@mail.gmail.com>
References: <003901c553b0$a03fc350$0202a8c0@BensPC>	
	<851c8d31050508104713d6c07e@mail.gmail.com>
Message-ID: <4280026E.50608@lachy.id.au>

Jim Ley wrote:
> adding in a link rel of help would seem a pretty low rent thing to
> define,

There's already a "help" relationship defined in HTML 4 [1], it doesn't 
need to be added.  Perhaps it's semantics could be refined and maybe 
give some examples of use and describe some possible implementation methods.

[1] http://www.w3.org/TR/html401/types.html#h-6.12

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

From ian at hixie.ch  Tue May 10 00:58:03 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 May 2005 07:58:03 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0: On-line help
In-Reply-To: <427FE95A.7000402@edwards.name>
References: <001f01c554e1$92b000b0$0202a8c0@BensPC>

	<427FE95A.7000402@edwards.name>
Message-ID: 

On Mon, 9 May 2005, Dean Edwards wrote:
> >
> > Unless someone can come up with a way to make discoverability 
> > practical and usable, there is no point us having [help].
> 
> It is not all about user agents. I once had to build a web application 
> with extensive context sensitive help. The app even recalled common 
> entries for data fields. To make it work we invented an attribute called 
> "helpID". If the "help" attribute were defined we would have used that 
> instead.

I don't see anything wrong with a Web application using custom attributes 
(preferably clearly prefixed or in a custom namespace) to store 
information like this. But I don't see the value in making the attribute 
for such a case standard. It would restrict what you could do with it, for 
one -- say the Web app wanted to store just a number for the help. Or just 
a URI. Or two URIs. Or an IDREF. Or a string. If we had an attribute, we'd 
have to define what it was, thus either blocking innovation, or using up 
an attribute for no good reason.

> [...reasons why the things I listed might work sometimes...]

Yes, all the things I listed are plausible solutions, that's why I listed 
them. But they're not good _enough_, IMHO.

> I think that a help attribute is useful in the realm of web 
> applications. Applications tend to be more complex than web documents. A 
> good application is sometimes only as good as its help system. Even if 
> UAs make nothing of it, web developers would have a standard attribute 
> to hook their own help systems from.

I don't see the advantage of having a standard way of doing something 
non-standard. It wouldn't improve interoperability.

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

From fora at annevankesteren.nl  Tue May 10 03:50:26 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 10 May 2005 12:50:26 +0200
Subject: [whatwg] [wf2] Note about XML attribute value handling
Message-ID: <428091F2.1000201@annevankesteren.nl>

Could we perhaps make a note about this in the WF2 specification:

Preferably somewhere close to . My weblog used to run 
on XHTML and previewed weblog comments where stored inside the VALUE 
attribute of a hiddenINPUT element (actually, that is still the case). 
As XHTML means the above mentioned XML rule applies all formatting got 
lost. That was a major problem for white-space significant replies. 
(Replies using the PRE element.)

I think it might make sense for the specification to point that out. And 
perhaps provide a way in a future update to the specification to have a 
hidden TEXTAREA. (Such a TEXTAREA can be implemented now using: 
foo.)

There was a similar problem with the XHTML admin of Movable Type as 
described here:

-- 
  Anne van Kesteren

From markwubben at gmail.com  Tue May 10 05:27:20 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Tue, 10 May 2005 14:27:20 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <427F81C1.3060001@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
Message-ID: <3b24e6c505051005276bb44a5e@mail.gmail.com>

On 5/9/05, James Graham  wrote:
> But can you do it such that it will work without javascript? I consider
> distinguishing read/unread messages to be a basic enough feature that it
> should be possible to implement it without requiring client-side
> scripting. In this case, the obvious implementation would be a
> javascript function called when the message was recieved that performed
> a background POST request to update the read flag on the message. Is
> there a better way?
Well, you could load an iframe with a redirect meta element, which
will then, uhm, use GET to modify the state. That's all I can think
off, though.

From mikko.rantalainen at peda.net  Tue May 10 13:49:57 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Tue, 10 May 2005 23:49:57 +0300
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <428091F2.1000201@annevankesteren.nl>
References: <428091F2.1000201@annevankesteren.nl>
Message-ID: <42811E75.4030907@peda.net>

Anne van Kesteren wrote:
> Could we perhaps make a note about this in the WF2 specification:
>   
> 
> Preferably somewhere close to . My weblog used to run 
> on XHTML and previewed weblog comments where stored inside the VALUE 
> attribute of a hiddenINPUT element (actually, that is still the case). 
> As XHTML means the above mentioned XML rule applies all formatting got 
> lost. That was a major problem for white-space significant replies. 
> (Replies using the PRE element.)

 works just fine with existing UAs even when one 
uses application/xhtml+xml provided that all meaningful whitespace has 
been converted to entities. 
 for LF,  for CR and so on. PHP, 
for example, provides function htmlentities() exactly for this purpose.

It would be nice to have a note about that somewhere in the spec. I too 
found it hard way.

-- 
Mikko

From fora at annevankesteren.nl  Tue May 10 16:37:14 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Wed, 11 May 2005 01:37:14 +0200
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <42811E75.4030907@peda.net>
References: <428091F2.1000201@annevankesteren.nl> <42811E75.4030907@peda.net>
Message-ID: <428145AA.6000803@annevankesteren.nl>

Mikko Rantalainen wrote:
>> Could we perhaps make a note about this in the WF2 specification:
>>   
>>
>> Preferably somewhere close to . My weblog used to 
>> run on XHTML and previewed weblog comments where stored inside the 
>> VALUE attribute of a hiddenINPUT element (actually, that is still the 
>> case). As XHTML means the above mentioned XML rule applies all 
>> formatting got lost. That was a major problem for white-space 
>> significant replies. (Replies using the PRE element.)
>
>  works just fine with existing UAs even when one 
> uses application/xhtml+xml provided that all meaningful whitespace has 
> been converted to entities. 
 for LF,  for CR and so on. PHP, 
> for example, provides function htmlentities() exactly for this purpose.

Really? Why would 'htmlentities' be useful in an XML environment? Also, 
getting HTML *entities* in your XML document doesn't seem like a good thing.

(I'm aware of possible solutions. It's just that you don't normally 
think of this. Even Tim Bray - editor of the XML specification - called 
it "broken as designed".)

-- 
  Anne van Kesteren

From mikko.rantalainen at peda.net  Tue May 10 22:48:32 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Wed, 11 May 2005 08:48:32 +0300
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <428145AA.6000803@annevankesteren.nl>
References: <428091F2.1000201@annevankesteren.nl> <42811E75.4030907@peda.net>
	<428145AA.6000803@annevankesteren.nl>
Message-ID: <42819CB0.702@peda.net>

Anne van Kesteren wrote:
> Mikko Rantalainen wrote:
>> works just fine with existing UAs even when one 
>>uses application/xhtml+xml provided that all meaningful whitespace has 
>>been converted to entities. 
 for LF,  for CR and so on. PHP, 
>>for example, provides function htmlentities() exactly for this purpose.
> 
> Really? Why would 'htmlentities' be useful in an XML environment? Also, 
> getting HTML *entities* in your XML document doesn't seem like a good thing.

Yes, you're right that in some cases that results in problems. That's 
because htmlentities() returns entity references like """; if it 
*only* returned numeric character references like """ it would work 
just fine despite the fact that it's designed for HTML. Those numbers 
refer to UNICODE character points. Als note that XML normalization rules 
state that "For a character reference, append the referenced character 
to the normalized value" but "For an entity reference, recursively apply 
step 3 of this algorithm to the replacement text of the entity." [1] 
Real world  user agent behavior might differ and that's what I'm really 
interested in.

That said, I'm using my own function to correctly encode special 
characters to numerical character references, but the point remains the 
same. It doesn't matter if you put stuff in the contents of an element 
or inside an attribute value; you *have to* encode the string to hide 
special characters. If you put the string inside an attribute, the 
encoding must also include all whitespace and quotation characters in 
addition to characters like "<", "&" and ">".

You cannot put a random string between  and  tags 
either and expect to get a valid XML fragment as a result.

[1] http://www.w3.org/TR/REC-xml/#AVNormalize

-- 
Mikko

From fora at annevankesteren.nl  Wed May 11 02:48:51 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Wed, 11 May 2005 11:48:51 +0200
Subject: [whatwg] [wf2] Note about XML attribute value handling
In-Reply-To: <42819CB0.702@peda.net>
References: <428091F2.1000201@annevankesteren.nl>
	<42811E75.4030907@peda.net>	<428145AA.6000803@annevankesteren.nl>
	<42819CB0.702@peda.net>
Message-ID: <4281D503.5030301@annevankesteren.nl>

Mikko Rantalainen wrote:
> You cannot put a random string between  and  tags 
> either and expect to get a valid XML fragment as a result.

True, that's why htmlspecialchars was created (in PHP). (Note that there 
are five predefined entities in XML of which " is one.)

-- 
  Anne van Kesteren

From markwubben at gmail.com  Wed May 11 03:28:25 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Wed, 11 May 2005 12:28:25 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <3b24e6c505051005276bb44a5e@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
Message-ID: <3b24e6c505051103282661831e@mail.gmail.com>

I think the following things are going on here:
1) Because of easier styling links have been used for non-idempotent actions
2) The semantics defining such an action are located in the URI,
instead of HTTP. Think `/delete/$id`
3) A way to solve this would be to use buttons with good styling. The
styling will be hard to do cross-browser
4) Another way is to use ``

I'd like to expend on point 4. It would be rather easy to create an
implementation for older browsers. The problem, however, occurs when
the `href` attribute points to the non-idempotent URI: without JS
providing the compatibility, it would still evoke a non-idempotent
action on the server. A way to solve this is by linking the `href` to
a URI which asks for confirmation (through a form), while using an
`action` attribute to specify the location of the non-idempotent
action. If the spec states that `href` must not equal `action`, we
have a solution for the problem.

An example:

    delete

What do you think?

From kornel at ldreams.net  Wed May 11 03:50:02 2005
From: kornel at ldreams.net (Kornel Lesinski)
Date: Wed, 11 May 2005 11:50:02 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <3b24e6c505051103282661831e@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk> <427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk> <427F5642.60507@w3future.com>
	<427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>
Message-ID: 

On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
wrote:

> An example:
>
>      method="post">delete
>
> What do you think?

That it doesn't look like data to send using POST method.
I'm afraid that in most cases it will be used as:

delete

So there must be something that requires authors to use it properly...

-- 
regards, Kornel Lesinski

From markwubben at gmail.com  Wed May 11 05:24:22 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Wed, 11 May 2005 14:24:22 +0200
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

Message-ID: <3b24e6c505051105244c825ced@mail.gmail.com>

On 5/11/05, Kornel Lesinski  wrote:
> That it doesn't look like data to send using POST method.
> I'm afraid that in most cases it will be used as:
> 
> delete
> 
> So there must be something that requires authors to use it properly...

Hmm, interesting. Perhaps the `href` must link to a resource outside
this page? This stuff is getting way too complicated....

From hsivonen at iki.fi  Wed May 11 06:42:35 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 11 May 2005 16:42:35 +0300
Subject: [whatwg] RELAX NG + Schematron schemas?
Message-ID: <93354aff6755fba0042414ef13e7a82e@iki.fi>

What's the situation with WHAT WG schema deliverables? Does WHAT WG 
even consider them WHAT WG deliverables? At some point fantasai was 
working on an SGML DTD. Is anyone planning on writing RELAX NG + 
Schematron schemas for the WHAT WG specs?

Has anyone assessed the nature of the machine checkable conformance 
criteria in terms of checkability using RELAX NG and the Schematron? 
How significant and numerous are the criteria that cannot be checked 
using RELAX NG of the Schematron?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From ian at hixie.ch  Wed May 11 10:05:47 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 May 2005 17:05:47 +0000 (UTC)
Subject: [whatwg] RELAX NG + Schematron schemas?
In-Reply-To: <93354aff6755fba0042414ef13e7a82e@iki.fi>
References: <93354aff6755fba0042414ef13e7a82e@iki.fi>
Message-ID: 

On Wed, 11 May 2005, Henri Sivonen wrote:
>
> What's the situation with WHAT WG schema deliverables? Does WHAT WG even 
> consider them WHAT WG deliverables? At some point fantasai was working 
> on an SGML DTD. Is anyone planning on writing RELAX NG + Schematron 
> schemas for the WHAT WG specs?
> 
> Has anyone assessed the nature of the machine checkable conformance 
> criteria in terms of checkability using RELAX NG and the Schematron? How 
> significant and numerous are the criteria that cannot be checked using 
> RELAX NG of the Schematron?

Anyone who wants to work on such support files is welcome to do so and 
will be provided with access to the syntax.whatwg.org site to make them 
available. Personally I won't be spending any time on them. The spec won't 
be giving any syntax support files normative status (since doing so would 
be redundant with teh spec prose).

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

From gavin at tmpei.com  Wed May 11 04:52:43 2005
From: gavin at tmpei.com (Gavin Anderegg)
Date: Wed, 11 May 2005 08:52:43 -0300
Subject: [whatwg] Correction for the Web Applications 1.0 Document
Message-ID: <2E4D1A9B-6887-40EB-9898-81F1E72E229A@tmpei.com>

Section 2.1.5 - Class
     In the following sentence there is a duplicate "separated":
     The value must be a list of zero or more words (consisting of  
one or more non-space characters) separated separated by one or more  
spaces.

Great document, by the way. Keep up the good work.

--------------
Gavin Anderegg
TechnoMedia PEI

Tel: 902.368.3043
Fax: 902.566.5447

From ian at hixie.ch  Wed May 11 10:08:24 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 May 2005 17:08:24 +0000 (UTC)
Subject: [whatwg] Re: Correction for the Web Applications 1.0 Document
In-Reply-To: <2E4D1A9B-6887-40EB-9898-81F1E72E229A@tmpei.com>
References: <2E4D1A9B-6887-40EB-9898-81F1E72E229A@tmpei.com>
Message-ID: 

On Wed, 11 May 2005, Gavin Anderegg wrote:
> 
> Section 2.1.5 - Class
>     In the following sentence there is a duplicate "separated":
>     The value must be a list of zero or more words (consisting of one or more
> non-space characters) separated separated by one or more spaces.
> 
> Great document, by the way. Keep up the good work.

Thanks, fixed.

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

From fantasai.lists at inkedblade.net  Wed May 11 20:50:25 2005
From: fantasai.lists at inkedblade.net (fantasai)
Date: Wed, 11 May 2005 23:50:25 -0400
Subject: [whatwg] [WA1] Literals and Actions, comments on inline markup
Message-ID: <4282D281.8030905@inkedblade.net>

Literals
--------

   There doesn't seem to be any appropriate markup for literals in HTML.

   For example:

      The words 'elude' and 'allude' are frequently mixed up.

   The formatting for such elements varies freely: I've seen single quotes
   (which I prefer), double quotes, and italics. It is therefore stylistic,
   and should be controlled (or controllable) with CSS.

Actions
-------

   I can't figure out any appropriate markup for things like

      The pattern, I said, not the text! *runs away*
                                         ^^^^^^^^^^^
                                            this.

   It's not used in formal specs or professional web apps, but,
   it's frequently used in less formal discussions.

Links ()
-----------

   * # If the a element has no href attribute, then the element is a placeholder

     This is nice.

   * Scanning quickly through the texts for  and , I didn't see a
     discussion of their differing semantics. Chris Hoess sums up an explanation
     you gave to him four years ago in bug 87428:

     https://bugzilla.mozilla.org/show_bug.cgi?id=87428#c43

     "Ian actually managed to convince me last night on IRC that there's a reason
      to have different UI for  and .  The first is
      a page link; the relationship denoted in the link element applies for the
      whole page. The second is a context link; the relationship denoted applies
      to the immediate context of the anchor element."

     I would like to see this mentioned in the spec.

   * # The type attribute ... is purely advisory.

     Should it factor into the algorithm for determining a file's content type
     when meta-information is not there, or is that outside the scope of this
     spec?

   * One of the previous uses of  was to mark a destination anchor with
     'name'. For the most part, the 'id' attribute has made this use obsolete.
     I'm wondering, though, what would be the appropriate WA1 markup to use
     for anchoring to a bit of text that is not otherwise marked-up?

     For example, I use  to mark sentence fragments in
       http://fantasai.inkedblade.net/weblog/2003/marketing/tab-logic#what
     so that I can refer to them in the discussion. (I'll admit the styling
     is not well-chosen... numbering them with CSS would have been ideal.)

Emphasis ()
---------------

   # The em element represents stress emphasis of its contents.

   I would render 'stress emphasis' as 'emphatic stress'.

   The example, btw, is *excellent*.

Strength ()
-------------------

   Subtle change from HTML4 semantics, and I think I approve. The example,
   again, is excellent.

   The contrast between
     # Changing the importance of a piece of text with the strong element
     # does not change the meaning of the sentence.
   and
     # The placement of emphasis changes the meaning of the sentence.
   is brilliant.

Highlighting ()
------------------

   # The m element represents a run of text marked or highlighted.

   This is cool.

   Another use for it would be in highlighting important phrases in
   documents optimized for skimming. (Or buzzwords in marketing hype
   like at the top of
     http://fantasai.inkedblade.net/weblog/2003/marketing/about
   , not that I approve of such language.)

   I'd say the distinction between highlighting and  & 
   is that highlighting does not change the reading of the text when
   you're reading straight through, it just helps you find the
   bits you should pay attention to.

Small Print ()
---------------------

   # The small element represents small print (part of a document often
   # describing legal restrictions, such as copyrights or other
   # disadvantages), or other side comments.

   Is  appropriate for the example at the end of
     http://fantasai.inkedblade.net/weblog/2003/big-small/
   ?

   # Note: The small element does not "de-emphasise" or lower the
   # importance of text emphasised by the em element or marked as
   # important with the strong element.

   Does  de-emphasize the text at all? This paragraph implies
   that it does, except within  or , but it is not clear
   from the definition.

Defining Instances ()
--------------------------

   # The paragraph, definition list group, or section that contains the
   # dfn element contains the definition for the term given by the
   # contents of the dfn element.

   I have very often seen defining instances whose definition is limited
   to just the sentence in which it appears. The rest of the paragraph
   is related discussion, of course, but nothing I would pull out into
   a glossary.

   Also, this sentence implies that  should be used with , but
   I don't see what you mean by that implication. There are no examples
   with  in the  section. If I were to take that idea and run
   with it, I'd say that if a  contains a , then the 
 is
   defining the term contained within the  only; the rest of the

 is extra meta-information. E.g.

term (t?rm)
    ...

Instance of Term ()
----------------------

   # The i element represents an instance of the use of a term, such as
   # a taxonomic designation, technical term, an idiomatic phrase from
   # another language, or similar.

   I think this is a great definition for an element we really need to
   have in HTML.

   However, I am not convinced that leaving HTML with no purely
   presentational tag for italics is a good idea. That leaves nothing
   for people who do not have the time, opportunity, or patience to
   learn/semantic/ HTML markup and for simplistic authoring UAs. 
   and  are often the first -- or only -- tags people learn, and
   they are among the few tags understood by most commenting systems.
   Whatever semantics you declare here for  will be flagrantly
   ignored by all but a minority of authors. How is defining 's
   semantics this way useful?

Inline Code Fragments ()
------------------------------

   The example should be of an inlined code fragment, not a block-inline
   tag combination pretending to be a block element.

Sample Output ()
----------------------

   # Nested samp and kbd  elements allow for the styling of specific elements
   # of the sample output using a stylesheet.
   #
   # jdoe at mowmow:~$ssh demo.example.com
   # Last login: Tue Apr 12 09:10:17 2005 from mowmow.example.com on pts/1
   # Linux demo 2.6.10-grsec+gg3+e+fhs6b+nfs+gr0501+++p3+c4a+gr2b-reslog-v6.189
   # #1 SMP Tue Feb 1 11:22:36 PST 2005 i686 unknown
   # jdoe at mowmow:~$ _

   This is an interesting example. The outer  can be interpreted as
   "output of terminal" and the inner one as "output of shell", which seems
   all well and good.

   However, what if I wanted to colorize the output of Mozilla's layout
   regression tests?

   Running verify test for E:\moz_src\mozilla\layout\html\tests\block\rtest.lst.
   Writing regression data to
     E:\moz_src\mozilla\layout\html\tests\table\core\verify\standards1.rgd
   Comparing to regression data from
     E:\moz_src\mozilla\layout\html\tests\table\core\baseline\standards1.rgd
   frame bbox mismatch: 0,26437,4824,600 vs. 0,26437,4872,600
   Node 1:
     TableOuter(table)(144) 0x10004 0,26437,4824,600, |null attr|-16777216|left:
     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw top:
     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top: 1[0x1]enum
     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum 0|1
     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw  Null
     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0 8
     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
   Node 2:
     TableOuter(table)(144) 0x10004 0,26437,4872,600, |null attr|-16777216|left:
     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw top:
     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top: 1[0x1]enum
     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum 0|1
     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw  Null
     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0 8
     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
   frame bbox mismatch: 0,0,4824,600 vs. 0,0,4872,600

   (This makes more sense if it's not wrapped. See
     http://www.mozilla.org/newlayout/doc/regression_tests.html
    But not much more.)

   I would want to mark up
     - the Running veryify test line
     - the Writing regression data line
     - the Comparing to line
     - the filenames in each of those
     - the frame bbox mismatch label
     - its vs. value
     - the node labels
     - the frame type (TableOuter(table))
     - each name-value pairing in the output line

   However, it does not seem to me that marking these with  would be the
   right thing to do any more than marking up function names, variable names,
   and keywords in a code sample with  would be the right thing to do.
   Either those are both right, or they're both wrong.

   Please specify.

User Input ()
------------------

   # The kbd element represents user input (typically keyboard input,
   # although it may also be used to represent other input, such as
   # voice commands).

   Can we have some examples for marking up GUI elements? E.g.

     Don't press the Emergency button.

     Go to Tools > Options... and select the General tab. Change
     the Indentation Type radio from Tabs to Spaces, check the
     Auto-Indent box, and type 4 into the Indent Spaces box.

   Those should be marked up so that one can use a style sheet to
     - make "Emergency" look like a button
     - display "Tools" and "Options" in the menu font
     - make "General" look like a tab
     - make "4" look like it's typed inside a text input
     - and use the appropriate label fonts for "Indentation Type",
       "Tabs", "Spaces", "Auto-Indent", and "Indent Spaces".

   # When the kbd element is nested inside another kbd element, it
   # represents an actual key or other single unit of input as
   # appropriate for the input mechanism.

   So "Press the Esc key" would be marked up as
     Press the Esc key
   ?

Superscripts and Subscripts (^{and _{)
---------------------------------------------

   # marking up mathematical, but

   "mathematical" should be replaced with a noun.

Quotes ()
------------

   * You should probably add some notes on presentation, esp. wrt
     quote mark generation.

   * You need to explain that  should only be used for actual
     quotations, not as a shortcut for “ and ”. (I've
     seen it abused that way, but I forget where..)

General
-------

   Overall, I'm really, really impressed with what you've done here.

   One nit: Please provide actual titles for the sections (as I have
   done here) rather than just putting the element name. (But don't
   leave out the element name either.)

~fantasai

From fantasai.lists at inkedblade.net  Wed May 11 21:14:23 2005
From: fantasai.lists at inkedblade.net (fantasai)
Date: Thu, 12 May 2005 00:14:23 -0400
Subject: [whatwg] [WA1] Literals and Actions, comments on inline markup
In-Reply-To: <4282D281.8030905@inkedblade.net>
References: <4282D281.8030905@inkedblade.net>
Message-ID: <4282D81F.70900@inkedblade.net>

fantasai wrote:
> 
> Strength ()
> -------------------
> 
>   Subtle change from HTML4 semantics, and I think I approve. The example,
>   again, is excellent.
> 
>   The contrast between
>     # Changing the importance of a piece of text with the strong element
>     # does not change the meaning of the sentence.
>   and
>     # The placement of emphasis changes the meaning of the sentence.
>   is brilliant.

Figured out what was bothering me about the first sentence.

   # The strong element represents strong importance for its contents.

Change "strong importance" to "importance stress". This also puts it
in parallel with "emphatic stress".

~fantasai

From Maniac at SoftwareManiacs.Org  Thu May 12 03:07:43 2005
From: Maniac at SoftwareManiacs.Org (Maniac)
Date: Thu, 12 May 2005 14:07:43 +0400
Subject: [whatwg] [WA1] Literals and Actions, comments on inline markup
In-Reply-To: <4282D281.8030905@inkedblade.net>
References: <4282D281.8030905@inkedblade.net>
Message-ID: <42832AEF.4070704@SoftwareManiacs.Org>

fantasai wrote:

> Literals
> --------
>
>   There doesn't seem to be any appropriate markup for literals in HTML.
>
>   For example:
>
>      The words 'elude' and 'allude' are frequently mixed up.
>
>   The formatting for such elements varies freely: I've seen single quotes
>   (which I prefer), double quotes, and italics. It is therefore 
> stylistic,
>   and should be controlled (or controllable) with CSS.

Not so freely in fact. For example in russian typography these things 
should be marked up only with quotes (U+00AB and U+00BB). Simple double 
quotes (") are however more widely used and single quotes (') are also 
used but mainly in tech-savvy environment. But speaking of italics as a 
way of marking up literals - this just won't be understood within 
majority of people. Italics in russian typography is quite rare and may 
be associated perhaps only with emphasis, not literals.

That said I agree that it should be controllable with CSS. But since 
it's not entirely stylistic it shouldn't be controlled only by stylesheet.

From sjoerd at w3future.com  Thu May 12 12:01:21 2005
From: sjoerd at w3future.com (Sjoerd Visscher)
Date: Thu, 12 May 2005 21:01:21 +0200
Subject: [whatwg] A thought:}}
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>

Message-ID: <4283A801.8040601@w3future.com>

Kornel Lesinski wrote:
> On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
> wrote:
> 
>> An example:
>>
>>     > method="post">delete
>>
>> What do you think?
> 
> 
> That it doesn't look like data to send using POST method.
> I'm afraid that in most cases it will be used as:
> 
> delete
> 
> So there must be something that requires authors to use it properly...
> 
Why? People write browser/standard specific things all the time. If it 
works for them, who cares?

I like this proposal because it actually solves the original problem, 
without a need for Google to change their accelerator code.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

From jg307 at cam.ac.uk  Thu May 12 15:05:37 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Thu, 12 May 2005 23:05:37 +0100
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>

Message-ID: <4283D331.7080803@cam.ac.uk>

Kornel Lesinski wrote:
> On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
> wrote:
> 
>> An example:
>>
>>     > method="post">delete
>>
>> What do you think?
> 
> 
> That it doesn't look like data to send using POST method.
> I'm afraid that in most cases it will be used as:
> 
> delete
> 
> So there must be something that requires authors to use it properly...
> 

Wouldn't it work if a single URL in the the href attribute was used for 
both request types? i.e. simply
delete
The serverside application would be expected to deal with GET requests 
on the URI in a sane way e.g. returning a confirmation page with a 
POSTable form on it - this would account for legacy clients and allow 
tools like GWA to work.

From michael at quuxo.com  Thu May 12 20:28:10 2005
From: michael at quuxo.com (Michael Gratton)
Date: Fri, 13 May 2005 12:58:10 +0930
Subject: [whatwg] A thought: 
In-Reply-To: <4283A801.8040601@w3future.com>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
Message-ID: <15cb675b6b43eba69145b1873029306a@quuxo.com>

[resent, to the list this time]

On 13/05/2005, at 4:31, Sjoerd Visscher wrote:
>
> I like this proposal because it actually solves the original problem, 
> without a need for Google to change their accelerator code.

No, it won't in many/most cases.

The Google Accelerator (and every other spidering tool, such as wget) 
will still fetch those links using GET because they are not aware of 
the new semantics implied by method="post". Most web applications I 
have seen (certainly nearly every one written in Java) do not 
differentiate between parameters provided by a GET or a POST; you can 
do either and the application will work in the same way. So the 
Accelerator will keep on fetching those links and applications will 
still perform some non-idempotent action and we will still have the 
same problem.

Since implementing this proposal to solve the Google Accelerator 
problem means both modifying existing UA to support it and/or fixing 
the web apps that are broken anyway, I would rather just fix the broken 
web apps in the first place and not implement this proposal.

/Mike

-- 
Michael Gratton, Software Architect.
Quuxo Software 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: 

From mikko.rantalainen at peda.net  Thu May 12 23:31:30 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Fri, 13 May 2005 09:31:30 +0300
Subject: [whatwg] A thought: 
In-Reply-To: <4283D331.7080803@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>	
	<4283D331.7080803@cam.ac.uk>
Message-ID: <428449C2.7090400@peda.net>

James Graham wrote:
> Kornel Lesinski wrote:
>>On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben   
>>wrote:
>>>
>>>    >>method="post">delete
>>
>>That it doesn't look like data to send using POST method.
>>I'm afraid that in most cases it will be used as:
>>
>>delete
> 
> Wouldn't it work if a single URL in the the href attribute was used for 
> both request types? i.e. simply
> delete
> The serverside application would be expected to deal with GET requests 
> on the URI in a sane way e.g. returning a confirmation page with a 
> POSTable form on it

+1

Server can figure out if the request has been made with GET or POST 
and it can behave correctly using to that information.

During transition phase scripting can be used to POST the delete 
operation or scripting could be used to add something to the GET 
request (like "?jsconfirmdone=1"). Details doesn't matter here as 
we're talking about workarounds that make the thing work without the 
confirmation page in UAs that don't support this new attribute 
"method". Default fallback behavior would be to use confirmation 
page generated by the server.

Broken server apps will be still broken and there's nothing we can 
write in the spec that forces every developer to create perfect 
applications.

-- 
Mikko

From ian at hixie.ch  Fri May 13 03:31:23 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 May 2005 10:31:23 +0000 (UTC)
Subject: [whatwg] Re: Forming Opinions
Message-ID: 

(In response to
   http://www.xml.com/pub/a/2005/04/20/deviant.html
   http://www.xml.com/pub/a/2005/04/27/deviant.html
   http://www.xml.com/pub/a/2005/05/04/deviant.html
   http://www.xml.com/pub/a/2005/05/11/deviant.html
...)

First of all, thanks for your comments!

I've skipped past the less concrete remarks, since they mostly relate to 
general issues of what direction Web browsers should be going in, whereas 
the WHATWG charter starts off with an assumption as to what direction they 
should go in, letting other directions be discussed and used in parallel.

You wrote:
>
> Section 2 starts off saying "At the heart of any form lies the form 
> controls", which seems like a poor choice of words. 

Agreed. Removed.

> Another useful resource is description of common features that are 
> widely implemented in IE and other browsers, but not formally documented 
> as a standard anywhere. In this camp is the autocomplete attribute. 
> There are likely others as well, but the arrangement of the document 
> makes it difficult to see which features fall into this category.

True. I have made a note to add an appendix in future specs that detail 
which parts are known to have been widely implemented already.

> Based on that experience, I've concluded that [the repetition] section 
> doesn't live up to one of the primary requirements of WF2: that it 
> should provide familiar ground for existing developers.

I agree. Unfortunately we haven't really seen a better proposal. 
Suggestions welcome! (The XForms model is unfortunately not really an 
option here for several reasons; in the first place it is not backwards 
compatible, not even to the small extent that the WF2 model is, and in the 
second place it is poorly defined in terms of the DOM, which makes it hard 
to integrate into the general HTML forms and CSS styling model.)

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

From hsivonen at iki.fi  Fri May 13 06:47:01 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 13 May 2005 16:47:01 +0300
Subject: [whatwg] A thought: 
In-Reply-To: <15cb675b6b43eba69145b1873029306a@quuxo.com>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk> <427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk> <427F5642.60507@w3future.com>
	<427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>
Message-ID: 

On May 13, 2005, at 06:28, Michael Gratton wrote:

> Most web applications I have seen (certainly nearly every one written 
> in Java) do not differentiate between parameters provided by a GET or 
> a POST; you can do either and the application will work in the same 
> way.

Of the various server-side frameworks available Java servlets are among 
the most cluefully designed when it comes to getting HTTP right. If a 
developer calls doPost from doGet, there is nothing the framework 
designer can do about it.

I'm still -1 on changing the specs to accommodate people who have been 
ignoring RFC 2616.

By the way, the main problem with the publicized case was that their 
non-idempotent GETs did not have query strings. Usually the people who 
don't respect the idempotency of GETs also have crufty URLs with query 
strings so that a robot can apply heuristics to avoid query strings.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From michael at quuxo.com  Fri May 13 07:42:04 2005
From: michael at quuxo.com (Michael Gratton)
Date: Sat, 14 May 2005 00:12:04 +0930
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi> <427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com> <427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com> <427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>

Message-ID: <1115995324.7233.13.camel@localhost.localdomain>

On Fri, 2005-05-13 at 16:47 +0300, Henri Sivonen wrote:
> Of the various server-side frameworks available Java servlets are among 
> the most cluefully designed when it comes to getting HTTP right. If a 
> developer calls doPost from doGet, there is nothing the framework 
> designer can do about it.

True. I am not bashing the Servlet API, I am just pointing out common
practise. The Struts framework, for example, is a very popular Java
framework built on the Servlet API but it calls the same processing
method for both GETs and POSTs. Very poor form.

Also, I think that because it uses same API to access parameters
specified by both GET and POST requests it tends to encourage this sort
of behaviour. But this is probably OT.

> I'm still -1 on changing the specs to accommodate people who have been 
> ignoring RFC 2616.

Ditto.

> Usually the people who 
> don't respect the idempotency of GETs also have crufty URLs with query 
> strings so that a robot can apply heuristics to avoid query strings.

Which of course might punish sites (or users of sites) that have valid
uses for query strings.

/Mike.

-- 
Michael Gratton, Software Architect.
Quuxo Software 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: 

From jg307 at cam.ac.uk  Fri May 13 08:56:44 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Fri, 13 May 2005 16:56:44 +0100
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>

Message-ID: <4284CE3C.4040606@cam.ac.uk>

Henri Sivonen wrote:

> On May 13, 2005, at 06:28, Michael Gratton wrote:
>
>> Most web applications I have seen (certainly nearly every one written 
>> in Java) do not differentiate between parameters provided by a GET or 
>> a POST; you can do either and the application will work in the same way.
>
>
> Of the various server-side frameworks available Java servlets are 
> among the most cluefully designed when it comes to getting HTTP right. 
> If a developer calls doPost from doGet, there is nothing the framework 
> designer can do about it.
>
> I'm still -1 on changing the specs to accommodate people who have been 
> ignoring RFC 2616.

That seems to be based on the belief that all things which look like 
links must correspond to idempotent actions. I don't think this is true 
and, in general, think that trying to couple the user interface to the 
underlying protocol is a bad idea.

-- 
"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

From kornel at ldreams.net  Fri May 13 09:43:59 2005
From: kornel at ldreams.net (Kornel Lesinski)
Date: Fri, 13 May 2005 17:43:59 +0100
Subject: [whatwg] A thought: 
In-Reply-To: <4284CE3C.4040606@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>
	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>
	<427D510F.6010802@cam.ac.uk> <427D78B0.2080608@myrealbox.com>
	<427E141B.2060604@cam.ac.uk> <427F5642.60507@w3future.com>
	<427F81C1.3060001@cam.ac.uk>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>

	<4284CE3C.4040606@cam.ac.uk>
Message-ID: 

On Fri, 13 May 2005 16:56:44 +0100, James Graham  wrote:

> That seems to be based on the belief that all things which look like  
> links must correspond to idempotent actions.

Yes, that is exactly the idea behind it.

> I don't think this is true and, in general, think that trying to couple  
> the user interface to the underlying protocol is a bad idea.

That is user interface which represents what protocol does.

Links are not coupled with http GET method. You may link to any resource  
using any protocol, but following a link should not have side-effects - by  
design.

Web applications usually don't have undo, so IMHO it should be clear that  
click on certain UI elements has side effects.

Difference between radio buttons and checkboxes is quite clear by looks of  
them. There should be difference between links and buttons as well,  
because one _goes_ somewhere, and another  _does_ something.

In case with marking e-mail as read that would be element that _goes_  
somewhere AND _does_ something, so I think that  might be suitable in  
this case.

How about requiring non-idempotent links to have rel="nofollow"? That  
might solve the "google accelerator problem".

-- 
regards, Kornel Lesinski

From olav at olav.dk  Fri May 13 13:28:56 2005
From: olav at olav.dk (=?ISO-8859-1?Q?Olav_Junker_Kj=E6r?=)
Date: Fri, 13 May 2005 22:28:56 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <4284CE3C.4040606@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>	
	<4284CE3C.4040606@cam.ac.uk>
Message-ID: <42850E08.2030505@olav.dk>

James Graham wrote:
> That seems to be based on the belief that all things which look like 
> links must correspond to idempotent actions. I don't think this is true 
> and, in general, think that trying to couple the user interface to the 
> underlying protocol is a bad idea.

No, its a great idea! ;-)

Most users dont know anything about POST or GET, but I believe its a 
common expectation that you can always safely click links (and then 
press back to return), while you should think twice about pressing a 
form button, since it might indicate that you agree to something or 
wants to buy something or subscribe to a mailinglist or whatever.

I think this coupling between protocol and UI is one of the great ideas 
of the web.

So a link which performs a unsafe action is not just wrong according to 
HTTP, its also bad UI.

regards
Olav Junker Kj?r

From jg307 at cam.ac.uk  Fri May 13 14:02:24 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Fri, 13 May 2005 22:02:24 +0100
Subject: [whatwg] A thought: 
In-Reply-To: 
References: <427BF5D1.8050207@colorstudy.com>	<6cda28534ce9660c4ddfcb110df1a11b@iki.fi>	<427D510F.6010802@cam.ac.uk>
	<427D78B0.2080608@myrealbox.com>	<427E141B.2060604@cam.ac.uk>
	<427F5642.60507@w3future.com>	<427F81C1.3060001@cam.ac.uk>	<3b24e6c505051005276bb44a5e@mail.gmail.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>		<4284CE3C.4040606@cam.ac.uk>

Message-ID: <428515E0.5020408@cam.ac.uk>

Kornel Lesinski wrote:

> On Fri, 13 May 2005 16:56:44 +0100, James Graham  wrote:
>
>> That seems to be based on the belief that all things which look like  
>> links must correspond to idempotent actions.
>
>
> Yes, that is exactly the idea behind it.
>
>> I don't think this is true and, in general, think that trying to 
>> couple  the user interface to the underlying protocol is a bad idea.
>
>
> That is user interface which represents what protocol does.
>
> Links are not coupled with http GET method. You may link to any 
> resource  using any protocol, but following a link should not have 
> side-effects - by  design.
>
> Web applications usually don't have undo, so IMHO it should be clear 
> that  click on certain UI elements has side effects.

But that's already unclear. Given a button on a web page it's impossible 
(without context) to tell if it has side effects or not. If I click the 
"Search" button on Google, it has no side effects yet the "Submit Order" 
(or whatever the exact working is) button on Amazon, despite being 
exactly the same type of UI element, has side effects. The same is true 
in offline UIs - the Save menu item in my text editor is non-idempotent 
yet the close-by Open  menu item is idempotent. In general, it's hard to 
think of a class of UI where it's unambiguous which actions will have 
side effects just from the visual presentation of the elements and 
without additional contextual information.

Despite this, people have the desire to make links a special class of UI 
object that correspond to idempotent actions only. From a purely 
mechanical point of view, this makes sense - after all one doesn't want 
bots to follow links. From the point of view of that part of the web 
that consists of interlinked documents it mostly makes sense. But from 
the point of view of web applications, it doesn't make sense. It makes 
no sense to require a webmail application to use a form element to open 
each message just because doing so modifies the underlying database, 
despite the fact that a link is an appropriate element to represent the 
action.

Fortunately for the UI designers, there is an acceptable alternative to 
a link. It's  with  javascript to provide the  behavior. Even if 
there was a way to ensure that links were _never_ used for 
non-idempotent actions, you'd still see link-like elements used for such 
actions. Unfortunately they'd have none  of the semantic value  offered 
by  elements.

-- 
"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

From markwubben at gmail.com  Sat May 14 11:02:30 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Sat, 14 May 2005 20:02:30 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <428515E0.5020408@cam.ac.uk>
References: <427BF5D1.8050207@colorstudy.com>
	<3b24e6c505051005276bb44a5e@mail.gmail.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>
	 <4284CE3C.4040606@cam.ac.uk>

	<428515E0.5020408@cam.ac.uk>
Message-ID: <3b24e6c50505141102285c593@mail.gmail.com>

On 5/13/05, James Graham  wrote:
> Despite this, people have the desire to make links a special class of UI
> object that correspond to idempotent actions only. From a purely
> mechanical point of view, this makes sense - after all one doesn't want
> bots to follow links. From the point of view of that part of the web
> that consists of interlinked documents it mostly makes sense. But from
> the point of view of web applications, it doesn't make sense. It makes
> no sense to require a webmail application to use a form element to open
> each message just because doing so modifies the underlying database,
> despite the fact that a link is an appropriate element to represent the
> action.
>
> Fortunately for the UI designers, there is an acceptable alternative to
> a link. It's  with  javascript to provide the  behavior. Even if
> there was a way to ensure that links were _never_ used for
> non-idempotent actions, you'd still see link-like elements used for such
> actions. Unfortunately they'd have none  of the semantic value  offered
> by  elements.

And this, I think, is the gist of the argument here. I agree with
James here, but what about you?

From markwubben at gmail.com  Sat May 14 11:04:04 2005
From: markwubben at gmail.com (Mark Wubben)
Date: Sat, 14 May 2005 20:04:04 +0200
Subject: [whatwg] A thought: 
In-Reply-To: <3b24e6c50505141102285c593@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>
	<3b24e6c505051103282661831e@mail.gmail.com>

	<4283A801.8040601@w3future.com>
	<15cb675b6b43eba69145b1873029306a@quuxo.com>
	 <4284CE3C.4040606@cam.ac.uk>

	<428515E0.5020408@cam.ac.uk>
	<3b24e6c50505141102285c593@mail.gmail.com>
Message-ID: <3b24e6c5050514110468434643@mail.gmail.com>

Argh, sorry, folks.. I keep messing things up here. Must be the
conversation view...

On 5/13/05, James Graham  wrote:
> Despite this, people have the desire to make links a special class of UI
> object that correspond to idempotent actions only. From a purely
> mechanical point of view, this makes sense - after all one doesn't want
> bots to follow links. From the point of view of that part of the web
> that consists of interlinked documents it mostly makes sense. But from
> the point of view of web applications, it doesn't make sense. It makes
> no sense to require a webmail application to use a form element to open
> each message just because doing so modifies the underlying database,
> despite the fact that a link is an appropriate element to represent the
> action.
>
> Fortunately for the UI designers, there is an acceptable alternative to
> a link. It's  with  javascript to provide the  behavior. Even if
> there was a way to ensure that links were _never_ used for
> non-idempotent actions, you'd still see link-like elements used for such
> actions. Unfortunately they'd have none  of the semantic value  offered
> by  elements.

And this, I think, is the gist of the argument here. I agree with
James here, but what about you?

From dean at edwards.name  Mon May 16 13:00:02 2005
From: dean at edwards.name (Dean Edwards)
Date: Mon, 16 May 2005 21:00:02 +0100
Subject: [whatwg] Implementation of WF2 for IE
In-Reply-To: <3b24e6c5050514110468434643@mail.gmail.com>
References: <427BF5D1.8050207@colorstudy.com>	<3b24e6c505051103282661831e@mail.gmail.com>		<4283A801.8040601@w3future.com>	<15cb675b6b43eba69145b1873029306a@quuxo.com>	
	<4284CE3C.4040606@cam.ac.uk>		<428515E0.5020408@cam.ac.uk>	<3b24e6c50505141102285c593@mail.gmail.com>
	<3b24e6c5050514110468434643@mail.gmail.com>
Message-ID: <4288FBC2.8080009@edwards.name>

Hi all,

Some of the developers on this list are collaborating on a scripted 
implementation of Web Forms 2.0 for Internet Explorer (Win32). We are 
hosting the development on SourceForge. The solution will be available 
under the LGPL (although that it is open to change). There is an open 
discussion here:

https://sourceforge.net/forum/forum.php?forum_id=466583

We'd appreciate your help/insight/suggestions. To confess, we are 
already flummoxed by the CVS system, so if someone can be of help then 
visit the link above. The other developers are Olav Junker Kj?r (who has 
been extremely busy), Erik Arvidsson and Dimitri Glazkov.

The project home page is here:

https://sourceforge.net/projects/wf2/

There is very little to see so far. I'll post again when there is 
something concrete to demonstrate. This message is mostly a call for 
help with CVS. ;-)

Regards,
-dean

From ian at hixie.ch  Sat May 21 06:09:57 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 21 May 2005 13:09:57 +0000 (UTC)
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: <428F237D.8000508@annevankesteren.nl>
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>
Message-ID: 

On Sat, 21 May 2005, Anne van Kesteren wrote:
> Dan Brickley wrote:
> > Perhaps  would work?
> 
> Dropping [] would work too. I still haven't seen any use cases that 
> require this particular empty construct.

Actually Steven Pemberton gave some interesting examples of what look to 
me like valid use cases for 
 in a recent talk of his. Search for  
in these slides:

   http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/

I don't really see what else to use for those.

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

From fora at annevankesteren.nl  Sat May 21 06:25:33 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sat, 21 May 2005 15:25:33 +0200
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com>
	<20050521112154.GJ18952@homer.w3.org>	<428F237D.8000508@annevankesteren.nl>

Message-ID: <428F36CD.1030408@annevankesteren.nl>

Ian Hickson wrote:
>>> Perhaps  would work?
>> 
>> Dropping [] would work too. I still haven't seen any use cases
>> that require this particular empty construct.
> 
> Actually Steven Pemberton gave some interesting examples of what look
> to me like valid use cases for  in a recent talk of his. Search
> for  in these slides:
> 
> http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/
> 
> I don't really see what else to use for those.

Why doens't SECTION suffice? They are sections separated by decoration.
At least, that is how it appeals to me.

-- 
  Anne van Kesteren

From ian at hixie.ch  Sat May 21 06:33:14 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 21 May 2005 13:33:14 +0000 (UTC)
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: <428F36CD.1030408@annevankesteren.nl>
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>

	<428F36CD.1030408@annevankesteren.nl>
Message-ID: 

On Sat, 21 May 2005, Anne van Kesteren wrote:
> 
> Why doens't SECTION suffice? They are sections separated by decoration. 
> At least, that is how it appeals to me.

They're not really sections. The chapter is the section, these are 
paragraphs together in the same chapter, with a divider between some of 
the paragraphs.

I read a lot of fiction books and when I come across a "* * *" it reads to 
me like a paragraph, saying "Meanwhile, in a different part of the 
universe:"; it doesn't read as "end section. new section:".

IMHO.

To put it another way, sections are things that you can put a title to. 
There's no title you can put to a group of paragraphs separated from other 
groups of paragraphs in the same chapter of a work of fiction, in my 
experience. It's just the same chapter, with the narrative exploring 
different characters or scenes.

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

From rimantas at gmail.com  Sat May 21 06:42:05 2005
From: rimantas at gmail.com (Rimantas Liubertas)
Date: Sat, 21 May 2005 16:42:05 +0300
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>

Message-ID: <5ccfb334050521064226f6c575@mail.gmail.com>

On 5/21/05, Ian Hickson  wrote:
<...>
> Actually Steven Pemberton gave some interesting examples of what look to
> me like valid use cases for 
 in a recent talk of his. Search for 
> in these slides:
> 
>    http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/
> 
> I don't really see what else to use for those.
> 

I see no point for this even in this case. If you separate _sections_,
then they are already separate and you can style sections themself.

Example: http://rimantas.com/bits/hr/nohr.html

And if  had any semantic meaning, then it was trasfered to class
attribute ;)

Regards,
Rimantas
-- 
http://rimantas.com/

From christoph.paeper at tu-clausthal.de  Sun May 22 15:59:16 2005
From: christoph.paeper at tu-clausthal.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Mon, 23 May 2005 00:59:16 +0200
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com>
	<20050521112154.GJ18952@homer.w3.org>	<428F237D.8000508@annevankesteren.nl>		<428F36CD.1030408@annevankesteren.nl>

Message-ID: <42910EC4.5010601@tu-clausthal.de>

Ian Hickson schrieb:
> 
> I read a lot of fiction books and when I come across a "* * *" it reads to 
> me like a paragraph, saying "Meanwhile, in a different part of the 
> universe:"; it doesn't read as "end section. new section:".

     ...
     ...

     ...

     ...
     ...

Works have either just one plot or more which are either parallel (like 
the example above) or nested (where the top-most doesn't need to be 
stuffed into a 'div'). Correct mark-up (in inadequate presentation) 
could destroy the reader's pleasure, though, when the author wants to 
keep the recipient in the dark about what point of view a certain part 
really belongs to.

> To put it another way, sections are things that you can put a title to. 

'div' is the proper HTML element type for subdivisions (of sections) 
that actually are not sections. (IMO sections always have a heading, 
'h'.) It, optionally, can be categorized with the 'class' attribute and 
be identified by an 'id' attribute.

> There's no title you can put to a group of paragraphs separated from other 
> groups of paragraphs in the same chapter of a work of fiction, in my 
> experience.

Anyhow you can still group paragraphs by wrapping them in a division 
instead of dividing them by a separator. The latter is IMO not a very 
markupish approach. MLs are usually about putting (informational) atoms 
into bags and these into larger ones, iterated until you reach the top 
one, the root.

From ian at hixie.ch  Sun May 22 16:38:19 2005
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 22 May 2005 23:38:19 +0000 (UTC)
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: <42910EC4.5010601@tu-clausthal.de>
References: <428BCDCA.3010204@eammm.com> <20050521112154.GJ18952@homer.w3.org>
	<428F237D.8000508@annevankesteren.nl>

	<428F36CD.1030408@annevankesteren.nl>

	<42910EC4.5010601@tu-clausthal.de>
Message-ID: 

On Mon, 23 May 2005, Christoph P?per wrote:
> Ian Hickson schrieb:
> > 
> > I read a lot of fiction books and when I come across a "* * *" it reads to
> > me like a paragraph, saying "Meanwhile, in a different part of the
> > universe:"; it doesn't read as "end section. new section:".
> 
>   
>     ...
>     ...
>     
>     
>     ...
>     
>     ...
>     ...
>   

...has no semantics apart from delineating one section. Remember that 
class="" and  are meaningless. A document has the same semantics 
after you strip out any class attributes and  elements.

> > To put it another way, sections are things that you can put a title 
> > to.
> 
> 'div' is the proper HTML element type for subdivisions (of sections) that
> actually are not sections.

According to what specification? According to HTML4,  only "defines 
content to be block-level" (whatever that means!).

> Anyhow you can still group paragraphs by wrapping them in a division 
> instead of dividing them by a separator. The latter is IMO not a very 
> markupish approach. MLs are usually about putting (informational) atoms 
> into bags and these into larger ones, iterated until you reach the top 
> one, the root.

The paragraphs are all part of the  (chapter). They're not 
further grouped together, IMHO. An 
 is equivalent to a  with the 
content "Meanwhile, somewhere else..." or similar ("From someone else's 
point of view...", "At another time..."). In fact if a story was to be 
styled into comic form, 
 elements would typically be presented as 
narrator-level text in the next paragraph's panel. For example:

   No! said Fred.

   The tree stood alone.

In comic form:

   +----------+ +--------------+-------+
   |  _____   | | Meanwhile... |       |
   | < No! >  | +--------------+       |
   |  \/^^^   | |         /|\          |
   |  o       | |         /|\          |
   | -+-      | |          |           |
   | / \      | |          |           |
   +----------+ +----------------------+

Not that we have any user agents or stylesheet languages (short of actual 
humans) capable of that kind of interpretation and presentation today, but 
my point is that the  here is a unit on par with a paragraph, it's not 
an artefact of an implied higher level grouping.

In text form:

   "No!" said Fred.

      *   *   *

   The tree stood alone.

In aural form:

   No!, said Fred. [pause] The tree stood alone.

If we didn't have , I would imagine the above example would be marked 
up as:

   No! said Fred.
   * * *
   The tree stood alone.

...or some such. I really don't think:

    No! said Fred.

    The tree stood alone.

...would be better than , in fact I think it would be unnatural from 
an authoring perspective. We mustn't fall into the trap of considering 
everything to be a hierarchy, just because that is what XML most easily 
marks up. Book authors have managed quite well for centuries without 
considering their documents to be formed of trees! (Notwithstanding what 
paper is made of, I mean.)

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

From mikko.rantalainen at peda.net  Mon May 23 03:40:49 2005
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Mon, 23 May 2005 13:40:49 +0300
Subject: [whatwg] Re: About XHTML 2.0
In-Reply-To: 
References: <428BCDCA.3010204@eammm.com>
	<20050521112154.GJ18952@homer.w3.org>	<428F237D.8000508@annevankesteren.nl>		<428F36CD.1030408@annevankesteren.nl>

Message-ID: <4291B331.50408@peda.net>

Ian Hickson wrote:
> On Sat, 21 May 2005, Anne van Kesteren wrote:
> 
>>Why doens't SECTION suffice? They are sections separated by decoration. 
>>At least, that is how it appeals to me.
> 
> They're not really sections. The chapter is the section, these are 
> paragraphs together in the same chapter, with a divider between some of 
> the paragraphs.
> 
> I read a lot of fiction books and when I come across a "* * *" it reads to 
> me like a paragraph, saying "Meanwhile, in a different part of the 
> universe:"; it doesn't read as "end section. new section:".

I read the "* * *" part exactly the same way. And I consider your 
quoted text to be the header for that sub-section even though it's 
omitted from the output. I feel that the correct markup to use would be

Yet another chapter

In the Jack's basement
...

Meanwhile in the Bill's room
...

In my opinion, this is the correct sematics for the content. To 
increase excitement for the reader, some of the content is hidden 
during the presentation. If you feel that hiding the information is 
part of the semantics in this case (arguably that may be true), just 
drop all the  elements with class "undisclosed" above.

I think this is an example of why an  element shouldn't be 
required inside a  element.

IMHO.

> To put it another way, sections are things that you can put a title to. 
> There's no title you can put to a group of paragraphs separated from other 
> groups of paragraphs in the same chapter of a work of fiction, in my 
> experience. It's just the same chapter, with the narrative exploring 
> different characters or scenes.

I think you can always put a title to a group of paragrahps. It's 
just that sometimes (often?) you decide to leave it out for brevity 
/ clarity / excitement / whatever.

-- 
Mikko

From olav at olav.dk  Tue May 24 11:13:06 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 24 May 2005 20:13:06 +0200
Subject: [whatwg] Submit buttons
Message-ID: <42936EB2.4090901@olav.dk>

I think there is a slight inconsistency with submit buttons.
Section 2.17.:
"Normally, activating a submit button ... must submit the first form the 
control is associated with"
Section 2.3
"If the platform supports submitting a form implicitly ... then when 
doing so the first submit button, this default button, must be the one 
used to initiate form submission (and it will therefore be successful)."

The problem is that the the default button for a form might not submit 
the same form when activatated, if the form is not the first form in the 
forms collection of the button.

It could be solved by requiring that submit buttons (and input 
type=image) may only be associated with a single form at a time.

regards
Olav Junker Kj?r

From supercanadian at gmail.com  Thu May 26 12:08:49 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 12:08:49 -0700
Subject: [whatwg] General TCP connections API?
Message-ID: <84ce626f050526120834cb3241@mail.gmail.com>

Hello,

(Please excuse me if this has already been discussed.  I'm still
working my way through the mailing list archive.  Also, I hope I'm not
out of place by just interjecting myself.)

Are there any plans to add an API to create TCP connections?

IMO, this is very necessary for creating "web applications".  And it
would be unfortunate if it wasn't included.

Right now, there seems to be a new fad revolving around
XmlHttpRequest.  It has been nicknamed AJAX by many.  And heralded as
a means of asynchronous communication for the Web.  However, AJAX only
gives the illusion of asynchronous communication between the server
and client.  The client is polling the server.  And often a new TCP
connection is created (and later tore down) each time the server is
polled.  (Which, IMO, is bad.)

The nice thing about XmlHttpRequest is that it makes it so you can
"update" a webpage without having to reload it.  Which improves
usability.  However, because of the polling, performance is adversely
affected.  Not to mention that polling is not the optimal mode of
communication.

One could come up with a new protocol for asynchronous communication. 
(Maybe as something to accompany HTTP.  Or maybe even as an extension
to it -- HTTP 1.2?)  Which may solve this problem.  But other
"problems" could arise in the future.  It would be good to provide
developers (of web applications) the building blocks to solve a wider
set of problems.  And to me, I think having an API to create TCP
connection is one of these building blocks.

Some might say that letting the client create general TCP connects
would bring up all sorts of security concerns.  However, I think these
security concerns can be dealt with by making it so the API would only
allow the client to create a TCP connection to the "host" that the
client -- the webpage (or web application) -- came from.

Or, alternatively, we could allow the host that the webpage (or web
application) came from to specify a list of domains (or IP addresses)
that clients could connect to.  (Of course, there would be
restrictions on this.  The hosts in that list would need to "allow"
the original host to do this.  A mechanism for this would need to be
created.)

There could even be other restrictions.  For example, a host could
specify what ports it allows webpages (and web applications) to
connnect to.

So,... are there any plans to add an API to create TCP connections?

See ya

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From kornel at ldreams.net  Thu May 26 12:58:35 2005
From: kornel at ldreams.net (Kornel Lesinski)
Date: Thu, 26 May 2005 20:58:35 +0100
Subject: [whatwg] General TCP connections API?
In-Reply-To: <84ce626f050526120834cb3241@mail.gmail.com>
References: <84ce626f050526120834cb3241@mail.gmail.com>
Message-ID: 

> The client is polling the server.  And often a new TCP
> connection is created (and later tore down) each time the server is
> polled.  (Which, IMO, is bad.)

HTTP/1.1 uses persistent connections by default. If you set long keepalive  
time on your webserver, chances are that all requests are going to be done  
over same TCP/IP connection.

To have your own connections you'd have to use other port than 80 and that  
may be disallowed on many restricted systems.

If user navigates to the next page, browser will destroy your JS objects  
and close their connections. That may result in worse performance than  
with HTTP connection that is kept alive between pages.

Even if connections are limited to the same host, you couldn't safely  
serve anything else on it. Spammers might use numerous HTML-injection  
techniques to send spam using other people's computers, and this may get  
much worse if host restriction fails. From past experience of hundreds of  
cross-site scripting vulnerabilities, you can be sure that this will  
happen sooner or later.

BTW: There's a hack that lets you get data from server without polling -  
use iframe, start sending its contents and don't close connection - keep  
sending 

every visitor will send spam using example.com server.

On a second thought this may be prevented by forcing some special  
handshake or transport protocol for custom connections...
but then this feature becomes just alternative HTTP + XML RPC that only  
offers smaller lag for price of increased complexity and worse  
browser/server support. Is it worth it?

-- 
regards, Kornel Lesinski

From supercanadian at gmail.com  Thu May 26 15:10:00 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 15:10:00 -0700
Subject: [whatwg] General TCP connections API?
In-Reply-To: 
References: <84ce626f050526120834cb3241@mail.gmail.com>

	<84ce626f05052613307e086b2b@mail.gmail.com>

Message-ID: <84ce626f05052615101c94a0a3@mail.gmail.com>

Hello,

On 5/26/05, Kornel Lesinski  wrote:
> On Thu, 26 May 2005 21:30:18 +0100, Charles Iliya Krempeaux
>  wrote:
> 
> >> To have your own connections you'd have to use other port than 80 and
> >> that may be disallowed on many restricted systems.
> >
> > Could you please elaborate on this.
> 
> Clients that have many blocked ports on firewall - for example to block
> P2P inside school networks.

I made this argument in another e-mail too,... but I'll do it again....

I think that we should allow TCP connections, even if it won't work in
some cases.

For example, often people access the web on a computer at a cafe or
school that does not have an e-mail client.  In these cases the
"mailto" URL will not work.  However, we still allow the "mailto" URLs
in webpages.

Also, it could be the case that a network (on an office) bans outgoing
connects on any port other than 80 (for HTTP) and 443 (for HTTPS).
This would stop FTP URLs from working.  However, we still allow "ftp"
URLs in webpages.

In other words, "let me use it when I can use it".  (Since we are
already following this principle on the web.)

[...]

> >> Even if connections are limited to the same host, you couldn't safely
> >> serve anything else on it. Spammers might use numerous HTML-injection
> >> techniques to send spam using other people's computers, and this may get
> >> much worse if host restriction fails.
> 
> > Could you please elaborate on this.
> 
> Let's say there's website
> example.com/page.php?name=John
> that prints
> Hello "John"!
> 
> On your website, if you create iframe with URL:
> example.com/page.php?name=

I won't be a problem if the web developers is escaping whatever the
user supplies.  (This is developer error, ignorance, or stupidity.) 
For example, if the web developer is using PHP, then he should be
making use of the htmlspecialchars() function.  For example, their
code should be something like:

Web developers should NOT be allowing arbitrary (HTML, JavaScript,
etc) code to get inserted into their webpages on their site!  (Even if
a web developer does this today, he allows the potential for havoc!)

I could also make an argument to NOT allow CGI parameters in the first
place because people could potentially use it to make system calls. 
For example, consider that I have a script that gives me "finger" info
for users of the system.  And suppose it is usually called with
something like:

    http://example.com/finger.cgi?username=joeblow

And that this is implemented with a system call.  Maybe something like:

Then there would be a problem if I called this URL with something like:

    http://example.com/finger.cgi?username=joeblow;rm+-fR+.

Then the command wouldn't just be:

    finger joeblow

But would be

    finger joeblow; rm -fR .

(Which could delete a hole bunch of stuff.)

I don't think developer error, ignorance, or stupidity should be an
argument to not allow TCP connections.

> every visitor will send spam using example.com server.
> 
> 
> On a second thought this may be prevented by forcing some special
> handshake or transport protocol for custom connections...
> but then this feature becomes just alternative HTTP + XML RPC that only
> offers smaller lag for price of increased complexity and worse
> browser/server support. Is it worth it?

The argument for allowing TCP connections isn't so that a small drop
in lag can be obtained.  But so that things that otherwise could not
be solved using HTTP can be solved (using a custom protocol).  (Please
refer to my "streaming images at 24 frames per second" example in the
other e-mail I wrote.)

See ya

> --
> regards, Kornel Lesinski
> 

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From supercanadian at gmail.com  Thu May 26 17:40:21 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 17:40:21 -0700
Subject: Fwd: [whatwg] General TCP connections API?
In-Reply-To: 
References: <84ce626f050526120834cb3241@mail.gmail.com>

	<84ce626f05052613307e086b2b@mail.gmail.com>

	<84ce626f05052615101c94a0a3@mail.gmail.com>

Message-ID: <84ce626f0505261740414b9c44@mail.gmail.com>

Hello,

I think this was suppose to go to the mailing list, and not just me.

See ya

---------- Forwarded message ----------
From: Kornel Lesinski 
Date: May 26, 2005 5:34 PM
Subject: Re: [whatwg] General TCP connections API?
To: Charles Iliya Krempeaux 

On Thu, 26 May 2005 23:10:00 +0100, Charles Iliya Krempeaux
 wrote:

>> On your website, if you create iframe with URL:
>> example.com/page.php?name=
>
> I won't be a problem if the web developers is escaping whatever the
> user supplies.

...and HTML developers should write valid HTML, etc.

Sorry, but there is A LOT of totally ignorant/incompetent web developers
and sysadmins.

> For example, let's say I want to stream images, or video, or audio,
> from the client to the server.

and how are you going to decode and display them using Javascript?
and how that is better than current streaming multimedia plugins? or Java?

> And that there were some high "performance" demands
> for this that HTTP couldn't meet.  (Like, for example, if I wanted to
> push 24 frames per second from client to server.)

This doesn't make sense to me.

HTTP doesn't add any overhead to TCP/IP except headers (you don't have to
use chunked encoding), so your custom protocol can't save you more than
*one* IP packet per file! (and typically less thanks to keepalive
connections)

For high performance you can't use TCP/IP and need some lower-level
protocol like UDP and specially crafted data format that works with
partial/out-of-order packets. That's absolutely not a thing anyone would
dare to implement in Javascript.

--
regards, Kornel Lesinski

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
 Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From supercanadian at gmail.com  Thu May 26 22:58:08 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 26 May 2005 22:58:08 -0700
Subject: [whatwg] General TCP connections API?
In-Reply-To: 
References: <84ce626f050526120834cb3241@mail.gmail.com>

	<84ce626f05052613307e086b2b@mail.gmail.com>

	<84ce626f05052615101c94a0a3@mail.gmail.com>

Message-ID: <84ce626f05052622584508e9f5@mail.gmail.com>

Hello,

On 5/26/05, Kornel Lesinski  wrote:
> On Thu, 26 May 2005 23:10:00 +0100, Charles Iliya Krempeaux
>  wrote:
> 
> >> On your website, if you create iframe with URL:
> >> example.com/page.php?name=
> >
> > I won't be a problem if the web developers is escaping whatever the
> > user supplies.
> 
> ...and HTML developers should write valid HTML, etc.
> 
> Sorry, but there is A LOT of totally ignorant/incompetent web developers
> and sysadmins.

Agreed.  But if you are going to not support (or allow) anything that
could screw up a system due to a mistake by an ignorant/incompetent
web developers or sysadmins then we might as well not allow the whole
concept of CGI, server side scripting, and dynamic database driven
websites.  (Since this could be used to screw up systems.)

Just look at how many people use an HTTP GET (instead of POST, PUT,
DELETE, or something else) to change things -- delete or update
records -- on the webserver.  This sometimes causes problems when
search engines crawl sites.  Does this mean we should get rid of
search engine web crawlers because some ignorant/incompetent web
developer doesn't understand the differences between the different
HTTP methods and how they should be used?

Sometimes ignorant/incompetent web developers pass input from CGI
variables to a system call (unescaped and unquoted).  This can be used
to do all sorts of malicious acts by allowing the user to run
arbitrary commands on the server.  Does this mean that we should get
rid of CGI and server side scripting?

I disagree that ignorance/incompetents web developers or sysadmins
should be a reason to not allow TCP connections.  Because, following
that line of reasoning would be an argument to get rid of CGI, server
side scripting, and database driven websites.

> > For example, let's say I want to stream images, or video, or audio,
> > from the client to the server.
> 
> and how are you going to decode and display them using Javascript?
> and how that is better than current streaming multimedia plugins? or Java?

The image streaming thing was just an example.  (I was trying to come
up with an example that could make use of a TCP connection.  Although
it is an example I was working on before.  The solution to this was to
write a native desktop application for Linux, Windows, and Mac. 
Although part of that was due to needing to access the camera and
microphone on the computer.)

Incidentally, Java provides a TCP connection API like the one I'm
proposing for web applications.  Refer to #8 in the Java Security FAQ:

    http://java.sun.com/sfaq/

I actually think Java would be an excellent solution.  (I actually
really liked it when the JVM was in virtually every browser.) 
However, today, it doesn't seem to be there on all browsers.  Last I
checked, it wasn't even included on Windows XP.  And isn't included on
most Linux distributions.  (Although correct me if I'm wrong.)  Today,
you have to download and install it yourself.

Which is why I think there should be a TCP connection API.  So that a
plain vanilla web browser (of tomorrow) can create a TCP connection
(without relying on extensions that may or may not be there).

> > And that there were some high "performance" demands
> > for this that HTTP couldn't meet.  (Like, for example, if I wanted to
> > push 24 frames per second from client to server.)
> 
> This doesn't make sense to me.
> 
> HTTP doesn't add any overhead to TCP/IP except headers (you don't have to
> use chunked encoding), so your custom protocol can't save you more than
> *one* IP packet per file! (and typically less thanks to keepalive
> connections)
> 
> For high performance you can't use TCP/IP and need some lower-level
> protocol like UDP and specially crafted data format that works with
> partial/out-of-order packets. That's absolutely not a thing anyone would
> dare to implement in Javascript.
> 

What I was talking about here was more about the cost of creating and
tearing down TCP connections when using the HTTP protocol, for each
request.  Although, it is true that the "persistentness" of HTTP/1.1
can help.  However, as I understand it, this "persistentness" can't be
depended on.  (The connection could be closed by the server.)  But
correct me if I'm wrong.  (Perhaps I just don't have enough knowledge
about tweaking a webserver for its persistentness.)

See ya

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/

From dean at edwards.name  Fri May 27 22:44:14 2005
From: dean at edwards.name (Dean Edwards)
Date: Sat, 28 May 2005 06:44:14 +0100
Subject: [whatwg] Web Forms 2.0 Typo
In-Reply-To: <84ce626f05052622584508e9f5@mail.gmail.com>
References: <84ce626f050526120834cb3241@mail.gmail.com>		<84ce626f05052613307e086b2b@mail.gmail.com>		<84ce626f05052615101c94a0a3@mail.gmail.com>	
	<84ce626f05052622584508e9f5@mail.gmail.com>
Message-ID: <4298052E.4060901@edwards.name>

Ian,

Just spotted this: "validityMessage" should be "validationMessage" in 
http://whatwg.org/specs/web-forms/current-work/.

-dean

From ldrhcp at gmail.com  Sat May 28 08:27:13 2005
From: ldrhcp at gmail.com (Lenny Domnitser)
Date: Sat, 28 May 2005 11:27:13 -0400
Subject: [whatwg] Canvas should be script-only, not an HTML element
Message-ID: <94355ecc0505280827707692e6@mail.gmail.com>

Creating a non-semantic