On Wed, 6 Aug 2008, Simon Pieters wrote:
> On Wed, 06 Aug 2008 22:06:33 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
> >
> > is probably the right element for this. You can use fallback
> > content in the element to show text in legacy browsers that
> > don't support HTML5.
> >
> > [mpt wrote
On Wed, 06 Aug 2008 22:42:09 +0200, Simon Pieters <[EMAIL PROTECTED]> wrote:
Validators can still issue warnings to help with aspect ratio mistakes
without putting up a road block for authors trying to migrate to HTML5.
Moreover, currently the spec bans this, which seems legitimate enough:
On Wed, 06 Aug 2008 22:06:33 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Wed, 30 Jul 2008, Matthew Paul Thomas wrote:
>
> I'm not sure that this usage of is one that the spec today
> considers valid. Wouldn't be the better way to do this?
Indeed it wouldn't, because wouldn't work in w3
On Wed, 30 Jul 2008, Matthew Paul Thomas wrote:
> >
> > I'm not sure that this usage of is one that the spec today
> > considers valid. Wouldn't be the better way to do this?
>
> Indeed it wouldn't, because wouldn't work in w3m at all!
Yeah, you're right, wouldn't work particularly well for t
Ian Hickson wrote on 30/07/08 04:08:
>
> On Sun, 14 Oct 2007, Matthew Paul Thomas wrote:
>>
>> On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote:
>>>
>>> I don't think "If both attributes are specified, then the ratio of
>>> the specified width to the specified height must be the same as the
>>>
Kristof Zelechovski writes:
> The element you are describing is effectively a progress bar control.
> It is still not present in HTML
HTML 5 introduces for that:
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html#the-progress
Smylers
. This has the disadvantage of being irrelevant
to screen readers.
HTH,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Wednesday, July 30, 2008 5:08 AM
To: Matthew Paul Thomas
Cc: WHATWG
Subject: Re: [whatwg] element comments
On
On Sun, 14 Oct 2007, Matthew Paul Thomas wrote:
> On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote:
> >
> > I don't think "If both attributes are specified, then the ratio of the
> > specified width to the specified height must be the same as the ratio
> > of the logical width to the logical heig
On Sat, 13 Oct 2007, Henri Sivonen wrote:
> On Oct 13, 2007, at 01:55, Ian Hickson wrote:
> > On Tue, 7 Nov 2006, Henri Sivonen wrote:
> > > So I think width and height should not have conformance requirements
> > > tied to pixel dimensions of the references image file. They are
> > > presentatio
On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote:
...
I don't think "If both attributes are specified, then the ratio of the
specified width to the specified height must be the same as the ratio
of the logical width to the logical height in the image file." solves
any real problem given what b
On Oct 13, 2007, at 01:55, Ian Hickson wrote:
On Tue, 7 Nov 2006, Henri Sivonen wrote:
So I think width and height should not have conformance requirements
tied to pixel dimensions of the references image file. They are
presentational, but they are such a useful presentational
optimization
t
On Sat, 4 Nov 2006, Anne van Kesteren wrote:
> On Sat, 04 Nov 2006 07:37:32 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > >
> > > * It should probably mention 'img.src = foo' (that loading directly
> > > starts). I thought that 'img.setAttribute("src", foo)' even did
> > > different things in
this, but I wonder if the list can be
pruned with the expiration of the GIF patents.]
BdG
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt
Sent: Thursday, 2007 August 16 00:06
To: Ian Hickson
Cc: WHATWG
Subject: Re: [whatwg] element comments
Ian Hickson wrote:
On Sat, 4 Nov 2006, Lachlan Hunt wrote:
And, as I mentioned in IRC, I think it should be defined that the value
should resolve to a valid URI for an image, so that
isn't conforming, except in this rare case:
Ok but... what's an image? Do we exclude PDFs and SVG? (Safari
Hi,
Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and
Opera
respectively support those.)
snip
As Simon asked on IRC, who are we helping by limiting what's allowed?
Displaying PDF is great for company web-apps (mine uses it
extensively, saving us lots of time).
B
At 10:48 + 15/08/07, Ian Hickson wrote:
> > > * I would also suggest to put "If the src attribute is omitted,
> > there is no alternative image representation." after the last
> > statement on the alt attribute.
>
> Done. (I think. I edited a bunch of stuff before reading your comment
On Sat, 4 Nov 2006, Lachlan Hunt wrote:
> Ian Hickson wrote:
> > On Fri, 3 Nov 2006, Anne van Kesteren wrote:
> > > * It should probably mention 'img.src = foo' (that loading directly
> > > starts). I thought that 'img.setAttribute("src", foo)' even did different
> > > things in browsers (when the
Le 7 nov. 2006 à 14:28, Greg Kilwein a écrit :
Also, if only one of either the "width" or "height" attributes is
set, some browsers will scale the other dimension automatically.
Consider this example:
Some browsers will scale height to be 25 in this instance, given an
image with a widt
Andreyka Lechev wrote:
On 07.11.2006, at 19:49, Shadow2531 wrote:
On 11/7/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
I thought the proposal was that only that (setting height and width
to the
intrinsic size of the image) would be conforming, but that rendering
would
still be the same.
On 07.11.2006, at 19:49, Shadow2531 wrote:
On 11/7/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
I thought the proposal was that only that (setting height and
width to the
intrinsic size of the image) would be conforming, but that
rendering would
still be the same.
[encouraged if you
On 11/7/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
I thought the proposal was that only that (setting height and width to the
intrinsic size of the image) would be conforming, but that rendering would
still be the same.
Yeh, in example method, this is the suggestion:
(at least from what I
On Nov 4, 2006, at 08:37, Ian Hickson wrote:
I'm thinking of only allowing integer values, and requiring them to be
equal to the dimensions of the image, if present (and requiring
both to
be present if either is present). Would people be ok with that?
Suppose there are desktop systems in th
Anne van Kesteren wrote:
On Tue, 07 Nov 2006 03:49:40 +0100, Matthew Paul Thomas
<[EMAIL PROTECTED]> wrote:
In 1998 I used a version of iBrowse for the Amiga that treated
width= and height= in the way Ian proposed -- as preliminary advice on
the dimensions of the image, reflowing if the actual
On Tue, 07 Nov 2006 03:49:40 +0100, Matthew Paul Thomas
<[EMAIL PROTECTED]> wrote:
In 1998 I used a version of iBrowse for the Amiga that treated
width= and height= in the way Ian proposed -- as preliminary advice on
the dimensions of the image, reflowing if the actual dimensions turned
ou
[re. width= and height=]
On Nov 4, 2006, at 9:01 AM, Alexey Feldgendler wrote:
On Sat, 04 Nov 2006 12:37:32 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
...
I'm thinking of only allowing integer values, and requiring them to be
equal to the dimensions of the image, if present (and requiring
Le 5 nov. 2006 à 7:42, Elliotte Harold a écrit :
There are always edge cases. The distinction between semantics and
presentation is a fuzzy one. Nonetheless, I think most of the time
height and width as specified on today's img tags are clearly
presentational.
I'm beginning to get lost in
Lachlan Hunt wrote:
Using attributes to describe actual metadata about an image that has
real practical benefits, for both the author and user, is not
presentational in my view.
Yes, but that is not what the height and width attributes are. They say
nothing about the image and everything abo
Matthew Raymond wrote:
Lachlan Hunt wrote:
I disagree. Specifying the size is very good for incremental rendering,
but the alternatives are awful.
1.
The style attribute is far more presentational than the height and width
attributes.
I don't see how either is more or less presentatio
Lachlan Hunt wrote:
> I disagree. Specifying the size is very good for incremental rendering,
> but the alternatives are awful.
>
> 1.
>
> The style attribute is far more presentational than the height and width
> attributes.
I don't see how either is more or less presentational. The |hei
On Sat, 04 Nov 2006 22:27:18 +0100, Matthew Raymond
<[EMAIL PROTECTED]> wrote:
Right. There can be differences between the initial value of an
attribute contained in markup and the instantaneous value in the DOM,
such as the case with or ,
That's .defaultValue and .defaultSelected respecti
Lachlan Hunt wrote:
> Ian Hickson wrote:
>> On Fri, 3 Nov 2006, Anne van Kesteren wrote:
>>> * It should probably mention 'img.src = foo' (that loading directly
>>> starts). I thought that 'img.setAttribute("src", foo)' even did
>>> different things in browsers (when the element is not yet insert
On Sat, 04 Nov 2006 19:43:02 +0600, Spartanicus
<[EMAIL PROTECTED]> wrote:
The problem with allowing omission of alt depends on the meaning of
without alt. If without alt is defined to mean the same as
with alt="", then the problem is that all cases when people omit
the alt attribute b
On Sat, 04 Nov 2006 12:42:34 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
If without alt is defined to mean that the image is semantically
valuable but without an alternative text, then the problem is that we
need to distinguish between empty and omitted alt in DOM somehow.
That's easy enou
On Sat, 04 Nov 2006 12:37:32 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
* The height and width attributes as defined are completely
presentational. I don't really see any value in keeping them. Now I
suppose they have to be supported anyway, but so does .
I'm thinking of only allowing inte
On Fri, 03 Nov 2006 19:38:37 +0600, Anne van Kesteren
<[EMAIL PROTECTED]> wrote:
>> * Regarding the alt attribute, wouldn't it make sense to just allow it to
>> be omitted? In terms of meaning it seems the same.
I have always considered requiring the alt attribute resulting in the
use of alt="" a
Matthew Raymond <[EMAIL PROTECTED]> wrote:
>Michel Fortin wrote:
>> Except that, contrary to bgcolor, the height and width attributes can
>> help solve a real problem: page jiggling while the images loads. It's
>> somewhat like the type="image/jpg" attribute you can set for links:
>> it giv
Ian Hickson <[EMAIL PROTECTED]> wrote:
[width and height attribute on the element]
>I'm thinking of only allowing integer values, and requiring them to be
>equal to the dimensions of the image, if present (and requiring both to
>be present if either is present). Would people be ok with that?
On Nov 4, 2006, at 08:37, Ian Hickson wrote:
I'm thinking of only allowing integer values, and requiring them to be
equal to the dimensions of the image, if present (and requiring
both to
be present if either is present). Would people be ok with that?
What about non-square pixels in the ima
>> * The height and width attributes as defined are completely
>> presentational. I don't really see any value in keeping them. Now I
>> suppose they have to be supported anyway, but so does .
I disagree. Specifying the size is very good for incremental rendering,
but the alternatives are awful.
On Sat, 04 Nov 2006 07:37:32 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
* It should probably mention 'img.src = foo' (that loading directly
starts). I thought that 'img.setAttribute("src", foo)' even did
different things in browsers (when the element is not yet inserted into
the document) so r
Ian Hickson wrote:
On Fri, 3 Nov 2006, Anne van Kesteren wrote:
* It should probably mention 'img.src = foo' (that loading directly
starts). I thought that 'img.setAttribute("src", foo)' even did
different things in browsers (when the element is not yet inserted into
the document) so reflect m
On Fri, 3 Nov 2006, Alexey Feldgendler wrote:
>
> > * Regarding the alt attribute, wouldn't it make sense to just allow it
> > to be omitted? In terms of meaning it seems the same. On the other
> > hand, it probably shows the difference between people who thought of
> > the alternative represen
On Fri, 3 Nov 2006, Anne van Kesteren wrote:
>
> * I think the section on the element should also define 'new
> Image([width [, height]])' which effectively returns an HTMLImageElement
> object in current browsers.
Done.
> * It should probably mention 'img.src = foo' (that loading directly
Michel Fortin wrote:
> Except that, contrary to bgcolor, the height and width attributes can
> help solve a real problem: page jiggling while the images loads. It's
> somewhat like the type="image/jpg" attribute you can set for links:
> it gives advance information on what the external conten
Le 3 nov. 2006 à 8:38, Anne van Kesteren a écrit :
* The height and width attributes as defined are completely
presentational. I don't really see any value in keeping them. Now I
suppose they have to be supported anyway, but so does bgcolor="">.
Except that, contrary to bgcolor, the height
On Fri, 03 Nov 2006 19:38:37 +0600, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> * Regarding the alt attribute, wouldn't it make sense to just allow it to
> be omitted? In terms of meaning it seems the same. On the other hand, it
> probably shows the difference between people who thought of the
Some points:
* I think the section on the element should also define 'new
Image([width [, height]])' which effectively returns an HTMLImageElement
object in current browsers.
* It should probably mention 'img.src = foo' (that loading directly
starts). I thought that 'img.setAttribute("sr
47 matches
Mail list logo
