Mark Baker wrote:
The real problem here AIUI - at least in the context of HTML 5's
inferred rel=feed bit - is not just entry documents, it's any Atom
document which wouldn't normally be considered a feed by a typical
user; something that most people would be interested in subscribing
to. An
Actually, for the form application/atom+xml;type=entry it's more
likely that browsers will completely ignore the type param as they do
currently.
- James
fantasai wrote:
[snip]
That means rel=feed won't be implied on an Atom Entry document whether
the
new MIME type syntax is chosen to be
I can't recall if it has been already discussed:
Why do we need an event-source element in the markup? It only makes sense in
conjunction with scripting, so I think it would be better to drop this element
and have the event source objects only created by scripts. Similar practices
are already
In the top part of the Close tag open state there's no mentioning of
consuming the next input character and this is correct. However, then it
goes on saying that you should reconsume the current input character in
the data state. I think it makes more sense that to say that you just have
On Wed, 06 Dec 2006 09:33:30 +0100, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
http://whatwg.org/specs/web-apps/current-work/#elements lists the
elements which are considered void. The command and event-source
also have empty content model, so shouldn't they end up there as well?
That's in
Ian Hickson wrote:
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
On Fri, 01 Dec 2006 13:39:27 +0600, Lachlan Hunt [EMAIL PROTECTED] wrote:
3. The start tag may have a number of attributes, the syntax for which
is described below. Attribute names must be separated from the tag
name or a preceding unquoted attribute value, and should be separated
On Wed, 06 Dec 2006 10:50:29 +0100, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
3. The start tag may have a number of attributes, the syntax for which
is described below. Attribute names must be separated from the tag
name or a preceding unquoted attribute value, and should be
On Wed, 06 Dec 2006 16:04:20 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote:
3. The start tag may have a number of attributes, the syntax for which
is described below. Attribute names must be separated from the tag
name or a preceding unquoted attribute value, and should be
On Tue, 05 Dec 2006 00:54:04 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
I mean that the feed might contain items that were never part of the page
linking to the feed. For example, this page:
!DOCTYPE HTML
titleFeeds for this site/title
link rel=feed href=status.xml
link
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 people writing parsers and come
up with a standard
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 people writing parsers and
Sam Ruby wrote:
Anne van Kesteren wrote:
http://code.google.com/p/html5lib/
I have no interest in participating in a project without test cases.
You are entirely right that we have a serious lack of testcases at the moment.
This is intended to be a temporary situation, hence my interest
On Wed, 6 Dec 2006, Bjoern Hoehrmann wrote:
If something can be deduced it is there for all intents and purposes.
You can look at this from a very practical perspective: someone wants to
build a HTML5 conformance checker. He has already implemented an al-
gorithm that transforms a
The section on handling entities should contain the following mapping:
128: 8364,
129: 65533,
130: 8218,
131: 402,
132: 8222,
133: 8230,
134: 8224,
135: 8225,
136: 710,
137: 8240,
138: 352,
139: 8249,
140: 338,
141: 65533,
142: 381,
On 12/5/06, Sam Ruby [EMAIL PROTECTED] wrote:
I have a request. It would be nice if the sniffing algorithm made an
exception for text/plain.
It would be nice, but
Use case:
http://svn.smedbergs.us/wordpress-atom10/tags/0.6/wp-atom10-comments.php
Fixed in FF 2.0.0.1, btw. text/plain
On Wed, 6 Dec 2006, Alexey Feldgendler wrote:
On Fri, 01 Dec 2006 13:39:27 +0600, Lachlan Hunt [EMAIL PROTECTED] wrote:
3. The start tag may have a number of attributes, the syntax for which
is described below. Attribute names must be separated from the tag
name or a preceding
Anne van Kesteren wrote:
The section on handling entities should contain the following mapping:
128: 8364,
129: 65533,
130: 8218,
131: 402,
132: 8222,
133: 8230,
134: 8224,
135: 8225,
136: 710,
137: 8240,
138: 352,
139: 8249,
140: 338,
On Wed, 6 Dec 2006, Alexey Feldgendler wrote:
On Tue, 05 Dec 2006 00:54:04 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
I mean that the feed might contain items that were never part of the page
linking to the feed. For example, this page:
!DOCTYPE HTML
titleFeeds for this
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
Hi,
From: Ian Hickson [EMAIL PROTECTED]
A missing /option implies non-conformance but no parse error per 9.1
and 9.2 respectively.
option and other form controls aren't yet really part of the
specification, and are missing all over the place. I added these to the
syntax section for you,
On Wed, 6 Dec 2006, Simon Pieters wrote:
From: Ian Hickson [EMAIL PROTECTED]
A missing /option implies non-conformance but no parse error per 9.1
and 9.2 respectively.
option and other form controls aren't yet really part of the
specification, and are missing all over the place. I
On Wed, 06 Dec 2006 17:51:55 +0100, Sam Ruby [EMAIL PROTECTED]
wrote:
+1, though I would suggest a one change:
159: 376 // Yuml;
Yeah. That was actually a mistake on my side.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Robert Sayre wrote:
On 12/5/06, Sam Ruby [EMAIL PROTECTED] wrote:
I have a request. It would be nice if the sniffing algorithm made an
exception for text/plain.
It would be nice, but
Use case:
http://svn.smedbergs.us/wordpress-atom10/tags/0.6/wp-atom10-comments.php
Fixed in FF 2.0.0.1,
On Wed, 06 Dec 2006 07:52:17 +0530, Karl Dubost [EMAIL PROTECTED] wrote:
Le 6 déc. 2006 à 04:08, Martin Atkins a écrit :
Mike Schinkel wrote:
All really sucessful text formats have been easy to edit (why did
RSS take off while RDF is still struggling to get off the ground?)
I don't
On 12/6/06, Sam Ruby [EMAIL PROTECTED] wrote:
How was it fixed?
It was fixed in a way that covers mis-sniffed feed content
specifically. That is, content that was sniffed as a feed but isn't
one, like that Atom template or some FOAF files, are displayed
correctly. These are edge cases.
Both
On Wed, 6 Dec 2006, Bjoern Hoehrmann wrote:
So my authoring tool takes a conforming document, parses that into a
Document, the user adds a proper table with only tr/td elements, and
requests to save the document as HTML. My authoring tool then writes
Document.innerHTML into the file.
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
Hi,
From: Ian Hickson [EMAIL PROTECTED]
Hm. Actually an optgroup start tag has to imply an /optgroup end tag
for compatibility with browsers... spec fixed.
Then nested optgroups as allowed in WF2 is just another thing that only
works in XHTML5? How many sites would break if /optgroup wasn't
* Ian Hickson wrote:
No conformance criteria are broken if the user agent is assumed to have
converted the document to a serialisable form by adding an appropriate
tbody element and then serialised that.
If the user agent has not, e.g. it shows a tree of what it thinks it
serialised, and that
Le 6 déc. 2006 à 21:33, James Graham a écrit :
Did you have a list for implementers somewhere? I think it would be
a very worthwhile effort to come up with a set of implementation
independent, self-describing (i.e. where the testcase itself
contains the expected parse tree in some form),
Charles McCathieNevile wrote:
To say it is foundering seems to me like suggesting that jet aircraft are
foundering because most people use propellor planes, or cars.
Let me restate then: RDF is floundering to achieve widespread adoption.
And from everything I've read, I've come to believe that
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
Martin Atkins write:
All really sucessful text formats have been easy to
edit (why did RSS take off while RDF is still
struggling to get off the ground?)
I don't necessarily disagree with your sentiment, but
it could be argued that RSS has done well while RDF
has floundered
Alexey Feldgendler wrote:
An interesting idea, but I don't see how Google would benefit from this.
1.) If the web get cleaner, it's easier for search engines to inspect
documents
2.) If Google doesn't benefit from a better web, why would they pay Ian to
edit the HTML5 spec?
On the other hand,
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
Le 6 déc. 2006 à 04:35, Alexey Feldgendler a écrit :
On Tue, 05 Dec 2006 22:30:36 +0600, Lachlan Hunt
[EMAIL PROTECTED] wrote:
A specification cannot refer to something as volatile as a wiki
page.
Actually, it's already doing that in another section.
Le 6 déc. 2006 à 11:17, Karl Dubost a écrit :
What Elias is saying is that the effort of RDFa community is
1. compatible with microformats (no changes are asked on this
front)
2. being able to relate information distributed in a document
(people do not want to have necessary to
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:
Elias Torres wrote:
On the other hand, we keep missing the point,
that no matter what the syntax is, in microformats
at least (our current answer) we can't differentiate
from class values that are properties/classes(types)
and which ones are not.
Here's at least one good use-case
Lachlan Hunt wrote:
It's not up to a specification to specify a
conformance requirement stating which
implementations can be used, nor mandating
particular implementation details.
By providing the suggest test I was trying to get people to use a conforming
component for all the reasons I
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
Sam,
Le 6 déc. 2006 à 23:13, Sam Ruby a écrit :
My original interest was to write a replacement for Python's
SGMLLIB, i.e., one that was not based on the theoretical ideal of
how SGML vocabularies work, but one based on the practical notion
of how HTML actually is parsed.
I'm not sure
On Tue, 5 Dec 2006, Elias Torres wrote:
div span class=ibm-part-descriptionour part number span
class=part-id123/span/span/div
Yes? What about it?
I guess this is similar to Karl's example.
div id=order1 class=ibm-order
span class=ibm-part-descriptionour part number
Thanks for your patience trying to work out these extremely hypothetical
examples with me. I need to figure out a way to get the internal
examples out here so we can discuss them concretely. In the meantime,
you have motivated me to look at the existing infrastructure with a
different perspective
On Thu, 07 Dec 2006 06:08:56 +0600, Karl Dubost [EMAIL PROTECTED] wrote:
A specification cannot refer to something as volatile as a wiki
page.
Actually, it's already doing that in another section.
http://www.whatwg.org/specs/web-apps/current-work/#other
I think it's inappropriate there as
On Thu, 07 Dec 2006 05:09:44 +0600, Mike Schinkel [EMAIL PROTECTED] wrote:
A specification cannot refer to something as volatile as a wiki page.
Then have it refer to something less volatile than a wiki page.
A section in the spec itself would be just fine. The wiki page could, of
course,
On Thu, 07 Dec 2006 05:09:44 +0600, Mike Schinkel [EMAIL PROTECTED] wrote:
And if these corporations were using content management systems that didn't
produce standards-based code, you can bet those CMS vendors would soon have
a new #1 priority, but fast. And THAT would clean up the web
52 matches
Mail list logo
