Re: [whatwg] Offline Resources

[Maciej Stachowiak]

On Jun 10, 2007, at 3:40 AM, Lachlan Hunt wrote:


Hi,
  Apparently Firefox 3 has implemented new features for offline  
resources, including rel="offline-resource" and some new DOM APIs.


| Introduced support for , which puts
| resources into the browser's offline cache. This allows a web
| application to ensure that its resources are available in the cache
| when the browser goes into offline mode. See Marking Resources for
| Offline Use for further details on offline support.

http://www.mozilla.org/projects/firefox/3.0a3/releasenotes/
http://www.campd.org/stuff/Offline%20Cache.html

This seems someone similar in functionality to the local cache  
feature in Google Gears.  It would probably be worth investigating  
it and standardising something like it in HTML5.


There was a recent (brief) discussion thread on this. I think the  
Google Gears design for this works better than the Mozilla design,  
because it lets offline mode use all the same URIs as regular mode,  
so the offline support can be cleanly factored from the rest of the  
web app. I think we should discuss the right standards approach  
further, though I'm somewhat surprised that Mozilla hasn't brought  
their work so far to the standards process before now.


Regards,
Maciej

Re: [whatwg] Still more comments and questions on Web Apps 1.0

[Maciej Stachowiak]

On Jun 8, 2007, at 6:05 PM, Ian Hickson wrote:



I am not an expert here, but IIRC, the underlying PDF/Quartz  
imaging model
does not allow general xoring. I think it is important to ensure  
that canvas
can be implemented on top a Quartz 2D drawing context on OS X  
without breaking

hardware acceleration or PDF output.


I can drop 'xor', I guess...


PDF can't actually do the other porter-duff operators either (except  
SrcOver). Instead it has a different concept of "blend modes" which  
are supposedly more general but can't actually synthesize the porter- 
duff operators. However, on OS X the 'xor' operator will be supported  
at least as well on any given graphics context as, say, SrcAtop or  
DestAtop. In practice what happens on graphics contexts that can't  
natively support the operator is that a bitmap is generated.


I would recommend against dropping XOR.

Regards,
Maciej

Re: [whatwg] Still more comments and questions on Web Apps 1.0

[Henri Sivonen]

On Jun 10, 2007, at 15:31, Michel Fortin wrote:


Le 2007-06-10 à 7:05, Anne van Kesteren a écrit :

On Sat, 09 Jun 2007 23:03:54 +0200, Michel Fortin  
<[EMAIL PROTECTED]> wrote:

I don't think XML does that, actually.


See the first paragraph of http://www.w3.org/TR/xml/#syntax for  
the reason why this is so. White space outside the the root  
element is markup and not text.


Yyou're right. I was indeed missing something. Thank you.

In that case, I guess it'd make sense to do the same for HTML.


Yes, it makes sense to do the same. Otherwise there'd be particularly  
esoteric non-roundtrippable case when converting from HTML5 to XHTML5  
and back to HTML5.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] Still more comments and questions on Web Apps 1.0

[Michel Fortin]

Le 2007-06-10 à 7:05, Anne van Kesteren a écrit :

On Sat, 09 Jun 2007 23:03:54 +0200, Michel Fortin  
<[EMAIL PROTECTED]> wrote:

I don't think XML does that, actually.


See the first paragraph of http://www.w3.org/TR/xml/#syntax for the  
reason why this is so. White space outside the the root element is  
markup and not text.


Yyou're right. I was indeed missing something. Thank you.

In that case, I guess it'd make sense to do the same for HTML.

Oh and I've said PHP 5's parser (libxml2) treat it as text; I've just  
realised there was an error in my test. In reality it does ignore  
whitespace at the root of the document. Sorry for the confusion.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] accessibility management for timed media elements, proposal

[Benjamin Hawkes-Lewis]

I wrote:

The crudest way of doing this would be to provide transcriptions of 
audio descriptions to supplement the captions. I believe one can do that 
with SMIL; I don't know what the situation with other container formats 
or player UIs is however.


I just ran across the Open and Closed Project's proposal for a XEX 
format including "audio description scripts", which is precisely the 
sort of inclusion I mentioned:


http://openandclosed.org/docs/AccessibilityExchange.html

--
Benjamin Hawkes-Lewis

Re: [whatwg] Still more comments and questions on Web Apps 1.0

[Anne van Kesteren]

On Sat, 09 Jun 2007 23:03:54 +0200, Michel Fortin  
<[EMAIL PROTECTED]> wrote:

I don't think XML does that, actually.


See the first paragraph of http://www.w3.org/TR/xml/#syntax for the reason  
why this is so. White space outside the the root element is markup and not  
text.



--
Anne van Kesteren

Re: [whatwg] accessibility management for timed media elements, proposal

[Benjamin Hawkes-Lewis]

Dave Singer wrote:


