date:20080821

On Wed, 20 Aug 2008, Garrett Smith wrote:

 http://www.whatwg.org/specs/web-apps/current-work/#onhashchange
 | onhashchange
 |
 |Must be invoked whenever a hashchange event
 | is targeted at or bubbles through the element.
 
 I see it fires on History Traversal:
 | If the specified entry has a URL that differs from the current entry's
 | only by its fragment identifier, and the two share the same Document
 | object, then fire a simple event with the name hashchange at the body
 | element
 
 Is 'hashchange' an event that fires every time window.location.hash 
 changes?

Yes.


 I'm not sure what that has to do with the body element.

Nothing especially, except that that is where the event is fired, so that 
you can do body onhashchange=


 This may be one of those new ideas that may not ever see widespread 
 implementation.

It's already implemented in IE8.


 I'm interested in discussing the other issue that is more relevant to 
 existing standards and implementations (Misconceptions Documented).

I will reply to all feedback in due course; the IDL-related issues are 
currently awaiting WebIDL updates that that the HTML5 spec can be updated. 
You can see what e-mails are still pending replies here:

   http://whatwg.org/issues/

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

Re: [whatwg] Workers proposal

On Wed, 20 Aug 2008, Jonas Sicking wrote:
 
 Do we really need the SharedWorker interface. I.e. couldn't we just 
 return a MessagePort?

We could. It would mean either putting onerror on all message ports, or 
not reporting error information for shared workers. Actually even if we 
did put onerror on ports, it would be difficult to define which ports 
actually get the error events.

It would also mean not using a constructor, but that's fine.

Finally, it would make extending the interface later much harder if we 
found that it was useful to allow different users of the shared worker to 
control something.

