On Tue, 28 Feb 2006, Loune wrote:
I don't know if this has been addressed or not, since I only briefly
scanned the spec. Hopefully, I didn't write this for nothing :) This
relates to the handling of anchors in URLs:
A common argument or complaint against AJAX is that it renders the back
On Mon, 25 Jun 2007, Kristof Zelechovski wrote:
If there is a character set that sports both, it must be used to put
down some human language. My point there is no language that could make
use of this distinction by having both uuml; and utrema;. There are
languages that use uuml; and
On Thu, 21 Jun 2007, Anne van Kesteren wrote:
Currently if you encounter /body or /html inside a noscript
element in the scripting disabled case you will get incorrect results as
the current node is not the head element but the noscript element.
Hm, indeed, you'd get an infinite loop.
Once upon a time Ian Hickson shaped the electrons to say...
Frames are out (except iframe, which I don't really see as being a
problem, though let me know if I'm wrong on this). Tables for layout are
I think iframe is required simply by weight of use. It seems like
most web-based advertising
Ian Hickson wrote:
On Sat, 24 Feb 2007, Keryx Web wrote:
- A table within a table cell (Has this ever been used for anything but
layout?)
There are valid uses of that, though they are rare.
Really? What are they?
--
Lachlan Hunt
http://lachy.id.au/
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
On Sat, 24 Feb 2007, Keryx Web wrote:
Speaking from __my__ experience, and the experience of those (too few)
colleagues that I've met in Sweden who teach standards based web
development, it is hard too make the student understand that something
is wrong if he/she get's away with it.
Ian Hickson wrote:
On Fri, 21 Jul 2006, Henri Sivonen wrote:
I gather that a normative reference to the Porter�Duff paper is needed:
http://keithp.com/~keithp/porterduff/p253-porter.pdf
On Mon, 24 Jul 2006, L. David Baron wrote:
I've written tests for the 11 operators defined in the paper,
On 20/05/07, Mathieu HENRI [EMAIL PROTECTED] wrote:
Ian Hickson wrote:
I've referenced the paper and dropped 'darker'.
Please, please, pretty please, bring 'darker' back.
Rename it 'multiply' if you want, or if like me you think this name
better reflects the operation previously known as
On Fri, 21 Jul 2006, Henri Sivonen wrote:
I gather that a normative reference to the Porter�Duff paper is needed:
http://keithp.com/~keithp/porterduff/p253-porter.pdf
On Mon, 24 Jul 2006, L. David Baron wrote:
I've written tests for the 11 operators defined in the paper, plus a
test
On Wed, 16 May 2007, Darin Adler wrote:
1) NANs
2) non-floating point values
3) missing parameters
b) excess arguments
1, 3, and b now raise exceptions except if otherwise specified. I
haven't yet defined 2. I'm not sure what it should say.
I think that (2)
On 17/05/07, Ian Hickson [EMAIL PROTECTED] wrote:
I've changed the spec to say to ignore extra arguments and raise an
exception for too few arguments.
What happens when someone calls drawImage(image, dx, dy, dw)? That's
too few arguments for void drawImage(in HTMLImageElement image, in
float
On May 16, 2007, at 5:31 PM, Philip Taylor wrote:
On 17/05/07, Ian Hickson [EMAIL PROTECTED] wrote:
I've changed the spec to say to ignore extra arguments and raise
an exception for too few arguments.
What happens when someone calls drawImage(image, dx, dy, dw)?
That's too few arguments
Ian Hickson wrote:
Probably the best we can do is design the language to make the right
thing easier, and invest more heavily in education. In this regard HTML
is in the same boat as more important subjects; I imagine that as we
improve the quality of education in general, understanding of the
On Wed, 21 Feb 2007 22:38:48 +0100, Elliotte Harold [EMAIL PROTECTED] wrote:
... most of the tools that
have been built have been built by programmers with more experience in
WYSIWYG word processors than in semantic markup. The semanticists who
have built GUI tools have not had the necessary
[EMAIL PROTECTED]
Cc: whatwg@lists.whatwg.org; Vlad Alexander (xhtml.com)
[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 4:34 PM
Subject: Re: [whatwg] several messages about HTML5
Ian Hickson wrote:
The original reason I got involved in this work is that I realised that
the human race
Michel Fortin wrote:
About that, I would like to suggest that the current text be changed to
reserve class names starting with a dash - for private use. That way
that we would have a pool of class names which are guarantied to not be
taken over later when new predefined class names are added.
On Wed, 21 Feb 2007 10:41:12 +0100, Gervase Markham [EMAIL PROTECTED]
wrote:
About that, I would like to suggest that the current text be changed to
reserve class names starting with a dash - for private use. That way
that we would have a pool of class names which are guarantied to not be
Anne van Kesteren wrote:
On Wed, 21 Feb 2007 10:41:12 +0100, Gervase Markham [EMAIL PROTECTED]
wrote:
Surely it would make much more sense to have all the predefined class
names start with a dash? After all, XHTML5 is not yet standardised,
whereas people have been using all sorts of random
On Wed, 21 Feb 2007 11:33:36 +0100, Gervase Markham [EMAIL PROTECTED]
wrote:
I don't see how the analogy holds. Why is using a fairly clean namespace
for predefined class names instead of a well-used one the same sort of
thing as having HTML parsers stop at the first error?
The analogy I
Gervase Markham wrote:
(I guess I'm making an underlying assumption here that there aren't
loads of existing pages on the web using HTML 5 predefined class names
while expecting HTML 5 rendering and semantics for them. But, unless I'm
missing something, that seems like a reasonable
Anne van Kesteren wrote:
The analogy I tried to make (apparently it failed) is that design
decisions for C/C++ are not necessarily good for HTML.
Right. But they aren't necessarily bad either. What is wrong with
picking a clean rather than a dirty namespace for predefined class
names? Or
On Feb 21, 2007, at 07:14, Sander Tekelenburg wrote:
That's not a flaw in HTML, because it is essential to HTML that it
separates content from presentation.
I think device independence and accessibility are worthwhile goals.
Semantic markup and separation of content and style are not
Henri Sivonen wrote:
I think device independence and accessibility are worthwhile goals.
Semantic markup and separation of content and style are not essential
in themselves but just a means of pursuing the other goals.
Those aren't the /only/ goals of semantic markup and separation of
On Feb 21, 2007, at 16:39, Benjamin Hawkes-Lewis wrote:
Henri Sivonen wrote:
I think device independence and accessibility are worthwhile goals.
Semantic markup and separation of content and style are not essential
in themselves but just a means of pursuing the other goals.
Those aren't the
On Wed, 21 Feb 2007 00:05:47 + (UTC), Ian Hickson wrote:
* Radical new benefits to offset the pain of change
* Backwards-compatibility with the old technology
I agree.
It's the first really open,
collaborative community that has taken on a task of this magnitude
AFAICR from Daniel
On Wed, 21 Feb 2007 16:56:56 +0100, David Latapie [EMAIL PROTECTED]
wrote:
I don't say so just for nitpicking, but would also appreciate feedbacks
from people who were already there by IETF times; what are the
difference between “IETF time” and “WHATWG time” in the way of working?
Newsflash:
On Tue, 20 Feb 2007 21:56:30 -0500, Michel Fortin wrote:
Le 2007-02-20 à 19:05, Ian Hickson a écrit :
The proposal to have predefined class names is still very much in the air,
we're mostly waiting for author and implementation feedback to see if it
is workable. Currently the HTML5 spec
On Wed, 21 Feb 2007 17:10:42 +0100, Anne van Kesteren wrote:
On Wed, 21 Feb 2007 16:56:56 +0100, David Latapie [EMAIL PROTECTED] wrote:
I don't say so just for nitpicking, but would also appreciate feedbacks
from people who were already there by IETF times; what are the
difference between
On Wed, 21 Feb 2007 17:28:16 +0200, Henri Sivonen wrote:
Actually, the fact that many native English speakers cannot write
it's vs. its or they're vs. their vs. there correctly
suggests that people have a tendency to think in terms of aural
*presentation* of the language instead of the
Benjamin Hawkes-Lewis wrote:
James Graham wrote:
Obviously I would love to be proven wrong but given the
limited success in this field in the last decade, I'm not holding my breath.
What actual attempts have been made in this field, that could be judged
relative successes or failures?
The
Ian Hickson wrote:
The original reason I got involved in this work is that I realised that
the human race has written literally billions of electronic documents, but
without ever actually saying how they should be processed.
That's a feature, not a bug.
If, in a
thousand years, someone
Vlad Alexander (xhtml.com) wrote:
Is it due to a flaw in HTML that it is difficult to build authoring tools, such
as WYSIWYG editors, that generate markup rich in semantics, embody
best-practices and can be easily used by non-technical people? Since much of
the content on the Web is created
Elliotte Harold wrote:
Authorial intent is a myth.
Presumably you don't mean that authors don't have intents, but rather
than authorial intent is ultimately irrecoverable. That's true, but it's
not necessarily an especially useful truth (in this context). All
communication involves
Michel Fortin wrote:
t that, I would like to suggest that the current text be changed to
reserve class names starting with a dash - for private use. That way
that we would have a pool of class names which are guarantied to not be
taken over later when new predefined class names are added.
Le 2007-02-21 à 11:34, David Latapie a écrit :
I think it'd be useful to have that on rel values (link types) as
well.
rel=microformat?
The rel attribute is about links. What I meant by that is that I
think it would be useful to have a private domain for link types too.
It would work a
On Mon, 19 Feb 2007, Vlad Alexander (xhtml.com) wrote:
Why do we need X/HTML 5? When did this need become apparent?
HTML started as a document language for scientist to share their
work. It evolved over time; for example the img element was added,
forms were added, WYSIWYG features were added,
4. One of the biggest problems with HTML is that content authors can get away
with writing tag soup. As a result, most content authors don't feel the need
to write markup to specification. When markup is not written to specification,
CSS may not get applied correctly, JavaScript may not execute
...
10. In the minds of most people, HTML is dead and X/HTML 5 is perceived as an
attempt to resurrect it. Given this perception, how can you succeed in
marketing HTML to consumers (those who build Web sites)?
Aren't those minds of the people who sell XHTML tools with false
statements like
Vlad Alexander (xhtml.com) wrote:
(NB I'm just another correspondent, not an official WHATWG voice or
anything.)
Why not put an end to tag soup by requiring user-agents to only
accept markup written to specification?
Problem 1: Even if HTML5 were /not/ intended to be backwards compatible,
Vlad Alexander (xhtml.com) wrote:
4. One of the biggest problems with HTML is that content authors can
get away with writing tag soup. As a result, most content authors
don't feel the need to write markup to specification. When markup is
not written to specification, CSS may not get applied
On Feb 21, 2007, at 10:00 AM, Vlad Alexander (xhtml.com) wrote:
4. One of the biggest problems with HTML is that content authors can
get away with writing tag soup. As a result, most content authors
don't feel the need to write markup to specification. When markup is
not written to
On Tue, 20 Feb 2007, Vlad Alexander (xhtml.com) wrote:
4. One of the biggest problems with HTML is that content authors can get
away with writing tag soup.
Is it really a problem? Or is it the reason the Web is so wildly
successful? Would the Web have taken off in the same way if it worked
Thank you Ian. Just one follow-up question. You wrote:
...We could require editors to do this, but since nobody knows
how to do it, it would be a stupid requirement. ...
Is it due to a flaw in HTML that it is difficult to build authoring tools, such
as WYSIWYG editors, that generate markup
On Tue, 20 Feb 2007, Vlad Alexander (xhtml.com) wrote:
...We could require editors to do this, but since nobody knows how to
do it, it would be a stupid requirement. ...
Is it due to a flaw in HTML that it is difficult to build authoring
tools, such as WYSIWYG editors, that generate
Vlad Alexander (xhtml.com) wrote:
Thank you Ian. Just one follow-up question. You wrote:
...We could require editors to do this, but since nobody knows how
to do it, it would be a stupid requirement. ...
Is it due to a flaw in HTML that it is difficult to build authoring
tools, such as
Le 2007-02-20 à 19:05, Ian Hickson a écrit :
The proposal to have predefined class names is still very much in
the air,
we're mostly waiting for author and implementation feedback to see
if it
is workable. Currently the HTML5 spec leaves a number of things
unanswered
(like what happens if
Le 21 févr. 2007 à 09:05, Ian Hickson a écrit :
If we want to make HTML5 successful, we have to make sure the browser
vendors pay attention to it. Any requirements that make their
market share
go down relative to browsers who aren't following the spec will
immediately be ignored.
it seems
Le 21 févr. 2007 à 11:39, Ian Hickson a écrit :
On Tue, 20 Feb 2007, Vlad Alexander (xhtml.com) wrote:
...We could require editors to do this, but since nobody knows
how to
do it, it would be a stupid requirement. ...
Is it due to a flaw in HTML that it is difficult to build authoring
Le 21 févr. 2007 à 11:40, Lachlan Hunt a écrit :
It's not so much a flaw in HTML's design, as it is the refusal of
popular WYSIWYG editor vendors to replace common presentational
UIs, such as font styles and colours, with much more useful
semantic UIs. I don't believe it's particularly
At 21:21 -0500 UTC, on 2007-02-20, Vlad Alexander (xhtml.com) wrote:
[...]
Is it due to a flaw in HTML that it is difficult to build authoring tools,
such as WYSIWYG editors, that generate markup rich in semantics, embody
best-practices and can be easily used by non-technical people?
I think
On Thu, 4 Jan 2007, Mike Schinkel wrote:
I think you are saying that it could allow it?
Yes.
The tag soup is just the parsing rules. The parsing rules are part
of the markup language. The markup language is explicitly in scope.
Is there no room in a spec to make non-normative
Ian Hickson wrote:
Well, there's some room for that (that's mostly what the
green notes are in the spec), but in general those notes are
only included for uncontroversial suggestions -- when there's
the slightest suggestion of controversy, the suggestions are
best included outside the
On Thu, 4 Jan 2007, Mike Schinkel wrote:
Cool. How do I get rights to post on the blog?
Everyone has rights to post on the blog.
And where exactly should I link that type of proposal from here?
http://wiki.whatwg.org/wiki/Feature_Proposals
Wherever you think is best. There are no rules.
On Tue, 26 Dec 2006, Mike Schinkel wrote:
I'm wondering if you collectively would consider adding the following to
the spec; a recommendation that clients offer two modes; one mode
being for users where the spec works as currently envisioned. The second
mode would be for web developers
Ian Hickson wrote:
# This specification defines the parsing rules for HTML
documents, whether # they are syntactically valid or not.
Certain points in the parsing # algorithm are said to be
parse errors. The error handling for parse # errors is
well-defined: user agents must either act as
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 Wed, 6 Dec 2006, James Graham wrote:
Ian Hickson wrote:
On Tue, 5 Dec 2006, James Graham wrote:
As someone in the process of implementing a HTML5 parser from the spec, my
_only_ complaint so far is that there aren't (yet) any testcases.
If you could get together with the other
101 - 200 of 248 matches
Mail list logo