At 16:35  +0100 9/06/07, Benjamin Hawkes-Lewis wrote:


[snip]


The proposal does not describe how conflicts such as the following
 would be resolved:

User specifies:

captions: want high-contrast-video: want

Author codes:

   


There is no suitable source here;  it's best to have something (late)
in the list which is less restrictive.


But if UAs can apply accessibility preferences to a catch-all 
listed last, then what's the advantage of creating multiple 
elements in the first place? Current container formats can
include captions and audio descriptions. So is the problem we're trying
to solve that container formats don't contain provision for alternate
visual versions (high contrast and not high contrast)? Or are we trying 
to cut down on bandwidth wastage by providing videos containing only the 
information the end-user wants?



a) I should think sign-language interpretation needs to be in
there.

sign-interpretation: want | dont-want | either (default: want)

Unless we want to treat sign interpretation as a special form of 
subtitling. How is subtitling in various languages to be handled?


I think we assume that a language attribute can also be specified, as
 today.


The lang attribute specifies "the primary language for the element's 
contents and for any of the element's attributes that contain text", not 
the referenced resource. hreflang "gives the language of the linked 
resource" as a single "valid RFC 3066 language code." So we'd need a new 
attribute or to change the content model of hreflang to explicitly 
specify the separate multiple languages of a resource.


http://www.whatwg.org/specs/web-apps/current-work/multipage/section-global.html#the-lang

http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#hreflang3

I note in passing that these attributes should be updated to use RFC 
4646 not RFC 3066 as per:


http://www.w3.org/TR/i18n-html-tech-lang/#ri20030112.224623362


I have to confess I saw the BBC story about sign-language soon after
sending this round internally.  But I need to do some study on the 
naming of sign languages and whether they have ISO codes.  Is it true

that if I say that the human language is ISO 639-2 code XXX, and
that it's signed, there is only one choice for what the sign language
is (I don't think so -- isn't american sign language different from
british)? Alternatively, are there ISO or IETF codes for sign
languages themselves?


Brian Campbell has eloquently answered some of these questions.

The reason I was thinking of using a CSS property was that signed 
interpretation is not the same as signing featured in the original 
video. But it's true that information about what sign languages are 
available is important, so a CSS property alone wouldn't solve the 
problem. Maybe we need new attributes to crack this nut:


dubbinglangs="fr" subtitlelangs="de,it" 
signedinterpretationlangs="sgn-en,sgn-fr,sgn-de,sgn-it" ...>


This would indicate that the main video content features people talking 
in English and people signing in English; the video is captioned in 
English, French, German, Italian, and their SignWriting analogues 
(American Sign Language in the case of English), dubbed in French, 
subtitled in German and Italian, and provided with signed interpretation 
in American, French, German and Italian Sign Languages.


Granted it's a sledgehammer, but it does provide the fine-grained 
linguistic information we need. It would also seemingly remove the need 
for putting a caption media query on . While this markup looks 
complicated, most videos currently on the web could be marked up like:




as all they provide is a single-language spoken track.



I should add a little note about "sgn-en-sgnw". The IANA language tag 
registry includes the following entry:



Type: script
Subtag: Sgnw
Description: SignWriting
Added: 2006-10-17


http://www.iana.org/assignments/language-subtag-registry

One might want to omit the sgnw subtag on the basis that other sign 
language transliterations are academic not everyday (just as one omits 
the latn subtag for en, fr, and so on). However, those who work on such 
things have yet to come up with an entirely settled formulation. See 
this thread on the IETF languages mailing list:


http://www.alvestrand.no/pipermail/ietf-languages/2006-October/005126.html

Meanwhile, people are already creating SignWriting captions:

http://www.webcitation.org/5PUMLS0mp




b) Would full descriptive transcriptions (e.g. for the deafblind)
fit into this media feature-based scheme or not?

transcription: want | dont-want | either (default: either)


how are these presented to a deafblind user?


Depends. I think the ideal would be to have transcriptions inside a 
container format, so that /everyone/ could access them and so that 
deafbind people who still have some sight can see some of the video. The 
transcriptions could be dispatched to a braille display. And, yeah, with 
my sledgehammer 

[whatwg] Offline Resources

[Lachlan Hunt]

Hi,
  Apparently Firefox 3 has implemented new features for offline 
resources, including rel="offline-resource" and some new DOM APIs.


| Introduced support for , which puts
| resources into the browser's offline cache. This allows a web
| application to ensure that its resources are available in the cache
| when the browser goes into offline mode. See Marking Resources for
| Offline Use for further details on offline support.

http://www.mozilla.org/projects/firefox/3.0a3/releasenotes/
http://www.campd.org/stuff/Offline%20Cache.html

This seems someone similar in functionality to the local cache feature 
in Google Gears.  It would probably be worth investigating it and 
standardising something like it in HTML5.


--
Lachlan Hunt
http://lachy.id.au/