On Sat, 2 Dec 2006, Mike Schinkel wrote:
You don't need to do one or the other. It's just up to you which you
do. Neither is better or worse than the other. They are equivalent,
neither is deprecated, There's no reason to try and do both.
If, as you say one is as good as the
On Dec 2, 2006, at 09:19, Lachlan Hunt wrote:
The best idea so far for how to make it work is for parsers to
automatically recognise the tag names and put them into the correct
namespace.
I think putting subtrees rooted at svg or math in the SVG and
MathML namespaces respectively (and
Lachlan Hunt wrote:
The XHTML serialisation exists to make use of XML-only features, like
xmlns syntax. People wishing to use such features *must* use XML. There
has been no reason whatsoever given for wanting to try and use
unsupported XML-only syntax in HTML, most likely because there is
On 12/1/06, Michel Fortin [EMAIL PROTECTED] wrote:
I wonder if xml:lang and xmlns couldn't be made legal in HTML.
xml:lang would simply become conformant in HTML as a synonym for the
lang attribute, it's already in the spec that it should get the
correct treatment anyway. xmlns would only be
Henri Sivonen wrote:
I think putting subtrees rooted at svg or math in the SVG and MathML
namespaces respectively (and allowing / to close elements while the
tokenizer is looking at such a subtree) would be more forward-compatible
with future SVG and MathML revisions. (Subtrees rooted at
Elliotte Harold wrote:
Lachlan Hunt wrote:
HTML and XML have significantly different parsing requirements and
they absolutely must be treated as significantly different file
formats. Any attempt to treat them as the same format is an extremely
bad idea.
That's only true to the extent that
On 3 Nov 2006, at 9:51PM, Ãistein E. Andersen wrote:
In section 5.2.2., `chickenkïwi.soup' (with diaeresis) appears twice [...],
as does `chickenkiwi.soup' (without diaeresis).
No one ever replied to this, and the draft remains unchanged.
(If this is /not/ a typo, this should probably be
On 12/1/06, Elliotte Harold [EMAIL PROTECTED] wrote:
Henri Sivonen wrote:
6. Are noncharacters U+FDD0..U+FDEF allowed (?)
7. Are the noncharacters from the last two characters of each plane
allowed (?)
I don't have particularly strong feelings here. Putting those characters
is HTML is a
Lachlan Hunt wrote:
HTML 2.0 to 4.01 documents could, in the same way you're insisting on
using XML tools on the back end, be reliably parsed using SGML tools.
Surely you jest. First of all, I believe there was only ever one parser
that implemented all of the SGML specification, SP from
Elliotte Harold wrote:
James Graham wrote:
Ignoring the _syntax_ for a moment, there have been reasons given for
wanting to use XML _features_ in HTML5 - the desire to embed MathML or
SVG in a HTML document, for example. You suggest punting these use
cases to XHTML5, without addressing the
James Graham wrote:
Well I think you're hugely mistaken. Any model without support for error
recovery is not suitable for hand authoring (and only marginally
suitable for machine authoring).
You mean like almost every programming language ever invented? When's
the last time you saw error
Elliotte Harold wrote:
I don't believe most web documents are hand authored any more. Consider
that essentially every page generated by Blogger, Moveable Type or
WordPress is not hand authored. Almost every page at sites like
Amazon.com or walmart.com is not hand authored. Hand authoring is a
Lachlan Hunt wrote:
The Yellow Screen of Death is about as annoying as you can get. I
really don't understand how you can go on about the benefits of XML
because it requires well-formedness, but then turn around and say XML
can be served as text/html which just makes all your arguments null
Robert Sayre wrote:
SVG and MathML have a DOM. It wouldn't be that hard to serialize it as
HTML5.
Robert, if you will permit me, I would like to recast that into the form
of a question, jeopardy style.
The question is: what would the HTML5 serialization be for the DOM which
is internally
On Sat, 02 Dec 2006 21:10:49 +0100, Rimantas Liubertas
[EMAIL PROTECTED] wrote:
P.S. That script, complete with indentation and readable variable
names, is still an order of magnitude smaller than
http://whatwg.org/images/logo
...
And so is this one: http://rimantas.com/bits/whatwg.png
I
On 12/2/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
There's probably no way you can serialize that document.
Hmm, Sam's example displayed correctly in Safari, Firefox, Opera, and
recent WebKit nightlies.
I don't think we need to settle this issue in December 2006, but I do
think there is
On 12/2/06, Robert Sayre [EMAIL PROTECTED] wrote:
On 12/2/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
There's probably no way you can serialize that document.
Hmm, Sam's example displayed correctly in Safari, Firefox, Opera, and
recent WebKit nightlies.
That's wrong. Sam's example
On 12/2/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Sat, 02 Dec 2006 22:55:00 +0100, Robert Sayre [EMAIL PROTECTED] wrote:
On 12/2/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
There's probably no way you can serialize that document.
Hmm, Sam's example displayed correctly in Safari,
Shipping Safari has no SVG support. WebKit nightlies do. That's the
only reason the logo now renders correctly in the nightlies so
that particular file is completely irrelevant to this discussion.
dave
On Dec 2, 2006, at 2:41 PM, Robert Sayre wrote:
On 12/2/06, Anne van Kesteren
On 12/2/06, Robert Sayre [EMAIL PROTECTED] wrote:
I don't think we need to settle this issue in December 2006, but I do
think there is ample evidence of interoperable but undocumented
behavior that HTML5 implementors will need to consider.
Does the WHATWG have a process for capturing
On 12/2/06, David Hyatt [EMAIL PROTECTED] wrote:
Shipping Safari has no SVG support. WebKit nightlies do. That's the
only reason the logo now renders correctly in the nightlies so
that particular file is completely irrelevant to this discussion.
I'm confused. Which file? And why is it
On Dec 2, 2006, at 18:24, Sam Ruby wrote:
It would not be wise for HTML5 to limit itself to the more constrained
character set of XML. In particular, the form feed character is
pretty popular,
This is yet another case where take HTML5, read it into a DOM, and
serialize it as XML, and voilà:
On Dec 3, 2006, at 00:48, Sam Ruby wrote:
On 12/2/06, Robert Sayre [EMAIL PROTECTED] wrote:
I don't think we need to settle this issue in December 2006, but I do
think there is ample evidence of interoperable but undocumented
behavior that HTML5 implementors will need to consider.
Does the
Hi,
If figure is intended to be used for thumbnails then we have to allow a
around the embedded content:
figure
a href=foo-larger.htmlimg alt=... src=foo.png/a
legend.../legend
/figure
Clicking on the image is how most galleries work AFAIK -- the link is mostly
not in the caption.
Hi,
Here's a page that has code snippets with captions:
http://www.thomasfrank.se/object_prototype_is_erlaubt.html
A use-case for figure, no?
Regards,
Simon Pieters
_
Leta efter bilder på Red Hot Chili Peppers
Robert Sayre wrote:
link rel=edit
type=application/atom+xml
href=entry.xml /
While type is useful for things which result in GET requests, while
specifying several locally-relevant protocols I've run into the fact
that it's not so hot for anything that requires the
On 12/2/06, Henri Sivonen [EMAIL PROTECTED] wrote:
On Dec 2, 2006, at 18:24, Sam Ruby wrote:
It would not be wise for HTML5 to limit itself to the more constrained
character set of XML. In particular, the form feed character is
pretty popular,
BTW, I copy and pasted the wrong table. The
On Sat, 02 Dec 2006 23:41:34 +0100, Robert Sayre [EMAIL PROTECTED] wrote:
There's probably no way you can serialize that document.
Hmm, Sam's example displayed correctly in Safari, Firefox, Opera, and
recent WebKit nightlies.
Yes. Rendering it is different from serializing it though. I agree
On 12/2/06, Daniel E. Renfer [EMAIL PROTECTED] wrote:
The difference between a collection of entries and a single entry is
an important one. Sure, once you get inside the Entry, everything is
the same, but knowing ahead of time that you are requesting a single
Entry assists in processing.
But
On Sat, 02 Dec 2006 23:48:17 +0100, Sam Ruby [EMAIL PROTECTED]
wrote:
I don't think we need to settle this issue in December 2006, but I do
think there is ample evidence of interoperable but undocumented
behavior that HTML5 implementors will need to consider.
Does the WHATWG have a process
On 12/2/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
What is the benefit of refusing to specify a serialization?
I didn't refuse anything.
I don't think that is a productive way to have a discussion, but the
issue seems to be more controversial than I expected. Maybe we all
need a little
Henri Sivonen wrote:
Elliotte Harold wrote:
What I don't understand is why some members of this working group is
so dead set on actively preventing HTML from being XML. The non-
draconian error handling I understand. But why are you disappointed
that !DOCTYPE html is well-formed XML?
Ian:
(I didn't know what part to quote, so I left your email intact below.)
So what guidance would you publish after HTML5 is released with regards to
people in each of the following situations:
1.) Currently coding HTML(4) but trying to move to XHTML
2.) Currently coding XHTML and cleaning up
Work is being done on such tools now. A few of us have
begun writing a parser in Python, which will be either public
domain (preferably) or under a free software licence. I also
have plans to write one in PHP, which will be public domain.
Henri Sivonen has written one in Java for the
Elliotte:
I hope you are not advocating that we shouldn't have considerations for
hand-editing, and I don't see the need for hand editing ever changing.
Even if people don't hand edit entire pages they will hand edit fragments of
pages such as on wikis and forums and blogs and cms.
Also, if
The following are honest questions, not rhetorical baiting.
Lachlan Hunt wrote:
Use XHTML, send it with an HTML MIME type, and be happy.
No!
Why not? What's wrong with doing that?
Lachlan Hunt wrote:
In many more cases, an HTML document or even an
XHTML 1.0 as text/html document
Mike Schinkel wrote:
So what guidance would you publish after HTML5 is released with regards to
people in each of the following situations:
Note: Where I refer to outputting HTML below, I assume the use of
text/html. Where I refer to outputting XHTML below, I assume the use of
an XML MIME
Hello Lachlan,
On 12/2/06, Lachlan Hunt [EMAIL PROTECTED] wrote:
Lachlan Hunt wrote:
Work is being done on such tools now. A few of us have begun writing a
parser in Python, which will be either public domain (preferably) or
under a free software licence.
We've just set up a project for
38 matches
Mail list logo
