Karl Dubost wrote:
Give the possibility that the textarea of a form to trigger
an editor, (A kind of setenv $EDITOR editorname)
(potentially wysiwyg). and/or implement a real wysiwyg editor
for forms in browsers (which sounds a bit silly when you really
think about it) There will be less
2006/12/4, Ian Hickson:
On Sun, 3 Dec 2006, Thomas Broyer wrote:
What I mean is that being syndication feed is not a property of a
relationship, it's a property of one end of the relationship (the
resource the link starts from or points to); so it has nothing to do
with the rel= attribute.
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
I suspect the others you mention are similar.
I don't ever remember using angle brackets
on Blogger, but it's been a while.
Point of note, Typepad has an Allow limited HTML option, no markdown.
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
Henri Sivonen wrote:
At this point, it is important to realize that
pro-XHTML advocacy
Who are the pro-XHTML advocates; those one who want divergence, or those who
want HTML5 to interoperate with XHTML as much as possible?
This reasoning is then applied to XHTML
served as text/html. This
Andrew Fedoniouk wrote:
Any technology to be widely accepted shall establish good set
of motivations. Ideally new technology shall bring benefits to all
actors or parties involved. Groups involved in acceptance of,
say, new version of HTML on the Web are:
1) web designers,
2) UA
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
Lachlan Hunt wrote:
(IE's disastrous XML Data Islands and Custom Tags provide sufficient
evidence of that.)
Why are XML Data Islands disasterous?
http://www.w3.org/mid/[EMAIL PROTECTED]
In that email you wrote:
My point is that the whole idea of embedding
XML in
Mike Schinkel wrote:
Henri Sivonen wrote:
I'll name the difference of XHTML_all and XHTML_compatible as
XHTML_incompatible. Lachlan gave examples that indicate that
XHTML_incompatible is not empty.
I'm sorry but may I please ask for a reference? I unfortunately don't
know where to find that
Le 3 déc. 2006 à 18:49, Ian Hickson a écrit :
On Sun, 3 Dec 2006, Thomas Broyer wrote:
What I mean is that being syndication feed is not a property of a
relationship, it's a property of one end of the relationship (the
resource the link starts from or points to); so it has nothing
to do
* Ian Hickson wrote:
You should request removal of the section. It is just a non-normative
discussion of implications of the parsing algorithm despite the claim
that extra restrictions are being defined and the misuse of RFC2119
keywords. As the thread shows, such discussion is unlikely to be
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]
Mike Schinkel wrote:
Hmm. I believe the http standard states that clients are not suppose to
override a content-type given by a server. For example, a web page showing a
script virus shouldn't be identified by the client as a script and executed;
the client should instead just display it as a
Mike Schinkel wrote:
Elliotte Rusty Harold wrote:
People who hand edit can handle some simple
well-formedness rules.
I think that is wishful thinking, unless we deliberately want to limit the
number of people who can contribute on the web.
For a long time we not so deliberately did limit
Sam Ruby wrote:
James Graham wrote:
[Internal data model in server]
|
|
HTML 5 Serializer
|
|
{Network}
|
|
HTML 5 Parser
|
|
On 12/4/06, Ian Hickson [EMAIL PROTECTED] wrote:
First, I must point out that WHATWG thought processes seems to regard
XML syntax as inseparable, for no real reason. In mind, a allowing a
trailing slash (for example) does not imply allowing CDATA and all the
rest.
Currently, there wouldn't
Le 4 déc. 2006 à 6:14, Mike Schinkel a écrit :
It does matter. It is not just one of the important things, it is THE
important thing. Having two divergent HTMLs will create problems
for a vast
number of people and will significantly reduce efficiencies for
anyone that
has to deal with it.
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
On 12/4/06, Mike Schinkel [EMAIL PROTECTED] wrote:
Shadow2531:
Sounds like you are in agreement. But can I ask you to summarized what you'd
propose?
Not sure if I can summarize, but I can be more specific by example.
Example browser preferences:
(Default value is first value)
[Markup
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
On Mon, 4 Dec 2006, Thomas Broyer wrote:
There's no need to fetch every link if you base your assumptions on the
type= attribute (and *only* the type= attribute, not the combination
with any special rel= attribute value). If you don't use the type=
attribute on links, you'll have many
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
Here's a random half dozen examples, picked to show a bit of diversity:
http://beta.versiontracker.com/mac/osx/home-edu/updates.rss
http://city.piao.com.cn/rss.asp?85
http://feuerwehr-melle-de.server13031.isdg.de/index.php?id=199
http://hesten.innit.no/hru/rss.php?START=0STOP=3
On Dec 4, 2006, at 07:48, Mike Schinkel wrote:
Henri Sivonen wrote:
C, Java, Python, Perl, C# and Ruby attract developers who
are capable of creating libraries. These languages already
have library ecosystems in place.
Forgive me for being so blunt, but that is an incredibly naïve view.
On Mon, 4 Dec 2006, Sam Ruby wrote:
Independent of what the specs say *MUST* happen, I'd like people to
bring up one or more browsers with a URL from this list, and see if the
browser asked them if they wanted to subscribe. Subscribe is not a
normal feature associated with text/html,
2006/12/3, Mike Schinkel:
What about Perl, Ruby, Javascript, Cold Fusion, JSP (Java), ASP.NET
(C#/VB.NET), and ASP (VBScript/ActiveX)?
(Did I miss any of significance?)
I've just started (today) a .NET implementation (in C#): a parser as
an XmlReader subclass and writers as XmlWriter and
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}
|
|
On Mon, 2006-12-04 at 15:07 +0900, Karl Dubost wrote:
Give the possibility that the textarea of a form to trigger an
editor, (A kind of setenv $EDITOR editorname)(potentially wysiwyg).
and/or implement a real wysiwyg editor for forms in browsers (which
sounds a bit silly when you really
Le 5 déc. 2006 à 08:27, Benjamin Hawkes-Lewis a écrit :
On Mon, 2006-12-04 at 15:07 +0900, Karl Dubost wrote:
Give the possibility that the textarea of a form to trigger an
editor, (A kind of setenv $EDITOR editorname)(potentially wysiwyg).
and/or implement a real wysiwyg editor for forms in
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
On Tue, 5 Dec 2006, Simon Pieters wrote:
Revision 410:
parser section says 'HTML' must be uppercase. We can discuss
if that should change (mail the list), but the syntax section
needs to be consistent, at least.
Where does it say that? What I find is this (in the DOCTYPE name state):
There are two worlds and that is why the mime-type had always been a
difficult story.
Le 4 déc. 2006 à 16:55, Ian Hickson a écrit :
On Sat, 2 Dec 2006, Elliotte Harold wrote:
Lachlan Hunt wrote:
The Yellow Screen of Death is about as annoying as you can get. I
really don't understand how
On Tue, 5 Dec 2006, Karl Dubost wrote:
2. When people edit files locally on their filesystem (outside HTTP
world) and they put them online through FTP (outside HTTP world), to
finally reach a folder controlled by a Web server (inside HTTP World),
troubles are starting.
There aren't
* Ian Hickson wrote:
How do you propose to organise it instead? The XML, HTML, and CSS
specifications quite clearly show that organising it so that the syntax
and the parsing rules are defined in the same prose leads to serious
deficiences (HTML forgot to define parsing altogether, CSS failed
On Tue, 5 Dec 2006, �istein E. Andersen wrote:
First, the parsing rules seem to give the token HTML for any string
[Hh][Tt][Mm][Ll].
Uh, oops. Yes, you're right. Ok, back to case-insensitive. (That does seem
better, anyway.)
Secondly, is this comparison supposed to be done when the
On Tue, 5 Dec 2006, Bjoern Hoehrmann wrote:
[...] section 9.2 defines syntax and parsing rules together.
No, it doesn't. It doesn't define the syntax at all. It defines how to
parse the syntax, and what to report as a syntax error, but that section
has no normative criteria that apply to
Bjoern Hoehrmann wrote:
I may be able to make additional suggestions once someone showed me
an example of HTML syntax where a 'p' element has a 'pre' child
element.
The pre element is allowed to occur where structured inline-level
elements are allowed.
Le 5 déc. 2006 à 11:38, Ian Hickson a écrit :
On Tue, 5 Dec 2006, Karl Dubost wrote:
2. When people edit files locally on their filesystem (outside HTTP
world) and they put them online through FTP (outside HTTP world), to
finally reach a folder controlled by a Web server (inside HTTP
Le 5 déc. 2006 à 05:34, Ian Hickson a écrit :
The other issue, supporting other vocabularies in HTML5, is an open
issue,
but it will be addressed in due course. We need more implementation
experience first, and there are far more pressing problems.
slightly related. What about foreign
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, Karl Dubost wrote:
Le 5 déc. 2006 à 11:38, Ian Hickson a écrit :
On Tue, 5 Dec 2006, Karl Dubost wrote:
2. When people edit files locally on their filesystem (outside HTTP
world) and they put them online through FTP (outside HTTP world), to
finally reach a
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,
Ian Hickson wrote:
On Tue, 5 Dec 2006, Karl Dubost wrote:
Le 5 déc. 2006 à 05:34, Ian Hickson a écrit :
The other issue, supporting other vocabularies in HTML5, is an open
issue, but it will be addressed in due course. We need more
implementation experience first, and there are far more
Le 5 déc. 2006 à 15:09, Ian Hickson a écrit :
On Tue, 5 Dec 2006, Karl Dubost wrote:
Le 5 déc. 2006 à 05:34, Ian Hickson a écrit :
The other issue, supporting other vocabularies in HTML5, is an open
issue, but it will be addressed in due course. We need more
implementation experience first,
Ian Hickson wrote:
On Tue, 5 Dec 2006, Elias Torres wrote:
I work at IBM/Lotus and are in the process of shipping a series of
internal components used by IBM employees as Lotus products. We have
tried using microformats as an extension mechanism for HTML but found
several limitations
* Ian Hickson wrote:
No, it doesn't. It doesn't define the syntax at all. It defines how to
parse the syntax, and what to report as a syntax error, but that section
has no normative criteria that apply to documents.
That is quite irrelevant. The definition of the parsing algorithm
along with
On Tue, 5 Dec 2006, Elias Torres wrote:
In one of the products, we need two things: one to specify our own piece
of structure data (call it microformat, call it RDFa data).
Could you give an example of the kind of data you're talking about and how
you'd use it? Obviously I don't mean to ask
On Tue, 5 Dec 2006, Bjoern Hoehrmann wrote:
* Ian Hickson wrote:
No, it doesn't. It doesn't define the syntax at all. It defines how to
parse the syntax, and what to report as a syntax error, but that
section has no normative criteria that apply to documents.
That is quite irrelevant.
I
69 matches
Mail list logo
