Here's a page I constructed, and tested on Firefox:
http://intertwingly.net/stories/2007/04/10/test.html
This page is meant to be served as application/xhtml+xml.
Can you test it and see what results you get? Then lets discuss further.
In Safari 2.0.4: Processed as HTML, it says data and
On Apr 9, 2007, at 10:27 AM, Maciej Stachowiak wrote:
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
For the case of a bitstream format change, there is version
information
in the header of a theora bitstream. Major and minor version numbers
are being used similarly to the way that *nix library version numbers
work - anything with a minor change is backwards compatible, but a
major change
This topic came up on #html-wg today.
Mail.app and other mail clients don't put alt attributes on images
generated in email. They could add alt=, but there are two reasons
it might be better to allow no alt attribute at all, at least for
email clients.
1) A mail message is often sent to
On Apr 10, 2007, at 11:42 PM, Jonas Sicking wrote:
Here's a page I constructed, and tested on Firefox:
http://intertwingly.net/stories/2007/04/10/test.html
This page is meant to be served as application/xhtml+xml.
Can you test it and see what results you get? Then lets discuss
further.
I think the correct fallback for a photograph for its own sake is alt=(Use
a browser that supports graphic images to view).
The problem is that such images usually have an independent caption that is
visible with alongside the image. Specifying a description of the content
of the image as the
On Apr 11, 2007, at 2:01 AM, Kristof Zelechovski wrote:
I think the correct fallback for a photograph for its own sake is
alt=(Use
a browser that supports graphic images to view).
If you really want to be anal about the spec, I don't think this
would truly represent text with an
Kristof Zelechovski wrote:
I think the correct fallback for a photograph for its own sake is alt=(Use
a browser that supports graphic images to view).
Not much use to a blind user, for example. (Of course arguably flickr as a whole
isn't much use to a blind user but that alt text still seems
Maciej Stachowiak wrote:
On Apr 10, 2007, at 8:12 PM, Sam Ruby wrote:
Maciej Stachowiak wrote:
On Apr 10, 2007, at 2:14 PM, Sam Ruby wrote:
Anne van Kesteren wrote:
On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby
[EMAIL PROTECTED] wrote:
How so?
I missed the part where you wanted to change
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
Per HTML5 section 8.1.2.3, however, such an attribute name would not be
considered conformant.
Yes, only attributes defined in the specification are conformant.
Despite this, later in document, in the description of
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
To give a specific example: say I make my own mjsml prefix with
namespace http://example.org/mjsml;. In HTML4 UAs, to look up an
mjsml:extension attribute using getAttribute(mjsml:extension). In
HTML5 UAs, I'd have to
Anne van Kesteren wrote:
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
Per HTML5 section 8.1.2.3, however, such an attribute name would not
be considered conformant.
Yes, only attributes defined in the specification are conformant.
I was specifically referring to
On Wed, 11 Apr 2007 13:53:21 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
Per HTML5 section 8.1.2.3, however, such an attribute name would not
be considered conformant.
Yes, only attributes
Anne van Kesteren wrote:
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
To give a specific example: say I make my own mjsml prefix with
namespace http://example.org/mjsml;. In HTML4 UAs, to look up an
mjsml:extension attribute using getAttribute(mjsml:extension).
In
Anne van Kesteren wrote:
On Wed, 11 Apr 2007 13:53:21 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
Per HTML5 section 8.1.2.3, however, such an attribute name would not
be considered conformant.
Yes,
On Wed, 11 Apr 2007 14:15:15 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
To give a specific example: say I make my own mjsml prefix with
namespace http://example.org/mjsml;. In HTML4 UAs, to look up
On Wed, 11 Apr 2007 14:15:19 +0200, Sam Ruby [EMAIL PROTECTED]
wrote:
[...]
Like others, I'm not convinced that the way forward is to allow a new
attribute which has a micro-grammar for parsing what would be
represented in the DOM essentially as a character blob.
That's fine. I'm merely
If you want structured data in this attribute, why not just use JSON?
That's an idea that crossed my mind as well. I dismissed it for a few
reasons:
- authors would have to entitize quotes and ampersands in their attributes,
which they're not used to doing with JSON normally.
- evaluating it
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
- Geoffrey Sneddon
Anne van Kesteren wrote:
I think I'd rather have something simple such as
prefix_name for extensions made by ECMAScript libraries, etc. (As
opposed to an in scope xmlns:prefix=http://...; with prefix:name
extensions which work differently in XML.) That would also work better
for element
Geoffrey Sneddon wrote:
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
I would be rather surprised if that were true, given that Firefox
doesn't do it and I've
Gervase Markham wrote:
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
I would be rather surprised if that were true, given that Firefox
doesn't do it and I've
On 11/04/07, Gervase Markham [EMAIL PROTECTED] wrote:
Geoffrey Sneddon wrote:
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
I would be rather surprised if that
At 3:13 PM +0100 UTC, on 4/11/07, Gervase Markham wrote:
Geoffrey Sneddon wrote:
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
I would be rather surprised if
On Wed, 11 Apr 2007 18:38:11 +0200, Jon Barnett [EMAIL PROTECTED]
wrote:
Is this more the realm of an RFC (3986 and 3987) instead of HTML5?
Jon Barnett
Probably, unless you restrict the special handling to a few HTML
attributes.
--
Anne van Kesteren
http://annevankesteren.nl/
Kristof Zelechovski wrote:
I think the correct fallback for a photograph for its own sake is alt=(Use
a browser that supports graphic images to view).
That is basically what happens if you omit the alt attribute altogether.
My graphical browsers (when I turn off images) write Image in place
Kristof Zelechovski wrote:
(as client side Lisp is my personal dream)
http://www.cs.stevens.edu/~dlong/software/kamen/index.php
-dean
On 4/10/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:
Kevin Marks wrote:
I think the dialog example is a retrograde step. The
olliciteq|blockquote pattern seems much better than redefining
dt and dd, which will confuse XOXO parsers that try to be
Postelian. Did I miss some reasoning
On 4/11/07, Jon Barnett [EMAIL PROTECTED] wrote:
If you want structured data in this attribute, why not just use JSON?
That's an idea that crossed my mind as well. I dismissed it for a few
reasons:
- authors would have to entitize quotes and ampersands in their attributes,
which they're not
On Wed, 11 Apr 2007 15:13:09 +0100, Gervase Markham [EMAIL PROTECTED]
wrote:
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
I would be rather surprised if that
On 4/11/07, Jon Barnett [EMAIL PROTECTED] wrote:
On 4/11/07, Kevin Marks [EMAIL PROTECTED] wrote:
On 4/11/07, Jon Barnett [EMAIL PROTECTED] wrote:
If you want structured data in this attribute, why not just use JSON?
That's an idea that crossed my mind as well. I dismissed it for a
Hi,
I apologize if I've missed this in the specification or mailing
archives, but I have a suggestion related to standardizing web
archives in HTML5. Currently, I know that Firefox uses Mozilla
Archive Format (.maf), Internet Explorer and Opera use MIME HTML
(.mht) and Safari uses its
On Wed, 2007-04-11 at 11:13 -0700, Kevin Marks wrote:
My point is that this is breaking the expected containment of dtdd
in a dl- if you want a new structure purely for dialog, define
speaker and keep q. I really fail to see why redefining a
definition list as speech is less 'proper' than
On Wed, 11 Apr 2007 14:02:39 +0100, Geoffrey Sneddon
[EMAIL PROTECTED] wrote:
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
I think it can be added.
RFC 1738
On Apr 11, 2007, at 16:04, Sam Ruby wrote:
1) re: prefix_name - how are prefixes registered? Henri is free
to correct me if I am wrong, but I gathered that the requirement
was for a bit of decentralized extensibility, i.e., the notion that
anybody for any reason could defined an extension
On 4/11/07, Tyler Keating [EMAIL PROTECTED] wrote:
Hi,
I apologize if I've missed this in the specification or mailing
archives, but I have a suggestion related to standardizing web
archives in HTML5. Currently, I know that Firefox uses Mozilla
Archive Format (.maf), Internet Explorer and Opera
On 11-Apr-07, at 4:17 PM, Michael A. Puls II wrote:
On 4/11/07, Tyler Keating [EMAIL PROTECTED] wrote:
Hi,
I apologize if I've missed this in the specification or mailing
archives, but I have a suggestion related to standardizing web
archives in HTML5. Currently, I know that Firefox uses
On Apr 11, 2007, at 6:04 AM, Sam Ruby wrote:
Anne van Kesteren wrote:
I think I'd rather have something simple such as prefix_name for
extensions made by ECMAScript libraries, etc. (As opposed to an in
scope xmlns:prefix=http://...; with prefix:name extensions which
work differently in
Michael A. Puls II wrote:
It's a really good way to archive, but IE won't handle it and most
plug-ins don't accept data URIs, so there are problems with that
use-case. (unless browsers can help with that in a secure way.)
I made a suggestion about this on the Opera forums a while ago when
Opera
Le 12 avr. 2007 à 05:24, Tyler Keating a écrit :
I apologize if I've missed this in the specification or mailing
archives, but I have a suggestion related to standardizing web
archives in HTML5.
The work has been already started
See Widgets 1.0 Requirements
http://www.w3.org/TR/WAPF-REQ/
At 12:12 +1000 11/04/07, Silvia Pfeiffer wrote:
On 4/11/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Wouldn't it be simpler to use video/ogg and audio/ogg as the base
types here? That would already tell you the intended disposition.
Please note that rfc4281 also mentions the problem that
I wrote some code to split the WA1 spec into more easily digestible
pieces, and Hixie set it up to produce
http://www.whatwg.org/specs/web-apps/current-work/multipage/ -
hopefully this is useful for people.
The filenames are not incredibly stable (since they come from
autogenerated IDs in the
On 4/11/07, Lachlan Hunt [EMAIL PROTECTED] wrote:
Michael A. Puls II wrote:
It's a really good way to archive, but IE won't handle it and most
plug-ins don't accept data URIs, so there are problems with that
use-case. (unless browsers can help with that in a secure way.)
I made a suggestion
43 matches
Mail list logo
