On Tue, 06 Mar 2007 14:40:51 +0100, Elliotte Harold
<[EMAIL PROTECTED]> wrote:
I don't think we need a novideo element. This would work:
Complete marked up transcript of the video.
Yup, that was also in the proposal, fwiw.
--
Anne van Kesteren
<http://anne
t the height
and width attributes of the ImageData object you get back.
Maybe putImageData() should throw a TYPE_MISMATCH_ERR for non ImageData
objects as first argument? Similar to drawImage()...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
uot; attribute on the remove / move-up /
move-down controls (thanks Simon for the bug report!).
Species:
Count:
Delete
Move Up
Move Down
Add Species
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
tities that haven't really been sorted out yet...
Personally I'd just give everyone HTML unless they specifically ask for
XML and even then those tools should be capable of handling HTML imo.
After all, it's the exchange format of the web.
--
Anne van Kesteren
<http://an
sing oddity I don't really get this point.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
t
there) and changing that now is impossible given how many authors got XML
as text/html "completely wrong".
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
ually can't
use entities, but then you can because they have some build in knowledge
for certain DOCTYPEs... However, this is not guaranteed to be cross
browser.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
, but since it's
very unlikely that Internet Explorer will support that for a long time,
and since HTML5 is backward compatible with HTML4, the HTML5 DOCTYPE
might be a much better option.
Yeah, I suppose that could work. FYI: my site is still .nl:
http://annevankesteren.nl/2004/06/standard-
st, I was not expecting an attribute
named "autocomplete" to have a security meaning... My bad, and sorry
for the spam.
Historical reasons...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
. If I recall correctly parsing-wise it's possible to let contain
block level elements. That's being considered now to cater for those use
cases.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
a link target much like in HTML4.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
reases scrapability/accessibility. is one supposed to just wrap
canvas polygons in s or something?
What does ... not offer that href="">... does? And if this is in fact an application you might
actually want to have the as fallback of the along with other
content...
--
Anne
not a moving target. However, given that other
interpreting software, such as web browsers, do change, maybe conformance
should too.)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
e's no plan for that to change.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
;t actually see
bar or turn it off...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
laying something, but you can't actually
see bar or turn it off...
bar shouldn't start playing in that case, should it?
Not sure. Should
show a modal dialog?
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
"/bar" />
I suppose xml:base="" should affect href="". That would make it consistent
with
at least. Interesting sample.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Mon, 12 Mar 2007 01:01:38 +0100, Matthew Ratzloff
<[EMAIL PROTECTED]> wrote:
On Sun, March 11, 2007 3:20 pm, Anne van Kesteren wrote:
There needs to be versioning? The web has done great so far without
it... I'm not sure I really see the need.
The Web has done great so far
On Wed, 14 Mar 2007 10:17:48 +0100, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
They don't conflict. They are both applied. is the document's
base URI, and xml:base is the base URI of the element it is applied on.
What about:
http://www.example.org/"; xml:base=
|
test |
...
Alternatively could be redefined to have this type of semantics when
its content model is just elements and text content.
(Also thanks to Sjoerd Visscher.)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
n text/html (besides
doing the sane thing in XML). I've suggested that to them in the past.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
to actually use it.
Nobody is talking about adding. It was suggested that Microsoft, if
desired, could utilize as a trigger for "real standards
mode".
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Wed, 14 Mar 2007 18:20:43 +0100, Robert Brodrecht
<[EMAIL PROTECTED]> wrote:
Anne van Kesteren Wrote
IE doesn't have a broken box model in standards mode.
I was under the impression you wanted to throw out different rendering
modes because they are difficult for implementors.
sentially rethink how to implement
the DOM (allowing "incest" relations) and rendering (hasLayout comes to
mind). Some of the things there fundamentally break with both the DOM and
CSS specifications.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
always
rendered 100x100, nor is it good to have a new tag that
renders the src as 100x100. You simply use the existing tag and
modify it to your specific case.
FWIW: The proposal here is not entirely new. Internet Explorer supports
these events.
--
Anne van Kesteren
<http
e video is shown "letterboxes" what does the surrounding space look
like? Would that be the 'background' of the element?
* I like how videoHeight and videoWidth work but are they not too
different from how similar constructs work in HTML (such as ,
, , )?
inside the screen
area at 400 x 300. If keepaspect is not set, the video would show at
400 x 400.
That's how is defined now. Except that "keepaspect" is the default
behavior and there's no way to switch. Perhaps people should reread the
draft?
--
Anne van Kesteren
<http
is far too complex for such a simple feature. What's outlined
in the current draft, with a possible future extension of to
turn UI on seems more sensible, easier to support and easier to author.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
pause() be
removed?
Cheers,
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
be to trigger togglePause()... That
might actually be interesting.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
tart tag as , or if not found, treat the
start tag as . Any content using in strict mode with
another HTML doctype is broken anyway, so it doesn't really matter
how that looks.
Oh yes, lets upgrade DOCTYPE sniffing to the 20th century. Fricking
awesome.
--
Anne van Kesteren
<http:/
gs way too much. User agents will always have to support everything
that's being used and doing that based on DOCTYPE sniffing (which
essentially implies versioning) is a rathole where you'd rather not go.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
raft.
2) Auto tabbing
for a 4 digit code:
This can be easily achieved with a simple script but I wonder if it's
desirable.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
desireable and useful (and I'd like to
see improved keyboard accessibility (such as arrow keys too) but this is
probably not the place for that rant!...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
owerCase) rather than
filtering/refusing certain keys - I will dig back in incase I missed
something in Xforms...
My bad, look at pattern="". That's probably more what you're looking for.
(Thanks Hixie!)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
quot;).getXMLDocument.
It seems as though external things which have DOMs are quite different
that other sorts of media and may deserve their own tag.
This use case is already addressed by :
document.getElementById('test').contentDocument
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
less demanding than scripting. Its popularity will probably be
synergized by rather dramatic increases in use of SVG.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
has been dropped) would be added
back. I suppose it might be considered overloading, but in a way we're
just defining how the processing model of a plugin could also work...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
currentSrc relies on a definition that may not be defined. For instance,
if the src="" attribute is not set and there are no element
children.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
y supposed to be
loading the content?
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
-
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Wouldn't it be better if no INDEX_SIZE_ERR was raised but instead the
previous value was retained? For consistency with
CanvasRenderingContext2D.globalAlpha for instance. It's not really
important, but I think that some consistency between the various APIs
would be nice.
-
you can easily extend that for
playlists. Prolly in a similar way as you proposed for .
By the way, people also suggested using an external file to contain the
playlist.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
.
Per the parsing algorithm they should never be normalized in attributes.
I'm not sure why you're suggesting they should.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
fallback content, it will be misunderstood
by the current browsers as pertaining to the .
Apart from the fact that I'm not entirely sure about reusing
anymore, I don't understand this argument.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
. I actually think that those type of document
semantics, including math, should just be part of HTML.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
The dateTime DOM attribute is spelled with an uppercase T:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-79359609
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
D-level
requirement, probably) support for the various supported image formats as
it gives a clear indication of what authors can rely on and what user
agents have to implement in order to support the web.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Tue, 27 Mar 2007 12:41:28 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
* Anne van Kesteren wrote:
Also, I think the HTML specification should mandate (as SHOULD-level
requirement, probably) support for the various supported image formats
as it gives a clear indication o
r the page has loaded?
That load event dispatched on the element also waits for all
external scripts and images to be loaded. This is not always desirable.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Hi,
* The IDL for the element is incorrect. Specifically,
the attributes need a name change.
* The HTMLMediaElement.currentLoop attribute should be of type
unsigned long rather than float.
Cheers,
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
element.
Any better way to markup these?
If I remember correctly was suggested for this purpose on IRC. The
advantage of over would be that people wouldn't easily think you
could put anything inside (as you put almost anywhere).
--
Anne van Kesteren
<http://an
ut -- it does exactly the
same as Flash does, which doesn't have its own element.
Java already has its own element. Not much chance you can take it away at
this point.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
g a new UA doesn't involve as much
reverse engineering as it used to.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
e
As I asked before: how does an author provided 'CSS zapper' not do that?
How in fact does requiring default presentations remove the need for
authors to provide 'CSS zappers'?
Not all authors will use a 'CSS zapper' (whatever it is). They will still
ex
e next step?
Providing some compelling usecases.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
#x27;s a pretty simple equation.
[...]
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
The tokenization section should also handle:
as "correct" comments for compat with the web. This means that
shows "-->" and that
shows "-->".
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Sat, 07 Apr 2007 14:27:14 +0200, Nicholas Shanks
<[EMAIL PROTECTED]> wrote:
AFAIK browsers and other HTML clients don't currently treat these as
comments, [...]
Well, sorry to say, you got your facts wrong.
[...]
--
Anne van Kesteren
<http://annevankeste
ling slash allowed, etc.).
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
ss it again...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
h names containing a colon, with an
apparent prefix, and one that matched an enclosing xmlns: declaration
were to be changed?
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
ion of "Attribute name
state", no parse error is produced for this condition. Nor does the
current html5lib parser produce a parse error with this data.
Correct. We're not doing validation. Just tokenizing and building a tree.
[...]
--
Anne van Kesteren
<http://an
would be
just as ok to use a different prefix. By basing this on the prefix (which
is needed if you want this to be compatible with HTML, etc.) you're moving
the semantics from the namespace to the prefix, which seems like a bad
idea.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
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, onl
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.or
ld be allowed, but there seems to be some
desire to have an ability to introduce "conforming" extension elements /
attributes which are implemented using a script library.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
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.n
for instance:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/thread.html#10088
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
the URI/IRI RFCs.
Your point of view is interesting though...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
or now, is just empty.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
They should say something different from what the element says. ;-)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
o just copying
some bits doesn't seem like a good justification for consistency.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
ible).
[EMAIL PROTECTED] is what you want. (You may need to subscribe to
the list first.)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
basically means less exceptions in the tokenizer for the
'<' character which would be fine with me.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Wed, 25 Apr 2007 09:53:10 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
On Wed, 25 Apr 2007 00:03:40 +0200, Simon Pieters <[EMAIL PROTECTED]>
wrote:
The parsing section says that < in an unquoted attribute value
terminates the tag. However, according to my testing
istinfo.cgi/commit-watchers-whatwg.org
The specification currently seems to point to the wrong URL though.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Wed, 25 Apr 2007 17:42:16 +0200, Aux <[EMAIL PROTECTED]> wrote:
Don't know if title/alt is automatically aplied to every HTML tag, but
it will be useful for .
title= is. How would alt= be useful?
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
means for HTML.
I fully agree with Simons original proposal though.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
er fallback I think. Given that video itself can go wrong at
times as well showing fallback when something goes wrong makes it quite
complicated I'm afraid.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
ove
margins on the body element.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
This section has the following line: "User agents must ignore any rows for
image types that they do not support." In my mind, this is in direct
conflict with the warning above that says it's imperative for user agents
to follow the same set of rules for security reasons.
treated the same as xml:id imo
(except that for now I suppose they have different handling if both the
xml: and normal attribute specified).
* Don't disallow in XHTML5 (it doesn't do any good, but
doesn't harm either).
If it doesn't have any effect would
), at least in Safari.
Sorry, I know very little of javascript. Are you saying it is technically
impossible for a UA to know beforehand what a script will do?
This doesn't just apply to JavaScript:
http://en.wikipedia.org/wiki/Halting_problem
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
already loaded.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Wed, 09 May 2007 11:10:22 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
It would be nice if this method described things for image in terms of
.complete. Although I've also heard people suggest they would like this
method to be synchronous when HTMLImageElement is pas
ifferences. It
simply indicates what _is_ different. Thanks.
(The page should really have been called "Differences from HTML4" as we're
not building on top of that...)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
return value of .fillStyle and
.strokeStyle yourself anyway...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
would like to party so Hixie can
take the relevant feedback into account and make a descision? :-)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Fri, 11 May 2007 10:11:39 +0200, Kristof Zelechovski
<[EMAIL PROTECTED]> wrote:
The scripts should test the canvas variable before use. It is empty in
IE7 and using it causes a runtime error.
That's perfectly fine for tests.
--
Anne van Kesteren
<http://annevankeste
yet another reason I don't want to be involved in the game. :)
It doesn't seem like a good reason not to participate to me. In fact, if
you have a use for the language and people are changing it in a way you
disagree with you should participate. HTML5 is still open for debate
etting fillStyle and strokeStyle. It's also not
clear what the use case is, as I understand it.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
enced
developers playing with these features have already made these
mistakes.
I'm not quite sure what a good solution to this problem would be.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
DEX_SIZE_ERR would be
correct here, though.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Sat, 12 May 2007 17:54:25 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
These features are nice but I don't think authors will understand that
imagedata.height != canvas.height (likewise for width). Authors will
just make something that works in their browser and then ass
some additional checking...)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
On Sun, 13 May 2007 11:49:23 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
In a reply to a message from Mathieu Hixie indicated that you can create
your own ImageData objects easily in ECMAScript:
var data = { height:1, width:1, data:[0,0,0,0] }
context.putImageData(data
used anywhere that an interface can be
used.
Agreed.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Internet Explorer 7 and Opera 9 don't move and to the
element during parsing (much like they don't do that for
If we simply ignore there's no longer a need to append elements to
the head element pointer. In fact, we can remove it. I'm not sure how much
this would complicate conformance checking, but it would certainly be very
nice not to have such strange appending rules for the limited set of
elem
401 - 500 of 1841 matches
Mail list logo
