Re: [whatwg] Thesis draft about HTML5 conformance checking

[olivier Thereaux]

On Mar 28, 2007, at 21:24 , Henri Sivonen wrote:
It's been a truly informative and enlightening reading, especially  
the parts where you develop on the (im)possibility of using only  
schemas to describe conformance to the html5 specs. This is a  
question that has been bothering me for a long time, especially as  
there is only one (as of today) production-ready conformance  
checking tool not based on some kind (or combination) of schema- 
based parsers,


I take it that you mean the Feed Validator?


Indeed.

Also, in the future, I'd like to make it super-easy for CMS  
developers to integrate the conformance checker back end to their  
products. To enable this, the barrier for getting a runnable copy  
should be low.


Libraries/APIs in a few languages?

I'm very pessimistic about translations. Even the online markup  
checkers whose authors have borne the burden of making the messages  
translatable aren't getting numerous translation contributions.


It depends. Projets with large user bases do get a lot of volunteers  
for translation.



Indeed. Did you have a chance to look at EARL?


I did. I also had a look at the SOAP and Unicorn outputs of the W3C  
Validator. I like EARL the least of the three, because its  
assumptions about the nature of the checker software do not work  
well with implementations that have a grammar-based schema inside.  
Grammar-based implementations cannot cite an exact conformance  
criterion when a derivation in the grammar fails as demonstrated by  
the EARL output of the W3C Validator. The SOAP and Unicorn formats,  
even if crufty to my taste, match better the SAX ErrorHandler  
interface.


Interesting, thanks for your thoughts. Which version of EARL did you  
look at? If you made your mind based on the earl outputs of the  
markup validator, note that it's due for an update. the EARL spec has  
gone through a lot of development and changes, and the new version  
clearly takes conformance checkers as a use case:

http://www.w3.org/TR/2007/WD-EARL10-Schema-20070323/
The group developing EARL is really eager to get feedback, so if you  
find that it has shortcomings in some areas, I think you could easily  
get that changed.


--
olivier

Re: [whatwg] Attribute for holding private data for scripting

[Jon Barnett]

I can think of two possibilities.

One would be to allow the param element as a child of any element (or any
block level element?)
http://www.whatwg.org/specs/web-apps/current-work/#param

And then make an attribute of HTMLElement called params
readonly attribute HTMLCollection params;

Where params is a collection of HTMLParamElements that are children (not
further descendants) of that element.

That would make this:
Some more content

easy to access via JavaScript:
var foo = document.getElementById("foo");
if(foo.params['answer'] == 42) {
// it is!!
}

The only other possibility I can think of would be an HTML attribute called
"params" that would be a list of tokenized name value pairs, but that sounds
even hairier to implement.

This would have simplified something I did last week involving the Google
Maps API, where I did, as mentioned, make up a fake attribute.  There may be
better ways to do this.

On 4/9/07, ddailey <[EMAIL PROTECTED]> wrote:


Henri, thanks for the link to PPK's suggestions -- I rather like many of
them.

Henri Sivonen wrote:

> At http://www.quirksmode.org/blog/archives/2007/04/html_5.html PPK
> suggests having an attribute for storing private data for scripts.
>

I'm having a hard time seeing what you're talking about here. When PPK
says
"This attribute [to store data for unobtrusive scripts] should be valid
for
all HTML elements. " I'm rather sure I've lost you.

Sometimes, I'll stick a long string inside an invisible textarea just so
as
to give JavaScript something to chew on -- then I can use string.split to
pull the data apart. Is that what you mean? I rather doubt it.

By "private" you don't really mean inaccessible to end users do you?

I think I need an example to understand.

regards,
David






--
Jon Barnett

Re: [whatwg] Give guidance about RFC 4281 codecs parameter

[Dave Singer]

At 11:59  -0700 9/04/07, Charles Iliya Krempeaux wrote:

Hello,

On 4/9/07, Dave Singer <[EMAIL PROTECTED]> wrote:

WARNING:  I have CC'd the co-authors of the RFC, as I think they 
might like to see the discussion, comment on my answers, and 
possibly correct me.  I also have a question whether there is a typo 
in the RFC...


* * * * *


Henry

these are all great questions.  Let me see how many I can answer.

Overall, the RFC was struggling with the issue that there is no 
'uniform' naming of codecs;  the namespace for codecs is dependent 
on the container format, so products that do container conversion 
have to have tables of code matches.  ugh.  That's why the RFC is as 
it is.


The RFC suggests that updated information would be done with RFCs, 
which is a little heavy.  The RFC as written formally applies to 
3GPP files and 3GPP2 files, but the definitions are applicable for 
all ISO-family files.


As you'll see below, 3GPP has also defined it for avc1 in MP4-family 
containers, but no spec. or registration authority provides a 
pointer.  We might want to ask IANA whether we could add something 
to the MIME registry.



