On Mon, 10 Nov 2008 11:51:34 +0100, Tommy Thorsen [EMAIL PROTECTED]
wrote:
I noticed that, according to the html5 algorithm, when the parser sees a
title start tag when in the in body insertion mode, it's not
supposed to relocate it to the head element. Opera matches this
behaviour, but
Simon Pieters wrote:
The description of the title element in the spec (4.2.2 The title
element) says:
Contexts in which this element may be used:
In a head element containing no other title elements.
I don't care very strongly about whether or not title elements are
allowed
On Mon, 10 Nov 2008 15:31:48 +0100, Tommy Thorsen [EMAIL PROTECTED]
wrote:
Simon Pieters wrote:
The description of the title element in the spec (4.2.2 The title
element) says:
Contexts in which this element may be used:
In a head element containing no other title elements.
I
On Sun, Nov 9, 2008 at 8:10 PM, Eduard Pascual [EMAIL PROTECTED] wrote:
I can't say for sure if this is an issue from the spec document
itself, or just a rendering bug on my browser (FF 3.0.3), but here it
goes:
Within the section 4.3.1 The script element, on the algorythm
labeled Running a
I noticed that, according to the html5 algorithm, when the parser sees a
title start tag when in the in body insertion mode, it's not
supposed to relocate it to the head element. Opera matches this
behaviour, but Firefox moves any title tag it finds into the head element.
The description of
On Mon, 10 Nov 2008, Tommy Thorsen wrote:
I don't care very strongly about whether or not title elements are
allowed anywhere, but I do think the output of the parsing algorithm
should be valid html according to the rest of the spec. So, in my
opinion, we need to change either the allowed
On Mon, Nov 10, 2008 at 2:57 PM, Pentasis [EMAIL PROTECTED] wrote:
Hi,
I seem to have a few problems here, but nothing I cannot handle. For some
reason I get my e-mails later than I should and they are working on the
electricity grid here, so I have no power during the day (only at night).
Paul Arzul wrote:
we could use the Default style sheet for HTML 4:
http://www.w3.org/TR/CSS21/sample.html
That style sheet is purported to be both descriptive and prescriptive (read
the prelude carefully, and you'll see how messed-up it is). In reality, it
is neither. No browser implements
On Mon, 10 Nov 2008, Eduard Pascual wrote:
I can't say for sure if this is an issue from the spec document
itself, or just a rendering bug on my browser (FF 3.0.3), but here it
goes:
Within the section 4.3.1 The script element, on the algorythm
labeled Running a script, step 6, the text for
In the handler for 'A start tag whose tag name is li' in in body,
the algorithm says jump to the last step in a couple of places. Is
the last step step 5, or is it the final unnumbered step which says,
Finally, insert an HTML element for the token?
I suggest, to make this clearer, that we
On 10/3/08 4:37 PM, Oliver Hunt wrote:
thinking out loud
Just had a thought (no idea how original) -- how about if fillStyle were
able to accept a 3 or 4 number array? eg. fillStyle = [0, 0.3, 0.6, 1.0] ?
That might work well if people are using arrays as vectors/colours
/thinking out loud
I
On Nov 6, 2008, at 12:32 AM, Eduard Pascual wrote:
...
Initially, HTML was entirely structural: no presentation, and no
semantics. Just paragraphs, headings, anchors, and few other things.
...
The earliest surviving HTML draft from 1992 includes the PLAINTEXT
and LISTING elements, both
On Tue, 15 Jul 2008, Csaba Gabor wrote:
It is frequently the case that SELECT elements of size 1 (drop downs) are
quite long, requiring scrolling to reach most of the options. For example:
Year a person was born in
States of the US
Countries of the world
Height (in inches or cm)
This
On Wed, 5 Nov 2008, Oldřich Vetešník wrote:
It would be awesome if something like this would be possible:
label for=idfieldInstructions/label
input name=idfield id=idfield
error for=idfieldMust be a valid value/error
You can use output for this purpose at this point.
And to further
On Tue, 29 Jul 2008, Garrett Smith wrote:
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
On Thu, 14 Aug 2008, Garrett Smith wrote:
There is no note in the WF 2.0 specification, nor the HTML 4.01, nor the
HTML DOM specifications that an element should not be named submit or
action to avoid such consequences. Was this considered?
I don't think we want to limit these names, since
On Wed, 30 Jul 2008, Tab Atkins Jr. wrote:
I did some searching through the archives, but didn't find anything at
all that talked about this. Out of curiousity, was there a reason that
datetime doesn't store/send it's value as a unix timestamp? True, the
standard unixtime unit is
On Mon, Nov 10, 2008 at 8:46 PM, Matthew Paul Thomas [EMAIL PROTECTED] wrote:
The earliest surviving HTML draft from 1992 includes the PLAINTEXT and
LISTING elements, both entirely presentational.
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html
PLAINTEXT was aimed to
Should video and audio elements be able to load and play resources from
other origins?
Perhaps Ian thinks not:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
There's a to-and-fro discussion here:
http://lists.xiph.org/pipermail/theora/2008-November/001931.html
Jonas got involved here:
On Nov 10, 2008, at 6:50 PM, Robert O'Callahan wrote:
Should video and audio elements be able to load and play
resources from other origins?
Perhaps Ian thinks not:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
There's a to-and-fro discussion here:
On 10-Nov-08, at 7:49 PM, Maciej Stachowiak wrote:
1) Allow unrestricted cross-origin video/audio
2) Allow cross-origin video/audio but carefully restrict the
API to limit the information a page can get about media loaded
from a different origin
3) Disallow cross-origin video/audio unless
21 matches
Mail list logo
