From simonp at opera.com  Fri May  1 00:06:40 2009
From: simonp at opera.com (Simon Pieters)
Date: Fri, 01 May 2009 09:06:40 +0200
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
Message-ID: <op.us8opfayidj3kv@simon-pieterss-macbook.local>

On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 25 Oct 2007, Anne van Kesteren wrote:
>>
>> For Opera 9.5 beta we implemented some experimental extensions to
>> <canvas> involving SVGSvgElement. SVGSvgElement is supported as "image"
>> argument to both drawImage and createPattern. (An HTMLImageElement
>> pointing to an SVG element is also supported, but that seems natural if
>> you support SVG from <img>.)
>>
>> For drawImage the pixel size of the SVG is determined as follows:
>>
>>   1. The image size parameters passed to drawImage
>>   2. The intrinsic size of the SVG image
>>   3. 300 x 150
>>
>> For createPattern it is as follows:
>>
>>   1. The intrinsic size of the SVG image
>>   2. 300 x 150
>>
>> (It would be nice if createPattern was extended to allow height/width
>> arguments as well.)
>>
>> The intrinsic size of the SVG image is the specified size with
>> percentages resolved against 300 x 150, and sizes depending on the
>> font-size resolved against the computed font-size of the SVGSvgElement
>> (will be the browser default most of the time).
>>
>> The SVG image is always rendered at time 0 for animated images.
>>
>> Drawing an SVG image currently marks the canvas context as unsafe so
>> toDataURL() and getImageData() throw. We expect to make this story a bit
>> nicer at some point.
>
> As far as I can tell this doesn't require any changes to HTML5, since the
> same applies here as applies to a regular <img>, right?

It would at least have to change to make it not throw...

"The image argument must be an instance of HTMLImageElement, HTMLCanvasElement, or HTMLVideoElement. If the image is of the wrong type or null, the implementation must raise a TYPE_MISMATCH_ERR exception."

-- 
Simon Pieters
Opera Software



From chaals at opera.com  Fri May  1 04:03:04 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Fri, 01 May 2009 13:03:04 +0200
Subject: [whatwg] converting word (was  <code> attributes
In-Reply-To: <771D246166F7418BAA2BF6512388FEBA@POCZTOWIEC>
References: <bd14ac7c0904281216h8cb7872n42a1bb1dc6541190@mail.gmail.com>
	<46A6570E0F584A659A066B83EE911BA9@disxgdg31szkx7>
	<771D246166F7418BAA2BF6512388FEBA@POCZTOWIEC>
Message-ID: <op.us8znexnwxe0ny@widsith.local>

On Thu, 30 Apr 2009 13:25:17 +0200, Kristof Zelechovski  
<giecrilj at stegny.2a.pl> wrote:

> Automatic conversion from Microsoft Word to HTML is doomed to fail  
> because the document models and the requirements are different.
> The best you can get is a tree of DIVs and SPANs with Word-
> specific classes.  Anything better needs a serious and thoughtful
> remake by the editor.

This is an oversimplification to the point of being misleading.

There are many ways to use Word, and many people and organisations with  
haf a clue use it in such a way that automatic conversion can be  
relatively easily used to generate highly semantically rich and valid  
markup - much better than the sort of tripe one typically finds on the Web  
today.

Word enabled the clear semantic markup of documents before HTML even  
existed, and people who use it like that are in a good position to produce  
HTML that is much better quality than most developers come up with. It  
also enables presentation-driven markup to be converted automatically to  
make the underlying semantics explicit (something that virtually no HTML  
tool outside those which convert from another input format manages to do).

This stuff is not rocket science, either. It is the sort of thing that was  
routine more than a decade ago when people started to use HTML as well as,  
or instead of, Word and similar formats.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

From adrian.sutton at ephox.com  Fri May  1 04:22:32 2009
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Fri, 01 May 2009 12:22:32 +0100
Subject: [whatwg] converting word (was  <code> attributes
In-Reply-To: <op.us8znexnwxe0ny@widsith.local>
Message-ID: <C6209A08.11901%adrian.sutton@ephox.com>

On 01/05/2009 12:03, "Charles McCathieNevile" <chaals at opera.com> wrote:
> This is an oversimplification to the point of being misleading.
> 
> There are many ways to use Word, and many people and organisations with
> haf a clue use it in such a way that automatic conversion can be
> relatively easily used to generate highly semantically rich and valid
> markup - much better than the sort of tripe one typically finds on the Web
> today.

I can verify this with a lot of real world experience.  Ephox has been
selling a WYSIWYG editor for around 10 years now and the single most popular
feature is it's ability to copy and paste clean HTML from Microsoft Word.
The resulting HTML brings over the structure of the document (headings,
tables, lists, images etc) but not the inline formatting so the content then
matches the CSS.  The formatting and styles can optionally be brought over
as well but in the last 3-5 years popular demand has been to match the site
stylesheet rather than the original formatting.

The biggest challenge in this is actually removing the huge amount of inline
formatting and proprietary tags/attributes that Microsoft Word adds.  In the
latest versions it's also a challenge to put lists back together as actual
HTML lists since Word has started exporting them as paragraphs with a bullet
from the symbol font and lots of nbsps.

Pretty much every editor I know of can preserve the semantic information
from Word when copying and pasting, they all vary in how well they strip out
the inline formatting and proprietary tags with most doing a fairly poor job
of this second part.

Regards, 

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>


From brucel at opera.com  Fri May  1 04:27:24 2009
From: brucel at opera.com (Bruce Lawson)
Date: Fri, 01 May 2009 12:27:24 +0100
Subject: [whatwg] converting word (was  <code> attributes
In-Reply-To: <C6209A08.11901%adrian.sutton@ephox.com>
References: <C6209A08.11901%adrian.sutton@ephox.com>
Message-ID: <op.us80ryrch8on37@bruce-pc>

On Fri, 01 May 2009 12:22:32 +0100, Adrian Sutton  
<adrian.sutton at ephox.com> wrote:


> The biggest challenge in this is actually removing the huge amount of  
> inline
> formatting and proprietary tags/attributes that Microsoft Word adds.  In  
> the
> latest versions it's also a challenge to put lists back together as  
> actual
> HTML lists since Word has started exporting them as paragraphs with a  
> bullet
> from the symbol font and lots of nbsps.

Off topic, I know - but couldn't a VBA macro hook into word and actually  
make an "export as semantic html" option that exported the heading levels  
as h1..h6, honoured bold, italics, links, bullets and numbers as ul and  
ol, and just ignored all colours, font changes etc. So there is nothing to  
clean up?

bruce

From adrian.sutton at ephox.com  Fri May  1 04:42:25 2009
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Fri, 01 May 2009 12:42:25 +0100
Subject: [whatwg] converting word (was  <code> attributes
In-Reply-To: <op.us80ryrch8on37@bruce-pc>
Message-ID: <C6209EB1.11908%adrian.sutton@ephox.com>

On 01/05/2009 12:27, "Bruce Lawson" <brucel at opera.com> wrote:
> On Fri, 01 May 2009 12:22:32 +0100, Adrian Sutton
> <adrian.sutton at ephox.com> wrote:
> Off topic, I know - but couldn't a VBA macro hook into word and actually
> make an "export as semantic html" option that exported the heading levels
> as h1..h6, honoured bold, italics, links, bullets and numbers as ul and
> ol, and just ignored all colours, font changes etc. So there is nothing to
> clean up?

Yes, but you'd have to get users to install the macro and get around virus
checkers etc. Then you'd have to write a separate applescript version for
Mac.  I'm not sure how difficult all that would be - it's cheaper for us to
just tweak and update the existing filtering code than it would be to go
down this route now.

It also wouldn't give the option to preserve the styles, but in a HTML
compliant way which the filtering process does give (and pretty impressive
accuracy in rendering given how little control HTML gives compared to Word's
native model). EditLive! for example could include the styles as either an
embedded stylesheet (thus preserving any custom styles from word as class
names) or inline styles (thus making a very messy but compliant bit of HTML
but useful if you're only editing a fragment).

For the record, OpenOffice and it's variants tend to create pretty good HTML
out of the box and don't need this kind of filtering at all.  Excel is even
surprisingly good but does add some proprietary attributes.

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>


From singer at apple.com  Fri May  1 08:14:04 2009
From: singer at apple.com (David Singer)
Date: Fri, 1 May 2009 08:14:04 -0700
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<2c0e02830904060308u10702328n316290b8746586a6@mail.gmail.com>
	<E470702C-DB5F-44C5-8CCD-81AA988FCB29@apple.com>
	<c2e346f90904062111t7429143ande88c37c654b7bb9@mail.gmail.com>
	<2A9F6E32-1680-47E9-98B8-C7DCA6B484B1@apple.com>
	<Pine.LNX.4.62.0904300024400.10370@hixie.dreamhostps.com>
	<2c0e02830904291828v34f4060frc11b0d761e543cea@mail.gmail.com>
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com>
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
Message-ID: <p06240864c620c1e9823c@[17.202.35.52]>

At 11:42  +1000 1/05/09, Silvia Pfeiffer wrote:
>re c):
>It depends on how the UA displays it. If the UA displays the 5s offset
>as the beginning of the video, then the user cannot easily jump to 0s
>offset. I thought this was the whole purpose of the discussion:
>whether we should encourage UAs to display just the addressed segment
>in the timeline (which makes sense for a 5sec extract from a 2 hour
>video) or whether we encourage UAs to display the timeline of the full
>resource only.

I think we came to a slightly more abstract conclusion, that the UA 
focuses the user's initial attention on the indicated fragment.

[And we are silent about how it does that, and also about how easy it 
is to look elsewhere.]

>I only tried to clarify the differences for the UA and
>what the user gets, supporting an earlier suggestion that UAs may want
>to have a means for switching between full timeline and segment
>timeline display. Ultimately, it's a UA problem and not a HTML5
>problem.

Exactly, agreed.
-- 
David Singer
Multimedia Standards, Apple Inc.

From christoph.paeper at crissov.de  Fri May  1 09:36:36 2009
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Fri, 1 May 2009 18:36:36 +0200
Subject: [whatwg] About Descendent Tags
In-Reply-To: <Pine.LNX.4.62.0904301909310.18851@hixie.dreamhostps.com>
References: <d12877180904070546l681f48bbl552ddcf22799c16e@mail.gmail.com>
	<00F1E1E83A6440A29666CF72CA1B7F82@POCZTOWIEC>
	<d12877180904070622k4bf211f6m767f3959b7dd549b@mail.gmail.com>
	<D241D61F88004A41AC8A7515E5E6AE18@POCZTOWIEC>
	<d12877180904070945ha41b89al21cdf2fd8e48f1ff@mail.gmail.com>
	<49DB8574.2020007@opera.com>
	<Pine.LNX.4.62.0904301909310.18851@hixie.dreamhostps.com>
Message-ID: <14B07AEE-3B88-4D3A-A29F-09FE15D4EAD9@crissov.de>

Ian Hickson:
> On Tue, 7 Apr 2009, Kristof Zelechovski wrote:
>>
>> The header element is not for the page header, it is for grouping  
>> section
>> headings, and the tag name chosen for this element is misleading.
>
> I've renamed the old <header> to <hgroup>.

Did you consider using 'h' instead?

From ian at hixie.ch  Fri May  1 14:21:35 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 1 May 2009 21:21:35 +0000 (UTC)
Subject: [whatwg] About Descendent Tags
In-Reply-To: <14B07AEE-3B88-4D3A-A29F-09FE15D4EAD9@crissov.de>
References: <d12877180904070546l681f48bbl552ddcf22799c16e@mail.gmail.com>
	<00F1E1E83A6440A29666CF72CA1B7F82@POCZTOWIEC>
	<d12877180904070622k4bf211f6m767f3959b7dd549b@mail.gmail.com>
	<D241D61F88004A41AC8A7515E5E6AE18@POCZTOWIEC>
	<d12877180904070945ha41b89al21cdf2fd8e48f1ff@mail.gmail.com>
	<49DB8574.2020007@opera.com>
	<Pine.LNX.4.62.0904301909310.18851@hixie.dreamhostps.com>
	<14B07AEE-3B88-4D3A-A29F-09FE15D4EAD9@crissov.de>
Message-ID: <Pine.LNX.4.62.0905012120050.7824@hixie.dreamhostps.com>

On Fri, 1 May 2009, Christoph P?per wrote:
> Ian Hickson:
> > On Tue, 7 Apr 2009, Kristof Zelechovski wrote:
> > > 
> > > The header element is not for the page header, it is for grouping section
> > > headings, and the tag name chosen for this element is misleading.
> > 
> > I've renamed the old <header> to <hgroup>.
> 
> Did you consider using 'h' instead?

I think that would be confusing for people who have heard of XHTML2's <h> 
(since it is quite different; HTML5's <h1> is the better match there). 
Normally that wouldn't be a great concern, but this is one feature of 
XHTML2 that has received a lot of attention from early adopters, and so 
confusion on this front could set the wrong trajectory for a long time to 
come. That is, after all, why we renamed the elements in the first place. :-)

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

From ian at hixie.ch  Fri May  1 16:18:26 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 1 May 2009 23:18:26 +0000 (UTC)
Subject: [whatwg] DOM-related and API-related feedback
In-Reply-To: <25199700630-BeMail@Kev>
References: <25199700630-BeMail@Kev>
Message-ID: <Pine.LNX.4.62.0905012314500.18851@hixie.dreamhostps.com>

On Wed, 1 Apr 2009, Kevin Field wrote:
> On Sun Dec 28 03:38:07 PST 2008, Ian Hickson wrote:
> > On Sun, 8 Jun 2008, Ojan Vafai wrote:
> > > 
> > > I can speak to the first (getNextFocusableElement). One case I have 
> > > hit where this would be useful is a designMode iframe (in this case 
> > > a rich-text editor). I wanted tab to go to the next focusable 
> > > element, which was a different element depending on the context the 
> > > editor is embedded in. There's currently no way to do that.
> > 
> > It seems like this is something that should be left up to the user 
> > agent. After all, how is the Web page to know which key binding moves 
> > the focus normally anyway?
> > 
> > If we were to provide this it seems what we'd have to do is provide an 
> > API that actually moves the focus (e.g. provide a focusNextElement() 
> > method and a focusPreviousElemnt() method), since the next focusable 
> > item might not even have a DOM node (e.g. the location bar) or it 
> > might be in another origin. But then what if the user agent doesn't do 
> > things using a cycle but instead uses directional focus management, 
> > like many phones?
> 
> I'm currently working on a UI that I intend to be fully usable via 
> keyboard or mouse.  When an element is given focus, a mouse-usable UI is 
> generated, but the focused element also accepts keystrokes.  It appears 
> to be currently very difficult to have the element give its focus over 
> to the next available focusable element when the user clicks something 
> in the mouse-usable UI.  So I'm not replacing tab or whatever the 
> keybinding might be, but I do want a click in one area to be followed by 
> a simulated tab (or equivalent) keypress.  This is an important use case 
> for me.
> 
> I propose extending the blur() function to act like history.go(): 
> element.blur(-1) would act like element.focus() plus a shift + tab (or 
> equivalent) keypress, and element.blur(1) would act like element.focus() 
> plus a tab (or equivalent) keypress.
> 
> Your final question made me stop and think, but in the end, "6.5.1 
> Sequential focus navigation" and the tabindex attribute already exist.  
> This should still work.  Developers targeting phone platforms would 
> simply not make use of this function, and in any case, phone users would 
> still have their directional focus management available unless the 
> developer was malicious, in which case she or he could just abuse 
> element.focus() or other existant technologies as-is.

I once drafted something along these lines in the Web Controls draft:

   http://www.whatwg.org/specs/web-controls/current-work/#the-documentui

I haven't added this to HTML5 at this point (I'm concerned about feature 
creep, and I'd rather address this along with other editing problems all 
at once, probably in its own spec), but I think it's something we should 
definitely keep in mind.

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

From christoph.paeper at crissov.de  Sat May  2 04:40:08 2009
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Sat, 2 May 2009 13:40:08 +0200
Subject: [whatwg] About Descendent Tags
In-Reply-To: <Pine.LNX.4.62.0905012120050.7824@hixie.dreamhostps.com>
References: <d12877180904070546l681f48bbl552ddcf22799c16e@mail.gmail.com>
	<00F1E1E83A6440A29666CF72CA1B7F82@POCZTOWIEC>
	<d12877180904070622k4bf211f6m767f3959b7dd549b@mail.gmail.com>
	<D241D61F88004A41AC8A7515E5E6AE18@POCZTOWIEC>
	<d12877180904070945ha41b89al21cdf2fd8e48f1ff@mail.gmail.com>
	<49DB8574.2020007@opera.com>
	<Pine.LNX.4.62.0904301909310.18851@hixie.dreamhostps.com>
	<14B07AEE-3B88-4D3A-A29F-09FE15D4EAD9@crissov.de>
	<Pine.LNX.4.62.0905012120050.7824@hixie.dreamhostps.com>
Message-ID: <CE60AC92-E26E-459E-A803-994455C5CEDE@crissov.de>

Ian Hickson:
> On Fri, 1 May 2009, Christoph P?per wrote:
>> Ian Hickson:
>>> I've renamed the old <header> to <hgroup>.
>> Did you consider using 'h' instead?
>
> I think that would be confusing for people who have heard of  
> XHTML2's <h>
> (since it is quite different; HTML5's <h1> is the better match there).

Well, "the rank of an |hgroup| element is the same as for an |h1|  
element", but to superset XHTML2's |h| more or less, |h|/|hgroup|  
would have to work, i.e. have a text for outlines, without |h#|  
descendants.

   <h><h1>Foo</h1></h>,
   <h><h1>Foo</h1><h2>Bar</h2></h>,
   <h><h2>Bar</h2><h1>Foo</h1></h>,
   <h><h2>Foo</h2></h> and
   <h>Foo</h>

would all have to add "Foo" as a highest rank entry to the document  
(or section) outline.

Anyhow, I just wanted to make sure the option was considered. I don't  
care much either way. It's more important that |header| now matches | 
footer| better.

(And I certainly don't want to reopen the can of worms that is |hr|,  
which I still would expect to be treated like an empty |section| (or | 
h#|/|h|/|hgroup|), not like an empty |p|, thus possibly closing  
implicit sections.)

From shelleyp at burningbird.net  Sat May  2 07:22:03 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Sat, 02 May 2009 09:22:03 -0500
Subject: [whatwg] notes on current HTML5 draft
Message-ID: <49FC570B.9090508@burningbird.net>

Per Ian Hickson's request, first of my notes on the current HTML 5 draft

Section 1.6.3, where you compare HTML5 with XHTML2 and XForms, you write

"However, XHTML2 and XForms lack features to express the semantics of 
many of the non-document types of content often seen on the Web. For 
instance, they are not well-suited for marking up forum sites, auction 
sites, search engines, online shops, mapping applications, e-mail 
applications, word processors, real-time strategy games, and the like.

This specification aims to extend HTML so that it is also suitable in 
these contexts."

This sounds more like marketing speak than something one would find in a 
specification. If it's important for an individual to know why they 
might want to use HTML5 over XHTML2, then the information should be 
given in detail, rather than in one vague paragraph.

In addition, I've not found that the HTML5 specification answers the 
claims given in the above paragraph. For instance, why would HTML5 be 
better for a mapping application than XHTML2? Or an auction site?

In section 1.7, you write

"The "DOM5 HTML", "HTML5", and "XHTML5" representations cannot all 
represent the same content. For example, namespaces cannot be 
represented using "HTML5", but they are supported in "DOM5 HTML" and 
"XHTML5". Similarly, documents that use the noscript  feature can be 
represented using "HTML5", but cannot be represented with "XHTML5" and 
"DOM5 HTML". Comments that contain the string "-->" can be represented 
in "DOM5 HTML" but not in "HTML5" and "XHTML5". And so forth."

"And so forth", is not something one wants to read in a specification, 
because we expect precision, and "and so forth" is vague, and imprecise.

Since the HTML5 supposedly represents both a HTML and a XHTML 
serialization technique, perhaps the document can take a lesson from the 
RDF community and provide a separate document, or at least a section 
detailing the two different serialization techniques. This would go far, 
too, in clearing up the confusion regarding XHTML. Too many people are 
making assumptions that "XHTML is dead" because the XHTML serialization 
of HTML5 is not spelled out as clearly as it could be.

You actually do mix the differences between the two throughout the 
document, but that, to me, seems to 'clutter' up the spec -- making it 
difficult to determine what's new in the spec. If the HTML5 document is 
a new model for web page markup, then the model aspect of the spec 
should be detailed separately from its various serializations, and that 
includes any API.

Right now, it's difficult to read the specification because it jumps too 
frequently between the abstract and the implementation, sometimes in one 
sentence.

More later.

Shelley







From shelleyp at burningbird.net  Sat May  2 07:39:45 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Sat, 02 May 2009 09:39:45 -0500
Subject: [whatwg] Section 3 semantics and structure
Message-ID: <49FC5B31.1050607@burningbird.net>

More general comments on the HTML5 draft:

In section three, you mix structure and semantics, but the two are not 
necessarily compatible.

For instance, we see an introduction to the Document, and then 
immediately proceed into a description of Documents in the DOM. Frankly, 
I don't see how a description of the DOM fits either structure or 
semantics. To me, structure would be the structure of the markup in the 
document, and the semantics would be the, well, it's hard to say what it 
would be, you apply semantics to elements, such as section and header. 
Whatever it is, it's not DOM related.

Then you follow up with Security. What does this have to do with 
structure or semantics?

Perhaps if the intro section was filled in, we would have an 
understanding of what you mean by structure, and semantics. Right now, 
though, I see what is basically a bucket of information, somehow grouped 
under this heading, perhaps because it doesn't fit anywhere else.

Now you do a nice description of what you consider as semantics in 
section 3.3.1, and I would expect this, then, to be followed by a 
listing of the elements, but again, there's the DOM. There's no cohesive 
pattern to the document, especially when the different document levels 
are mixed so haphazardly.

I think of a document as a communication between writer and audience. 
Now there are probably three audiences for HTML5:  user agent 
developers, such as browser companies; web developers, interested in  
the DOM, scripting events, and so on; and designers or others, more 
likely interested in the markup.

I, as a web developer/designer, am not really interested in the user 
agent aspects of the specs. Another person who is a designer, may not be 
interested in the developer or UA aspects. But all of us are forced to 
go through material addressed to all three audiences just to find the 
information we need.

I, a designer interested in learning about the new semantic elements, 
have to wade through sections on the DOM and security, including 
cookies, because I'm not sure when I'll be getting to the bits I need. 
There's no clear demarcation between audiences in the document.

More later

Shelley

From shelleyp at burningbird.net  Sat May  2 08:38:44 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Sat, 02 May 2009 10:38:44 -0500
Subject: [whatwg] section 3 top headers
Message-ID: <49FC6904.7040200@burningbird.net>

More on HTML5 draft review:

Your top level section headers in Section 3 don't make a lot of sense.

In particular, you insert a section on the paragraph element, at the 
same top level that you reference all HTML elements. Why did you plunk 
the paragraph in as a separate section? And I'm also assuming I misread 
the bit about other elements straddling paragraphs. I'm assuming you 
don't mean that something like

And let's look at the section headers:

Introduction
Documents
Elements
Content Models
Paragraphs
APIs in HTML documents
Dynamic Markup insertion

There's no cohesive pattern to this section. One moment you're talking 
about Elements in the DOM, the next paragraph elements. And you're 
actually defining the paragraph element, but the elements are described 
fully in Section 4. Where you also describe the paragraph element.

That's a lot of jumping around for folks.

More later

Shelley


From shelleyp at burningbird.net  Sat May  2 10:23:05 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Sat, 02 May 2009 12:23:05 -0500
Subject: [whatwg] example of serialization problems
Message-ID: <49FC8179.2020001@burningbird.net>

Review of HTML5 document:

Here's a good example of a potential point of confusion for readers of 
the spec when it comes to serialization:

In section 4.5.8 you introduce the ul element, and then demonstrate it 
with a several child li elements, each of which is shown with an HTML 
serialization.

In second 4.5.9, you introduce the li element, and then demonstrate the 
li element using a serialization approach that would work with both 
XHTML and HTML serializations.

And still later, in section 4.5.13.1, you again demonstrate li elements 
using only the HTML serialization format.

In all of this is an implicit assumption of the capabilities of your 
audience, that they understand the differences between the two. Yet, 
this isn't stated as a prereq for the audience of the document. In fact, 
you state that a familiarity with XML is helpful, but not required. And 
as far as I've been able to see, though I may have missed it, 
discussions about closing tags doesn't take place until section 8.

My suggestion would be to include both HTML and XHTML serializations, 
carefully differentiating between the two. Or to provide separate 
documents detailing the elements and their serialized form, HTML version 
and XHTML version, if you want to inter-mix model and serialization 
technique.

As for Section 8, that really is for user agent developers, only. 
Seriously, I doubt you expect typical web developers or designers to get 
much from this section. I would almost expect this to be a separate 
document. What would be helpful is to bring this section up one level in 
complexity, specifically focused at web developers/designers.

More later

Shelley

From ian at hixie.ch  Sat May  2 23:32:59 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 3 May 2009 06:32:59 +0000 (UTC)
Subject: [whatwg] accesskey=""
In-Reply-To: <492C8259.8040506@helsinki.fi>
References: <492C58A5.7090002@helsinki.fi> <492C7402.3010101@googlemail.com>
	<492C7945.2090604@helsinki.fi> <492C7EA6.3010108@googlemail.com>
	<492C8259.8040506@helsinki.fi>
Message-ID: <Pine.LNX.4.62.0905030155560.18851@hixie.dreamhostps.com>


After many years of pondering on the issue, I have checked in a definition 
of the accesskey="" attribute.

On Thu, 20 Sep 2007, Maciej Stachowiak wrote:
> 
> Keyboard shortcuts are useful for a number of reasons:
> 
> - They are important to usability of normal desktop applications. The 
> typical native application includes a number of keyboard shortcuts and 
> experienced users often make use of them in preference to the mouse or 
> tab cycling. For instance, many Mac OS X desktop applications feature 
> Cmd-Z as a keyboard shortcut for undo, and this is faster than picking 
> the command from a pull-down menu.
> 
> - Keyboard shortcuts can be an aid to accessibility for users who cannot 
> readily operate a pointing device such as a mouse, due to motor or 
> vision difficulties.
> 
> - Many mobile devices have a pointing device that is very awkward for 
> anyone to use.

These are good reasons to have a feature for keyboard shortcuts.


> HTML 4.01 has a feature for keyboard shortcuts, the accesskey="" 
> attribute. But it has many problems:
> 
> - It is tied to a specific control in the page. But in native 
> applications, many keyboard shortcuts do not have a direct one-to-one 
> correspondence with a specific control element. For example, you may 
> want a shortcut to focus an element that is also capable of activating, 
> or vice versa, but accesskey can't let you choose which to do. Or you 
> may want increment and decrement commands where the in-page UI is a 
> slider control.

I have allowed the <command> element to be given an access key, which 
allows any scriptable behaviour to be given a keyboard shortcut.


> - Keyboard shortcuts are not discoverable. It's not obvious looking at a 
> web application whether it even has keyboard shortcuts, let alone what 
> they are.

I have provided an API that returns a string representing the keyboard 
shortcut that a particular element has assigned to it, so that scripts can 
expose keyboard shortcuts without having to guess as to the platform 
conventions.

I have also added the right hooks for user agents to provide the feature 
that you propose (not quoted here) for putting the commands into the 
menubar of the application.


> - There are barriers to the UA making keyboard shortcuts discoverable. 
> Putting a marker on elements with an accesskey value at all times messes 
> with the appearance of the page as intended by the designer of the page. 
> Having a visual indicator that appears when the user depresses the 
> appropriate secret modifier key is only discoverable if the user knows 
> the secret modifier, which is unlikely to be the case.

This is now addressed by those aforementioned hooks, which basically make 
any activatable or focusable element with an accesskey="" attribute into a 
command that can be exposed in a menu.


> - There are barriers to the web app making keyboard shortcuts 
> discoverable. The web app does not know what modifier keys the UA will 
> add, if any, so it cannot display the true shortcut in the page or in 
> help materials.

The aforementioned DOM attribute now enables this.


> - The set of keys available for shortcuts is not the same across 
> different devices, operating systems and browsers, but the syntax for 
> accesskey requires choosing one. For example, 0-9 are the only keys that 
> could reasonably be available on a mobile phone with only a numeric 
> keypad. But in Safari on Mac OS X, 0-9 with the normal modifier key for 
> keyboard shortcuts are taken by the browser itself.

I have addressed this by making the accesskey="" attribute take a 
space-separated list of characters, and requiring the user agent to use 
the most useful one. For compatibility with legacy UAs, providing just one 
character is naturally still supported, but as user agents support the 
new feature, authors will be able to transition to providing more than 
one shortcut character.

For future extensibility, I have also required tokens with more than one 
character to be ignored for now. We can later add identifiers for various 
purposes, e.g. accesskey="help" to mean that the user agent's default 
"help" key should be used, whatever that is.


> - The UA may wish to present a list of available keyboard shortcuts to 
> the user in some sort of list, but there may not be a good label 
> available. All the UA can use is the label of the control, but a label 
> that's good in the context of the page may not be very good in an 
> out-of-context list. For example, <http://www.amazon.com/> has two 
> buttons labelled "Go" at the very top, one of which performs an Amazon 
> search and the other of which performs a Web search. I'm not sure either 
> of these buttons is a great choice for a keyboard shortcut, but if there 
> were a list giving their shortcuts you'd really want the labels in the 
> list to be "Search Amazon" and "Search the Web" respectively, not "Go".

This is resolved partially by allowing the author to put the accesskey="" 
attribute on the <command> element with a label="" instead of on the 
<button> element (maybe later linking them using the command="" attribute, 
though support for this in the spec is awaiting implementation experience 
with the command system as a whole). It is still possible for authors to 
use accesskey="" on elements without a label, but user agents are not 
required to actually assign a shortcut key if they think the label is not 
going to be useful enough for reuse in the menu.


> - The name of the new attribute is deliberately different than 
> "accesskey", since the semantics and allowed values are different. This 
> makes it possible in theory for a page to use both accesskey and 
> shortcutkey on the same element, if we end up allowing them on the same 
> elements; they could have some level of keyboard access in older UAs but 
> get the better new model in HTML5 UAs. I also think "shortcut key" is a 
> better name, since keyboard shortcuts exist for all users, not just for 
> accessibility purposes.

I think the ability to transition by just using one character until most 
browsers support more than one is quite adequate. It's not like this is a 
heavily used feature where it's imperative that the new multiple-key 
feature be available today.


On Thu, 20 Sep 2007, Asbj?rn Ulsberg wrote:
> 
> First I have to say that I really like the suggestion. What's missing, 
> though, is a way to bind a command to an actual action in the document. 
> Is this done via a "command" attribute, via scripting, or both?

I've also allowed any other command (e.g. <a>, <input type=button>, etc) 
to be used as a way to set accesskey, which address this. Long term I 
expect we'll allow biding of commands together using an attribute, too.


On Thu, 20 Sep 2007, Adam Roben wrote:
>
> It might be useful to add a DOM attribute to the <command> element that 
> would return the UA's textual representation of the resulting shortcut. 
> This would be useful, for example, if a web app wanted to provide a 
> documentation page that listed all of their shortcuts. The best name 
> I've been able to come up with so far is "computedShortcutKey".

I did this (and called it "accessKeyLabel" so that it would fall by 
"accessKey" in alphabetical lists).


On Fri, 21 Sep 2007, Maciej Stachowiak wrote:
> 
> As stated in my proposal, I don't think the same benefits can be 
> achieved using the accesskey attribute while maintaining compatibility. 
> Just to give an example, let's say I'm writing a web-based mail client 
> with a toolbar offering some common commands. The toolbar button to 
> compose a new message just says [Compose], because in context and with 
> the icon above that seems clear. But I'd like to have the label in a 
> menu listing the shortcut keys to say "Compose New Message", since it is 
> out of context. I'd like it to use some shortcut based on N in clients 
> with a full keyboard, and something based on 1 in clients with only a 
> numeric keypad available. Under my proposal, you'd do it like this:
> 
> <command id="compose" shortcutkey="n 1" label="Compose New Message"
> onclick="compose()">
> 
> <input type="button" value="Compose" onclick="compose()">
> 
> How do you suggest this could be done with accesskey? Note that using 
> space-separated values in accesskey will fail in current UAs, thus 
> removing any backward-compatibility benefits.

You would say just "n" for now, then, when the new feature is wildly 
deployed, you would change it to "n 1". Or alternatively, you would set 
"n" on the <input> element, and "n 1" on the <command>.


> I forgot to mention one other major problem with accesskey. HTML4 says 
> that the effect of activating an accesskey should be to focus the 
> element. But this is very rarely the desired action for a keyboard 
> shorcut. Almost always you want the shortcut to activate something or do 
> some script action. Although the spec seems confused on this point, 
> since it gives some examples of focus that sound more like activation.

I have made HTML5 say that accesskey triggers the command's Action, which 
varies from element to element but is roughly equivalent to clicking it.


On Fri, 25 Jan 2008, Jean-Nicolas Boulay Desjardins wrote:
>
> In the present standard you are alowd to use the same accesskey in to 
> different links... For example:
> 
> <a href="bob.html" accesskey="b">Bob web page</a>
> <a href="bob.html" accesskey="b">Bob web page</a>
> 
> But what would happend if this was to happend:
> 
> <a href="bob.html" accesskey="b">Bob web page</a>
> <a href="alex.html" accesskey="b">Alex web page</a>
> 
> Again this is allowed in the present web standard, but if you think 
> about it its illogical, on what bases thus the browser decide wich one 
> to access first or should it open the tow?

The spec now defines how this works, though it leaves up to the UA the 
decision as to which should get an access key assigned, or whether they 
should both get access keys assigned (but with different modifiers).


On Mon, 28 Jan 2008, Mikko Rantalainen wrote:
> 
> Perhaps the accesskey should be kept but its meaning should be 
> transformed a bit. Instead of being a key (letter) it should be a 
> keyword for a behavior. A good accesskey values could be "home", 
> "index", "search", "contact". The user then could bind the "home" 
> accesskey to any "home" button of his selection. It could be CTRL+H or 
> perhaps F11 instead. Some keyboards have additional "multimedia" keys 
> that could easily be used for such behavior.

I haven't specified this, but I _have_ left room for extending the spec in 
this direction in future, should we find that what we have so far still 
isn't enough.


On Tue, 25 Nov 2008, Olli Pettay wrote:
> 
> FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets.
> FF3 changed the behavior to require visible and focusable element.
> IE7 doesn't seem to activate, only focus (at least <a> elements), and
> because hidden element isn't really focusable, it doesn't seem to do anything
> with elements with display:none.

The spec says that accesskey="" only triggers the command if the element 
defines a command that is neither Disabled nor Hidden. Now display:none 
doesn't make a command Hidden (indeed, <command> is display:none by 
default), but accesskey="" itself only defines a command if the element is 
focusable and that only happens if the element is being rendered.

So, long story short, it's defined, but it's not a simple answer.


> A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588

Per spec, those <a> elements are both defining commands that are enabled 
and not hidden, so their access keys should work, and would cause the 
links to be followed.

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

From annevk at opera.com  Mon May  4 06:36:06 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 04 May 2009 15:36:06 +0200
Subject: [whatwg] rename CanvasPixelArray
In-Reply-To: <Pine.LNX.4.62.0904302309510.18851@hixie.dreamhostps.com>
References: <op.un7jxvp964w2qv@annevk-t60.oslo.opera.com>
	<4979FA2B.8070704@email.it>
	<Pine.LNX.4.62.0904302309510.18851@hixie.dreamhostps.com>
Message-ID: <op.uteqqgkl64w2qv@annevk-t60>

On Fri, 01 May 2009 01:10:19 +0200, Ian Hickson <ian at hixie.ch> wrote:
> I haven't renamed it. I don't think it's a big deal to introduce other
> interfaces that look the same but with different names, if we need to.

I agree that's not a problem, but the asymmetry between ImageData and CanvasPixelArray would be nice to avoid. (I'd be fine with renaming ImageData to CanvasData as well.)


-- 
Anne van Kesteren
http://annevankesteren.nl/

From annevk at opera.com  Mon May  4 06:38:10 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 04 May 2009 15:38:10 +0200
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
Message-ID: <op.uteqtwn164w2qv@annevk-t60>

On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson <ian at hixie.ch> wrote:
> As far as I can tell this doesn't require any changes to HTML5, since the
> same applies here as applies to a regular <img>, right?

Maybe you misunderstood, but the request was not about <img> referencing SVG, but passing an SVGSVGElement object directly to drawImage() and friends.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From oliver at apple.com  Mon May  4 07:21:17 2009
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 4 May 2009 07:21:17 -0700
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <op.uteqtwn164w2qv@annevk-t60>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
Message-ID: <C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>


On May 4, 2009, at 6:38 AM, Anne van Kesteren wrote:

> On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson <ian at hixie.ch> wrote:
>> As far as I can tell this doesn't require any changes to HTML5,  
>> since the
>> same applies here as applies to a regular <img>, right?
>
> Maybe you misunderstood, but the request was not about <img>  
> referencing SVG, but passing an SVGSVGElement object directly to  
> drawImage() and friends.
I had certainly misunderstood :D

I'm not sure this is a great idea, as like all other elements the size  
of an SVGSVGElement may be influenced by where it is in the DOM, which  
makes it unclear how drawImage(SVGSVGElement) should work, eg. should  
it use the "natural" size of the element, the size of the element  
according to its current location in the dom (and what happens if it's  
not in the dom?), or what?

I believe drawImage should be left as it currently is (basically  
taking objects that are intrinsically bitmap-ish), and if we were to  
add an ability to draw an svg element into the canvas it should really  
be an simple drawElement(Element) method instead, after all, why  
restrict it it just to SVG elements?

--Oliver

>
>
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/


From scampa.giovanni at gmail.com  Mon May  4 07:26:55 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Mon, 4 May 2009 16:26:55 +0200
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
Message-ID: <65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>

2009/5/4 Oliver Hunt <oliver at apple.com>:
>
> On May 4, 2009, at 6:38 AM, Anne van Kesteren wrote:
>
>> On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>> As far as I can tell this doesn't require any changes to HTML5, since the
>>> same applies here as applies to a regular <img>, right?
>>
>> Maybe you misunderstood, but the request was not about <img> referencing
>> SVG, but passing an SVGSVGElement object directly to drawImage() and
>> friends.
>
> I had certainly misunderstood :D
>
> I'm not sure this is a great idea, as like all other elements the size of an
> SVGSVGElement may be influenced by where it is in the DOM, which makes it
> unclear how drawImage(SVGSVGElement) should work, eg. should it use the
> "natural" size of the element, the size of the element according to its
> current location in the dom (and what happens if it's not in the dom?), or
> what?

If HTMLImgElement uses the natural size, then SVGSVGElement should as
well. The CSS properties set on <img> at its natural position in the
DOM don't matter, so it is not really an issue.

> I believe drawImage should be left as it currently is (basically taking
> objects that are intrinsically bitmap-ish), and if we were to add an ability
> to draw an svg element into the canvas it should really be an simple
> drawElement(Element) method instead, after all, why restrict it it just to
> SVG elements?

<svg> has an intrinsic size (like <video>,<img>, and
<embed>/<object>), the other have not.

> --Oliver
>

Giovanni

From chuck at jumis.com  Mon May  4 13:51:23 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Mon, 4 May 2009 13:51:23 -0700 (PDT)
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <mailman.1.1241463862.15225.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.1.1241463862.15225.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <2436.67.171.33.219.1241470283.squirrel@mx.visc.us>

Oliver writes:
>> I believe drawImage should be left as it currently is (basically taking
>> objects that are intrinsically bitmap-ish), and if we were to add an
>> ability
>> to draw an svg element into the canvas it should really be an simple
>> drawElement(Element) method instead, after all, why restrict it it just
>> to
>> SVG elements?

Giovanni writes:
> <svg> has an intrinsic size (like <video>,<img>, and
> <embed>/<object>), the other have not.

Adding onto Giovanni's statement:

SVG is a graphics format -- there are specifications as to how each
element should render (how it should look). HTML has no such
specifications.

While you can roll your own drawElement(Element), it will give you
unstable output. Drawing an SVG should give you stable output across all
browsers (supporting SVG).

It's possible that a CSS Box Element could be drawable, per standards. I
think that's something to be inherited from SVG-land, not an item for the
Canvas specs. I'm sure SVG will gradually borrow more from the CSS Level 3
model as it matures. Meanwhile, roll your own.

-Charles

From giecrilj at stegny.2a.pl  Mon May  4 13:51:18 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 4 May 2009 22:51:18 +0200
Subject: [whatwg] Section 3 semantics and structure
In-Reply-To: <49FC5B31.1050607@burningbird.net>
References: <49FC5B31.1050607@burningbird.net>
Message-ID: <841C6EC236DA41E2A2771243E42CC2DE@POCZTOWIEC>

HTML5 elements live in the DOM, and markup creates two (preferable) ways to
persist HTML5 documents and fragments.  But in principle you could persist
them as JSON equally well (probably making your site inaccessible to bots),
with a few framework exceptions just to bootstrap the browser.  It is quite
surprising at the first sight.
HTH,
Chris



From giecrilj at stegny.2a.pl  Mon May  4 14:03:00 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 4 May 2009 23:03:00 +0200
Subject: [whatwg] converting word (was  <code> attributes
In-Reply-To: <op.us80ryrch8on37@bruce-pc>
References: <C6209A08.11901%adrian.sutton@ephox.com>
	<op.us80ryrch8on37@bruce-pc>
Message-ID: <FDAEE8B065734159A72EFDCBDE2E2293@POCZTOWIEC>

Microsoft Word has an option to save as filtered HTML; the result is almost
clean and almost valid, with a few exceptions, but it still not good.
However, the Word-specific stuff is gone, so you can focus on real problems.
HTH,
Chris



From giecrilj at stegny.2a.pl  Mon May  4 14:14:48 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 4 May 2009 23:14:48 +0200
Subject: [whatwg] notes on current HTML5 draft
In-Reply-To: <49FC570B.9090508@burningbird.net>
References: <49FC570B.9090508@burningbird.net>
Message-ID: <9CDCE4450483425C96A11E9AB44B09CC@POCZTOWIEC>

One thing XHTML(2) does not provide is resilience to invalid code, which is
very important for sites featuring third-party content like advertisements,
or user-generated content like blogs.  Script-only add-ons like database
access and Web sockets in HTML5 are a big advantage for Web applications as
well.
I would not consider an exhaustive list of serialization issues in various
modes appropriate for the specification itself; this is covered in the FAQ
and it is a straightforward conclusion from the features and limitations of
the media involved (which are specified).
Best regards,
Chris



From fantasai.lists at inkedblade.net  Mon May  4 14:52:21 2009
From: fantasai.lists at inkedblade.net (fantasai)
Date: Mon, 04 May 2009 14:52:21 -0700
Subject: [whatwg] table 'frames' attribute
Message-ID: <49FF6395.7000100@inkedblade.net>

Section 10.2.6, i.e. The XHTML syntax: Rendering: Punctuation and decoration
contains some style rules for handling the [rules] and [frames] attributes
of the <table> element. I haven't reviewed it all in detail but this part

   table[frames=void] > tr > td, table[frames=void] > tr > th,
   table[frames=above] > tr > td, table[frames=above] > tr > th,
   table[frames=below] > tr > td, table[frames=below] > tr > th,
   ...
   table[frames=border] > tfoot > tr > td, table[frames=border] > tfoot > tr > th {
     border-style: solid;
   }

is certainly wrong both per spec (HTML4) and implementation. It should be
removed. Also, you probably want to track Mozilla bug 43178 for this section
   https://bugzilla.mozilla.org/show_bug.cgi?id=43178
since we are actually planning to implement these attributes with CSS rules
unless we hit performance problems with that approach.

There's a collection of tests for these attributes here:
   http://fantasai.inkedblade.net/markup/tests/table-frame-rules/
I should probably expand it to include tests for the empty string and junk
valuse, but that's what it is for now.

~fantasai


From annevk at opera.com  Mon May  4 15:03:09 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 05 May 2009 00:03:09 +0200
Subject: [whatwg] table 'frames' attribute
In-Reply-To: <49FF6395.7000100@inkedblade.net>
References: <49FF6395.7000100@inkedblade.net>
Message-ID: <op.utfd7j1t64w2qv@anne-van-kesterens-macbook.local>

On Mon, 04 May 2009 23:52:21 +0200, fantasai  
<fantasai.lists at inkedblade.net> wrote:
> [...]

Regardless of whether the effect of the rules is wrong, the name of the  
attribute is frame, not frames, as far as I can tell.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From ian at hixie.ch  Mon May  4 15:05:18 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 4 May 2009 22:05:18 +0000 (UTC)
Subject: [whatwg] table 'frames' attribute
In-Reply-To: <49FF6395.7000100@inkedblade.net>
References: <49FF6395.7000100@inkedblade.net>
Message-ID: <Pine.LNX.4.62.0905042204450.7824@hixie.dreamhostps.com>

On Mon, 4 May 2009, fantasai wrote:
>
> Section 10.2.6, i.e. The XHTML syntax: Rendering: Punctuation and decoration
> contains some style rules for handling the [rules] and [frames] attributes
> of the <table> element. I haven't reviewed it all in detail but this part
> 
>   table[frames=void] > tr > td, table[frames=void] > tr > th,
>   table[frames=above] > tr > td, table[frames=above] > tr > th,
>   table[frames=below] > tr > td, table[frames=below] > tr > th,
>   ...
>   table[frames=border] > tfoot > tr > td, table[frames=border] > tfoot > tr >
> th {
>     border-style: solid;
>   }
> 
> is certainly wrong both per spec (HTML4) and implementation. It should be
> removed.

Could you elaborate on how it is wrong?

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

From ddailey at zoominternet.net  Mon May  4 15:16:50 2009
From: ddailey at zoominternet.net (ddailey)
Date: Mon, 4 May 2009 18:16:50 -0400
Subject: [whatwg] SVG extensions to <canvas>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com><Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
Message-ID: <73FE5A31637844918BED8FA46A68E03D@disxgdg31szkx7>

> On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson <ian at hixie.ch> wrote:
>> As far as I can tell this doesn't require any changes to HTML5, since the
>> same applies here as applies to a regular <img>, right?

Anne van Kesteren replied:
> Maybe you misunderstood, but the request was not about <img> referencing 
> SVG, but passing an SVGSVGElement object directly to drawImage() and 
> friends.

Maybe I misunderstood (or, more precisely, I am about to state my probable 
misunderstanding):

Does this mean for example, that the author could take a chunk of <svg> code 
or its equivalent and pass it to canvas.drawImage() (and friends) and then 
have a raster version in JavaScript of the <svg> ? If so, then would that 
not allow, client-side, things like interrogating pixel values at point 
(x,y) within an SVG? That's something I'd like to see. I understand that if 
done improperly this can yield security problems across domains, but it 
seems in this case we're only talking one domain.

David 


From annevk at opera.com  Mon May  4 15:39:38 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 05 May 2009 00:39:38 +0200
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <73FE5A31637844918BED8FA46A68E03D@disxgdg31szkx7>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<73FE5A31637844918BED8FA46A68E03D@disxgdg31szkx7>
Message-ID: <op.utffwcgc64w2qv@anne-van-kesterens-macbook.local>

On Tue, 05 May 2009 00:16:50 +0200, ddailey <ddailey at zoominternet.net>  
wrote:
> Maybe I misunderstood (or, more precisely, I am about to state my  
> probable misunderstanding):
>
> Does this mean for example, that the author could take a chunk of <svg>  
> code or its equivalent and pass it to canvas.drawImage() (and friends)  
> and then have a raster version in JavaScript of the <svg> ? If so, then  
> would that not allow, client-side, things like interrogating pixel  
> values at point (x,y) within an SVG? That's something I'd like to see. I  
> understand that if done improperly this can yield security problems  
> across domains, but it seems in this case we're only talking one domain.

The SVG fragment could still contain a cross-origin reference of some  
sorts so it does not help with that. It does allow you to create some SVG  
and draw it on a <canvas> without having to first create a data URL or  
some such out of it.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From robert at ocallahan.org  Mon May  4 16:44:32 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 4 May 2009 16:44:32 -0700
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
	<65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
Message-ID: <11e306600905041644g68e0e4gb1f91a153e3475fb@mail.gmail.com>

On Mon, May 4, 2009 at 7:26 AM, Giovanni Campagna <scampa.giovanni at gmail.com
> wrote:

> <svg> has an intrinsic size (like <video>,<img>, and
> <embed>/<object>), the other have not.
>

<video> and <img> usually have intrinsic sizes, but
<embed>/<object>/<iframe> usually don't. <svg> often does and often does
not.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090504/24061c45/attachment-0001.htm>

From fantasai.lists at inkedblade.net  Mon May  4 18:09:09 2009
From: fantasai.lists at inkedblade.net (fantasai)
Date: Mon, 04 May 2009 18:09:09 -0700
Subject: [whatwg] table 'frames' attribute
In-Reply-To: <Pine.LNX.4.62.0905042204450.7824@hixie.dreamhostps.com>
References: <49FF6395.7000100@inkedblade.net>
	<Pine.LNX.4.62.0905042204450.7824@hixie.dreamhostps.com>
Message-ID: <49FF91B5.6000209@inkedblade.net>

Ian Hickson wrote:
> On Mon, 4 May 2009, fantasai wrote:
>> Section 10.2.6, i.e. The XHTML syntax: Rendering: Punctuation and decoration
>> contains some style rules for handling the [rules] and [frames] attributes
>> of the <table> element. I haven't reviewed it all in detail but this part
>>
>>   table[frames=void] > tr > td, table[frames=void] > tr > th,
>>   table[frames=above] > tr > td, table[frames=above] > tr > th,
>>   table[frames=below] > tr > td, table[frames=below] > tr > th,
>>   ...
>>   table[frames=border] > tfoot > tr > td, table[frames=border] > tfoot > tr >
>> th {
>>     border-style: solid;
>>   }
>>
>> is certainly wrong both per spec (HTML4) and implementation. It should be
>> removed.
> 
> Could you elaborate on how it is wrong?

Yeah, sure.

http://www.w3.org/TR/html40/struct/tables.html#h-11.3.1

"This attribute specifies which sides of the frame surrounding a table
will be visible."

It's not supposed to create any internal borders, just affect the borders
of the <table> itself. By contrast the 'border' attribute does create
internal borders, but you can see that called out specifically later in
that section.

~fantasai

From ian at hixie.ch  Mon May  4 20:01:51 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 May 2009 03:01:51 +0000 (UTC)
Subject: [whatwg] Getting data out of poorly written Web pages
Message-ID: <Pine.LNX.4.62.0905050012120.18851@hixie.dreamhostps.com>


One of the use cases I collected from the e-mails sent in over the past 
few months was the following:

   USE CASE: Getting data out of poorly written Web pages, so that the user
   can find more information about the page's contents.

   SCENARIOS:
     * Alfred merges data from various sources in a static manner, generating
       a new set of data. Bob later uses this static data in conjunction with
       other data sets to generate yet another set of static data. Julie then
       visits Bob's page later, and wants to know where and when the various
       sources of data Bob used come from, so that she can evaluate its
       quality. (In this instance, Alfred and Bob are assumed to be
       uncooperative, since creating a static mashup would be an example of a
       poorly-written page.)
     * TV guide listings - If the TV guide provider does not render a link to
       IMDB, the browser should recognise TV shows and give implicit links.
       (In this instance, it is assumed that the TV guide provider is
       uncooperative, since it isn't providing the links the user wants.)
     * Students and teachers should be able to discover each other -- both
       within an institution and across institutions -- via their blogging.
       (In this instance, it is assumed that the teachers and students aren't
       cooperative, since they would otherwise be able to find each other by
       listing their blogs in a common directory.)
     * Tim wants to make a knowledge base seeded from statements made in
       Spanish and English, e.g. from people writing down their thoughts
       about George W. Bush and George H.W. Bush. (In this instance, it is
       assumed that the people writing the statements aren't cooperative,
       since if they were they could just add the data straight into the
       knowledge base.)

   REQUIREMENTS:
     * Does not need cooperation of the author (if the page author was
       cooperative, the page would be well-written).
     * Shouldn't require the consumer to write XSLT or server-side code to
       derive this information from the page.


One class of the solutions that was proposed to address this is the idea 
of getting the author to mark up microdata (small bits of data) in the 
page, annotating the information that is needed to complete the scenarios. 
Such formats could be RDFa, Microformats, n3, a custom format for HTML5, 
or any number of other syntaxes. However, it's not clear that this would 
help in this case, since the underlying assumption with these particular 
problems is that the author isn't actively cooperating with the user 
(likely due to ignorance, of course, not malice).

Let's examine these use cases with a microdata solution in mind:

     * Alfred merges data from various sources in a static manner, generating
       a new set of data. Bob later uses this static data in conjunction with
       other data sets to generate yet another set of static data. Julie then
       visits Bob's page later, and wants to know where and when the various
       sources of data Bob used come from, so that she can evaluate its
       quality.

Here, Julie is two steps removed from the original data. Since we are 
assuming here that Alfred and Bob are not cooperating with Julie, we must 
also assume that they haven't included this information on the page. If 
they haven't included it, then microdata doesn't help, as there is nothing 
to mark up.


     * TV guide listings - If the TV guide provider does not render a link to
       IMDB, the browser should recognise TV shows and give implicit links.
       (In this instance, it is assumed that the TV guide provider is
       uncooperative, since it isn't providing the links the user wants.)

If the TV guide listing page was cooperative, it would just provide the 
links to the IMDB that the user wants. It isn't; we cannot, therefore, 
assume that it would be ready to include microdata that would let the user 
find the relevant page on the IMDB using a tool that consumes Microdata.


     * Students and teachers should be able to discover each other -- both
       within an institution and across institutions -- via their blogging.

The obvious solution here is for the students and teachers to simply 
register their blogs in a common directory. However, assuming that they 
are not even doing that, it is unlikely that they _would_ include some 
kind of microdata in their pages to solve the problem.


     * Tim wants to make a knowledge base seeded from statements made in
       Spanish and English, e.g. from people writing down their thoughts
       about George W. Bush and George H.W. Bush.

If the people writing down their thoughts were to be "hip" enough to write 
their thoughts using microdata annotations, they'd also be able to just 
add them to the knowledge base directly. So again, we must assume that 
this is a case where we can't rely on microdata.


Thus, we have our first requirement:

     * Does not need cooperation of the author.

If we take the author out of the equation, there are three other parties 
that could help solve this problem:

 1. The user.

 2. The user's client tool provider (e.g. browser vendor).

 3. Third party tool providers (e.g. web sites, search engines).

Relying on the user to solve these problems is somewhat missing the point 
of solving the problems, so let's focus on the browser and on other tools.


The other requirement listed above, from someone who presumably wishes to 
avoid the user having to do any extra work, is:

     * Shouldn't require the consumer to write XSLT or server-side code to
       derive this information from the page.

This is worth bearing in mind as we look at how browsers and other tools 
might help solve the problem.


First let's look at the scenarios again, from the perspective of the 
client software:

     * Alfred merges data from various sources in a static manner, generating
       a new set of data. Bob later uses this static data in conjunction with
       other data sets to generate yet another set of static data. Julie then
       visits Bob's page later, and wants to know where and when the various
       sources of data Bob used come from, so that she can evaluate its
       quality.

>From the browser's point of view, Julie is viewing a Web page with some 
data, say, some HTML <table>s, and requests the browser's help in 
identifying the source of the data.

It's not clear to me that the browser could do _anything_ at this point 
that would solve the problem. Without help from the page, finding the 
origin of data is a search problem, and the browser doesn't really have 
anywhere to begin from.


     * TV guide listings - If the TV guide provider does not render a link to
       IMDB, the browser should recognise TV shows and give implicit links.

>From the browser's point of view, the user is visiting a page with various 
bits of text on it.

There has been some work in the area of having browsers give implicit 
links, but that has historically not been successful at all:

   http://en.wikipedia.org/wiki/Smart_tag_(Microsoft)

However, as that Wikipedia page points out, what _has_ been moderately 
successful (so far) is the idea of having the browser offer links when the 
user selects some text. Thus, if the user is an IMDB user, he could select 
the TV show title, and select "IMDB" from the resulting menu.

This solution does solve the problem without XSLT or server-side consumer 
code. Thus, this appears to be a solution to this particular scenario.


     * Students and teachers should be able to discover each other -- both
       within an institution and across institutions -- via their blogging.

Form the browser's point of view, the user is browsing one page, and 
desires other pages that are similar in a particular way. Again, this is 
fundamentally a search problem, so it's not clear that there's anything 
that could be done to address it from the browser.


     * Tim wants to make a knowledge base seeded from statements made in
       Spanish and English, e.g. from people writing down their thoughts
       about George W. Bush and George H.W. Bush.

Here the client is not a browser, but some other tool, whose job it is to 
populate a knowledge base from statements in Spanish and English. Almost 
by definition then, it seems like this tool should, as part of its 
operation, be able to convert English and Spanish into the knowledge 
base's format. Such tools currently are not widely available to the 
general public. That's probably ok, though, since to be honest, the 
general public is unlikely to make direct use of knowledge bases at this 
point anyway.

Whether this requires some code from the user (as opposed to being 
automatic) depends on the software, but software that can interpret such 
statements (i.e. AI or NLP software) would presumably do so without help 
from the user.

Unfortunately, such solutions are somewhat hypothetical at this point. 
Thus client software is a possible solution, but not a great one.


Let's look at the scenarios again from the point of view of a third-party 
software provider, e.g. a search engine:

     * Alfred merges data from various sources in a static manner, generating
       a new set of data. Bob later uses this static data in conjunction with
       other data sets to generate yet another set of static data. Julie then
       visits Bob's page later, and wants to know where and when the various
       sources of data Bob used come from, so that she can evaluate its
       quality.

This is a problem that can be solved by a provider with a large amount of 
data. For prose, e.g. to search for the original source of a quote or 
syndicated blog post, this problem is in fact mostly solved -- search for 
a representative string from the document, and use your search engine's 
features to focus on the document that first used that phrase. This is a 
harder problem for numbers, though, and is even harder if the mashup 
doesn't include the original data.


     * TV guide listings - If the TV guide provider does not render a link to
       IMDB, the browser should recognise TV shows and give implicit links.

A search engine can be used to search for the show, which will then 
provide links that the user wants relating to that show. This solution has 
the advantage of already being part of a user's daily routine.


     * Students and teachers should be able to discover each other -- both
       within an institution and across institutions -- via their blogging.

Search engines are in a unique position to find pages similar to each 
other, and indeed many search engines have had a "similar pages" feature 
for some time. It seems plausible that tools could be developed that 
specifically search for blogs that appear to be from students or teachers, 
if there is a demand for this.


     * Tim wants to make a knowledge base seeded from statements made in
       Spanish and English, e.g. from people writing down their thoughts
       about George W. Bush and George H.W. Bush.

Third party tools do not seem useful for solving this problem (except 
insofar as they could be used to augment the solution described for this 
problem earlier with client-side tools).



In conclusion:

Some of these scenarios are easy to solve with existing technology. Others 
will require advances in natural language processing or other large-corpus 
technologies. None, it seems, of this particular set of use cases are 
particularly well addressed by microdata markup.

For finding information about a page, such as what data an analysis is 
based on, or finding other pages from people with similar interests, when 
the page author isn't really interested in participating in a system that 
would aid this, tools such as search engines seem like the most promising 
solution. These solutions are still immature, though, and much work in 
this area is to be expected going forward.

For using information on a page, such as a TV Show's title, to navigate to 
other sites, such as IMDB, the browser's own UI is probably the best 
starting point. Features such as IE8's Accelerators and Mac OS X's "Search 
in Google" address this use case adequately and in an extensible and 
simple fashion that the user can tune to his or her preferences.

Finally, turning text in multiple languages into machine-processable data 
is a problem that will likely be the continued target of focused research 
both in corporate R&D and in academia, and efforts like Wolfram Alpha 
indicate that this is in fact an area with growing interest.


Thus, I haven't added anything to HTML5 to address the above use cases.

A number of further use cases remain to be examined. I will send further 
e-mail hopefully this week as I address them.

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

From jonas at sicking.cc  Mon May  4 21:46:20 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 4 May 2009 21:46:20 -0700
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com> 
	<E470702C-DB5F-44C5-8CCD-81AA988FCB29@apple.com>
	<c2e346f90904062111t7429143ande88c37c654b7bb9@mail.gmail.com> 
	<2A9F6E32-1680-47E9-98B8-C7DCA6B484B1@apple.com>
	<Pine.LNX.4.62.0904300024400.10370@hixie.dreamhostps.com> 
	<2c0e02830904291828v34f4060frc11b0d761e543cea@mail.gmail.com> 
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com> 
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com> 
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
Message-ID: <63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>

On Thu, Apr 30, 2009 at 6:42 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> On Fri, May 1, 2009 at 2:25 AM, David Singer <singer at apple.com> wrote:
>> At 23:15 ?+1000 30/04/09, Silvia Pfeiffer wrote:
>>>
>>> ?> On Thu, 30 Apr 2009, Silvia Pfeiffer wrote:
>>>>>
>>>>> ?> On Wed, 8 Apr 2009, Silvia Pfeiffer wrote:
>>>>> ?>>
>>>>> ?>> Note that in the Media Fragment working group even the specification
>>>>> ?>> of http://www.example.com/t.mov#time="10s-20s" may mean that only
>>>>> the
>>>>> ?>> requested 10s clip is delivered, especially if all the involved
>>>>> ?>> instances in the exchange understand media fragment URIs.
>>>>> ?>
>>>>> ?> That doesn't seem possible since fragments aren't sent to the server.
>>>>>
>>>>> ?The current WD of the Media Fragments WG
>>>>> ?http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/
>>>>> ?specifies that a URL that looks like this
>>>>> ?http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21
>>>>> ?is to be resolved on the server through the following basic process:
>>>>>
>>>>> ?1. UA chops off the fragment and turns it into a HTTP GET request with
>>>>> ?a newly introduced time range header
>>>>> ?e.g.
>>>>> ?GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
>>>>> ?Host: www.w3.org
>>>>> ?Accept: video/*
>>>>> ?Range: seconds=12-21
>>>>>
>>>>> ?2. The server slices the multimedia resource by mapping the seconds to
>>>>> ?bytes and extracting a playable resource (potentially fixing container
>>>>> ?headers). The server will then reply with the closest inclusive range
>>>>> ?in a 206 HTTP response:
>>>>> ?e.g.
>>>>> ?HTTP/1.1 206 Partial Content
>>>>> ?Accept-Ranges: bytes, seconds
>>>>> ?Content-Length: 3571437
>>>>> ?Content-Type: video/mp4
>>>>> ?Content-Range: seconds 11.85-21.16
>>>>
>>>> ?That seems quite reasonable, assuming the UA is allowed to seek to other
>>>> ?parts of the video also.
>>>>
>>>>
>>>>> ?> On Thu, 9 Apr 2009, Jonas Sicking wrote:
>>>>> ?>>
>>>>> ?>> If we look at how fragment identifiers work in web pages today, a
>>>>> ?>> link such as
>>>>> ?>>
>>>>> ?>> http://example.com/page.html#target
>>>>> ?>>
>>>>> ?>> this displays the 'target' part of the page, but lets the user
>>>>> scroll
>>>>> ?>> to anywhere in the resource. This feels to me like it maps fairly
>>>>> ?>> well to
>>>>> ?>>
>>>>> ?>> http://example.com/video.ogg#t=5s
>>>>> ?>>
>>>>> ?>> displaying the selected frame, but displaying a timeline for the
>>>>> full
>>>>> ?>> video and allowing the user to directly go to any position.
>>>>> ?>
>>>>> ?> Agreed. This is how the spec works now.
>>>>>
>>>>> ?This is also how we did it with Ogg and temporal URIs, but this is not
>>>>> ?the way in which the standard for media fragment URIs will work.
>>>>
>>>> ?It sounds like it is. I don't understand the difference.
>>>
>>> Because media fragment URIs will not deliver the full resource like a
>>> HTML page does, but will instead only provide the segment that is
>>> specified with the temporal region.
>>> http://example.com/video.ogg#t=5s ?only retrieves the video from 5s to
>>> the end, not from start to end.
>>>
>>> So you cannot scroll to the beginning of the video without another
>>> retrieval action:
>>
>> which is fine. ?I don't see the problem; ?given a fragment we
>> a) focus the user's attention on that fragment
>> b) attempt to optimize network traffic to display that fragment as quickly
>> as possible
>>
>> Neither of these stop
>> c) the user from casting his attention elsewhere
>> d) more network transactions being done to support this
>
>
> re c):
> It depends on how the UA displays it. If the UA displays the 5s offset
> as the beginning of the video, then the user cannot easily jump to 0s
> offset. I thought this was the whole purpose of the discussion:
> whether we should encourage UAs to display just the addressed segment
> in the timeline (which makes sense for a 5sec extract from a 2 hour
> video) or whether we encourage UAs to display the timeline of the full
> resource only. I only tried to clarify the differences for the UA and
> what the user gets, supporting an earlier suggestion that UAs may want
> to have a means for switching between full timeline and segment
> timeline display. Ultimately, it's a UA problem and not a HTML5
> problem.

I think there are two use cases:

1. Wanting to start the user at a particular point in a video, while
still showing the user that the full video is there. For example in a
political speech you may want to start off at a particularly
interesting part, while still allowing the viewer to "rewind" to any
part of the speech in order to gain more context if so desired.
This is very similar to how web pages work today if you include a
fragment identifier. The UI accounts for the full page, but the page
is scrolled to a particular part.

2. Wanting to only show a small part of a longer video. For example in
the video containing a movie, it would be possible to link to a
particular scene, with a given start and end time.


The danger of only doing 2, even if it's possible somehow for the user
to switch to make the UI display the full range of the movie, is that
unless the UI is extremely obvious, most users are not going to see
it.

Or to put it another way. I think there is a use case for both linking
to a specific point in a video file, as well to point to a range in
it. Probably even a combination of the two where you point to a point
inside a range.

/ Jonas

From giecrilj at stegny.2a.pl  Mon May  4 23:39:28 2009
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Tue, 5 May 2009 08:39:28 +0200
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<E470702C-DB5F-44C5-8CCD-81AA988FCB29@apple.com><c2e346f90904062111t7429143ande88c37c654b7bb9@mail.gmail.com>
	<2A9F6E32-1680-47E9-98B8-C7DCA6B484B1@apple.com><Pine.LNX.4.62.0904300024400.10370@hixie.dreamhostps.com>
	<2c0e02830904291828v34f4060frc11b0d761e543cea@mail.gmail.com>
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com>
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52><2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
Message-ID: <689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>

If the author wants to show only a sample of a resource and not the full
resource, I think she does it on purpose.  It is not clear why it is vital
for the viewer to have an _obvious_ way to view the whole resource instead;
if it were the case, the author would provide for this.
IMHO,
Chris



From scampa.giovanni at gmail.com  Tue May  5 04:35:47 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Tue, 5 May 2009 13:35:47 +0200
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <11e306600905041644g68e0e4gb1f91a153e3475fb@mail.gmail.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
	<65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
	<11e306600905041644g68e0e4gb1f91a153e3475fb@mail.gmail.com>
Message-ID: <65307430905050435x5d16050akab3f14d9251797cf@mail.gmail.com>

2009/5/5 Robert O'Callahan <robert at ocallahan.org>:
> On Mon, May 4, 2009 at 7:26 AM, Giovanni Campagna
> <scampa.giovanni at gmail.com> wrote:
>>
>> <svg> has an intrinsic size (like <video>,<img>, and
>> <embed>/<object>), the other have not.
>
> <video> and <img> usually have intrinsic sizes, but
> <embed>/<object>/<iframe> usually don't. <svg> often does and often does
> not.

What is embed used for? Flash and videos. Both have intrinsic sizes
What is object used for? Videos, Java applets and Silverlight. They
all have intrinsic sizes.
Basically, for what concerns rendering (the element being "replaced"
in the CSS meaning of term), <img>,<embed>,<object>,<svg> have
intrinsic sizes (they may be rescaled, but this is ortogonal)

Note that I didn't include <iframe> in this list, because it could be
rendered as if the child document contents were inside the parent
document, within the <iframe> (auto height given by elements content);
or it could be rendered as a window, with intrinsic sizes given by
width/height.

> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Giovanni

From robert at ocallahan.org  Tue May  5 09:27:33 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 5 May 2009 09:27:33 -0700
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <65307430905050435x5d16050akab3f14d9251797cf@mail.gmail.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
	<65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
	<11e306600905041644g68e0e4gb1f91a153e3475fb@mail.gmail.com>
	<65307430905050435x5d16050akab3f14d9251797cf@mail.gmail.com>
Message-ID: <11e306600905050927i56392978j3af21e5d14bf4cad@mail.gmail.com>

On Tue, May 5, 2009 at 4:35 AM, Giovanni Campagna <scampa.giovanni at gmail.com
> wrote:

> What is embed used for? Flash and videos. Both have intrinsic sizes
> What is object used for? Videos, Java applets and Silverlight. They
> all have intrinsic sizes.


In principal, maybe they do, but typically those sizes are not exposed to
the browser and are not used in layout.

Basically, for what concerns rendering (the element being "replaced"
> in the CSS meaning of term), <img>,<embed>,<object>,<svg> have
> intrinsic sizes (they may be rescaled, but this is ortogonal)
>

SVG images often don't have an intrinsic size. What's the intrinsic size of
this image?
<svg xmlns="http://www.w3.org/2000/svg">
  <linearGradient id="g" x1="0" y1="0" x2="1" y2="0">
    <stop stop-color="red" offset="0"/><stop stop-color="lime" offset="1"/>
  </linearGradient>
  <rect x="0%" y="0%" width="100%" height="100%" fill="url(#g)"/>
</svg>

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090505/b75fdb19/attachment.htm>

From joaoe at opera.com  Tue May  5 09:31:13 2009
From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=)
Date: Tue, 05 May 2009 18:31:13 +0200
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <11e306600905050927i56392978j3af21e5d14bf4cad@mail.gmail.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
	<65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
	<11e306600905041644g68e0e4gb1f91a153e3475fb@mail.gmail.com>
	<65307430905050435x5d16050akab3f14d9251797cf@mail.gmail.com>
	<11e306600905050927i56392978j3af21e5d14bf4cad@mail.gmail.com>
Message-ID: <op.utgtibaa2q99of@id-c0981>


> SVG images often don't have an intrinsic size. What's the intrinsic size of
> this image?
> <svg xmlns="http://www.w3.org/2000/svg">
>   <linearGradient id="g" x1="0" y1="0" x2="1" y2="0">
>     <stop stop-color="red" offset="0"/><stop stop-color="lime" offset="1"/>
>   </linearGradient>
>   <rect x="0%" y="0%" width="100%" height="100%" fill="url(#g)"/>
> </svg>
>
> Rob

This is the same as <table><tr><td><textarea></textarea></td></tr></table>
where the Ua shrink wraps the table but the textarea inherit the parents width. This would cause a 0 width table, but currentl user agents rely on other attributes to get the intrinsic dimensions, like rows and cols for the table. In the SVG case, the UA could use default dimensions, like 300 per 300

-- 

Jo?o Eiras
Core Developer, Opera Software ASA, http://www.opera.com/

From msporny at digitalbazaar.com  Tue May  5 20:09:40 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue, 05 May 2009 23:09:40 -0400
Subject: [whatwg] "Just create a Microformat for it" - thoughts on
	micro-data topic
Message-ID: <4A00FF74.4010702@digitalbazaar.com>

bcc: Public RDFa Task Force mailing list (but not speaking as a member)

Kyle Weems recent post[1] on CSSquirrel discusses[2] some of the more
recent rumblings surrounding RDFa and Microformats as potential
micro-data solutions. It specifically addresses a conversation between
Ian and Tantek regarding Microformats:

http://krijnhoetmer.nl/irc-logs/whatwg/20090430#l-693

Since I've seen this argument made numerous times now, and because it
seems like a valid solution to someone that isn't familiar with the
Microformats process, I'm addressing it here. The argument goes
something like this:

"It looks like that markup problem X can be solved with a simple
Microformat."

This seems like a reasonable answer at first - Microformats, at their
core, are simple tag-based mechanisms for data markup. Most semantic
representation problems can be solved by explicitly tagging content.

What most people fail to see, however, is that this statement
trivializes the actual implementation cost of the solution. A
Microformat is much more than a simple tag-based mechanism and it is far
more difficult to create one than most people realize. Creating a
Microformat is a very time consuming prospect, including:

  1. Attempting to apply current Microformats to solve your problem.
  2. Gathering examples to show how the content is represented in the
     wild.
  3. Gathering common data formats that encode the sort of content
     you are attempting to express.
  4. Analyzing the data formats and the content.
  5. Deriving common vocabulary terms.
  6. Proposing a draft Microformat and arguing the relevance of each
     term in the vocabulary.
  7. Sorting out parsing rules for the Microformat.
  8. Repeating steps 1-7 until the community is happy.
  9. Testing the Microformat in the wild, getting feedback, writing
     code to support your specific Microformat.
  10. Draft stage - if you didn't give up by this point.

I say this as the primary editor of the hAudio Microformat - it is a
grueling process, certainly not for those without thick skin and a
strong determination to complete even simple vocabularies. Each one of
those steps can take weeks or months to complete.

I'm certainly not knocking the output of the Microformats community -
the documents that come out of the community have usually been vetted
quite thoroughly. However, to hear somebody propose Microformats as a
quick or easy solution makes me cringe every time I hear it.

The hAudio Microformat initiative started over 2 years ago and it's
still going, still not done. So, while it is true that someone may want
to put themselves through the headache of creating a Microformat to
solve a particular markup problem, it is unlikely. One must only look at
our track record - output for the Microformats community is at roughly
10 new vocabularies[3] (not counting rel-vocabularies and vocabularies
not based directly on a previous data format).

Compare that with the roughly 120-150 registered[3], active RDF
vocabularies[4] via prefix.cc. Now certainly, quantity != quality,
however, it does demonstrate that there is something that is causing
more people to generate RDF vocabularies than Microformats vocabularies.

Note that this argument doesn't apply to class-attribute-based semantic
markup, but one should not make the mistake that it is easy to create a
Microformat.

-- manu

[1] http://www.cssquirrel.com/comic/?comic=16
[2] http://www.cssquirrel.com/2009/05/04/comic-update-html5-manners/
[3] http://microformats.org/wiki/Main_Page#Specifications
[4] http://prefix.cc/popular/all

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From msporny at digitalbazaar.com  Tue May  5 20:32:18 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue, 05 May 2009 23:32:18 -0400
Subject: [whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
Message-ID: <4A0104C2.8080009@digitalbazaar.com>

bcc: Public RDFa Task Force mailing list (but not speaking as a member)

Thinking out loud...

It seems as though there is potential here, based on the recent IRC
conversations about the topic[1] and the use cases[2] posted by Ian,
that WHATWG's use cases/requirements, and therefore solution, could
diverge from both the Microformats community as well as the RDFa
community use cases/requirements/solution.

There should be a requirement, as Microformats and XHTML1.1+RDFa have
required, that a potential solution to this issue should be compatible
with both the Microformats and RDFa approaches. This would mean, at a
high-level:

- Not creating ambiguous cases for parser writers.
- Not triggering output in a Microformats/RDFa parser as a side-effect
  of WHATWG micro-data markup.
- Not creating an environment where WHATWG micro-data markup breaks or
  eliminates Microformats/RDFa markup.

I think these are implied since HTML5 has gone to great lengths to
provide backward compatibility. However, since I'm not clear on the
details of how this community operates, I thought it better to be
explicit about the requirement.

-- manu

[1]http://krijnhoetmer.nl/irc-logs/whatwg/20090430#l-693
[2]http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019374.html

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From ian at hixie.ch  Tue May  5 21:00:19 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 May 2009 04:00:19 +0000 (UTC)
Subject: [whatwg] "Just create a Microformat for it" - thoughts on
 micro-data topic
In-Reply-To: <4A00FF74.4010702@digitalbazaar.com>
References: <4A00FF74.4010702@digitalbazaar.com>
Message-ID: <Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>

On Tue, 5 May 2009, Manu Sporny wrote:
>
> Creating a Microformat is a very time consuming prospect, including:
> 
>   1. Attempting to apply current Microformats to solve your problem.
>   2. Gathering examples to show how the content is represented in the
>      wild.
>   3. Gathering common data formats that encode the sort of content
>      you are attempting to express.
>   4. Analyzing the data formats and the content.
>   5. Deriving common vocabulary terms.
>   6. Proposing a draft Microformat and arguing the relevance of each
>      term in the vocabulary.
>   7. Sorting out parsing rules for the Microformat.
>   8. Repeating steps 1-7 until the community is happy.
>   9. Testing the Microformat in the wild, getting feedback, writing
>      code to support your specific Microformat.
>   10. Draft stage - if you didn't give up by this point.
> 
> [...] RDF [...]

Are you saying that RDF vocabularies can be created _without_ this due 
diligence?

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

From ben at adida.net  Tue May  5 21:04:07 2009
From: ben at adida.net (Ben Adida)
Date: Tue, 05 May 2009 21:04:07 -0700
Subject: [whatwg] "Just create a Microformat for it" - thoughts on
 micro-data topic
In-Reply-To: <Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>
References: <4A00FF74.4010702@digitalbazaar.com>
	<Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>
Message-ID: <4A010C37.4070708@adida.net>

Ian Hickson wrote:
> Are you saying that RDF vocabularies can be created _without_ this due 
> diligence?

Who decides what the right due diligence is? One organization for *all*
topics, ever?

An RDF vocabulary can be created by the proper community, i.e. a music
vocabulary by music experts, a copyright vocabulary by copyright
experts, a biomedical vocabulary by biomedical experts, rather than
assuming that one central group should be the centralized bottleneck for
all development.

In other words, RDF vocabularies function like the web does:
decentralized, let the best sites/vocabs win.

-Ben

From ian at hixie.ch  Tue May  5 21:32:36 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 May 2009 04:32:36 +0000 (UTC)
Subject: [whatwg] Micro-data/Microformats/RDFa Interoperability
	Requirement
In-Reply-To: <4A0104C2.8080009@digitalbazaar.com>
References: <4A0104C2.8080009@digitalbazaar.com>
Message-ID: <Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>

On Tue, 5 May 2009, Manu Sporny wrote:
> 
> There should be a requirement, as Microformats and XHTML1.1+RDFa have 
> required, that a potential solution to this issue should be compatible 
> with both the Microformats and RDFa approaches. This would mean, at a 
> high-level:
> 
> - Not creating ambiguous cases for parser writers.

Noted, thanks.


> - Not triggering output in a Microformats/RDFa parser as a side-effect
>   of WHATWG micro-data markup.
> - Not creating an environment where WHATWG micro-data markup breaks or
>   eliminates Microformats/RDFa markup.

This isn't possible. Even a regular HTML5 document with no microdata 
annotations that links in a style sheet ends up triggering output in 
Microformats and RDFa parsers -- Microformats because any use of 'class' 
can clash with a Microformats class name, and RDFa because any use of the 
"rel" attribute can do the same.

So I'm not sure really how to handle such a requirement.

It's also not clear to me what RDFa's position in text/html is. As I 
understand it, RDFa only applies to XHTML. Thus it seems that HTML5 has 
already broken compatibility with RDFa, since it requires processors to 
handle text/html content in a non-XML manner.

Similarly, the rules for handling CURIEs in RDFa, especially in rel="", 
are already incompatible with HTML4 and HTML5 rules. For example, the way 
that "n:next" and "next" can end up being equivalent in RDFa processors 
despite being different per HTML rules (assuming an "n" namespace is 
appropriately declared).

I don't think there's much that can be done about this (this isn't 
something that we can change HTML5 rules for; browser vendors would not 
accept having to resolve QNames in rel="" attributes as part of 
processing, for one).


> I think these are implied since HTML5 has gone to great lengths to
> provide backward compatibility.

Backwards compatibility in HTML5 is primarily concerned with being 
compatible with legacy markup, of which there is very little when it comes 
to either RDFa or Microformats (especially RDFa, since there's so little 
XHTML content for it to be found in).

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

From ian at hixie.ch  Tue May  5 22:54:06 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 May 2009 05:54:06 +0000 (UTC)
Subject: [whatwg] "Just create a Microformat for it" - thoughts on
 micro-data topic
In-Reply-To: <4A010C37.4070708@adida.net>
References: <4A00FF74.4010702@digitalbazaar.com>
	<Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>
	<4A010C37.4070708@adida.net>
Message-ID: <Pine.LNX.4.62.0905060432590.7824@hixie.dreamhostps.com>

On Tue, 5 May 2009, Ben Adida wrote:
> Ian Hickson wrote:
> > Are you saying that RDF vocabularies can be created _without_ this due 
> > diligence?
> 
> Who decides what the right due diligence is?

The person writing the vocabulary, presumably.


> One organization for *all* topics, ever?

I don't think that would really scale. Even for major languages, like 
HTML, we haven't found a single organisation to be a successful model.


Manu's list didn't mention anything about a single organisation:

On Tue, 5 May 2009, Manu Sporny wrote:
>
> Creating a Microformat is a very time consuming prospect, including:
> 
>   1. Attempting to apply current Microformats to solve your problem.
>   2. Gathering examples to show how the content is represented in the
>      wild.
>   3. Gathering common data formats that encode the sort of content
>      you are attempting to express.
>   4. Analyzing the data formats and the content.
>   5. Deriving common vocabulary terms.
>   6. Proposing a draft Microformat and arguing the relevance of each
>      term in the vocabulary.
>   7. Sorting out parsing rules for the Microformat.
>   8. Repeating steps 1-7 until the community is happy.
>   9. Testing the Microformat in the wild, getting feedback, writing
>      code to support your specific Microformat.
>   10. Draft stage - if you didn't give up by this point.

Surely all of the above apply equally to any RDFa vocabulary just as it 
would to _any_ vocabularly, regardless of the underlying syntax?

Consider each of these in turn:

1: You have to make sure you're not reinventing the wheel, whatever 
language or vocabulary you are designing.

2: You have to make sure whatever language or vocabulary you are designing 
is something that your users can use.

3: If you do have to invent a new language or vocabulary, it makes sense 
to base it on the base of knowledge humanity has collected on the subject.

4: You have to study the information collected in steps 2 and 3 to make 
sense of it.

5: Deriving vocabulary names is a key part of any language design effort.

6: Justifying your design is a key part of any language design effort 
also. Not doing this would lead to a language or vocabulary with 
unnecessary parts, making it harder to use.

7: With any language, part of designing the vocabulary is defining how to 
process content that uses it.

8: Defining any language or vocabulary effectively must, clearly, involve 
a feedback loop with community review.

9: The most important practical test of a language is the test of 
deployment. Getting feedback and writing code is naturally part of writing 
a format.

10: You have to specify the language.

As far as I can tell, the steps above are just the steps one would take 
for designing any format, language, or vocabulary. Are you saying that 
creating an RDF vocabulary _doesn't_ involve these steps? How is an RDF 
vocabulary defined if not using these steps?

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

From scampa.giovanni at gmail.com  Wed May  6 04:53:35 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Wed, 6 May 2009 13:53:35 +0200
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <11e306600905050927i56392978j3af21e5d14bf4cad@mail.gmail.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
	<65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
	<11e306600905041644g68e0e4gb1f91a153e3475fb@mail.gmail.com>
	<65307430905050435x5d16050akab3f14d9251797cf@mail.gmail.com>
	<11e306600905050927i56392978j3af21e5d14bf4cad@mail.gmail.com>
Message-ID: <65307430905060453v73303d15o9cb33f2dc3aee8b@mail.gmail.com>

2009/5/5 Robert O'Callahan <robert at ocallahan.org>:
> On Tue, May 5, 2009 at 4:35 AM, Giovanni Campagna
> <scampa.giovanni at gmail.com> wrote:
>>
>> What is embed used for? Flash and videos. Both have intrinsic sizes
>> What is object used for? Videos, Java applets and Silverlight. They
>> all have intrinsic sizes.
>
> In principal, maybe they do, but typically those sizes are not exposed to
> the browser and are not used in layout.

This is an implementation problem (and likely a bug: if a don't
specify width/height for video I should get the intrinsic size, not a
default)

>> Basically, for what concerns rendering (the element being "replaced"
>> in the CSS meaning of term), <img>,<embed>,<object>,<svg> have
>> intrinsic sizes (they may be rescaled, but this is ortogonal)
>
> SVG images often don't have an intrinsic size. What's the intrinsic size of
> this image?
> <svg xmlns="http://www.w3.org/2000/svg">
> ? <linearGradient id="g" x1="0" y1="0" x2="1" y2="0">
> ??? <stop stop-color="red" offset="0"/><stop stop-color="lime" offset="1"/>
> ? </linearGradient>
> ? <rect x="0%" y="0%" width="100%" height="100%" fill="url(#g)"/>
> </svg>

That <svg> hasn't got intrinsic sizes, so it cannot be rendered on a
canvas. This doesn't preclude the use of <svg> with intrinsic sizes,
that are given only by width/height attributes on <svg>.

> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Giovanni

From jonbarnett at gmail.com  Wed May  6 06:07:57 2009
From: jonbarnett at gmail.com (Jon Barnett)
Date: Wed, 6 May 2009 08:07:57 -0500
Subject: [whatwg] Timers
Message-ID: <bde87dd20905060607w72709886k72cfce573a723df9@mail.gmail.com>

Do setTimeout and setInterval belong in HTML 5?  They're not really DOM
related.  They're supported by ActionScript, which doesn't have a DOM. AS
supports the same signatures that HTML 5 does (plus another one).  HTML 5
already says they're specific to Javascript/ECMAScript, so there's no need
for other DOM implementations to support them.

I searched the ES5 final draft and didn't see a reference to them anywhere.
Have they been considered for ECMAScript 5 or any version?

I didn't find any discussion in the WHATWG archives.

http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary646.html

-- 
Jon Barnett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090506/9f2d40f5/attachment-0001.htm>

From msporny at digitalbazaar.com  Wed May  6 08:22:57 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed, 06 May 2009 11:22:57 -0400
Subject: [whatwg] "Just create a Microformat for it" - thoughts on
 micro-data topic
In-Reply-To: <Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>
References: <4A00FF74.4010702@digitalbazaar.com>
	<Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>
Message-ID: <4A01AB51.3010705@digitalbazaar.com>

Ian Hickson wrote:
> On Tue, 5 May 2009, Manu Sporny wrote:
>> Creating a Microformat is a very time consuming prospect, including:
>>
>> ... Microformats Due Diligence Rules ...
> 
> Are you saying that RDF vocabularies can be created _without_ this due 
> diligence?

What I am saying is that the amount of due diligence that goes into a
particular vocabulary should be determined by the community that will
use the vocabulary.

Some of these will be large communities and will require an enormous
amount of due diligence, others will be very small communities, which
may not require as much due diligence as larger communities, or they may
have a completely different process to the Microformats process. The key
here is that a micro-data approach should allow them to have the
flexibility to create vocabularies in a distributed manner.

Ian Hickson wrote:
> On Tue, 5 May 2009, Ben Adida wrote:
>>> Ian Hickson wrote:
>>>>> Are you saying that RDF vocabularies can be created _without_ this
>>>>> due diligence?
>>>
>>> Who decides what the right due diligence is?
>
>The person writing the vocabulary, presumably.

Your stance is a bit more lax than mine on this. I'd say that it is the
community, not solely the vocabulary author, that determines the right
amount of due diligence. If the community does not see the proper amount
of due diligence going into vocabulary creation, or the vocabulary does
not solve their problem, then they should be free to develop a competing
alternative.

This is especially true because the proper amount of due diligence can
easily become a philosophical argument - each community can have a
perfectly rational argument to do things differently when solving the
same problem.

Your position, that the vocabulary author decides the proper amount of
due diligence, is rejected in the Microformats community. In the
Microformats community, every vocabulary has the same amount of due
diligence applied to it.

I think that this is a good thing for that particular community, but it
does have a number of downsides - scalability being one of them. It
creates a bottleneck - we can only get so many vocabularies through our
centralized, community-based process and the barrier to creating a
vocabulary is very high. As a result, we don't support small community
vocabularies and only support widely established publishing behavior
(contact information, events, audio, recipes, etc).

So, maybe this requirement should be added to the micro-data
requirements list:

If micro-data is going to succeed, it needs to support a mechanism that
provides easy, distributed vocabulary development, publishing and re-use.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/

From msporny at digitalbazaar.com  Wed May  6 08:58:54 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed, 06 May 2009 11:58:54 -0400
Subject: [whatwg] "Just create a Microformat for it" - thoughts on
 micro-data topic
In-Reply-To: <Pine.LNX.4.62.0905060432590.7824@hixie.dreamhostps.com>
References: <4A00FF74.4010702@digitalbazaar.com>	<Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>	<4A010C37.4070708@adida.net>
	<Pine.LNX.4.62.0905060432590.7824@hixie.dreamhostps.com>
Message-ID: <4A01B3BE.6090801@digitalbazaar.com>

Ian Hickson wrote:
>> One organization for *all* topics, ever?
> 
> I don't think that would really scale. Even for major languages, like 
> HTML, we haven't found a single organisation to be a successful model.

Then you, Ben, and I agree on this particular point:

In order for semantic/micro-data markup to scale well, we must ensure
that distributed vocabulary development, publishing and re-use is a
cornerstone of the solution.

> Manu's list didn't mention anything about a single organisation

Then I wasn't clear enough - I meant that the single organization was
the Microformats community and that the list works for that particular
community, but is not guaranteed to work for all communities.

You could say that the "single community" could be the W3C or WHATWG -
pushing vocabulary standardization solely through any one of these
organizations would be the wrong solution, therefore we should be
cognizant of that in this micro-data discussion.

> Surely all of the above apply equally to any RDFa vocabulary just as it 
> would to _any_ vocabularly, regardless of the underlying syntax?

Not necessarily...

> 6: Justifying your design is a key part of any language design effort 
> also. Not doing this would lead to a language or vocabulary with 
> unnecessary parts, making it harder to use.

What happens when the people you're justifying your design to are the
gatekeepers? What happens when they don't understand the problem you're
attempting to solve? Or they disagree with you on a philosophical level?
Or they have some sort of political reason to not allow your vocabulary
to see the light of day (think large multi-national vs. little guy)? In
the Microformats community, this stage, especially if one of the
Microformat founders disagrees with your stance, can kill a vocabulary.

> 7: With any language, part of designing the vocabulary is defining how to 
> process content that uses it.

Not if there are clear parsing rules and it's easy to separate the
vocabulary from the parsing rules. This should be a requirement for the
micro-data solution:

Separation of concerns between the markup used to express the micro-data
(the HTML markup) and the vocabularies used to express the semantics
(the micro-data vocabularies).

> 9: The most important practical test of a language is the test of 
> deployment. Getting feedback and writing code is naturally part of writing 
> a format.

This statement is vague, so I'm elaborating a bit to cover the possible
readings of this statement:

Writing markup code (ie: HTML) should be a natural part of writing a
semantic vocabulary meant to be embedded in HTML.

Writing parser code (ie: Python, Perl, Ruby, C, etc.) should not be a
natural part of writing a semantic vocabulary - they wholly different
disciplines. Microformats require you to write both markup code and
parser code by design.

> As far as I can tell, the steps above are just the steps one would take 
> for designing any format, language, or vocabulary. Are you saying that 
> creating an RDF vocabulary _doesn't_ involve these steps? How is an RDF 
> vocabulary defined if not using these steps?

I don't believe that Ben is saying that at all - those steps are best
practices and apply generally to most communities. However, they do not
work for all communities and they do not work well when they are
transformed from best practices to a requirement that all vocabularies
must meet in order to be published.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/

From jbanes at gmail.com  Wed May  6 09:03:19 2009
From: jbanes at gmail.com (Jerason Banes)
Date: Wed, 6 May 2009 11:03:19 -0500
Subject: [whatwg] Timers
In-Reply-To: <bde87dd20905060607w72709886k72cfce573a723df9@mail.gmail.com>
References: <bde87dd20905060607w72709886k72cfce573a723df9@mail.gmail.com>
Message-ID: <82c3f5040905060903q4e9eb647k3efdea3e978c54fd@mail.gmail.com>

SetTimeout and setInterval are from the original Javascript specification,
pre-ECMA. That specification is not officially standardized anywhere, but it
is supported by all web browsers and most implementations of the Javascript
language. (Including ActionScript.)
The pre-ECMA specs are often known as the "DOM-0" APIs. Since they have
never been standardized before, it makes sense for HTML5 to finally spec the
non-deprecated APIs in an attempt to provide a consistent environment across
browsers. Especially when recent events have proven that there are companies
who like to implement the letter of the standard, but not the spirit.

You can read the earlier specs here:

http://docs.sun.com/source/816-6408-10/

Here's the spec for setTimeout and setInterval:

http://docs.sun.com/source/816-6408-10/window.htm#1203758
http://docs.sun.com/source/816-6408-10/window.htm#1203669

Hope that helps!

Thanks,
Jerason Banes
(Interested Observer of WHATWG Activities)


On Wed, May 6, 2009 at 8:07 AM, Jon Barnett <jonbarnett at gmail.com> wrote:

> Do setTimeout and setInterval belong in HTML 5?  They're not really DOM
> related.  They're supported by ActionScript, which doesn't have a DOM. AS
> supports the same signatures that HTML 5 does (plus another one).  HTML 5
> already says they're specific to Javascript/ECMAScript, so there's no need
> for other DOM implementations to support them.
>
> I searched the ES5 final draft and didn't see a reference to them
> anywhere.  Have they been considered for ECMAScript 5 or any version?
>
> I didn't find any discussion in the WHATWG archives.
>
>
> http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary646.html
>
> --
> Jon Barnett
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090506/d73f65a3/attachment.htm>

From whatwg at adambarth.com  Wed May  6 09:31:50 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Wed, 6 May 2009 09:31:50 -0700
Subject: [whatwg] innerStaticHTML
Message-ID: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>

Rob and I were discussing the use case for IE8's toStaticHTML API and
thought it might make sense to standardize a more robust and
future-proof API for the same use case.

USE CASE

I receive an untrusted string, for example a weather report or a
Twitter status update, from postMessage or a cross-origin
XMLHttpRequest, and I want to display its content to the user without
getting XSSed.

WORKAROUNDS

If the content is purely text (e.g., no images, styles, or
hyperlinks), then I can create a text node containing the string and
insert it into my page's DOM.  If the content is not purely text, I
need to implement an XSS filter in JavaScript (which folks commonly
screw up).

PROPOSAL

In addition to innerHTML, DOM elements should expose an
innerStaticHTML property.  When set, innerStaticHTML should behave the
same as innerHTML except that scripts should not execute (even in
event handlers) and plug-ins should not be created.

EXAMPLE

<script>
fetchMostRecentTweetFor("whatwg", function (tweet) {
  document.getElementById("whatwg_tweet).innerStaticHTML = tweet;
});
</script>

WHY NOT toStaticHTML?

toStaticHTML addresses the same use cause by translating an untrusted
string to another string that lacks active HTML content.  This API has
two issues:

1) The untrusted string -> static string -> HTML parser workflow
requires the browser to parse the string twice, introducing a
performance penalty and a security issue if the two parsing aren't
identical.

2) The API is difficult to future-proof because future versions of
HTML are likely to add new tags with active content (e.g., like the
<video> tag's event handlers).  Either we'll have to commit to a
toStaticHTML algorithm that will be secure in all future versions of
HTML, or we'll have to change the input-output behavior of
toStaticHTML in future versions of HTML.

innerStaticHTML addresses the same use case without these issues.

Adam

From joaoe at opera.com  Wed May  6 09:40:47 2009
From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=)
Date: Wed, 06 May 2009 18:40:47 +0200
Subject: [whatwg] innerStaticHTML
In-Reply-To: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
Message-ID: <op.utiol9s92q99of@id-c0981>


> PROPOSAL
>
> In addition to innerHTML, DOM elements should expose an
> innerStaticHTML property.  When set, innerStaticHTML should behave the
> same as innerHTML except that scripts should not execute (even in
> event handlers) and plug-ins should not be created.
>

As part of a browser implementation team I can clearly say that the cases where scripts should, or should not run are very hard to implement in a cross browser compatible way. Marking those scripts or plugins are non-executable would make everything much more complex and bug prone. Also, it would be impossible to do that for a onevent attribute without all sorts of problems.
The suggestion of marking content as non-executable doesn't solve anything, because after setting innerStaticHTML another script might serialize a piece of the affected DOM to string and back to a tree, and the code could then execute, which would not be wanted.

The only viable solution, from my point of view, would be for the UA to parse the string, and remove all untrusted content from the result tree before appending to the document.
That would mean removing all onevent attributes, all scripts elements, all plugins, etc. Basically, letting the UA implement all the filtering.



-- 

Jo?o Eiras
Core Developer, Opera Software ASA, http://www.opera.com/

From excors+whatwg at gmail.com  Wed May  6 09:56:40 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 6 May 2009 17:56:40 +0100
Subject: [whatwg] innerStaticHTML
In-Reply-To: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
Message-ID: <ea09c0d10905060956u3b86d83aj82efbc3b1289f085@mail.gmail.com>

On Wed, May 6, 2009 at 5:31 PM, Adam Barth <whatwg at adambarth.com> wrote:
> USE CASE
>
> I receive an untrusted string, for example a weather report or a
> Twitter status update, from postMessage or a cross-origin
> XMLHttpRequest, and I want to display its content to the user without
> getting XSSed.
>
> WORKAROUNDS
>
> If the content is purely text (e.g., no images, styles, or
> hyperlinks), then I can create a text node containing the string and
> insert it into my page's DOM. ?If the content is not purely text, I
> need to implement an XSS filter in JavaScript (which folks commonly
> screw up).

Could <iframe sandbox> work as a workaround?

    var iframe = document.createElement('iframe');
    iframe.sandbox = ''; // (um, I hope this is right? I'm guessing
any non-null/undefined value enables sandboxing, or something)
    iframe.seamless = true;
    iframe.src = 'data:text/html,'+encodeURIComponent(tweet);
    document.getElementById('whatwg_tweet').appendChild(iframe);

-- 
Philip Taylor
excors at gmail.com

From ian at hixie.ch  Wed May  6 11:40:40 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 May 2009 18:40:40 +0000 (UTC)
Subject: [whatwg] Timers
In-Reply-To: <bde87dd20905060607w72709886k72cfce573a723df9@mail.gmail.com>
References: <bde87dd20905060607w72709886k72cfce573a723df9@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0905061838571.7824@hixie.dreamhostps.com>

On Wed, 6 May 2009, Jon Barnett wrote:
>
> Do setTimeout and setInterval belong in HTML 5?  They're not really DOM 
> related.  They're supported by ActionScript, which doesn't have a DOM. 
> AS supports the same signatures that HTML 5 does (plus another one).  
> HTML 5 already says they're specific to Javascript/ECMAScript, so 
> there's no need for other DOM implementations to support them.

If anyone would like to volunteer to write the spec to define setTimeout() 
outside of HTML5, I'd be happy to remove the section as soon as such a 
spec is on a standard track somewhere. The section had been waiting for an 
editor for a year or more until last week where I finally gave up waiting 
and just wrote the spec myself. Since it's only a few paragraphs I didn't 
bother going through the overhead of separating it out into its own doc.

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

From oliver at apple.com  Wed May  6 13:16:50 2009
From: oliver at apple.com (Oliver Hunt)
Date: Wed, 6 May 2009 13:16:50 -0700
Subject: [whatwg] SVG extensions to <canvas>
In-Reply-To: <65307430905060453v73303d15o9cb33f2dc3aee8b@mail.gmail.com>
References: <op.t0rob7p764w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0904301914210.18851@hixie.dreamhostps.com>
	<op.uteqtwn164w2qv@annevk-t60>
	<C347A5C5-31A5-4E56-988F-31F61B601F65@apple.com>
	<65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
	<11e306600905041644g68e0e4gb1f91a153e3475fb@mail.gmail.com>
	<65307430905050435x5d16050akab3f14d9251797cf@mail.gmail.com>
	<11e306600905050927i56392978j3af21e5d14bf4cad@mail.gmail.com>
	<65307430905060453v73303d15o9cb33f2dc3aee8b@mail.gmail.com>
Message-ID: <5B2BF325-619E-45F0-95D9-FCCF947C39C8@apple.com>

>> SVG images often don't have an intrinsic size. What's the intrinsic  
>> size of
>> this image?
>> <svg xmlns="http://www.w3.org/2000/svg">
>>   <linearGradient id="g" x1="0" y1="0" x2="1" y2="0">
>>     <stop stop-color="red" offset="0"/><stop stop-color="lime"  
>> offset="1"/>
>>   </linearGradient>
>>   <rect x="0%" y="0%" width="100%" height="100%" fill="url(#g)"/>
>> </svg>
>
> That <svg> hasn't got intrinsic sizes, so it cannot be rendered on a
> canvas. This doesn't preclude the use of <svg> with intrinsic sizes,
> that are given only by width/height attributes on <svg>.

That's really really bad, as that means sometimes drawing you svg will  
work, and sometimes it won't.  That's why it's a bad API.

--Oliver

From ian at hixie.ch  Wed May  6 13:26:28 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 May 2009 20:26:28 +0000 (UTC)
Subject: [whatwg] "Just create a Microformat for it" - thoughts on
 micro-data topic
In-Reply-To: <4A01B3BE.6090801@digitalbazaar.com>
References: <4A00FF74.4010702@digitalbazaar.com>
	<Pine.LNX.4.62.0905060358250.7824@hixie.dreamhostps.com>
	<4A010C37.4070708@adida.net>
	<Pine.LNX.4.62.0905060432590.7824@hixie.dreamhostps.com>
	<4A01B3BE.6090801@digitalbazaar.com>
Message-ID: <Pine.LNX.4.62.0905061906310.7824@hixie.dreamhostps.com>

On Wed, 6 May 2009, Manu Sporny wrote:
> 
> What I am saying is that the amount of due diligence that goes into a 
> particular vocabulary should be determined by the community that will 
> use the vocabulary.

This seems clear, yes, but surely any community wishing to create a 
vocabulary would want to go through the steps you outlined.


> Your position, that the vocabulary author decides the proper amount of 
> due diligence, is rejected in the Microformats community. In the 
> Microformats community, every vocabulary has the same amount of due 
> diligence applied to it.

In the Microformats community, the community is the author.


> So, maybe this requirement should be added to the micro-data 
> requirements list:
> 
> If micro-data is going to succeed, it needs to support a mechanism that 
> provides easy, distributed vocabulary development, publishing and 
> re-use.

Noted as:

     * Creating a custom vocabulary should be relatively easy.
     * Distributed vocabulary development should be possible; it
       should not require coordination through a centralised system.
     * It should be possible to publish and re-use custom
       vocabularies.


> > Surely all of the above apply equally to any RDFa vocabulary just as 
> > it would to _any_ vocabularly, regardless of the underlying syntax?
> 
> Not necessarily...

I am dismayed that anyone would consider developing a language or 
vocabulary without following the steps you outlined. They seem to me to be 
a fundamental cornerstone of any development process.


> > 6: Justifying your design is a key part of any language design effort 
> > also. Not doing this would lead to a language or vocabulary with 
> > unnecessary parts, making it harder to use.
> 
> What happens when the people you're justifying your design to are the
> gatekeepers?

The people to which you should justify your design are your users. They 
are the only real gatekeepers.


> In the Microformats community, this stage, especially if one of the 
> Microformat founders disagrees with your stance, can kill a vocabulary.

It can kill getting "Microformats.org" branding on your vocabulary, just 
like if Tim disagrees with something it can kill W3C branding on your 
language. Why does that matter? Just define your vocabulary elsewhere. 
Microformats just use the "class" attribute, there's no reason that can't 
be done outside Microformats.org (indeed it happens every day as people 
make up random class names for their style sheets).

HTML5 is a poster child for this (W3C said no, so we did it elsewhere). 


> > 7: With any language, part of designing the vocabulary is defining how 
> > to process content that uses it.
> 
> Not if there are clear parsing rules and it's easy to separate the
> vocabulary from the parsing rules.

So XML and RDF vocabulary designers don't have to define schemas?

Parsing rules are a tiny fraction of what you have to define as part of a 
language. Just look at the size of XML vocabulary definitions like SVG or 
XHTML2 or XForms or MathML.


> This should be a requirement for the micro-data solution:
> 
> Separation of concerns between the markup used to express the micro-data 
> (the HTML markup) and the vocabularies used to express the semantics 
> (the micro-data vocabularies).

Noted (Microdata solutions shouldn't change HTML parsing rules).

However, I don't think that's really relevant to point 7 here. Whatever 
mechanism we end up with, it'll be important to define the semantics of 
vocabularies. For example, if something is a "person", it can have a 
"gender", and it can have a "foot", but the "foot" can't have a "gender". 
Vocabularies also need to define how to handle errors (like when someone 
says a foot is female).


> > 9: The most important practical test of a language is the test of 
> > deployment. Getting feedback and writing code is naturally part of 
> > writing a format.
> 
> This statement is vague, so I'm elaborating a bit to cover the possible 
> readings of this statement:
> 
> Writing markup code (ie: HTML) should be a natural part of writing a 
> semantic vocabulary meant to be embedded in HTML.
> 
> Writing parser code (ie: Python, Perl, Ruby, C, etc.) should not be a 
> natural part of writing a semantic vocabulary - they wholly different 
> disciplines. Microformats require you to write both markup code and 
> parser code by design.

A vocabulary that is never processed by anyone is not a useful vocabulary. 
So someone eventually is going to have to process the vocabulary, if it's 
useful. The only sure way to know if processing a vocabulary is possible 
in a sane way is to try to do so, and that means writing code.

Now this code might be just a bunch of queries against an RDF quad store, 
or it could be some complicated C++ app that does something awesome. But 
without writing _something_, you can't really know for sure if the 
language or vocabulary is sane.

You really want to know if your vocabulary is sane long before people 
start investing money in using it, otherwise you'll have wasted their time 
when it turns out that it's not possible to make good use of the data due 
to some fundamental flaw in the vocabulary.

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

From robert at ocallahan.org  Wed May  6 14:01:29 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 6 May 2009 14:01:29 -0700
Subject: [whatwg] innerStaticHTML
In-Reply-To: <op.utiol9s92q99of@id-c0981>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
	<op.utiol9s92q99of@id-c0981>
Message-ID: <11e306600905061401h75125642jca0154f0f46f4dd7@mail.gmail.com>

On Wed, May 6, 2009 at 9:40 AM, Jo?o Eiras <joaoe at opera.com> wrote:

> As part of a browser implementation team I can clearly say that the cases
> where scripts should, or should not run are very hard to implement in a
> cross browser compatible way. Marking those scripts or plugins are
> non-executable would make everything much more complex and bug prone. Also,
> it would be impossible to do that for a onevent attribute without all sorts
> of problems.
> The suggestion of marking content as non-executable doesn't solve anything,
> because after setting innerStaticHTML another script might serialize a piece
> of the affected DOM to string and back to a tree, and the code could then
> execute, which would not be wanted.
>
> The only viable solution, from my point of view, would be for the UA to
> parse the string, and remove all untrusted content from the result tree
> before appending to the document.
> That would mean removing all onevent attributes, all scripts elements, all
> plugins, etc. Basically, letting the UA implement all the filtering.
>

I think that's actually what Adam is proposing. At least, it's what I had in
mind when we discussed it.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090506/c56ed9ca/attachment.htm>

From robert at ocallahan.org  Wed May  6 14:04:42 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 6 May 2009 14:04:42 -0700
Subject: [whatwg] innerStaticHTML
In-Reply-To: <ea09c0d10905060956u3b86d83aj82efbc3b1289f085@mail.gmail.com>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
	<ea09c0d10905060956u3b86d83aj82efbc3b1289f085@mail.gmail.com>
Message-ID: <11e306600905061404q31350b61ha93742c88dc14a9e@mail.gmail.com>

On Wed, May 6, 2009 at 9:56 AM, Philip Taylor
<excors+whatwg at gmail.com<excors%2Bwhatwg at gmail.com>
> wrote:

> Could <iframe sandbox> work as a workaround?
>
>    var iframe = document.createElement('iframe');
>    iframe.sandbox = ''; // (um, I hope this is right? I'm guessing
> any non-null/undefined value enables sandboxing, or something)
>    iframe.seamless = true;
>    iframe.src = 'data:text/html,'+encodeURIComponent(tweet);
>    document.getElementById('whatwg_tweet').appendChild(iframe);
>

Seamless sandboxed IFRAMEs are probably harder to implement, probably
heavier-weight, and won't work in all situations, such as if you want to get
safe inline content or want to safely manipulate the content before
displaying it.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090506/b2d8ff88/attachment.htm>

From ian at hixie.ch  Wed May  6 16:07:38 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 May 2009 23:07:38 +0000 (UTC)
Subject: [whatwg] Allowing authors to keep track of where content originates
Message-ID: <Pine.LNX.4.62.0905062209510.18851@hixie.dreamhostps.com>


One of the use cases I collected from the e-mails sent in over the past 
few months was the following:

   USE CASE: Allow authors to keep track of where content originates.

   SCENARIOS:
     * A blog, say htmlfive.net, copies content wholesale from another, say
       blog.whatwg.org (as permitted and encouraged by the license). The
       author of the original content would like the reader of the reproduced
       content to know the provenance of the content. The reader would like
       to find the original blog post so he can leave comments for the
       original author.
     * Chaals could improve the Opera intranet if he had a mechanism for
       identifying the original source of various parts of a page, as that
       would let him contact the original author quickly to report problems
       or request changes.

   REQUIREMENTS:
     * Parsing rules should be unambiguous.
     * Should not require changes to HTML5 parsing rules.


The two scenarios are subtly different, so I'm going to handle them 
separately.

First, the blog syndication scenario:

     * A blog, say htmlfive.net, copies content wholesale from another, say
       blog.whatwg.org (as permitted and encouraged by the license). The
       author of the original content would like the reader of the reproduced
       content to know the provenance of the content. The reader would like
       to find the original blog post so he can leave comments for the
       original author.

This case is relatively easy: the original author need but ask for the 
editor of the syndicating site to include a link to the original content. 
If the editor isn't willing to do this, then there's nothing at the HTML 
language level that we can do to force him. In practice, with htmlfive.net 
syndicating blog.whatwg.org content, the editor of the former happily 
agreed to include a link to the original blog, and does so. The current 
setup doesn't link to the original article, but the titles aren't changed, 
so an author can relatively easily find the original content.

Similarly, "Planet"-style syndicators include links to the original 
entries, so this is already possible.

The odds of syndicators including these links can be improved a little by 
putting the link explicitly in the post markup in the feed, since 
typically syndicators just display the feeds verbatim.

This doesn't require any new parsing at all, so the requirements are met 
too.



Next, the mashup page:

     * Chaals could improve the Opera intranet if he had a mechanism for
       identifying the original source of various parts of a page, as that
       would let him contact the original author quickly to report problems
       or request changes.

Since this is an intranet, I again assume that we can rely on the authors 
and editors to cooperate.

HTML4 had a solution to this, the cite="" attribute on <blockquote> or 
<q>. Within a controlled environment, this can be used quite well, as Mark 
showed in late 2002. However, using <blockquote> for mashups is a bit 
weird, and not really in the spirit of the <blockquote> tag (though 
probably in the letter, admittedly). So I've added cite="" to the 
<section> and <article> elements, so that mashup authors can more easily 
keep track of where the sections come from.

The requirements collected as part of this effort for these scenarios are:

     * Parsing rules should be unambiguous.

The parsing rules here are the same as for <blockquote cite="">, which is 
very well-defined at this point.

     * Should not require changes to HTML5 parsing rules.

This doesn't affect any of the parsing rules.


In conclusion, this use case can be addressed with a combination of 
discussion with editors, including explicit links using <a href="">, and 
using the new cite="" attribute on <section> and <article>.


A number of further use cases remain to be examined. I will send further 
e-mail hopefully this week as I address them.

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

From giecrilj at stegny.2a.pl  Thu May  7 03:24:47 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Thu, 7 May 2009 12:24:47 +0200
Subject: [whatwg] innerStaticHTML
In-Reply-To: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
Message-ID: <C4121745AF44419EB9E7D92CA81A3F90@POCZTOWIEC>

If toStaticHTML prunes everything it is not sure of, the danger of a known
language construct suddenly introducing active content is negligible.  I am
sure HTML5 specification editors bear that aspect in mind and so shall they
in the future.
Chris



From philipj at opera.com  Thu May  7 04:22:17 2009
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Thu, 07 May 2009 13:22:17 +0200
Subject: [whatwg] media resource selection algorithm typo
Message-ID: <op.utj4jftyatwj1d@sisko.linkoping.osa>

In the search loop, step 6 can never be reached because step 5 either goes  
to 1 or aborts the task. Simply removing "Otherwise, abort the task."  
should do the trick.

-- 
Philip J?genstedt
Opera Software

From jackalmage at gmail.com  Thu May  7 07:25:51 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 7 May 2009 09:25:51 -0500
Subject: [whatwg] innerStaticHTML
In-Reply-To: <11e306600905061401h75125642jca0154f0f46f4dd7@mail.gmail.com>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
	<op.utiol9s92q99of@id-c0981>
	<11e306600905061401h75125642jca0154f0f46f4dd7@mail.gmail.com>
Message-ID: <dd0fbad0905070725v37b4754dgbbf76d2f51d759fb@mail.gmail.com>

On Wed, May 6, 2009 at 4:01 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Wed, May 6, 2009 at 9:40 AM, Jo?o Eiras <joaoe at opera.com> wrote:
>>
>> As part of a browser implementation team I can clearly say that the cases
>> where scripts should, or should not run are very hard to implement in a
>> cross browser compatible way. Marking those scripts or plugins are
>> non-executable would make everything much more complex and bug prone. Also,
>> it would be impossible to do that for a onevent attribute without all sorts
>> of problems.
>> The suggestion of marking content as non-executable doesn't solve
>> anything, because after setting innerStaticHTML another script might
>> serialize a piece of the affected DOM to string and back to a tree, and the
>> code could then execute, which would not be wanted.
>>
>> The only viable solution, from my point of view, would be for the UA to
>> parse the string, and remove all untrusted content from the result tree
>> before appending to the document.
>> That would mean removing all onevent attributes, all scripts elements, all
>> plugins, etc. Basically, letting the UA implement all the filtering.
>
>
> I think that's actually what Adam is proposing. At least, it's what I had in
> mind when we discussed it.

I'm in favor of this.  Browser-specified sanitizing, woo!

Obviously this doesn't replace the need for sandbox iframes (those are
still necessary for building a page using external html without
javascript), but it's a much easier solution for pretty much any
js-based sandbox-iframe situation.

~TJ

From msporny at digitalbazaar.com  Thu May  7 07:56:46 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu, 07 May 2009 10:56:46 -0400
Subject: [whatwg] Micro-data/Microformats/RDFa Interoperability
	Requirement
In-Reply-To: <Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>
References: <4A0104C2.8080009@digitalbazaar.com>
	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>
Message-ID: <4A02F6AE.1000602@digitalbazaar.com>

Ian Hickson wrote:
>> - Not triggering output in a Microformats/RDFa parser as a side-effect
>>   of WHATWG micro-data markup.
>> - Not creating an environment where WHATWG micro-data markup breaks or
>>   eliminates Microformats/RDFa markup.
> 
> This isn't possible. 

Things that are impossible just take longer, right :)

In all seriousness, I think there was a mis-communication here, the
things that I'm thinking about are possible, I'll elaborate and further
clarify below.

> Even a regular HTML5 document with no microdata 
> annotations that links in a style sheet ends up triggering output in 
> Microformats and RDFa parsers 

This is fine and is what legacy markup does in the same RDFa processor
that purposefully doesn't throw an error when processing a
non-XHTML1.1+RDFa document. By design, RDFa generates triples for
certain rel/rev values that were semantic terms in HTML4.

> -- Microformats because any use of 'class' 
> can clash with a Microformats class name, 

Yes, and unintended clashes with Microformats is fine as long as
whatever micro-data solution that this community adopts doesn't do
something like:

<div class="vcard"><span class="fn">Rupert Giles</span></div>

and then define different values for 'fn' inside an 'hcard' that
conflict with what the Microformats community has stated that they mean.
Since Microformats don't use named scopes for most of their vocabulary
terms, it's far easier to clash with those terms than it is to clash
with the RDFa terms.

The RDFa community was very careful to not negatively impact existing
Microformats markup. We purposefully did not re-use @class because in
the RDFa designs that did re-use it, it caused a number of
clashes/issues. Similarly, we did not re-use @id because authors were
already using it in a way that did not mesh well with semantic markup
concepts.

So, this argument isn't "Don't use @class at all", but rather "Don't
create ambiguity in @class where there is none currently."

Not re-defining things to mean something different than the Microformats
community has already defined should be a design requirement. For
example, don't create an ambiguous situation where a Microformats parser
would parse an vcard/FN and understand that this is a hCard Microformat
with a "Formatted Name" of "Rupert Giles" and a HTML5 micro-data parser
would do the same and determine that you're talking about something that
is semantically different.

> and RDFa because any use of the "rel" attribute can do the same.

No, not /any/ use - /specific/ uses of rel, and then only if the HTML5
micro-data solution does something that is counter to how RDFa uses the
attribute or the value. Really, the @rel values are only defined for
XHTML1.1, so this is technically less of a concern for RDFa than it is
for Microformats.

The most important issue with RDFa is not re-using attributes already
defined by XHTML1.1+RDFa without them having the exact same use in
HTML5. Attributes like @about, @property, @datatype, @resource, @content
and @typeof.

> It's also not clear to me what RDFa's position in text/html is. As I 
> understand it, RDFa only applies to XHTML. Thus it seems that HTML5 has 
> already broken compatibility with RDFa, since it requires processors to 
> handle text/html content in a non-XML manner.

No exactly, the processing rules for RDFa are more-or-less XML-agnostic
(by design) and can be made completely XML-agnostic with a minimal set
of known changes.

There is this lingering issue of xmlns in HTML5, but even if WHATWG
removes xmlns entirely from HTML5 (which we don't want you to do), there
is still the @prefix alternative[1] for RDFa.

RDFa also uses @rev extensively, so removing that value from HTML5 has
some fairly strong negative consequences for RDFa, which is why we would
prefer that it not be removed.

> Similarly, the rules for handling CURIEs in RDFa, especially in rel="", 
> are already incompatible with HTML4 and HTML5 rules. For example, the way 
> that "n:next" and "next" can end up being equivalent in RDFa processors 
> despite being different per HTML rules (assuming an "n" namespace is 
> appropriately declared).

If they end up being equivalent in RDFa, the RDFa author did so
explicitly when declaring the 'n' prefix to the default prefix mapping
and we should not second-guess the authors intentions. Unless I'm
missing something, "n:next" and "next" cannot accidentally end up being
equivalent - they cannot become equivalent due to language ambiguity and
they cannot become equivalent due to a bug in the current RDFa
processing rules.

We were very careful about not accidentally creating the ambiguity you
describe. So, I'm asserting that the rules for handling CURIEs in RDFa
are not incompatible with HTML4 and HTML5 rules. Do you have any other
examples that counter this point? Please either confirm or deny so that
I can make note of it on the RDFa wiki.

In any case, this discussion is about HTML5 /not/ creating ambiguity for
values that Microformats/RDFa uses /if/ a different micro-data solution
is chosen. So, to solve this issue in world where HTML5 adopts a
different micro-data solution from Microformats/RDFa - don't adopt xmlns
(which sounds like the direction you're going) and don't use @prefix to
declare prefix mappings (which sounds like you guys don't want to do
that anyway, so it shouldn't be a big deal).

> I don't think there's much that can be done about this (this isn't 
> something that we can change HTML5 rules for; browser vendors would not 
> accept having to resolve QNames in rel="" attributes as part of 
> processing, for one).

This has been explained many[2] times[3] now[4], CURIEs are not QNames.
If you have an issue with CURIEs, please state the exact issue that you
have with CURIEs and don't use a false analogy.

Browser vendors already resolve things like class="big-bold-letters"
using CSS stylesheets, they are in the business of resolving values in
attributes, what makes this any different? Nobody has been able to
effectively highlight this argument to me, does a wiki page exist that
explains this argument in detail? If not, can somebody create one?

Again, since this particular thread is about
Micro-data/Microformats/RDFa Interoperability - and if HTML5 creates
their own micro-data solution, don't define any CURIE-like behavior in
your micro-data solution that would conflict with Microformats and RDFa.

>> I think these are implied since HTML5 has gone to great lengths to
>> provide backward compatibility.
> 
> Backwards compatibility in HTML5 is primarily concerned with being 
> compatible with legacy markup, of which there is very little when it comes 
> to either RDFa or Microformats (especially RDFa, since there's so little 
> XHTML content for it to be found in).

When is the cut-off date for this? What constitutes legacy markup for
HTML5? I ask because the finishing touches for HTML5 aren't supposed to
be done until 2022, so I would expect that all markup before that date
would constitute legacy markup? As you know RDFa is being integrated
into Drupal core as we speak, which means that we can expect roughly 1.4
million sites to have RDFa integrated after 4 months of the next Drupal
release[5]. Is that enough? How many sites must adopt a particular web
technology for them to be considered valid legacy sites per HTML5's
metrics? Could this information be placed into a wiki page if it isn't
already?

-- manu

[1]http://rdfa.info/wiki/Alternate-prefix-declaration-mechanism
[2]http://lists.w3.org/Archives/Public/www-html-editor/2008OctDec/0000.html
[3]http://www.w3.org/TR/curie/#s_intro
[4]http://rdfa.info/wiki/Developer-faq#QNames_have_been_identified_as_a_known_anti-pattern.2C_does_RDFa_revive_QName_use.3F
[5]http://buytaert.net/drupal-download-statistics-2008

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From brucel at opera.com  Thu May  7 08:15:57 2009
From: brucel at opera.com (Bruce Lawson)
Date: Thu, 07 May 2009 16:15:57 +0100
Subject: [whatwg] Question on (new) header and hgroup
Message-ID: <op.utkfcvf1h8on37@bruce-pc>

I'm struggling to understand the reasons for <hgroup>: wouldn't one or
more h1..h6 elements wrapped in the same <header> imply just such a
grouping without the need for such an element?

To illustrate my query, what is the difference between

<header>
<h1>HTML 5</h1>
<h2>a new era of loveliness</h2>
<nav> ... </nav>
</header>

and

<header>
<hgroup>
<h1>HTML 5</h1>
<h2>a new era of loveliness</h2>
</hgroup>
<nav> ... </nav>
</header>

?

-- 
Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From brucel at opera.com  Thu May  7 08:17:51 2009
From: brucel at opera.com (Bruce Lawson)
Date: Thu, 07 May 2009 16:17:51 +0100
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
	audio/ video
Message-ID: <op.utkff1ldh8on37@bruce-pc>

This may already be in the spec, but I couldn't find it.

I think the spec should explicity require UAs to provide a mehanism to
mute audio and to pause video, even if the controls attribute is not set.

This will be of great benefit to screenreader users, as well as to people
who work in shared environments and who may not be expecting noise.

(There is a precedent for worrying about "mere annoyance": "User agents
should not provide a public API to cause videos to be shown full-screen. A
script, combined with a carefully crafted video file, could trick the user
into thinking a system-modal dialog had been shown, and prompt the user
for a password. There is also the danger of "mere" annoyance, with pages
launching full-screen videos when links are clicked or pages navigated.")

Should autoplay be removed as an attribute of audio and video, precisely
to remove such annoyance from people who rely on aural browsing? While
there are video sites such as youTube that do play videos automatically,
others such as vimeo don't. Is there an archive that lists the use-cases
for autoplay and contrasts it with the "annoyance" and accessibility
issues?.

(see  
http://www.brucelawson.co.uk/2009/accessibility-of-html5-video-and-audio-elements/)

-- 
Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From jgraham at opera.com  Thu May  7 08:25:40 2009
From: jgraham at opera.com (James Graham)
Date: Thu, 07 May 2009 17:25:40 +0200
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
 audio/ video
In-Reply-To: <op.utkff1ldh8on37@bruce-pc>
References: <op.utkff1ldh8on37@bruce-pc>
Message-ID: <4A02FD74.5070108@opera.com>

Bruce Lawson wrote:
> This may already be in the spec, but I couldn't find it.
> 
> I think the spec should explicity require UAs to provide a mehanism to
> mute audio and to pause video, even if the controls attribute is not set.

This would not make sense in some situations e.g. for a UA designed to 
play in-store video adverts (which I hate by the way :) ). In general 
the spec does not and should not mandate or constrain UI, although it 
does sometimes make suggestions (in general I am rather against this 
because the people that are good at writing technical specifications are 
rarely the same people who are good at designing UI, so such suggestions 
are often not that great. And UI is an area in which browsers should be 
allowed to compete).

From jgraham at opera.com  Thu May  7 08:34:21 2009
From: jgraham at opera.com (James Graham)
Date: Thu, 07 May 2009 17:34:21 +0200
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <op.utkfcvf1h8on37@bruce-pc>
References: <op.utkfcvf1h8on37@bruce-pc>
Message-ID: <4A02FF7D.5070301@opera.com>

Bruce Lawson wrote:
> I'm struggling to understand the reasons for <hgroup>: wouldn't one or
> more h1..h6 elements wrapped in the same <header> imply just such a
> grouping without the need for such an element?
> 
> To illustrate my query, what is the difference between
> 
> <header>
> <h1>HTML 5</h1>
> <h2>a new era of loveliness</h2>
> <nav> ... </nav>
> </header>
> 
> and
> 
> <header>
> <hgroup>
> <h1>HTML 5</h1>
> <h2>a new era of loveliness</h2>
> </hgroup>
> <nav> ... </nav>
> </header>

<hgroup> affects the document structure, <header> does not. So if you 
made an outline view of your document, the examples above would look 
(with the addition of a <hx> element inside the nav with content 
"Navigation") like

+--HTML 5
    +--A new era of loveliness
       +--Navigation

+--HTML 5 - a new era of loveliness
    +--Navigation

So, in the first example "A new era of loveliness" is a real section 
heading and the navigation becomes a subsection of that section. In the 
second example the <hgroup> element tells us that the <h1> and <h2> 
elements form a heading-subheading pair and that the navigation is a 
subsection of the section headed by this heading/subheading pair.

Is that any clearer?

From t.broyer at gmail.com  Thu May  7 08:34:08 2009
From: t.broyer at gmail.com (Thomas Broyer)
Date: Thu, 7 May 2009 17:34:08 +0200
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <op.utkfcvf1h8on37@bruce-pc>
References: <op.utkfcvf1h8on37@bruce-pc>
Message-ID: <a9699fd20905070834i279ac9c0na49473fa276308c2@mail.gmail.com>

On Thu, May 7, 2009 at 5:15 PM, Bruce Lawson <brucel at opera.com> wrote:
> I'm struggling to understand the reasons for <hgroup>: wouldn't one or
> more h1..h6 elements wrapped in the same <header> imply just such a
> grouping without the need for such an element?

No longer, as <header> is not a sectioning element (IIUC).

> To illustrate my query, what is the difference between
>
> <header>
> <h1>HTML 5</h1>
> <h2>a new era of loveliness</h2>
> <nav> ... </nav>
> </header>
>
> and
>
> <header>
> <hgroup>
> <h1>HTML 5</h1>
> <h2>a new era of loveliness</h2>
> </hgroup>
> <nav> ... </nav>
> </header>
>
> ?

The answer is in the second example of <header> (copied thereafter for
convenience):

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-header-element

In this example, the page has a page heading given by the h1 element,
and two subsections whose headings are given by h2 elements. The
content after the header element is still part of the last subsection
started in the header element, because the header element doesn't take
part in the outline algorithm.

<body>
 <header>
  <h1>Little Green Guys With Guns</h1>
  <nav>
   <ul>
    <li><a href="/games">Games</a> |
    <li><a href="/forum">Forum</a> |
    <li><a href="/download">Download</a>
   </ul>
  </nav>
  <h2>Important News</h2> <!-- this starts a second subsection -->
  <!-- this is part of the subsection entitled "Important News" -->
  <p>To play today's games you will need to update your client.</p>
  <h2>Games</h2> <!-- this starts a third subsection -->
 </header>
 <p>You have three active games:</p>
 <!-- this is still part of the subsection entitled "Games" -->
 ...

-- 
Thomas Broyer

From brucel at opera.com  Thu May  7 08:37:38 2009
From: brucel at opera.com (Bruce Lawson)
Date: Thu, 07 May 2009 16:37:38 +0100
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <4A02FF7D.5070301@opera.com>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
Message-ID: <op.utkgc0kuh8on37@bruce-pc>

On Thu, 07 May 2009 16:34:21 +0100, James Graham <jgraham at opera.com> wrote:

> So, in the first example "A new era of loveliness" is a real section  
> heading and the navigation becomes a subsection of that section. In the  
> second example the <hgroup> element tells us that the <h1> and <h2>  
> elements form a heading-subheading pair and that the navigation is a  
> subsection of the section headed by this heading/subheading pair.

> Is that any clearer?

much, thanks. Does your sectioning outliner utility now take these changes  
into account, by the way?


-- 
Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From excors+whatwg at gmail.com  Thu May  7 09:51:08 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Thu, 7 May 2009 17:51:08 +0100
Subject: [whatwg] rel=license example
Message-ID: <ea09c0d10905070951k73fb862csaed53fd91470165f@mail.gmail.com>

The rel=license example in
<http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-license>
looks like:

 <body>
  <h1>Kissat</h1>
  <nav> <a href="../">Return to photo index</a> </nav>
  <img src="/pix/39627052_fd8dcd98b5.jpg">
  <p>One of them has six toes!</p>
  ...
 </body>

Looking down the list of <img> alternative text requirements in the
table of contents, the <img> seems to be "A key part of the content"
(<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#a-key-part-of-the-content>).

It's presumably not "possible for detailed alternative text to be
provided", because it's a photo rather than some kind of describable
diagram. Maybe "the nature of the image might be such that providing
thorough alternative text is impractical" but I can't tell if this
applies since I don't know what the image is. The "Images whose
contents are not known" case looks like the best fit. That requires
one of three things:

There's no title attribute, so it fails the first requirement.

There's no figure element, so it fails the second requirement.

Therefore it requires: "The img element is part of the only paragraph
directly in its section, and is the only img element without an alt
attribute in its section, and its section has an associated heading."

Its section is the section created by the <body> element. I think the
paragraphs directly in the section are "<img ...>", "One of them has
six toes!", "...". (I thought "Return to photo index" was too, but
then I realised it's not "directly in" the section, assuming that
means it must consist of direct child nodes. Also I'm assuming the
paragraph formed explicitly by a <p> element is directly in the parent
element of the <p>, rather than being directly in the <p> itself). So
the img element isn't part of the only paragraph, and it fails the
third requirement too.

Conclusions probably include a subset of the following:

 * The license example is invalid.
 * The validity rules for <img> are far too complex since even the
editor got them wrong.
 * The validity rules for <img> are far too complex since it takes
this much effort to work out that the editor got them wrong.
 * The validity rules for <img> are far too complex since I concluded
the editor got them wrong when actually he got them right.
 * The validity rules for <img> are not explained sufficiently clearly
since I concluded the editor got it wrong when actually he got it
right.
 * I'm too stupid to understand HTML since the spec is sufficiently
simple and sufficiently clear and I still concluded the editor got it
wrong when actually he got it right.

-- 
Philip Taylor
excors at gmail.com

From Smylers at stripey.com  Thu May  7 10:32:12 2009
From: Smylers at stripey.com (Smylers)
Date: Thu, 7 May 2009 18:32:12 +0100
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <4A02FF7D.5070301@opera.com>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
Message-ID: <20090507173212.GB16047@stripey.com>

James Graham writes:

> Bruce Lawson wrote:
> 
> > I'm struggling to understand the reasons for <hgroup>: wouldn't one
> > or more h1..h6 elements wrapped in the same <header> imply just such
> > a grouping without the need for such an element?
> 
> <hgroup> affects the document structure, <header> does not.

That explains _how_ they are different (as does the spec), but not _why_
it is like that.

More specifically:

* Are there significant cases where <header> needs _not_ to imply
  <hgroup>?  Consider wrapping an <hgroup> inside every <header>; how
  many places has that broken the semantics?  I could believe that most
  of the cases where a pager header appropriately contains multiple
  headings they are subtitles rather than subsections.

  Anybody who specifically needs subsections in a <header> could still
  have them by using <section> inside <header>.  That wouldn't help for
  the 'Little Green Guys with Guns' example (where a section is started
  in a <header> then 'leaks out' into the following elements) -- but
  would it be unacceptable to force authors to write that with </header>
  before one of the <h2>-s?

* Given the newness and nuance of <header> and <hgroup> and the
  distinction between them, it's likely that some authors will confuse
  them.  Given that <hgroup> doesn't appear to do anything on the page
  (it's similar to invisible meta-data), it's likely that some authors
  will omit it[*1] when it's needed to convey the semantics they intend.

  Might actually the number of authors who mistakenly write <header>
  instead of <header><hgroup> outnumber those who need to have
  subsections in headers?  That is, if <header> implied <hgroup>, might
  it fix more cases than it breaks?

* Are there significant cases where <hgroup> will be useful outside of
  <header>?

  <hgroup> exists to allow for subtitles and the like.  It's fairly
  common for documents to have these -- where it's likely there's use
  for a <header> element anyway.
  
  It's much less common for a mere section of a document to warrant a
  multi-part title; is that a case which is worth solving?  If it is,
  would it be problematic to force authors to use <header> there?

  I think that would mean that a subsection like this:

    <hgroup><h2>Kaboom!</h2> <h3>A Mysterious Loud Noise</h3></hgroup>
    <p>Suddenly ...

  Would instead have to be written as:

    <section>
      <header><h2>Kaboom!</h2> <h3>A Mysterious Loud Noise</h3></header>
      <p>Suddenly ...
    </section>

  That doesn't seem too onerous for such a niche usage.

If <header> implied <hgroup> semantics (but only acted as a heading if
there actually is an <h1> somewhere inside it) and if all current uses
of <hgroup> could be put inside a <header> then we could avoid
introducing the <hgroup> element.

Smylers

[*1]  <header> is less likely to suffer from this since it's often
replacing <div class="header"> or similar; authors want a block at that
point in the page anyway.

From kornel at geekhood.net  Thu May  7 11:34:26 2009
From: kornel at geekhood.net (Kornel Lesinski)
Date: Thu, 07 May 2009 19:34:26 +0100
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <op.utkfcvf1h8on37@bruce-pc>
References: <op.utkfcvf1h8on37@bruce-pc>
Message-ID: <op.utkojov6ptj49s@aimac.local>

These new elements weren't clear to me initially either.

Maybe instead of:

<h1>HTML 5</h1>
<h2>a new era of loveliness</h2>

We should introduce <subtitle> or <tagline> elements?

<h1>HTML 5</h1>
<tagline>a new era of loveliness</tagline>

or perhaps stepping a little on XHTML2's toes isn't that bad and <hgroup> can be renamed to <h>:

<h>
<h1>HTML 5</h1>
<h2>a new era of loveliness</h2>
</h>

-- 
regards, Kornel Lesinski

From singer at apple.com  Thu May  7 12:04:20 2009
From: singer at apple.com (David Singer)
Date: Thu, 7 May 2009 12:04:20 -0700
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<E470702C-DB5F-44C5-8CCD-81AA988FCB29@apple.com>
	<c2e346f90904062111t7429143ande88c37c654b7bb9@mail.gmail.com>
	<2A9F6E32-1680-47E9-98B8-C7DCA6B484B1@apple.com>
	<Pine.LNX.4.62.0904300024400.10370@hixie.dreamhostps.com>
	<2c0e02830904291828v34f4060frc11b0d761e543cea@mail.gmail.com>
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com>
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
Message-ID: <p062408ffc628e0b05904@[17.202.35.52]>

At 8:39  +0200 5/05/09, K?i?tof ?elechovski wrote:
>If the author wants to show only a sample of a resource and not the full
>resource, I think she does it on purpose.  It is not clear why it is vital
>for the viewer to have an _obvious_ way to view the whole resource instead;
>if it were the case, the author would provide for this.
>IMHO,
>Chris

It depends critically on what you think the 
semantics of the fragment are.  In HTML (the best 
analogy I can think of), the web page is not 
trimmed or edited in any way -- you are merely 
directed to one section of it.

I am also aware that browsers that don't 
implement fragments will also show the whole 
resource;  so authors can't rely on he trimming.

Given both of these, I tend towards using # as a 
focus of attention;  if trimming is desired, the 
server should probably do it (maybe using ?).


-- 
David Singer
Multimedia Standards, Apple Inc.

From ian at hixie.ch  Thu May  7 12:53:22 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 May 2009 19:53:22 +0000 (UTC)
Subject: [whatwg] Micro-data/Microformats/RDFa
	Interoperability	Requirement
In-Reply-To: <4A02F6AE.1000602@digitalbazaar.com>
References: <4A0104C2.8080009@digitalbazaar.com>
	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>
	<4A02F6AE.1000602@digitalbazaar.com>
Message-ID: <Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>

On Thu, 7 May 2009, Manu Sporny wrote:
> 
> So, this argument isn't "Don't use @class at all", but rather "Don't 
> create ambiguity in @class where there is none currently."

I agree that if HTML5 re-uses vocabulary "root" terms from Microformats, 
it should either not use class="", or should do so in a way that does not 
cause existing consumers of Microformats to treat existing content in a 
way that is not compliant with HTML5.


> Not re-defining things to mean something different than the Microformats
> community has already defined should be a design requirement.

That requirement has been broken for some time, because the definitions of 
rel="license" and rel="tag" in HTML5 differ from those on the Microformats 
wiki. (The definitions in HTML5 are closer to what existing 
implementations and content rely on, though, so I don't think it violates 
the requirement to "not cause existing consumers of Microformats to treat 
existing content in a way that is not compliant with HTML5".)


> > and RDFa because any use of the "rel" attribute can do the same.
> 
> No, not /any/ use - /specific/ uses of rel, and then only if the HTML5 
> micro-data solution does something that is counter to how RDFa uses the 
> attribute or the value.

Actually as far as I can tell, it really is any use.

The RDFa specification is very confusing to me (e.g. I don't understand 
how the normative processing model is separate from the section "RDFa 
Processing in detail"), so I may be misinterpreting things, but as far as 
I can tell:

  <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
    <base href="http://example.com/"/>
    <link about="http://example.net/"
          rel="dc.author" 
          href="http://a.example.org/"/>
   ...

...will result in the following triple:

   <http://example.net/> <http://example.com/dc.author> <http://a.example.org/> .


> The most important issue with RDFa is not re-using attributes already 
> defined by XHTML1.1+RDFa without them having the exact same use in 
> HTML5. Attributes like @about, @property, @datatype, @resource, @content 
> and @typeof.

content="" is already an attribute on <meta> in HTML, and that one can't 
be changed either.

Given that HTML4 already has five of RDFa's 10 attributes (not counting 
prefix declaration mechanisms), and defines processing for these that 
conflicts with RDFa's (e.g. as described below), it's not clear to me what 
benefit there would be in completely avoiding the other five attributes if 
there was a need to use such an attribute.

For example, it would be somewhat presumptious of RDFa to prevent any 
future version of HTML from being able to use the word "resource" as an 
attribute name. What if we want to extend the forms features to have an 
XForms "datatype" compatibility layer; why should we not be able to use 
the "datatype" and "typeof" attributes?

Surely this is what namespaces were intended for.


> > Similarly, the rules for handling CURIEs in RDFa, especially in 
> > rel="", are already incompatible with HTML4 and HTML5 rules. For 
> > example, the way that "n:next" and "next" can end up being equivalent 
> > in RDFa processors despite being different per HTML rules (assuming an 
> > "n" namespace is appropriately declared).
> 
> If they end up being equivalent in RDFa, the RDFa author did so 
> explicitly when declaring the 'n' prefix to the default prefix mapping 
> and we should not second-guess the authors intentions.

My only point is that it is not compatible with HTML4 and HTML5, because 
they end up with different results in the same situation (one can treat 
two different values as the same, while the other can treat two different 
values as different).

Another example would be the following:

  <html xmlns="http://www.w3.org/1999/xhtml">
   <head about="">
    <link rel="stylesheet" href="...">
    <link rel="STYLESHEET" href="...">
    ...

...which would be treated as two different triples in an RDFa processor, 
but treated as two identical imports according to an HTML4/5 processor.

Another example would be:

  <html xmlns="http://www.w3.org/1999/xhtml">
   <head about="">
    <link rel="stylesheet alternate next" href="...">
    ...

...which in RDFa would cause the following triples to be created:

   <> <http://www.w3.org/1999/xhtml/vocab#stylesheet> <...> .
   <> <http://www.w3.org/1999/xhtml/vocab#alternate> <...> .
   <> <http://www.w3.org/1999/xhtml/vocab#next> <...> .

...but according to HTML4/5, is really only two relations (an alternativee 
stylesheet and the next document).


> > I don't think there's much that can be done about this (this isn't 
> > something that we can change HTML5 rules for; browser vendors would 
> > not accept having to resolve QNames in rel="" attributes as part of 
> > processing, for one).
> 
> This has been explained many[2] times[3] now[4], CURIEs are not QNames. 
> If you have an issue with CURIEs, please state the exact issue that you 
> have with CURIEs and don't use a false analogy.

Browser vendors would not accept having to resolve prefixes in attribute 
values as part of processing link relations.

(What's the difference between mapping to a full URI and mapping to a 
namespace,local pair? The problem with QNames in attributes is that they 
require the attribute processor to have information from the namespace 
processor, and as far as I can tell this continues to exist in RDFa.)


> > Backwards compatibility in HTML5 is primarily concerned with being 
> > compatible with legacy markup, of which there is very little when it 
> > comes to either RDFa or Microformats (especially RDFa, since there's 
> > so little XHTML content for it to be found in).
> 
> When is the cut-off date for this?

Such things are dealt with as judgement calls. If you want a date, though, 
I guess today, since we don't have data for tomorrow yet.


> I ask because the finishing touches for HTML5 aren't supposed to be done 
> until 2022

CR (when the finishing touches are done) is supposed to happen in 2012, 
not 2022. LC (when the spec is done) is supposed to be October 2009. 2022 
is the optimistic date for the test suite to be complete and 
implementations to be bug-free.

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

From jgraham at opera.com  Thu May  7 13:34:46 2009
From: jgraham at opera.com (jgraham at opera.com)
Date: Thu, 07 May 2009 20:34:46 +0000
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <20090507173212.GB16047@stripey.com>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<20090507173212.GB16047@stripey.com>
Message-ID: <20090507203446.w2pd12cu800owoos@staff.opera.com>

Quoting Smylers <Smylers at stripey.com>:

> James Graham writes:
>
>> Bruce Lawson wrote:
>>
>> > I'm struggling to understand the reasons for <hgroup>: wouldn't one
>> > or more h1..h6 elements wrapped in the same <header> imply just such
>> > a grouping without the need for such an element?
>>
>> <hgroup> affects the document structure, <header> does not.
>
> That explains _how_ they are different (as does the spec), but not _why_
> it is like that.
>
> More specifically:
>
> * Are there significant cases where <header> needs _not_ to imply
>   <hgroup>?  Consider wrapping an <hgroup> inside every <header>; how
>   many places has that broken the semantics?  I could believe that most
>   of the cases where a pager header appropriately contains multiple
>   headings they are subtitles rather than subsections.

The semantic that authors seem to want from an element named "header"  
is "All the top matter of my page before the main content". That could  
include headers, subheaders, navigation, asides (at least per the  
current definition of aside which I think is silly, but I digress) and  
almost anything else. Since the <header> can contain multiple distinct  
logical sections of the document, each with their own headers, it  
makes no sense to implicitly wrap its contents in <hgroup>.

> * Given the newness and nuance of <header> and <hgroup> and the
>   distinction between them, it's likely that some authors will confuse
>   them.  Given that <hgroup> doesn't appear to do anything on the page
>   (it's similar to invisible meta-data), it's likely that some authors
>   will omit it[*1] when it's needed to convey the semantics they intend.

Yes, that is possible. The thinking behind the change (or, at least,  
part of my reason for proposing it) was that it is less harmful if  
authors omit something where it would be useful than that they use it  
incorrectly in such a way that tools which follow the spec would be  
broken from the point of view of end users. In particular the old  
formulation of <header> would have caused the <h2> element to be  
omitted from the outline in cases like <header><h1>My  
Blog</h1><nav><h2>Navigation</h2></nav></header>, which would be  
confusing for users. On he other hand in the current formulation of  
the spec, the most likely error (omitting <hgroup>) only has the  
effect that that outline heirachy is slightly wrong, with the  
subheader appearing as an actual header; it does not lead to data  
loss. This seems like a much better failure mode.

> * Are there significant cases where <hgroup> will be useful outside of
>   <header>?
>
>   <hgroup> exists to allow for subtitles and the like.  It's fairly
>   common for documents to have these -- where it's likely there's use
>   for a <header> element anyway.
>
>   It's much less common for a mere section of a document to warrant a
>   multi-part title; is that a case which is worth solving?  If it is,
>   would it be problematic to force authors to use <header> there?

It seems highly odd to have <header> perform a dual role where  
sometimes it means "section header" and sometimes it means "group of  
heading/subheading elements". Much more confusing than one element per  
role.



From atwilson at google.com  Thu May  7 13:39:26 2009
From: atwilson at google.com (Drew Wilson)
Date: Thu, 7 May 2009 13:39:26 -0700
Subject: [whatwg] MessagePorts in Web Workers: implementation feedback
Message-ID: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>

Hi all,

I've been hashing through a bunch of the design issues around using
MessagePorts within Workers with IanH and the Chrome/WebKit teams and I
wanted to follow up with the list with my progress.

The problems we've encountered are all solveable, but I've been surprised at
the amount of work involved in implementing worker MessagePorts (and the
resulting implications that MessagePorts have on worker
lifecycles/reachability). My concern is that the amount of work to implement
MessagePorts within Worker context may be so high that it will prevent
vendors from implementing the SharedWorker API. Have other implementers
started working on this part of the spec yet?

Let me quickly run down some of the implementation issues I've run into -
some of these may be WebKit/Chrome specific, but other browsers may run into
some of them as well:

1) MessagePort reachability is challenging in the context of separate Worker
heaps

In WebKit, each worker has its own heap (in Chrome, they will have their own
process as well). The spec reads:

User agents must act as if
MessagePort<http://www.w3.org/TR/html5/comms.html#messageport>objects
have a strong reference to their entangled
MessagePort <http://www.w3.org/TR/html5/comms.html#messageport> object.

Thus, a message port can be received, given an event listener, and then
forgotten, and so long as that event listener could receive a message, the
channel will be maintained.

Of course, if this was to occur on both sides of the channel, then both
ports would be garbage collected, since they would not be reachable from
live code, despite having a strong reference to each other.

Furthermore, a MessagePort<http://www.w3.org/TR/html5/comms.html#messageport>object
must not be garbage collected while there exists a message in a task
queue <http://www.w3.org/TR/html5/browsers.html#task-queue> that is to be
dispatched on that
MessagePort<http://www.w3.org/TR/html5/comms.html#messageport>object,
or while the
MessagePort <http://www.w3.org/TR/html5/comms.html#messageport> object's port
message queue <http://www.w3.org/TR/html5/comms.html#port-message-queue> is
open and there exists a
message<http://www.w3.org/TR/html5/comms.html#event-message>event in
that queue.

The end result of this is the need to track some common state across an
entangled MessagePort pair such as: number of outstanding messages, open
state of each end, and number of active references to each port (zero or
non-zero). Turns out this last bit will require adding new hooks to the
JavaScriptCore garbage collector to detect transitioning between 1 and 0
references without actually freeing the object - not that difficult, but
possibly something that other implementers should keep in mind.

2) MessagePorts dramatically change the worker lifecycle

Having MessagePorts in worker context means that Workers can outlive their
parent window(s) - I can create a worker, pass off an entangled MessagePort
to another window (say, to a different domain), then close the original
window, and the worker should stay alive. In the case of WebKit, this causes
some problems for things like worker-initiated network requests - if workers
can continue to run even though there are no open windows for that origin,
then it becomes problematic to perform network requests (part of this is due
to the architecture of WebKit which requires proxying network requests to
window context, but part of this is just a general problem of "how do you
handle things like HTTP Auth when there are no open windows for that
origin?")

Finally, the spec defines a fairly broad definition of what makes a worker
reachable - here's an excerpt from my WebKit Shared Worker design doc, where
I summarize the spec (possibly incorrectly - feel free to correct any
misconceptions):

> PermissibleThe spec specifies that a worker is *permissible* based on
> whether it has a reachable MessagePort that has been entangled *at some
> point in the past* with an active window (or with a worker who is itself
> permissible). Basically, if a worker has *ever* been entangled with an
> active window, or if it's ever been entangled with a worker who is itself
> permissible (i.e. it's associated with an active window via a chain of
> workers that have been entangled at some point in the past) then it's
> permissible.
>
> The reason why the "at some point in the past" language is present is to
> allow a page to create a fire-and-forget worker (for example, a worker that
> does a set of long network operations) without having to keep a reference to
> that worker around.
>
> Once the referent windows close, the worker should also close, as being
> permissible is a necessary (but not sufficient) criteria for being
> runnable.
> Active neededA permissible worker is *active needed* if:
>
>    1. it has pending timers/network requests/DB activity, or
>    2. it is currently entangled with an active window, or another active
>    needed worker.
>
>
> The intent behind #1 is to enable fire-and-forget workers that don't exit
> until they are idle. The intent behind #2 is that an idle worker shouldn't
> exit as long as it's reachable by an active window (possibly chained through
> other workers).
>
The end result is that for each worker we need to keep track of a big list
of every window it's ever been entangled with. As workers become entangled
with other workers, they each inherit the list of entangled windows from the
other worker. As windows become inactive, we then walk the lists of every
worker to remove references to the window and properly shutdown the worker
as appropriate. All of this with the appropriate cross-thread
synchronization, of course :)

Likewise, determining when a worker is active needed requires tracking a
graph of entangled message ports, and walking that graph to determine
whether a given worker is reachable by any active window. Typically this is
only needed when either a window closes, or when a worker goes idle.

Again, none of these issues individually are insurmountable, but in total
they add up to a significant amount of work for what should be a fairly
incremental improvement (going from dedicated workers to shared workers).
Have other vendors started investigating what it takes to implement
SharedWorkers (and therefore MessagePorts in workers)?

Another approach for SharedWorkers would be to give them an implicit
MessagePort-esque API like dedicated Workers and not allow passing in
MessagePorts to postMessage(). This would mean that references to workers
can't really be passed around to other windows/workers, but rather are kept
per-origin. Dedicated workers could work as they do now in Firefox/WebKit
(with no MessagePorts). The SharedWorker lifecycle could be significantly
simplified such that a SharedWorker is permissible as long as there's an
active window under the same origin (no more walking some distributed
cross-thread dependency graph).

The thing we'd give up is the capabilities-based API that MessagePorts
provide, but I'd argue that the workaround is simple: the creating window
can just act as a proxy for the worker. IMO, the implementation burden far
outstrips the benefit of allowing direct foreign access to workers.
Literally 90% of the work on my plate for SharedWorkers seems to derive from
MessagePorts in one form or another, which seems completely wrong.

I'd like to hear your thoughts on this - are people open to removing
MessagePort support from Workers?

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090507/ce35a927/attachment-0001.htm>

From giecrilj at stegny.2a.pl  Thu May  7 14:27:54 2009
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Thu, 7 May 2009 23:27:54 +0200
Subject: [whatwg] Micro-data/Microformats/RDFa
	InteroperabilityRequirement
In-Reply-To: <4A02F6AE.1000602@digitalbazaar.com>
References: <4A0104C2.8080009@digitalbazaar.com><Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>
	<4A02F6AE.1000602@digitalbazaar.com>
Message-ID: <AF8FBC538C824220A89A16268B0E6495@POCZTOWIEC>

The main problem with prefixes is that the meaning of prefixes is not
preserved when a code fragment is pasted elsewhere, so that prefixed names
can end up meaningless or having an entirely different meaning from what the
author had intended.  A similar problem arises with DTD entities (indeed,
DTD entities could be used instead of prefixes).
HTH,
Chris


From giecrilj at stegny.2a.pl  Thu May  7 14:29:41 2009
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Thu, 7 May 2009 23:29:41 +0200
Subject: [whatwg] rel=license example
In-Reply-To: <ea09c0d10905070951k73fb862csaed53fd91470165f@mail.gmail.com>
References: <ea09c0d10905070951k73fb862csaed53fd91470165f@mail.gmail.com>
Message-ID: <160F0B6E833946CBB74C60C4AE5FD064@POCZTOWIEC>

The rel=license example in
<http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#li
nk-type-license>
looks like:

 <body>
  <h1>Kissat</h1>
  <nav> <a href="../">Return to photo index</a> </nav>
  <img src="/pix/39627052_fd8dcd98b5.jpg">
  <p>One of them has six toes!</p>
  ...
 </body>

I would say that this particular example represents a figure with caption.
IMHO,
Chris




From ian at hixie.ch  Thu May  7 14:47:04 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 May 2009 21:47:04 +0000 (UTC)
Subject: [whatwg] MessagePorts in Web Workers: implementation feedback
In-Reply-To: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
References: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0905072144530.7824@hixie.dreamhostps.com>

On Thu, 7 May 2009, Drew Wilson wrote:
> 
> Having MessagePorts in worker context means that Workers can outlive 
> their parent window(s) - I can create a worker, pass off an entangled 
> MessagePort to another window (say, to a different domain), then close 
> the original window, and the worker should stay alive. In the case of 
> WebKit, this causes some problems for things like worker-initiated 
> network requests - if workers can continue to run even though there are 
> no open windows for that origin, then it becomes problematic to perform 
> network requests (part of this is due to the architecture of WebKit 
> which requires proxying network requests to window context, but part of 
> this is just a general problem of "how do you handle things like HTTP 
> Auth when there are no open windows for that origin?")

How does WebKit handle this case for regular Windows? (e.g. if a script 
does x=window.open(), grabs the x.XMLHttpRequest constructor, calls 
x.close(), and then invokes the constructor.)


> The thing we'd give up is the capabilities-based API that MessagePorts 
> provide, but I'd argue that the workaround is simple: the creating 
> window can just act as a proxy for the worker.

That's a rather poor workaround. :-)

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

From mjs at apple.com  Thu May  7 15:12:01 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 07 May 2009 15:12:01 -0700
Subject: [whatwg] MessagePorts in Web Workers: implementation feedback
In-Reply-To: <Pine.LNX.4.62.0905072144530.7824@hixie.dreamhostps.com>
References: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
	<Pine.LNX.4.62.0905072144530.7824@hixie.dreamhostps.com>
Message-ID: <67F89213-B833-43E2-9171-05D702BAACD2@apple.com>


On May 7, 2009, at 2:47 PM, Ian Hickson wrote:

> On Thu, 7 May 2009, Drew Wilson wrote:
>>
>> Having MessagePorts in worker context means that Workers can outlive
>> their parent window(s) - I can create a worker, pass off an entangled
>> MessagePort to another window (say, to a different domain), then  
>> close
>> the original window, and the worker should stay alive. In the case of
>> WebKit, this causes some problems for things like worker-initiated
>> network requests - if workers can continue to run even though there  
>> are
>> no open windows for that origin, then it becomes problematic to  
>> perform
>> network requests (part of this is due to the architecture of WebKit
>> which requires proxying network requests to window context, but  
>> part of
>> this is just a general problem of "how do you handle things like HTTP
>> Auth when there are no open windows for that origin?")
>
> How does WebKit handle this case for regular Windows? (e.g. if a  
> script
> does x=window.open(), grabs the x.XMLHttpRequest constructor, calls
> x.close(), and then invokes the constructor.)

I believe what would happen is: the UI would be thrown up by the  
window in which the script doing x.XMLHttpRequest runs, rather than  
the home window.

  - Maciej

>
>
>> The thing we'd give up is the capabilities-based API that  
>> MessagePorts
>> provide, but I'd argue that the workaround is simple: the creating
>> window can just act as a proxy for the worker.
>
> That's a rather poor workaround. :-)
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'


From atwilson at google.com  Thu May  7 15:12:46 2009
From: atwilson at google.com (Drew Wilson)
Date: Thu, 7 May 2009 15:12:46 -0700
Subject: [whatwg] MessagePorts in Web Workers: implementation feedback
In-Reply-To: <Pine.LNX.4.62.0905072144530.7824@hixie.dreamhostps.com>
References: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
	<Pine.LNX.4.62.0905072144530.7824@hixie.dreamhostps.com>
Message-ID: <f965ae410905071512y6046285dw27cec1c31663b7ed@mail.gmail.com>

It looks like WebKit binds the XMLHttpRequest object to its parent document
at instantiation time, so the source of the constructor doesn't make a
difference. And it looks like that binding is cleared when the document is
closed so invoking xhr.send() on an XHR object whose parent document is no
longer open fails silently. I'm basing this on code inspection, not on
extensive knowledge of the codebase, so the webkit folks should feel free to
correct me here.

Why is having the window proxy on behalf of its workers a poor workaround
for worker MessagePorts? I totally understand the utility of MessagePorts
for things like cross-window and cross-iframe communication, but it seems
like the use cases for external access to workers are far more obscure.

-atw

On Thu, May 7, 2009 at 2:47 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 7 May 2009, Drew Wilson wrote:
> >
> > Having MessagePorts in worker context means that Workers can outlive
> > their parent window(s) - I can create a worker, pass off an entangled
> > MessagePort to another window (say, to a different domain), then close
> > the original window, and the worker should stay alive. In the case of
> > WebKit, this causes some problems for things like worker-initiated
> > network requests - if workers can continue to run even though there are
> > no open windows for that origin, then it becomes problematic to perform
> > network requests (part of this is due to the architecture of WebKit
> > which requires proxying network requests to window context, but part of
> > this is just a general problem of "how do you handle things like HTTP
> > Auth when there are no open windows for that origin?")
>
> How does WebKit handle this case for regular Windows? (e.g. if a script
> does x=window.open(), grabs the x.XMLHttpRequest constructor, calls
> x.close(), and then invokes the constructor.)
>
>
> > The thing we'd give up is the capabilities-based API that MessagePorts
> > provide, but I'd argue that the workaround is simple: the creating
> > window can just act as a proxy for the worker.
>
> That's a rather poor workaround. :-)
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090507/adabb0c9/attachment.htm>

From mjs at apple.com  Thu May  7 15:28:46 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 07 May 2009 15:28:46 -0700
Subject: [whatwg] MessagePorts in Web Workers: implementation feedback
In-Reply-To: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
References: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
Message-ID: <DD94E15D-6977-48D8-9026-A5B3EBC33F3A@apple.com>


I agree with Drew's assessment that MessagePorts in combination with  
Workers are extremely complicated to implement correctly, as currently  
specified. In fact, the design seems to push towards having lockable  
shared state, even though one potential advantage of the message  
passing design is to avoid locking and shared state.

Besides removing MessagePorts as a way to communicate with workers,  
another possibility is simplifying the life cycle requirements. For  
example, getting rid of the keepalive rule, whereby both MessagePorts  
remain live so long as either is otherwise live, would remove the  
majority of the complexity. I don't think the slight convenience of  
that rule is worth the extra implementation cost.

On May 7, 2009, at 1:39 PM, Drew Wilson wrote:

> Hi all,
>
> I've been hashing through a bunch of the design issues around using  
> MessagePorts within Workers with IanH and the Chrome/WebKit teams  
> and I wanted to follow up with the list with my progress.
>
> The problems we've encountered are all solveable, but I've been  
> surprised at the amount of work involved in implementing worker  
> MessagePorts (and the resulting implications that MessagePorts have  
> on worker lifecycles/reachability). My concern is that the amount of  
> work to implement MessagePorts within Worker context may be so high  
> that it will prevent vendors from implementing the SharedWorker API.  
> Have other implementers started working on this part of the spec yet?
>
> Let me quickly run down some of the implementation issues I've run  
> into - some of these may be WebKit/Chrome specific, but other  
> browsers may run into some of them as well:
>
> 1) MessagePort reachability is challenging in the context of  
> separate Worker heaps
>
> In WebKit, each worker has its own heap (in Chrome, they will have  
> their own process as well). The spec reads:
> User agents must act as if MessagePort objects have a strong  
> reference to their entangled MessagePort object.
>
> Thus, a message port can be received, given an event listener, and  
> then forgotten, and so long as that event listener could receive a  
> message, the channel will be maintained.
>
> Of course, if this was to occur on both sides of the channel, then  
> both ports would be garbage collected, since they would not be  
> reachable from live code, despite having a strong reference to each  
> other.
>
> Furthermore, a MessagePort object must not be garbage collected  
> while there exists a message in a task queue that is to be  
> dispatched on that MessagePort object, or while the MessagePort  
> object's port message queue is open and there exists a message event  
> in that queue.
>
> The end result of this is the need to track some common state across  
> an entangled MessagePort pair such as: number of outstanding  
> messages, open state of each end, and number of active references to  
> each port (zero or non-zero). Turns out this last bit will require  
> adding new hooks to the JavaScriptCore garbage collector to detect  
> transitioning between 1 and 0 references without actually freeing  
> the object - not that difficult, but possibly something that other  
> implementers should keep in mind.
> 2) MessagePorts dramatically change the worker lifecycle
>
> Having MessagePorts in worker context means that Workers can outlive  
> their parent window(s) - I can create a worker, pass off an  
> entangled MessagePort to another window (say, to a different  
> domain), then close the original window, and the worker should stay  
> alive. In the case of WebKit, this causes some problems for things  
> like worker-initiated network requests - if workers can continue to  
> run even though there are no open windows for that origin, then it  
> becomes problematic to perform network requests (part of this is due  
> to the architecture of WebKit which requires proxying network  
> requests to window context, but part of this is just a general  
> problem of "how do you handle things like HTTP Auth when there are  
> no open windows for that origin?")
>
> Finally, the spec defines a fairly broad definition of what makes a  
> worker reachable - here's an excerpt from my WebKit Shared Worker  
> design doc, where I summarize the spec (possibly incorrectly - feel  
> free to correct any misconceptions):
>
> Permissible
>
> The spec specifies that a worker is permissible based on whether it  
> has a reachable MessagePort that has been entangled at some point in  
> the past with an active window (or with a worker who is itself  
> permissible). Basically, if a worker has ever been entangled with an  
> active window, or if it's ever been entangled with a worker who is  
> itself permissible (i.e. it's associated with an active window via a  
> chain of workers that have been entangled at some point in the past)  
> then it's permissible.
>
> The reason why the "at some point in the past" language is present  
> is to allow a page to create a fire-and-forget worker (for example,  
> a worker that does a set of long network operations) without having  
> to keep a reference to that worker around.
>
> Once the referent windows close, the worker should also close, as  
> being permissible is a necessary (but not sufficient) criteria for  
> being runnable.
> Active needed
>
> A permissible worker is active needed if:
> it has pending timers/network requests/DB activity, or
> it is currently entangled with an active window, or another active  
> needed worker.
>
> The intent behind #1 is to enable fire-and-forget workers that don't  
> exit until they are idle. The intent behind #2 is that an idle  
> worker shouldn't exit as long as it's reachable by an active window  
> (possibly chained through other workers).
> The end result is that for each worker we need to keep track of a  
> big list of every window it's ever been entangled with. As workers  
> become entangled with other workers, they each inherit the list of  
> entangled windows from the other worker. As windows become inactive,  
> we then walk the lists of every worker to remove references to the  
> window and properly shutdown the worker as appropriate. All of this  
> with the appropriate cross-thread synchronization, of course :)
> Likewise, determining when a worker is active needed requires  
> tracking a graph of entangled message ports, and walking that graph  
> to determine whether a given worker is reachable by any active  
> window. Typically this is only needed when either a window closes,  
> or when a worker goes idle.
>
> Again, none of these issues individually are insurmountable, but in  
> total they add up to a significant amount of work for what should be  
> a fairly incremental improvement (going from dedicated workers to  
> shared workers). Have other vendors started investigating what it  
> takes to implement SharedWorkers (and therefore MessagePorts in  
> workers)?
>
> Another approach for SharedWorkers would be to give them an implicit  
> MessagePort-esque API like dedicated Workers and not allow passing  
> in MessagePorts to postMessage(). This would mean that references to  
> workers can't really be passed around to other windows/workers, but  
> rather are kept per-origin. Dedicated workers could work as they do  
> now in Firefox/WebKit (with no MessagePorts). The SharedWorker  
> lifecycle could be significantly simplified such that a SharedWorker  
> is permissible as long as there's an active window under the same  
> origin (no more walking some distributed cross-thread dependency  
> graph).
> The thing we'd give up is the capabilities-based API that  
> MessagePorts provide, but I'd argue that the workaround is simple:  
> the creating window can just act as a proxy for the worker. IMO, the  
> implementation burden far outstrips the benefit of allowing direct  
> foreign access to workers. Literally 90% of the work on my plate for  
> SharedWorkers seems to derive from MessagePorts in one form or  
> another, which seems completely wrong.
> I'd like to hear your thoughts on this - are people open to removing  
> MessagePort support from Workers?
>
> -atw
>
>
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090507/8b749d5b/attachment-0001.htm>

From silviapfeiffer1 at gmail.com  Thu May  7 15:45:15 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 8 May 2009 08:45:15 +1000
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <p062408ffc628e0b05904@17.202.35.52>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com> 
	<Pine.LNX.4.62.0904300024400.10370@hixie.dreamhostps.com> 
	<2c0e02830904291828v34f4060frc11b0d761e543cea@mail.gmail.com> 
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com> 
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com> 
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com> 
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com> 
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52>
Message-ID: <2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com>

On Fri, May 8, 2009 at 5:04 AM, David Singer <singer at apple.com> wrote:
> At 8:39 ?+0200 5/05/09, K?i?tof ?elechovski wrote:
>>
>> If the author wants to show only a sample of a resource and not the full
>> resource, I think she does it on purpose. ?It is not clear why it is vital
>> for the viewer to have an _obvious_ way to view the whole resource
>> instead;
>> if it were the case, the author would provide for this.
>> IMHO,
>> Chris
>
> It depends critically on what you think the semantics of the fragment are.
> ?In HTML (the best analogy I can think of), the web page is not trimmed or
> edited in any way -- you are merely directed to one section of it.

There are critical differences between HTML and video, such that this
analogy has never worked well.


> I am also aware that browsers that don't implement fragments will also show
> the whole resource; ?so authors can't rely on he trimming.

This is not a standardisation problem, but an adoption problem. In a
transition phase there may be user agents that cannot deal with
fragments, but ultimately that will not be the case any more.


> Given both of these, I tend towards using # as a focus of attention; ?if
> trimming is desired, the server should probably do it (maybe using ?).

Just making sure I understand your suggestion correctly: I assume you
are saying that both # and ? would be able to only deliver the data
fragment that relates to the given specified temporal fragment, but
you are suggesting that by using "#" the user agent is being told to
present the context, while by using "?" the user agent would focus
attention on the fragment only. Is that what you're saying or am I
misunderstanding?

I'm asking because that has not been the consensus in the media
fragments WG as of today and if there is a discussion to be had, we
should take this back to the mf WG. It is an interesting view and has
actual technical implications - e.g. "#" could deliver the raw data
without requiring an adapted container since it could be assumed that
the core decoding environment is already set up - an adapted container
is however required in the "?" case since the "?" creates a new
resource.

Regards,
Silvia.

From simonp at opera.com  Thu May  7 15:58:21 2009
From: simonp at opera.com (Simon Pieters)
Date: Fri, 08 May 2009 00:58:21 +0200
Subject: [whatwg] Interaction of explicit and implicit sections (was: Re:
 Question on (new) header and hgroup)
In-Reply-To: <4A02FF7D.5070301@opera.com>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
Message-ID: <op.utk0rj2bidj3kv@simon-pieterss-macbook.local>

On Thu, 07 May 2009 17:34:21 +0200, James Graham <jgraham at opera.com> wrote:

> Bruce Lawson wrote:
>> I'm struggling to understand the reasons for <hgroup>: wouldn't one or
>> more h1..h6 elements wrapped in the same <header> imply just such a
>> grouping without the need for such an element?
>>  To illustrate my query, what is the difference between
>>  <header>
>> <h1>HTML 5</h1>
>> <h2>a new era of loveliness</h2>
>> <nav> ... </nav>
>> </header>
>>  and
>>  <header>
>> <hgroup>
>> <h1>HTML 5</h1>
>> <h2>a new era of loveliness</h2>
>> </hgroup>
>> <nav> ... </nav>
>> </header>
>
> <hgroup> affects the document structure, <header> does not. So if you  
> made an outline view of your document, the examples above would look  
> (with the addition of a <hx> element inside the nav with content  
> "Navigation") like
>
> +--HTML 5
>     +--A new era of loveliness
>        +--Navigation

Actually I believe it would be:

+--HTML 5
    +--A new era of loveliness
    +--Navigation


This surprised me when I used implicit sections and just wrapped <article>s around news items (which were <h3>s). I expected the outline to be like it was without the <article>:

+--Site heading
   +--Page heading
      +--News item

...but instead it became (according to your and gsnedders' outliners):

+--Site heading
   +--Page heading
   +--News item


Maybe the spec should change here to match people's expectations better?


> +--HTML 5 - a new era of loveliness
>     +--Navigation
>
> So, in the first example "A new era of loveliness" is a real section  
> heading and the navigation becomes a subsection of that section. In the  
> second example the <hgroup> element tells us that the <h1> and <h2>  
> elements form a heading-subheading pair and that the navigation is a  
> subsection of the section headed by this heading/subheading pair.
>
> Is that any clearer?

-- 
Simon Pieters
Opera Software



From simonp at opera.com  Thu May  7 16:12:01 2009
From: simonp at opera.com (Simon Pieters)
Date: Fri, 08 May 2009 01:12:01 +0200
Subject: [whatwg] Interaction of explicit and implicit sections (was:
 Re: Question on (new) header and hgroup)
In-Reply-To: <op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
Message-ID: <op.utk1ebunidj3kv@simon-pieterss-macbook.local>

On Fri, 08 May 2009 00:58:21 +0200, Simon Pieters <simonp at opera.com> wrote:

> Actually I believe it would be:
>
> +--HTML 5
>     +--A new era of loveliness
>     +--Navigation
>
>
> This surprised me when I used implicit sections and just wrapped  
> <article>s around news items (which were <h3>s). I expected the outline  
> to be like it was without the <article>:
>
> +--Site heading
>    +--Page heading
>       +--News item
>
> ...but instead it became (according to your and gsnedders' outliners):
>
> +--Site heading
>    +--Page heading
>    +--News item
>
>
> Maybe the spec should change here to match people's expectations better?

<zcorpan_> hmm i wonder how <hgroup> messes up implicit sections
<zcorpan_> maybe <hgroup> should have the same rank as its highest child h* element instead of always having rank 1
<zcorpan_> so you can do <h1>foo</h1><h2>bar</h2><hgroup><h3>baz</h3><h4>quux</h4></hgroup>
<zcorpan_> where baz is a subsection of bar
<Hixie> non-issue in practice, imho, <hgroup> is almost always going to be the first heading
<Hixie> and the rest of the time, people can use <section>
<Hixie> no?
<zcorpan_> would be nice if it worked as people expect when using implied sections
<Hixie> i guess
<Hixie> ...send mail :-)

-- 
Simon Pieters
Opera Software



From simonp at opera.com  Thu May  7 16:21:08 2009
From: simonp at opera.com (Simon Pieters)
Date: Fri, 08 May 2009 01:21:08 +0200
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
 audio/ video
In-Reply-To: <op.utkff1ldh8on37@bruce-pc>
References: <op.utkff1ldh8on37@bruce-pc>
Message-ID: <op.utk1titgidj3kv@simon-pieterss-macbook.local>

On Thu, 07 May 2009 17:17:51 +0200, Bruce Lawson <brucel at opera.com> wrote:

> Should autoplay be removed as an attribute of audio and video, precisely
> to remove such annoyance from people who rely on aural browsing? While
> there are video sites such as youTube that do play videos automatically,
> others such as vimeo don't. Is there an archive that lists the use-cases
> for autoplay and contrasts it with the "annoyance" and accessibility
> issues?.

Removing the attribute will not make pages stop autoplaying video. Instead they will use script to make videos autoplay, and then it becomes harder for the user to prevent videos from autoplaying. (You could have a pref in the UA to disable autoplay="".)

-- 
Simon Pieters
Opera Software



From singer at apple.com  Thu May  7 16:43:55 2009
From: singer at apple.com (David Singer)
Date: Thu, 7 May 2009 16:43:55 -0700
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<Pine.LNX.4.62.0904300024400.10370@hixie.dreamhostps.com>
	<2c0e02830904291828v34f4060frc11b0d761e543cea@mail.gmail.com>
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com>
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52>
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com>
Message-ID: <p06240804c62921c89a85@[17.202.35.52]>

At 8:45  +1000 8/05/09, Silvia Pfeiffer wrote:
>On Fri, May 8, 2009 at 5:04 AM, David Singer <singer at apple.com> wrote:
>>  At 8:39  +0200 5/05/09, K?i"tof ?elechovski wrote:
>>>
>>>  If the author wants to show only a sample of a resource and not the full
>>>  resource, I think she does it on purpose.  It is not clear why it is vital
>>>  for the viewer to have an _obvious_ way to view the whole resource
>>>  instead;
>>>  if it were the case, the author would provide for this.
>>>  IMHO,
>>>  Chris
>>
>>  It depends critically on what you think the semantics of the fragment are.
>>   In HTML (the best analogy I can think of), the web page is not trimmed or
>>  edited in any way -- you are merely directed to one section of it.
>
>There are critical differences between HTML and video, such that this
>analogy has never worked well.

could you elaborate?

>  > Given both of these, I tend towards using # as a focus of attention;  if
>>  trimming is desired, the server should probably do it (maybe using ?).
>
>Just making sure I understand your suggestion correctly: I assume you
>are saying that both # and ? would be able to only deliver the data
>fragment that relates to the given specified temporal fragment, but
>you are suggesting that by using "#" the user agent is being told to
>present the context, while by using "?" the user agent would focus
>attention on the fragment only. Is that what you're saying or am I
>misunderstanding?

Roughly, yes.  I am saying that

? -- the author of the URI has to know that the 
server he points the URI at supports the ? 
syntax.  The server essentially makes a resource 
using the query instructions, and delivers it to 
the UA.

# -- the UA focuses the user's attention on, and 
optimizes the network usage for that focus of, 
the indicated fragment.  It does this (a) 
visually, using whatever indicator it likes (we 
don't specify what the 'controller' looks like) 
and (b) using whatever network support it can get 
from the server (time-range, byte-range, or no 
support at all).

A reason I say this is that technically I believe 
that # is stripped by the UA;  we cannot then put 
a delivery requirement in, because that would 
apply to the server, which doesn't even get to 
see the # in all likelihood.



-- 
David Singer
Multimedia Standards, Apple Inc.

From conrad at metadecks.org  Thu May  7 16:49:36 2009
From: conrad at metadecks.org (Conrad Parker)
Date: Fri, 8 May 2009 08:49:36 +0900
Subject: [whatwg]  <video>/<audio> feedback
In-Reply-To: <dba6c0830905071647k3ba02974i3245ea7afc86db7b@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com>
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52>
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com>
	<dba6c0830905071647k3ba02974i3245ea7afc86db7b@mail.gmail.com>
Message-ID: <dba6c0830905071649l4e9eac6bk65ecf0fac4ee8eb1@mail.gmail.com>

2009/5/8 Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
> On Fri, May 8, 2009 at 5:04 AM, David Singer <singer at apple.com> wrote:
>> At 8:39 ?+0200 5/05/09, K?i?tof ?elechovski wrote:
>>>
>>> If the author wants to show only a sample of a resource and not the full
>>> resource, I think she does it on purpose. ?It is not clear why it is vital
>>> for the viewer to have an _obvious_ way to view the whole resource
>>> instead;
>>> if it were the case, the author would provide for this.
>>> IMHO,
>>> Chris
>>
>> It depends critically on what you think the semantics of the fragment are.
>> ?In HTML (the best analogy I can think of), the web page is not trimmed or
>> edited in any way -- you are merely directed to one section of it.
>
> There are critical differences between HTML and video, such that this
> analogy has never worked well.
>
>
>> I am also aware that browsers that don't implement fragments will also show
>> the whole resource; ?so authors can't rely on he trimming.
>
> This is not a standardisation problem, but an adoption problem. In a
> transition phase there may be user agents that cannot deal with
> fragments, but ultimately that will not be the case any more.
>
>
>> Given both of these, I tend towards using # as a focus of attention; ?if
>> trimming is desired, the server should probably do it (maybe using ?).
>
> Just making sure I understand your suggestion correctly: I assume you
> are saying that both # and ? would be able to only deliver the data
> fragment that relates to the given specified temporal fragment, but
> you are suggesting that by using "#" the user agent is being told to
> present the context, while by using "?" the user agent would focus
> attention on the fragment only. Is that what you're saying or am I
> misunderstanding?
>
> I'm asking because that has not been the consensus in the media
> fragments WG as of today and if there is a discussion to be had, we
> should take this back to the mf WG. It is an interesting view and has
> actual technical implications - e.g. "#" could deliver the raw data
> without requiring an adapted container since it could be assumed that
> the core decoding environment is already set up - an adapted container
> is however required in the "?" case since the "?" creates a new
> resource.

by an "adapted container" do you mean something like Ogg Skeleton, ie.
a video container that records the desired in/out points?

I agree with David's suggestion, as I understand it in the context of
HTML5: the UA may present the context of media segments that use '#'
and '?' syntax differently.

However I don't think this should change how we do data transport (ie.
the HTTP and the media container). I'd suggest that the scope that
should be covered in HTML5 is to suggest how much seek bar should be
displayed for the video. However when the user navigates on that seek
bar (by clicking on a random position), the UA may use whatever means
are appropriate for the media type [as suggested by the media
fragments wg] in order to retrieve that data.

Conrad.

From jackalmage at gmail.com  Thu May  7 17:03:38 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 7 May 2009 19:03:38 -0500
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <20090507203446.w2pd12cu800owoos@staff.opera.com>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<20090507173212.GB16047@stripey.com>
	<20090507203446.w2pd12cu800owoos@staff.opera.com>
Message-ID: <dd0fbad0905071703l1675a27chfa230f9ae78b3d07@mail.gmail.com>

On Thu, May 7, 2009 at 3:34 PM,  <jgraham at opera.com> wrote:
> Quoting Smylers <Smylers at stripey.com>:
>
>> James Graham writes:
>>
>>> Bruce Lawson wrote:
>>>
>>> > I'm struggling to understand the reasons for <hgroup>: wouldn't one
>>> > or more h1..h6 elements wrapped in the same <header> imply just such
>>> > a grouping without the need for such an element?
>>>
>>> <hgroup> affects the document structure, <header> does not.
>>
>> That explains _how_ they are different (as does the spec), but not _why_
>> it is like that.
>>
>> More specifically:
>>
>> * Are there significant cases where <header> needs _not_ to imply
>> ?<hgroup>? ?Consider wrapping an <hgroup> inside every <header>; how
>> ?many places has that broken the semantics? ?I could believe that most
>> ?of the cases where a pager header appropriately contains multiple
>> ?headings they are subtitles rather than subsections.
>
> The semantic that authors seem to want from an element named "header" is
> "All the top matter of my page before the main content". That could include
> headers, subheaders, navigation, asides (at least per the current definition
> of aside which I think is silly, but I digress) and almost anything else.
> Since the <header> can contain multiple distinct logical sections of the
> document, each with their own headers, it makes no sense to implicitly wrap
> its contents in <hgroup>.

James got it exactly.  I, as an author, want an element that fills a
role analogous to <article> in semantics, so I can trivially and
obviously mark up that the section is just a prelude to my main
content.

In my own pages, when I use a <div #header>, it usually contains, in
addition to the heading itself, some non-heading text and a nav or
two.  That latter bit especially would be inappropriate within an
(implicit) <hgroup>.

>> * Are there significant cases where <hgroup> will be useful outside of
>> ?<header>?
>>
>> ?<hgroup> exists to allow for subtitles and the like. ?It's fairly
>> ?common for documents to have these -- where it's likely there's use
>> ?for a <header> element anyway.
>>
>> ?It's much less common for a mere section of a document to warrant a
>> ?multi-part title; is that a case which is worth solving? ?If it is,
>> ?would it be problematic to force authors to use <header> there?
>
> It seems highly odd to have <header> perform a dual role where sometimes it
> means "section header" and sometimes it means "group of heading/subheading
> elements". Much more confusing than one element per role.

Section headers with subtitles lower down in the document hierarchy
occur with a decent frequency in my pages.  The document itself would
have a complex <header> (possibly with an <hgroup>), then the
<article> would have an <hgroup> of its own.

~TJ

From atwilson at google.com  Thu May  7 17:40:55 2009
From: atwilson at google.com (Drew Wilson)
Date: Thu, 7 May 2009 17:40:55 -0700
Subject: [whatwg] MessagePorts in Web Workers: implementation feedback
In-Reply-To: <DD94E15D-6977-48D8-9026-A5B3EBC33F3A@apple.com>
References: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
	<DD94E15D-6977-48D8-9026-A5B3EBC33F3A@apple.com>
Message-ID: <f965ae410905071740y4598d541vee3fe447bc18029b@mail.gmail.com>

Agreed that removing this requirement:

> User agents must act as if MessagePort<http://www.w3.org/TR/html5/comms.html#messageport>objects have a strong reference to their entangled
> MessagePort <http://www.w3.org/TR/html5/comms.html#messageport> object.
>
would make MessagePort implementation much easier, as it would remove the
need to track reachability across multiple threads. This requirement can get
tricky especially as both sides can be cloned, in-flight to a new owner,
etc.

My only concern is that removing this requirement introduces
non-deterministic behavior - if I have an entangled MessagePort and I
register an onmessage() handler with it, then drop my reference to it, after
which someone calls postMessage() on the entangled port, there's no way to
tell if my onmessage() handler will be invoked ; it entirely depends on
whether a GC happens first or not. That seems bad.

-atw

On Thu, May 7, 2009 at 3:28 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> I agree with Drew's assessment that MessagePorts in combination with
> Workers are extremely complicated to implement correctly, as currently
> specified. In fact, the design seems to push towards having lockable shared
> state, even though one potential advantage of the message passing design is
> to avoid locking and shared state.
>
> Besides removing MessagePorts as a way to communicate with workers, another
> possibility is simplifying the life cycle requirements. For example, getting
> rid of the keepalive rule, whereby both MessagePorts remain live so long as
> either is otherwise live, would remove the majority of the complexity. I
> don't think the slight convenience of that rule is worth the extra
> implementation cost.
>
> On May 7, 2009, at 1:39 PM, Drew Wilson wrote:
>
> Hi all,
>
> I've been hashing through a bunch of the design issues around using
> MessagePorts within Workers with IanH and the Chrome/WebKit teams and I
> wanted to follow up with the list with my progress.
>
> The problems we've encountered are all solveable, but I've been surprised
> at the amount of work involved in implementing worker MessagePorts (and the
> resulting implications that MessagePorts have on worker
> lifecycles/reachability). My concern is that the amount of work to implement
> MessagePorts within Worker context may be so high that it will prevent
> vendors from implementing the SharedWorker API. Have other implementers
> started working on this part of the spec yet?
>
> Let me quickly run down some of the implementation issues I've run into -
> some of these may be WebKit/Chrome specific, but other browsers may run into
> some of them as well:
>
> 1) MessagePort reachability is challenging in the context of separate
> Worker heaps
>
> In WebKit, each worker has its own heap (in Chrome, they will have their
> own process as well). The spec reads:
>
> User agents must act as if MessagePort<http://www.w3.org/TR/html5/comms.html#messageport>objects have a strong reference to their entangled
> MessagePort <http://www.w3.org/TR/html5/comms.html#messageport> object.
>
> Thus, a message port can be received, given an event listener, and then
> forgotten, and so long as that event listener could receive a message, the
> channel will be maintained.
>
> Of course, if this was to occur on both sides of the channel, then both
> ports would be garbage collected, since they would not be reachable from
> live code, despite having a strong reference to each other.
>
> Furthermore, a MessagePort<http://www.w3.org/TR/html5/comms.html#messageport>object must not be garbage collected while there exists a message in a task
> queue <http://www.w3.org/TR/html5/browsers.html#task-queue> that is to be
> dispatched on that MessagePort<http://www.w3.org/TR/html5/comms.html#messageport>object, or while the
> MessagePort <http://www.w3.org/TR/html5/comms.html#messageport> object's port
> message queue <http://www.w3.org/TR/html5/comms.html#port-message-queue>is open and there exists a
> message <http://www.w3.org/TR/html5/comms.html#event-message> event in
> that queue.
>
> The end result of this is the need to track some common state across an
> entangled MessagePort pair such as: number of outstanding messages, open
> state of each end, and number of active references to each port (zero or
> non-zero). Turns out this last bit will require adding new hooks to the
> JavaScriptCore garbage collector to detect transitioning between 1 and 0
> references without actually freeing the object - not that difficult, but
> possibly something that other implementers should keep in mind.
>
> 2) MessagePorts dramatically change the worker lifecycle
>
> Having MessagePorts in worker context means that Workers can outlive their
> parent window(s) - I can create a worker, pass off an entangled MessagePort
> to another window (say, to a different domain), then close the original
> window, and the worker should stay alive. In the case of WebKit, this causes
> some problems for things like worker-initiated network requests - if workers
> can continue to run even though there are no open windows for that origin,
> then it becomes problematic to perform network requests (part of this is due
> to the architecture of WebKit which requires proxying network requests to
> window context, but part of this is just a general problem of "how do you
> handle things like HTTP Auth when there are no open windows for that
> origin?")
>
> Finally, the spec defines a fairly broad definition of what makes a worker
> reachable - here's an excerpt from my WebKit Shared Worker design doc, where
> I summarize the spec (possibly incorrectly - feel free to correct any
> misconceptions):
>
>> PermissibleThe spec specifies that a worker is *permissible* based on
>> whether it has a reachable MessagePort that has been entangled *at some
>> point in the past* with an active window (or with a worker who is itself
>> permissible). Basically, if a worker has *ever* been entangled with an
>> active window, or if it's ever been entangled with a worker who is itself
>> permissible (i.e. it's associated with an active window via a chain of
>> workers that have been entangled at some point in the past) then it's
>> permissible.
>>
>> The reason why the "at some point in the past" language is present is to
>> allow a page to create a fire-and-forget worker (for example, a worker that
>> does a set of long network operations) without having to keep a reference to
>> that worker around.
>>
>> Once the referent windows close, the worker should also close, as being
>> permissible is a necessary (but not sufficient) criteria for being
>> runnable.
>> Active neededA permissible worker is *active needed* if:
>>
>>    1. it has pending timers/network requests/DB activity, or
>>    2. it is currently entangled with an active window, or another active
>>    needed worker.
>>
>>
>> The intent behind #1 is to enable fire-and-forget workers that don't exit
>> until they are idle. The intent behind #2 is that an idle worker shouldn't
>> exit as long as it's reachable by an active window (possibly chained through
>> other workers).
>>
> The end result is that for each worker we need to keep track of a big list
> of every window it's ever been entangled with. As workers become entangled
> with other workers, they each inherit the list of entangled windows from the
> other worker. As windows become inactive, we then walk the lists of every
> worker to remove references to the window and properly shutdown the worker
> as appropriate. All of this with the appropriate cross-thread
> synchronization, of course :)
>
> Likewise, determining when a worker is active needed requires tracking a
> graph of entangled message ports, and walking that graph to determine
> whether a given worker is reachable by any active window. Typically this is
> only needed when either a window closes, or when a worker goes idle.
>
> Again, none of these issues individually are insurmountable, but in total
> they add up to a significant amount of work for what should be a fairly
> incremental improvement (going from dedicated workers to shared workers).
> Have other vendors started investigating what it takes to implement
> SharedWorkers (and therefore MessagePorts in workers)?
>
> Another approach for SharedWorkers would be to give them an implicit
> MessagePort-esque API like dedicated Workers and not allow passing in
> MessagePorts to postMessage(). This would mean that references to workers
> can't really be passed around to other windows/workers, but rather are kept
> per-origin. Dedicated workers could work as they do now in Firefox/WebKit
> (with no MessagePorts). The SharedWorker lifecycle could be significantly
> simplified such that a SharedWorker is permissible as long as there's an
> active window under the same origin (no more walking some distributed
> cross-thread dependency graph).
>
> The thing we'd give up is the capabilities-based API that MessagePorts
> provide, but I'd argue that the workaround is simple: the creating window
> can just act as a proxy for the worker. IMO, the implementation burden far
> outstrips the benefit of allowing direct foreign access to workers.
> Literally 90% of the work on my plate for SharedWorkers seems to derive from
> MessagePorts in one form or another, which seems completely wrong.
>
> I'd like to hear your thoughts on this - are people open to removing
> MessagePort support from Workers?
>
> -atw
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090507/903512b3/attachment.htm>

From dgerard at gmail.com  Thu May  7 17:51:19 2009
From: dgerard at gmail.com (David Gerard)
Date: Fri, 8 May 2009 01:51:19 +0100
Subject: [whatwg] Suitable video codec
Message-ID: <fbad4e140905071751o4a588589s2f2b5e19f8d437cf@mail.gmail.com>

H.264 was advocated here for the <video> element as higher quality
than competing codecs such as Theora could ever manage.

The Thusnelda coder is outdoing H.,264 in current tests:

http://web.mit.edu/xiphmont/Public/theora/demo7.html

This is of course developmental work. I'm sure the advocates of H. 264
can also tune its encoders to keep up, and not make Theora the only
reasonable candidate for the <video> element.


- d.

From pkasting at google.com  Thu May  7 17:57:01 2009
From: pkasting at google.com (Peter Kasting)
Date: Thu, 7 May 2009 17:57:01 -0700
Subject: [whatwg] Suitable video codec
In-Reply-To: <fbad4e140905071751o4a588589s2f2b5e19f8d437cf@mail.gmail.com>
References: <fbad4e140905071751o4a588589s2f2b5e19f8d437cf@mail.gmail.com>
Message-ID: <d62cf1d10905071757p5cc8639gb67ed2ba8e5382da@mail.gmail.com>

On Thu, May 7, 2009 at 5:51 PM, David Gerard <dgerard at gmail.com> wrote:

> The Thusnelda coder is outdoing H.,264 in current tests:
>

Be careful how glowing you make this sound -- this is on a particular
objective test (not subjective, and thus perversely less accurate in
reflecting "how good do people think this looks"), and only based on one
video clip.

That's not to diminish the Theora work at all -- the results are also
subjectively better IMO, and Theora getting better is a win no matter what.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090507/149e1444/attachment-0001.htm>

From jackalmage at gmail.com  Thu May  7 18:06:19 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 7 May 2009 20:06:19 -0500
Subject: [whatwg] Interaction of explicit and implicit sections (was:
	Re: Question on (new) header and hgroup)
In-Reply-To: <op.utk1ebunidj3kv@simon-pieterss-macbook.local>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
	<op.utk1ebunidj3kv@simon-pieterss-macbook.local>
Message-ID: <dd0fbad0905071806p3b7faeb5h90f8daa9f525fc7e@mail.gmail.com>

On Thu, May 7, 2009 at 6:12 PM, Simon Pieters <simonp at opera.com> wrote:
> <zcorpan_> hmm i wonder how <hgroup> messes up implicit sections
> <zcorpan_> maybe <hgroup> should have the same rank as its highest child h*
> element instead of always having rank 1
> <zcorpan_> so you can do
> <h1>foo</h1><h2>bar</h2><hgroup><h3>baz</h3><h4>quux</h4></hgroup>
> <zcorpan_> where baz is a subsection of bar
> <Hixie> non-issue in practice, imho, <hgroup> is almost always going to be
> the first heading
> <Hixie> and the rest of the time, people can use <section>
> <Hixie> no?
> <zcorpan_> would be nice if it worked as people expect when using implied
> sections
> <Hixie> i guess
> <Hixie> ...send mail :-)

The rank-change feels like magic and is absolutely certain to be
overlooked in practice.  What's worse, *because* this situation is
rare in practice (I agree here with Hixie), it'll be unlikely that
most authors even realize they're committing a mistake.  When I write
an <h3> I want it to act like an <h3>, no matter whether it's being
grouped with an <h4> or not.  If I wanted a rank-1 header, I can put
an <h1> in the <hgroup> instead.

In short, the current rank-change is likely to produce bad behavior in
the common case (well, the common rare case, as opposed to the rare
rare case), while inheriting rank from children produces good behavior
in this case.  Both behaviors have workarounds, but the inheriting
case's workaround is more 'local' and obvious - you just set the rank
of the enclosed heading to what you want; the workaround for the
magic-rank-1 case makes you to partially abandon the implicit
sectioning algorithm, and requires an end tag far removed from the
place where the trouble happened.

So, I support zcorpan's suggestion.

~TJ

~TJ

From jackalmage at gmail.com  Thu May  7 18:10:20 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 7 May 2009 20:10:20 -0500
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
	audio/ video
In-Reply-To: <op.utkff1ldh8on37@bruce-pc>
References: <op.utkff1ldh8on37@bruce-pc>
Message-ID: <dd0fbad0905071810w23c1013ajd512044cb4831f0b@mail.gmail.com>

On Thu, May 7, 2009 at 10:17 AM, Bruce Lawson <brucel at opera.com> wrote:
> This may already be in the spec, but I couldn't find it.
>
> I think the spec should explicity require UAs to provide a mehanism to
> mute audio and to pause video, even if the controls attribute is not set.
>
> This will be of great benefit to screenreader users, as well as to people
> who work in shared environments and who may not be expecting noise.
>
> (There is a precedent for worrying about "mere annoyance": "User agents
> should not provide a public API to cause videos to be shown full-screen. A
> script, combined with a carefully crafted video file, could trick the user
> into thinking a system-modal dialog had been shown, and prompt the user
> for a password. There is also the danger of "mere" annoyance, with pages
> launching full-screen videos when links are clicked or pages navigated.")
>
> Should autoplay be removed as an attribute of audio and video, precisely
> to remove such annoyance from people who rely on aural browsing? While
> there are video sites such as youTube that do play videos automatically,
> others such as vimeo don't. Is there an archive that lists the use-cases
> for autoplay and contrasts it with the "annoyance" and accessibility
> issues?.
>
> (see
> http://www.brucelawson.co.uk/2009/accessibility-of-html5-video-and-audio-elements/)

I don't see why this should be a browser requirement.  UAs are
*allowed* to provide such a facility to their users, so if your UA
doesn't, complain until they do!

~TJ

From msporny at digitalbazaar.com  Thu May  7 19:40:49 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu, 07 May 2009 22:40:49 -0400
Subject: [whatwg] Micro-data/Microformats/RDFa Interoperability
	Requirement
In-Reply-To: <Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>
References: <4A0104C2.8080009@digitalbazaar.com>	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>	<4A02F6AE.1000602@digitalbazaar.com>
	<Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>
Message-ID: <4A039BB1.4050703@digitalbazaar.com>

Ian Hickson wrote:
> On Thu, 7 May 2009, Manu Sporny wrote:
>> So, this argument isn't "Don't use @class at all", but rather "Don't 
>> create ambiguity in @class where there is none currently."
> 
> I agree that if HTML5 re-uses vocabulary "root" terms from Microformats, 
> it should either not use class="", or should do so in a way that does not 
> cause existing consumers of Microformats to treat existing content in a 
> way that is not compliant with HTML5.

Good, there's agreement there, then. :)

>> Not re-defining things to mean something different than the Microformats
>> community has already defined should be a design requirement.
> 
> That requirement has been broken for some time, because the definitions of 
> rel="license" and rel="tag" in HTML5 differ from those on the Microformats 
> wiki. (The definitions in HTML5 are closer to what existing 
> implementations and content rely on, though, so I don't think it violates 
> the requirement to "not cause existing consumers of Microformats to treat 
> existing content in a way that is not compliant with HTML5".)

That's certainly not what the WHATWG blog stated just 20 days ago for
rel="license":

http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-license
http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-tag

and the spec doesn't seem to clearly outline the difference in
definition either (at least, that's not my reading of the spec):

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-license
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-tag

Am I looking at the wrong spec? How can the definitions of rel="license"
and rel="tag" be different when Mark Pilgrim has stated very clearly
that they were standardized in the Microformats community and the HTML5
spec makes no mention of any sort of difference in definition from HTML5
and Microformats?

>>> and RDFa because any use of the "rel" attribute can do the same.
>> No, not /any/ use - /specific/ uses of rel, and then only if the HTML5 
>> micro-data solution does something that is counter to how RDFa uses the 
>> attribute or the value.
> 
> Actually as far as I can tell, it really is any use.

No it isn't, more below. :)

> The RDFa specification is very confusing to me (e.g. I don't understand 
> how the normative processing model is separate from the section "RDFa 
> Processing in detail"), so I may be misinterpreting things, but as far as 
> I can tell:
> 
>   <html xmlns="http://www.w3.org/1999/xhtml">
>    <head>
>     <base href="http://example.com/"/>
>     <link about="http://example.net/"
>           rel="dc.author" 
>           href="http://a.example.org/"/>
>    ...
> 
> ...will result in the following triple:
> 
>    <http://example.net/> <http://example.com/dc.author> <http://a.example.org/> .

Two corrections:

The first is that an RDFa processor would not generate this triple. It
wouldn't know what "dc.author" meant. As a general design principle,
RDFa ignores all values it doesn't know anything about. The processor
would detect the subject being set via the @about, then it would go
searching for a known CURIE value or (in XHTML1.1+RDFa) a known
@rel/@rev reserved attribute value (such as "next", "stylesheet", etc.).
Since "dc.author" is neither a known CURIE value or a known reserved
word, it would exit the LINK element without creating any triples.

The second is that you are assuming that @rel/@rev reserved attribute
values are the same for all XML and non-XML family languages - they
aren't. Reserved words such as "next" and "prev" can be defined per
language - or, none can be defined... it's up to the language adopting
RDFa to define those values. For a list of the current values, you can see:

http://www.w3.org/TR/rdfa-syntax/#relValues

>> The most important issue with RDFa is not re-using attributes already 
>> defined by XHTML1.1+RDFa without them having the exact same use in 
>> HTML5. Attributes like @about, @property, @datatype, @resource, @content 
>> and @typeof.
> 
> Given that HTML4 already has five of RDFa's 10 attributes (not counting 
> prefix declaration mechanisms), and defines processing for these that 
> conflicts with RDFa's (e.g. as described below), it's not clear to me what 
> benefit there would be in completely avoiding the other five attributes if 
> there was a need to use such an attribute.

Note that I didn't say "completely avoid" attributes... I said "re-using
attributes already defined by XHTML1.1+RDFa without them having the
exact same use in HTML5". At this point, I don't see any conflict
between XHTML1.1+RDFa and HTML5.

I was asking for semantic equivalence when adopting attributes, not
complete avoidance.

> For example, it would be somewhat presumptious of RDFa to prevent any 
> future version of HTML from being able to use the word "resource" as an 
> attribute name. What if we want to extend the forms features to have an 
> XForms "datatype" compatibility layer; why should we not be able to use 
> the "datatype" and "typeof" attributes?

As long as their legacy nature was preserved, and those uses didn't
create ambiguity in RDFa processors and semantic equivalence was
ensured, I don't see why they shouldn't be re-used.

> Surely this is what namespaces were intended for.

Uhh, what sort of namespaces are we talking about here? xmlns-style,
namespaces? I thought those were on their way out in HTML5? Henri seems
to hate them with a passion.

Are we talking about the implied HTML5 document namespace? If so, in a
world where there is no RDFa in HTML5, I'm guessing that web developers
are going to shove XHTML1.1+RDFa into HTML5 documents anyway, and at
that point the document namespace isn't going to mean much - which is
one of the reasons that I'm so concerned about HTML5 re-defining
attributes and attribute values.

>>> Similarly, the rules for handling CURIEs in RDFa, especially in 
>>> rel="", are already incompatible with HTML4 and HTML5 rules. 

No, they are not, as explained above in the @rel reserved attribute
values discussion.

>>> For 
>>> example, the way that "n:next" and "next" can end up being equivalent 
>>> in RDFa processors despite being different per HTML rules (assuming an 
>>> "n" namespace is appropriately declared).
>> If they end up being equivalent in RDFa, the RDFa author did so 
>> explicitly when declaring the 'n' prefix to the default prefix mapping 
>> and we should not second-guess the authors intentions.
> 
> My only point is that it is not compatible with HTML4 and HTML5, because 
> they end up with different results in the same situation (one can treat 
> two different values as the same, while the other can treat two different 
> values as different).

It is only not compatible with HTML5 if this community chooses for it to
not be compatible with HTML5. Do you agree or disagree that we shouldn't
second guess the authors intentions if they go out of their way to
declare a mapping for 'n'?

> Another example would be the following:
> 
>   <html xmlns="http://www.w3.org/1999/xhtml">
>    <head about="">
>     <link rel="stylesheet" href="...">
>     <link rel="STYLESHEET" href="...">
>     ...
> 
> ...which would be treated as two different triples in an RDFa processor, 
> but treated as two identical imports according to an HTML4/5 processor.

Hmmm, this is a good technical point, but may be a bug in the spec. My
processor doesn't do a case-insensitive match, but perhaps the RDFa
processor should do a case-insensitive match for reserved words. I know
we discussed this at one point, but can't remember what we decided. I'll
post something about this to the RDFa mailing list to see if anyone
there can remember.

If we do a case-insensitive match, which we probably should, the point
still stands - the semantic meaning of the statements are equivalent.

> Another example would be:
> 
>   <html xmlns="http://www.w3.org/1999/xhtml">
>    <head about="">
>     <link rel="stylesheet alternate next" href="...">
>     ...
> 
> ...which in RDFa would cause the following triples to be created:
> 
>    <> <http://www.w3.org/1999/xhtml/vocab#stylesheet> <...> .
>    <> <http://www.w3.org/1999/xhtml/vocab#alternate> <...> .
>    <> <http://www.w3.org/1999/xhtml/vocab#next> <...> .
> 
> ...but according to HTML4/5, is really only two relations (an alternativee 
> stylesheet and the next document).

That's a very strained argument. The contents of @rel are supposed to be
LinkTypes, which are space-separated keywords:

http://www.w3.org/TR/html4/types.html#type-links

It just so happens that when you use "alternate" and "stylesheet"
together that the browser is supposed to recognize that an alternate
stylesheet exists.

I've always thought that this was an abuse of the rel attribute - there
should have been an "alternate-stylesheet" LinkType, but what's done is
done.

AFAIK, there is nothing in the HTML4 or HTML5 spec that states that for
rel="alternate stylesheet" that there is only one relation. There are
three relationships because there are three separate LinkTypes  specified.

>>> I don't think there's much that can be done about this (this isn't 
>>> something that we can change HTML5 rules for; browser vendors would 
>>> not accept having to resolve QNames in rel="" attributes as part of 
>>> processing, for one).
>>
>> This has been explained many[2] times[3] now[4], CURIEs are not QNames. 
>> If you have an issue with CURIEs, please state the exact issue that you 
>> have with CURIEs and don't use a false analogy.
> 
> Browser vendors would not accept having to resolve prefixes in attribute 
> values as part of processing link relations.

Why not? They're already required to resolve values using an external
document for CSS when processing all @class attribute. That is a far
steeper requirement than being required to use an internal mapping
mechanism when processing a few attributes.

> (What's the difference between mapping to a full URI and mapping to a 
> namespace,local pair? 

Not much, but a QName is technically much more than that - which is why
I take issue with members of this community continuing to assert that
CURIEs and QNames are equivalent. A QName can be used anywhere in an XML
document, except for in attributes:

http://www.w3.org/TR/REC-xml-names/#ns-qualnames

The namespace and local part are required to be validated.

A CURIE can only be used in very specific attributes defined by a
language (such as XHTML1.1+RDFa or HTML5) and are not required to be
validated:

http://www.w3.org/TR/curie/#sec_1.1.

They differ in:

- The location that they can be used.
- Whether or not they are required to be validated.

The only similarity they have is that they can be expanded to full URIs.

Saying that QNames and CURIEs are equivalent is like saying XHTML2 and
HTML5 are equivalent because they both use <a href="...">. Just because
two technologies have one thing in common doesn't make them equivalent.

> The problem with QNames in attributes is that they 
> require the attribute processor to have information from the namespace 
> processor, and as far as I can tell this continues to exist in RDFa.)

If that's really the problem, why don't you just have a prefix processor
that the attribute processor relies on and drop the namespace processor
entirely?

Why is it such a big deal for the attribute processor to have a
reference to the prefix processor?

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From msporny at digitalbazaar.com  Thu May  7 20:03:30 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu, 07 May 2009 23:03:30 -0400
Subject: [whatwg] Why CURIE prefixes? (was: Re: Micro-data/Microformats/RDFa
 InteroperabilityRequirement)
In-Reply-To: <AF8FBC538C824220A89A16268B0E6495@POCZTOWIEC>
References: <4A0104C2.8080009@digitalbazaar.com><Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>	<4A02F6AE.1000602@digitalbazaar.com>
	<AF8FBC538C824220A89A16268B0E6495@POCZTOWIEC>
Message-ID: <4A03A102.7060109@digitalbazaar.com>

Kristof Zelechovski wrote:
> The main problem with prefixes is that the meaning of prefixes is not
> preserved when a code fragment is pasted elsewhere, so that prefixed names
> can end up meaningless or having an entirely different meaning from what the
> author had intended. 

The problem isn't with prefixes, it is with any mechanism that relies on
a remote declaration mechanism. For example:

1. If you cut/paste HTML that uses CSS extensively without copying the
stylesheet information or the necessary outer <div>/<span>s, the markup
will have an entirely different rendering.

2. If you cut/paste half of a table, or half of a list, it will have an
entirely different meaning than the originating markup.

3. If you cut/paste Javascript code without importing the proper base
libraries, it will have an entirely different effect than the original code.

These are problems that we have in HTML4 and will continue to have in
HTML5. However, the fact that these problems exist and will continue to
exist didn't stop us from adopting the technologies anyway. It is the
nature of the solution for the requirement.

The reason that we have prefixes is because the ability to extend
vocabularies in a decentralized manner was a requirement when creating
RDFa (as it is now for micro-data in HTML5). The alternatives are:

1. Using full URIs to express predicates (which is very error prone, but
is something that we're still exploring), or
2. Hard coding predicate values via a centralized mechanism, which is
very restrictive and not scalable.

If anybody has any other ideas on how to approach this requirement, it
would be great to hear them. :)

> A similar problem arises with DTD entities (indeed,
> DTD entities could be used instead of prefixes).

We looked at that - many people seem to hate DTDs these days, and it
would require a new DTD for every new vocabulary defined (which could be
in the thousands).

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From bijumaillist at gmail.com  Thu May  7 20:34:38 2009
From: bijumaillist at gmail.com (Biju)
Date: Thu, 7 May 2009 23:34:38 -0400
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<c2e346f90904062111t7429143ande88c37c654b7bb9@mail.gmail.com>
	<2A9F6E32-1680-47E9-98B8-C7DCA6B484B1@apple.com>
	<Pine.LNX.4.62.0904300024400.10370@hixie.dreamhostps.com>
	<2c0e02830904291828v34f4060frc11b0d761e543cea@mail.gmail.com>
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com>
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
Message-ID: <4a27dd80905072034q6b008038s61f79e8ef8de227c@mail.gmail.com>

just another thought

On Tue, May 5, 2009 at 12:46 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>
> 2. Wanting to only show a small part of a longer video. For example in
> the video containing a movie, it would be possible to link to a
> particular scene, with a given start and end time.
>

isnt it this similar to CSS img {clip:rect(<top>, <right>, <bottom>, <left>);}
ie, clipping for time range

Just want to share a site already implemented video fragments
http://pad.ma/Vgpfnjp8/info
to play video move mouse over the image, find a slide you wish to start,
then click to select that as starting frame.
you will goto a page where there is video the one at left,
click the play button on the control provided.

the bar at bottom shows the time scale

two images at right show start and end for looping a segment.

From anders.rundgren at telia.com  Thu May  7 22:52:31 2009
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Fri, 8 May 2009 07:52:31 +0200
Subject: [whatwg] <keygen> - competitor update
Message-ID: <CD403F81D65649859D1116F29ABBB98C@AndersPC>

I don't know how far you have gotten with <keygen>.
You may be interested in knowing what the "competition" is doing :-)

>From a provisioning point of view smart cards have a long way to go.  >From the SKS paper:

     "even if you buy a $100 card; it still doesn't enable an on-line issuer 
      to verify that keys were actually created in the card!"

Since on-line provisioning is the norm for Information Cards, mobile device keys, etc, I have added something which I call "Air-tight Provisioning" to the USB memory stick design I'm working with.

Air-tight provisioning, the basics:
http://webpki.org/papers/keygen2/secure-key-store.pdf
If you take a look at "Dual-use Device IDs", you will find a novel (?) use of device certificates.

Air-tight provisioning, core facility:
http://webpki.org/papers/keygen2/session-key-establishment--security-element-2-server.pdf

The most important conclusion drawn so far is that provisioning must be an integral part of a cryptographic sub-system, otherwise it will be full with quirks, security holes, and interoperability issues.  A good thing is that nothing prevents designs like the above to be used with conventional cryptographic APIs for the "execution" part of a key's life; it is "only" the provisioning and management operations that need a major overhaul.

Is this standardization?  Not really.   After talking to literally hundreds of people, it is fairly clear that standardization takes too long time, is riddled by politics, and very often lacks real-world testing.  XKMS is an example of a standard that failed on the market in spite of being supported by all he big guns.  Open design, free code, and a community seems to be the most realistic way ahead.

Anders Rundgren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090508/1368489d/attachment.htm>

From simonp at opera.com  Thu May  7 23:46:58 2009
From: simonp at opera.com (Simon Pieters)
Date: Fri, 08 May 2009 08:46:58 +0200
Subject: [whatwg] Interaction of explicit and implicit sections (was:
 Re: Question on (new) header and hgroup)
In-Reply-To: <op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
Message-ID: <op.utlmgkuuidj3kv@simon-pieterss-macbook.local>

On Fri, 08 May 2009 00:58:21 +0200, Simon Pieters <simonp at opera.com> wrote:

> Actually I believe it would be:
>
> +--HTML 5
>     +--A new era of loveliness
>     +--Navigation
>
>
> This surprised me when I used implicit sections and just wrapped  
> <article>s around news items (which were <h3>s). I expected the outline  
> to be like it was without the <article>:
>
> +--Site heading
>    +--Page heading
>       +--News item
>
> ...but instead it became (according to your and gsnedders' outliners):
>
> +--Site heading
>    +--Page heading
>    +--News item
>
>
> Maybe the spec should change here to match people's expectations better?

OTOH, if we do this, then the default style sheet (the x x x h1 stuff) will be wrong. I guess the proper solution to that is to introduce :heading-level(n) that uses the outline algorithm. (But how to select and style subtitles in hgroup though?)

-- 
Simon Pieters
Opera Software



From Smylers at stripey.com  Fri May  8 03:42:19 2009
From: Smylers at stripey.com (Smylers)
Date: Fri, 8 May 2009 11:42:19 +0100
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <dd0fbad0905071703l1675a27chfa230f9ae78b3d07@mail.gmail.com>
	<20090507203446.w2pd12cu800owoos@staff.opera.com>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<20090507173212.GB16047@stripey.com>
	<20090507203446.w2pd12cu800owoos@staff.opera.com>
	<dd0fbad0905071703l1675a27chfa230f9ae78b3d07@mail.gmail.com>
	<op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<20090507173212.GB16047@stripey.com>
	<20090507203446.w2pd12cu800owoos@staff.opera.com>
Message-ID: <20090508104219.GA29592@stripey.com>

jgraham at opera.com writes:

> Quoting Smylers <Smylers at stripey.com> :
>
> > James Graham writes:
> >
> > > <hgroup> affects the document structure, <header> does not.
> >
> > That explains _how_ they are different (as does the spec), but not
> > _why_ it is like that.
> >
> > More specifically:
> >
> > * Are there significant cases where <header> needs _not_ to imply
> >   <hgroup> ?  Consider wrapping an <hgroup> inside every <header> ;
> >   how many places has that broken the semantics?  I could believe
> >   that most of the cases where a pager header appropriately contains
> >   multiple headings they are subtitles rather than subsections.
>
> The semantic that authors seem to want from an element named "header"
> is "All the top matter of my page before the main content". That could
> include headers, subheaders, navigation, asides and almost anything
> else.

It could.  But most of the above have no effect on the outline
algorithm.  In practice, how often do current <div class="header">
sections contain headers of multiple sections, without those nested
sections being separately wrapped in their own <div>-s (or similar,
which could become <section> or whatever's appropriate in HTML 5)?

> Since the <header> can contain multiple distinct logical sections of
> the document, each with their own headers, it makes no sense to
> implicitly wrap its contents in <hgroup>.

You're right.  What I was really thinking of is something closer to:
inside <header> if any <hx> elements are encountered before any nested
sectioning elements then treat all the <hx> elements as being a single
heading.

So <header> could still contain <section>-s, with their own headings.
And a <header> with no <hx> elements wouldn't create an empty entry in
the outline.

> > * Given the newness and nuance of <header> and <hgroup> and the
> >   distinction between them, it's likely that some authors will
> >   confuse them.  Given that <hgroup> doesn't appear to do anything
> >   on the page (it's similar to invisible meta-data), it's likely
> >   that some authors will omit it[*1] when it's needed to convey the
> >   semantics they intend.
>
> Yes, that is possible. The thinking behind the change (or, at least,
> part of my reason for proposing it) was that it is less harmful if
> authors omit something where it would be useful than that they use it
> incorrectly in such a way that tools which follow the spec would be
> broken from the point of view of end users.

That's a good point.

> In particular the old formulation of <header> would have caused the
> <h2> element to be omitted from the outline in cases like <header>
> <h1> My Blog</h1> <nav> <h2> Navigation</h2> </nav> </header> , which
> would be confusing for users.

Indeed.  What I intended to raise for consideration (and hopefully now
have done) is that <header> would not merge the above, because <nav>
starts a new section inside <header>.  Consider a similar example:

  <header>
    <h1>My Blog</h1> <h2>Ramblings of an internet nobody</h2>
    <nav><h2>Navigation</h2> ... </nav>
  </header>

The spec currently has both the <h2>-s as subsections.  The alternative
I was thinking of would treat the <h1> and first <h2> as being a single
heading (of the entire document), but keep the second <h2> (as the
heading of the navigation).

> On he other hand in the current formulation of the spec, the most
> likely error (omitting <hgroup> ) only has the effect that that
> outline heirachy is slightly wrong, with the subheader appearing as an
> actual header; it does not lead to data loss. This seems like a much
> better failure mode.

That's true.  But if the number of failures can be minimized, it matters
less what the failure mode is.

My concern is that with <hgroup> being so esoteric, combined with its
effect being largely invisible, it will hardly be used and therefore
possibly not worth adding to HTML 5.

Authors don't have a good track record on accurately adding invisible
metadata.  If we can algorithmically get it right in most cases, while
leaving a way for careful authors to explicitly override it if
necessary, that may be better overall.

> > * Are there significant cases where <hgroup> will be useful outside
> >   of <header> ?
> >
> >  <hgroup> exists to allow for subtitles and the like.  It's fairly
> >  common for documents to have these -- where it's likely there's use
> >  for a <header> element anyway.
> >
> >  It's much less common for a mere section of a document to warrant a
> >  multi-part title; is that a case which is worth solving?  If it is,
> >  would it be problematic to force authors to use <header> there?
>
> It seems highly odd to have <header> perform a dual role where
> sometimes it means "section header" and sometimes it means "group of
> heading/subheading elements". Much more confusing than one element per
> role.

I think the two concepts are sufficiently overlapping that it isn't
really a dual role.  <header> could mean 'section (or document) header'
-- it would be used when a section's header consists of more than just a
single <hx> element.  Whether those elements are because of multi-part
titles or search boxes or whatever is a distinction that authors would
not need to think about.

Tab Atkins Jr. writes:

> Section headers with subtitles lower down in the document hierarchy
> occur with a decent frequency in my pages.  The document itself would
> have a complex <header> (possibly with an <hgroup> ), then the
> <article> would have an <hgroup> of its own.

But if the first <hgroup> were omitted and the second <hgroup> were
written as <header>, and the document conveyed exactly the same
semantics, would that actually be worse?

Smylers

From mjs at apple.com  Fri May  8 05:52:17 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 08 May 2009 05:52:17 -0700
Subject: [whatwg] MessagePorts in Web Workers: implementation feedback
In-Reply-To: <f965ae410905071740y4598d541vee3fe447bc18029b@mail.gmail.com>
References: <f965ae410905071339w282160dehd0f345902644795e@mail.gmail.com>
	<DD94E15D-6977-48D8-9026-A5B3EBC33F3A@apple.com>
	<f965ae410905071740y4598d541vee3fe447bc18029b@mail.gmail.com>
Message-ID: <3CFBB1C5-FECC-4951-AE96-ED9FD38D841F@apple.com>


On May 7, 2009, at 5:40 PM, Drew Wilson wrote:

> Agreed that removing this requirement:
> User agents must act as if MessagePort objects have a strong  
> reference to their entangled MessagePort object.
>
> would make MessagePort implementation much easier, as it would  
> remove the need to track reachability across multiple threads. This  
> requirement can get tricky especially as both sides can be cloned,  
> in-flight to a new owner, etc.
>
> My only concern is that removing this requirement introduces non- 
> deterministic behavior - if I have an entangled MessagePort and I  
> register an onmessage() handler with it, then drop my reference to  
> it, after which someone calls postMessage() on the entangled port,  
> there's no way to tell if my onmessage() handler will be invoked ;  
> it entirely depends on whether a GC happens first or not. That seems  
> bad.

That's a fair concern. I would mention a few counterpoints:

1) Nondeterministic behavior is inevitable with an API designed for  
concurrency. There are surely already possible cases of nondeterminism  
in the MessagePort API. Consider sending a message to two different  
workers and waiting for the reply. The replies may arrive in either  
order; indeed, the workers may receive the messages in either order,  
so if they are in communication with each other you cannot rely on one  
getting the message and performing its action first first.

2) The nondeterministic behavior in this case is easily avoided by  
what are in any case good coding practices: (a) don't drop all  
references to a MessagePort you are still using, and (b) call close()  
on the MessagePort when you are done with it and don't want more  
messages.

3) The alternatives on the table to removing this requirement are  
either removing the ability to use MessagePorts to communicate  with  
Workers, or leaving the spec as-is with its attendant high  
implementation cost.

Given all these factors, I think avoid nondeterminism in the one  
particular case you describe, when authors can already avoid it in a  
reasonable way, is not worth the order of magnitude increase in  
implementation complexity imposed by the entanglement keepalive  
requirement. I also think accepting this small amount of potential  
nondeterminism is preferable to excluding Workers from using  
MessagePorts.

Thus, on the whole, I think the best option is to remove the keepalive  
requirement.

Regards,
Maciej

>
> -atw
>
> On Thu, May 7, 2009 at 3:28 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> I agree with Drew's assessment that MessagePorts in combination with  
> Workers are extremely complicated to implement correctly, as  
> currently specified. In fact, the design seems to push towards  
> having lockable shared state, even though one potential advantage of  
> the message passing design is to avoid locking and shared state.
>
> Besides removing MessagePorts as a way to communicate with workers,  
> another possibility is simplifying the life cycle requirements. For  
> example, getting rid of the keepalive rule, whereby both  
> MessagePorts remain live so long as either is otherwise live, would  
> remove the majority of the complexity. I don't think the slight  
> convenience of that rule is worth the extra implementation cost.
>
> On May 7, 2009, at 1:39 PM, Drew Wilson wrote:
>
>> Hi all,
>>
>> I've been hashing through a bunch of the design issues around using  
>> MessagePorts within Workers with IanH and the Chrome/WebKit teams  
>> and I wanted to follow up with the list with my progress.
>>
>> The problems we've encountered are all solveable, but I've been  
>> surprised at the amount of work involved in implementing worker  
>> MessagePorts (and the resulting implications that MessagePorts have  
>> on worker lifecycles/reachability). My concern is that the amount  
>> of work to implement MessagePorts within Worker context may be so  
>> high that it will prevent vendors from implementing the  
>> SharedWorker API. Have other implementers started working on this  
>> part of the spec yet?
>>
>> Let me quickly run down some of the implementation issues I've run  
>> into - some of these may be WebKit/Chrome specific, but other  
>> browsers may run into some of them as well:
>>
>> 1) MessagePort reachability is challenging in the context of  
>> separate Worker heaps
>>
>> In WebKit, each worker has its own heap (in Chrome, they will have  
>> their own process as well). The spec reads:
>> User agents must act as if MessagePort objects have a strong  
>> reference to their entangled MessagePort object.
>>
>> Thus, a message port can be received, given an event listener, and  
>> then forgotten, and so long as that event listener could receive a  
>> message, the channel will be maintained.
>>
>> Of course, if this was to occur on both sides of the channel, then  
>> both ports would be garbage collected, since they would not be  
>> reachable from live code, despite having a strong reference to each  
>> other.
>>
>> Furthermore, a MessagePort object must not be garbage collected  
>> while there exists a message in a task queue that is to be  
>> dispatched on that MessagePort object, or while the MessagePort  
>> object's port message queue is open and there exists a message  
>> event in that queue.
>>
>> The end result of this is the need to track some common state  
>> across an entangled MessagePort pair such as: number of outstanding  
>> messages, open state of each end, and number of active references  
>> to each port (zero or non-zero). Turns out this last bit will  
>> require adding new hooks to the JavaScriptCore garbage collector to  
>> detect transitioning between 1 and 0 references without actually  
>> freeing the object - not that difficult, but possibly something  
>> that other implementers should keep in mind.
>> 2) MessagePorts dramatically change the worker lifecycle
>>
>> Having MessagePorts in worker context means that Workers can  
>> outlive their parent window(s) - I can create a worker, pass off an  
>> entangled MessagePort to another window (say, to a different  
>> domain), then close the original window, and the worker should stay  
>> alive. In the case of WebKit, this causes some problems for things  
>> like worker-initiated network requests - if workers can continue to  
>> run even though there are no open windows for that origin, then it  
>> becomes problematic to perform network requests (part of this is  
>> due to the architecture of WebKit which requires proxying network  
>> requests to window context, but part of this is just a general  
>> problem of "how do you handle things like HTTP Auth when there are  
>> no open windows for that origin?")
>>
>> Finally, the spec defines a fairly broad definition of what makes a  
>> worker reachable - here's an excerpt from my WebKit Shared Worker  
>> design doc, where I summarize the spec (possibly incorrectly - feel  
>> free to correct any misconceptions):
>>
>> Permissible
>>
>> The spec specifies that a worker is permissible based on whether it  
>> has a reachable MessagePort that has been entangled at some point  
>> in the past with an active window (or with a worker who is itself  
>> permissible). Basically, if a worker has ever been entangled with  
>> an active window, or if it's ever been entangled with a worker who  
>> is itself permissible (i.e. it's associated with an active window  
>> via a chain of workers that have been entangled at some point in  
>> the past) then it's permissible.
>>
>> The reason why the "at some point in the past" language is present  
>> is to allow a page to create a fire-and-forget worker (for example,  
>> a worker that does a set of long network operations) without having  
>> to keep a reference to that worker around.
>>
>> Once the referent windows close, the worker should also close, as  
>> being permissible is a necessary (but not sufficient) criteria for  
>> being runnable.
>> Active needed
>>
>> A permissible worker is active needed if:
>> it has pending timers/network requests/DB activity, or
>> it is currently entangled with an active window, or another active  
>> needed worker.
>>
>> The intent behind #1 is to enable fire-and-forget workers that  
>> don't exit until they are idle. The intent behind #2 is that an  
>> idle worker shouldn't exit as long as it's reachable by an active  
>> window (possibly chained through other workers).
>> The end result is that for each worker we need to keep track of a  
>> big list of every window it's ever been entangled with. As workers  
>> become entangled with other workers, they each inherit the list of  
>> entangled windows from the other worker. As windows become  
>> inactive, we then walk the lists of every worker to remove  
>> references to the window and properly shutdown the worker as  
>> appropriate. All of this with the appropriate cross-thread  
>> synchronization, of course :)
>> Likewise, determining when a worker is active needed requires  
>> tracking a graph of entangled message ports, and walking that graph  
>> to determine whether a given worker is reachable by any active  
>> window. Typically this is only needed when either a window closes,  
>> or when a worker goes idle.
>>
>> Again, none of these issues individually are insurmountable, but in  
>> total they add up to a significant amount of work for what should  
>> be a fairly incremental improvement (going from dedicated workers  
>> to shared workers). Have other vendors started investigating what  
>> it takes to implement SharedWorkers (and therefore MessagePorts in  
>> workers)?
>>
>> Another approach for SharedWorkers would be to give them an  
>> implicit MessagePort-esque API like dedicated Workers and not allow  
>> passing in MessagePorts to postMessage(). This would mean that  
>> references to workers can't really be passed around to other  
>> windows/workers, but rather are kept per-origin. Dedicated workers  
>> could work as they do now in Firefox/WebKit (with no MessagePorts).  
>> The SharedWorker lifecycle could be significantly simplified such  
>> that a SharedWorker is permissible as long as there's an active  
>> window under the same origin (no more walking some distributed  
>> cross-thread dependency graph).
>> The thing we'd give up is the capabilities-based API that  
>> MessagePorts provide, but I'd argue that the workaround is simple:  
>> the creating window can just act as a proxy for the worker. IMO,  
>> the implementation burden far outstrips the benefit of allowing  
>> direct foreign access to workers. Literally 90% of the work on my  
>> plate for SharedWorkers seems to derive from MessagePorts in one  
>> form or another, which seems completely wrong.
>> I'd like to hear your thoughts on this - are people open to  
>> removing MessagePort support from Workers?
>>
>> -atw
>>
>>
>>
>>
>>
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090508/9a56f8f4/attachment-0001.htm>

From silviapfeiffer1 at gmail.com  Fri May  8 06:46:17 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 8 May 2009 23:46:17 +1000
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <p06240804c62921c89a85@17.202.35.52>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com> 
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com> 
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com> 
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com> 
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com> 
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52> 
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com> 
	<p06240804c62921c89a85@17.202.35.52>
Message-ID: <2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com>

On Fri, May 8, 2009 at 9:43 AM, David Singer <singer at apple.com> wrote:
> At 8:45 ?+1000 8/05/09, Silvia Pfeiffer wrote:
>>
>> On Fri, May 8, 2009 at 5:04 AM, David Singer <singer at apple.com> wrote:
>>>
>>> ?At 8:39 ?+0200 5/05/09, K?i"tof ?elechovski wrote:
>>>>
>>>> ?If the author wants to show only a sample of a resource and not the
>>>> full
>>>> ?resource, I think she does it on purpose. ?It is not clear why it is
>>>> vital
>>>> ?for the viewer to have an _obvious_ way to view the whole resource
>>>> ?instead;
>>>> ?if it were the case, the author would provide for this.
>>>> ?IMHO,
>>>> ?Chris
>>>
>>> ?It depends critically on what you think the semantics of the fragment
>>> are.
>>> ?In HTML (the best analogy I can think of), the web page is not trimmed
>>> or
>>> ?edited in any way -- you are merely directed to one section of it.
>>
>> There are critical differences between HTML and video, such that this
>> analogy has never worked well.
>
> could you elaborate?

At the risk of repeating myself ...

HTML is text and therefore whether you download a snippet only or the
full page and then do an offset does not make much of a difference.
Even for a long page.

In contrast, downloading a snippet of video compared to the full video
will make a huge difference, in particular for long-form video.

So, the difference is that in HTML the user agent will always have the
context available within its download buffer, while for video this may
not be the case.

This admittedly technical difference also has an influence on the user
interface.

If you have all the context available in the user agent, it is easy to
just grab a scroll-bar and jump around in the full content manually to
look for things. This is not possible in the video case without many
further download actions, which will each incur a network delay. This
difference opens the door to enable user agents with a choice in
display to either provide the full context, or just the fragment
focus.

Thus, while comparing media fragments to HTML fragments is a simple
way to introduce the concept - and I use it, too, to explain to my
less technical peers - it doesn't really help for detailed
specifications.

Regards,
Silvia.

From jackalmage at gmail.com  Fri May  8 07:42:13 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 8 May 2009 09:42:13 -0500
Subject: [whatwg] Interaction of explicit and implicit sections (was:
	Re: Question on (new) header and hgroup)
In-Reply-To: <op.utlmgkuuidj3kv@simon-pieterss-macbook.local>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
	<op.utlmgkuuidj3kv@simon-pieterss-macbook.local>
Message-ID: <dd0fbad0905080742y6afc45e8x51642ef881addc2e@mail.gmail.com>

On Fri, May 8, 2009 at 1:46 AM, Simon Pieters <simonp at opera.com> wrote:
> I guess the proper solution to that is to introduce
> :heading-level(n) that uses the outline algorithm. (But how to select and
> style subtitles in hgroup though?)

If you used a :heading-level() pseudoclass, you'd just do
":heading-level(x) h2" to style the h2 within an element of heading
level x.  (This would only target <h2>s withing <hgroup>s right now,
not <h2>s by themselves.)

~TJ

From dale at ucsc.edu  Fri May  8 08:45:35 2009
From: dale at ucsc.edu (Michael Dale)
Date: Fri, 08 May 2009 08:45:35 -0700
Subject: [whatwg] Suitable video codec
In-Reply-To: <fbad4e140905071751o4a588589s2f2b5e19f8d437cf@mail.gmail.com>
References: <fbad4e140905071751o4a588589s2f2b5e19f8d437cf@mail.gmail.com>
Message-ID: <4A04539F.7050301@ucsc.edu>

yea.. the take home point is that Theora now has an encoder that puts it 
in the same ballpark as contemporary proprietary codecs. I would not say 
Theora is "outdoing h.264". The results of a given PSNR test are 
impressive and important to publicize but I think my wording in posting 
about that test might have promoted overstating the quality factor.

The only quality that really mattered in terms of standardization has 
stayed constant: which is Ogg Theora is /royalty free/ and implementable 
in both proprietary and free software browsers.

--michael

David Gerard wrote:
> H.264 was advocated here for the <video> element as higher quality
> than competing codecs such as Theora could ever manage.
>
> The Thusnelda coder is outdoing H.,264 in current tests:
>
> http://web.mit.edu/xiphmont/Public/theora/demo7.html
>
> This is of course developmental work. I'm sure the advocates of H. 264
> can also tune its encoders to keep up, and not make Theora the only
> reasonable candidate for the <video> element.
>
>
> - d.



From singer at apple.com  Fri May  8 09:25:43 2009
From: singer at apple.com (David Singer)
Date: Fri, 8 May 2009 09:25:43 -0700
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<Pine.LNX.4.62.0904300621100.10370@hixie.dreamhostps.com>
	<2c0e02830904300615x9e0adc5q70d98966208257e7@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52>
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com>
	<p06240804c62921c89a85@17.202.35.52>
	<2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com>
Message-ID: <p06240805c62a0c11e4a7@[10.0.1.6]>

At 23:46  +1000 8/05/09, Silvia Pfeiffer wrote:
>On Fri, May 8, 2009 at 9:43 AM, David Singer <singer at apple.com> wrote:
>>  At 8:45  +1000 8/05/09, Silvia Pfeiffer wrote:
>>>
>>>  On Fri, May 8, 2009 at 5:04 AM, David Singer <singer at apple.com> wrote:
>>>>
>>>>   At 8:39  +0200 5/05/09, K?i"tof ?elechovski wrote:
>>>>>
>>>>>   If the author wants to show only a sample of a resource and not the
>>>>>  full
>>>>>   resource, I think she does it on purpose.  It is not clear why it is
>>>>>  vital
>>>>>   for the viewer to have an _obvious_ way to view the whole resource
>>>>>   instead;
>>>>>   if it were the case, the author would provide for this.
>>>>>   IMHO,
>>>>>   Chris
>>>>
>>>>   It depends critically on what you think the semantics of the fragment
>>>>  are.
>>>>   In HTML (the best analogy I can think of), the web page is not trimmed
>>>>  or
>>>>   edited in any way -- you are merely directed to one section of it.
>>>
>>>  There are critical differences between HTML and video, such that this
>>>  analogy has never worked well.
>>
>>  could you elaborate?
>
>At the risk of repeating myself ...
>
>HTML is text and therefore whether you download a snippet only or the
>full page and then do an offset does not make much of a difference.
>Even for a long page.

you might try loading, say, the one-page version 
of the HTML5 spec. from the WhatWG site...it 
takes quite a while.  Happily Ian also provides a 
multi-page, but this is not always the case.

>
>In contrast, downloading a snippet of video compared to the full video
>will make a huge difference, in particular for long-form video.

there are short and long pages and videos.

But we're talking about a point of principal 
here, which should be informed by practical, for 
sure, but not dominated by it.

The reason I want clarity is that this has 
ramifications.  For example, if a UA is asked to 
play a video with a fragment indication 
#time="10s-20s", and then a script seeks to 5s, 
does the user see the video at the 5s point of 
the total resource, or 15s?  I think it has to be 
5s.

>
>So, the difference is that in HTML the user agent will always have the
>context available within its download buffer, while for video this may
>not be the case.

I'm sorry, I am lost.  We could quite easily 
extend HTTP to allow for anchor-based retrieval 
of HTML (i.e. convert a 'please start at anchor 
X' into a pair of byte-range responses, for the 
global material, and then the document from that 
anchor onwards).

>
>This admittedly technical difference also has an influence on the user
>interface.
>
>If you have all the context available in the user agent, it is easy to
>just grab a scroll-bar and jump around in the full content manually to
>look for things. This is not possible in the video case without many
>further download actions, which will each incur a network delay. This
>difference opens the door to enable user agents with a choice in
>display to either provide the full context, or just the fragment
>focus.

But we can optimize for the fragment without disallowing the seeking.


-- 
David Singer
Multimedia Standards, Apple Inc.

From ian at hixie.ch  Fri May  8 11:57:44 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 May 2009 18:57:44 +0000 (UTC)
Subject: [whatwg] Micro-data/Microformats/RDFa
	Interoperability	Requirement
In-Reply-To: <4A039BB1.4050703@digitalbazaar.com>
References: <4A0104C2.8080009@digitalbazaar.com>
	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>
	<4A02F6AE.1000602@digitalbazaar.com>
	<Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>
	<4A039BB1.4050703@digitalbazaar.com>
Message-ID: <Pine.LNX.4.62.0905081833080.7824@hixie.dreamhostps.com>

On Thu, 7 May 2009, Manu Sporny wrote:
> 
> That's certainly not what the WHATWG blog stated just 20 days ago for
> rel="license" [...]

The WHATWG blog is an open platform on which anyone can post, and content 
is not vetted for correctness. Mark can sometimes make mistakes. Feel free 
to post a correction. :-)


> and the spec doesn't seem to clearly outline the difference in 
> definition either (at least, that's not my reading of the spec):
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-license
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-tag

Actually I just looked at the rel-tag faq and found that it disagrees with 
what Tantek had told me, so (assuming the faq is normative or that the 
rel-tag spec does mention this somewhere that I didn't find) the specs do 
match here.

For rel-license, the HTML5 spec defines the value to apply to the content 
and not the page as a whole. This is a recent change to match actual 
practice and I will be posting about this shortly.


> > The RDFa specification is very confusing to me (e.g. I don't 
> > understand how the normative processing model is separate from the 
> > section "RDFa Processing in detail"), so I may be misinterpreting 
> > things, but as far as I can tell:
> > 
> >   <html xmlns="http://www.w3.org/1999/xhtml">
> >    <head>
> >     <base href="http://example.com/"/>
> >     <link about="http://example.net/"
> >           rel="dc.author" 
> >           href="http://a.example.org/"/>
> >    ...
> > 
> > ...will result in the following triple:
> > 
> >    <http://example.net/> <http://example.com/dc.author> <http://a.example.org/> .
> 
> Two corrections:
> 
> The first is that an RDFa processor would not generate this triple.

My apologies, I misinterpreted 5.4.4. Use of CURIEs in Specific Attributes 
to mean that rel="" was a relative-uri-or-curie attribute. (5.4.4. Use of 
CURIEs in Specific Attributes says it's "link-type-or-curie", but 5.4.3. 
General Use of CURIEs in Attributes doesn't list that as a possibility and 
at the end says that rel="" is an exception only insofar as it supports 
specific link types as well, which I interpreted differently.)


> > For example, it would be somewhat presumptious of RDFa to prevent any 
> > future version of HTML from being able to use the word "resource" as 
> > an attribute name. What if we want to extend the forms features to 
> > have an XForms "datatype" compatibility layer; why should we not be 
> > able to use the "datatype" and "typeof" attributes?
> 
> As long as their legacy nature was preserved, and those uses didn't 
> create ambiguity in RDFa processors and semantic equivalence was 
> ensured, I don't see why they shouldn't be re-used.

Ah, ok. If such attributes are re-used, I suppose that it should be 
possible to make sure that it is possible to re-use them in a way that 
doesn't conflict with RDFa (e.g. by triggering the non-curie-non-uri 
behaviour for property="" or by having authors who want RDFa compatibility 
use xmlns:http="http:" declarations or some such).

Noted.


> > Surely this is what namespaces were intended for.
> 
> Uhh, what sort of namespaces are we talking about here? xmlns-style, 
> namespaces?

The idea of XML Namespaces was to allow people to extend vocabularies
with a new features without clashing with older features by putting the 
new names in new namespaces. It seems odd that RDFa, a W3C technology for 
an XML vocabulary, didn't use namespaces to do it.


> >>> For example, the way that "n:next" and "next" can end up being 
> >>> equivalent in RDFa processors despite being different per HTML rules 
> >>> (assuming an "n" namespace is appropriately declared).
> >>
> >> If they end up being equivalent in RDFa, the RDFa author did so 
> >> explicitly when declaring the 'n' prefix to the default prefix 
> >> mapping and we should not second-guess the authors intentions.
> > 
> > My only point is that it is not compatible with HTML4 and HTML5, 
> > because they end up with different results in the same situation (one 
> > can treat two different values as the same, while the other can treat 
> > two different values as different).
> 
> It is only not compatible with HTML5 if this community chooses for it to 
> not be compatible with HTML5. Do you agree or disagree that we shouldn't 
> second guess the authors intentions if they go out of their way to 
> declare a mapping for 'n'?

I don't think that's a relevant question. My point is that it is possible 
in RDFa to put two strings that have different semantics in HTML4 and yet 
have them have the same semantics in RDFa. This means RDFa is not 
compatible with HTML4.


> > Another example would be:
> > 
> >   <html xmlns="http://www.w3.org/1999/xhtml">
> >    <head about="">
> >     <link rel="stylesheet alternate next" href="...">
> >     ...
> > 
> > ...which in RDFa would cause the following triples to be created:
> > 
> >    <> <http://www.w3.org/1999/xhtml/vocab#stylesheet> <...> .
> >    <> <http://www.w3.org/1999/xhtml/vocab#alternate> <...> .
> >    <> <http://www.w3.org/1999/xhtml/vocab#next> <...> .
> > 
> > ...but according to HTML4/5, is really only two relations (an 
> > alternativee stylesheet and the next document).
> 
> That's a very strained argument. The contents of @rel are supposed to be 
> LinkTypes, which are space-separated keywords:
> 
> http://www.w3.org/TR/html4/types.html#type-links
> 
> It just so happens that when you use "alternate" and "stylesheet" 
> together that the browser is supposed to recognize that an alternate 
> stylesheet exists.
>
> I've always thought that this was an abuse of the rel attribute - there 
> should have been an "alternate-stylesheet" LinkType, but what's done is 
> done.
> 
> AFAIK, there is nothing in the HTML4 or HTML5 spec that states that for 
> rel="alternate stylesheet" that there is only one relation. There are 
> three relationships because there are three separate LinkTypes 
> specified.

It's very clear in HTML5. In HTML4 it's there but about as vague as the 
rest of HTML4. What HTML4 says is academic though since this is 
well-established implementation practice.

Whether it is inconvenient or not, the fact remains that legacy 
implementations (and HTML5, and arguably HTML4) require a processing here 
that is not semantically equivalent to RDFa's.


> > Browser vendors would not accept having to resolve prefixes in 
> > attribute values as part of processing link relations.
> 
> Why not?

You would have to ask them. I tend not to argue with implementor feedback. 
If they tell me they won't do something, I don't tell them to do it.

This by the way is the complaint regarding "QNames in content" and "QNames 
in attribute values". CURIEs don't change this, which is why you'll find a 
lot of people just say that CURIEs are no different to QNames.


> They differ in:
> 
> - The location that they can be used.

The complaint with QNames is when they are used in places they're not 
supposed to be used, like content or attribute values.


> - Whether or not they are required to be validated.

QNames in content or attribute values are typically not required to be 
validated either.


> The only similarity they have is that they can be expanded to full URIs.

That's the complaint. (Specifically, that they can do so in a dynamic 
fashion -- e.g. what happens if a user changes a prefix="" or xmlns:*="" 
attribute value dynamically from script? Do all the RDFa triples change 
too?)


> > The problem with QNames in attributes is that they require the 
> > attribute processor to have information from the namespace processor, 
> > and as far as I can tell this continues to exist in RDFa.)
> 
> If that's really the problem, why don't you just have a prefix processor 
> that the attribute processor relies on and drop the namespace processor 
> entirely?

There are two fundamental problems, one is with having the prefix 
processor be used by code that is in the XML parser and code that is very 
separate from the XML parser (e.g. based on DOM code) -- implementors find 
combining the two to be highly impractical -- and the other is that the 
prefix processor has to handle dynamic changes to prefixes.

These are the problems with QNames-in-content and QNames-in-attributes and 
they apply equally to CURIEs.

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

From ian at hixie.ch  Fri May  8 12:57:31 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 May 2009 19:57:31 +0000 (UTC)
Subject: [whatwg] Helping people seaching for content filtered by license
Message-ID: <Pine.LNX.4.62.0905072258380.18851@hixie.dreamhostps.com>


One of the use cases I collected from the e-mails sent in over the past 
few months was the following:

   USE CASE: Help people searching for content to find content covered by
   licenses that suit their needs.

   SCENARIOS:
     * If a user is looking for recipes of pies to reproduce on his blog, he
       might want to exclude from his results any recipes that are not
       available under a license allowing non-commercial reproduction.
     * Lucy wants to publish her papers online. She includes an abstract of
       each one in a page, but because they are under different copyright
       rules, she needs to clarify what the rules are. A harvester such as
       the Open Access project can actually collect and index some of them
       with no problem, but may not be allowed to index others. Meanwhile, a
       human finds it more useful to see the abstracts on a page than have to
       guess from a bunch of titles whether to look at each abstract.
     * There are mapping organisations and data producers and people who take
       photos, and each may place different policies. Being able to keep that
       policy information helps people with further mashups avoiding
       violating a policy. For example, if GreatMaps.com has a public domain
       policy on their maps, CoolFotos.org has a policy that you can use data
       other than images for non-commercial purposes, and Johan Ichikawa has
       a photo there of my brother's cafe, which he has licensed as "must pay
       money", then it would be reasonable for me to copy the map and put it
       in a brochure for the cafe, but not to copy the data and photo from
       CoolFotos. On the other hand, if I am producing a non-commercial guide
       to cafes in Melbourne, I can add the map and the location of the cafe
       photo, but not the photo itself.
     * Tara runs a video sharing web site for people who want licensing
       information to be included with their videos. When Paul wants to blog
       about a video, he can paste a fragment of HTML provided by Tara
       directly into his blog. The video is then available inline in his
       blog, along with any licensing information about the video.
     * Fred's browser can tell him what license a particular video on a site
       he is reading has been released under, and advise him on what the
       associated permissions and restrictions are (can he redistribute this
       work for commercial purposes, can he distribute a modified version of
       this work, how should he assign credit to the original author, what
       jurisdiction the license assumes, whether the license allows the work
       to be embedded into a work that uses content under various other
       licenses, etc).
     * Flickr has images that are CC-licensed, but the pages themselves are
       not.
     * Blogs may wish to reuse CC-licensed images without licensing the whole
       blog as CC, but while still including attribution and license
       information (which may be required by the licenses in question).

   REQUIREMENTS:
     * Content on a page might be covered by a different license than other
       content on the same page.
     * When licensing a subpart of the page, existing implementations must
       not just assume that the license applies to the whole page rather than
       just part of it.
     * License proliferation should be discouraged.
     * License information should be able to survive from one site to another
       as the data is transfered.
     * Expressing copyright licensing terms should be easy for content
       creators, publishers, and redistributors to provide.
     * It should be more convenient for the users (and tools) to find and
       evaluate copyright statements and licenses than it is today.
     * Shouldn't require the consumer to write XSLT or server-side code to
       process the license information.
     * Machine-readable licensing information shouldn't be on a separate page
       than human-readable licensing information.
     * There should not be ambiguous legal implications.
     * Parsing rules should be unambiguous.
     * Should not require changes to HTML5 parsing rules.


The scenarios described above fall into three categories: searching for 
content, publishing content, and obtaining legal advice.

First, I will examine the search scenario:

     * If a user is looking for recipes of pies to reproduce on his blog, he
       might want to exclude from his results any recipes that are not
       available under a license allowing non-commercial reproduction.

This is technically possible today. The rel="license" link type allows 
authors to specify the license that applies to the main content on a page, 
in this case recipes, search engines can be programmed with the most 
common licenses, and the user can tell the search engine what 
characteristics he wants ("compatible with GPLv2", "no advertising 
clause", "doesn't have patent implications", "allows redistribution to 
countries on the US blacklist").

This has some implications:

 - Each unit of content (recipe in this case) must have its own 
   independent page at a distinct URL. This is actually good practice 
   anyway today for making content discoverable from search engines, and 
   it is compatible with what people already do, so this seems fine.

 - New licenses are discouraged, as they would not be automatically 
   supported by search engines. This is needed by one of the requirements:

     * License proliferation should be discouraged.

This solution is already deployed on such sites as Flickr, and already 
supported on search engines such as Google.



Next, I will look at the content publishing scenarios:

     * Lucy wants to publish her papers online. She includes an abstract of
       each one in a page, but because they are under different copyright
       rules, she needs to clarify what the rules are. A harvester such as
       the Open Access project can actually collect and index some of them
       with no problem, but may not be allowed to index others. Meanwhile, a
       human finds it more useful to see the abstracts on a page than have to
       guess from a bunch of titles whether to look at each abstract.

This really boils down to two points:

 - Being able to include the license of various items on a page for humans 
   to read.

 - Being able to control what harvesters (spiders) index.

Being able to include a license on a page is easy: you just include the 
license name and a link to the license. Since this is for the user in this 
case, there is no need for any special markup.

Controlling harvesters is a separate problem. This is actually a 
well-understood problem space with a number of very well-understood 
solutions. For site-wide control, there is robots.txt, which can target 
individual spiders (as in this case). On a page-by-page basis, there is 
the <meta> element's "noindex" value.

Thus this particular scenario doesn't require any new features.


     * There are mapping organisations and data producers and people who take
       photos, and each may place different policies. Being able to keep that
       policy information helps people with further mashups avoiding
       violating a policy. For example, if GreatMaps.com has a public domain
       policy on their maps, CoolFotos.org has a policy that you can use data
       other than images for non-commercial purposes, and Johan Ichikawa has
       a photo there of my brother's cafe, which he has licensed as "must pay
       money", then it would be reasonable for me to copy the map and put it
       in a brochure for the cafe, but not to copy the data and photo from
       CoolFotos. On the other hand, if I am producing a non-commercial guide
       to cafes in Melbourne, I can add the map and the location of the cafe
       photo, but not the photo itself.

This doesn't seem to require any technological solution at all; it seems 
to be purely a legal issue. So long as the licenses are clearly stated, as 
they presumably must be (for example, the MIT license requires the 
copyright text to follow the text even as it is copied, the Creative 
Commons licenses require the license or its URL to be published with any 
reproductions, etc), there is no need for any markup.


     * Tara runs a video sharing web site for people who want licensing
       information to be included with their videos. When Paul wants to blog
       about a video, he can paste a fragment of HTML provided by Tara
       directly into his blog. The video is then available inline in his
       blog, along with any licensing information about the video.

(Really? A video sharing site dedicated to people who want licensing 
information to be included with their videos? That's a pretty specific 
audience, wow.)

This can be done with HTML5 today. For example, here is the markup you 
could include to allow someone to embed a video on their site while 
including the copyright or license information:

   <figure>
    <video src="http://example.com/videodata/sJf-ulirNRk" controls>
     <a href="http://video.example.com/watch?v=sJf-ulirNRk">Watch</a>
    </video>
    <legend>
     Pillar post surgery, starting to heal.
     <small>&copy; copyright 2008 Pillar. All Rights Reserved.</small>
    </legend>
   </figure>


     * Flickr has images that are CC-licensed, but the pages themselves are
       not.

I've clarified the HTML5 spec's definition of rel=license and included an 
example showing a page based on what Flickr is doing.

For search, this has the right result (when a search page returns an 
arbitrary Flickr page, it's because they are looking for the image, which 
is what the rel=license link Flickr gives is for), and it is clear to the 
user (they see the license information clearly, and there's no confusion 
that it might apply to the rest of the page).


     * Blogs may wish to reuse CC-licensed images without licensing the whole
       blog as CC, but while still including attribution and license
       information (which may be required by the licenses in question).

The example above shows this for a movie, but it works as well for a 
photo:

   <figure>
     <img src="http://nearimpossible.com/DSCF0070-1-tm.jpg" alt="">
     <legend>
      Picture by Bob.
      <small><a href="http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode">Creative 
      Commons Attribution-Noncommercial-Share Alike 2.5 Generic License</a></small>
     </legend>
   </figure>

Admittedly, if this scenario is taken in the context of the first 
scenario, meaning that Bob wants this image to be discoverable through 
search, but doesn't want to include it on a page of its own, then extra 
syntax to mark this particular image up would be useful.

However, in my research I found very few such cases. In every case where I 
found multiple media items on a single page with no dedicated page, either 
every item was licensed identically and was the main content of the page, 
or each item had its own separate page, or the items were licensed under 
the same license as the page. In all three of these cases, rel=license 
already solves the problem today. This discourages people from using 
multiple licenses, of course, but that's actually a good thing, as it 
discourages license proliferation.



     * Fred's browser can tell him what license a particular video on a site
       he is reading has been released under, and advise him on what the
       associated permissions and restrictions are (can he redistribute this
       work for commercial purposes, can he distribute a modified version of
       this work, how should he assign credit to the original author, what
       jurisdiction the license assumes, whether the license allows the work
       to be embedded into a work that uses content under various other
       licenses, etc).

Advising a user on the legal implications of a license is something that 
needs trained professionals, but given a particular license, advice could 
be provided in canned form. So it seems like this is already possible, the 
user just has to select a license from a list of licenses. A user agent 
could pre-select a license based on the value of the page's rel=license 
link(s), or based on scanning the page for mention of a license, too.




I will now examine how these solutions fit the requirements:

     * Content on a page might be covered by a different license than other
       content on the same page.

For the search case, this is handled by separating that content so that 
each page that is to be discoverable via a license filter is discoverable 
at independent URLs. This appears to fit the existing practice.


     * When licensing a subpart of the page, existing implementations must
       not just assume that the license applies to the whole page rather than
       just part of it.

This is resolved by not having a mechanism for machine-readably licensing 
just part of a page, and instead putting such content on its own page, 
which leads to a better experience anyway from a search perspective.


     * License proliferation should be discouraged.

I've mentioned several ways in which this is achieved.


     * License information should be able to survive from one site to another
       as the data is transfered.

This is clearly possible if the license information is mere text, and 
indeed some of the licenses already require this anyway.


     * Expressing copyright licensing terms should be easy for content
       creators, publishers, and redistributors to provide.

It is simple to express license terms, since no special syntax beyond the 
legally-required verbiage is necessary.


     * It should be more convenient for the users (and tools) to find and
       evaluate copyright statements and licenses than it is today.

This requirement is not met. I do not know of any way to improve matters 
beyond what is available today, unfortunately. This would probably require 
lesiglative simplifications of copyright law, which, while probably quite 
desireable, are somewhat out of scope of HTML5.


     * Shouldn't require the consumer to write XSLT or server-side code to
       process the license information.

No XSLT is necessary for consuming rel="license". Some code is necessary 
to make a search engine to index rel="license" data, but that seems 
inevitable and, in practice, is a small amount of code relative to the 
rest of the code involved in an indexing project.


     * Machine-readable licensing information shouldn't be on a separate page
       than human-readable licensing information.

Since the only machine-readable licensing information that HTML5 provides 
for is rel="license", and that can only be included as part of a link on 
the page with the license statement, this requirement is met.


     * There should not be ambiguous legal implications.

This requirement is met only insofar as rel="license" doesn't make any 
firm legal statements; the page is required to be unambiguous about what 
is considered the main content. In practice I think we can see that sites 
like Flickr have found that this is possible. Beyond that, since the only 
legal implications here are those that would be present without any markup 
at all (i.e. copyright statements, etc), the legal implications of HTML5's 
features seem minimal.


     * Parsing rules should be unambiguous.

The rules for parsing rel="" values are well-understood and clear, I 
believe.


     * Should not require changes to HTML5 parsing rules.

No parsing rules changed during the addressing of these use cases.



In conclusion, it seems most of these use cases are already handled by the 
current text in the spec and do not show a need for a more elaborate 
scheme. The rel="license" feature in particular handles search adequately, 
and is already deployed both in consumers and generators. Two areas where 
we could add more syntax-level support would be in licensing subparts 
explicitly, and in providing machine-readable licenses. The former seems 
like an obvious need but actual deployed content doesn't seem to need it, 
since most individually licensed works exist on pages of their own 
already, or are covered by the same license as other works on the same 
page. The latter is a dangerous area to get into, as licenses have very 
specific legal wording. We could never make the machine-readable text have 
legal standing, and thus people couldn't rely on it to draw conclusions 
anyway. Furthermore, it would encourage license proliferation which is 
already a problem.


A number of further use cases remain to be examined, including some more 
specifically looking at attribution rather than licensing. I will send 
further e-mail next week as I address them.

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

From shelleyp at burningbird.net  Fri May  8 13:02:31 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Fri, 08 May 2009 15:02:31 -0500
Subject: [whatwg] microdata use cases and Getting data out of poorly written
 Web pages
Message-ID: <4A048FD7.6080208@burningbird.net>

It's difficult to tell where one should comment on the so-called 
microdata use cases. I'm forced to send to multiple mailing lists.

Ian, I would like to see the original request that went into this 
particular use case. In particular, I'd like to know who originated it, 
so that we can ensure that the person has read your follow-up, as well 
as how you condensed the use case down (to check if your interpretation 
is proper or not).

In addition, from my reading of this posting of yours titled "[whatwg] 
Getting data out of poorly written Web pages", is this open for any 
discussion? It seems to me that you received the original data, 
generated a use case document from the data, unilaterally, and now 
you're making unilateral decisions as to whether the use case requires a 
change in HTML5 or not.

Is this what we can expect from all of the use cases?

Shelley




From ian at hixie.ch  Fri May  8 13:20:13 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 May 2009 20:20:13 +0000 (UTC)
Subject: [whatwg] microdata use cases and Getting data out of poorly
 written Web pages
In-Reply-To: <4A048FD7.6080208@burningbird.net>
References: <4A048FD7.6080208@burningbird.net>
Message-ID: <Pine.LNX.4.62.0905082013010.7824@hixie.dreamhostps.com>

On Fri, 8 May 2009, Shelley Powers wrote:
>
> It's difficult to tell where one should comment on the so-called 
> microdata use cases. I'm forced to send to multiple mailing lists.

Please don't cross-post to the WHATWG list and other lists -- you may pick 
either one, I read all of them. (Cross-posting results in a lot of 
confusion because some of the lists only allow members to posts, which 
others allow anyone to post, so we end up with fragmented threads.)


> Ian, I would like to see the original request that went into this 
> particular use case. In particular, I'd like to know who originated it, 
> so that we can ensure that the person has read your follow-up, as well 
> as how you condensed the use case down (to check if your interpretation 
> is proper or not).

I did not keep track of where the use cases came from (I generally ignore 
the source of requests so as to avoid any possible bias).

However, I can probably figure out some of the sources of a particular 
scenario if you have a specific one in mind. Could you clarify which 
scenario or requirement you are particularly interested in?


> In addition, from my reading of this posting of yours titled "[whatwg] 
> Getting data out of poorly written Web pages", is this open for any 
> discussion?

Naturally, all input is always welcome.


> It seems to me that you received the original data, generated a use case 
> document from the data, unilaterally, and now you're making unilateral 
> decisions as to whether the use case requires a change in HTML5 or not.
> 
> Is this what we can expect from all of the use cases?

Yes.

If my proposals don't actually address the use cases, then please do point 
how that is the case. Similarly, if there are missing use cases, please 
bring them up. All input is always welcome (whether on the lists, or 
direct e-mal, on blogs, or wherever). None of the text in the HTML5 spec 
is frozen, it's merely a proposal. If there are use cases that should be 
addressed that are not addressed then we should address them.

(Regarding microdata note that I've so far only sent proposals for three 
of the 20 use cases that I collected. I've still got a lot to go through.)

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

From shelleyp at burningbird.net  Fri May  8 13:47:50 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Fri, 08 May 2009 15:47:50 -0500
Subject: [whatwg] microdata use cases and Getting data out of poorly
 written Web pages
In-Reply-To: <Pine.LNX.4.62.0905082013010.7824@hixie.dreamhostps.com>
References: <4A048FD7.6080208@burningbird.net>
	<Pine.LNX.4.62.0905082013010.7824@hixie.dreamhostps.com>
Message-ID: <4A049A76.2030400@burningbird.net>

Ian Hickson wrote:
> On Fri, 8 May 2009, Shelley Powers wrote:
>   
>> It's difficult to tell where one should comment on the so-called 
>> microdata use cases. I'm forced to send to multiple mailing lists.
>>     
>
> Please don't cross-post to the WHATWG list and other lists -- you may pick 
> either one, I read all of them. (Cross-posting results in a lot of 
> confusion because some of the lists only allow members to posts, which 
> others allow anyone to post, so we end up with fragmented threads.)
>
>
>   
But different people respond to the mailings in different ways, 
depending on the list. This isn't just you, Ian. How can I ensure that 
the W3C people have access to the same concerns?
>> Ian, I would like to see the original request that went into this 
>> particular use case. In particular, I'd like to know who originated it, 
>> so that we can ensure that the person has read your follow-up, as well 
>> as how you condensed the use case down (to check if your interpretation 
>> is proper or not).
>>     
>
> I did not keep track of where the use cases came from (I generally ignore 
> the source of requests so as to avoid any possible bias).
>
>   
Documenting the originator of a use case is introducing bias? In what 
universe?

If anything, documenting where the use cases come from, and providing 
access to the original, raw data helps to ensure that bias has not been 
introduced. More importantly, it gives your teammates a chance to verify 
your interpretation of the use cases, and provide correction, if needed.

> However, I can probably figure out some of the sources of a particular 
> scenario if you have a specific one in mind. Could you clarify which 
> scenario or requirement you are particularly interested in?
>
>
>   
Ian, I think its important that you provide a place documenting the 
original raw data. This provides a historical perspective on the 
decisions going into HTML5 if nothing else.

If you need help, I'm willing to help you. You'll need to forward me the 
emails you received, and send me links to the other locations. I'll then 
put all these into a document and we can work to map to your condensed 
document. That way there's accountability at all steps in the decision 
process, as well as transparency.

Once I put the document together, we can put with other documents that 
also provide history of the decision processes.
>> In addition, from my reading of this posting of yours titled "[whatwg] 
>> Getting data out of poorly written Web pages", is this open for any 
>> discussion?
>>     
>
> Naturally, all input is always welcome.
>
>
>   
No, I didn't ask if input was welcome. I asked if this was still open 
for discussion, or if you have made up your mind, and and further 
discussion will just be wasting everyone's time.
>> It seems to me that you received the original data, generated a use case 
>> document from the data, unilaterally, and now you're making unilateral 
>> decisions as to whether the use case requires a change in HTML5 or not.
>>
>> Is this what we can expect from all of the use cases?
>>     
>
> Yes.
>   
That's not appropriate for a team environment.
> If my proposals don't actually address the use cases, then please do point 
> how that is the case. Similarly, if there are missing use cases, please 
> bring them up. All input is always welcome (whether on the lists, or 
> direct e-mal, on blogs, or wherever). None of the text in the HTML5 spec 
> is frozen, it's merely a proposal. If there are use cases that should be 
> addressed that are not addressed then we should address them.
>
>   
Again, how can I? I don't have the original data.
> (Regarding microdata note that I've so far only sent proposals for three 
> of the 20 use cases that I collected. I've still got a lot to go through.)
>
>   
After digging, I found another one, at

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019620.html

Again, though, the writing style indicates the item is closed, and 
discussion is not welcome. I have to assume that this is how you 
mentally perceive the item, and therefore though we may respond, the 
response will make no difference.

And I can't find the third one. Perhaps you can provide a direct link.

I'm concerned, too, about the fact that the discussion for these is 
happening on the WhatWG group, but not in the HTML WG email list. I've 
never understood two different email lists, and have felt having both is 
confusing, and potentially misleading. Regardless, shouldn't this 
discussion be taking place in the HTML WG, too?

Isn't the specification the W3C HTML5 specification, also?

I'm just concerned because from what I can see of both groups, interests 
and concerns differ between the groups. That means only addressing 
issues in one group, would leave out potentially important discussions 
in the other group.

Shelley



From ian at hixie.ch  Fri May  8 20:30:35 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 9 May 2009 03:30:35 +0000 (UTC)
Subject: [whatwg] Allowing authors to annotate their documents to explain
 things for readers
Message-ID: <Pine.LNX.4.62.0905090314230.7824@hixie.dreamhostps.com>


One of the use cases I collected from the e-mails sent in over the past 
few months was the following:

   USE CASE: Allow authors to annotate their documents to highlight the key
   parts, e.g. as when a student highlights parts of a printed page, but in a
   hypertext-aware fashion.

   SCENARIOS:
     * Fred writes a page about Napoleon. He can highlight the word Napoleon
       in a way that indicates to the reader that that is a person. Fred can
       also annotate the page to indicate that Napoleon and France are
       related concepts.

This use case isn't altogether clear, but if the target audience of the 
annotations is human readers (as opposed to machines and readers using 
automated processing tools), then it seems like this is already possible 
in a number of ways in HTML5.

The easiest way of addressing this is just to include text bringing the 
user's attention to relationships:

   <p>This page is about Napoleon. He was my uncle and lived in 
   France.</p>

Individual keywords can be highlighted with <b>:

   <p>This page is about <b>Napoleon</b>. He was my uncle and lived in 
   <b>France</b>.</p>

Prose annotations can be added to individual words or phrases using the 
title="" attribute:

   <p>This page is about <span title="A person">Napoleon</span>. He was my 
   uncle and lived in <span title="A hamlet near Drummond, in Idaho, 
   USA">France</span>.</p>

These typically show as tooltips.

To highlight material on the page that might be relevant to the user, e.g. 
if the user searched for the word "Uncle" and the site wanted to highlight 
the word "Uncle", the <mark> element can be used:

   <p>This page is about Napoleon. He was my <mark>uncle</mark> and lived 
   in France.</p>

The same element can be used by a reader editing an existing document to 
highlight the parts that warrant further study, possibly using the 
title="" attribute to include notes:

   <p>This page is about Napoleon. He was my uncle and <mark 
   title="really?">lived in France</mark>.</p>

Links can be used to link parts of a document together to indicate 
relationships:

   <p id="napoleon">My uncle was called Napoleon. See also: <a
   href="#france">France</a>, <a href="#uncle">Uncle</a>.</p>
   ...
   <p id="france">France is a hamlet near Drummond, ID. My uncle lived 
   there. See also: <a href="#napoleon">Napoleon</a>.</p>

In conclusion, this use case doesn't seem to need any new changes to the 
language.

A number of further use cases remain to be examined, including some more 
specifically looking at machine-readable annotations rather than 
annotations aimed directly at human readers. I will send further e-mail 
next week as I address them.

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

From silviapfeiffer1 at gmail.com  Fri May  8 21:09:32 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Sat, 9 May 2009 14:09:32 +1000
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <p06240805c62a0c11e4a7@10.0.1.6>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com> 
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com> 
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com> 
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52> 
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com> 
	<p06240804c62921c89a85@17.202.35.52>
	<2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com> 
	<p06240805c62a0c11e4a7@10.0.1.6>
Message-ID: <2c0e02830905082109t64fa89aaj5dd50933c3d9283@mail.gmail.com>

On Sat, May 9, 2009 at 2:25 AM, David Singer <singer at apple.com> wrote:
> At 23:46 ?+1000 8/05/09, Silvia Pfeiffer wrote:
>>
>> On Fri, May 8, 2009 at 9:43 AM, David Singer <singer at apple.com> wrote:
>>>
>>> ?At 8:45 ?+1000 8/05/09, Silvia Pfeiffer wrote:
>>>>
>>>> ?On Fri, May 8, 2009 at 5:04 AM, David Singer <singer at apple.com> wrote:
>>>>>
>>>>> ?At 8:39 ?+0200 5/05/09, K?i"tof ?elechovski wrote:
>>>>>>
>>>>>> ?If the author wants to show only a sample of a resource and not the
>>>>>> ?full
>>>>>> ?resource, I think she does it on purpose. ?It is not clear why it is
>>>>>> ?vital
>>>>>> ?for the viewer to have an _obvious_ way to view the whole resource
>>>>>> ?instead;
>>>>>> ?if it were the case, the author would provide for this.
>>>>>> ?IMHO,
>>>>>> ?Chris
>>>>>
>>>>> ?It depends critically on what you think the semantics of the fragment
>>>>> ?are.
>>>>> ?In HTML (the best analogy I can think of), the web page is not trimmed
>>>>> ?or
>>>>> ?edited in any way -- you are merely directed to one section of it.
>>>>
>>>> ?There are critical differences between HTML and video, such that this
>>>> ?analogy has never worked well.
>>>
>>> ?could you elaborate?
>>
>> At the risk of repeating myself ...
>>
>> HTML is text and therefore whether you download a snippet only or the
>> full page and then do an offset does not make much of a difference.
>> Even for a long page.
>
> you might try loading, say, the one-page version of the HTML5 spec. from the
> WhatWG site...it takes quite a while. ?Happily Ian also provides a
> multi-page, but this is not always the case.

That just confirms the problem and it's obviously worse with video. :-)


> The reason I want clarity is that this has ramifications. ?For example, if a
> UA is asked to play a video with a fragment indication #time="10s-20s", and
> then a script seeks to 5s, does the user see the video at the 5s point of
> the total resource, or 15s? ?I think it has to be 5s.

I agree, it has to be 5s. The discussion was about what timeline is
displayed and what can the user easily access through seeking through
the displayed timeline. A script can access any time of course. But a
user is restricted by what the user interface offers.


>> So, the difference is that in HTML the user agent will always have the
>> context available within its download buffer, while for video this may
>> not be the case.
>
> I'm sorry, I am lost. ?We could quite easily extend HTTP to allow for
> anchor-based retrieval of HTML (i.e. convert a 'please start at anchor X'
> into a pair of byte-range responses, for the global material, and then the
> document from that anchor onwards).

Yes, but that's not the way it currently works and it is not a
proposal currently under discussion.


>> This admittedly technical difference also has an influence on the user
>> interface.
>>
>> If you have all the context available in the user agent, it is easy to
>> just grab a scroll-bar and jump around in the full content manually to
>> look for things. This is not possible in the video case without many
>> further download actions, which will each incur a network delay. This
>> difference opens the door to enable user agents with a choice in
>> display to either provide the full context, or just the fragment
>> focus.
>
> But we can optimize for the fragment without disallowing the seeking.

What do you mean by "optimize for the fragment"? Of course none of the
discussion will inherently disallow seeking - scripts will always be
able to do the seeking. But the user may not find it easy to do
seeking to a section that is not accessible through the displayed
timeline, which can be both a good and a bad thing.


Cheers,
Silvia.

From brucel at opera.com  Sat May  9 00:45:40 2009
From: brucel at opera.com (Bruce Lawson)
Date: Sat, 09 May 2009 08:45:40 +0100
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
 audio/ video
In-Reply-To: <dd0fbad0905071810w23c1013ajd512044cb4831f0b@mail.gmail.com>
References: <op.utkff1ldh8on37@bruce-pc>
	<dd0fbad0905071810w23c1013ajd512044cb4831f0b@mail.gmail.com>
Message-ID: <op.utnjuecqh8on37@bruce-pc>

On Fri, 08 May 2009 02:10:20 +0100, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Thu, May 7, 2009 at 10:17 AM, Bruce Lawson <brucel at opera.com> wrote:

>> Should autoplay be removed as an attribute of audio and video, precisely
>> to remove such annoyance from people who rely on aural browsing? While
>> there are video sites such as youTube that do play videos automatically,
>> others such as vimeo don't. Is there an archive that lists the use-cases
>> for autoplay and contrasts it with the "annoyance" and accessibility
>> issues?.

I'm convinced by Simon Pieters that removing the autoplay attribute  
wouldn't solve matters as people would just use script, and a browser  
option that disables autoplay across the board is better.

But that adds weight to  my greater argument for a mandatory control on  
autoplayed media allowing user to mute sound. Relying in the operating  
system's volume control is not the option as that mutes the offending  
sound *and* screenreader output, so the rest of the content is inaudible.

> I don't see why this should be a browser requirement.  UAs are
> *allowed* to provide such a facility to their users, so if your UA
> doesn't, complain until they do!

Perfect solution for those who live in Utopia. But as many users neither  
choose their browsers, or are unable to change them, it's better to  
require it of the browser.

bruce



-- 
Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From julian.reschke at gmx.de  Sat May  9 03:54:04 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 09 May 2009 12:54:04 +0200
Subject: [whatwg] Micro-data/Microformats/RDFa
	Interoperability	Requirement
In-Reply-To: <4A039BB1.4050703@digitalbazaar.com>
References: <4A0104C2.8080009@digitalbazaar.com>	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>	<4A02F6AE.1000602@digitalbazaar.com>	<Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>
	<4A039BB1.4050703@digitalbazaar.com>
Message-ID: <4A0560CC.2090507@gmx.de>

Manu Sporny wrote:
> ...
> The second is that you are assuming that @rel/@rev reserved attribute
> values are the same for all XML and non-XML family languages - they
> aren't. Reserved words such as "next" and "prev" can be defined per
> language - or, none can be defined... it's up to the language adopting
> RDFa to define those values. For a list of the current values, you can see:
> ...

They currently can be defined per language, but that doesn't make it a 
good idea.

You are aware of MNot's "Web Linking" draft 
(<http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html>), 
and the fact that it seems to enjoy support from the TAG?

BR, Julian

From jackalmage at gmail.com  Sat May  9 14:16:56 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sat, 9 May 2009 16:16:56 -0500
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
	audio/ video
In-Reply-To: <op.utnjuecqh8on37@bruce-pc>
References: <op.utkff1ldh8on37@bruce-pc>
	<dd0fbad0905071810w23c1013ajd512044cb4831f0b@mail.gmail.com>
	<op.utnjuecqh8on37@bruce-pc>
Message-ID: <dd0fbad0905091416r5074e29ayd02a205328816a02@mail.gmail.com>

On Sat, May 9, 2009 at 2:45 AM, Bruce Lawson <brucel at opera.com> wrote:
> On Fri, 08 May 2009 02:10:20 +0100, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
>> I don't see why this should be a browser requirement. ?UAs are
>> *allowed* to provide such a facility to their users, so if your UA
>> doesn't, complain until they do!
>
> Perfect solution for those who live in Utopia. But as many users neither
> choose their browsers, or are unable to change them, it's better to require
> it of the browser.

Browser developers are typically attentive to accessibility issues,
especially when they can be resolved by something as easy as a simple
config entry.  A SHOULD would be sufficient there.

The issue is that not all browsers have significant configs (I'm
thinking of mobile browsers here), and I don't believe their inability
to provide such a choice to the user should make them nonconforming.

As well, recall that the majority browser for 'unsophisticated' users
is still IE6 or 7, and IE8 still lacks any support for <video> at all,
so those users will be stuck dealing with js and flash-based video for
some time still.  Marginally more savvy users will be using FF, Opera,
or Safari, all of which I believe would likely be receptive to this
change.

~TJ

From msporny at digitalbazaar.com  Sat May  9 19:37:45 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat, 09 May 2009 22:37:45 -0400
Subject: [whatwg] Micro-data/Microformats/RDFa
	Interoperability	Requirement
In-Reply-To: <Pine.LNX.4.62.0905081833080.7824@hixie.dreamhostps.com>
References: <4A0104C2.8080009@digitalbazaar.com>
	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>
	<4A02F6AE.1000602@digitalbazaar.com>
	<Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>
	<4A039BB1.4050703@digitalbazaar.com>
	<Pine.LNX.4.62.0905081833080.7824@hixie.dreamhostps.com>
Message-ID: <4A063DF9.5010608@digitalbazaar.com>

Ian Hickson wrote:
> On Thu, 7 May 2009, Manu Sporny wrote:
>> That's certainly not what the WHATWG blog stated just 20 days ago for
>> rel="license" [...]
> 
> The WHATWG blog is an open platform on which anyone can post, and content 
> is not vetted for correctness. Mark can sometimes make mistakes. Feel free 
> to post a correction. :-)

Well, the problem is that I don't know who to correct - you or Mark.
It's unclear to me if it's the spec that needs correcting or the blog post?

> For rel-license, the HTML5 spec defines the value to apply to the content 
> and not the page as a whole. This is a recent change to match actual 
> practice and I will be posting about this shortly.

Hmm, yes - after re-reading the definitions, they do differ...
especially in how the hAudio Microformat uses rel="license". I find the
HTML5 one to be very problematic. Microformats rel="license" is better,
and the RDFa use of rel="license" is even better (I can go into the
reasoning if those on the list are curious).

For example, in HTML5, how do you express 20 items on a page, each with
separate licenses? How do you differentiate a page that has 3 primary
topics, each with a separate license?

In short - what's the purpose of rel="license" if a machine can't use it
to help the person browsing identify important sections of a page?
Afterall, it's only machine readable, isn't it? What's the sense in
having rel="license" if a machine can't be sure of the section of the
page to which it applies?

>>> Surely this is what namespaces were intended for.
>> Uhh, what sort of namespaces are we talking about here? xmlns-style, 
>> namespaces?
> 
> The idea of XML Namespaces was to allow people to extend vocabularies
> with a new features without clashing with older features by putting the 
> new names in new namespaces. It seems odd that RDFa, a W3C technology for 
> an XML vocabulary, didn't use namespaces to do it.

As you are aware, the RDF in XHTML 1.1 Task Force was created to figure
out a way to express RDF via XHTML. The standard mechanism for extending
XHTML is XHTML Modularization[1]. From the XHTML modularization spec:

"""
This modularization provides a means for subsetting and extending
XHTML... this specification is intended for use by language designers as
they construct new XHTML Family Markup Languages.
"""

We used the standard mechanism, specifically designed to extend XHTML
vocabularies, approved by the XHTML working group, the W3C TAG and a
number of other W3C and public web groups, to extend the language.

Had we been tasked with expressing RDF in XML, we would have called it
RDF/XML[2]... :)

>>>>> For example, the way that "n:next" and "next" can end up being 
>>>>> equivalent in RDFa processors despite being different per HTML rules 
>>>>> (assuming an "n" namespace is appropriately declared).
>>>> If they end up being equivalent in RDFa, the RDFa author did so 
>>>> explicitly when declaring the 'n' prefix to the default prefix 
>>>> mapping and we should not second-guess the authors intentions.
>>> My only point is that it is not compatible with HTML4 and HTML5, 
>>> because they end up with different results in the same situation (one 
>>> can treat two different values as the same, while the other can treat 
>>> two different values as different).
>> It is only not compatible with HTML5 if this community chooses for it to 
>> not be compatible with HTML5. Do you agree or disagree that we shouldn't 
>> second guess the authors intentions if they go out of their way to 
>> declare a mapping for 'n'?
> 
> I don't think that's a relevant question. My point is that it is possible 
> in RDFa to put two strings that have different semantics in HTML4 and yet 
> have them have the same semantics in RDFa. This means RDFa is not 
> compatible with HTML4.

Of course it's relevant - the whole reason there are two strings with
the same semantics, in your rather contrived example, is because the
author went out of their way to make the statement. This doesn't happen
by accident - the web page author intended it to happen.

More importantly - you've just made the same statement twice in RDFa and
once in HTML4. I can't think of a single technically significant
negative repercussion for generating a duplicate triple in a corner
case. Why does one duplicated triple in a contrived example mean that
the entirety of RDFa isn't compatible with HTML4?

More importantly, if you see this as an issue, why don't you see the
semantic difference between rel="alternate"[3] in HTML4 and
rel="alternate"[4] in HTML5 as being an issue? That case is even worse,
exactly the same string - entirely different semantics.

If HTML4 validation is a concern, there's even a preliminary HTML4+RDFa
DTD that is available:

http://www.w3.org/MarkUp/DTD/html4-rdfa-1.dtd

I do get your point - but why should we be concerned about it?

>>> Browser vendors would not accept having to resolve prefixes in 
>>> attribute values as part of processing link relations.
>> Why not?
> 
> You would have to ask them. I tend not to argue with implementor feedback. 
> If they tell me they won't do something, I don't tell them to do it.

I would expect the primary editor for a web specification to understand
the reason that every single one of their implementors refuse to
implement a technique that they use elsewhere in their products. Since
I've successfully implemented this stuff[5] - I know how easy it is to
do what we're proposing.

I'd love to ask eacho of them why it is perceived as difficult and
discuss possible solutions. A public e-mail would be best so that we can
discuss on this list, but a private e-mail would be fine as well. So
please, if your organization has decided to not resolve prefixes in
attribute values, please send me an e-mail.

After two weeks, I'll check back in with the mailing list to report on
the number of responses I received and a summary of the reasoning
(anonymized, of course) for the benefit of this community.

> This by the way is the complaint regarding "QNames in content" and "QNames 
> in attribute values". CURIEs don't change this, which is why you'll find a 
> lot of people just say that CURIEs are no different to QNames.

We are having a technical discussion and therefore it behooves us to be
technically accurate when describing a particular technology. It is
technically inaccurate to refer to CURIEs and QNames interchangeably
just as it is technically inaccurate to refer to HTML5 and HTML4
interchangeably.

I should also point out that there has been no technical reason
expressed as to why "the complaint" is valid.

>> The only similarity they have is that they can be expanded to full URIs.
> 
> That's the complaint. (Specifically, that they can do so in a dynamic 
> fashion -- e.g. what happens if a user changes a prefix="" or xmlns:*="" 
> attribute value dynamically from script? Do all the RDFa triples change 
> too?)

If you run the RDFa processing rules right after the change, yes, of
course a subset of the RDFa triples would change. Why is this a
technical issue?

Since the author has decided, via code, to change the prefix mappings -
they are making a statement that they would like the semantics of the
page to change.

Put another way, if you do this:

var color="red";

and then use 'color' in your CSS styling via Javascript for one
iteration of your page render (say to set some red text). Then you go
and change the color to 'green', and do a second iteration of your page
render - wouldn't you expect the colors that were 'red' to change to
'green'?

We do this sort of thing all the time with CSS. What is the exact
technical issue with this approach?

>>> The problem with QNames in attributes is that they require the 
>>> attribute processor to have information from the namespace processor, 
>>> and as far as I can tell this continues to exist in RDFa.)
>> If that's really the problem, why don't you just have a prefix processor 
>> that the attribute processor relies on and drop the namespace processor 
>> entirely?
> 
> There are two fundamental problems, one is with having the prefix 
> processor be used by code that is in the XML parser and code that is very 
> separate from the XML parser (e.g. based on DOM code) -- implementors find 
> combining the two to be highly impractical 

I find that hard to believe. It may be valid, but we have a number of
entirely SAX-based and DOM-based implementations of RDFa in XHTML done
in a variety of languages (C, Javascript, Python, Perl, Ruby, C#, etc.)
and not one of our implementors complained about this "problem".

> and the other is that the 
> prefix processor has to handle dynamic changes to prefixes.

Again, why is this a technical issue?

-- manu

[1]http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/
[2]http://www.w3.org/TR/rdf-syntax-grammar/
[3]http://www.w3.org/TR/html401/types.html#type-links
[4]http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-alternate
[5]http://rdfa.digitalbazaar.com/librdfa/trac/

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From msporny at digitalbazaar.com  Sat May  9 21:11:22 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun, 10 May 2009 00:11:22 -0400
Subject: [whatwg] Helping people seaching for content filtered by license
In-Reply-To: <Pine.LNX.4.62.0905072258380.18851@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0905072258380.18851@hixie.dreamhostps.com>
Message-ID: <4A0653EA.5060508@digitalbazaar.com>

Ian Hickson wrote:
> The scenarios described above fall into three categories: searching for 
> content, publishing content, and obtaining legal advice.

Ian, these use cases and your responses to them need to be put up on a
wiki somewhere - not many people have the time to read through 20 use
cases each with numerous scenarios/requirements and argumentation.

It's going to be very difficult for anybody other than you to piece
together what has been addressed and what has not been addressed.

In addition, transparency and ease of access during this process should
be a requirement. Transparency cannot happen unless you post all of the
information that you have to some permanent location.

Both Shelley Powers and I have offered to help do this, I strongly
suggest you take us up on the offer as we want to be thorough and
careful as we go through these use cases. Most importantly, we want to
start generating preliminary documentation for HTML5's microdata facilities.

> First, I will examine the search scenario:
> 
>      * If a user is looking for recipes of pies to reproduce on his blog, he
>        might want to exclude from his results any recipes that are not
>        available under a license allowing non-commercial reproduction.
> 
> This is technically possible today. The rel="license" link type allows 
> authors to specify the license that applies to the main content on a page, 
> in this case recipes, search engines can be programmed with the most 
> common licenses, and the user can tell the search engine what 
> characteristics he wants ("compatible with GPLv2", "no advertising 
> clause", "doesn't have patent implications", "allows redistribution to 
> countries on the US blacklist").
> 
> This has some implications:
> 
>  - Each unit of content (recipe in this case) must have its own 
>    independent page at a distinct URL. This is actually good practice 
>    anyway today for making content discoverable from search engines, and 
>    it is compatible with what people already do, so this seems fine.
> 
>  - New licenses are discouraged, as they would not be automatically 
>    supported by search engines. This is needed by one of the requirements:
> 
>      * License proliferation should be discouraged.
> 
> This solution is already deployed on such sites as Flickr, and already 
> supported on search engines such as Google.

This isn't a solution to the problem because of the following issues:

- Search engines shouldn't be the gatekeeper when it comes to "valid"
  and "invalid" licenses. New licenses shouldn't be discouraged as
  they're vital to keep up with ever changing laws around the world. I
  don't want to wait around for search engines to decide that supporting
  a particular license is in their best interest.

- You're forcing recipe page authors to publish their documentation in a
  very specific way (one recipe per page). That seems like a very
  arbitrary limitation. What if I have a goat cheese recipe
  (attribution, non-commercial) that has a jam recipe
  (attribution, share-alike) that pairs very well with the cheese.
  Personally, I'd want to put both recipes on the same page and
  rel="license" has a limitation that it only applies to the "main
  content" on the page in HTML5. Why is HTML5 forcing me to publish one
  recipe per page if I want to ensure that my license information is
  machine-readable?

> Next, I will look at the content publishing scenarios:
> 
>      * Lucy wants to publish her papers online. She includes an abstract of
>        each one in a page, but because they are under different copyright
>        rules, she needs to clarify what the rules are. A harvester such as
>        the Open Access project can actually collect and index some of them
>        with no problem, but may not be allowed to index others. Meanwhile, a
>        human finds it more useful to see the abstracts on a page than have to
>        guess from a bunch of titles whether to look at each abstract.
> 
> This really boils down to two points:
> 
>  - Being able to include the license of various items on a page for humans 
>    to read.
> 
>  - Being able to control what harvesters (spiders) index.
> 
> Being able to include a license on a page is easy: you just include the 
> license name and a link to the license. Since this is for the user in this 
> case, there is no need for any special markup.

Including a link to a license is very different from making that license
automatically machine-readable. Expressing, to the spider, what rights
it has on that particular page is not as simple as linking to a license.
Sure, you can hard code certain rights and associate them with certain
license URLs - but that's a hack, it's not a good general purpose solution.

> Controlling harvesters is a separate problem. This is actually a 
> well-understood problem space with a number of very well-understood 
> solutions. For site-wide control, there is robots.txt, which can target 
> individual spiders (as in this case). On a page-by-page basis, there is 
> the <meta> element's "noindex" value.

Not all authors have access to the robots.txt file (in fact, the
majority of researchers I know use a CMS and do not have any access to
robots.txt). Not all researchers have access to the HEAD of the document
via <meta> either. So, this isn't a viable general purpose solution.

> Thus this particular scenario doesn't require any new features.
> 
>      * There are mapping organisations and data producers and people who take
>        photos, and each may place different policies. Being able to keep that
>        policy information helps people with further mashups avoiding
>        violating a policy. For example, if GreatMaps.com has a public domain
>        policy on their maps, CoolFotos.org has a policy that you can use data
>        other than images for non-commercial purposes, and Johan Ichikawa has
>        a photo there of my brother's cafe, which he has licensed as "must pay
>        money", then it would be reasonable for me to copy the map and put it
>        in a brochure for the cafe, but not to copy the data and photo from
>        CoolFotos. On the other hand, if I am producing a non-commercial guide
>        to cafes in Melbourne, I can add the map and the location of the cafe
>        photo, but not the photo itself.
> 
> This doesn't seem to require any technological solution at all; it seems 
> to be purely a legal issue. So long as the licenses are clearly stated, as 
> they presumably must be (for example, the MIT license requires the 
> copyright text to follow the text even as it is copied, the Creative 
> Commons licenses require the license or its URL to be published with any 
> reproductions, etc), there is no need for any markup.

Read the scenario more closely - the goal of the scenario is to "help
people with further mashups [to avoid] violating a policy". This means
that all of the objects in the scenario must be tagged with licensing
information of some kind. As it is explained above, HTML5 doesn't
currently have that ability via rel="license". The technological
solution could warn the person when they download the image of their
rights associated with the image. The operating system could even
associate the licensing information with the image when it is stored to
the local file system.

This is not just a legal issue - there are ways that this information
could help people comply with legal policies. I find Flickr's
"Attribution Creative Commons licenses" search feature incredibly useful
- it would be even more useful if all documents on the web had that
information associated with them.

>      * Tara runs a video sharing web site for people who want licensing
>        information to be included with their videos. When Paul wants to blog
>        about a video, he can paste a fragment of HTML provided by Tara
>        directly into his blog. The video is then available inline in his
>        blog, along with any licensing information about the video.
> 
> (Really? A video sharing site dedicated to people who want licensing 
> information to be included with their videos? That's a pretty specific 
> audience, wow.)

It's not specific at all - video rights clearinghouses are a big
business in news, documentaries, television and blockbuster movies.
There are hundreds of companies just like this one:

http://www.thoughtequity.com/

> This can be done with HTML5 today. For example, here is the markup you 
> could include to allow someone to embed a video on their site while 
> including the copyright or license information:
> 
>    <figure>
>     <video src="http://example.com/videodata/sJf-ulirNRk" controls>
>      <a href="http://video.example.com/watch?v=sJf-ulirNRk">Watch</a>
>     </video>
>     <legend>
>      Pillar post surgery, starting to heal.
>      <small>&copy; copyright 2008 Pillar. All Rights Reserved.</small>
>     </legend>
>    </figure>

That's not machine readable - where in the HTML5 spec does it say that
"license information for videos will be placed in a SMALL element". Even
if that were the case, how would a machine be able to extract the rights
associated with the license?

>      * Flickr has images that are CC-licensed, but the pages themselves are
>        not.

Flickr already uses RDFa to express the rights for the images, which is
impossible to do in HTML5:

http://www.flickr.com/photos/vegaseddie/3339507278/

More specifically, these are a few of the RDFa triples embedded in that
page that contain information pertinent to the license (TURTLE triple
syntax):

<http://www.flickr.com/photos/vegaseddie/3339507278/>
     cc:attributionURL <http://www.flickr.com/photos/vegaseddie/> ;
     cc:license <http://creativecommons.org/licenses/by/2.0/deed.en> ;
     dc:creator <http://www.flickr.com/photos/vegaseddie/> ;
     dc:title "Baboon" ;
     xhv:license <http://creativecommons.org/licenses/by/2.0/deed.en> ;
<http://www.flickr.com/photos/vegaseddie/> foaf:name "Paolo Camera" .

(Triples extracted via pyRdfa: http://www.w3.org/2007/08/pyRdfa/)

> I've clarified the HTML5 spec's definition of rel=license and included an 
> example showing a page based on what Flickr is doing.

Just changing rel="license" is not going to be sufficient. You will have
to express the same information, as shown above, in HTML5 if you would
like to support the same functionality that Flickr supports today.

This e-mail only covers the first 1/3rd of this single use case - as you
can see, there are still many issues to resolve. I'll go through the
rest of this use case e-mail when I have some more free time... hope
this helps. :)

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From brucel at opera.com  Sun May 10 00:58:47 2009
From: brucel at opera.com (Bruce Lawson)
Date: Sun, 10 May 2009 08:58:47 +0100
Subject: [whatwg] request for clarification: aside, figure
Message-ID: <op.utpe39xth8on37@bruce-pc>

I don't think the spec is clear enough defining these two elements from an  
author's perspective.

"The aside element represents a section of a page that consists of content  
that is tangentially related to the content around the aside element, and  
which could be considered separate from that content."

"The figure element represents some flow content, optionally with a  
caption, which can be moved away from the main flow of the document  
without affecting the document's meaning.

What is the difference between a <figure> that has no caption and an  
<aside>? Both seem to be connected in some way with the main content  
around it, but can be considered separate/ may be moved.

Common-sense suggests that a figure is usually an  illustration/ diagram/  
picture, but doesn't have to be (the spec gives an example of the poem  
Jabberwocky marked up as a figure).

So If I have a magazine-style pullquote, is that a figure or an aside (or  
neither)?

For example, in the middle of a fictional interview about markup, I might  
want to pull out a quote and citation: Do I write

<aside>
<blockquote>After a sip of sweet sherry, I turn into Mr Last  
Week</blockquote>
<cite>Ian Hickson</cite>
</aside>

Or

<figure>
<blockquote>After a sip of sweet sherry, I turn into Mr Last  
Week</blockquote>
<legend>Ian Hickson</cite>
</aside>



-- 
Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From brucel at opera.com  Sun May 10 01:07:38 2009
From: brucel at opera.com (Bruce Lawson)
Date: Sun, 10 May 2009 09:07:38 +0100
Subject: [whatwg] request for clarification: aside, figure
In-Reply-To: <op.utpe39xth8on37@bruce-pc>
References: <op.utpe39xth8on37@bruce-pc>
Message-ID: <op.utpfi0rzh8on37@bruce-pc>

On Sun, 10 May 2009 08:58:47 +0100, Bruce Lawson <brucel at opera.com> wrote:

Typo in last email: I meant

For example, in the middle of a fictional interview about markup, I might
want to pull out a quote and citation: Do I write

<aside>
<blockquote>After a sip of sweet sherry, I turn into Mr Last
Week</blockquote>
<cite>Ian Hickson</cite>
</aside>

Or

<figure>
<blockquote>After a sip of sweet sherry, I turn into Mr Last
Week</blockquote>
<legend>Ian Hickson</legend>
</figure>

From ian at hixie.ch  Sun May 10 03:32:34 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 10 May 2009 10:32:34 +0000 (UTC)
Subject: [whatwg] Annotating structured data that HTML has no semantics for
Message-ID: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>


One of the more elaborate use cases I collected from the e-mails sent in 
over the past few months was the following:

   USE CASE: Annotate structured data that HTML has no semantics for, and
   which nobody has annotated before, and may never again, for private use or
   use in a small self-contained community.

   SCENARIOS:
     * A group of users want to mark up their iguana collections so that they
       can write a script that collates all their collections and presents
       them in a uniform fashion.
     * A scholar and teacher wants other scholars (and potentially students)
       to be able to easily extract information about what he teaches to add
       it to their custom applications.
     * The list of specifications produced by W3C, for example, and various
       lists of translations, are produced by scraping source pages and
       outputting the result. This is brittle. It would be easier if the data
       was unambiguously obtainable from the source pages. This is a custom
       set of properties, specific to this community.
     * Chaals wants to make a list of the people who have translated W3C
       specifications or other documents, and then use this to search for
       people who are familiar with a given technology at least at some
       level, and happen to speak one or more languages of interest.
     * Chaals wants to have a reputation manager that can determine which of
       the many emails sent to the WHATWG list might be "more than usually
       valuable", and would like to seed this reputation manager from
       information gathered from the same source as the scraper that
       generates the W3C's TR/ page.
     * A user wants to write a script that finds the price of a book from an
       Amazon page.
     * Todd sells an HTML-based content management system, where all
       documents are processed and edited as HTML, sent from one editor to
       another, and eventually published and indexed. He would like to build
       up the editorial metadata used by the system within the HTML documents
       themselves, so that it is easier to manage and less likely to be lost.
     * Tim wants to make a knowledge base seeded from statements made in
       Spanish and English, e.g. from people writing down their thoughts
       about George W. Bush and George H.W. Bush, and has either convinced
       the people making the statements that they should use a common
       language-neutral machine-readable vocabulary to describe their
       thoughts, or has convinced some other people to come in after them and
       process the thoughts manually to get them into a computer-readable
       form.

   REQUIREMENTS:
     * Vocabularies can be developed in a manner that won't clash with future
       more widely-used vocabularies, so that those future vocabularies can
       later be used in a page making use of private vocabularies without
       making the earlier annotations ambiguous.
     * Using the data should not involve learning a plethora of new APIs,
       formats, or vocabularies (today it is possible, e.g., to get the price
       of an Amazon product, but it requires learning a new API; similarly
       it's possible to get information from sites consistently using 'class'
       values in a documented way, but doing so requires learning a new
       vocabulary).
     * Shouldn't require the consumer to write XSLT or server-side code to
       process the annotated data.
     * Machine-readable annotations shouldn't be on a separate page than
       human-readable annotations.
     * The information should be convertible into a dedicated form (RDF,
       JSON, XML) in a consistent manner, so that tools that use this
       information separate from the pages on which it is found have a
       standard way of conveying the information.
     * Should be possible for different parts of an item's data to be given
       in different parts of the page, for example two items described in the
       same paragraph. ("The two lamps are A and B. The first is $20, the
       second $30. The first is 5W, the second 7W.")
     * It should be possible to define globally-unique names, but the syntax
       should be optimised for a set of predefined vocabularies.
     * Adding this data to a page should be easy.
     * The syntax for adding this data should encourage the data to remain
       accurate when the page is changed.
     * The syntax should be resilient to intentional copy-and-paste
       authoring: people copying data into the page from a page that already
       has data should not have to know about any declarations far from the
       data.
     * The syntax should be resilient to unintentional copy-and-paste
       authoring: people copying markup from the page who do not know about
       these features should not inadvertently mark up their page with
       inapplicable data.
     * Any additional markup or data used to allow the machine to understand
       the actual information shouldn't be redundantly repeated (e.g. on each
       cell of a table, when setting it on the column is possible).
     * Parsing rules should be unambiguous.
     * Should not require changes to HTML5 parsing rules.
     * Creating a custom vocabulary should be relatively easy.
     * Distributed vocabulary development should be possible; it
       should not require coordination through a centralised system.
     * It should be possible to publish and re-use custom
       vocabularies.


Some of the scenarios for this use case required substantial additions to 
the spec, so before I go through the scenarios, I will describe how I 
ended up putting what I did into the spec.

Let's base this on a variant of the first scenario:

     * A group of users want to mark up their iguana collections so that they
       can write a script that collates all their collections and presents
       them in a uniform fashion.

I don't know anything about iguanas, but let's pretend it's about cats, 
which should be basically the same thing from a markup perspective. Let's 
say someone in the group has the following text on http://example.org/:

     <section>
      <h1>Hedral</h1>
      <p>Hedral is a male american domestic shorthair, with a fluffy black 
      fur with white paws and belly.</p>
      <img src="hedral.jpeg" alt="" title="Hedral, age 18 months" 
      class="photo">
     </section>

...and suppose that they want to make it so that the following information 
can be extracted from this part of this page:

   Cat name:    "Hedral"
   Description: "Hedral is a male american domestic shorthair, with a 
                 fluffy black fur with white paws and belly."
   Image:       "http://example.org/hedral.jpeg"

Let's presume there are several authors each with their own distinct and 
differently-structured pages who all want to cooperate so that a single 
script can be used to amalgamate the information stored in their pages to 
print a table summarising this information about their cats.

The simplest solution would be for them to define a basic vocabulary using 
class names and just have them extract the data based on these class 
names, a la Microformats. The markup above might become:

     <section>
      <h1 class="name">Hedral</h1>
      <p class="desc">Hedral is a male american domestic shorthair, with a 
      fluffy black fur with white paws and belly.</p>
      <img src="hedral.jpeg" alt="" title="Hedral, age 18 months" 
      class="photo img">
     </section>

This works well; a script can be written to just rip out the relevant 
data. Unfortunately it has a couple of problems:

 - it is likely that the class names will clash with other classes used by 
   other people, which would make it hard to handle situations where 
   different communities want to work together.

 - there is no way to group information about each cat together on a page 
   with multiple cats.

 - there is no way for a parser to know which classes are properties of 
   cats and which are just for styling (e.g. 'photo' used in this 
   example).

The first problem is easy to solve, we can just use more unique class 
names, e.g. com.damowmow.name, com.damowmow.desc, and com.damowmow.img:

     <section>
      <h1 class="com.damowmow.name">Hedral</h1>
      <p class="com.damowmow.desc">Hedral is a male american domestic 
      shorthair, with a fluffy black fur with white paws and belly.</p>
      <img src="hedral.jpeg" alt="" title="Hedral, age 18 months" 
      class="photo com.damowmow.img">
     </section>

The second is harder to solve. We could introduce a class name that says 
"this is a cat", much like the way Microformats do, but then parsers would 
need to know about the "root class names" (to use the Microformats term) 
to know where to begin collecting data.

The third problem is somewhat of a blocker, and is the most common 
complaint I heard from people about Microformats.


Another solution we could consider is RDFa:

     <section typeof="d:cat" xmlns:d="http://damowmow.com/">
      <h1 property="d:name">Hedral</h1>
      <p property="d:desc">Hedral is a male american domestic shorthair, 
      with a fluffy black fur with white paws and belly.</p>
      <img src="hedral.jpeg" alt="" title="Hedral, age 18 months" 
      class="photo" rel="d:img">
     </section>

This unfortunately also has a number of problems.

 - it uses prefixes, which most authors simply do not understand, and 
   which many implementors end up getting wrong (e.g. SearchMonkey 
   hard-coded certain prefixes in its first implementation, Google's 
   handling of RDF blocks for license declarations is all done with 
   regular expressions instead of actually parsing the namespaces, etc).
   Even if implemented right, namespaces still lead to flaky 
   copy-and-paste behaviour.

 - it sometimes uses rel="" and sometimes uses property="" and it's hard 
   to know when to use one or the other.

 - it introduces much more power than is necessary to solve this problem.

We can fix the first problem by using URLs instead, and using the 
xmlns:http trick to keep things working in RDFa processors:

     <section typeof="http://damowmow.com/cat" xmlns:http="http:">
      <h1 property="http://damowmow.com/name">Hedral</h1>
      <p property="http://damowmow.com/desc">Hedral is a male american 
      domestic shorthair, with a fluffy black fur with white paws and 
      belly.</p>
      <img src="hedral.jpeg" alt="" title="Hedral, age 18 months" 
      class="photo" rel="http://damowmow.com/img">
     </section>

This, though, is quite ugly. An alternative is to go back to the non-URI 
class names we had above. This doesn't break compatibility with the RDFa 
processors, because when there is no colon in the property="" or rel="" 
attributes, the RDFa processors just ignore the values (this is the "no 
prefix" mapping of CURIEs):

     <section typeof="com.damowmow.cat">
      <h1 property="com.damowmow.name">Hedral</h1>
      <p property="com.damowmow.desc">Hedral is a male american 
      domestic shorthair, with a fluffy black fur with white paws and 
      belly.</p>
      <img src="hedral.jpeg" alt="" title="Hedral, age 18 months" 
      class="photo" rel="com.damowmow.img">
     </section>

At this point though we might as well change rel="" to property="" and 
just say that on <img> it takes the value from src="", because that's 
going to be a lot more understandable, and won't affect RDFa processors 
(which at this point are ignoring the values):

     <section typeof="com.damowmow.cat">
      <h1 property="com.damowmow.name">Hedral</h1>
      <p property="com.damowmow.desc">Hedral is a male american 
      domestic shorthair, with a fluffy black fur with white paws and 
      belly.</p>
      <img src="hedral.jpeg" alt="" title="Hedral, age 18 months" 
      class="photo" property="com.damowmow.img">
     </section>

This has us past the first two problems listed above for RDFa, but we 
still have the third, if we were to adopt the rest of RDFa -- way too much 
power to solve this problem. So instead, let's assume we're sticking with 
just these two attributes, typeof="" and property="", in the "prefix-less" 
CURIE space. This gives us a very small subset of RDFa to start from.

Let's see if this works well for other ways of marking up cat data:

     <body typeof="com.damowmow.cat">
      <p>I love my cats. My oldest cat is <span
      property="com.damowmow.name">Silver</span>. <span
      property="com.damowmow.desc">Silver is <span
      property="com.damowmow.age">11</span> years old and refuses to eat
      alone, always waiting for either Yellow or Blue to eat with
      him.</p>
     </body>

This seems fine. This example shows overlapping properties, so that data 
can be extracted from within the value of another.


At this point, I would like to introduce another example, also taken from 
the scenarios above, to examine if this works well in other scenarios:

     * The list of specifications produced by W3C, for example, and various
       lists of translations, are produced by scraping source pages and
       outputting the result. This is brittle. It would be easier if the data
       was unambiguously obtainable from the source pages. This is a custom
       set of properties, specific to this community.

Let's presume that each spec has the following structure:

   Name:
   URL:
   Status:
     Level:
     Publication Date:
     Comments Deadline:
   Working Group:

This might be encoded as:

   <div typeof="org.w3.spec">
    <h1 property="org.w3.name">HTML5</h1>
    <a property="org.w3.url" href="/TR/html5">Current Version</a>
    <div property="org.w3.status">
     <p>Level: <span property="org.w3.level">WD</span>
     <p>Date: <span property="org.w3.pubdate">03/02/2009</span>
     <p>Deadline: <span property="org.w3.deadline">02/03/2009</span>
    </div>
    <p>Working Group: <span property="org.w3.wg">HTMLWG</span>
   </div>

There is a problem here. The original structure has "status" as a property 
with three sub-properties, but according to the "minimal RDFa" convention 
we've come up with so far, the markup here has "status" as containing a 
long string and the other properties are at the top level, like this:

   Name: "HTML5"
   URL: "/TR/html5"
   Status: "Level: WD Date: 2009-03-02 Deadline: 2010-01-01"
   Level: "WD"
   Publication Date: "03/02/2009"
   Comments Deadline: "02/03/2009"
   Working Group: "HTMLWG"

What we need is a way to say that a property is really a new set of 
name-value pairs. If we look at the current markup, we are using typeof="" 
for this, but typeof="" expects a type as its value, whereas here we 
don't need an explicit type. We could just say typeof="" can be used 
without a type:

   <div typeof="org.w3.spec">
    <h1 property="org.w3.name">HTML5</h1>
    <a property="org.w3.url" href="/TR/html5">Current Version</a>
    <div property="org.w3.status" typeof>
     <p>Level: <span property="org.w3.level">WD</span>
     <p>Date: <span property="org.w3.pubdate">03/02/2009</span>
     <p>Deadline: <span property="org.w3.deadline">02/03/2009</span>
    </div>
    <p>Working Group: <span property="org.w3.wg">HTMLWG</span>
   </div>

But that doesn't make much sense and isn't allowed in RDFa anyway.

Let's rename "typeof" to "item" instead:

   <div item="org.w3.spec">
    <h1 property="org.w3.name">HTML5</h1>
    <a property="org.w3.url" href="/TR/html5">Current Version</a>
    <div property="org.w3.status" item>
     <p>Level: <span property="org.w3.level">WD</span>
     <p>Date: <span property="org.w3.pubdate">03/02/2009</span>
     <p>Deadline: <span property="org.w3.deadline">02/03/2009</span>
    </div>
    <p>Working Group: <span property="org.w3.wg">HTMLWG</span>
   </div>

Now the result makes more sense:

   Name: "HTML5"
   URL: "/TR/html5"
   Status:
     Level: "WD"
     Publication Date: "03/02/2009"
     Comments Deadline: "02/03/2009"
   Working Group: "HTMLWG"

While we're at it, we should use the <time> element for encoding those 
dates, so that we don't have work out if the deadline is before the 
publication date or if these are weird US-format dates:

   <div item="org.w3.spec">
    <h1 property="org.w3.name">HTML5</h1>
    <a property="org.w3.url" href="/TR/html5">Current Version</a>
    <div property="org.w3.status" item>
     <p>Level: <span property="org.w3.level">WD</span>
     <p>Date: <time property="org.w3.pubdate" datetime="2009-02-03">03/02/2009</time>
     <p>Deadline: <time property="org.w3.deadline" datetime="2009-03-02">02/03/2009</time>
    </div>
    <p>Working Group: <span property="org.w3.wg">HTMLWG</span>
   </div>

(So, <img> gets its content from src="", <time> gets its content from 
datetime="", and everything else gets its content from the element's own 
contents, serialised to text.)


One of the requirements is the following:

     * Should be possible for different parts of an item's data to be given
       in different parts of the page, for example two items described in the
       same paragraph. ("The two lamps are A and B. The first is $20, the
       second $30. The first is 5W, the second 7W.")

Here we have two "items" (to use the terminology that the attribute name 
above implies), but they are mixed together.

   <p>The two lamps are A and B. The first is $20, the
   second $30. The first is 5W, the second 7W.</p>

The proposal so far doesn't handle this:

   <p item>The two lamps are <span
   property="com.example.name">A</span> and <span ???>B</span>. The
   first is <span property="com.example.price">$20</span>, the second
   <span ???>$30</span>. The first is <span
   property="com.example.power">5W</span>, the second <span
   ???>7W</span>.</p>

What do we put for the "???"s?

In RDFa we would have to give each of these items a name using about="" 
and then link them that way, but this has two problems: these items aren't 
named, nor is there an obvious name to give them, and it makes it hard to 
identify a single element responsible for introducing an item, which would 
make DOM interfaces to this somewhat more complex.

Microformats aren't especially useful here for inspiration as they do not 
solve this problem at all.

Instead, let us try using the regular "IDREF" functionality that HTML uses 
in a variety of other places, like <label for="">. For this we'll need a 
new attribute, but unfortunately we can't use about="" (which would be the 
obvious name to use), because that would conflict with RDFa, so instead 
we'll use subject="":

   <p>The two lamps are <span item id=a><span
   property="com.example.name">A</span></span> and <span item
   id=b><span property="com.example.name">B</span></span>. The first
   is <span subject="a" property="com.example.price">$20</span>, the
   second <span subject="b"
   property="com.example.price">$30</span>. The first is <span
   subject="a" property="com.example.power">5W</span>, the second
   <span subject="b" property="com.example.power">7W</span>.</p>

This is somewhat verbose, but I think this example represents pretty much 
the worst case scenario -- in most cases, most of the content would be in 
one place with just the odd other property elsewhere on the page.


With this proposal in mind, let's now go through the scenarios.

     * A group of users want to mark up their iguana collections so that they
       can write a script that collates all their collections and presents
       them in a uniform fashion.

Assuming Iguanas aren't too different from cats, here's an example of what 
this could look like:

   Page 1:
   <section item="com.damowmow.cat">
    <h1 property="com.damowmow.name">Hedral</h1>
    <p property="com.damowmow.desc">Hedral is a male american domestic
    shorthair, with a fluffy black fur with white paws and belly.</p>
    <img property="com.damowmow.img" src="hedral.jpeg" alt="" title="Hedral, age 18 months">
   </section>

   Page 2:
   <body item="com.damowmow.cat">
    <p>I love my cats. My oldest cat is <span
    property="com.damowmow.name">Silver</span>. <span
    property="com.damowmow.desc">Silver is <span
    property="com.damowmow.age">11</span> years old and refuses to eat
    alone, always waiting for either Yellow or Blue to eat with
    him.</p>
   </body>

   Page 3:
   <h2>My Cats<h2>
   <dl>
    <dt>Schr&ouml;dinger
    <dd item="com.damowmow.cat">
     <meta property="com.damowmow.name" content="Schr&ouml;dinger">
     <meta property="com.damowmow.age" content="9">
     <p property="com.damowmow.desc">Orange male.
    <dt>Erwin
    <dd item="com.damowmow.cat">
     <meta property="com.damowmow.name" content="Lord Erwin">
     <meta property="com.damowmow.age" content="3">
     <p property="com.damowmow.desc">Siamese color-point.
     <img property="com.damowmow.img" alt="" src="/images/erwin.jpeg">
   </dl>

(Note the <meta>s in the last example -- since sometimes the information 
isn't visible, rather than requiring that people put it in and hide it 
with display:none, which has a rather poor accessibility story, I figured 
we could just allow <meta> anywhere, if it has a property="" attribute.)

Assuming a Perl library HTML::Microdata with the following API (which 
could be written on top of html5lib, for instance):

   # $doc is an HTML document instance
   my $microdata = new HTML::Microdata($doc);
   my @items = $microdata->items() # returns a list of items
   my @x = $microdata->items('x') # returns a list of items with that type
   my $properties = $item->properties() # returns a hashref of name-[value] pairs

...then the following could generate a table of all the cats:

   my @cats;
   # @docs is a list of pre-parsed document instances
   foreach my $doc (@docs) {
     my $data = new HTML::Microdata($doc);
     push(@cats, $data->items('com.damowmow.cat')); 
   }
   print "<table><thead><tr><th>Name<th>Age<th>Image<th>Description<tbody>";
   foreach my $cat (@cats) {
     my $name = '&mdash;';
     if (exists $cat->properties->{'com.damowmow.name'}) {
       $name = escapeHTML($cat->properties->{'com.damowmow.name'}->[0]);
     }
     my $age = '';
     if (exists $cat->properties->{'com.damowmow.age'}) {
       $age = escapeHTML($cat->properties->{'com.damowmow.age'}->[0]);
     }
     my $image = '';
     if (exists $cat->properties->{'com.damowmow.img'}) {
       my $src = escapeHTML($cat->properties->{'com.damowmow.img'}->[0]);
       $image = "<img src='$src' alt=''>";
     }
     my $description = '';
     if (exists $cat->properties->{'com.damowmow.desc'}) {
       $description = escapeHTML($cat->properties->{'com.damowmow.desc'}->[0]);
     }
     print "<tr><td>$name<td>$age<td>$image<td>$description";
   }
   print "</table>";

This seems pretty simple to use.


     * A scholar and teacher wants other scholars (and potentially students)
       to be able to easily extract information about what he teaches to add
       it to their custom applications.
     * The list of specifications produced by W3C, for example, and various
       lists of translations, are produced by scraping source pages and
       outputting the result. This is brittle. It would be easier if the data
       was unambiguously obtainable from the source pages. This is a custom
       set of properties, specific to this community.

These seem to be more or less the same.


     * Chaals wants to make a list of the people who have translated W3C
       specifications or other documents, and then use this to search for
       people who are familiar with a given technology at least at some
       level, and happen to speak one or more languages of interest.

It seems that, given a tool that can parse this microdata format from HTML 
pages, it would be reasonably straight-forward to write a tool to search 
the data for particular patterns.


     * Chaals wants to have a reputation manager that can determine which of
       the many emails sent to the WHATWG list might be "more than usually
       valuable", and would like to seed this reputation manager from
       information gathered from the same source as the scraper that
       generates the W3C's TR/ page.

The reputation manager and e-mail processing is out of scope here, but the 
microdata format would address the problem of scraping the data in a less 
brittle manner than would be required today.


     * A user wants to write a script that finds the price of a book from an
       Amazon page.

This wouldn't be helped my the microdata solution proposed above, since 
Amazon apparently do not wish to expose the data in this fashion, but 
instead the Amazon API can be used for this purpose, so there is an 
alternative solution here.


     * Todd sells an HTML-based content management system, where all
       documents are processed and edited as HTML, sent from one editor to
       another, and eventually published and indexed. He would like to build
       up the editorial metadata used by the system within the HTML documents
       themselves, so that it is easier to manage and less likely to be lost.

It's unclear exactly what metadata this would involve, but the microdata 
solution described above seems like it would work for this.


     * Tim wants to make a knowledge base seeded from statements made in
       Spanish and English, e.g. from people writing down their thoughts
       about George W. Bush and George H.W. Bush, and has either convinced
       the people making the statements that they should use a common
       language-neutral machine-readable vocabulary to describe their
       thoughts, or has convinced some other people to come in after them and
       process the thoughts manually to get them into a computer-readable
       form.

The knowledge base aspect of this is out of scope for HTML, but if someone 
is able to convince people to mark up sentences in HTML, the microdata 
solution above would, as far as I can tell, provide sufficient flexibility 
to mark up such features.


The requirements were as follows:

     * Vocabularies can be developed in a manner that won't clash with future
       more widely-used vocabularies, so that those future vocabularies can
       later be used in a page making use of private vocabularies without
       making the earlier annotations ambiguous.

The use of reversed domain labels makes this possible without needing 
prefixes and without making the page unreadable, so this seems satisfied.


     * Using the data should not involve learning a plethora of new APIs,
       formats, or vocabularies (today it is possible, e.g., to get the price
       of an Amazon product, but it requires learning a new API; similarly
       it's possible to get information from sites consistently using 'class'
       values in a documented way, but doing so requires learning a new
       vocabulary).

This need isn't met. There would still be a plethora of vocabularies to 
learn. I don't see how to satisfy this requirement short of defining one 
very comprehensive vocabulary and requiring that only that vocabulary be 
used, but that seems like an impractical solution.


     * Shouldn't require the consumer to write XSLT or server-side code to
       process the annotated data.

This requirement isn't met. While XSLT itself isn't necessarily needed, 
there is still typcially a need for code to process the parsed annotations 
to do something with it.

This requirement was later clarified to mean that it should be possible to 
write a single parser that isn't continually maintained in the way that 
the Microformats parsers have to be as new vocabularies are added. That 
_is_ handled by this new syntax, so hopefully that will be enough.


     * Machine-readable annotations shouldn't be on a separate page than
       human-readable annotations.

This requirement is met.


     * The information should be convertible into a dedicated form (RDF,
       JSON, XML) in a consistent manner, so that tools that use this
       information separate from the pages on which it is found have a
       standard way of conveying the information.

I've included a section on converting microdata blobs to JSON and a 
section on converting HTML documents, including microdata blobs, to RDF, 
so that there is a consistent representation of HTML documents in those 
formats. I haven't defined an XML form of the microdata syntax, since HTML 
can be expressed as XML already, and I'm not sure that a dedicated format 
for microdata would be particularly wieldy.


     * Should be possible for different parts of an item's data to be given
       in different parts of the page, for example two items described in the
       same paragraph. ("The two lamps are A and B. The first is $20, the
       second $30. The first is 5W, the second 7W.")

This was discussed above.


     * It should be possible to define globally-unique names, but the syntax
       should be optimised for a set of predefined vocabularies.

The syntax allows URIs and encourages use of Java-like identifiers, but 
some of the use cases that I haven't handled yet are about dedicated 
vocabularies for particular purposes, so I'll return to this soon.


     * Adding this data to a page should be easy.

Based on the examples I've written above, as well as a number of others 
I've written while developing this, it seems that this is a pretty easy 
syntax to use. It is easier than Microformats for people who already use 
"class" heavily, and it is easier than RDFa (it's a loose subset).


     * The syntax for adding this data should encourage the data to remain
       accurate when the page is changed.

The syntax encourages the use of inline metadata for this very purpose, 
while allowing hidden metadata for the cases where trying to shoe-horn 
microdata into visible form is counterproductive.


     * The syntax should be resilient to intentional copy-and-paste
       authoring: people copying data into the page from a page that already
       has data should not have to know about any declarations far from the
       data.

Since microdata doesn't use prefixes, it's quite resilient to copy/paste.


     * The syntax should be resilient to unintentional copy-and-paste
       authoring: people copying markup from the page who do not know about
       these features should not inadvertently mark up their page with
       inapplicable data.

This isn't really met. It's very easy to copy an element with a 
property="" or item="" attribute and not realise that more is being said 
by the markup than the author realises. I'm not sure how to address this. 
This problem is also present in RDFa and Microformats, but my discussions 
with people who have worked with and on those technologies did not reveal 
any obvious solutions that didn't involve significantly reducing ease of 
authoring.


     * Any additional markup or data used to allow the machine to understand
       the actual information shouldn't be redundantly repeated (e.g. on each
       cell of a table, when setting it on the column is possible).

This isn't met at all with the current proposal. Unfortunately the only 
general solutions I could come up with that would allow this were 
selector-based, and in practice authors are still having trouble 
understanding how to use Selectors even with CSS.


     * Parsing rules should be unambiguous.

The parsing rules for microdata are clearly set out in the spec.


     * Should not require changes to HTML5 parsing rules.

The HTML5 parsing rules are untouched.


     * Creating a custom vocabulary should be relatively easy.

Creating a good vocabulary is always a lot of work, but in general the 
microdata syntax doesn't make it harder, at least. I haven't yet addressed 
the issue of validating the vocabulary, which is one of the use cases that 
I haven't yet dealt with.


     * Distributed vocabulary development should be possible; it
       should not require coordination through a centralised system.

This is handled through the use of URIs or domain-label-based identifiers.


     * It should be possible to publish and re-use custom
       vocabularies.

Nothing in the syntax seems to preclude this.


In conclusion:

To address this use case and its scenarios, I've added to HTML5 a simple 
syntax (three new attributes) based on RDFa. It doesn't have the full 
power of RDF, because that didn't seem to be necessary to address the use 
cases. It doesn't really have anything in common with Microformats; I 
didn't find the Microformats syntax to be very convenient. (This was also 
the experience with eRDF.)

I expect the syntax will need adjustments over the coming weeks to address 
issues that I overlooked. I look forward to such feedback.


A number of further use cases remain to be examined, including one
with scenarios regarding validating custom vocabularies and allowing
editors to provide help with custom vocabularies, and including
several regarding specific vocabularies such as events, contact
information, and bibliographic information. I will send further e-mail
next week as I address them.

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

From excors+whatwg at gmail.com  Sun May 10 06:21:37 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sun, 10 May 2009 14:21:37 +0100
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
Message-ID: <ea09c0d10905100621w4d41325eu90cc03e9735e2885@mail.gmail.com>

On Sun, May 10, 2009 at 11:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>
> One of the more elaborate use cases I collected from the e-mails sent in
> over the past few months was the following:
>
> ? USE CASE: Annotate structured data that HTML has no semantics for, and
> ? which nobody has annotated before, and may never again, for private use or
> ? use in a small self-contained community.
>
> [...]
>
> To address this use case and its scenarios, I've added to HTML5 a simple
> syntax (three new attributes) based on RDFa.

There's a quickly-hacked-together demo at
http://philip.html5.org/demos/microdata/demo.html (works in at least
Firefox and Opera), which attempts to show you the JSON serialisation
of the embedded data, which might help in examining the proposal.

-- 
Philip Taylor
excors at gmail.com

From shelleyp at burningbird.net  Sun May 10 09:21:48 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Sun, 10 May 2009 11:21:48 -0500
Subject: [whatwg] Custom microdata handling added to HTML5 spec
Message-ID: <4A06FF1C.6030802@burningbird.net>

Since a new section detailing HTML5's handling of custom microdata  has 
been added to the HTML5 spec

(tracked here http://html5.org/tools/web-apps-tracker?from=3073&to=3074 
and displayed here http://dev.w3.org/html5/spec/Overview.html#microdata 
and announced 
herehttp://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html 
), I'm assuming my effort to re-examine the use cases Ian has published 
is irrelevant, and a waste of everyone's time.

I will hence discontinue any and all effort associated with this 
specification.

Shelley




From shelleyp at burningbird.net  Sun May 10 12:28:24 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Sun, 10 May 2009 14:28:24 -0500
Subject: [whatwg] Continuing
Message-ID: <4A072AD8.9020808@burningbird.net>

Sorry for the double emails today.

I will continue with revisiting the use cases for the microdata section. 
One additional component I'll add to the use cases is applying my 
interpretation of how RDFa might handle the use case, as compared  to 
how it could be handled with Ian's new HTML5 microdata proposal. This 
will, of course, slow me down a bit.

Note, though, that I don't claim to be an expert on either RDFa or Ian's 
new microdata proposal.  My hope is that if I make a mistake, or I'm not 
clear, folks will respond to my writing with corrections and/or 
additions. The purpose behind my effort is to open discussion. I will 
admit, though, that I do have a bias for RDFa, primarily because this is 
something that's real, today, and that I can use, today.

Shelley

From msporny at digitalbazaar.com  Sun May 10 13:14:04 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun, 10 May 2009 16:14:04 -0400
Subject: [whatwg] Micro-data/Microformats/RDFa
	Interoperability	Requirement
In-Reply-To: <4A0560CC.2090507@gmx.de>
References: <4A0104C2.8080009@digitalbazaar.com>	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>	<4A02F6AE.1000602@digitalbazaar.com>	<Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>
	<4A039BB1.4050703@digitalbazaar.com> <4A0560CC.2090507@gmx.de>
Message-ID: <4A07358C.3080404@digitalbazaar.com>

Julian Reschke wrote:
> Manu Sporny wrote:
>> ...
>> The second is that you are assuming that @rel/@rev reserved attribute
>> values are the same for all XML and non-XML family languages - they
>> aren't. Reserved words such as "next" and "prev" can be defined per
>> language - or, none can be defined... it's up to the language adopting
>> RDFa to define those values. For a list of the current values, you can
>> see:
>> ...
> 
> They currently can be defined per language, but that doesn't make it a
> good idea.

I agree in principle, but practicality overrode that principle in the
RDFa Task Force. The reason they're defined per language is because:

1. We were specifically working on RDF in XHTML and did not have the
authority to define them for all languages.
2. We also couldn't base a solution on another draft document.
3. Even if we could do all of this, getting each HTML-family work group
to agree on a set of common @rel types would be nearly impossible for
our small group to accomplish while working on RDF in XHTML.

> You are aware of MNot's "Web Linking" draft
> (<http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html>),
> and the fact that it seems to enjoy support from the TAG?

Thanks for pointing it out, I wasn't aware of that draft :). RDFa can be
used in non-web-languages, so we shouldn't go overboard by saying that
the Web Linking draft should apply for all languages that use RDFa.

I agree that it would be good for web languages to standardize around
that draft for LinkTypes... specifically for reserved @rel/@rev values
in RDFa for HTML family languages. I've raised the issue[1] with the
RDFa Task Force... we'll discuss further on that list.

-- manu

[1]http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0054.html

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From jgraham at opera.com  Sun May 10 14:37:31 2009
From: jgraham at opera.com (jgraham at opera.com)
Date: Sun, 10 May 2009 21:37:31 +0000
Subject: [whatwg] Annotating structured data that HTML has no
	semantics	for
Message-ID: <20090510213731.yezvxe5s040s40wg@staff.opera.com>

Quoting Philip Taylor <excors+whatwg at gmail.com>:

> On Sun, May 10, 2009 at 11:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> One of the more elaborate use cases I collected from the e-mails sent in
>> over the past few months was the following:
>>
>> ? USE CASE: Annotate structured data that HTML has no semantics for, and
>> ? which nobody has annotated before, and may never again, for private use or
>> ? use in a small self-contained community.
>>
>> [...]
>>
>> To address this use case and its scenarios, I've added to HTML5 a simple
>> syntax (three new attributes) based on RDFa.
>
> There's a quickly-hacked-together demo at
> http://philip.html5.org/demos/microdata/demo.html (works in at least
> Firefox and Opera), which attempts to show you the JSON serialisation
> of the embedded data, which might help in examining the proposal.

I have a *totally unfinished* demo that does something rather similar
at [1]. It is highly likely to break and/or give incorrect results**.
If you use it for anything important you are insane :)

My general impression from writing the tool is that this proposal is,
at least, easy to write consumers for. I get the feeling that the
production side will also be within the grasp of most authors,
although it is hard to say for sure since I haven't really tried
authoring anything.

[1] http://james.html5.org/microdata/

** Known bugs include: incorrect lowercasing of non ascii characters,
lack of support for resolving uris, lack of rdf output, some others
that I forget



From msporny at digitalbazaar.com  Sun May 10 15:12:53 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun, 10 May 2009 18:12:53 -0400
Subject: [whatwg] Custom microdata handling added to HTML5 spec
In-Reply-To: <4A06FF1C.6030802@burningbird.net>
References: <4A06FF1C.6030802@burningbird.net>
Message-ID: <4A075165.1030702@digitalbazaar.com>

Shelley Powers wrote:
> Since a new section detailing HTML5's handling of custom microdata  has
> been added to the HTML5 spec
> 
> http://dev.w3.org/html5/spec/Overview.html#microdata

I've only had a brief chance to look over the HTML5 Microdata spec, but
there is one big problem that overrides all of the other issues: The
HTML5 Microdata spec is in direct conflict with planned RDFa extensions
and will almost surely result in spurious triples being generated in
RDFa processors in the future.

We are currently working[1] on features to dynamically extending the
base set of reserved words and the set of pre-defined prefixes through a
mechanism called RDFa Profiles[2]. It is proposed that this mechanism
would allow authors to do this in their documents:

<div profile="http://example.org/myprofile.html"> ...
  <span property="description">A description for this page.</span>
  <span about="#me" property="name">Manu Sporny</span>
</div>

Note that 'description' and 'name' are not prefixed, but would be mapped
to a full URI in the document listed by @profile. This allows the ease
of Microformats-like markup but with all of the rigor of RDFa.

The HTML5 microdata proposal, as it stands right now, would create
numerous spurious triples if implemented and would violate the purpose
of @property as it is being developed in the RDFa community.

I'll have more comments on the microdata proposal based on the response
to this e-mail.

-- manu

[1]http://www.w3.org/2009/04/30-rdfa-minutes.html#item04
[2]http://rdfa.info/wiki/RDFa_Profiles

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From ben at adida.net  Sun May 10 15:29:53 2009
From: ben at adida.net (Ben Adida)
Date: Sun, 10 May 2009 15:29:53 -0700
Subject: [whatwg]
	Micro-data/Microformats/RDFa	Interoperability	Requirement
In-Reply-To: <4A07358C.3080404@digitalbazaar.com>
References: <4A0104C2.8080009@digitalbazaar.com>	<Pine.LNX.4.62.0905060401410.7824@hixie.dreamhostps.com>	<4A02F6AE.1000602@digitalbazaar.com>	<Pine.LNX.4.62.0905071909280.7824@hixie.dreamhostps.com>	<4A039BB1.4050703@digitalbazaar.com>
	<4A0560CC.2090507@gmx.de> <4A07358C.3080404@digitalbazaar.com>
Message-ID: <4A075561.70709@adida.net>

Julian wrote:
> You are aware of MNot's "Web Linking" draft
> (<http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html>),
> and the fact that it seems to enjoy support from the TAG?

Julian, you continue to bring this up as if we hadn't already discussed 
this: there are significant differences of opinion with mnot on whether 
his interpretation of @rel values is correct in prior HTML versions, and 
there are a number of folks who disagree (not just us in RDFa), 
including at least two RECs (RDFa and GRDDL).

The point is: if you assume that @rel="foo" always means the same thing, 
then many folks believe you're already violating the HTML spec, which 
specifically uses @profile to modulate the meaning of @rel, and 
sometimes via another level of indirection.

-Ben


From lhs at malform.no  Sun May 10 16:45:47 2009
From: lhs at malform.no (Leif Halvard Silli)
Date: Mon, 11 May 2009 01:45:47 +0200
Subject: [whatwg] Helping people seaching for content filtered by license
Message-ID: <4A07672B.7060408@malform.no>

Ben Adida ben at adida.net  Sun May 10 15:29:53 PDT 2009:
> Julian wrote:
> > You are aware of MNot's "Web Linking" draft
> > 
> (<http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html>),
> > and the fact that it seems to enjoy support from the TAG?
>
> Julian, you continue to bring this up as if we hadn't already discussed
> this:

Where and when has it been discussed?

> there are significant differences of opinion with mnot on whether
> his interpretation of @rel values is correct in prior HTML versions, 

He has Requested For Comments, so that can be corrected, no?

> and  there are a number of folks who disagree (not just us in RDFa),
> including at least two RECs (RDFa and GRDDL).

Is this claim based on a mere comparison of the description of those 
link relations in said specifications? Perhaps some of the disagreements 
are merely a different wording?

> The point is: if you assume that @rel="foo" always means the same thing,
> then many folks believe you're already violating the HTML spec, which
> specifically uses @profile to modulate the meaning of @rel, and
> sometimes via another level of indirection.

Where does nottingham draft define anything that contradicts the default 
HTML 401 profile?  Authors will often assume that rel="foo" does means 
the same thing wherever it appears, hence a central register is a 
benefit so that specification writers and profile writers can know what 
the standard semantics are.

As to modifying semantics, it is probably not wise to profile or specify 
semantics that differs from the central register. But having a central 
register cannot in itself prevent profiles (default profiles or 
linked-in profiles) from defining their own semantics when necessary.

It does by the way seem like an unfortunate mix of semantics and other 
issues that HTML 5 does not allow the @rev attribute. Rather, HTML 5 
should allow the @rev attribute, but should eventually say that it 
hasn't defined any values for it. Thus authors who are linking to a 
profile that does define values for @rev could still use @rev without 
producing an invalid HTML 5 document.
-- 
leif halvard silli


From samaxes at gmail.com  Sun May 10 16:51:09 2009
From: samaxes at gmail.com (Samuel Santos)
Date: Mon, 11 May 2009 00:51:09 +0100
Subject: [whatwg] Asynchronous file upload
Message-ID: <fe7db4750905101651g79b4d762ia2e598dfb9daa21c@mail.gmail.com>

I was asked by a client if it was possible to implement something similar to
the asynchronous file upload used on gmail using only standard web
technologies.

Looking at the gmail source code I can see that they use some flash magic.
And by reading the HTML5 spec I could not find a way to implement this
feature.

Wouldn't it be great if this was possible?

--
Samuel Santos
http://www.samaxes.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090511/bc74e6d9/attachment.htm>

From pstradomski at gmail.com  Sun May 10 17:00:00 2009
From: pstradomski at gmail.com (=?utf-8?q?Pawe=C5=82_Stradomski?=)
Date: Mon, 11 May 2009 02:00:00 +0200
Subject: [whatwg] Asynchronous file upload
In-Reply-To: <fe7db4750905101651g79b4d762ia2e598dfb9daa21c@mail.gmail.com>
References: <fe7db4750905101651g79b4d762ia2e598dfb9daa21c@mail.gmail.com>
Message-ID: <200905110200.01129.pstradomski@gmail.com>

W li?cie Samuel Santos z dnia poniedzia?ek 11 maja 2009:
> I was asked by a client if it was possible to implement something similar
> to the asynchronous file upload used on gmail using only standard web
> technologies.
>
> Looking at the gmail source code I can see that they use some flash magic.
> And by reading the HTML5 spec I could not find a way to implement this
> feature.

Submitting the form that contains file upload to a iframe.
The question does not seem to belong to this list, does it?

-- 
Pawe? Stradomski


From ionut.g.stan at gmail.com  Sun May 10 17:24:26 2009
From: ionut.g.stan at gmail.com (Ionut G. Stan)
Date: Mon, 11 May 2009 03:24:26 +0300
Subject: [whatwg] Asynchronous file upload
In-Reply-To: <fe7db4750905101651g79b4d762ia2e598dfb9daa21c@mail.gmail.com>
References: <fe7db4750905101651g79b4d762ia2e598dfb9daa21c@mail.gmail.com>
Message-ID: <4A07703A.6070400@gmail.com>

There appears to be some W3C activity regarding this problem. There is a 
draft about
file uploads[1] which is edited by a Mozilla employee. This is not 
accidentally. As of Firefox 3
we have the possibility of Ajax file uploads. The API resembles pretty 
much the draft.

Also, Safari 4 and Chrome 2 - WebKit in other words - provide an API for 
the same purpose,
but it has less to do with the above mentioned standard draft.

I've written an extensive post [2] about the API in Firefox 3. Maybe it 
will help you.

[1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html
[2] http://igstan.blogspot.com/2009/01/pure-javascript-file-upload.html

On 5/11/2009 02:51, Samuel Santos wrote:
> I was asked by a client if it was possible to implement something 
> similar to the asynchronous file upload used on gmail using only 
> standard web technologies.
>
> Looking at the gmail source code I can see that they use some flash magic.
> And by reading the HTML5 spec I could not find a way to implement this 
> feature.
>
> Wouldn't it be great if this was possible?
>
> --
> Samuel Santos
> http://www.samaxes.com/

-- 
Ionut G. Stan
I'm under construction  |  http://igstan.blogspot.com/


From singer at apple.com  Sun May 10 18:56:27 2009
From: singer at apple.com (David Singer)
Date: Mon, 11 May 2009 09:56:27 +0800
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <2c0e02830905082109t64fa89aaj5dd50933c3d9283@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<p0624083ec61f812f3c0d@17.202.35.52>
	<2c0e02830904301842h5f6bcf1cyc8743e135a31436c@mail.gmail.com>
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com>
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52>
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com>
	<p06240804c62921c89a85@17.202.35.52>
	<2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com>
	<p06240805c62a0c11e4a7@10.0.1.6>
	<2c0e02830905082109t64fa89aaj5dd50933c3d9283@mail.gmail.com>
Message-ID: <p0624081ac62d3543eff2@[17.202.35.52]>

At 14:09  +1000 9/05/09, Silvia Pfeiffer wrote:
>  > you might try loading, say, the one-page version of the HTML5 
>spec. from the
>>  WhatWG site...it takes quite a while.  Happily Ian also provides a
>>  multi-page, but this is not always the case.
>
>That just confirms the problem and it's obviously worse with video. :-)
>
>
>>  The reason I want clarity is that this has ramifications.  For example, if a
>>  UA is asked to play a video with a fragment indication #time="10s-20s", and
>>  then a script seeks to 5s, does the user see the video at the 5s point of
>>  the total resource, or 15s?  I think it has to be 5s.
>
>I agree, it has to be 5s. The discussion was about what timeline is
>displayed and what can the user easily access through seeking through
>the displayed timeline. A script can access any time of course. But a
>user is restricted by what the user interface offers.

Sure.  I think we are probably in agreement.  Logically, the UA is 
dealing with the whole resource -- which is why it's 5s in this case. 
The UA is also responsible for focusing the user on the fragment, and 
(implicitly) for optimizing the network for what the user is focusing 
on.

For example, some UAs would essentially invoke the same code if the 
user immediately did a seek to a time, if the javacsript did a seek 
to a time, or the initial URI had a fragment indicator starting at a 
time.  In all three cases, the UA tries to start at that time as best 
it can, optimizing network access to do that.

>  > But we can optimize for the fragment without disallowing the seeking.
>
>What do you mean by "optimize for the fragment"?

I mean, the UA can get support from the server for time-based access, 
helping optimizing the network access for the fragment to be 
presented, while at the same time allowing seeking outside that 
fragment.

>  Of course none of the
>discussion will inherently disallow seeking - scripts will always be
>able to do the seeking. But the user may not find it easy to do
>seeking to a section that is not accessible through the displayed
>timeline, which can be both a good and a bad thing.

How easy a particular user interface is to use for various tasks is 
(I hope) not our worry...
-- 
David Singer
Multimedia Standards, Apple Inc.

From simonp at opera.com  Mon May 11 00:32:38 2009
From: simonp at opera.com (Simon Pieters)
Date: Mon, 11 May 2009 09:32:38 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
In-Reply-To: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
Message-ID: <op.utq8klgfidj3kv@simon-pieterss-macbook.local>

On Sun, 10 May 2009 12:32:34 +0200, Ian Hickson <ian at hixie.ch> wrote:

>    Page 3:
>    <h2>My Cats<h2>
>    <dl>
>     <dt>Schr&ouml;dinger
>     <dd item="com.damowmow.cat">
>      <meta property="com.damowmow.name" content="Schr&ouml;dinger">
>      <meta property="com.damowmow.age" content="9">
>      <p property="com.damowmow.desc">Orange male.
>     <dt>Erwin
>     <dd item="com.damowmow.cat">
>      <meta property="com.damowmow.name" content="Lord Erwin">
>      <meta property="com.damowmow.age" content="3">
>      <p property="com.damowmow.desc">Siamese color-point.
>      <img property="com.damowmow.img" alt="" src="/images/erwin.jpeg">
>    </dl>

Given the microdata solution and this example, there is now a reason other than styling to introduce <di>, since here you duplicate the <dt> information in <meta>.

   <dl>
    <di item="com.damowmow.cat">
     <dt property="com.damowmow.name">Schr&ouml;dinger
     <dd>
      <meta property="com.damowmow.age" content="9">
      <p property="com.damowmow.desc">Orange male.
    </di>
    ...


The styling problem is discussed at http://forums.whatwg.org/viewtopic.php?t=47

-- 
Simon Pieters
Opera Software



From whatwg at adambarth.com  Mon May 11 09:16:23 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Mon, 11 May 2009 09:16:23 -0700
Subject: [whatwg] innerStaticHTML
In-Reply-To: <op.utiol9s92q99of@id-c0981>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com> 
	<op.utiol9s92q99of@id-c0981>
Message-ID: <7789133a0905110916l3ef56bb2y57d7483ec09ef617@mail.gmail.com>

On Wed, May 6, 2009 at 9:40 AM, Jo?o Eiras <joaoe at opera.com> wrote:
> The suggestion of marking content as non-executable doesn't solve anything, because after setting innerStaticHTML another script might serialize a piece of the affected DOM to string and back to a tree, and the code could then execute, which would not be wanted.

Yes, we can't make it impossible for web developers to shoot
themselves in the foot.  We also can't stop them from calling eval on
a query string argument.  However, innerStaticHTML does make it easier
to display untrusted HTML to the user.

> The only viable solution, from my point of view, would be for the UA to parse the string, and remove all untrusted content from the result tree before appending to the document.

This is what I meant to suggest.

> That would mean removing all onevent attributes, all scripts elements, all plugins, etc. Basically, letting the UA implement all the filtering.

Exactly.  As you say, the UA is in a much better position to do this
correctly than an individual web site.

On Thu, May 7, 2009 at 3:24 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> If toStaticHTML prunes everything it is not sure of, the danger of a known
> language construct suddenly introducing active content is negligible.  I am
> sure HTML5 specification editors bear that aspect in mind and so shall they
> in the future.

Even if you believe that we've already committed to not introducing
active content that breaks toStaticHTML (which I'm not convinced we
have, especially because I don't know what algorithm it uses), that
still leaves the performance and correctness issues of parsing the
untrusted content twice.  Parsing the content once is more efficient
and more predictable.

Adam

From giovanni.gentili at gmail.com  Mon May 11 10:15:59 2009
From: giovanni.gentili at gmail.com (Giovanni Gentili)
Date: Mon, 11 May 2009 19:15:59 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
Message-ID: <4a30f5360905111015y94d0e05w8e1f53a1aeed154f@mail.gmail.com>

Ian Hickson:
> ? USE CASE: Annotate structured data that HTML has no semantics for, and
> ? which nobody has annotated before, and may never again, for private use or
> ? use in a small self-contained community.
> (..)
> ? SCENARIOS:

Between the scenarios should be considered also this case:

* a user (or groups of users) wants to annotate
items present on a generic web page with
additional properties in a certain vocabulary.
for example Joe wants to gather in a blog
a series of personal annotation to movies
(or other type of items) present in imdb.com.

other examples of "external annotation" could
be derived from this document [1].

this option require that @subject accept:

1) ID of an element with an item attribute, in the same Document
or
2) valid URL of an element with an item attribute elsewhere in the web
or
3) a valid URL (ithe item is the referred document or fragment)

This raises two other questions:

a) In the case of  properties specified for element
without ancestor with an item attribute specified
the corresponding item should be the document?
(element body with implicit item attribute).

b) Do we need to require UA to offer a standard
way to visualize (at least as an option left to the user)
the structured information carried in microdata ?
And copy&paste? See also this email [2].

[1] http://www.w3.org/TR/2009/WD-media-annot-reqs-20090119/#req-r01
[2] http://lists.w3.org/Archives/Public/public-html/2009Jan/0082.html

-- 
Giovanni Gentili

From excors+whatwg at gmail.com  Mon May 11 10:44:22 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Mon, 11 May 2009 18:44:22 +0100
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <4a30f5360905111015y94d0e05w8e1f53a1aeed154f@mail.gmail.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
	<4a30f5360905111015y94d0e05w8e1f53a1aeed154f@mail.gmail.com>
Message-ID: <ea09c0d10905111044k6a847e18q36f71041d953ee9c@mail.gmail.com>

On Mon, May 11, 2009 at 6:15 PM, Giovanni Gentili
<giovanni.gentili at gmail.com> wrote:
> * a user (or groups of users) wants to annotate
> items present on a generic web page with
> additional properties in a certain vocabulary.
> for example Joe wants to gather in a blog
> a series of personal annotation to movies
> (or other type of items) present in imdb.com.
>
> [...]
>
> this option require that @subject accept:
>
> 1) ID of an element with an item attribute, in the same Document
> or
> 2) valid URL of an element with an item attribute elsewhere in the web
> or
> 3) a valid URL (ithe item is the referred document or fragment)

For the RDF output, you can use <link property="about"
href="http://subject/"> to create triples whose subject is a URL. (I
believe in general you can also do:
  <meta item id="n0">
  <link subject="n0" property="about" href="http://subject/">
  <link subject="n0" property="http://predicate1/" href="http://object1/">
  <meta subject="n0" property="http://predicate2/" content="object2">
to represent arbitrary RDF triples.)

I don't think it would make sense for @subject to be a URL when
generating JSON output, because there wouldn't be anywhere to
represent that URL in the output structure. But there could be a
convention that properties called "about" indicate the URLs that the
item applies to, and then it would work with exactly the same markup
as the RDF case.

-- 
Philip Taylor
excors at gmail.com

From robert at ocallahan.org  Mon May 11 16:05:28 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 12 May 2009 11:05:28 +1200
Subject: [whatwg] innerStaticHTML
In-Reply-To: <7789133a0905110916l3ef56bb2y57d7483ec09ef617@mail.gmail.com>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
	<op.utiol9s92q99of@id-c0981>
	<7789133a0905110916l3ef56bb2y57d7483ec09ef617@mail.gmail.com>
Message-ID: <11e306600905111605o15998127hfd07e93592bce7c8@mail.gmail.com>

On Tue, May 12, 2009 at 4:16 AM, Adam Barth <whatwg at adambarth.com> wrote:

> On Thu, May 7, 2009 at 3:24 AM, Kristof Zelechovski
> <giecrilj at stegny.2a.pl> wrote:
> > If toStaticHTML prunes everything it is not sure of, the danger of a
> known
> > language construct suddenly introducing active content is negligible.  I
> am
> > sure HTML5 specification editors bear that aspect in mind and so shall
> they
> > in the future.
>
> Even if you believe that we've already committed to not introducing
> active content that breaks toStaticHTML (which I'm not convinced we
> have, especially because I don't know what algorithm it uses)


I would be shocked if we have committed to not introducing active content
that breaks IE8's toStaticHTML. That would be terribly limiting. (Does it
prune the <video> and <audio> event attributes?)

When you call innerStaticHTML it should prune everything that's unsafe for
*this UA*. Authors should not send that content to other UAs and expect it
to be safe for those UAs.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090512/6cdd5007/attachment.htm>

From ian at hixie.ch  Mon May 11 16:23:22 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 11 May 2009 23:23:22 +0000 (UTC)
Subject: [whatwg] Custom microdata handling added to HTML5 spec
In-Reply-To: <4A075165.1030702@digitalbazaar.com>
References: <4A06FF1C.6030802@burningbird.net>
	<4A075165.1030702@digitalbazaar.com>
Message-ID: <Pine.LNX.4.62.0905112323030.7824@hixie.dreamhostps.com>

On Sun, 10 May 2009, Manu Sporny wrote:
> Shelley Powers wrote:
> > Since a new section detailing HTML5's handling of custom microdata  has
> > been added to the HTML5 spec
> > 
> > http://dev.w3.org/html5/spec/Overview.html#microdata
> 
> I've only had a brief chance to look over the HTML5 Microdata spec, but
> there is one big problem that overrides all of the other issues: The
> HTML5 Microdata spec is in direct conflict with planned RDFa extensions
> and will almost surely result in spurious triples being generated in
> RDFa processors in the future.

I've renamed property="" to itemprop="".

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

From kornel at geekhood.net  Mon May 11 17:02:05 2009
From: kornel at geekhood.net (=?UTF-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Tue, 12 May 2009 01:02:05 +0100
Subject: [whatwg] innerStaticHTML
In-Reply-To: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
References: <7789133a0905060931k608c0d83qc847c6a0cf665f17@mail.gmail.com>
Message-ID: <6E0135E8-4EA6-4C9E-888F-279BA8729B35@geekhood.net>

On 06.05.2009, at 17:31, Adam Barth wrote:
>
> WHY NOT toStaticHTML?
>
> toStaticHTML addresses the same use cause by translating an untrusted
> string to another string that lacks active HTML content.  This API has
> two issues:
>
> 1) The untrusted string -> static string -> HTML parser workflow
> requires the browser to parse the string twice, introducing a
> performance penalty and a security issue if the two parsing aren't
> identical.

That is based on assumptions that:
1. parsing is expensive enough to warrant API optimized for this  
particular case
2. browsers cannot optimize it otherwise
3. returned code will be ambiguous

In client-side scripts untrusted content comes from the network, which  
means that parsing time is going to be miniscule compared to time  
required to fetch the content (and to render it). My guess is that  
parsing itself is not a bottleneck.

Second, it _is_ possible to avoid reparsing without special API for  
this. toStaticHTML() may return subclass of String that contains  
reference to parsed DOM. Roughly something like this:

function toStaticHTML(html)
{
     var cleanDOM = clean(parse(html))
     return {
         toString:function(){return unparse(cleanDOM)},
         node:cleanDOM
     }
}

which should make common case:

innerHTML = toStaticHTML(html) just as fast as innerStaticHTML = html;

toStaticHTML() enables other optimisations, e.g. filtered HTML can be  
saved for future use (in local storage) or string filtered once used  
in multiple places.

Alternatively there could be toStaticDOM() method that returns  
DOMDocumentFragment, avoiding reparsing issue entirely.

> 2) The API is difficult to future-proof because future versions of
> HTML are likely to add new tags with active content (e.g., like the
> <video> tag's event handlers).

When support for new tag is added to a browser, it would also be added  
to its toStaticHTML()/innerStaticHTML, so evolution of HTML shouldn't  
be a problem either way. Browser doesn't need to worry about dangerous  
constructs it does not support.

Methods are easier to patch than properties in JavaScript, so if  
implementation of existing toStaticHTML() turned out to be insecure,  
the method could be easily replaced/patched on cilent-side, or  
applications could post-process output of toStaticHTML().
It's not that easy with a property.

I dislike APIs based on magic properties. Properties cannot take  
arguments and we'd have to create new property for every combination  
of arguments. If innerHTML was a method, instead of creating new  
property we could extend it to be innerHTML(html, static=true).

If more sophisticated filtering becomes needed in the future, we could  
have toStaticHTML(html, {preserve:['svg','rdf'], remove:'marquee'}),  
but it would be silly to create another  
innerStaticHTMLwithSVGandRDFbutWithoutMarquee property.

-- 
regards, Kornel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090512/15357f76/attachment.htm>

From chuck at jumis.com  Mon May 11 18:05:35 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Mon, 11 May 2009 18:05:35 -0700
Subject: [whatwg] Expandos and Prototyping
Message-ID: <4A08CB5F.1040709@jumis.com>

Are expando / prototype functions at all included in the HTML 5 specs?
While we may all know what Object.prototype does, I'd like to see its 
use added to
Section 6: Web browsers.

The Prototype Expando is not necessarily a Javascript-only construct, 
and neither is HTML 5.

While I'm not championing full prototype inheritance, I do wonder 
(out-loud),
whether some small section of HTML 5 might be describe the most basic of 
prototyping and expandos:

Many projects use "ellipse" or other shapes for example, but this is easier:
CanvasRenderingContext2D.prototype.funcName = function() {
    alert("Fill"+this.fillStyle);
}
.... document.createElement('canvas').getContext('2d').funcName();

I've never seen any developers attempt to use multiple inheritance 
within the CanvasRenderingContext2D object,
nor have I tested myself to see if Firefox (the champion of such 
schemes) supports it. Which is why I'd be
more than satisfied simply requiring single inheritance. It's already 
available in all implementations,
and we spent a good deal of time making it available in our own.

Expando Prototype would need descriptions of:
expandos, prototyped objects, for(... in ...)

All modern browsers support prototype, and so do many languages (without 
writing libraries).
We've confirmed that it expandos and prototypes work just fine in Active 
X, MS long ago created IDispatchEx.

Any host language with getter / setter availability can implement 
prototyping and expandos on an object, at least of one depth.

I'd like to see  ".prototype" described in the scripting section.

That said, I'm more hesitant to champion ".constructor" and ".__proto__".

-Charles




From ian at hixie.ch  Mon May 11 18:18:09 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 May 2009 01:18:09 +0000 (UTC)
Subject: [whatwg] Expandos and Prototyping
In-Reply-To: <4A08CB5F.1040709@jumis.com>
References: <4A08CB5F.1040709@jumis.com>
Message-ID: <Pine.LNX.4.62.0905120116370.7824@hixie.dreamhostps.com>

On Mon, 11 May 2009, Charles Pritchard wrote:
>
> Are expando / prototype functions at all included in the HTML 5 specs?

Yes. Specifically, HTML5 uses WebIDL for all its definitions of 
interfaces, objects, etc, and the WebIDL spec defines how prototypes, 
custom properties, etc, work:

   http://dev.w3.org/2006/webapi/WebIDL/

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

From tim.tepasse at uni-dortmund.de  Mon May 11 20:06:14 2009
From: tim.tepasse at uni-dortmund.de (=?ISO-8859-1?Q?Tim_Tepa=DFe?=)
Date: Tue, 12 May 2009 05:06:14 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
Message-ID: <5EE04DAE-91B1-412A-8BB1-0468C173FA8F@uni-dortmund.de>

A cursory glance on the new section 5 raises two questions on  
indirection:

> (Note the <meta>s in the last example -- since sometimes the  
> information
> isn't visible, rather than requiring that people put it in and hide it
> with display:none, which has a rather poor accessibility story, I  
> figured
> we could just allow <meta> anywhere, if it has a property=""  
> attribute.)

That seems to be a solution optimised for extremely invisible metadata  
but not for metadata which differs from the human visible data.  
Imagine as an example the simple act of marking up a number (and  
ignoring what the number denotes).  For human consumption a thousands  
seperator is often used, the type of seperator differs by language,  
locale and context. Just in my little word I see on regular basis the  
point, the comma, the space, the thin space and sometimes the the  
apostrophe. Parsing different representations of numbers would be a  
chore. The value of textContent of the element <span  
itemprop="com.example.price">?&nbsp;1thinsp;000thinsp;000,&mdash;</ 
span> is clearly unusable, demanding an additional invisible <meta  
property="com.example.price" content="1000000">.

My irritation lies in the element proliferation, requiring one element/ 
attribute combination for machines, one element/text content  
combination for humans. Of course, any sane author would arrange both  
elements in a close relation, as parent/child or sibling but there  
would be still two different elements to maintain, leading to a higher  
cognitive load. Not just for authors but also for programmers: a  
fluctating price had to be actualized on two different elements; tree  
walking DOM scripts had to take meta-Elements in account. Furthermore  
it clashes with the familiar habit of other elements in HTML. A  
hyperlink is one element with a machine-readable attribute and human- 
readable text content. A citation is one element with a machine- 
readable reference and human-readable text content. The same model is  
used in <meter>, <progress>, <time>, <abbr> ... but not in user- 
defined objects. I'd prefer an additional @content-like attribute  
which supersedes the text content and maybe even the default values of  
the other value-bearing elements, reducing two different elements to  
maintain or change to just one.


> Instead, let us try using the regular "IDREF" functionality that  
> HTML uses
> in a variety of other places, like <label for="">. For this we'll  
> need a
> new attribute, but unfortunately we can't use about="" (which would  
> be the
> obvious name to use), because that would conflict with RDFa, so  
> instead
> we'll use subject="":


I'm slighty irritated by the implied change from active, possessive  
formulating (?The cat has the name Hedral.?) to something more passive- 
y (?Hedral is a name owned by that cat.?). My mental model for  
property relationships orients itself more on the former wording; link  
relationships are similar in that regard. @about/@subject are like  
@rev; a @resource alias @rel would feel more natural. There are  
practical relation by the missing @resource, I think. Imagine a  
document documenting an household and a household vocabulary which  
allows triples of <human>s which are in an <owner> relationship to a  
<cat>. Given an household of two humans and one cat; how does one  
markup the assumption that the cat has two owners?




From herenvardo at gmail.com  Tue May 12 03:55:42 2009
From: herenvardo at gmail.com (Eduard Pascual)
Date: Tue, 12 May 2009 12:55:42 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
Message-ID: <6ea53250905120355jc2ea7f9u4a370137cad55f9d@mail.gmail.com>

I don't really like to be harsh, but I have some criticism to this,
and it's going to be quite hard. However, my goal by pointing out what
I consider so big mistakes is to help HTML5 becoming as good as it
could be.

First issue: it solves a (major) subset of what RDFa would solve.
However, it has been taken as a requirement to avoid
clashes/incompatibilities with RDFa. In other words, as things stand,
authors will face two options: either use RDFa in HTML5, which would
forsake validation but actually work; or take a less powerful, less
supported (at least for now: many RDFa-aware agents vs. zero HTML5's
microdata -aware agents) that validates but provides no pragmatic
advantages.
IMO, an approach that forces authors to choose between
validity/conformance which doesn't *yet* works vs. invalid solutions
that actually work is a horrible idea: it encourages authors to
forsake validity if they want things to work.
Wouldn't the RDFa + @prefix solution suggested many times work better
and require less effort (for spec writters, for implementors, and for
content authors)? Keep in mind that I don't think RDFa + @prefix is
the solution we need; I'm just trying to point out that the current
approach is even worse than that.

Second issue: as the "decaffeinated RDFa" it is, the HTML5 Microdata
approach tends to fail where RDFa itself fails. It's nice that, thanks
to the <time> element, the problem with trying to reuse human-readable
dates as machine-readable is dodged; but there are other cases where
separate values might be needed: for example using a street address
for the human-readable representation of a location and the exact
geographic coordinates as the machine-readable (since not all
micro-data parsers can rely on Google Maps's database to resolve
street addresses, you know); or using a colored name (such as "lime
green" displayed on lime green color) as the human-readable
representation of a color, and the hexcode (like #00FF00) as the
machine-readable representation. These are just the cases from the top
of my head, and this can't be considered in any way a complete list.
While *favoring* the reuse of human-readable values for the
machine-readable ones is appropiate, because it's the widely most
common case, *forcing* that reuse is a quite bad idea, because it is
*not* the *only* case.

Third issue: also a flaw inherited from RDFa, it can be summarized as
completelly ignoring the requirement I submitted to this list on April
28th, in reply to Ian asking us to review the use cases [1]. I'll try
to illustrate it with a example, inspired by the original use-case:
Let's say someone's marking up a collection of iguanas (or cats, or
even CDs, doesn't really make a difference when illustrating this
issue), making a page for each iguana (or whatever) with all the
details for it; and then making an "index" page listing the maybe 20
iguanas with their name, picture, and link to the corresponding page.
Adding micro-data to that "index", either with RDFa or with Ian's
microdata proposal, would involve stating 20 times in the markup
something like "this is the iguana's picture; this is the iguana's
name; and this is the iguana's URL". It would be preferable to be able
to state something like "each (row) <tr> in the <table> describes an
iguana: the <img>s are each iguana's picture, the contents of the
<a>'s are the names, and the @href of the <a>'s are the URLs to their
main pages" just once. If I only need to state the table headings once
for the users to understand this concept, why should a micro-data
consumer require me to state it 20 times, once for each row?
Please note how such a page would be quite painful to maintain: any
mistake in the micro-data mark-up would generate invalid data and
require a manual harvest of the data on the page, thus killing the
whole purpose of micro-data. And repeating something 20 (or more)
times brings a lot of chances to put a typo in, or to miss an
attribute, or any minor but devastating mistake like these.

Last, but not least, I'm not sure if it was wise to start defining a
solution while some of the requirements seem to be still under
discussion. Actually, I had a possible solution in mind, but I was
holding it while reviewing it against the requiremetns being
discussed, so I could adapt it to any requirements I might had
initially missed. Seeing that solutions are already being discussed
here, I'm trying to put the ideas into a human-readable document that
I plan to submit to this list either late today or early tomorrow for
your review and consideration.


Regards,
Eduard Pascual

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019487.html

From excors+whatwg at gmail.com  Tue May 12 04:59:32 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 12 May 2009 12:59:32 +0100
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <6ea53250905120355jc2ea7f9u4a370137cad55f9d@mail.gmail.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
	<6ea53250905120355jc2ea7f9u4a370137cad55f9d@mail.gmail.com>
Message-ID: <ea09c0d10905120459i2ab12211x433cb02fe0357b10@mail.gmail.com>

On Tue, May 12, 2009 at 11:55 AM, Eduard Pascual <herenvardo at gmail.com> wrote:
> [...]
> (at least for now: many RDFa-aware agents vs. zero HTML5's
> microdata -aware agents)

HTML5 microdata parsers seem pretty trivial to write -
http://philip.html5.org/demos/microdata/demo.html is only about two
hundred lines to read all the data and to produce JSON and
N3-serialised RDF. It shouldn't take more than a few hours to produce
a similar library for other languages, including the time taken to
read the spec, so the implementation cost for generic parser libraries
doesn't seem like a significant problem.

The cost of integration with backend RDF-based systems seems more
significant - hopefully you could simply replace the frontend RDFa
parser with a microdata parser and generate the same RDF triples and
it would all work fine, but I don't know whether that's true in
practice (because maybe the microdata syntax is too restrictive to
represent the vocabularies people want to use, and so they'd have to
go to lots of extra effort to create a new vocabulary).

> [...] there are other cases where
> separate values might be needed: for example using a street address
> for the human-readable representation of a location and the exact
> geographic coordinates as the machine-readable (since not all
> micro-data parsers can rely on Google Maps's database to resolve
> street addresses, you know); or using a colored name (such as "lime
> green" displayed on lime green color) as the human-readable
> representation of a color, and the hexcode (like #00FF00) as the
> machine-readable representation.

You could replace
  <span itemprop="color">lime green</span>
  <span itemprop="location">1 High Street</span>
with
  <meta itemprop="color" content="#00FF00"><span>lime green</span>
  <meta itemprop="location.lat" content="56.78"><meta
itemprop="location.long" content="-12.34"><span>1 High Street</span>
to get the desired output. (Not particularly elegant syntax, though.)

-- 
Philip Taylor
excors at gmail.com

From shelleyp at burningbird.net  Tue May 12 05:30:28 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Tue, 12 May 2009 07:30:28 -0500
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
In-Reply-To: <ea09c0d10905120459i2ab12211x433cb02fe0357b10@mail.gmail.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>	<6ea53250905120355jc2ea7f9u4a370137cad55f9d@mail.gmail.com>
	<ea09c0d10905120459i2ab12211x433cb02fe0357b10@mail.gmail.com>
Message-ID: <4A096BE4.404@burningbird.net>

Philip Taylor wrote:
> On Tue, May 12, 2009 at 11:55 AM, Eduard Pascual <herenvardo at gmail.com> wrote:
>   
>> [...]
>> (at least for now: many RDFa-aware agents vs. zero HTML5's
>> microdata -aware agents)
>>     
>
> HTML5 microdata parsers seem pretty trivial to write -
> http://philip.html5.org/demos/microdata/demo.html is only about two
> hundred lines to read all the data and to produce JSON and
> N3-serialised RDF. It shouldn't take more than a few hours to produce
> a similar library for other languages, including the time taken to
> read the spec, so the implementation cost for generic parser libraries
> doesn't seem like a significant problem.
>   

Writing something that will produce triples may be easy, but what's 
important is that you're producing an RDF model.

Philip, I've been looking at your application, and you're not producing 
the same model for Ian's microdata proposal that is produced using 
either eRDF or RDFa. I'll have more on this later.
> The cost of integration with backend RDF-based systems seems more
> significant - hopefully you could simply replace the frontend RDFa
> parser with a microdata parser and generate the same RDF triples and
> it would all work fine, but I don't know whether that's true in
> practice (because maybe the microdata syntax is too restrictive to
> represent the vocabularies people want to use, and so they'd have to
> go to lots of extra effort to create a new vocabulary).
>
>   
>> [...] there are other cases where
>> separate values might be needed: for example using a street address
>> for the human-readable representation of a location and the exact
>> geographic coordinates as the machine-readable (since not all
>> micro-data parsers can rely on Google Maps's database to resolve
>> street addresses, you know); or using a colored name (such as "lime
>> green" displayed on lime green color) as the human-readable
>> representation of a color, and the hexcode (like #00FF00) as the
>> machine-readable representation.
>>     
>
> You could replace
>   <span itemprop="color">lime green</span>
>   <span itemprop="location">1 High Street</span>
> with
>   <meta itemprop="color" content="#00FF00"><span>lime green</span>
>   <meta itemprop="location.lat" content="56.78"><meta
> itemprop="location.long" content="-12.34"><span>1 High Street</span>
> to get the desired output. (Not particularly elegant syntax, though.)
>
>   

It's funny, but oddly enough, this discussion reminds me of when I 
started at Boeing, right after college. I started just when the great 
debate between SQL and QUEL was ending, in SQL's favor. Most folks still 
feel that QUEL was the "superior" option, but SQL won out in the end 
because it had widespread use, and was supported by more of the 
(powerful) database companies, and hence the companies using the databases.

The same could be said of Betamax versus VHS, and even the recent HDTV 
and Blu-Ray debates: we can get caught up in issues of superiority and 
argue the fine points of (mostly) obscure markup until the cows come 
home, but at some point in time, you have to pick a standard to get 
behind, or no one will any confidence in _any_ of the options being 
proposed--and the concept underlying the competing technologies (or 
standards) is hindered, perhaps for years.

Sorry, I digress. Eduard, looking forward to seeing your own 
interpretation of the best metadata annotation.

Shelley



From julian.reschke at gmx.de  Tue May 12 07:01:18 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 12 May 2009 16:01:18 +0200
Subject: [whatwg] Custom microdata handling added to HTML5 spec
In-Reply-To: <4A075165.1030702@digitalbazaar.com>
References: <4A06FF1C.6030802@burningbird.net>
	<4A075165.1030702@digitalbazaar.com>
Message-ID: <4A09812E.3020209@gmx.de>

Manu Sporny wrote:
> ...
> We are currently working[1] on features to dynamically extending the
> base set of reserved words and the set of pre-defined prefixes through a
> mechanism called RDFa Profiles[2]. It is proposed that this mechanism
> would allow authors to do this in their documents:
> 
> <div profile="http://example.org/myprofile.html"> ...
>   <span property="description">A description for this page.</span>
>   <span about="#me" property="name">Manu Sporny</span>
> </div>
> 
> Note that 'description' and 'name' are not prefixed, but would be mapped
> to a full URI in the document listed by @profile. This allows the ease
> of Microformats-like markup but with all of the rigor of RDFa.
> ...

So, to process the HTML fragment above, a recipient would always need to 
look up the profile resource, and extract RDF triples from *that* 
document (*) first?

How do you prevent the problem we've seen with DTDs (consumers not 
willing or able to cache the resource, and thus re-requesting the same 
resource over and over again)?

BR, Julian

(*) Which specific media types would a recipient be required to support 
for profiles?

From pmika at yahoo-inc.com  Tue May 12 10:27:20 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Tue, 12 May 2009 19:27:20 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
Message-ID: <4A09B178.9090000@yahoo-inc.com>

Just a quick comment on:

   it uses prefixes, which most authors simply do not understand, and
   which many implementors end up getting wrong (e.g. SearchMonkey
   hard-coded certain prefixes in its first implementation, Google's
   handling of RDF blocks for license declarations is all done with

Actually, the problem we see is not so much the prefixes themselves but 
rather the cumbersome way of specifying namespace prefix definitions 
using xmlns. So I think it would make sense to have some mechanism for 
referencing bundles of namespace prefixes ('profiles') or namespace 
registries, in order to easy authoring.

In terms of prefixes, I find that 'com.foaf-project.name' is a lot more 
difficult to write than 'foaf:name'. Reverse domain names are 
non-intuitive for non-programmer types (or non-Java programmers).

Cheers,
Peter

From jackalmage at gmail.com  Tue May 12 10:30:27 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 12 May 2009 12:30:27 -0500
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <6ea53250905120355jc2ea7f9u4a370137cad55f9d@mail.gmail.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
	<6ea53250905120355jc2ea7f9u4a370137cad55f9d@mail.gmail.com>
Message-ID: <dd0fbad0905121030x5a745921tcc6d1913324530e5@mail.gmail.com>

On Tue, May 12, 2009 at 5:55 AM, Eduard Pascual <herenvardo at gmail.com> wrote:
> Third issue: also a flaw inherited from RDFa, it can be summarized as
> completelly ignoring the requirement I submitted to this list on April
> 28th, in reply to Ian asking us to review the use cases [1]. I'll try
> to illustrate it with a example, inspired by the original use-case:
> Let's say someone's marking up a collection of iguanas (or cats, or
> even CDs, doesn't really make a difference when illustrating this
> issue), making a page for each iguana (or whatever) with all the
> details for it; and then making an "index" page listing the maybe 20
> iguanas with their name, picture, and link to the corresponding page.
> Adding micro-data to that "index", either with RDFa or with Ian's
> microdata proposal, would involve stating 20 times in the markup
> something like "this is the iguana's picture; this is the iguana's
> name; and this is the iguana's URL". It would be preferable to be able
> to state something like "each (row) <tr> in the <table> describes an
> iguana: the <img>s are each iguana's picture, the contents of the
> <a>'s are the names, and the @href of the <a>'s are the URLs to their
> main pages" just once. If I only need to state the table headings once
> for the users to understand this concept, why should a micro-data
> consumer require me to state it 20 times, once for each row?
> Please note how such a page would be quite painful to maintain: any
> mistake in the micro-data mark-up would generate invalid data and
> require a manual harvest of the data on the page, thus killing the
> whole purpose of micro-data. And repeating something 20 (or more)
> times brings a lot of chances to put a typo in, or to miss an
> attribute, or any minor but devastating mistake like these.

Well, he didn't quite *ignore* it - he did explicitly call out that
requirement to say that his solution didn't solve it at all.  He also
laid down the reason why - it's unlikely that any reasonable simple
in-place metadata solution would allow you to do that.  You either
need significant complexity, some reliance on language semantics (like
tables can rely on their headers), or moving to out-of-band
specification, likely through a Selectors-based model.

The last is likely the best solution for that, and is even easier to
implement within Ian' simplified proposal.  I don't see a good reason
why that can't advance on a separate track, as (being out-of-band) it
doesn't require changes to HTML to be usable.

I floated a basic proposal for Cascading RDF[1] several months ago,
and someone else (I think Eduard?  I'd have to check my archives) did
something very similar.

[1]: http://www.xanthir.com/rdfa-vs-crdf.php

~TJ

From jonas at sicking.cc  Tue May 12 12:01:57 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 12 May 2009 12:01:57 -0700
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <p0624081ac62d3543eff2@17.202.35.52>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com> 
	<63df84f0905042146v53f4b8f2r5cca09c97a274a49@mail.gmail.com> 
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52> 
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com> 
	<p06240804c62921c89a85@17.202.35.52>
	<2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com> 
	<p06240805c62a0c11e4a7@10.0.1.6>
	<2c0e02830905082109t64fa89aaj5dd50933c3d9283@mail.gmail.com> 
	<p0624081ac62d3543eff2@17.202.35.52>
Message-ID: <63df84f0905121201o5da6fae9u12a2396ce70cfef9@mail.gmail.com>

On Sun, May 10, 2009 at 6:56 PM, David Singer <singer at apple.com> wrote:
> At 14:09 ?+1000 9/05/09, Silvia Pfeiffer wrote:
>> ?Of course none of the
>> discussion will inherently disallow seeking - scripts will always be
>> able to do the seeking. But the user may not find it easy to do
>> seeking to a section that is not accessible through the displayed
>> timeline, which can be both a good and a bad thing.
>
> How easy a particular user interface is to use for various tasks is (I hope)
> not our worry...

I'm not sure I agree. If the spec provides a feature set that no one
is able to create a useful UI for, then there definitely might be a
problem with the spec.

I still have not received any comments on my previous assertion that
there are essentially two separate use cases here. One for bringing
attention to a specific point in a larger context, one for showing
only a smaller range of a video.

I do think both of these can be addressed using fragment identifiers,
but I do think we should treat them separately.

The fact that one of the bigger video sites today, youtube, has
support for displaying a given point in a larger context leads at
least some credibility to that people actually want to do this.

/ Jonas

From erik at textivism.com  Tue May 12 12:07:01 2009
From: erik at textivism.com (Erik Vorhes)
Date: Tue, 12 May 2009 14:07:01 -0500
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
	audio/ video
Message-ID: <22d65dda0905121207v3da5cd2cv2180b726f11c1d1b@mail.gmail.com>

On Sat, May 9, 2009, at 2:16 PM, Tab Atkins Jr. wrote:
> The issue is that not all browsers have significant configs (I'm
> thinking of mobile browsers here), and I don't believe their inability
> to provide such a choice to the user should make them nonconforming.

If a UA is incapable of audio output, by extension it conforms to
wording that uses MUST. (That is, it mutes audio by default, as it
provides no means to play audio.) So I'm not sure this is an actual
issue. In the illogical event that an audio-free UA wouldn't conform
to this requirement, surely it's possible to word the specification in
such a way that exempts those browsers from the requirement.


> As well, recall that the majority browser for 'unsophisticated' users
> is still IE6 or 7, and IE8 still lacks any support for <video> at all

What does the lack of support for <video> in IE 6-8 have to do with an
argument against requiring UAs to mute audio in <audio> and <video>?
Because those browsers exist without support for those elements, it
falls upon developers, content producers, et al., to make a good-faith
effort to provide accessible (and screenreader-friendly) content; the
wording of the HTML5 spec doesn't change current conditions, nor
should it be expected to.


Thanks,
Erik Vorhes

From msporny at digitalbazaar.com  Tue May 12 12:24:23 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue, 12 May 2009 15:24:23 -0400
Subject: [whatwg] Google announces Microformats/RDFa support
Message-ID: <4A09CCE7.5080101@digitalbazaar.com>

Google announces Microformats/RDFa support
http://lists.w3.org/Archives/Public/public-rdfa/2009May/0011.html

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/


From ian at hixie.ch  Tue May 12 13:19:57 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 May 2009 20:19:57 +0000 (UTC)
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
In-Reply-To: <4A09B178.9090000@yahoo-inc.com>
References: <4A09B178.9090000@yahoo-inc.com>
Message-ID: <Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>

On Tue, 12 May 2009, Peter Mika wrote:
>
> Just a quick comment on:
> 
>   it uses prefixes, which most authors simply do not understand, and
>   which many implementors end up getting wrong (e.g. SearchMonkey
>   hard-coded certain prefixes in its first implementation, Google's
>   handling of RDF blocks for license declarations is all done with
> 
> Actually, the problem we see is not so much the prefixes themselves but rather
> the cumbersome way of specifying namespace prefix definitions using xmlns. So
> I think it would make sense to have some mechanism for referencing bundles of
> namespace prefixes ('profiles') or namespace registries, in order to easy
> authoring.
> 
> In terms of prefixes, I find that 'com.foaf-project.name' is a lot more 
> difficult to write than 'foaf:name'. Reverse domain names are 
> non-intuitive for non-programmer types (or non-Java programmers).

If we can come up with a way of using the string "foaf:name" without 
having to declare "foaf" in each document, I'm totally in agreement. I've 
considered maybe registering the "foaf" URL scheme, or using some other 
punctuation character and having people register prefixes, but I don't 
know what punctuation character to use (':' and '.' are both taken).

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

From shelleyp at burningbird.net  Tue May 12 13:34:45 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Tue, 12 May 2009 15:34:45 -0500
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
In-Reply-To: <Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>
References: <4A09B178.9090000@yahoo-inc.com>
	<Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>
Message-ID: <4A09DD65.6010805@burningbird.net>

Ian Hickson wrote:
> On Tue, 12 May 2009, Peter Mika wrote:
>   
>> Just a quick comment on:
>>
>>   it uses prefixes, which most authors simply do not understand, and
>>   which many implementors end up getting wrong (e.g. SearchMonkey
>>   hard-coded certain prefixes in its first implementation, Google's
>>   handling of RDF blocks for license declarations is all done with
>>
>> Actually, the problem we see is not so much the prefixes themselves but rather
>> the cumbersome way of specifying namespace prefix definitions using xmlns. So
>> I think it would make sense to have some mechanism for referencing bundles of
>> namespace prefixes ('profiles') or namespace registries, in order to easy
>> authoring.
>>
>> In terms of prefixes, I find that 'com.foaf-project.name' is a lot more 
>> difficult to write than 'foaf:name'. Reverse domain names are 
>> non-intuitive for non-programmer types (or non-Java programmers).
>>     
>
> If we can come up with a way of using the string "foaf:name" without 
> having to declare "foaf" in each document, I'm totally in agreement. I've 
> considered maybe registering the "foaf" URL scheme, or using some other 
> punctuation character and having people register prefixes, but I don't 
> know what punctuation character to use (':' and '.' are both taken).
>
>   
But then we would lose the extensibility, which is the power behind all 
of this.

If I remember correctly, Henri had an issue with the DOM when it came to 
support of namespaces in XHTML, and not in HTML, which was the reason 
that @prefix or something along those lines proposed. There was quite 
positive progress in this regard, too. I don't know what happened to 
that progress.

But regardless, the majority of people will include metadata markup by 
installing a plug-in or module, and making a couple of choices. And if 
you put together a good ten-minute tutorial for the average developer, 
they'll have no problem with "foaf:name". Training and clarity of 
communication is much ore important than form, it always has been with 
technology.

The examples you come up with just don't justify discarding 
consideration of a capability that just started getting incorporated 
into Google search. I would say if your fellow Google developers could 
understand how this all works, there is hope for others.

Shelley

From rubys at intertwingly.net  Tue May 12 14:21:10 2009
From: rubys at intertwingly.net (Sam Ruby)
Date: Tue, 12 May 2009 17:21:10 -0400
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <4A09DD65.6010805@burningbird.net>
References: <4A09B178.9090000@yahoo-inc.com>
	<Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>
	<4A09DD65.6010805@burningbird.net>
Message-ID: <3d4032300905121421n411bb7e2q6dea4650cc59107@mail.gmail.com>

On Tue, May 12, 2009 at 4:34 PM, Shelley Powers
<shelleyp at burningbird.net> wrote:
>
> I
> would say if your fellow Google developers could understand how this all
> works, there is hope for others.

"if"

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0064.html

> Shelley

- Sam Ruby

From shelleyp at burningbird.net  Tue May 12 14:42:58 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Tue, 12 May 2009 16:42:58 -0500
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
In-Reply-To: <3d4032300905121421n411bb7e2q6dea4650cc59107@mail.gmail.com>
References: <4A09B178.9090000@yahoo-inc.com>	<Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>	<4A09DD65.6010805@burningbird.net>
	<3d4032300905121421n411bb7e2q6dea4650cc59107@mail.gmail.com>
Message-ID: <4A09ED62.7050908@burningbird.net>

Sam Ruby wrote:
> On Tue, May 12, 2009 at 4:34 PM, Shelley Powers
> <shelleyp at burningbird.net> wrote:
>   
>> I
>> would say if your fellow Google developers could understand how this all
>> works, there is hope for others.
>>     
>
> "if"
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0064.html
>
>   
> \
> - Sam Ruby
>
>   
Ah heck, I've made mistakes with vocabularies too. That's why you ask 
for feedback. Unfortunately, asking for feedback isn't an option when 
you're creating secret stuff.

I could have wished Google used FOAF or DC, too, but it's a start.

Shelley

From excors+whatwg at gmail.com  Tue May 12 15:09:25 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 12 May 2009 23:09:25 +0100
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <3d4032300905121421n411bb7e2q6dea4650cc59107@mail.gmail.com>
References: <4A09B178.9090000@yahoo-inc.com>
	<Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>
	<4A09DD65.6010805@burningbird.net>
	<3d4032300905121421n411bb7e2q6dea4650cc59107@mail.gmail.com>
Message-ID: <ea09c0d10905121509j44dd03b3h20eb0b21dcac9e14@mail.gmail.com>

On Tue, May 12, 2009 at 10:21 PM, Sam Ruby <rubys at intertwingly.net> wrote:
> On Tue, May 12, 2009 at 4:34 PM, Shelley Powers
> <shelleyp at burningbird.net> wrote:
>>
>> I
>> would say if your fellow Google developers could understand how this all
>> works, there is hope for others.
>
> "if"
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0064.html

Also: The instructions at
http://google.com/support/webmasters/bin/answer.py?answer=146898 (and
related pages) alternate between
 xmlns:v="http://rdf.data-vocabulary.org"
and
 xmlns:v="http://rdf.data-vocabulary.org/"
seemingly at random.

(The first means that property="v:name" abbreviates the bogus URI
"http://rdf.data-vocabulary.orgname", if I understand correctly. The
second means it's "http://rdf.data-vocabulary.org/name" which is a
404. Perhaps they meant xmlns:v="http://rdf.data-vocabulary.org/#"
which would point at the relevant bit of the vocabulary RDF file?
Hopefully people won't actually deploy content using the inconsistent
namespaces before the documentation is fixed...)

(They've also got a "<span<strong property="v:name">" and "<spanspan
property="v:locality">" and some unclosed <a>s, so it seems the
documentation writers are having difficulty even writing plain HTML.)

-- 
Philip Taylor
excors at gmail.com

From silviapfeiffer1 at gmail.com  Tue May 12 19:09:04 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 13 May 2009 12:09:04 +1000
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <63df84f0905121201o5da6fae9u12a2396ce70cfef9@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com> 
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52> 
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com> 
	<p06240804c62921c89a85@17.202.35.52>
	<2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com> 
	<p06240805c62a0c11e4a7@10.0.1.6>
	<2c0e02830905082109t64fa89aaj5dd50933c3d9283@mail.gmail.com> 
	<p0624081ac62d3543eff2@17.202.35.52>
	<63df84f0905121201o5da6fae9u12a2396ce70cfef9@mail.gmail.com>
Message-ID: <2c0e02830905121909m53fe1593j46d1932644720ae4@mail.gmail.com>

On Wed, May 13, 2009 at 5:01 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Sun, May 10, 2009 at 6:56 PM, David Singer <singer at apple.com> wrote:
>> At 14:09 ?+1000 9/05/09, Silvia Pfeiffer wrote:
>>> ?Of course none of the
>>> discussion will inherently disallow seeking - scripts will always be
>>> able to do the seeking. But the user may not find it easy to do
>>> seeking to a section that is not accessible through the displayed
>>> timeline, which can be both a good and a bad thing.
>>
>> How easy a particular user interface is to use for various tasks is (I hope)
>> not our worry...
>
> I'm not sure I agree. If the spec provides a feature set that no one
> is able to create a useful UI for, then there definitely might be a
> problem with the spec.
>
> I still have not received any comments on my previous assertion that
> there are essentially two separate use cases here. One for bringing
> attention to a specific point in a larger context, one for showing
> only a smaller range of a video.

Just to confirm: yes, there are two separate use cases. (I was under
the impression that the discussion had brought that out).

The question is how to distinguish them and which component should
make the choice.


> I do think both of these can be addressed using fragment identifiers,
> but I do think we should treat them separately.

They could be addresses using fragment identifiers, but then it's up
to the UA to decide when to display what and different UA
implementations will become inconsistent.

The challenge is to find a means of treating them separately in a
predefined way.

Thus, the idea of using "fragment" for attention (in YouTube style)
and "query" for focus on the now restricted new resource.

We're having that discussion now in the media fragment WG.

Cheers,
Silvia.

> The fact that one of the bigger video sites today, youtube, has
> support for displaying a given point in a larger context leads at
> least some credibility to that people actually want to do this.
>
> / Jonas
>

From lhs at malform.no  Tue May 12 20:45:13 2009
From: lhs at malform.no (Leif Halvard Silli)
Date: Wed, 13 May 2009 05:45:13 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
Message-ID: <4A0A4249.8010209@malform.no>

Tab Atkins Jr. on Tue, 12 May 2009 12:30:27 -0500:

> On Tue, May 12, 2009 at 5:55 AM, Eduard Pascual:
>   
>> > [...] It would be preferable to be able
>> > to state something like "each (row) <tr> in the <table> describes an
>> > iguana: the <img>s are each iguana's picture, the contents of the
>> > <a>'s are the names, and the @href of the <a>'s are the URLs to their
>> > main pages" just once.
Indeed.
>> > If I only need to state the table headings once
>> > for the users to understand this concept, why should a micro-data
>> > consumer require me to state it 20 times, once for each row?
>> > Please note how such a page would be quite painful to maintain: any
>> > mistake in the micro-data mark-up would generate invalid data and
>> > require a manual harvest of the data on the page, thus killing the
>> > whole purpose of micro-data.

Indeed. (But of course, for "copy-paste" safety, the format has to be 
"wordy" and repetitive.)

>>  And repeating something 20 (or more)
>> > times brings a lot of chances to put a typo in, or to miss an
>> > attribute, or any minor but devastating mistake like these.
>>     
>
> Well, he didn't quite *ignore* it - he did explicitly call out that
> requirement to say that his solution didn't solve it at all.  He also
> laid down the reason why - it's unlikely that any reasonable simple
> in-place metadata solution would allow you to do that.  You either
> need significant complexity, some reliance on language semantics (like
> tables can rely on their headers), or moving to out-of-band
> specification, likely through a Selectors-based model.
>   
Indeed. And Ian's arguments against a selector based model (the claim 
that authors have problems understanding selectors) was one of the least 
convincing arguments he made, I think.  CSS and selectors appears to be 
one of the best understood technologies of the web.
> The last is likely the best solution for that, and is even easier to
> implement within Ian' simplified proposal.  I don't see a good reason
> why that can't advance on a separate track, as (being out-of-band) it
> doesn't require changes to HTML to be usable.
>
> I floated a basic proposal for Cascading RDF[1] several months ago,
> and someone else (I think Eduard?  I'd have to check my archives) did
> something very similar.
>
> [1]: http://www.xanthir.com/rdfa-vs-crdf.php
>   

Hear hear.  Lets call it "Cascading RDF Sheets". It could be used for 
the following purposes:

1. The IRI of the Cascading RDF Sheet could serve the role of profile URI;
2. The Cascading RDF Sheet itself could serve the role of a profile 
document; (Finally we could get some kind of registered profile format.)
3. Just as CSS sheets today, a cRDFsheet could be used as authoring 
help, when authoring with a microformat. HTML editing programs could 
offer the elements + classes in the Cascading RDF Sheet to authors, the 
same way that some editors to today use the selectors in stylesheets as 
a "vocabulary repository" for the current file or project. CSS selectors 
is already a well known format. (One may then, of course, already use a 
CSS style sheet for this, kind of. But this soon becomes clumsy. Better 
to separate styling from semantics and structure.)

In fact, I myself begun looking into creating something along these 
lines ... Though rather than a "Cascading RDF Sheet", I looked into 
creating a "Profile Style Sheet" which could be used to define a machine 
readable microformat profile. My motivation for doing this was the 
authoring side of things, as I have been using a text editor which more 
or less uses CSS selectors the same way. (Instead of only offering me to 
pick "<p>" it also offers me to to pick <p class="a"> etc.) Ian's 
proposal do not give much thought about the authoring side, I feel, 
except  for the more casual author. For authors, it is helpful to have a 
"recipe" document and to avoid repetition and "data rot", as you 
mentioned in another message.

Ian's microdata format is easy to grasp the inner logics of - that is a 
good side of the proposal, this could help that it gets used.  But when 
it comes to author's and author groups' ability to define their own, 
decentralised semantics etc., then a decent profile format, which could 
be easily and simply integrated with authoring tools,  seems like a just 
as important  issue as a super simple microdata format.

The microformats.org community does not really have a machine parsable 
profile format. If there were such a format, I believe we would see more 
of more decentralized microformats.
-- 
leif halvard silli

From jackalmage at gmail.com  Tue May 12 21:19:21 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 12 May 2009 23:19:21 -0500
Subject: [whatwg] Spec should require UAs to have control to mute/ pause
	audio/ video
In-Reply-To: <22d65dda0905121207v3da5cd2cv2180b726f11c1d1b@mail.gmail.com>
References: <22d65dda0905121207v3da5cd2cv2180b726f11c1d1b@mail.gmail.com>
Message-ID: <dd0fbad0905122119v2cf46eb5i870bbfc1dc710761@mail.gmail.com>

On Tue, May 12, 2009 at 2:07 PM, Erik Vorhes <erik at textivism.com> wrote:
> On Sat, May 9, 2009, at 2:16 PM, Tab Atkins Jr. wrote:
>> The issue is that not all browsers have significant configs (I'm
>> thinking of mobile browsers here), and I don't believe their inability
>> to provide such a choice to the user should make them nonconforming.
>
> If a UA is incapable of audio output, by extension it conforms to
> wording that uses MUST. (That is, it mutes audio by default, as it
> provides no means to play audio.) So I'm not sure this is an actual
> issue. In the illogical event that an audio-free UA wouldn't conform
> to this requirement, surely it's possible to word the specification in
> such a way that exempts those browsers from the requirement.

Sorry, I meant mobile browsers *with* audio but *without* significant
config dialogs.

>> As well, recall that the majority browser for 'unsophisticated' users
>> is still IE6 or 7, and IE8 still lacks any support for <video> at all
>
> What does the lack of support for <video> in IE 6-8 have to do with an
> argument against requiring UAs to mute audio in <audio> and <video>?
> Because those browsers exist without support for those elements, it
> falls upon developers, content producers, et al., to make a good-faith
> effort to provide accessible (and screenreader-friendly) content; the
> wording of the HTML5 spec doesn't change current conditions, nor
> should it be expected to.

Part of your argument against just making this a SHOULD was about
people not having the knowledge or ability to switch browsers, in the
event that their current browser doesn't provide them a way to
globally mute <audio>/<video>.  My point was that the vast majority of
such people are on one of the versions of Internet Explorer, as that
is the basic 'default' on Windows.  Given that IE, even up through
IE8, doesn't support  <audio>/<video> at all, let alone with special
consideration for accessibility, those people without the
knowledge/ability to switch browsers are pretty much stuck anyway, no
matter what the spec says.

Thus, it should be acceptable to push browser vendors to provide this
feature simple for accessibility purposes, and those users who *can*
switch their browsers will be able to switch to one that implements
this.

~TJ

From singer at apple.com  Tue May 12 21:29:42 2009
From: singer at apple.com (David Singer)
Date: Wed, 13 May 2009 12:29:42 +0800
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <2c0e02830905121909m53fe1593j46d1932644720ae4@mail.gmail.com>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com>
	<689BD7C26A984B449F0093F84297F8F4@POCZTOWIEC>
	<p062408ffc628e0b05904@17.202.35.52>
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com>
	<p06240804c62921c89a85@17.202.35.52>
	<2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com>
	<p06240805c62a0c11e4a7@10.0.1.6>
	<2c0e02830905082109t64fa89aaj5dd50933c3d9283@mail.gmail.com>
	<p0624081ac62d3543eff2@17.202.35.52>
	<63df84f0905121201o5da6fae9u12a2396ce70cfef9@mail.gmail.com>
	<2c0e02830905121909m53fe1593j46d1932644720ae4@mail.gmail.com>
Message-ID: <p0624084bc62ffca8921a@[17.202.35.52]>

At 12:09  +1000 13/05/09, Silvia Pfeiffer wrote:
>On Wed, May 13, 2009 at 5:01 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>  On Sun, May 10, 2009 at 6:56 PM, David Singer <singer at apple.com> wrote:
>>>  At 14:09  +1000 9/05/09, Silvia Pfeiffer wrote:
>>>>   Of course none of the
>>>>  discussion will inherently disallow seeking - scripts will always be
>>>>  able to do the seeking. But the user may not find it easy to do
>>>>  seeking to a section that is not accessible through the displayed
>>>>  timeline, which can be both a good and a bad thing.
>>>
>>>  How easy a particular user interface is to use for various tasks 
>>>is (I hope)
>>>  not our worry...
>>
>>  I'm not sure I agree. If the spec provides a feature set that no one
>>  is able to create a useful UI for, then there definitely might be a
>>  problem with the spec.
>>
>>  I still have not received any comments on my previous assertion that
>>  there are essentially two separate use cases here. One for bringing
>>  attention to a specific point in a larger context, one for showing
>>  only a smaller range of a video.
>
>Just to confirm: yes, there are two separate use cases. (I was under
>the impression that the discussion had brought that out).

Yes, that's fine.  I think it's clear that we could have a 'verb' in 
the fragment "focus-on", "select" etc. to indicate that.  I think 
it's also clear that no matter what verb is used, the entire resource 
is 'available' to the UA, that scripts can (if they wish) navigate 
anywhere in the entire resource, and that UAs can optimize the 
interface for the given verb, but the interface can still permit 
access to the entire resource.
-- 
David Singer
Multimedia Standards, Apple Inc.

From mail at tobyinkster.co.uk  Wed May 13 02:19:17 2009
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Wed, 13 May 2009 10:19:17 +0100
Subject: [whatwg] Annotating structured data that HTML has no
	semantics	for
In-Reply-To: <4A0A4249.8010209@malform.no>
Message-ID: <1242206357.15673.62.camel@ophelia2.g5n.co.uk>

Leif Halvard Silli wrote:

> Hear hear.  Lets call it "Cascading RDF Sheets".

http://buzzword.org.uk/2008/rdf-ease/spec

http://buzzword.org.uk/2008/rdf-ease/reactions

I have actually implemented it. It works. RDFa is better though.

-Toby

From lhs at malform.no  Wed May 13 08:04:54 2009
From: lhs at malform.no (Leif Halvard Silli)
Date: Wed, 13 May 2009 17:04:54 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics for
Message-ID: <4A0AE196.7040906@malform.no>

Toby Inkster on Wed May 13 02:19:17 PDT 2009:
> Leif Halvard Silli wrote:
>
> > Hear hear.  Lets call it "Cascading RDF Sheets".
>
> http://buzzword.org.uk/2008/rdf-ease/spec
>
> http://buzzword.org.uk/2008/rdf-ease/reactions
>
> I have actually implemented it. It works.

Oh! Thanks for sharing.

> RDFa is better though.

What does 'better' mean in this context? Why and how? Because it is 
easier to process? But EASE seems more compatible with microformats, and 
is "better" in that sense.

I read all the reactions you pointed to. Some made the claim that EASE 
would move semantics out of the HTML file, and that microformats was 
better as it keeps the semantics inside the file. But I of course agree 
with you that EASE just underline/outline the semantics already in the file.

The thing that probably is most different from (most) microformats (and 
RDFa?) is that EASE can apply semantics even to bare naked elements 
without any @class, @id or other attributes. However, EASE do not 
/require/ one to use it like that. One may choose to create an entirely 
class based EASE document.

It would even be possible to use EASE together with Ian's microdata, 
don't you think?

 From the EASE draft:
> All properties in RDF-EASE begin with the string -rdf-, as per 
> ?4.1.2.1 Vendor-specific extensions in [CSS21]. This allows RDF-EASE 
> and CSS to be safely mixed in one file, [...]
I wonder why you think it is so important to be able to mix CSS and 
EASE. It seems better to separate the two completely.

 From the EASE draft:
> The algorithm assumes that the document is held in a DOM-compatible 
> representation,
Side kick: <meta> is proposed as part of microdata. But both Firefox and 
Safari will in the DOM render <meta> as part of <head>, regardless.
-- 
leif halvard silli

From giovanni.gentili at gmail.com  Wed May 13 08:07:09 2009
From: giovanni.gentili at gmail.com (Giovanni Gentili)
Date: Wed, 13 May 2009 17:07:09 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>
References: <4A09B178.9090000@yahoo-inc.com>
	<Pine.LNX.4.62.0905122018310.7824@hixie.dreamhostps.com>
Message-ID: <4a30f5360905130807l32b2e85sce72ee7280bee38f@mail.gmail.com>

>> In terms of prefixes, I find that 'com.foaf-project.name' is a lot more
>> difficult to write than 'foaf:name'. Reverse domain names are
>> non-intuitive for non-programmer types (or non-Java programmers).
>
> If we can come up with a way of using the string "foaf:name" without
> having to declare "foaf" in each document, I'm totally in agreement. I've
> considered maybe registering the "foaf" URL scheme, or using some other
> punctuation character and having people register prefixes, but I don't
> know what punctuation character to use (':' and '.' are both taken).

put in HTML5 some predefinited prefixes for @itemprop:

dc = http://purl.org/dc/terms/
foaf = http://xmlns.com/foaf/0.1/
vcard = http://www.w3.org/2001/vcard-rdf/3.0#
owl = http://www.w3.org/2002/07/owl#
rdf = http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs = http://www.w3.org/2000/01/rdf-schema#
sioc = http://rdfs.org/sioc/ns#
skos = http://www.w3.org/2004/02/skos/core#
xsd = http://www.w3.org/2001/XMLSchema#

also, instead of @item @itemprop @subject
is better @item @prop @subj
or @rdf-typeof @rdf-property @rdf-about (and @rdf-rel)
-- 
Giovanni Gentili

From erik.arvidsson at gmail.com  Wed May 13 08:45:06 2009
From: erik.arvidsson at gmail.com (Erik Arvidsson)
Date: Wed, 13 May 2009 08:45:06 -0700
Subject: [whatwg] DOMTokenList is unordered but yet requires sorting
Message-ID: <6eeb8bd10905130845o3f7e516dv50dedd35052f8979@mail.gmail.com>

Section 2.9.3 DOMTokenList says:

The DOMTokenList interface represents an interface to an underlying string
that consists of an *unordered* set of unique space-separated tokens.


Yet, the item method says:

The item(index) method must split the underlying string on spaces, *sort the
resulting list of tokens by Unicode code point*, remove exact duplicates,
and then return the indexth item in this list. If index is equal to or
greater than the number of tokens, then the method must return null.


What is the reason for requiring the set to be ordered in
item? It seems reasonable to say that the order of item is
implementation specific but require that it is stable between changes
of the class name.
If we still want to enforce that item returns the items in the sorted order
we should change the spec to say that DOMTokenList represents an ordered set
instead.


-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090513/92cebb94/attachment.htm>

From herenvardo at gmail.com  Wed May 13 11:16:54 2009
From: herenvardo at gmail.com (Eduard Pascual)
Date: Wed, 13 May 2009 20:16:54 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <dd0fbad0905121030x5a745921tcc6d1913324530e5@mail.gmail.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com> 
	<6ea53250905120355jc2ea7f9u4a370137cad55f9d@mail.gmail.com> 
	<dd0fbad0905121030x5a745921tcc6d1913324530e5@mail.gmail.com>
Message-ID: <6ea53250905131116l3e8f9a4evdb7048de80507079@mail.gmail.com>

Let me start with some apologies:

On Tue, May 12, 2009 at 12:55 PM, Eduard Pascual <herenvardo at gmail.com> wrote:
> [...]
> Seeing that solutions are already being discussed
> here, I'm trying to put the ideas into a human-readable document that
> I plan to submit to this list either late today or early tomorrow for
> your review and consideration.
Oops, I'm already late with that. I had some unexpected compromises and
had no time to finish that doc. I still hope, however, to publish it today.

On Tue, May 12, 2009 at 12:55 PM, Eduard Pascual <herenvardo at gmail.com> wrote:
> [...]
> Third issue: also a flaw inherited from RDFa, it can be summarized as
> completelly ignoring the requirement I submitted to this list on April
> 28th, in reply to Ian asking us to review the use cases [1].
> [...]
> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019487.html

On Tue, May 12, 2009 at 7:30 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> Well, he didn't quite *ignore* it - he did explicitly call out that
> requirement to say that his solution didn't solve it at all.

I missed that part of Ian's post, sorry. I really read it from top to bottom,
but it was quite long. I guess I should have re-read it.
Now, after some re-reading, I have noticed a point I should reply to:

On Sun, May 10, 2009 at 12:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> [...]
>     * Any additional markup or data used to allow the machine to understand
>       the actual information shouldn't be redundantly repeated (e.g. on each
>       cell of a table, when setting it on the column is possible).
>
> This isn't met at all with the current proposal. Unfortunately the only
> general solutions I could come up with that would allow this were
> selector-based, and in practice authors are still having trouble
> understanding how to use Selectors even with CSS.

First, I'd like to ask for a clarification from Ian: what do you mean by
"autrhos are still having trouble understanding how to use Selectors"?
If you mean that they have trouble when trying to select something like
"the second cell of the first row that has a 'foo' attribute different from
'bar' within tables that have four or more rows" or even more obscure stuff,
then I should agree: most authors will definitely have trouble dealing with
so complex cases, and I bet many will always have such trouble. However, if
you mean that authors can't deal with simple class, id, and/or
children/descendant
selectors, then I think you are seriously understimating authors.
On a side note, I'd like to advance that my idea, despite being Selector-based
(actually, I should say CSS-based: it reuses quite more than
selectors), wouldn't
require authors to use selectors at all, at least for the cases that
can currently
be solved by RDFa (or, FWIW, with the current Microdata approach on
the spec); the
same way a page can be completely styled with CSS without using
selectors, via the
"style" attribute.

On Tue, May 12, 2009 at 1:59 PM, Philip Taylor <excors+whatwg at gmail.com> wrote:
> On Tue, May 12, 2009 at 11:55 AM, Eduard Pascual <herenvardo at gmail.com> wrote:
>> [...]
>> (at least for now: many RDFa-aware agents vs. zero HTML5's
>> microdata -aware agents)
>
> HTML5 microdata parsers seem pretty trivial to write -
> http://philip.html5.org/demos/microdata/demo.html is only about two
> hundred lines to read all the data and to produce JSON and
> N3-serialised RDF. It shouldn't take more than a few hours to produce
> a similar library for other languages, including the time taken to
> read the spec, so the implementation cost for generic parser libraries
> doesn't seem like a significant problem.

Actually, I was thinking about the cost of deploying implementations,
rather than
writting them, since RDFa consumers are already out there and working. This,
however, strays a bit out of the original idea: it's not really a matter of how
big the cost is on its own, but of what do you get for that cost. This
is probably
my own fault, but I still fail to see what Ian's suggestion offers
that RDFa doesn't;
so my impression is that these costs, even if they are small, are
buying nothing, so
they are not worth it. If someone is willing to highlight what makes
this proposal
worth the costs (ie: what makes it better than RDFa), I'm willing to listen.

On Tue, May 12, 2009 at 2:30 PM, Shelley Powers
<shelleyp at burningbird.net> wrote:
> [...] Eduard, looking forward to seeing your own interpretation
> of the best metadata annotation.

Hey, who said my proposal will be, or try to be, the "best" one?
Definitelly, I didn't.
Actually, the reason to submit it here will be to have other people
look at it and
figure out ways to improve it (and I'm quite sure it can be improved,
I'm human after all).
Please, let me explicitly state that I don't pretend that idea to be
the "best" solution.
Since neither RDFa, nor Microformats, nor Ian's proposal could solve
my needs, my goal was
to build a solution that solves both my needs, and those solved by
other approaches, as a
proof that a solution that solves them all is *possible*.
Besides that, I'm glad I caught your interest.

On Tue, May 12, 2009 at 7:30 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> [...]
> I floated a basic proposal for Cascading RDF[1] several months ago,
> and someone else (I think Eduard?  I'd have to check my archives) did
> something very similar.
>
> [1]: http://www.xanthir.com/rdfa-vs-crdf.php

First: yes, it was me. Second: I can't really say how similar my idea
was to your proposal
because, honestly, I'm still unable to understand it (maybe it could
take benefit of a bit of
explanation, since it's barely an intro and an example). Anyway, once
I publish mine and you
see it you should be able to figure out wether they are similar or
not. And hopefully, we
might take the best of each and put it together to make something that
is better than either
your proposal or mine ;)

> I don't see a good reason why that can't advance on a separate track,
> as (being out-of-band) it doesn't require changes to HTML to be usable.
Actually, my proposal would require a minor change to HTML (an
attribute, for which no specific
name is enforced, that would mirror CSS's "style" attribute).
In addition, this comment has raised a doubt: where should I post the
doc once it's ready?
In this thread? On a new thread on the list? Somewhere else?


This said, it's only left to go back to work and finish the proposal document.

Regards,
Eduard Pascual

From giecrilj at stegny.2a.pl  Thu May 14 00:30:03 2009
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Thu, 14 May 2009 09:30:03 +0200
Subject: [whatwg] DOMTokenList is unordered but yet requires sorting
In-Reply-To: <6eeb8bd10905130845o3f7e516dv50dedd35052f8979@mail.gmail.com>
References: <6eeb8bd10905130845o3f7e516dv50dedd35052f8979@mail.gmail.com>
Message-ID: <390F704398754DA594B49023189CB25F@POCZTOWIEC>

If a token list represented an ordered set, it could not be sorted to get an
item because the host would have to preserve the original (document) order
of tokens.

Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090514/f434fe29/attachment.htm>

From jgraham at opera.com  Thu May 14 01:45:48 2009
From: jgraham at opera.com (James Graham)
Date: Thu, 14 May 2009 10:45:48 +0200
Subject: [whatwg] Annotating structured data that HTML has no	semantics
 for
In-Reply-To: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
Message-ID: <4A0BDA3C.3020709@opera.com>

jgraham at opera.com wrote:
> Quoting Philip Taylor <excors+whatwg at gmail.com>:
> 
>> On Sun, May 10, 2009 at 11:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>> One of the more elaborate use cases I collected from the e-mails sent in
>>> over the past few months was the following:
>>>
>>>   USE CASE: Annotate structured data that HTML has no semantics for, and
>>>   which nobody has annotated before, and may never again, for private 
>>> use or
>>>   use in a small self-contained community.
>>>
>>> [...]
>>>
>>> To address this use case and its scenarios, I've added to HTML5 a simple
>>> syntax (three new attributes) based on RDFa.
>>
>> There's a quickly-hacked-together demo at
>> http://philip.html5.org/demos/microdata/demo.html (works in at least
>> Firefox and Opera), which attempts to show you the JSON serialisation
>> of the embedded data, which might help in examining the proposal.
> 
> I have a *totally unfinished* demo that does something rather similar
> at [1]. It is highly likely to break and/or give incorrect results**.
> If you use it for anything important you are insane :)

I have now added extremely preliminary RDF support with output as N3 and 
  RDF/XML courtesy of rdflib. It is certain to be buggy.

From shelleyp at burningbird.net  Thu May 14 05:18:43 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Thu, 14 May 2009 07:18:43 -0500
Subject: [whatwg] Annotating structured data that HTML has no	semantics
 for
In-Reply-To: <4A0BDA3C.3020709@opera.com>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
	<4A0BDA3C.3020709@opera.com>
Message-ID: <4A0C0C23.3030402@burningbird.net>

James Graham wrote:
> jgraham at opera.com wrote:
>> Quoting Philip Taylor <excors+whatwg at gmail.com>:
>>
>>> On Sun, May 10, 2009 at 11:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>>
>>>> One of the more elaborate use cases I collected from the e-mails 
>>>> sent in
>>>> over the past few months was the following:
>>>>
>>>>   USE CASE: Annotate structured data that HTML has no semantics 
>>>> for, and
>>>>   which nobody has annotated before, and may never again, for 
>>>> private use or
>>>>   use in a small self-contained community.
>>>>
>>>> [...]
>>>>
>>>> To address this use case and its scenarios, I've added to HTML5 a 
>>>> simple
>>>> syntax (three new attributes) based on RDFa.
>>>
>>> There's a quickly-hacked-together demo at
>>> http://philip.html5.org/demos/microdata/demo.html (works in at least
>>> Firefox and Opera), which attempts to show you the JSON serialisation
>>> of the embedded data, which might help in examining the proposal.
>>
>> I have a *totally unfinished* demo that does something rather similar
>> at [1]. It is highly likely to break and/or give incorrect results**.
>> If you use it for anything important you are insane :)
>
> I have now added extremely preliminary RDF support with output as N3 
> and  RDF/XML courtesy of rdflib. It is certain to be buggy.
>
So much concern about generating RDF, makes one wonder why we didn't 
just implement RDFa...

Shelley

From danbri at danbri.org  Thu May 14 05:25:42 2009
From: danbri at danbri.org (Dan Brickley)
Date: Thu, 14 May 2009 14:25:42 +0200
Subject: [whatwg] Annotating structured data that HTML has no	semantics
 for
In-Reply-To: <4A0C0C23.3030402@burningbird.net>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>	<4A0BDA3C.3020709@opera.com>
	<4A0C0C23.3030402@burningbird.net>
Message-ID: <4A0C0DC6.5080900@danbri.org>

On 14/5/09 14:18, Shelley Powers wrote:
> James Graham wrote:
>> jgraham at opera.com wrote:
>>> Quoting Philip Taylor <excors+whatwg at gmail.com>:
>>>
>>>> On Sun, May 10, 2009 at 11:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>>>
>>>>> One of the more elaborate use cases I collected from the e-mails
>>>>> sent in
>>>>> over the past few months was the following:
>>>>>
>>>>> USE CASE: Annotate structured data that HTML has no semantics for, and
>>>>> which nobody has annotated before, and may never again, for private
>>>>> use or
>>>>> use in a small self-contained community.
>>>>>
>>>>> [...]
>>>>>
>>>>> To address this use case and its scenarios, I've added to HTML5 a
>>>>> simple
>>>>> syntax (three new attributes) based on RDFa.
>>>>
>>>> There's a quickly-hacked-together demo at
>>>> http://philip.html5.org/demos/microdata/demo.html (works in at least
>>>> Firefox and Opera), which attempts to show you the JSON serialisation
>>>> of the embedded data, which might help in examining the proposal.
>>>
>>> I have a *totally unfinished* demo that does something rather similar
>>> at [1]. It is highly likely to break and/or give incorrect results**.
>>> If you use it for anything important you are insane :)
>>
>> I have now added extremely preliminary RDF support with output as N3
>> and RDF/XML courtesy of rdflib. It is certain to be buggy.
>>
> So much concern about generating RDF, makes one wonder why we didn't
> just implement RDFa...

Having HTML5-microdata -to- RDF parsers is pretty critical to having 
test cases that help us all understand where RDFa-Classic and HTML5 
diverge. I'm very happy to see this work being done and that there are 
multiple implementations.

As far as I can see, the main point of divergence is around URI 
abbreviation mechanisms. But also HTML5 might not have a notion 
equivalent to RDF/RDFa's bNodes construct. The sooner we have these 
parsers the sooner we'll know for sure.

Dan


From shelleyp at burningbird.net  Thu May 14 05:34:43 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Thu, 14 May 2009 07:34:43 -0500
Subject: [whatwg] Annotating structured data that HTML has no	semantics
 for
In-Reply-To: <4A0C0DC6.5080900@danbri.org>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>	<4A0BDA3C.3020709@opera.com>
	<4A0C0C23.3030402@burningbird.net> <4A0C0DC6.5080900@danbri.org>
Message-ID: <4A0C0FE3.1070305@burningbird.net>

Dan Brickley wrote:
> On 14/5/09 14:18, Shelley Powers wrote:
>> James Graham wrote:
>>> jgraham at opera.com wrote:
>>>> Quoting Philip Taylor <excors+whatwg at gmail.com>:
>>>>
>>>>> On Sun, May 10, 2009 at 11:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>>>>
>>>>>> One of the more elaborate use cases I collected from the e-mails
>>>>>> sent in
>>>>>> over the past few months was the following:
>>>>>>
>>>>>> USE CASE: Annotate structured data that HTML has no semantics 
>>>>>> for, and
>>>>>> which nobody has annotated before, and may never again, for private
>>>>>> use or
>>>>>> use in a small self-contained community.
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>> To address this use case and its scenarios, I've added to HTML5 a
>>>>>> simple
>>>>>> syntax (three new attributes) based on RDFa.
>>>>>
>>>>> There's a quickly-hacked-together demo at
>>>>> http://philip.html5.org/demos/microdata/demo.html (works in at least
>>>>> Firefox and Opera), which attempts to show you the JSON serialisation
>>>>> of the embedded data, which might help in examining the proposal.
>>>>
>>>> I have a *totally unfinished* demo that does something rather similar
>>>> at [1]. It is highly likely to break and/or give incorrect results**.
>>>> If you use it for anything important you are insane :)
>>>
>>> I have now added extremely preliminary RDF support with output as N3
>>> and RDF/XML courtesy of rdflib. It is certain to be buggy.
>>>
>> So much concern about generating RDF, makes one wonder why we didn't
>> just implement RDFa...
>
> Having HTML5-microdata -to- RDF parsers is pretty critical to having 
> test cases that help us all understand where RDFa-Classic and HTML5 
> diverge. I'm very happy to see this work being done and that there are 
> multiple implementations.
>
> As far as I can see, the main point of divergence is around URI 
> abbreviation mechanisms. But also HTML5 might not have a notion 
> equivalent to RDF/RDFa's bNodes construct. The sooner we have these 
> parsers the sooner we'll know for sure.
>
> Dan
>
>
Actually, I believe there are other differences, as others have pointed 
out.

http://www.jenitennison.com/blog/node/103

http://realtech.burningbird.net/semantic-web/semantic-web-issues-and-practices/holding-on-html5

Some of the differences have resulted in more modifications to the 
underlying HTML5 spec, which is curious, because Ian has stated in 
comments that support for RDF is only a side interest and not the main 
purpose behind the microdata section.

With the statement that support for RDF isn't a particular goal of 
microdata, Dan, I think you're being optimistic about the good this 
effort will generate for RDFa. But, more power to you.

Shelley

From excors+whatwg at gmail.com  Thu May 14 06:54:21 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Thu, 14 May 2009 14:54:21 +0100
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <4A0C0DC6.5080900@danbri.org>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
	<4A0BDA3C.3020709@opera.com> <4A0C0C23.3030402@burningbird.net>
	<4A0C0DC6.5080900@danbri.org>
Message-ID: <ea09c0d10905140654g7c43ab5cp2a2eb7259d9d8251@mail.gmail.com>

On Thu, May 14, 2009 at 1:25 PM, Dan Brickley <danbri at danbri.org> wrote:
> Having HTML5-microdata -to- RDF parsers is pretty critical to having test
> cases that help us all understand where RDFa-Classic and HTML5 diverge. I'm
> very happy to see this work being done and that there are multiple
> implementations.
>
> As far as I can see, the main point of divergence is around URI abbreviation
> mechanisms. But also HTML5 might not have a notion equivalent to RDF/RDFa's
> bNodes construct. The sooner we have these parsers the sooner we'll know for
> sure.

If I understand RDF correctly, the idea is that everything can be
URIs, subjects and objects can instead be blank nodes, and objects can
instead be literals. If we restrict literals to strings (optionally
with languages), then I think all triples must follow one of these
eight patterns:

  <urn:subject> <urn:predicate> <urn:object> .
  <urn:subject> <urn:predicate> "object" .
  <urn:subject> <urn:predicate> "object"@lang .
  <urn:subject> <urn:predicate> _:X .
  _:X <urn:predicate> <urn:object> .
  _:X <urn:predicate> "object" .
  _:X <urn:predicate> "object"@lang .
  _:X <urn:predicate> _:Y .

These cases can be trivially mapped into HTML5 microdata as:

  <div item>
    <link itemprop="about" href="urn:subject">
    <link itemprop="urn:predicate" href="urn:object">
  </div>

  <div item>
    <link itemprop="about" href="urn:subject">
    <meta itemprop="urn:predicate" content="object">
  </div>

  <div item>
    <link itemprop="about" href="urn:subject">
    <meta itemprop="urn:predicate" content="object" lang="lang">
  </div>

  <div item>
    <link itemprop="about" href="urn:subject">
    <meta itemprop="urn:predicate" item id="X">
  </div>

  <link subject="X" itemprop="urn:predicate" href="urn:object">

  <meta subject="X" itemprop="urn:predicate" content="object">

  <meta subject="X" itemprop="urn:predicate" content="object" lang="lang">

  <meta subject="X" itemprop="urn:predicate" item id="Y">

(There's the caveat about <link> and <meta> being moved into <head> in
some browsers; you can replace them with <a> and <span> instead.)

These aren't the most elegant ways of expressing complex structures
(because they don't make much use of nesting), but hopefully they
demonstrate that it's possible to express any RDF graph (that only
uses string literals) by decomposing into triples and then writing as
HTML with these patterns.

(If all the triples using a blank node have the same subject, then you
don't need to use 'id' and 'subject' because you can just nest the
markup instead, I think.)

With my parser (in Firefox 3.0), the output triples (sorted into a
clearer order) are:

  <> <http://www.w3.org/1999/xhtml/vocab#item> <urn:subject> .
  <> <http://www.w3.org/1999/xhtml/vocab#item> <urn:subject> .
  <> <http://www.w3.org/1999/xhtml/vocab#item> <urn:subject> .
  <> <http://www.w3.org/1999/xhtml/vocab#item> <urn:subject> .
  <urn:subject> <urn:predicate> <urn:object> .
  <urn:subject> <urn:predicate> "object" .
  <urn:subject> <urn:predicate> "object"@lang .
  <urn:subject> <urn:predicate> _:n0 .
  _:n0 <urn:predicate> <urn:object> .
  _:n0 <urn:predicate> "object" .
  _:n0 <urn:predicate> "object"@lang .
  _:n0 <urn:predicate> _:n1 .

which corresponds to what was desired.

So, I can't see any limits on expressivity other than that literals
must be strings. (But I'm not at all an expert on RDF, and I may have
missed something in the microdata spec, so please let me know if I'm
wrong!)

-- 
Philip Taylor
excors at gmail.com

From herenvardo at gmail.com  Thu May 14 07:50:47 2009
From: herenvardo at gmail.com (Eduard Pascual)
Date: Thu, 14 May 2009 16:50:47 +0200
Subject: [whatwg] A Selector-based metadata proposal (was: Annotating
	structured data that HTML has no semantics for)
Message-ID: <6ea53250905140750s1095ba8bj57f5b54ec2be63f4@mail.gmail.com>

I have put online a document that describes my idea/proposal for a
selector-based solution to metadata.
The document can be found at http://herenvardo.googlepages.com/CRDF.pdf
Feel free to copy and/or link the file wherever you deem appropriate.

Needless to say, feedback and constructive criticism to the proposal
is always welcome.
(Note: if discussion about this proposal should take place somewhere
else, please let me know.)

Regards,
Eduard Pascual

From mjs at apple.com  Thu May 14 11:25:40 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 14 May 2009 11:25:40 -0700
Subject: [whatwg] Annotating structured data that HTML has no	semantics
	for
In-Reply-To: <4A0C0C23.3030402@burningbird.net>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
	<4A0BDA3C.3020709@opera.com> <4A0C0C23.3030402@burningbird.net>
Message-ID: <26409829-F1B0-49CE-A0F8-672B1E2B6748@apple.com>


On May 14, 2009, at 5:18 AM, Shelley Powers wrote:

> So much concern about generating RDF, makes one wonder why we didn't  
> just implement RDFa...

If it's possible to produce RDF triples from microdata, and if RDF  
triples of interest can be expressed with microdata, why does it  
matter if the concrete syntax is the same as RDFa? Isn't the important  
thing about RDF the data model, not the surface syntax?

(I understand that if the microdata syntax offered no advantages over  
RDFa, then it would be a wasted effort to diverge. But my impression  
is that you'd object to anything that isn't exactly identical to RDFa,  
even if it can easily be used in the same way.)

Regards,
Maciej


From jonas at sicking.cc  Thu May 14 11:53:37 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 14 May 2009 11:53:37 -0700
Subject: [whatwg] <video>/<audio> feedback
In-Reply-To: <p0624084bc62ffca8921a@17.202.35.52>
References: <c2e346f90904051552s569d8b4ak210e436da110857b@mail.gmail.com> 
	<2c0e02830905071545p5d8cdb15r16073474f570dad5@mail.gmail.com> 
	<p06240804c62921c89a85@17.202.35.52>
	<2c0e02830905080646i60ebe49eg7499b50fcd9399f@mail.gmail.com> 
	<p06240805c62a0c11e4a7@10.0.1.6>
	<2c0e02830905082109t64fa89aaj5dd50933c3d9283@mail.gmail.com> 
	<p0624081ac62d3543eff2@17.202.35.52>
	<63df84f0905121201o5da6fae9u12a2396ce70cfef9@mail.gmail.com> 
	<2c0e02830905121909m53fe1593j46d1932644720ae4@mail.gmail.com> 
	<p0624084bc62ffca8921a@17.202.35.52>
Message-ID: <63df84f0905141153r1d1942cauc555fa19562acc4@mail.gmail.com>

On Tue, May 12, 2009 at 9:29 PM, David Singer <singer at apple.com> wrote:
> At 12:09 ?+1000 13/05/09, Silvia Pfeiffer wrote:
>>
>> On Wed, May 13, 2009 at 5:01 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>
>>> ?On Sun, May 10, 2009 at 6:56 PM, David Singer <singer at apple.com> wrote:
>>>>
>>>> ?At 14:09 ?+1000 9/05/09, Silvia Pfeiffer wrote:
>>>>>
>>>>> ?Of course none of the
>>>>> ?discussion will inherently disallow seeking - scripts will always be
>>>>> ?able to do the seeking. But the user may not find it easy to do
>>>>> ?seeking to a section that is not accessible through the displayed
>>>>> ?timeline, which can be both a good and a bad thing.
>>>>
>>>> ?How easy a particular user interface is to use for various tasks is (I
>>>> hope)
>>>> ?not our worry...
>>>
>>> ?I'm not sure I agree. If the spec provides a feature set that no one
>>> ?is able to create a useful UI for, then there definitely might be a
>>> ?problem with the spec.
>>>
>>> ?I still have not received any comments on my previous assertion that
>>> ?there are essentially two separate use cases here. One for bringing
>>> ?attention to a specific point in a larger context, one for showing
>>> ?only a smaller range of a video.
>>
>> Just to confirm: yes, there are two separate use cases. (I was under
>> the impression that the discussion had brought that out).
>
> Yes, that's fine. ?I think it's clear that we could have a 'verb' in the
> fragment "focus-on", "select" etc. to indicate that. ?I think it's also
> clear that no matter what verb is used, the entire resource is 'available'
> to the UA, that scripts can (if they wish) navigate anywhere in the entire
> resource, and that UAs can optimize the interface for the given verb, but
> the interface can still permit access to the entire resource.

Personally I'm pretty un-opinionated on these details.

If setting a range in the fragment results in the .currentTime
spanning from 0 to length-of-range or from start-of-range to
end-or-range seems only like a question of which API is the most
author friendly. Script can always remove the range-fragment if it
wants to use a .currentTime outside of the range.

The only argument that I can think of either way is that it might be
hard to create a decent UI for the situation when a range is
specified, but .currentTime is set to outside that range using script.

But again, I don't have much of an opinion.

/ Jonas

From shelleyp at burningbird.net  Thu May 14 13:04:39 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Thu, 14 May 2009 15:04:39 -0500
Subject: [whatwg] Annotating structured data that HTML has no	semantics
 for
In-Reply-To: <26409829-F1B0-49CE-A0F8-672B1E2B6748@apple.com>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
	<4A0BDA3C.3020709@opera.com> <4A0C0C23.3030402@burningbird.net>
	<26409829-F1B0-49CE-A0F8-672B1E2B6748@apple.com>
Message-ID: <4A0C7957.50207@burningbird.net>

Maciej Stachowiak wrote:
>
> On May 14, 2009, at 5:18 AM, Shelley Powers wrote:
>
>> So much concern about generating RDF, makes one wonder why we didn't 
>> just implement RDFa...
>
> If it's possible to produce RDF triples from microdata, and if RDF 
> triples of interest can be expressed with microdata, why does it 
> matter if the concrete syntax is the same as RDFa? Isn't the important 
> thing about RDF the data model, not the surface syntax?
>
> (I understand that if the microdata syntax offered no advantages over 
> RDFa, then it would be a wasted effort to diverge. But my impression 
> is that you'd object to anything that isn't exactly identical to RDFa, 
> even if it can easily be used in the same way.)
>
> Regards,
> Maciej
>
>
Because one would assume that one way to accomplish a task would be more 
attractive to web developers, designers, parser developers, browsers, et 
al.

In addition, one would also assume that one way to accomplish a task 
would be more attractive in regards to testing, maintaining and moving 
on in the future.

Notice how there is only VHS and not Betamax?

Notice the same about Blu-Ray and HD-TV? People won't buy into something 
while there are competitive specs, and these are "competitive" in that 
it makes little since to use both in a document, though you can now.

The point is, people in the real world have to use this stuff. It helps 
them if they have one, generally agreed on approach. As it is, folks 
have to contend with both RDFa and microformats, but at least we know 
these have different purposes.

Shelley

From mjs at apple.com  Thu May 14 13:17:32 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 14 May 2009 13:17:32 -0700
Subject: [whatwg] Annotating structured data that HTML has no	semantics
	for
In-Reply-To: <4A0C7957.50207@burningbird.net>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
	<4A0BDA3C.3020709@opera.com> <4A0C0C23.3030402@burningbird.net>
	<26409829-F1B0-49CE-A0F8-672B1E2B6748@apple.com>
	<4A0C7957.50207@burningbird.net>
Message-ID: <ACDC6AA2-FCC8-4E53-8481-8CD98A31608E@apple.com>


On May 14, 2009, at 1:04 PM, Shelley Powers wrote:

> Maciej Stachowiak wrote:
>>
>> On May 14, 2009, at 5:18 AM, Shelley Powers wrote:
>>
>>> So much concern about generating RDF, makes one wonder why we  
>>> didn't just implement RDFa...
>>
>> If it's possible to produce RDF triples from microdata, and if RDF  
>> triples of interest can be expressed with microdata, why does it  
>> matter if the concrete syntax is the same as RDFa? Isn't the  
>> important thing about RDF the data model, not the surface syntax?
>>
>> (I understand that if the microdata syntax offered no advantages  
>> over RDFa, then it would be a wasted effort to diverge. But my  
>> impression is that you'd object to anything that isn't exactly  
>> identical to RDFa, even if it can easily be used in the same way.)
>>
>> Regards,
>> Maciej
>>
>>
> Because one would assume that one way to accomplish a task would be  
> more attractive to web developers, designers, parser developers,  
> browsers, et al.
>
> In addition, one would also assume that one way to accomplish a task  
> would be more attractive in regards to testing, maintaining and  
> moving on in the future.
>
> Notice how there is only VHS and not Betamax?
>
> Notice the same about Blu-Ray and HD-TV? People won't buy into  
> something while there are competitive specs, and these are  
> "competitive" in that it makes little since to use both in a  
> document, though you can now.

Physical media do tend to converge due to network effects. I think the  
effect is less strong for digital file formats. For example, MP3 and  
AAC are both fairly successful; similarly, MPEG-4, Windows Media and  
Ogg are all getting some degree of traction. But you may be right that  
ultimately there will be only one winner.

> The point is, people in the real world have to use this stuff. It  
> helps them if they have one, generally agreed on approach. As it is,  
> folks have to contend with both RDFa and microformats, but at least  
> we know these have different purposes.

 From my cursory study, I think microdata could subsume many of the  
use cases of both microformats and RDFa. It seems to me that it avoids  
much of what microformats advocates find objectionable, and provides a  
good basis for new microformats; but at the same time it seems it can  
represent a full RDF data model. Thus, I think we have the potential  
to get one solution that works for everyone.

I'm not 100% sure microdata can really achieve this, but I think  
making the attempt is a positive step.

One other detail that it seems not many people have picked up on yet  
is that microdata proposes a DOM API to extract microdata-based info  
from a live document on the client side. In my opinion this is huge  
and has the potential to greatly increase author interest in semantic  
markup.

Now, it may be that microdata will ultimately fail, either because it  
is outcompeted by RDFa, or because not enough people care about  
semantic markup, or whatever. But at least for now, I don't see a  
reason to strangle it in the cradle.

Regards,
Maciej


From shelleyp at burningbird.net  Thu May 14 13:30:41 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Thu, 14 May 2009 15:30:41 -0500
Subject: [whatwg] Annotating structured data that HTML has no	semantics
 for
In-Reply-To: <ACDC6AA2-FCC8-4E53-8481-8CD98A31608E@apple.com>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com>
	<4A0BDA3C.3020709@opera.com> <4A0C0C23.3030402@burningbird.net>
	<26409829-F1B0-49CE-A0F8-672B1E2B6748@apple.com>
	<4A0C7957.50207@burningbird.net>
	<ACDC6AA2-FCC8-4E53-8481-8CD98A31608E@apple.com>
Message-ID: <4A0C7F71.9040607@burningbird.net>

Maciej Stachowiak wrote:
>
> On May 14, 2009, at 1:04 PM, Shelley Powers wrote:
>
>> Maciej Stachowiak wrote:
>>>
>>> On May 14, 2009, at 5:18 AM, Shelley Powers wrote:
>>>
>>>> So much concern about generating RDF, makes one wonder why we 
>>>> didn't just implement RDFa...
>>>
>>> If it's possible to produce RDF triples from microdata, and if RDF 
>>> triples of interest can be expressed with microdata, why does it 
>>> matter if the concrete syntax is the same as RDFa? Isn't the 
>>> important thing about RDF the data model, not the surface syntax?
>>>
>>> (I understand that if the microdata syntax offered no advantages 
>>> over RDFa, then it would be a wasted effort to diverge. But my 
>>> impression is that you'd object to anything that isn't exactly 
>>> identical to RDFa, even if it can easily be used in the same way.)
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>> Because one would assume that one way to accomplish a task would be 
>> more attractive to web developers, designers, parser developers, 
>> browsers, et al.
>>
>> In addition, one would also assume that one way to accomplish a task 
>> would be more attractive in regards to testing, maintaining and 
>> moving on in the future.
>>
>> Notice how there is only VHS and not Betamax?
>>
>> Notice the same about Blu-Ray and HD-TV? People won't buy into 
>> something while there are competitive specs, and these are 
>> "competitive" in that it makes little since to use both in a 
>> document, though you can now.
>
> Physical media do tend to converge due to network effects. I think the 
> effect is less strong for digital file formats. For example, MP3 and 
> AAC are both fairly successful; similarly, MPEG-4, Windows Media and 
> Ogg are all getting some degree of traction. But you may be right that 
> ultimately there will be only one winner.

Now, that's the problem with all of this effort...winners and losers.

I don't support a spec because it gives me grins and giggles. I have 
certain tasks I want to do, and I look for what is the technology that 
has the most support in order to do them.

I've long been an adherent to RDF, which isn't really up for debate. 
Originally, I was an RDF/XML person, until the RDF-in-XHTML folks 
changed my mind.

What I see of RDFa is a specification that has been through a very long 
period of time, testing, commenting, being implemented by major players. 
I also have tools, right now, that I can use to process the RDFa, as 
well as support by two major search engine companies.

As Dan pointed out earlier, microdata seems to support most of RDF. 
Well, I know that RDFa does. It makes little sense to me to start from 
scratch when a mature specification with multi-vendor support already 
exists.

Especially when Drupal 7 rolls out with RDFa baked in. That's 1.7 
million sites supporting the spec. Then there's the new Google snippet 
thing -- who knows how many additional sites we'll now find supporting RDFa.

So, if I'm pushing for RDFa, it's not because I want to "win". It's 
because I have things I want to do now, and I would like to make sure 
have a reasonable chance of working a couple of years in the future. And 
yeah, once SVG is in HTML5, and RDFa can work with HTML5, maybe I 
wouldn't mind giving old HTML a try again. Lord knows I'd like to user 
ampersands again.

>
>> The point is, people in the real world have to use this stuff. It 
>> helps them if they have one, generally agreed on approach. As it is, 
>> folks have to contend with both RDFa and microformats, but at least 
>> we know these have different purposes.
>
> From my cursory study, I think microdata could subsume many of the use 
> cases of both microformats and RDFa. It seems to me that it avoids 
> much of what microformats advocates find objectionable, and provides a 
> good basis for new microformats; but at the same time it seems it can 
> represent a full RDF data model. Thus, I think we have the potential 
> to get one solution that works for everyone.
>
> I'm not 100% sure microdata can really achieve this, but I think 
> making the attempt is a positive step.
>
It can't, don't you see?

Microdata will only work in HTML5/XHTML5. XHTML 1.1 and yes, 2.0 will be 
around for years, decades. In addition, XHTML5 already supports RDFa.

Why you think something completely brand new, no vendor support, drummed 
up in a few hours or a day or so is more robust, and a better option 
than a mature spec in wide use, well frankly boggles my mind.

I am impressed with your belief in HTML5.

But
> One other detail that it seems not many people have picked up on yet 
> is that microdata proposes a DOM API to extract microdata-based info 
> from a live document on the client side. In my opinion this is huge 
> and has the potential to greatly increase author interest in semantic 
> markup.
>

Not really. Can do this now with RDFa in XHTML. And I don't need any new 
DOM to do it.

The power of semantic markup isn't really seen until you take that 
markup data _outside_ the document. And merge that data with data from 
other documents. Google rich snippets. Yahoo searchmonkey. Heck, even an 
application that manages the data from different subsites of one domain.

> Now, it may be that microdata will ultimately fail, either because it 
> is outcompeted by RDFa, or because not enough people care about 
> semantic markup, or whatever. But at least for now, I don't see a 
> reason to strangle it in the cradle.
>

Outcompeted...wow, what a way to think of it. Sorry, but competition has 
no place in spec work.

Shelley

>
>


From herenvardo at gmail.com  Thu May 14 13:52:57 2009
From: herenvardo at gmail.com (Eduard Pascual)
Date: Thu, 14 May 2009 22:52:57 +0200
Subject: [whatwg] Annotating structured data that HTML has no semantics
	for
In-Reply-To: <26409829-F1B0-49CE-A0F8-672B1E2B6748@apple.com>
References: <20090510213731.yezvxe5s040s40wg@staff.opera.com> 
	<4A0BDA3C.3020709@opera.com> <4A0C0C23.3030402@burningbird.net> 
	<26409829-F1B0-49CE-A0F8-672B1E2B6748@apple.com>
Message-ID: <6ea53250905141352l2763f1cj78ef14b0de726fff@mail.gmail.com>

On Thu, May 14, 2009 at 3:54 PM, Philip Taylor <excors+whatwg at gmail.com> wrote:
> [...]
> If we restrict literals to strings [...]
But *why* restrict literals to strings?? Being unable to state that
"2009-05-14" is a date makes that value completely useless: it would
only be useful on contexts where a date is expected (bascially,
because it is a date), but it can't be used on such contexts because
the tool retrieving the value has no hint about it being a date. Same
is true for integers, prices (a.k.a. decimals plus a currency symbol),
geographic coordinates, iguana descriptions, and so on.

On Thu, May 14, 2009 at 8:25 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On May 14, 2009, at 5:18 AM, Shelley Powers wrote:
>
>> So much concern about generating RDF, makes one wonder why we didn't just
>> implement RDFa...
>
> If it's possible to produce RDF triples from microdata, and if RDF triples
> of interest can be expressed with microdata, why does it matter if the
> concrete syntax is the same as RDFa? Isn't the important thing about RDF the
> data model, not the surface syntax?
It doesn't matter one syntax or another. But if a syntax already
exists (RDFa), building a new syntax should be properly justified. As
of now, the only supposed benefit I have heard of for this syntax is
that it avoids CURIEs... yet it replaces them with reversed domains??
Is that a benefit? I have been a Java programmer for some years, and
still find that convention absurd, horrible, and annoying. I'll agree
that CURIEs are ugly, and maybe hard to understand, but reversed
domains are equally ugly and hard to understand.

> (I understand that if the microdata syntax offered no advantages over RDFa,
> then it would be a wasted effort to diverge.
Which are the advantages it offers? I asked about them yesterday, and
no one has answered, so I'm asking again: please, enlighten me on this
because if I see no advantages myself and nobody else tells me about
any advantage, then the only conclusion a rational mind can take is
that there are no advantages. So, that's the position I'm on. I can
easily change my mind if anyone points out some advantage that might
actually help me more than RDFa when trying to add semantics and
metadata to my pages.

> But my impression is that you'd
> object to anything that isn't exactly identical to RDFa, even if it can
> easily be used in the same way.)
Actually, I do object to RDFa itself. Since the very first moment I
saw discussions about it on these lists, I have been trying to
highlight its flaws and to suggest ideas for alternatives.
Now, would you really expect me not to object to what, at least from
my current PoV, is simply worse than RDFa? IMHO, RDFa is just
*passable*, and microdata is too *mediocre* to get a pass. I don't
know about any solution that would be perfect, but I really think that
this community is definitely capable of producing something that is,
at least, *good*.

Of course, these are just my opinions, but I have told also what they
are based in. I'm eager to change my mind of there is base for it.

Regards,
Eduard Pascual

From erik.arvidsson at gmail.com  Thu May 14 13:58:20 2009
From: erik.arvidsson at gmail.com (Erik Arvidsson)
Date: Thu, 14 May 2009 13:58:20 -0700
Subject: [whatwg] DOMTokenList is unordered but yet requires sorting
In-Reply-To: <390F704398754DA594B49023189CB25F@POCZTOWIEC>
References: <6eeb8bd10905130845o3f7e516dv50dedd35052f8979@mail.gmail.com> 
	<390F704398754DA594B49023189CB25F@POCZTOWIEC>
Message-ID: <6eeb8bd10905141358g2ffeb8f6j7490b1b2781eada8@mail.gmail.com>

On Thu, May 14, 2009 at 00:30, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> If a token list represented an ordered set, it could not be sorted to get an
> item because the host would have to preserve the original (document) order
> of tokens.

The question is why does the set need to be ordered at all as long as
it is stable between changes? It would make implementations more
efficient with little no no loss in functionality.

-- 
erik

From nils-dagsson-moskopp at dieweltistgarnichtso.net  Thu May 14 15:31:50 2009
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Fri, 15 May 2009 00:31:50 +0200
Subject: [whatwg] [Fwd: Re: Helping people seaching for content filtered by
 license]
Message-ID: <1242340310.4050.0.camel@desudesudesu>

sorry, forgot to cc the list

-------- Weitergeleitete Nachricht --------
> Von: Nils Dagsson Moskopp
> <nils-dagsson-moskopp at dieweltistgarnichtso.net>
> An: Ian Hickson <ian at hixie.ch>
> Betreff: Re: [whatwg] Helping people seaching for content filtered by
> license
> Datum: Mon, 11 May 2009 10:04:41 +0200
> 
> Am Freitag, den 08.05.2009, 19:57 +0000 schrieb Ian Hickson:
> >      * Tara runs a video sharing web site for people who want licensing
> >        information to be included with their videos. When Paul wants to blog
> >        about a video, he can paste a fragment of HTML provided by Tara
> >        directly into his blog. The video is then available inline in his
> >        blog, along with any licensing information about the video.
> > 
> > (Really? A video sharing site dedicated to people who want licensing 
> > information to be included with their videos? That's a pretty specific 
> > audience, wow.)
> > 
> > This can be done with HTML5 today. For example, here is the markup you 
> > could include to allow someone to embed a video on their site while 
> > including the copyright or license information:
> > 
> >    <figure>
> >     <video src="http://example.com/videodata/sJf-ulirNRk" controls>
> >      <a href="http://video.example.com/watch?v=sJf-ulirNRk">Watch</a>
> >     </video>
> >     <legend>
> >      Pillar post surgery, starting to heal.
> >      <small>&copy; copyright 2008 Pillar. All Rights Reserved.</small>
> >     </legend>
> >    </figure>
> 
> Seriously, I don't get it. Is there really so much entrenched (widely
> deployed, a mess, IE-s