At 11:37  +0300 8/04/07, Henri Sivonen wrote:



 * Theora video and Vorbis audio in Ogg container. (application/ogg; .ogg)
 * Dirac video and Vorbis audio in Ogg container. (application/ogg; .ogg)
 * Theora video and Vorbis audio in Matroska container. 
(video/x-matroska; .mkv)
 * Dirac video and Vorbis audio in Matroska container. 
(video/x-matroska; .mkv)




My understanding is that the Ogg container is 'specific' to these 
codecs, and therefore the codecs parameter is not needed.  But I am 
not an Ogg or Matroska expert;  perhaps they could chime in?



No.  The containers are independent of the codecs put inside.

However, whether software, that supports Ogg or Matroska containers 
will actually be able to "play" other codecs is another issue 
altogether.


[...]



so a defined 'codecs' parameter might be prudent, perhaps.  Thanks 
for the correction.

--
David Singer
Apple Computer/QuickTime

Re: [whatwg] Give guidance about RFC 4281 codecs parameter

[Charles Iliya Krempeaux]

Hello,

On 4/9/07, Dave Singer <[EMAIL PROTECTED]> wrote:


 WARNING:  I have CC'd the co-authors of the RFC, as I think they might
like to see the discussion, comment on my answers, and possibly correct me.
I also have a question whether there is a typo in the RFC...

* * * * *


Henry

these are all great questions.  Let me see how many I can answer.

Overall, the RFC was struggling with the issue that there is no 'uniform'
naming of codecs;  the namespace for codecs is dependent on the container
format, so products that do container conversion have to have tables of code
matches.  ugh.  That's why the RFC is as it is.

The RFC suggests that updated information would be done with RFCs, which
is a little heavy.  The RFC as written formally applies to 3GPP files and
3GPP2 files, but the definitions are applicable for all ISO-family files.

As you'll see below, 3GPP has also defined it for avc1 in MP4-family
containers, but no spec. or registration authority provides a pointer.  We
might want to ask IANA whether we could add something to the MIME registry.


At 11:37  +0300 8/04/07, Henri Sivonen wrote:


 * Theora video and Vorbis audio in Ogg container. (application/ogg; .ogg)
 * Dirac video and Vorbis audio in Ogg container. (application/ogg; .ogg)
 * Theora video and Vorbis audio in Matroska container. (video/x-matroska;
.mkv)
 * Dirac video and Vorbis audio in Matroska container. (video/x-matroska;
.mkv)


My understanding is that the Ogg container is 'specific' to these codecs,
and therefore the codecs parameter is not needed.  But I am not an Ogg or
Matroska expert;  perhaps they could chime in?



No.  The containers are independent of the codecs put inside.

However, whether software, that supports Ogg or Matroska containers will
actually be able to "play" other codecs is another issue altogether.

[...]


See ya


--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/

Re: [whatwg] Attribute for holding private data for scripting

[ddailey]

Henri, thanks for the link to PPK's suggestions -- I rather like many of 
them.


Henri Sivonen wrote:

At http://www.quirksmode.org/blog/archives/2007/04/html_5.html PPK 
suggests having an attribute for storing private data for scripts.




I'm having a hard time seeing what you're talking about here. When PPK says 
"This attribute [to store data for unobtrusive scripts] should be valid for 
all HTML elements. " I'm rather sure I've lost you.


Sometimes, I'll stick a long string inside an invisible textarea just so as 
to give JavaScript something to chew on -- then I can use string.split to 
pull the data apart. Is that what you mean? I rather doubt it.


By "private" you don't really mean inaccessible to end users do you?

I think I need an example to understand.

regards,
David 

Re: [whatwg] Attribute for holding private data for scripting

[Maciej Stachowiak]

On Apr 8, 2007, at 11:12 AM, Henri Sivonen wrote:

At http://www.quirksmode.org/blog/archives/2007/04/html_5.html PPK  
suggests having an attribute for storing private data for scripts.


Currently, one can invent an attribute and it will work for  
scripts. However, it will look ugly for conformance checking. Since  
this is essentially a conformance definition issue as browsers  
would not be required to implement anything new (assuming a new  
reflecting attribute on HTMLElement is deemed unnecessary), adding  
an attribute for script-private data would be rather easy.


I think it would be worthwhile to add an attribute for script- 
private data to common attributes, so that scripters who need one  
and want to be conforming don't need to abuse e.g. title.


The class attribute can already be used for script-private data. I  
think the time script authors go for made-up attributes is when they  
need a set of key-value pairs. Class is not so great for that, but  
I'm not sure any new attribute would be either, unless it provided  
some sort of built-in key-value parsing.


Regards,
Maciej

Re: [whatwg] Give guidance about RFC 4281 codecs parameter

[Dave Singer]

WARNING:  I have CC'd the co-authors of the RFC, as I think they 
might like to see the discussion, comment on my answers, and possibly 
correct me.  I also have a question whether there is a typo in the 
RFC...


* * * * *