Anyone else have any opinions on this?


 This would probably require that we use a factory function rather than a 
 constructor, like getPortForSharedWorker or some such. In other words, 
 do we really need onclose and onerror for shared workers (onerror seems 
 to make some sense, onclose i'm less sure about).

I don't mind dropping them.


 I think startConversation makes as much sense on shared workers as 
 dedicated ones, so moving that API up to Worker/WorkerGlobalScope seems 
 like a good idea.

startConversation is on the port(s) in the shared worker case. I'm not 
sure what it would mean on the worker or global scope in the shared case, 
since there's no target without the port in that case.


 If we keep the constructors (see first paragraph), I would prefer the 
 syntax new Worker over new DedicatedWorker.

That's fine, I can change the base to be AbstractWorker and then have 
Worker and SharedWorker as the interfaces inheriting from it.


I'll wait for slightly more input and then update the spec.

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

Re: [whatwg] Creative Commons Rights Expression Language

2008-08-21 Thread Dan Brickley


+cc: Ben Adida

Tab Atkins Jr. wrote:
On Wed, Aug 20, 2008 at 5:22 PM, Bonner, Matt [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Hola,

I see that the Creative Commons has proposed additions to HTML
to support licenses (ccREL):
http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/

As an example, they offer:

div about=http://lessig.org/blog/;
xmlns:cc=http://creativecommons.org/ns#;
   This page, by
   a property=cc:attributionName rel=cc:attributionURL
 href=http://lessig.org/;
  Lawrence Lessig
   /a,
   is licensed under a
   a rel=license href=http://creativecommons.org/licenses/by/3.0/;
 Creative Commons Attribution License
   /a.
/div

Unless I missed something in the HTML5 spec, at the least this would add
the property attribute to a.  Wouldn't ccREL be expressed better
using link instead of a?

Matt
--
Matt Bonner
Hewlett-Packard Company


The whole thing would be best expressed as a microformat, as the entire 
thing can be made just as machine- and human-readable without having to 
introduce an entire new addition to html.  I think someone is a little 
confused about the important of CC...


(Note: the someone is not you, Matt, but the drafters of this proposal.  
Also, I love CC as much as the next guy, but there's absolutely no 
reason to extend html to accomodate it, as everything they want to 
express can be done in existing html and formatted as a microformat.)


I encourage you to (re)-read 
http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/ ... the spec 
explains that all of CC's concrete markup requirements are addressed by 
the HTML additions in the RDFa spec. It does not propose *any* new HTML 
markup to address CC's specific needs. Instead, they're telling the 
world that CC's needs (including their own requirement for independent 
extensions) are well-handled by RDFa.


RDFa adds a set of attributes; 
http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080403/#rdfa-attributes 
has a full list. The ccREL spec shows these in an XHTML+RDFa XHTML 
format. There's a strong case to add them to HTML5 too, in my view.


In other words, adding 'about', 'property', 'resource', 'datatype' and 
'typeof' and a namespace-URI association convention to HTML5 wouldn't 
merely be addressing the important needs of the Creative Commons 
community. It would allow the expression of properties defined by any 
decentralised community, without the need for central coordination. This 
includes not just CC, but every group worldwide who are extending and 
customising CC for their own needs. Not just FOAF, but groups extending 
it for modelling forum posts and social media (eg. SIOC), or opensource 
projects (DOAP). Not just Dublin Core, but the huge range of projects 
that extend it to handle educational metadata (which itself varies 
nationally), rights, aggregation, classification etc. The addition of 
the RDFa attributes would allow HTML5 to carry structured data expressed 
in all/any of these vocabularies.


The Microformats.org community have done wonderful work and have 
inspired many others, but it is unfair on them (and unrealistic) to 
pressure their community, mailing lists and wiki by expecting their 
process to be a central bottleneck for all markup extensions to HTML. 
The Web serves a massive and fast growing community, many of whom don't 
speak English and are whose markup needs aren't core business for 
Microformats.org. By using RDFa and associating each vocabulary with a 
URI, we can spread the workload a bit more evenly.


Note also that every new vocabulary initiative at Microformats.org 
creates real and non-trivial work for parser writers, as well as work 
for vocabulary authors in specifying what it means to mix each pair of 
vocabularies. For ccREL (and FOAF, Dublin Core, SIOC, DOAP, ...), this 
is largely handled by RDF/RDFa: it can be freely mixed with any other 
RDF vocabulary, and reliably parsed by generic parser code. The tradeoff 
here is that the markup is less hand optimised for beauty than with 
microformats. (When extra-pretty custom markup is important, RDF 
provides GRDDL as a way of using XSLT to specify a mapping into its 
common data model.)


For more on RDFa, see the primer, http://www.w3.org/2006/07/SWD/RDFa/primer/

For a microformat parser that also handles RDFa, see 
http://buzzword.org.uk/cognition/   ... or an RDF toolkit that also 
parses some popular microformats, see http://arc.semsol.org/


For RDFa parsing in Javascript, see 
http://www.w3.org/2006/07/SWD/RDFa/impl/js/


cheers,

Dan

ps. my slides from a recent talk on rdf and microformats are here, if 
anyone's interested. It's more about how enthusiasts from each effort 
can learn from each other, than about the technical detail: 
http://www.slideshare.net/danbri/one-big-happy-family/ via 
http://microformats.eventwax.com/vevent



--
http://danbri.org/

Re: [whatwg] Creative Commons Rights Expression Language

On Thu, 21 Aug 2008, Dan Brickley wrote:
 
 The Microformats.org community have done wonderful work and have 
 inspired many others, but it is unfair on them (and unrealistic) to 
 pressure their community, mailing lists and wiki by expecting their 
 process to be a central bottleneck for all markup extensions to HTML.

I don't think anyone is suggesting that all such ideas should go through 
the Microformats community. What is being suggested is that instead of 
adding more features to HTML, the people who want to annotate their HTML 
documents with metadata, like Creative Commons, merely use some of the 
many existing HTML extension mechanisms, like class=, rel=, etc.

Microformats.org has shown several things; one is that it is important to 
actually make sure the problem you are solving is one that needs solving, 
another is that it is possible to use the existing HTML extension 
mechanisms to mark up very rich semantic data.

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

Re: [whatwg] several messages about ol, ul, dl, and related subjects

On Tue, 26 Feb 2008, Tab Atkins Jr. wrote:
- LH (caption for list! A must-have)

Why not using the title attribute?

Actually with figure the lh element is now better handled using
figure and legend.

Using figure and legend:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('figure')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfigure%3E%0A%20%20%3Clegend%3EList%20title%3C%2Flegend%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A%3C%2Ffigure%3E
While this isn't horrible, it isn't supported properly, as noted before. FF
currently just ignores the fact that there's a legend tag at all and
treats the list title as a plain text node. IE7 treats the legend as an
unknown tag and the title as a plain text node, even if you try to apply the
createElement shim.

Using lh:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lh')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Clh%3EList%20title%3C%2Flh%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A
On the other hand, lh seems to be supported just fine in FF *and* IE7
(with the shim). This solution is usable *immediately*, which is a big
plus. Since we only want to allow a single header per list, though, I'd
prefer fully embracing the parallel with table and naming this element
lhead, thus implying it must come first and at most once.

It's true that legend has support problems, but these are fixable on the
long run (indeed the HTML parser requires that they be fixed, so either
this will eventually work, or we'll have to fix the parser and can revisit
this then). Adding a new element here is something I really want to avoid
because we already have half a dozen different ways to mark up titles,
captions, legends, labels, titles, and the like, and adding more just
seems silly.

At this point, though, why not just bend the definition of ul and ol and
allow hx tags directly? Both FF and IE7 form good DOM trees with this
markup.
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lhead')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0D%0A%20%20%3Cul%3E%0D%0A%20%20%20%20%3Ch1%3EList%20title%3C%2Fh1%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%3C%2Ful%3E%0D%0A
This solution doesn't seem to have a drawback, really. It's already
supported (*without* an IE shim), doesn't require the creation of a new
element, and is completely intuitive. Just specify (like thead) that it
must be at the start of the list, and can occur at most once.

This would address the problem for ol and ul, but wouldn't solve the
problem for all markup. The figure solution is more generic.

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

[whatwg] reversed lists

On Tue, 26 Feb 2008, Tab Atkins Jr. wrote:
 
 As noted by Jonas Sicking, reverse-ordered lists will require a browser 
 to read the entire list in before numbering, or else update on the fly 
 (not acceptable).  However, as Ian notes, this isn't a problem with 
 variable-width tables.  We accept that certain classes of tables can't 
 be displayed until the entire thing has been read and computed, and we 
 will just have to accept that with reverse-ordered lists as well.
 
 The exception would be if we adopted the rule, suggested by Simon 
 Pieters, that the start= attribute apply to the first *lexical* element 
 in the list, rather than the first *ordinal* element.  This would allow 
 browsers to render reversed lists immediately when it is present.  I 
 like this compromise.

This is basically what the spec does now, I think.


  ::stuff about step= attribute::
 
 I can't think of any use cases for a step= attribute currently, at least 
 none that wouldn't be served best by *arbitrary* number generation.  
 Frex, numbering a list with the successive squares or primes.  While 
 fancy, these are just cute tricks, and not actually generally useful as 
 far as I can tell.  The same would be true for the step= attribute.

Agreed; step= doesn't seem necessary yet.


On Wed, 23 Apr 2008, Christoph Päper wrote:
 Ian Hickson schrieb:
  On Fri, 25 Jan 2008, Christoph P�per wrote:
   
   I think it has been shown, that the meta attribute |reverse| would 
   not work in HTML, it would have to be a command attribute, i.e. it 
   doesn't describe the ordering of the following list items, but their 
   indended display. This would make it presentational and thereby not 
   suitable for HTML. It would belong into CSS, but that isn't very 
   good at reordering boxes.
  
  I don't really follow. What's wrong with how the spec works now?
 
 Without rereading or much rethinking the thread, the current spec is 
 right in that |reversed| describes the actual order of |li|s -- which 
 is, what markup should do --, but this doesn't degrade well and it's not 
 incremental, because you need to know the number of |ol|'s children 
 (which you could hardcode with |start|) in advance to number the first 
 item. Therefore someone proposed a command-like |reverse| (no 
 participle) attribute that would keep the numbers, but reorder the |li|s 
 with them, which is backwards-compatible, but works just as bad for 
 incremental rendering (though in a different way) and is not very 
 markupish and -- if at all -- should be done on the styling level.
 
   Logical markup order  Presentational markup order
 
   ol!--spec, compat--   ol!--messy--
 liFirst1. First liThird1. Third
 liSecond   2. SecondliSecond   2. Second
 liThird3. Third liFirst3. First
   /ol /ol
 
   ol reversed!--messy-- ol reversed!--spec--
 liFirst3. First liThird3. Third
 liSecond   2. SecondliSecond   2. Second
 liThird1. Third liFirst1. First
   /ol /ol
 
   ol reverse!--a proposal-- ol reverse!--messy--
 liFirst3. Third liThird3. First
 liSecond   2. SecondliSecond   2. Second
 liThird1. First liFirst1. Third
   /ol /ol

Reversing the rendered order seems like it would cause more trouble than 
reversing the numbers, so I think we should stick with what we have now.

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

Re: [whatwg] several messages about tables and related subjects

On Mon, 24 Mar 2008, Tab Atkins Jr. wrote:

   TH and TD
  * abbr (I think that's supported by screen readers, but need to verify)
 
 I don't really see that these attributes actually help anyone.
 
 I don't have a screen reader to verify, but afaik abbr= is used to provide a
 shortened form of the header when it is spoken aloud repeatedly.  Leaving it
 out won't *hurt* anything, but the annoyance of hearing a large bit of
 header repeated over and over again when the table is complex enough to
 *need* a regular reminder would be enough, I think, for abbr= to be
 considered to help people.
 
 I use abbr= to this effect in my own tables.

I understand the intent, but wouldn't it be better for the user agent to 
automatically abbreviate the table headers, for example by only saying the 
first few syllables of the first bit of unique text in the relevant 
headers once it has been said several times?

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

Re: [whatwg] several messages about tables and related subjects

On Thu, 21 Aug 2008, Pawe�~B Stradomski wrote:
 
 I guess it's to difficult to implement such guessing right.
 
 thead
 tr
   th abbr=EuropeAmount sold in Europe/th
   th abbr=AsiaAmount sold in Asia/th
   th abbr=North AmericaAmount sold in North America/th
 ..
 /tr
 /thead

This example would be fine, the UA could easily strip common leading text 
and just say Europe, Asia and North Am each time. (Stripping leading 
common text is a solved problem.)


 Another example (translated into English and simplified from real life 
 Polish text):
 
 h1Camp details/h1
 thead
 tr
   th/th
   th abbr=young scoutsCamp for young scouts (12-15 years old)/th
   th abbr=scouts leadersTraining camp for scout leaders (16-18 years 
 old)/th
 ..
 /tr

 [...]

In this example, the same algorithm would end up saying Camp for and 
Training as the two headers, but I think that's ok (if not necessarily 
ideal), since the user will know from having heard the full header several 
times that Camp for is short for the young people column and Training 
is short for the leaders column.


 Please don't remove this attribute, it doesn't hurt people who don't 
 care about using it, but might make it more difficult for disabled 
 people. Hearing same sentence over and over can kill usability.

It's wrong to think that attributes that no-one use (and research 
indicates that this attribute really isn't used at all) don't cause harm. 
Every part of the language that we have increases the cognotive load of 
the entire language. A language with one feature is simpler to learn than 
a language with one feature and six unused features.

I agree entirely that abbreviating long headers is something that should 
happen. But it should happen for _all_ tables, not just those written by 
conscientious authors.

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

Re: [whatwg] Creative Commons Rights Expression Language

2008-08-21 Thread Henri Sivonen


On Aug 21, 2008, at 10:49, Dan Brickley wrote:

I encourage you to (re)-read http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/ 
 ... the spec explains that all of CC's concrete markup requirements  
are addressed by the HTML additions in the RDFa spec.


The RDFa spec doesn't make any additions to HTML. It only specifies  
additions to XHTML, and those additions use a Namespace-dependent anti- 
pattern, so they aren't portable to HTML.


In other words, adding 'about', 'property', 'resource', 'datatype'  
and 'typeof' and a namespace-URI association convention to HTML5  
wouldn't merely be addressing the important needs of the Creative  
Commons community.


It seems to me that the Creative Commons community has more pressing  
needs that aren't related to RDF syntax. Specifically: Making people  
to refer to license URI at all, making them to identify which CC  
license they mean, making them understand what permissions they are  
giving irrevocably to others upon granting a license and making them  
understand what licenses used by others mean (NonCommercial, anyone?).  
Syntax doesn't solve any of these.


People don't know what they are doing when they flip those Flickr  
settings:

http://diveintomark.org/archives/2008/02/05/writing-with-ease#comment-11272

At least in a non-RDF context, pointing to the license by URI seems  
too hard. See

http://intertwingly.net/blog/2008/02/09/Mashups-Smashups#c1202660852

Also note that even CC leadership omits the license URI. I encourage  
you to examine the last frames of the videos at http:// 
lessig.blip.tv/. The latest video (http://lessig.blip.tv/file/ 
1185352/) works as an example. Whenever the last frame acknowledges  
the use of CC-licensed photos, it doesn't show the URI of the license.  
In fact, it doesn't even state in words or icons *which* CC license  
the photos were used under!


Getting back to the comment thread on intertwingly.net, a later  
comment contained this gem:

http://intertwingly.net/blog/2008/02/09/Mashups-Smashups#c1202810109
My sarcasm detector isn't quite working, so I can't tell if the  
comment was *meant* to mock RDF, but the follow-up comment is spot on:

http://intertwingly.net/blog/2008/02/09/Mashups-Smashups#c1202870522

It would allow the expression of properties defined by any  
decentralised community, without the need for central coordination.  
This includes not just CC, but every group worldwide who are  
extending and customising CC for their own needs. Not just FOAF, but  
groups extending it for modelling forum posts and social media (eg.  
SIOC), or opensource projects (DOAP). Not just Dublin Core,


Interesting that you mention Dublin Core. It's a great example of why  
it's bad to just rush embedding an RDF vocabulary into HTML without a  
semantic overlap unification process like the Microformats Process.  
Most of the original DC elements duplicate native metadata facilities  
of HTML and HTTP. There will always be more content using HTML title  
than DC title, so consumers will be better off being able to consume  
HTML title. There will always be more consuming apps for HTML  
title than DC title, so publishers will be better off using HTML  
titles.


but the huge range of projects that extend it to handle educational  
metadata (which itself varies nationally), rights, aggregation,  
classification etc. The addition of the RDFa attributes would allow  
HTML5 to carry structured data expressed in all/any of these  
vocabularies.


RDFa including namespace-URI mappings isn't the only possible way to  
accomplish RDF embedding into HTML5. RDFa uses CURIEs which take the  
qnames-in-content anti-pattern and keep digging the hole. I think we  
shouldn't introduce the complexity of Namespaces and qnames-in-content  
to HTML5.


Aside: The TAG has a finding saying that qnames-in-content are  
problematic:

http://www.w3.org/2001/tag/doc/qnameids.html

There's an obvious way how RDFa could have been adjusted to avoid the  
ills of Namespaces and qnames-in-content: using full URIs instead of  
CURIEs. N-Triples demonstrate that RDF triples can be serialized  
without a prefix binding layer.


Even if RDFa were adjusted to use full URIs, there'd still be the  
issue of objections to the additional attributes by people who not  
only think Namespaces are bad but think that embedding RDF in HTML at  
all is bad. I sent an outline of a possible way to route around this  
issue to the HTML WG and xml-dev, but my trial balloon got Warnocked:

http://lists.w3.org/Archives/Public/public-html/2008Aug/0231.html

Note: I'm not suggesting that it would be good for CC to promote  
something as complex as that. I wish CC weren't telling people to use  
RDF with any syntax (or with the NonCommercial license element, but  
that's off-topic here). However, something like the eRDF5 trial  
balloon could work for communities who, unlike CC, aren't trying to  
meet the general public and, therefore, can afford more

Re: [whatwg] Scripted querying of video capabilities

2008-08-21 Thread Tim Starling

timeless wrote:
 yes, i'd expect it to just work. however i'd also expect the apis not
 to work correctly. which means we'd probably be stuck with a case
 where we either lie and say ogg isn't supported (because we have no
 way to figure out if it's supported), which means it wouldn't work. or
 we'd lie and say it is supported (which means that if someone sniffs
 for ogg first, they'd send you ogg only and you would get nothing).

 people should just provide source tags for all formats they have in
 the order in which they'd like to send them. let the user agents
 figure it out.

   
We only have one format: Theora. We can play it with video, applet
or object. The challenge is to determine which is best.

 please don't encourage sniffing.

 footnote: if someone's annoying/evil and only provides one source,
 then yes, bad things will probably happen.

   

There is only one format that is feasible for web deployment and
patent-free, and that is Theora. Are you saying now that it's evil to
support patent-free codecs?

 Could i put in a plea for browsers to consider flagging this site
 isn't nice, it probably won't work if you visit it with another
 device, you should complain to the content provider. if possible,
 useragents should be encouraged to encourage their users to demand
 more availability of content in more formats :).
   

So not only do you want to derail my attempt to bring Theora content to
users, you want to turn those users into amateur MPEG-LA license salesmen?

-- Tim Starling

Re: [whatwg] Creative Commons Rights Expression Language

Can't you just embed your XML metadata in a SCRIPT element?
Chris

Re: [whatwg] several messages about tables and related subjects

The advantage of having an attribute referring to the current column of
every table element is that it is easier to check that the right data are
the right column.  Columns are filled sequentially but the exact position in
the sequence is accidental and meaningless in most cases.  I tend to put the
column keyword into the title attribute; this allows me to verify that the
keywords are in the right order.  This is verbose but it greatly improves
source code readability.  I think the abbr attribute could be used for this
purpose as well (repeated on every cell).
What do you think?
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Thursday, August 21, 2008 11:16 AM
To: Tab Atkins Jr.
Cc: whatwg List
Subject: Re: [whatwg] several messages about tables and related subjects

On Mon, 24 Mar 2008, Tab Atkins Jr. wrote:

   TH and TD
  * abbr (I think that's supported by screen readers, but need to verify)
 
 I don't really see that these attributes actually help anyone.
 
 I don't have a screen reader to verify, but afaik abbr= is used to provide
a
 shortened form of the header when it is spoken aloud repeatedly.  Leaving
it
 out won't *hurt* anything, but the annoyance of hearing a large bit of
 header repeated over and over again when the table is complex enough to
 *need* a regular reminder would be enough, I think, for abbr= to be
 considered to help people.
 
 I use abbr= to this effect in my own tables.

I understand the intent, but wouldn't it be better for the user agent to 
automatically abbreviate the table headers, for example by only saying the 
first few syllables of the first bit of unique text in the relevant 
headers once it has been said several times?

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

Re: [whatwg] Workers proposal


Ian Hickson wrote:

On Wed, 20 Aug 2008, Jonas Sicking wrote:
Do we really need the SharedWorker interface. I.e. couldn't we just 
return a MessagePort?


We could. It would mean either putting onerror on all message ports, or 
not reporting error information for shared workers. Actually even if we 
did put onerror on ports, it would be difficult to define which ports 
actually get the error events.


It would also mean not using a constructor, but that's fine.

Finally, it would make extending the interface later much harder if we 
found that it was useful to allow different users of the shared worker to 
control something.


Anyone else have any opinions on this?


Yeah, I don't feel strongly either way here. It feels cleaner to not 
have separate SharedWorker instances for each user of a shared worker, 
but there are also downsides with not doing that (like onerror and other 
future properties that we might want).


So I'm fine either way.

I think startConversation makes as much sense on shared workers as 
dedicated ones, so moving that API up to Worker/WorkerGlobalScope seems 
like a good idea.


startConversation is on the port(s) in the shared worker case. I'm not 
sure what it would mean on the worker or global scope in the shared case, 
since there's no target without the port in that case.


Ah, of course.

If we keep the constructors (see first paragraph), I would prefer the 
syntax new Worker over new DedicatedWorker.


That's fine, I can change the base to be AbstractWorker and then have 
Worker and SharedWorker as the interfaces inheriting from it.


Sounds good to me.

/ Jonas

Re: [whatwg] hashchange only dispatched in history traversal

2008-08-21 Thread Garrett Smith

On Wed, Aug 20, 2008 at 11:00 PM, Ian Hickson [EMAIL PROTECTED] wrote:
 On Wed, 20 Aug 2008, Garrett Smith wrote:

 http://www.whatwg.org/specs/web-apps/current-work/#onhashchange
 | onhashchange
 |
 |Must be invoked whenever a hashchange event
 | is targeted at or bubbles through the element.

 I see it fires on History Traversal:
 | If the specified entry has a URL that differs from the current entry's
 | only by its fragment identifier, and the two share the same Document
 | object, then fire a simple event with the name hashchange at the body
 | element

 Is 'hashchange' an event that fires every time window.location.hash
 changes?

 Yes.

I see that in MSDN now that hashchange applies to (window, BODY, FRAMESET).

HTML 5 expands hashchange to any element. Any element, such as div
or pre? How can you know if an element supports hashchange or not?
hashchange seems closely related to the Location interface, so it
would seem to make sense to have hashchange implemented for objects
that implement Location.

Has this been considered?

This would make it easier to know which elements support hashchange
events (body doesn't really support the event, it's just a pass-thru).

It would make the most sense to have hashchange *on* the Location, e.g.

location.addEventListener('hashchange', cb, false);

- but that would not be compatible with IE.



 I'm not sure what that has to do with the body element.

 Nothing especially, except that that is where the event is fired, so that
 you can do body onhashchange=


 fires at the body element  sounds as if the event is firing itself,
at the body. Instead, say the EventTarget fires the event. For
example: The window fires the hashchange event.

Body event handler attributes cascading to window is unclear and
creates ambiguity as to what the event is being attached to.

body onmousedown=alert(this)

alerts window in Firefox 3. The mousedown event fires anywhere, not
just on the body. This creates ambiguity. So it is a practice that
should be avoided in attempt to be cross browser. Has this problem
been considered?

1) add a note about bubbling. hashchange events bubble
2) replace the fires at the body element with the EventTarget fires
the event

