On Sun, 10 Dec 2006, Thomas Broyer wrote:
However, text/xml-script would result in a parse-error in HTML5 (if I
understand section 9.2 correctly).
I've removed the parse error.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A
Spartanicus wrote:
Mike Schinkel [EMAIL PROTECTED] wrote:
Google, Yahoo and MSN aren't in the business of enforcing a
standards- compliance agenda.
Who is?
A better question to ask would be to whom does it matter?.
Is it really relevant to give your opinion of my grammer?
SE's have
Henri Sivonen wrote:
On Dec 21, 2006, at 15:06, Mike Schinkel wrote:
Henri Sivonen wrote:
Google, Yahoo and MSN aren't in the business of enforcing a
standards- compliance agenda.
Who is?
I may be missing something obvious, but I can't think of
anyone who'd by in the business of
Mike Schinkel [EMAIL PROTECTED] wrote:
Google, Yahoo and MSN aren't in the business of enforcing a
standards- compliance agenda.
Who is?
A better question to ask would be to whom does it matter?.
Is it really relevant to give your opinion of my grammer?
I didn't, who is [in the business
Benjamin Hawkes-Lewis wrote:
Conversely, Site authors and developers, however, would be
most unlikely to ignore such warnings from one of the big
three search engines, because they're incredibly
embarrassing. Which would mean that 90% figure would shrink
fast. It would become an SEO
Henri Sivonen wrote:
Umm. The point is that you shouldn't show users something
that they don't understand or care about.
Depends on what your objective is. Objectives are not always singular.
Google, Yahoo and MSN aren't in the business of enforcing a
standards- compliance agenda.
Who
Aankhen wrote:
I was gonna go to this site I found on Google, but then I
saw that it was corrupted, so I figured it musta been a
security issue or something.
As for text/html, it's just another string of technical
jargon added by those crazy Google guys. Wonder what it means?
Perhaps
Mike Schinkel [EMAIL PROTECTED] wrote:
Google, Yahoo and MSN aren't in the business of enforcing a
standards- compliance agenda.
Who is?
A better question to ask would be to whom does it matter?. SE's have
nothing to gain from markup validity. They should serve up results
relevant to their
Mike Schinkel asked:
And at the risk of sounding snarky, can you point me to a
reference where is it codified that they are not (at least partially) in the
business of standards?
Spartanicus answered:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com
Humans don't work that way. If the words HTML (WARNING) or
XHTML (WARNING) started appearing next to over 90 percent
of search results, people would not think that something was
wrong with 90 percent of Web pages. They would think that
something was wrong with the search engine. And they
On Mon, 18 Dec 2006 16:57:08 +0600, Benjamin Hawkes-Lewis [EMAIL PROTECTED]
wrote:
Humans don't work that way. If the words HTML (WARNING) or XHTML
(WARNING) started appearing next to over 90 percent of search results,
people would not think that something was wrong with 90 percent of Web
On 12/18/06, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:
I would however definitely suggest better messages, since WARNING
verges on being meaningless. Perhaps HTML (corrupted) and XHTML
(corrupted) for documents that cite (or imply) a standard document type
but clearly fail to conform to it,
On 12/18/06, Alexey Feldgendler [EMAIL PROTECTED] wrote:
Maybe the other way round? Valid [X]HTML on valid documents?
That seems reasonable; if it were unobtrusive, most users would just
ignore it, but it'd be there for anyone who wanted to know.
--
Aankhen
(We have no branches.)
Aankhen wrote:
I was gonna go to this site I found on Google, but then I saw that it
was corrupted, so I figured it musta been a security issue or
something.
The original problem I was contesting and attempting to solve was that
users would think, incorrectly, that such messages indicated a
On Mon, 2006-12-18 at 12:28 -0800, Aankhen wrote:
On 12/18/06, Alexey Feldgendler [EMAIL PROTECTED] wrote:
Maybe the other way round? Valid [X]HTML on valid documents?
That seems reasonable; if it were unobtrusive, most users would just
ignore it, but it'd be there for anyone who wanted to
On Dec 19, 2006, at 9:54 AM, Benjamin Hawkes-Lewis wrote:
Aankhen wrote:
I was gonna go to this site I found on Google, but then I saw that it
was corrupted, so I figured it musta been a security issue or
something.
The original problem I was contesting and attempting to solve was that
Henri Sivonen wrote:
Search engines should not list ill-formed application/xhtml+xml at
all, because a user following the link would see the YSoD.
Ah, but what about XHTML 1.0 served as text/html, which is in a weird
twilight zone where it is neither HTML nor quite the same as
text/html
On Mon, 11 Dec 2006, Alexey Feldgendler wrote:
On Mon, 11 Dec 2006 05:27:14 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
...in new browsers, then it looks worse in new browsers than old
ones. Thus, new browsers will want to go back to the way that old
browsers handled it, so that they
On Mon, 11 Dec 2006, Alexey Feldgendler wrote:
On Mon, 11 Dec 2006 06:25:27 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
1.) Inserting Sam Ruby's SVG logo into HTML, for one example.
The img element already supports images in HTML. You can even embed
images directly in the page with
On Tue, 12 Dec 2006 02:53:50 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
They will, and old browsers will show either fallback content, if
provided, or nothing at all in place of the new-feature. I don't see
how is this rendering better than showing an error message for
malformed new-feature
Yes, visible metadata is far more likely to be kept updated
than invisible metadata (a quick look at the Web is enough
to demonstrate that).
You are making assumptions based on what has been and not what can be. If
business processes require the data to be maintained in order to continue
On Mon, 11 Dec 2006 05:27:14 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
...in new browsers, then it looks worse in new browsers than old ones.
Thus, new browsers will want to go back to the way that old browsers
handled it, so that they don't handle it worse than the (old)
competition.
I
On Mon, 11 Dec 2006 06:25:27 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
1.) Inserting Sam Ruby's SVG logo into HTML, for one example.
The img element already supports images in HTML. You can even embed
images directly in the page with data: URIs, regardless of the format (be
it PNG, JPEG,
On Thu, 07 Dec 2006 11:44:05 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
Here's an example. If this:
...text...
new-featureerroneous content/new-feature
...text...
...displays like this:
...text... ...text...
...in existing browsers, but like this:
...text... ERROR
2006/12/5, Michel Fortin:
It's interesting you mention script. If we want some sort of XML
data island, we could use something like this:
script type=text/xml
xml-content/
/script
Then, after the content of script has been gathered, the browser
could parse it as actual XML, stopping at the
At 02:37 + UTC, on 2006-12-08, Ian Hickson wrote:
On Fri, 8 Dec 2006, Sander Tekelenburg wrote:
[...]
http://www.whatwg.org/specs/web-apps/current-work/#parsing [...]
The error handling for parse errors is well-defined: user agents must
either act as described below when encountering
Sander Tekelenburg wrote:
I still have the impression that they can
undermine this entire effort by getting people to use authoring tools that on
purpose contain errors that result in 'good' looking pages in Explorer, and
'bad' in HTML5 browsers. Simply by producing code that they know will
Hi,
From: Sander Tekelenburg [EMAIL PROTECTED]
[...] But it still leaves the question whether
every browser will in fact be HTML5 compliant.
They probably won't, at least for the next few years. Historically all
browsers have always had bugs in their implementations. But having a clear
spec
At 17:05 +0200 UTC, on 2006-12-08, Rimantas Liubertas wrote:
[...]undermine this entire effort by getting people to use authoring tools
that on
purpose contain errors that result in 'good' looking pages in Explorer, and
'bad' in HTML5 browsers.
And how do you imagine Microsoft will get
At 16:13 + UTC, on 2006-12-08, Simon Pieters wrote:
From: Sander Tekelenburg [EMAIL PROTECTED]
[...] But it still leaves the question whether
every browser will in fact be HTML5 compliant.
They probably won't, at least for the next few years.
Right. That's a window of opportunity (for the
On Fri, 8 Dec 2006, Sam Ruby wrote:
If one has a single non-presentational relationship that one wishes to
associate with a web page AND one has control over the HTTP headers that
are sent with said web page (e.g., because your blogging software is
written in PHP), then an HTTP header is
On Fri, 8 Dec 2006, Sander Tekelenburg wrote:
But it still leaves the question whether every browser will in fact be
HTML5 compliant. Apparently Apple, Mozilla and Opera have that ambition.
Smaller ones, like iCab and lynx, will just have to follow. But what
about Microsoft? I still have
Ian Hickson wrote:
Ability to insert XML-based solutions into HTML and have then processed
as XML.
That's not a problem. That's a solution, looking for a problem.
1.) Inserting Sam Ruby's SVG logo into HTML, for one example.
2.) To incorporate an RSS feed in the HTML document and have it
At 00:45 + UTC, on 2006-12-05, Ian Hickson wrote:
[...]
[guesswork]
The point is the browsers all do the same thing, and that's well-defined
and documented [...]
if all the browsers do Z, then since the author presumably checked
his page with at least one browser, and it did Z,
On Thu, 07 Dec 2006 22:30:16 +0100, Sander Tekelenburg
[EMAIL PROTECTED] wrote:
[...] that produce code that triggers HTML5-compliant browsers to, as
per the HTML5 spec, stop processing the document, [...]
A parse error in HTML5 is not like a parse error (if there's such a
thing) in XML.
On Thu, 7 Dec 2006, Sander Tekelenburg wrote:
At 00:45 + UTC, on 2006-12-05, Ian Hickson wrote:
The point is the browsers all do the same thing, and that's well-defined
and documented [...]
if all the browsers do Z, then since the author presumably checked
his page with at least
At 01:22 + UTC, on 2006-12-08, Ian Hickson wrote:
On Thu, 7 Dec 2006, Sander Tekelenburg wrote:
At 00:45 + UTC, on 2006-12-05, Ian Hickson wrote:
[...]
I'm still somewhat sceptical about the reality of this though, as it relies
on the author checking the document with at least one
Ian Hickson wrote:
The pingback specification does exactly what the trackback
specification does, but without relying on RDF blocks in comments or
anything silly like that. It just uses the Microformats approach, and
is far easier to use, and doesn't require any additional bits to add
to
On Fri, 8 Dec 2006, Sander Tekelenburg wrote:
Your assumption seems to be that the interoperable handling of HTML
documents is to somehow abort processing. This is not the case. Each
error has explicitly defined error-recovery behaviour.
My mentioning of parsing abortion stems from
On Thu, 7 Dec 2006, Sam Ruby wrote:
They were made around the same time (Trackback was invented first). My
point was just that Trackback is not a good example of why you need
more attributes in HTML, since there are equivalent technologies that
do it with existing markup and no loss
On Mon, 04 Dec 2006 22:11:09 +0600, Michel Fortin [EMAIL PROTECTED] wrote:
I was initially disappointed that !DOCTYPE html is well-formed
because I though that it'd allow to differentiate HTML from XHTML
documents unambiguously (since XHTML documents couldn't have it).
That said, now I think
On Mon, 04 Dec 2006 20:43:15 +0600, Elliotte Harold [EMAIL PROTECTED] wrote:
1. Strong hand-authoring: static HTML written fully in a plain vanilla
text editor with tags in view
2. Weak hand-authoring: templates hand-authored, content not
My point then becomes, very little content on the web
On Mon, 04 Dec 2006 17:10:08 +0600, Mihai Sucan [EMAIL PROTECTED] wrote:
IMHO, requests for allowing the xmlns attribute and other XMLiness is a
bit over the board. I am for allowing the trailing slashes, they do no
harm, and they help us on the server side, under strict control. Also,
On Fri, 8 Dec 2006, Alexey Feldgendler wrote:
Recently, br/ has been brought into the common subset of HTML5 and
XHTML5. That's OK because browsers currently handle br/ the same in
HTML and XHTML, and will continue doing so. The same for xmlns attribute
on html.
However, introducing
On Tue, 5 Dec 2006, Sam Ruby wrote:
I don't see any documentation that requires XHTML to not support
display.write, but it certainly is a reality that nobody has done
so.
http://www.whatwg.org/specs/web-apps/current-work/#document.write1
(I'd like to make it work, but
Ian Hickson:
Validators are allowed to give any warnings or notes
they like. (The spec only specifies that a validator
must give no errors if there are no errors and must
give at least one error if there are any, IIRC.)
Is it possible for the spec to suggest/recommend that validators
On Wed, 6 Dec 2006, Mike Schinkel wrote:
Ian Hickson:
Validators are allowed to give any warnings or notes
they like. (The spec only specifies that a validator
must give no errors if there are no errors and must
give at least one error if there are any, IIRC.)
Is it possible for
Ian Hickson wrote:
On Tue, 5 Dec 2006, Sam Ruby wrote:
xmlns attributes are invalid on HTML elements except html, and
when found on unrecognized [elements] imply style=display:none
unless you recognize the value of this attribute.
There are millions of documents that would be broken by
On Wed, 6 Dec 2006, Sam Ruby wrote:
The common pattern that I see is that xmlns=.
It's certainly the more common value, but it is by no means the only one,
as you will see if you examine the various examples I gave in more detail.
--
Ian Hickson U+1047E
Ian Hickson wrote:
On Wed, 6 Dec 2006, Sam Ruby wrote:
The common pattern that I see is that xmlns=.
It's certainly the more common value, but it is by no means the only one,
as you will see if you examine the various examples I gave in more detail.
My bad. Point made.
- Sam Ruby
Ian Hickson wrote:
| [HTML5] is the format recommended for most authors. [...] Generally
| speaking, authors are discouraged from trying to use XML on the Web,
| because XML has much stricter syntax rules than the HTML5 variant
| described above [...]
--
Ian Hickson wrote:
IMHO that's the kind of thing that belongs on the wiki
or as an opinion piece on the blog (feel free to post
either). But the spec should stay out of the way of
such arguments.
Well, I can't go beyond that. But please realize that if the spec did
include it, even if it
On Wed, 6 Dec 2006, Mike Schinkel wrote:
The HTML5 parser would pass anything within XMLDATA elements to an
XML parser and insert whatever it returns into the response stream.
This could allow SVG and MathML to work, no?
What's the use case?
The use-case is to allow abitrary
Le 5 déc. 2006 à 17:03, Ian Hickson a écrit :
The one target now is HTML5.
I wonder about one thing though. If the recommended serialization is
HTML5, why is there new features which are simply not supported by
HTML5 (list inside paragraphs, nested forms, etc.)? My impression is
that
On Tue, 5 Dec 2006, Michel Fortin wrote:
The one target now is HTML5.
I wonder about one thing though. If the recommended serialization is
HTML5, why is there new features which are simply not supported by HTML5
(list inside paragraphs, nested forms, etc.)? My impression is that
On Tue, 5 Dec 2006, Sam Ruby wrote:
Case in point:
http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble
In IE, there's some stray XHTML HTML and XHTML HTML XML text. This
isn't acceptable to most people. It certainly isn't something that it
would make sense to
Ian Hickson wrote:
I don't see any documentation that requires XHTML to not support
display.write, but it certainly is a reality that nobody has done so.
http://www.whatwg.org/specs/web-apps/current-work/#document.write1
(I'd like to make it work, but can't work out how to specify it. If
Ian Hickson wrote:
On Tue, 5 Dec 2006, Sam Ruby wrote:
Case in point:
http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble
In IE, there's some stray XHTML HTML and XHTML HTML XML text. This
isn't acceptable to most people. It certainly isn't something that it
would make sense to
On 12/5/06, Sam Ruby [EMAIL PROTECTED] wrote:
In case there is anybody here who doesn't faithfully follow my blog
grin, I have prototyped MathML + SVG + XLINK in HTML4:
... [modify parser]...
This could be designed in such a way that
it was only enabled as an about:config option. Where I
Le Mon, 04 Dec 2006 09:55:32 +0200, Ian Hickson [EMAIL PROTECTED] a écrit:
I've been having a lot of trouble following this discussion, because I
can't work out what it is that is being asked for. There seem to be
multiple discussions going on, and it isn't clear to me that everybody
really
Ian Hickson wrote:
I've been having a lot of trouble following this
discussion Are there other requests? What are they?
1.) Minimize the changes *required* for existing documents to validate as
HTML5
2.) Provide strategies that make transitionality possible, and provide
incentives for moving
On Mon, 04 Dec 2006 08:55:32 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
* Possible Request D: We want HTML-style graceful error handling for XML
content.
This is out of scope of the HTML5 specification. Speak to the XML guys.
XML currently requires draconian error handling and has no defined
Ian Hickson wrote:
I've been having a lot of trouble following this discussion, because I
can't work out what it is that is being asked for. There seem to be
multiple discussions going on, and it isn't clear to me that everybody
really knows what they are arguing for or against.
I've changed
Ian Hickson wrote:
* Possible Request A: We want a way to add proprietary markup to HTML
documents, and have them be usable by text/html browsers.
This won't work, because the browsers won't support that proprietary
markup. This has nothing to do with the specs. (The same problem exists in
Ian Hickson wrote:
On Sat, 2 Dec 2006, Elliotte Harold wrote:
Secondly, anyone who actually tried to use an SGML parser to handle HTML
rapidly hit a wall since most HTML documents were not even close to
actually conformant to the SGML spec or the HTML DTD.
Exactly. And the *exact same
Ian Hickson wrote:
What is it about XML that you like, that you don't get with HTML, that
makes you request that we make HTML more like XML?
I'm not sure which HTML you're talking about here, but
1. A reliable, practical tool chain including XSLT
2. Extensibility. I want to embed the
Ian Hickson wrote:
In the Web Apps 1.0 world, an HTTP message whose headers say text/html is
an HTML document, regardless of what sequence of bytes the body of the
message actually say. An HTTP message whose headers say text/xml, or use
some other XML MIME type, is an XML document. It's the
Ian Hickson wrote:
On Sun, 3 Dec 2006, Mike Schinkel wrote:
Use XHTML, send it with an HTML MIME type, and be happy.
No!
Why not? What's wrong with doing that?
Well, it's impossible. If you _think_ you're using XHTML, but you process
it with an HTML processor (e.g. by sending it as
Ian Hickson wrote:
Consider that essentially every page generated by Blogger, Moveable Type
or WordPress is not hand authored.
Actually, all those _are_ hand authored. They all use templates that were
very carefully written by HTML authors by hand.
Almost every page at sites like
Elliotte Harold wrote:
That means I have to send text/html to browsers (because that's the only
thing they understand) and let my clients ignore that hint.
No.
As I understand it, the full chain of events should look like this:
[Internal data model in server]
|
James Graham wrote:
As I understand it, the full chain of events should look like this:
[Internal data model in server]
|
|
HTML 5 Serializer
|
|
{Network}
|
|
HTML 5
James Graham wrote:
Elliotte Harold wrote:
That means I have to send text/html to browsers (because that's the
only thing they understand) and let my clients ignore that hint.
No.
As I understand it, the full chain of events should look like this:
[Internal data model in server]
Sam Ruby wrote:
James Graham wrote:
[Internal data model in server]
|
|
HTML 5 Serializer
|
|
{Network}
|
|
HTML 5 Parser
|
|
Le 4 déc. 2006 à 2:55, Ian Hickson a écrit :
I've been having a lot of trouble following this discussion, because I
can't work out what it is that is being asked for. There seem to be
multiple discussions going on, and it isn't clear to me that everybody
really knows what they are arguing for
On Mon, 04 Dec 2006 17:10:18 +0100, Michel Fortin
[EMAIL PROTECTED] wrote:
I know I suggested xml:lang before, but that was when I thought it was
parsed in HTML. Now I think a more clever approach would be to allow
html:lang to validate in XHTML, because XHTML already mandates that
Le 4 déc. 2006 à 11:14, Anne van Kesteren a écrit :
For the record. There's no such thing as a lang attribute in the
HTML namespace. Except perhaps in some schema's the HTML WG at the
W3C is producing but those can safely be ignored.
Indeed, it's the lang attribute with no namespace I
Le Mon, 04 Dec 2006 18:10:18 +0200, Michel Fortin
[EMAIL PROTECTED] a écrit:
Le 4 déc. 2006 à 6:10, Mihai Sucan a écrit :
However, in the same spirit, a middle way for those who want XMLiness
in HTML, would be to allow the xmlns:?.* attribute, xml:base, xml:id,
and xml:lang. Yet, define
Le 4 déc. 2006 à 12:30, Mihai Sucan a écrit :
html lang=fr xmlns=http://www.w3.org/1999/xhtml;
head
titleSans titre/title
/head
body
pBonjour à tous!/p
p lang=roBună ziua tuturor!/p
pimg src=merci.png alt=Merci! id=mon-image //p
/body
/html
Nice example Mihai.
To reformulate my previous
Sam Ruby wrote:
[snip]
HTML5 can do one better. Instead of handling presentational MathML as a
special case, this support can be generalized. When a non-HTML element
is encountered inside a HTML document, the parser could make one
additional check: does this attribute have a xmlns attribute
[I unintentionally sent my previous message off-list. Sorry about that. Am
moving this back to the list again. As there's nothing personal in it, I
assume that's OK.]
At 18:37 + UTC, on 2006-12-04, Ian Hickson wrote:
On Mon, 4 Dec 2006, Sander Tekelenburg wrote:
[...]
[smiley to
Michel Fortin wrote:
Le 4 déc. 2006 à 6:10, Mihai Sucan a écrit :
However, in the same spirit, a middle way for those who want
XMLiness in HTML, would be to allow the xmlns:?.* attribute, xml:base,
xml:id, and xml:lang. Yet, define them as meaningless. Just for
validation purposes, just for
On Tue, 5 Dec 2006, Henri Sivonen wrote:
On Dec 4, 2006, at 22:34, Ian Hickson wrote:
The fact that my weblog and my planet are usefully viewable on Lynx is a
counter example that is meaningful to me.
My point is that if you used HTML5 instead, you would have _more_ features
On Mon, 4 Dec 2006, Ian Hickson wrote:
It also doesn't work that well. I'd be interested to see what happened
in IE if the SVG used the SVG 1.2 textArea feature. Or if it used the
SVG text and tSpan features.
Case in point:
http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble
On Mon, 4 Dec 2006, Robert Sayre wrote:
On 12/4/06, Ian Hickson [EMAIL PROTECTED] wrote:
It certainly isn't something that it would make sense to encourage.
Is this different than what IE does with canvas?
Yes, because with canvas the feature has been carefully designed to have
Sam Ruby wrote:
James Graham wrote:
As I understand it, the full chain of events should look like this:
[Internal data model in server]
|
|
HTML 5 Serializer
|
|
{Network}
|
|
At 20:46 + UTC, on 2006-12-04, Ian Hickson wrote:
On Mon, 4 Dec 2006, Sander Tekelenburg wrote:
[...]
[ESP engines]
Surely you're not saying that HTML5 will define error handling for every
possible case a UA may run into?
Yes. In fact, not only will it define this, it already _does_
On Tue, 5 Dec 2006, Sander Tekelenburg wrote:
http://www.whatwg.org/specs/web-apps/current-work/#parsing
Still, I don't see how this makes it not guesswork.
Well, if you want to call well-defined interoperable error handling
guesswork, then sure. I guess that's just terminology.
The
Le 4 déc. 2006 à 14:33, Martin Atkins a écrit :
Likewise, the content model of the script element is hardcoded
into the parser; there's no way to discover it from the syntax
alone. (I'll admit that there's no similar construct to the content
model of script in XML, however, so this
Le 4 déc. 2006 à 17:19, Lachlan Hunt a écrit :
I agree, but how are xml:lang, xml:base and xml:id any more
meaningless in HTML than xmlns?
In XHTML you can avoid using xml:base (by not specifying a base) and
xml:id (by using id). You can't avoid xmlns. That's why I think xmlns
comes
Ian Hickson schrieb:
On Mon, 4 Dec 2006, Robert Sayre wrote:
On 12/4/06, Ian Hickson [EMAIL PROTECTED] wrote:
It certainly isn't something that it would make sense to encourage.
Is this different than what IE does with canvas?
Yes, because with canvas the feature has been carefully designed
On Tue, 5 Dec 2006, Julian Reschke wrote:
Ian Hickson schrieb:
On Mon, 4 Dec 2006, Robert Sayre wrote:
On 12/4/06, Ian Hickson [EMAIL PROTECTED] wrote:
It certainly isn't something that it would make sense to encourage.
Is this different than what IE does with canvas?
Yes,
I've been having a lot of trouble following this discussion, because I
can't work out what it is that is being asked for. There seem to be
multiple discussions going on, and it isn't clear to me that everybody
really knows what they are arguing for or against.
I've changed the spec to allow a
92 matches
Mail list logo
