On Fri, 25 Jan 2008, Christoph P�per wrote:
Simon Pieters:
It was pointed out to me that the start='' attribute (and the corresponding
DOM attribute) currently defaults to 1. This could, AFAICT, reaonably
trivially be changed to make it depend on the direction of the list and the
number
On Sun, 8 Apr 2007, 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
On Sun, 17 Feb 2008, Dave Hodder wrote:
Please consider adding the 'l' element (as found in XHTML 2).
The 'l' element can be used to break up text into separate lines, in a
similar manner to the existing 'br' element. Unlike 'br', it is a
container element; instead of pLine 1brLine 2/p,
On Wed, 23 Apr 2008 02:38:05 +0200, Jeff Walden [EMAIL PROTECTED]
wrote:
Make the targetOrigin argument non-optional. * would mean don't
care while anything else would specify an origin (or result in a syntax
error). If this is done, it's no longer possible to have
On Tue, 11 Dec 2007, Christoph P�per wrote:
2007-12-11 05:56 Ian Hickson:
On Tue, 21 Mar 2006, Christoph Paeper wrote:
Would the following be inadequate usage according to this specification?
a href=foo.imgsampimg src=foo.t.img alt=...//samp/a
Yes. The former would be
Anne van Kesteren wrote:
How is omitting the argument any less explicit than providing a * as
argument? I would prefer we keep that part of the API as is.
It's far easier to forget to provide the origin than it is to accidentally provide
*. If you omit an origin with this API, one way or
Ian Hickson wrote:
3) Documents that use the same acronym to mean different things in
different contexts/sections.
For example, take that both abbr title=United States of
AmericaUSA/abbr and abbr title=United Space AllianceUSA/abbr
previously occurred in the document, and you *don't* want,
On Wed, 23 Apr 2008 04:35:39 +0800, Aaron Leventhal [EMAIL PROTECTED]
wrote:
So how do I know if this has been registered as a pending issue that
will be fixed in the spec?
As long as the spec remains the same as the W3C HTML 5 spec you can also
ask someone to raise an issue in that
Ian Hickson:
On Tue, 19 Feb 2008, Christoph P�per wrote:
brfirst line/br
Actually it's worse, /br is actually handled as br in browsers, so
you'd end up with blank lines if we did this.
Yeah, someone already told me by now. On the other hand, there are
probably worse compatibility
On Wed, 23 Apr 2008, Christoph Päper wrote:
Ian Hickson:
On Tue, 19 Feb 2008, Christoph P�per wrote:
brfirst line/br
Actually it's worse, /br is actually handled as br in browsers, so
you'd end up with blank lines if we did this.
Yeah, someone already told me by now. On the
On Tue, 22 Apr 2008 22:35:39 +0200, Aaron Leventhal [EMAIL PROTECTED]
wrote:
I checked with Opera and they also do tabindex=-1 makes anything
focusable. So the spec is out of line with implementations.
Note that for
http://tc.labs.opera.com/html/global-attributes/tabindex/004.htm
Ian Hickson schrieb:
On Wed, 23 Apr 2008, Christoph Päper wrote:
there are probably worse compatibility issues with
older specs and browsers than extra blank lines.
Hopefully not in HTML5. :-)
Isn't wrong numbering worse?
HTML4 UA HTML5 UA
ol reversed
Christoph Päper writes:
Ian Hickson schrieb:
On Wed, 23 Apr 2008, Christoph Päper wrote:
there are probably worse compatibility issues with older specs and
browsers than extra blank lines.
Hopefully not in HTML5. :-)
Isn't wrong numbering worse?
HTML4
2008/4/23 Ian Hickson [EMAIL PROTECTED]:
Summary: I've made the title= attribute on abbr optional again.
Maybe we need a smart validator that maintains a set of abbreviations
it comes across, if an abbr with no title attribute is encountered
that isn't in the set of already seen abbreviations,
Nicholas Shanks wrote:
On Mon, 21 Apr 2008, Patrick H. Lauke wrote:
Assistive technology is certainly a valid use case here.
Why? It doesn't seem to be the case to me that people using ATs are any
less able to work out what an abbreviation is than anyone else.
I think the point is that
The range of valid datetime strings is a subset of those specified by ISO 8601.
Most of the unused formats have been rejected on the grounds of simplicity of
parsing, but a format (I think added in ISO 8601:2004, but it may have been
earlier) offers a gain in utility that would not be unduly
16 matches
Mail list logo