Garrett

 --
 Ian Hickson   U+1047E)\._.,--,'``.fL

Re: [whatwg] Client-side includes proposal


I have to say that I don't really agree with Hixie here either.

I think there is much value in letting HTML be a viable format for 
document distribution outside the web. I definitely don't think of it as 
a non-goal. Things like distributable cross-platform DVDs of wikipedia 
containing just a stack of HTML pages would be an awesome way of 
delivering part of the web to people that are offline (be that on an 
airplane, the Alaskan wilderness or stuck in a warzone).


That said, there is always a cost/benefit analysis to any new feature. 
And I think the benefit for a feature specifically targetted for non-web 
HTML pages is smaller, which means that we should accept only smaller costs.


In the case of client side includes I'm unconvinced benefit is worth the 
cost. Additionally there already is a standard for it called XInclude, 
so I'm not really sure what the debate is.


If UAs want to support client side include they can implement XInclude. 
If they don't, why would we add it to HTML5?


/ Jonas

Re: [whatwg] Creative Commons Rights Expression Language

If I understand it correctly, we do not have a problem with the colon as a
namespace separator.  Our problem is that a:x sometimes means the same as
b:x and there is no reasonable way to make legacy browsers support this.
Different URLs, OTOH, are not expected to mean the same thing even if one is
an alias for another.
Chris