Henry

these are all great questions.  Let me see how many I can answer.

Overall, the RFC was struggling with the issue that there is no 
'uniform' naming of codecs;  the namespace for codecs is dependent on 
the container format, so products that do container conversion have 
to have tables of code matches.  ugh.  That's why the RFC is as it is.


The RFC suggests that updated information would be done with RFCs, 
which is a little heavy.  The RFC as written formally applies to 3GPP 
files and 3GPP2 files, but the definitions are applicable for all 
ISO-family files.


As you'll see below, 3GPP has also defined it for avc1 in MP4-family 
containers, but no spec. or registration authority provides a 
pointer.  We might want to ask IANA whether we could add something to 
the MIME registry.



At 11:37  +0300 8/04/07, Henri Sivonen wrote:


 * Theora video and Vorbis audio in Ogg container. (application/ogg; .ogg)
 * Dirac video and Vorbis audio in Ogg container. (application/ogg; .ogg)
 * Theora video and Vorbis audio in Matroska container. 
(video/x-matroska; .mkv)
 * Dirac video and Vorbis audio in Matroska container. 
(video/x-matroska; .mkv)


My understanding is that the Ogg container is 'specific' to these 
codecs, and therefore the codecs parameter is not needed.  But I am 
not an Ogg or Matroska expert;  perhaps they could chime in?


We did have the discussion over profiles of these codecs;  I 
understand profiles are not used, but I am still unclear as to which 
of the following is true:
a) features are never added to the bitstreams, so any release of the 
decoder will decode bitstreams made by any release of the encoder 
(modulo bugs);
b) the decoder release needed is signalled somehow in the bitstream 
('need at least the April 2005 release or later to decode this file')
c) neither of the above are true, it's left to the users to stay up 
to date, and if they don't, then, well, that's their problem.


If there are profiles, release versions etc. signalled, then a 
parameter might be appropriate, and if the container formats are 
general, a codecs parameter might be appropriate.


 * H.264 Baseline profile video and Low-Complexity AAC audio in MP4 
container. (video/mp4; .mp4)


The AAC is covered by the RFC;  the example is there - mp4a.40.2.

H.264 was recently covered by 3GPP.  See 26.244 V7.1.0 section A.2.2, 
available from www.3gpp.org.


When the first element of a value is 'avc1', indicating H.264 (AVC) 
video [29], the second element is the hexadecimal representation of 
the following three bytes in the sequence parameter set NAL unit 
specified in [29]: 1) profile_idc, 2) a byte composed of the values 
of constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, 
constraint_set3_flag, and reserved_zero_4bits in bit-significance 
order, starting from the most significant bit, and 3) level_idc. Note 
that reserved_zero_4bits is required to be equal to 0 in [29], but 
other values for it may be specified in the future by ITU-T or 
ISO/IEC.


You don't give me a level number, so I put xx for those hex digits below.

Assuming we're simple baseline, and also main and extended compatible
avc1.42E0xx


 * H.264 Extended profile video and Low-Complexity AAC audio in MP4 
container. (video/mp4; .mp4


Extended profile has the value (decimal) 88, and typically Extended 
profile streams would be marked as Baseline compatible, at least. 
Here is an example for this AVC


avc1.58A0xx


 * H.264 Main profile video and Low-Complexity AAC audio in MP4 
container. (video/mp4; .mp4)


Main profile is decimal 77, so something like
avc1.4D40xx

 * H.264 High profile video and Low-Complexity AAC audio in MP4 
container. (video/mp4; .mp4)


There are a number of high profiles, confusingly, though there is one 
called 'high', with value decimal 100.

avc1.6400xx

if it's not compatible with main, baseline, or extended profiles.

 * MPEG-4 Simple Profile profile video and Low-Complexity AAC audio 
in MP4 container. (video/mp4; .mp4)


Covered by the RFC:

For example, MPEG-4 Visual Simple Profile Level 0 has the value 9,
   so a complete string for MPEG-4 Visual Simple Profile Level 0 would
   be "mp4v.20.9".

Though when checking the next answer, I read in the spec. that we may 
have a typo here, it might be 8.  Ooops, if so.


Simple Profile/Level 0  1000
Reserved1001 - 


 * MPEG-4 Advanced Simple Profile profile video and Low-Complexity 
AAC audio in MP4 container. (video/mp4; .mp4)


Advanced Simple  Profile/Level 0

so, mp4v.20.240

 * MPEG-4 Simple Profile profile video and AMR audio in 3GPP 
container. (video/3gpp; .3gp)


Video we've covered.  AMR is in 26.244,

samr



 * WMV9 video and WMA 2 audio in ASF container.

Re: [whatwg] Anchor target-attribute extension to enable dom targeting

[Gervase Markham]

Kornel Lesinski wrote:
I was just referring to the concept. Something similar could be made for 
HTML.


It has been, albeit requiring script at the moment:

http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html

Gerv