On Mar 6, 2009, at 15:29, Marcos Caceres wrote:
2. The XHTML mapping should also appear in the file identification
table
[2].
What version of XHTML should I be pointing to? 1.0 or 1.1?
Does it need to say anything more than that .xhtml maps to application/
xhtml+xml? The media type is
Marcos Caceres schreef:
Hi Laurens,
As we no longer require user agents that conform the the packaging
spec to support any media types, I have added xhtml as a default start
file (extensions are .xhtml and .xht). This will be in the spec when I
next check the spec in.
Great, that adresses
On 3/6/09 2:24 PM, Laurens Holst wrote:
Marcos Caceres schreef:
Hi Laurens,
As we no longer require user agents that conform the the packaging
spec to support any media types, I have added xhtml as a default start
file (extensions are .xhtml and .xht). This will be in the spec when I
next
Marcos Caceres schreef:
2. The XHTML mapping should also appear in the file identification table
[2].
What version of XHTML should I be pointing to? 1.0 or 1.1?
Short version:
XHTML 1.1.
Long version:
The XHTML 1.0 spec has some interesting informative prose in section 4,
“differences
Hi Laurens,
As we no longer require user agents that conform the the packaging
spec to support any media types, I have added xhtml as a default start
file (extensions are .xhtml and .xht). This will be in the spec when I
next check the spec in.
Kind regards,
Marcos
2008/12/10 Laurens Holst
2008/12/10 Laurens Holst [EMAIL PROTECTED]:
Marcos Caceres schreef:
Seems that there is still too much incompatibility to suggest
application/xml support across Widget user agents. I think we should
just stick with text/html. If authors want to use application/xml,
then they can use content
On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres
[EMAIL PROTECTED] wrote:
If authors want to use application/xml,
then they can use content src=somefile type=application/xml /
and hope for the best :)
On Wed, Dec 10, 2008 at 12:06 AM, Adam Barth [EMAIL PROTECTED] wrote:
I haven't been
On Tue, Dec 9, 2008 at 10:06 PM, Adam Barth [EMAIL PROTECTED] wrote:
On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres
[EMAIL PROTECTED] wrote:
If authors want to use application/xml,
then they can use content src=somefile type=application/xml /
and hope for the best :)
I haven't been
Marcos Caceres schreef:
I'm not sure if any widget engines support application/xhtml+xml.
I do not know your definition of ‘widget engine’, but Opera, Safari,
Firefox all support application/xhtml+xml (and Prince XML too, but I
don’t suppose that would be used for widgets :)). And last I
Marcos Caceres schreef:
Seems that there is still too much incompatibility to suggest
application/xml support across Widget user agents. I think we should
just stick with text/html. If authors want to use application/xml,
then they can use content src=somefile type=application/xml /
and hope for
Hi Laurens,
2008/12/10 Laurens Holst [EMAIL PROTECTED]:
Marcos Caceres schreef:
I'm not sure if any widget engines support application/xhtml+xml.
I do not know your definition of 'widget engine', but Opera, Safari, Firefox
all support application/xhtml+xml (and Prince XML too, but I don't
On Wed, Dec 10, 2008 at 2:55 AM, Marcos Caceres
[EMAIL PROTECTED] wrote:
The content element is defined here:
http://dev.w3.org/2006/waf/widgets/#the-content
Would certainly appreciate more details about the security threat.
Thanks for the pointer. As timeless points out, this doesn't look
On Mon, Dec 8, 2008 at 9:04 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
On Sun, Dec 7, 2008 at 10:11 PM, Simon Pieters [EMAIL PROTECTED] wrote:
On Fri, 05 Dec 2008 15:53:22 +0100, Marcos Caceres
[EMAIL PROTECTED] wrote:
Moi? a personal political agenda to rid the word of
On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres
[EMAIL PROTECTED] wrote:
If authors want to use application/xml,
then they can use content src=somefile type=application/xml /
and hope for the best :)
I haven't been following the widget discussion very closely, so I
apologize if this issue is
Marcos Caceres schreef:
Moi? a personal political agenda to rid the word of
application/xhtml+xml? never! :P
^_^
Seriously speaking, the list of types is supposed to reflect what the
working group believes are the core development technologies that
underpin widgets (for version 1.0, at
Marcos Caceres schreef:
Ok, hearing no objections, then I propose we bake in the following
file extensions into the spec (we can debate which MIME types to use
after we settle on the extensions!):
.html
.htm
.css
.gif
.jpeg
.png
.js
.json
.xml
.txt
The following we should probably bake in too:
Hi Laurens,
2008/12/5 Laurens Holst [EMAIL PROTECTED]:
Marcos Caceres schreef:
Ok, hearing no objections, then I propose we bake in the following
file extensions into the spec (we can debate which MIME types to use
after we settle on the extensions!):
.html
.htm
.css
.gif
.jpeg
.png
On Fri, Dec 5, 2008 at 5:19 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Marcos Caceres wrote:
Hi Laurens,
2008/12/5 Laurens Holst [EMAIL PROTECTED]:
Marcos Caceres schreef:
Ok, hearing no objections, then I propose we bake in the following
file extensions into the spec (we can debate
On 2.12.2008 18.29, ext Marcos Caceres [EMAIL PROTECTED] wrote:
On Tue, Dec 2, 2008 at 3:19 PM, Jere Kapyaho [EMAIL PROTECTED] wrote:
snip
Yes, it's .flac (or .fla in a pinch) for FLAC.
Oh oh! .fla is a clash with Adobe flash files:(
Well, that would have been for truly legacy systems only.
On Tue, Dec 2, 2008 at 6:09 PM, Boris Zbarsky [EMAIL PROTECTED] wrote:
Marcos Caceres wrote:
That wouldn't be a problem in widgets, as we would say .css is always
text/css.
My point is that this doesn't seem like a reasonable requirement,
necessarily.
Do you have any suggestions as to
Marcos Caceres wrote:
Do you have any suggestions as to how we might move forward? Or a
different approach to solving the problem?
The problem being that a ZIP file doesn't know anything about the types
of files in it?
What Gecko does right now for jar: URIs is somewhat similar to what it
On Tue, Dec 2, 2008 at 1:42 AM, Marcos Caceres [EMAIL PROTECTED] wrote:
Ok, hearing no objections, then I propose we bake in the following
file extensions into the spec (we can debate which MIME types to use
after we settle on the extensions!):
.jpeg
you're missing .jpg which is fairly odd.
Marcos Caceres wrote on 11/29/2008 9:39 AM:
I had a discussion with Henri Sivonen and a few other people in the
HTML-WG about using HTML5's content-type sniffing as a way of deriving
the MIME type of files inside a widget package. Henri suggested that
we should primarily rely on file
On Sat, 29 Nov 2008, Bil Corry wrote:
Marcos Caceres wrote on 11/29/2008 9:39 AM:
I had a discussion with Henri Sivonen and a few other people in the
HTML-WG about using HTML5's content-type sniffing as a way of deriving
the MIME type of files inside a widget package. Henri suggested that
24 matches
Mail list logo