-Original Message-
From: Ben Adida [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 21, 2008 8:53 PM
To: Dan Brickley
Cc: Tab Atkins Jr.; Bonner, Matt; WHAT-WG; Ian Hickson; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [whatwg] Creative Commons Rights Expression Language


Namespaces are an anti-pattern, really? Says who? The web is inherently
namespaced. Everything you go to is scoped to a URL prefix. There isn't
one Paris or one New York, there is wikipedia/paris, and
nyc.gov/NewYork. So is it the : that bothers you? Is that really relevant?

Re: [whatwg] Creative Commons Rights Expression Language

I was trying to explain the rejection of namespaces in general because it is
a general decision.  It is not enough to make sure this particular use case
does not cause problems.
AFAIK, you can make a legacy browser that supports custom elements and
scripting to display a progress bar.  This probably means you partially
right: Lynx, NCSA Mosaic and MacWeb cannot render a progress bar element.
Chris

-Original Message-
From: Ben Adida [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 21, 2008 9:36 PM
To: Kristof Zelechovski
Cc: 'Dan Brickley'; 'Tab Atkins Jr.'; 'Bonner, Matt'; 'WHAT-WG'; 'Ian
Hickson'; [EMAIL PROTECTED]
Subject: Re: [whatwg] Creative Commons Rights Expression Language

Kristof Zelechovski wrote:
 If I understand it correctly, we do not have a problem with the colon as a
 namespace separator.  Our problem is that a:x sometimes means the same
as
 b:x and there is no reasonable way to make legacy browsers support this.

But... legacy browsers have no way to display a Progress Bar either, right?

RDFa does *not* affect how something is rendered. It just tells you what
portions of the page mean what exactly (this is a license, this is a
tag, etc...) So we're okay if legacy browsers don't understand it, they
can simply ignore it. In fact, even new browsers can ignore RDFa,
leaving the job to an extension. But of course, everyone is much better
off if RDFa can be validated in HTML/XHTML.

-Ben

Re: [whatwg] Creative Commons Rights Expression Language

2008-08-21 Thread Ben Adida

Kristof Zelechovski wrote:
 If I understand it correctly, we do not have a problem with the colon as a
 namespace separator.  Our problem is that a:x sometimes means the same as
 b:x and there is no reasonable way to make legacy browsers support this.

But... legacy browsers have no way to display a Progress Bar either, right?

RDFa does *not* affect how something is rendered. It just tells you what
portions of the page mean what exactly (this is a license, this is a
tag, etc...) So we're okay if legacy browsers don't understand it, they
can simply ignore it. In fact, even new browsers can ignore RDFa,
leaving the job to an extension. But of course, everyone is much better
off if RDFa can be validated in HTML/XHTML.

-Ben

Re: [whatwg] hashchange only dispatched in history traversal

On Thu, 21 Aug 2008, Garrett Smith wrote:
 
 HTML 5 expands hashchange to any element. Any element, such as div
 or pre? How can you know if an element supports hashchange or not?

I'm not sure what you mean. In HTML5, all event handler _attributes_ can 
be placed on any element, but that doesn't mean that the event will be 
fired by the UA at any element. The spec only fires the event at the body 
element.


 hashchange seems closely related to the Location interface, so it 
 would seem to make sense to have hashchange implemented for objects 
 that implement Location.
 
 Has this been considered?

Yes, but the benefit of being able to do body onhashchange= outweighs 
the logicalness of dispatching events to the Location object.


  I'm not sure what that has to do with the body element.
 
  Nothing especially, except that that is where the event is fired, so 
  that you can do body onhashchange=
 
  fires at the body element  sounds as if the event is firing itself, 
 at the body. Instead, say the EventTarget fires the event. For example: 
 The window fires the hashchange event.

I disagree with your interpretation of the terminology, but that's not 
just editorial so it's not a big deal.


 Body event handler attributes cascading to window is unclear and creates 
 ambiguity as to what the event is being attached to.
 
 body onmousedown=alert(this)
 
 alerts window in Firefox 3. The mousedown event fires anywhere, not 
 just on the body. This creates ambiguity. So it is a practice that 
 should be avoided in attempt to be cross browser. Has this problem been 
 considered?

Yeah, this is an open issue. I'm hoping that the DOM Events spec handles 
it.


 1) add a note about bubbling. hashchange events bubble

Per the spec, it doesnt.


 2) replace the fires at the body element with the EventTarget fires 
 the event

