Le 10 nov. 2006 à 19:16, Ian Hickson a écrit :
The difference is that will never work, because of things
like
this:
...A...
...
...which, for legacy compatibility reasons, must result in a DOM
where the
text with "A" ends
On Sat, 11 Nov 2006, Simon Pieters wrote:
>
> Point six from the list of the table element's required children[1]:
>
> A tfoot element, if there are no other tfoot elements in the table.
>
> ...should be, I think:
>
> Zero or one tfoot elements, if there are no other tfoot elements in the
>
On Fri, 10 Nov 2006, Michel Fortin wrote:
>
> And today's browsers also have problems with outside a table,
> which implies that my previously proposed markup for this:
>
>
> caption text
> ... figure content here ...
>
>
> would not work correctly in today's browsers. Bu
Hi,
Point six from the list of the table element's required children[1]:
A tfoot element, if there are no other tfoot elements in the table.
...should be, I think:
Zero or one tfoot elements, if there are no other tfoot elements in the
table.
Otherwise I read it like there must be a tfo
Le 10 nov. 2006 à 14:19, Alexey Feldgendler a écrit :
On Fri, 10 Nov 2006 23:47:05 +0600, Steve Runyon
<[EMAIL PROTECTED]> wrote:
Couldn't we extend the element to work for images as well
as form
elements? The for attribute would provide the explicit link to
the image
that would take th
Henri Sivonen a écrit :
WF 2.0 says: "Implementations and documents must comply to the W3C
Character Model specification. [CHARMOD]"
WA 1.0 says no such thing. Is that intentional?
I hope not!
Does C003 in Charmod outlaw bdo?
Nope. bdo is simply an assertion by the author that the presen
Regarding the idea of a hashing feature for downloads:
* I don't see why this idea should be in HTML rather than doing it the
way that the many, many existing solutions do it.
* I don't see why this idea would work anyway. All the proposed UIs have
obvious and fatal flaws.
Both of the
On Fri, 10 Nov 2006 23:47:05 +0600, Steve Runyon <[EMAIL PROTECTED]>
wrote:
Couldn't we extend the element to work for images as well as form
elements? The for attribute would provide the explicit link to the image
that would take the label's contents out-of-stream for screen readers,
and
Elliotte Harold wrote:
Jeff Seager wrote:
A better way would be to semantically attach the caption or cutline to
the image itself, so its display is paired naturally. In this way, the
width of the cutline would be dictated (unless overruled in the
stylesheet) by the width of the image. I'm su
On Nov 10, 2006, at 02:12, fantasai wrote:
Henri Sivonen wrote:
On Oct 27, 2006, at 16:21, Anne van Kesteren wrote:
On Fri, 27 Oct 2006 15:17:16 +0200, Lachlan Hunt
<[EMAIL PROTECTED]> wrote:
That's fine for document conformance, but what about how
browsers will handle it? Is the spec stil
Hi all,
I'm brand new to the list, so apologies if this idea has already been discussed or I'm missing the point
Couldn't we extend the element to work for images as well as form elements? The for attribute would provide the explicit link to the image that would take the label's contents
Elliotte Harold wrote:
Given that, I suspect we're probably better off just using regular
paragraphs in text with appropriate CSS instructions rather than
introducing a new element.
I strongly disagree. The caption is intrinsically linked to the image and, by
making this relationship explici
On Fri, 10 Nov 2006 01:57:19 +0600, Jeff Seager <[EMAIL PROTECTED]>
wrote:
A better way would be to semantically attach the caption or cutline to
the image itself, so its display is paired naturally. In this way, the
width of the cutline would be dictated (unless overruled in the
stylesheet) b
Jeff Seager wrote:
A better way would be to semantically attach the caption or cutline to
the image itself, so its display is paired naturally. In this way, the
width of the cutline would be dictated (unless overruled in the
stylesheet) by the width of the image. I'm suggesting that CAPTION be
Jeff Seager wrote:
What's clearly missing from the IMG specification is an appropriate
means for pairing each picture or graphic with a caption. Neither ALT
nor LONGDESC is appropriate for this. My current solution, borrowed from
Darren Brierton of Vancouver (
http://www.dzr-web.com/people/da
I finally got around making the following simple tool:
http://html5.org/tools/specification-diff
It's a small Python script that lets you generate unix diffs of Web
Applications 1.0. There's a form where you can enter two numbers. An
example would be:
http://html5.org/tools/specification-
Ian Hickson wrote:
"The file you have downloaded has been corrupted or tampered with."
"It works when I use IE but when I use Camari, it says that the file has
been corrupted." "Oh man, I'm not using Camari then! I don't need my music
to get corrupted!"
Yes, yes. I don't think it's impossibl
XcomCoolDude wrote:
How about a hash attribute for all elements that link to external files
(a, img, etc.)?
It would allow you to pass an MD5, SHA-1, SHA-256, or other hash to a
user-agent for automatic comparison with the linked file.
A related proposal is:
http://www.gerv.net/security/link
Michel Fortin wrote:
Sometime, presentational information is needed to display a document
correctly, and in those few cases where the presentation is tied to the
content, I think it belongs in the markup. The align attribute, when
used on table cells, covers one of those cases.
I think that
Henri Sivonen wrote:
On Oct 27, 2006, at 16:21, Anne van Kesteren wrote:
On Fri, 27 Oct 2006 15:17:16 +0200, Lachlan Hunt
<[EMAIL PROTECTED]> wrote:
That's fine for document conformance, but what about how browsers
will handle it? Is the spec still going to require browsers to
render overlap
On Thu, 9 Nov 2006, Gervase Markham wrote:
> Ian Hickson wrote:
> > If the idea is that UAs that implement this would stop you from using the
> > file if the checksum didn't match, then this would just cause users to use
> > browsers _without_ this feature to download files, since those browsers
>
On Nov 6, 2006, at 15:44, Alexey Feldgendler wrote:
On Sun, 05 Nov 2006 03:32:55 +0600, Henri Sivonen <[EMAIL PROTECTED]>
wrote:
It's not only about printing-while-downloading. It's about the
ability to print an arbitrarily long document without consuming
infinite memory for DOM.
What k
Title: The IMG element, proposing a CAPTION attribute
In response to the standards now being considered, I'm in favor of allowing percentages for the WIDTH attribute. In my own work, I've tried first to create a flexible layout that is (in roughly equal parts) semantically correct, scalable a
On Nov 9, 2006, at 17:19, Alexey Feldgendler wrote:
On Thu, 09 Nov 2006 17:18:46 +0600, Henri Sivonen <[EMAIL PROTECTED]>
wrote:
Do you mean moving all TFOOTs after TBODYs, so that the HTML 4.01
placement would be forbidden?
TFOOT should be allowed before TBODY because it helps progessive
Lachlan Hunt wrote:
scope="" will probably only be allowed for THs. Maybe it should be
REQUIRED for THs that aren't in obvious locations (first row, first
column, or whatever).
Maybe. I think the spec should explicitly define how to determine which
header cells are associated with each cel
On 11/7/06, Alexey Feldgendler <[EMAIL PROTECTED]> wrote:
On Tue, 07 Nov 2006 15:39:56 +0600, Anne van Kesteren
<[EMAIL PROTECTED]> wrote:
> The definition of downloading a resource must be clear that even if the
> resource does not need to be downloaded (because it has been cached or
> somethin
WF 2.0 says: "Implementations and documents must comply to the W3C
Character Model specification. [CHARMOD]"
WA 1.0 says no such thing. Is that intentional?
Does C003 in Charmod outlaw bdo?
(C013 is enforceable. So is C023.)
(C001, C002, C054 and C076 are not machine-enforceable as far as I
On Nov 9, 2006, at 13:18, Henri Sivonen wrote:
Not deployed yet.
The table integrity checker is now part of all (X)HTML presets at
http://hsivonen.iki.fi/validator/
There's a pseudo-schema called http://hsivonen.iki.fi/checkers/table/
which isn't a schema but a magic URL that causes the sys
On Fri, 10 Nov 2006 00:36:20 +0600, Henri Sivonen <[EMAIL PROTECTED]> wrote:
>>> Do you mean moving all TFOOTs after TBODYs, so that the HTML 4.01
>>> placement would be forbidden?
>> TFOOT should be allowed before TBODY because it helps progessive
>> rendering on paged media. I'm not sure if it
Ian Hickson wrote:
If the idea is that UAs that implement this would stop you from using the
file if the checksum didn't match, then this would just cause users to use
browsers _without_ this feature to download files, since those browsers
wouldn't complain about data corruption. "It works when
Michel: Actually, hash is the proper term. Checksums are much simpler, and are used only for checking against accidental modifications, whereas cryptographic hash functions are used to protect against malicious tampering. See http://en.wikipedia.org/wiki/Checksum.Ian: I imagine most user-agents wou
On Fri, 10 Nov 2006 00:57:41 +0600, Henri Sivonen <[EMAIL PROTECTED]> wrote:
>> TeX uses repeated passes over a long document to handle cross-
>> references properly using limited memory. It would be useful if
>> HTML allowed something like that.
> I see streaming bounded-memory operation and mul
32 matches
Mail list logo