I disagree with this interpretation of the terminology.

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

Re: [whatwg] Creative Commons Rights Expression Language

2008-08-21 Thread Silvia Pfeiffer

Just a little side-track for the video issues around this thread:

On Fri, Aug 22, 2008 at 4:53 AM, Ben Adida [EMAIL PROTECTED] wrote:
 Also note that even CC leadership omits the license URI.

 So you want a URI in the video content itself? What good would that do?

With links directly in the video, copies of the videos will continue
to contain the license, so there is a reason for putting metadata such
as the license inside the video. In fact, RDF inside video would be a
big step forward to deal with the DRM issues around videos.

 With ccREL (and specifically RDFa), the surrounding HTML can easily say
 *this* video is licensed under *that* license.

This is a good solution in the current situation where there is no
standard video and video annotation format. If there was a standard
video annotation format, we could have the video's DOM accessible
directly in the browser and such questions as what is the video's
license could be answered easily directly. I think this may come out
of the new W3C proposed video activity
http://www.w3.org/QA/2008/04/proposed_activity_for_video_on.html.

Regards,
Silvia.

Re: [whatwg] Creative Commons Rights Expression Language

2008-08-21 Thread Ben Adida

Silvia Pfeiffer wrote:
 With links directly in the video, copies of the videos will continue
 to contain the license, so there is a reason for putting metadata such
 as the license inside the video.

Ah yes, in this case I agree: if the metadata were machine-readable,
that would be great. I was talking about the URL not appearing in the
actual human-visible content.

I do hope we see some good standardization on embedded metadata.

-Ben

Re: [whatwg] meter with Only 1 Number

On Thu, 12 Jul 2007, Smylers wrote:

 meter in the current spec refers to 'the steps for finding one or two 
 numbers of a ratio in a string', and the user-agent requirements for 
 determining the maximum value explicitly allow for the textContent to 
 contain just one number (and no denominator punctuation character) -- 
 for example if the maximum is specified in the attribute, or if the 
 default max of 1 is desired:
 
   http://www.whatwg.org/specs/web-apps/current-work/#meter
 
 So these should be allowed:
 
   meter max=53/meter
 
   meter0.59/meter
 
 However the steps referred to don't, despite their name, seem to have 
 any way of returning just 1 number:
 
   http://www.whatwg.org/specs/web-apps/current-work/#ratios
 
 The only places where the steps return something (as distinct from 
 nothing) are step 8, which returns a number and a denominator character, 
 and step 14, which returns two numbers.
 
 In particular for a meter like either of the above, the number will be 
 parsed as number1 in step 4, then steps 6-8 will have no affect (because 
 there is no denominator character), step 9 will fail to find a second 
 number, and therefore step 10 will return nothing.
 
 I think that making step 10 instead return number1 will yield the 
 desired behaviour.

Good catch, thanks. Fixed.

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

Re: [whatwg] Fallback behavior


João Eiras wrote:

On , Jonas Sicking [EMAIL PROTECTED] wrote:
(...)


Here is the list of elements that we *don't* execute scripts inside of 
in firefox:


http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148 



i.e. iframe, noframes, noembed

Everywhere else we do execute the script.

The reason these elements ended up at the list is in bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=5847
https://bugzilla.mozilla.org/show_bug.cgi?id=26669

/ Jonas



I kind of agree with iframe and noembed, but noframes ?
noframes, IMO, it fairly legitimate, because you can have scripts 
providing fallback, or redirecting to another page.


Yes, we would presumably run scripts in noframes if we didn't have 
frame support. There is even a comment in the code that says that we 
should not check for noscript if we ever add the ability to turn off 
frame support.


/ Jonas

Re: [whatwg] Fallback behavior

2008-08-21 Thread Simon Pieters


On Thu, 21 Aug 2008 23:54:44 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:

Here is the list of elements that we *don't* execute scripts inside of  
in firefox:


http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148

i.e. iframe, noframes, noembed

Everywhere else we do execute the script.

The reason these elements ended up at the list is in bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=5847
https://bugzilla.mozilla.org/show_bug.cgi?id=26669


iframe, noframes and noembed are parsed as CDATA elements

   
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ciframe%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E%3C%2Fiframe%3E

so there can't be any script elements as children of those in text/html.  
In Opera and WebKit, the script executes in


   data:text/xml,iframe  
xmlns='http://www.w3.org/1999/xhtml'scriptalert(1)/script/iframe


and it hasn't caused us any problems AFAIK.

--
Simon Pieters
Opera Software

[whatwg] race condition in postMessage

There is a race condition in proposed new Web Workers spec. The return 
value from postMessage can in some cases be true, even if the worker 
never receives the message.


For example:

main.js:

w = new DedicatedWorker(worker.js);
if (w.postMessage(hello there)) {
  alert(success!!);
}


worker.js:

close();


If the postMessage is called before the worker has executed the 
'close()' call the function will return true. But if the worker starts 
up fast enough and calls close(), the function will return false.


To put it another way. Even if the worker is currently up and running 
when postMessage is called, there is no guarantee that the worker will 
run long enough to actually get to process the message.


The only solution I can see is making postMessage return void. What use 
cases require knowing that the postMessage succeeds?


/ Jonas

Re: [whatwg] Fallback behavior


Simon Pieters wrote:

On Thu, 21 Aug 2008 23:54:44 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:

Here is the list of elements that we *don't* execute scripts inside of 
in firefox:


http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148 



i.e. iframe, noframes, noembed

Everywhere else we do execute the script.

The reason these elements ended up at the list is in bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=5847
https://bugzilla.mozilla.org/show_bug.cgi?id=26669


iframe, noframes and noembed are parsed as CDATA elements

   
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ciframe%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E%3C%2Fiframe%3E 



so there can't be any script elements as children of those in text/html. 
In Opera and WebKit, the script executes in


   data:text/xml,iframe 
xmlns='http://www.w3.org/1999/xhtml'scriptalert(1)/script/iframe


and it hasn't caused us any problems AFAIK.


Looks like firefox doesn't parse the contents of the iframe as markup 
either, but rather treat it as CDATA. Which makes me wonder why we ever 
look for iframes in the parent chain :)


I suspect it's just remnants from when things worked differently, the 
check was put in in 1999 :)


But the effect is that even in XHTML, like the example you're providing 
above, scripts in iframes don't execute. This was not intentional though 
given that this code was put in in 1999, before we had xhtml support.


/ Jonas

Re: [whatwg] RDFa


(Back on WHATWG.)

On Thu, 21 Aug 2008, Ben Adida wrote:
 Ian Hickson wrote:
  I've taken this off the WHATWG list since it isn't about HTML5.
 
 That's unfortunate, since that's where it started regarding adding RDFa 
 support in HTML5. It would be nice if at least folks could see the 
 answer I sent.

I've whitelisted your e-mail address so that you can post to the WHATWG 
list without subscribing. However, if the e-mails on this thread were 
intended to be a request that the RDFa attributes be considered for HTML5, 
I must admit to having misunderstood the request.

I've addressed RDFa only in this message (as opposed to creative commons 
markup). It would be helpful if you could send a separate message that is 
specifically asking for the changes you desire, and explaining what 
problem it is they address, and what research shows that that is an 
important enough problem that we should address it. The messages sent so 
far seemed to be more about Creative Commons than about RDFa.


 Yes, there are lots of people who ask us (CC) if we have tools to 
 automatically embed license + attribution + title + more information and 
 automatically extract it.

That's weird. I wonder why these people are asking Creative Commons for 
these tools and not asking other communities (e.g. the WHATWG community). 
Usually I find that when there is a need, the people with that need 
approach multiple different groups trying to get their need met.

I'm also curious as to why, if this is so commonly requested, similar 
features such as hCard and hCalendar have seen limited uptake. I mean, 
sure, they are used on hundreds of sites, but on the cosmic scale of 
things that's pretty limited, especially given the wide applicability of 
those formats.


 Every time you say copyright statement as if that's the entire issue, 
 it shows that you haven't taken much time to think about our needs.

Who is the antecedant of our? It's the needs of the entire Web community 
that have to be taken into account for HTML. There are thousands of small 
communities with their own needs, we can't possibly address each one in 
HTML. Indeed, we have design principles that make addressing the needs of 
small communities an explicit non-goal.


 If the world always went by what the biggest player thinks is useful, 
 innovation would slow down pretty quickly. Some of your competitors are 
 quite a bit more interested in RDFa than you are.

There certainly is _some_ interest in RDFa, or we wouldn't be having this 
conversation. But I haven't seen the level of interest that, say, video or 
offline Web applications have had. I haven't even seen the level of 
interest that random HTML elements like abbr have received. The interest 
in technologies like RDF seems to be almost exclusively from people in the 
metadata processing space.


  You can create your own vocabularies without clashing with the 
  Microformats community and without introducing extensions to HTML.
 
 How do you know you're not clashing?

Use a unique name, e.g. include a domain name in the name, as in 
license.creativecommons.org or home.foaf.w3.org, or use a name you 
know isn't used because it's an unusual name, e.g. cc:license.


  Fundamentally my opinion is that RDFa is solving a problem that people 
  at large have no interest in addressing.
 
 I'm not sure what people at large means, but I do think your opinion 
 is not very well informed. There is significant interest in a generic 
 syntax for adding metadata inside HTML. It's a lot of the same drive for 
 microformats, for all the folks who can't handle the centralized process 
 and who need the vocab modularity.

I honestly don't see significant interest in computer-readable metadata. 
Just look at the average user's media library; most users have terrible 
metadata hygene.

But in any case HTML5 already has extension mechanisms, so the discussion 
should not be over whether RDFa is worth it or not, the discussion should 
be over what extension mechanisms RDF needs that HTML5 doesn't provide.


  That's not to say that I don't think computer-readable detailed 
  metadata is a great idea and everything, I just don't think it'll work 
  when your average human faces it.
 
 Why don't we at least build a real mechanism for expressing web-based 
 data, with distributed innovation and such, and the good parts of 
 microformats (*in* the HTML, DRY, etc...) And then we'll see. But you 
 keep basing your opinion on a past that never attempted to do this 
 right.

The failures of the past have had little to do with the syntax or 
expression mechanisms. They have to do with users simply not caring. It 
doesn't matter how wonderful or overengineered the solution we give them, 
if they don't care, they aren't going to use it correctly (if at all).


  With things like licensing metadata, where the person who benefits the 
  most isn't the person who writes the data, users simply aren't going 
  to bother doing a good job.
 
 That's an

[whatwg] Scripted video query proposal

2008-08-21 Thread Tim Starling

interface HTMLMediaElement {
...
boolean supportsType(in DOMString type);
...
}

The supportsType() method must return false if the user agent is sure it
cannot support the given type, and true if the user agent either can
support the given type, or cannot determine whether it can support the
given type.

The type parameter must be a MIME type. The codecs parameter may be
specified and might be necessary to specify exactly how the resource is
encoded [RFC2046] [RFC4281].

[end spec proposal]

Sample of simple detection JavaScript code:

div = document.getElementById('videocontainer');
video = document.getElementById( 'video1' );
if (!video.supportsType('application/ogg;codecs=theora)) {
div.innerHTML = Sorry, you can't play this content;
} else {
video.play();
}

Complains only if the browser is sure it doesn't support the type,
otherwise it will try to play.

Sample of complex detection code:

supportsJava = navigator.javaEnabled  navigator.javaEnabled();
badVideo = false;
goodVideo = false;
if (HTMLVideoElement) {
video = new HTMLVideoElement;
if (!video) {
// no video support
} else if (video.supportsType('application/x-nonsense-type')) {
badVideo = true;
} else if (video.supportsType('application/ogg;codecs=theora')) {
goodVideo = true;
}
}
if (goodVideo) {
embedVideo();
} else if (supportsJava) {
embedCortado();
} else if (badVideo) {
embedVideo();
} else {
showErrorMessage();
}

Shows the video only if the browser is reasonably likely to support
it, or if there is no Java alternative.

-- Tim Starling

[whatwg] 2.7.4. Content-Type sniffing

2008-08-21 Thread Mark Pilgrim

The spec has a note saying I'd like to add types like MPEG, AVI,
Flash, Java, etc, to the above table.
http://www.garykessler.net/library/file_sigs.html seems to have an
up-to-date list of many file signatures, including SWF (43 57 53), AVI
(52 49 46 46 xx xx xx xx 41 56 49 20 4C 49 53 54), Java class files
(CA FE BA BE), MPEG files (00 00 01 Bx), and so on.

Cheers,
-Mark

Re: [whatwg] Scripted video query proposal

2008-08-21 Thread Eric Carlson



On Aug 21, 2008, at 7:46 PM, Robert O'Callahan wrote:

Any browser that supports integration with an extensible framework  
like GStreamer, Quicktime or Direct Show is going to have a hard  
time ever reporting false. Apparently there was a conversation  
today in #theora that you might have seen whcih explains why this is  
so, at least for GStreamer.


With a three-value return, at least Firefox with both Ogg Theora and  
Quicktime support could return yes for Ogg and maybe for other  
types. But I think Safari is going to have to return maybe all the  
time --- except perhaps for codecs built into Quicktime. That  
doesn't help you.


  It is possible to build a list of all types supported by QuickTime  
dynamically. WebKit does this, so Safari knows about both the built in  
types and those added by third party importers.


eric

Re: [whatwg] Scripted video query proposal

2008-08-21 Thread Robert O'Callahan

On Fri, Aug 22, 2008 at 2:57 PM, Eric Carlson [EMAIL PROTECTED]wrote:

 It is possible to build a list of all types supported by QuickTime
 dynamically. WebKit does this, so Safari knows about both the built in types
 and those added by third party importers.


You mean this
http://trac.webkit.org/browser/trunk/WebCore/platform/graphics/mac/MediaPlayerPrivateQTKit.mm#L815
which calls this?
http://developer.apple.com/documentation/QuickTime/Reference/QTKitFramework/Classes/QTMovie_Class/Reference/Reference.html#//apple_ref/occ/clm/QTMovie/movieFileTypes
:

Does that actually enumerate all supported codecs? Looking at the Webkit
code and the Quicktime docs, it looks like it's just enumerating
file/container types.

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]

Re: [whatwg] hashchange only dispatched in history traversal

2008-08-21 Thread Garrett Smith

On Thu, Aug 21, 2008 at 4:09 PM, Ian Hickson [EMAIL PROTECTED] wrote:
 On Thu, 21 Aug 2008, Garrett Smith wrote:

 HTML 5 expands hashchange to any element. Any element, such as div
 or pre? How can you know if an element supports hashchange or not?

 I'm not sure what you mean. In HTML5, all event handler _attributes_ can
 be placed on any element, but that doesn't mean that the event will be
 fired by the UA at any element. The spec only fires the event at the body
 element.


The spec fires an event at the body element? LOL What does that mean?
Can you explian this using standard terms like currentTarget and
thisArg?

That's funny.

Detecting support for events is painful.  Detecting hashchange events,
given the current design, will be very painful.


 hashchange seems closely related to the Location interface, so it
 would seem to make sense to have hashchange implemented for objects
 that implement Location.

 Has this been considered?

 Yes, but the benefit of being able to do body onhashchange= outweighs

What benefit?

 the logicalness of dispatching events to the Location object.


The design association of Location --- LocationEvents

would seem to make browser scripting very easy. Once a location object
is obtained, it can be assumed to behave the way all location objects
behave. That would mean that it might be a fair inference to test:

if(location.addEventListener),

but that might be too loose an inference. A more thorough approach would be:-

var EventSupport = {};
if(location.addEventListener) {
(function(){
 var es = EventSupport;
 // Initialize the touch and gesture properties.
 es.location = hasSupport(LocationEvent);

 function hasSupport(s){
  try {
document.createEvent(s);
return true;
   } catch (e) {
 return false;
  }
 }
})();
}


  I'm not sure what that has to do with the body element.
 
  Nothing especially, except that that is where the event is fired, so
  that you can do body onhashchange=


That precludes the ability that hashchange would ever be supported on
body element. What's worse, the body element is far removed from the
event. It's not clear what the event target is or what the
event.target should be when the event fires. It is unclear what the
thisArg will be. The body is a child of the documentElement, which is
a child of the document, which is a property of the window.  It's far
removed.

Body's event handlers propagating to window worked in legacy browsers.
These browsers had such bararic APIs that design didn't matter. Demand
changed, browsers changed. Modern browsers are rich enough to
accommodate rich browser side applications and the trend forwards is
towards richer and richer functionality. API design matters more.


 Body event handler attributes cascading to window is unclear and creates
 ambiguity as to what the event is being attached to.

 body onmousedown=alert(this)

 alerts window in Firefox 3. The mousedown event fires anywhere, not
 just on the body. This creates ambiguity. So it is a practice that
 should be avoided in attempt to be cross browser. Has this problem been
 considered?

 Yeah, this is an open issue. I'm hoping that the DOM Events spec handles
 it.


Hoping? Why?

Creating ambiguous, illogical, confusing programming constructs is bad.

Such features will get used and the ambiguity will be realized in
implementations and with less careful, less knowledgeable developers
who did not memorize the complexities of an ambiguous API.

Such practices can be deprecated and discouraged in favor of features
that work better. This can be effective and font is good evidence.
Not much new code uses font because we have CSS working. This type
of new bad feature seems to be something that should be considered.
Hindsight is always better and retrospectively, we can see things that
the earlier specs got wrong. Using tests to write out proposals would
be a way to avoid this. For example, for hashchange feature, a test
could be wrote. it would fail, but we would see the design of the API.
From there, we could hack up a poll function using setInterval, and
with that, we could see the effect of how the API would work. It's
more work, but would seem to be worthwhile insurance.



 1) add a note about bubbling. hashchange events bubble

 Per the spec, it doesnt.

Ah, but per MSDN, it does.
http://msdn.microsoft.com/en-us/library/cc288209(VS.85).aspx

Specifying this in a different manner than the way it is specified in
MSDN is a good way to make browser scripting more difficult.

IE's hashchange bubbles.

Was this considered?


 2) replace the fires at the body element with the EventTarget fires
 the event

 I disagree with this interpretation of the terminology.


Then can you write something using standard terminology? I really
don't know what fires at the [xxx] means.

Thanks.

Garrett

 --
 Ian Hickson   U+1047E)\._.,--,'``.fL

Re: [whatwg] RDFa

2008-08-21 Thread Silvia Pfeiffer

On Fri, Aug 22, 2008 at 11:48 AM, Ian Hickson [EMAIL PROTECTED] wrote:
 I honestly don't see significant interest in computer-readable metadata.
 Just look at the average user's media library; most users have terrible
 metadata hygene.

It is true, we live in the middle ages of metadata hygene. But maybe
we can help move out of it and into more modern times by making tools
available that support metadata consistency better and that
automatically take care of some of the hygiene. Any such efforts
should be supported. We will not be able to get away completely from
having to deal with dirty metadata, but if it has an advantage to
people, they will care. The whole SEO industry is built on that fact.

 But in any case HTML5 already has extension mechanisms, so the discussion
 should not be over whether RDFa is worth it or not, the discussion should
 be over what extension mechanisms RDF needs that HTML5 doesn't provide.

I would like to understand exactly what changes to the existing HTML5
spec would be required to support RDFa. Ben - can you clarify? Maybe
the extension mechanism that Ian refers to already covers all the
needs, but it has not been clarified.

Regards,
Silvia.

Re: [whatwg] number-related feedback

2008-08-21 Thread Shannon

I was going to suggest the spec define unsigned integers as a value
between 1 and MAX_INT inclusive when I realised the spec doesn't define
the range of integer values at all. Is this deliberate?

Either way I would recommend making a decision on minimum and maximum
integer values an using them consistently. If not I can imagine the
rapid adoption of 64-bit systems will cause unexpected errors when the
same code is run on older 32-bit systems. There are valid arguments for
letting each system use its native integer but if this is the case then
perhaps the spec should require MIN_INT and MAX_INT be made available as
constants.

Also the spec interchanges the terms non-negative integer, positive
integer and unsigned integer. I suggest defining one of these clearly
and then using it everywhere.

This is a very minor point but is it necessary to say valid integer.
Given that there appears to be no defined min/max range when is
something both an integer and at the same time invalid? Isn't an invalid
integer a string?

Finally I wasn't aware Javascript made a distinction between signed and
unsigned integers. Is the distinction really necessary? Can we just make
everything signed integers and consistently call the full range
integer and the positive range integer greater than 0?

Shannon

Re: [whatwg] RDFa